[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Candidate re-charter/new WG
Are these sessions/BOFs already scheduled? I didn't find anything at
http://www.ietf.org/meetings/agenda.html
Thanks
Christian
> -----Original Message-----
> From: Ian Cooper [mailto:icooper@equinix.com]
> Sent: Friday, November 03, 2000 12:10 PM
> To: wrec@cs.utk.edu
> Cc: Patrik Fältström; Ned Freed; cdn@ops.ietf.org;
> ietf-openproxy@imc.org
> Subject: Candidate re-charter/new WG
>
>
> 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
>
>
>