Re: Candidate re-charter/new WG

[Dan Li <lidan@cisco.com>]

I think it's a good idea to have a focused forum to get something done. A 
web cache invalidation protocol will bring much value to reverse proxies 
(surrogates), forward proxies, and CDNs alike. Having WEBI devoted to it is 
a good thing.

Whatever WREC is bad for, I hope the execution of WEBI would remove any 
residue of that.

At 08:10 PM 11/3/00 +0000, Ian Cooper wrote:
>Now that we appear to have gotten to the end of the WREC work items (there 
>will be a new version of the Known Problems document - just changing the 
>order of things as an outcome of the Pittsburgh meeting - submitted in the 
>next few days), we need to decide how to move on.
>
>Below is a candidate (re)charter to take WREC forward as the "Web 
>Infrastructure" group (thanks to those who have given input of their 
>varying types).  As you'll see, the idea is to take on two work items that 
>we believe are essential for web infrastructure going forward.
>
>There is some cross over with the invalidation protocol with the CDNP 
>folks.  Since such a protocol is applicable to both areas, and since the 
>CDNP folks look to have plenty of other interesting things to work on, 
>WREC/WEBI appears to be a good place to work on this essential issue.
>
>Likewise, there is some degree of cross over with the intermediary 
>discovery protocol.  In order to have some hope of moving away from 
>interception proxy environments, we need to help user agents find 
>intermediates (proxies, extensible proxies, surrogates).  Given that this 
>is an area where two proposed WGs (CDNP, OPES) would also have an 
>interest, and since it doesn't appear to be directly in scope for either, 
>we feel that WREC/WEBI is the best place for this.
>
>Why the name change?  As (caching) proxies and surrogates become essential 
>components in the web infrastructure we need to examine interactions 
>between these systems.  "Web Replication and Caching" doesn't seem a 
>sufficiently descriptive group name.  There also appears to be a general 
>feeling of WREC=bad (and the name when spoken doesn't help any) that we'd 
>like to try and move away from.
>
>At present it's not totally clear whether we should be going direct to a 
>working group in San Diego, or whether we should go through a BoF stage to 
>discuss the area and determine whether the group is necessary (and if not 
>where the work items should be handled).
>
>Apologies for the short notice, but obviously we need to get an idea of 
>what we're doing in time to request a meeting in San Diego.  Truncating 
>the distribution to the WREC list (the "webi" list has *not* been set up 
>yet) would probably be a good idea.  (I'd set a Reply-To but I don't know 
>how to drive that part of my mail agent ;-) )
>
>Comments please!
>
>
>--------------------------->8-------------------------------------------
>
>Web Infrastructure (webi)
>
>Co-chairs:
>    Mark Nottingham <mnot@akamai.com>
>    Ian Cooper <icooper@equinix.com>
>
>Mailing Lists: [TENTATIVE]
>    General Discussion: webi@equinix.com
>    To Subscribe: webi-request@equinix.com
>    Archive: ftp://ftp.ietf.org/ietf-mail-archive/webi
>
>Description of Working Group:
>
>This working group will address specific issues identified by the WREC 
>working group in the world wide web infrastructure, providing generic 
>mechanisms which are useful in several application domains (proxies, 
>content delivery surrogates).
>
>Work items for this group will be:
>
>1) An invalidation protocol to provide a strong cache coherence mechanism
>    while avoiding the latency penalty of validation, usable in proxy as well
>    as surrogate configurations.
>
>2) An intermediate service discovery mechanism, consisting of:
>
>   a) An intermediary service description format, which describes what
>      services an intermediary or arbitrary group of intermediaries is
>      willing to provide, and
>
>   b) A discovery protocol for locating relevant service descriptions within
>      a single administrative domain.
>
>   Both components will take into consideration current practice, related
>   work in the IETF, and a reasoned set of requirements, which will include
>   the need to provide a reasonable alternative to interception proxies.
>
>Service discovery, and other issues pertaining to coordination between 
>multiple administrative domains are explicitly out of scope of this group.
>
>Protocols associated with the provisioning of value added services, 
>including the vectoring of adaptation requests to other devices, is also 
>out of scope for this group.
>
>
>Goals and Milestones:
>
>Feb 01: Requirements document for intermediary discovery and description
>Feb 01: First draft invalidation protocol
>Mar 01: Meet at Minneapolis IETF
>Apr 01: First draft intermediary discovery protocol
>Jul 01: First draft intermediary description mechanism
>Aug 01: Meet at London IETF
>Dec 01: Invalidation protocol finalized
>Dec 01: Salt Lake City
>Jan 02: Intermediary discovery protocol finalized
>Mar 02: Intermediary description mechanism finalized
>Apr 02: Re-charter
>
>