Candidate re-charter/new WG

[Ian Cooper <icooper@equinix.com>]

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