Final DRAFT of the WEBI minutes.
Any issues/corrections to myself by close of business PDT Friday 7
September please. Final minutes must be submitted to IETF on 10 September
at the latest.
As you will see, there are a couple of spots where we are unclear on the
attributions. If you happen to know the names or correct attributions (I
hope we're not putting words into Mark Day's mouth) please send these
in. We appear to have an elusive "Paul G".
Changes since last draft:
1) Clarified Fred's comment in 2nd para. of "client driven invalidation"
2) Corrected a couple of names/spellings
Draft minutes of the WEBI Working Group meeting, IETF51 (London)
Tuesday, 7 August 2001; 1300-1400
Co-chairs:
Ian Cooper <icooper@equinix.com>
Mark Nottingham <mnot@akamai.com>
Agenda:
The primary purpose of this meeting is to bring the RUP Requirements
document to a state where it can move forward to WG Last Call.
1) Agenda Bashing 2 minutes
2) Group Status 3 minutes
3) draft-ietf-webi-rup-requirements-01.txt 50 minutes
4) IDD update 3 minutes
5) Wrap up 2 minutes
Minutes taken by:
Ian Cooper <icooper@equinix.com>
Imran Chaudhri <imran@panteratech.com>
Minutes combined by Ian Cooper
During agenda bashing a request to cover ESI (Edge Side Includes)
Invalidation was made. Mark Nottingham stated that he had already planned
on giving an update and that this would be given in the context of the RUP
requirements update. Agenda accepted.
The chairs aired their concerns over a feeling of past lack of
participation, but acknowledged that there had been good discussion on the
mailing list. Thanks was given to Dan Li for her work on the RUP
requirements draft. Less than half of the room acknowledged having read
the requirements draft.
Mark Nottingham proceeded to cover some open issues in the RUP requirements
draft.
Use Cases:
==========
1) Server driven invalidation (push)
------------------------------------
Oskar Batuner commented that the document in general was very protocol
oriented and suggested that it should not go into some deep levels of
discussion.
Oskar also commented that requirements should not necessarily concentrate
on specific directions, but should support a general case - may be a
hierarchical configuration where the (origin) server is not directly in
communicating with the systems ultimately receiving the notifications.
(?)Joseph Hui suggested we should assume a reliable transport protocol -
requiring positive acknowledgement could tie up the system.
2) Client driven invalidation (pull)
------------------------------------
General feeling, raised by Oskar Batuner, was that the use case was
good. Dirk-Willem van Gulik commented that it may make life easier with
outward facing systems.
Fred Douglis commented that allowing arbitrary "clients" to participate in
RUP was a good idea, but would complicate things.
(?)Paul G suggested we do not use the term "transaction" since it conveys
strong meaning in other senses. The group agreed on this point.
Mark Day (?) suggested confirmation of (in)validation needs to be a
requirement. Dave Martin stated that confirmation was a requirement.
[NOTE: Unsure whether the initial comment came from Mark Day]
Andrew Randall asked whether this was a use case for OPES. Lee Rafalow
stated that this would be bending OPES, though it could be done.
For discussion on the list: should the systems be transactional?
3) Content location update
--------------------------
(This is where a content system redirects the receiving system to go
elsewhere for the invalidations)
Lisa Amini commented that this crosses over from pure invalidation to
meta-data, and that we would need to address meta-data in general if
included. At present this use case is the only reference to
meta-data. Mark Nottingham responded that he believed we should have
meta-data signalling but that list traffic indicated it was too much to
cover for the first draft and that we should be concentrating on
invalidation in this version. Lisa and John Border commented that CDI
needs meta-data; we should avoid duplication between groups where we can.
Mark Nottingham suggested we address invalidation (as the primary payload)
at present but to allow other data to be distributed while not considering
the exact definition of those payloads at this time.
4) Content prefetch hint
------------------------
Ian Cooper made a general comment within the context of this case that the
terms "client" and "server" appear to be confusing within the document
since they have well defined uses as roles in other environments. Some
possible suggestions were made:
??: "invalidator" for client, "listener" for server
Imran Chaudhri: content viewer and content publisher
Paul G(?) suggested we examine references in the distributed processing
realm for assistance here.
Also queried regarding "managed" and "unmanaged" entities (e.g. cache) and
whether better terms could be found. Andrew Randall queried whether we
needed to make any distinction between managed and unmanaged entities in
any case - group consensus was that there was no need to make this distinction.
Mark Nottingham commented that the document needs to include a list of
those entities that are allowed to participate within the RUP protocol realm.
(Aside comment from Mark Day - the group needs to maintain an "issues
list". Some discussion as to whether this was the responsibility of the
chairs ensued (no firm outcome).)
Ian Cooper queried whether there was any way to limit the scope of use of
the protocol (in order to address scaling characteristics) other than
authorization. Oskar Batuner suggested that an authorization feature was
required to limit access. Fred Douglis commented that some systems
explicitly deny access from browsers. Joseph Hui commented that we should
examine AAA requirements.
At this point it was noted we were starting to run short on time and that
discussions should be moved to the mailing list.
Mark Nottingham gave a short updated on the ESI invalidation protocol -
originating at Oracle. Moves toward this being a SOAP based protocol. ESI
Invalidation is a point-to-point solution of limited utility whereas RUP is
intended as a scalable protocol. Lee Rafalow queried where a
point-to-point protocol would be more appropriate than a scalable
protocol. Fred Douglis commented that point-to-point had first mover
advantage. Mark stated that he would write an email explaining the issues
and would send these to the list.
A short update on IDD was given; the co-chairs had had no success in
generating any interest in the browser vendor community, although IDD was
still seen as interesting. The chairs encouraged contributions in this area.
This archive was generated by hypermail 2b29 : Thu Nov 18 2004 - 11:22:59 MST