Hi, Ian, nice notes, pretty clear on the issues and consensus!
Let me try to list all the points I see floating in the minutes and on the
post-ietf mailing list. I will then incorporate them into the RUP doc
accordingly. If anyone has additional comments or disagrees with anything,
please speak out now, or at least before we go last call.
Here they are, in no particular order:
- remove the term "transaction" since it conveys strong meaning in other
senses. (Paul G.)
- remove references to NAT. (Joe T.)
- describe the need to work with RUP session discovery mechanisms. (Joe T.)
- ensure that "draft-ietf-webi-rup-reqs" limit itself to "requirements",
and not too "protocol oriented". (Oskar B.)
- ensure that "confirmation of (in)validation" is indeed a requirement.
(Mark D., Dave ..)
- clarify on the "guarantees" RUP needs to provides, and how it relates (or
differs) from "transactions". E.g., section 6.1 item 1 cannot claim to
"support" or "require" strong consistency. (Paul G., Joe T., and Dan L.)
- clarify that general "meta data" is allowed, and accommodated as concrete
payload types and arbitrary payload options, while invalidation is the
primary payload at present. (Mark N., Lisa A., Dan L., etc.)
- clarify the terms "client" and "server" , add the reference list on
transactions. (Ian C. Paul G.)
- remove the distinction between "managed" and "unmanaged", perhaps remove
any mention of them. (Andrew R.)
- add use cases in terms of administrative roles, i.e., a list of entities
that are allowed to participate within the RUP protocol realm. (Mark N.,
Dan L.)
- add security threat models such as DOS, in-band security, etc. (Joe T.)
- include microsoft notification references. (Stephane P.)
- add failure-mode consistency requirement. (Joe T., Dan L.)
A couple of points weren't put on the list:
- "whether there was any way to limit the scope of use of the protocol (in
order to address scaling characteristics) ".
- "assume a reliable transport protocol".
I thought we can dive into them during protocol design, instead of
requirements gathering. Please let me know if you think otherwise.
Any other issues? or misrepresentations of the existing issues?
Thanks!
Dan
At 11:37 AM 9/4/2001 -0700, Ian Cooper wrote:
>Apologies for the delay in getting these out. There are a few blanks and
>attributions that were not clear - if you can help resolve these, or have
>comments/corrections to the minutes in general, please let us know ASAP.
>
>
>
>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 Gulig(sp?) commented that it may make life easier
>with outward facing systems.
>
>[NOTE: Fred Douglis said something about something being a good idea but
>complicating things around here. I have sent him email to see if he
>recalls what this was.]
>
>(?)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 ?? (IBM) 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