Subject: Rechartering WREC

From: Mark Nottingham <[email-masked]>
Date: Sun, 8 Oct 2000 12:54:43 -0700

Recently, there's been a lot of discussion in various places about the
status of WREC, particularly since there are a few other proposals for new
working groups (currently at the BoF request stage) that need to define a
relationship, or lack thereof, to WREC before they can move forward.

WREC has a somewhat difficult past, and is currently somewhat dormant. This
may lead people to believe that the sensible thing to do is to close the
group down and split any work items off to the new groups; I'd like to
dispute this, and open more public discussion about the future of WREC.

The group's past has been difficult because it had some work items (the
taxonomy, and the known problems document) that had to be completed before
"real" work could be started. Additionally, the interception proxy issues
and misconceptions have plagued the group for some time; it's only recently
that a clear consensus about them seems to be forming.

However, these work items are nearly finished, and interception proxies are
an issue that can be resolved (either within the group, or in another
non-Application group). The main reason for domancy of the group is the fact
that there have been no further milestones identified for it, so that we're
stuck at re-chartering.

I'd argue that now is an excellent time for WREC to become an active and
useful working group; there are many potential work items for it, including:

* content peering
* enhanced coherence mechanisms (invalidation)
* log summary formats
* surrogate role clarification
* semantic transparency issues in intermediates
* coordination with content negotiation, other groups which affect
  intermediates
* proxy discovery (very important, in light of interception proxies)

More to the point, there's a real need in the IETF for a group that can
address the Web infrastructure as a whole. Highly focused groups, while
usually productive, can miss out on the bigger picture.

To this point, I'd propose that WREC re-charter as soon as possible, with the
above work items as well as others that come to light. In particular;

* I'd like there to be open discussion with the Content Alliance
  participants on the best forum for content peering. I very much appreciate
  the fact that they've opened their mailing list and documents for public
  view; this is a good first step.

  At first glance, it seems confusing that they are proposing a separate
  working group, as content peering is squarely within the charter of WREC. 
  While I can understand that this avoids some problems for them, I think it
  would be interesting to explore how their work and resources can be
  integrated into WREC.

* A relationship should be established with the EPSFW effort, if it evolves
  into a WG (as it appears it may). EPSFW doesn't seem to have as much
  overlap with WREC, except in that it affects proxies and involves semantic
  transparency issues. These need to be coordinated.
  
WREC has been languishing for a while, for a number of reasons. This doesn't
mean that there isn't a role for it, and that it can't address new issues.
Instead of killing it and wasteing a lot of effort, let's address those
reasons and move forward.

-- 
Mark Nottingham, Research Scientist
Akamai Technologies (San Mateo, CA)

---

From: "Mark Day" <[email-masked]>
Date: Mon, 9 Oct 2000 09:56:30 -0400

> To my knowledge the Content Alliance/Peering work hasn't had any such
> review to date, and I think that it's vital we have some
> discussion before
> any decision is made.  I agree with Mark [Nottingham] that at first glance
it seems
> confusing that there's a proposal for a separate group and would find it
> useful - purely from a WREC management perspective - on why that proposal
> was made.

I think we have been consistently agnostic on the issue of where CDN peering
belongs, as long as the work gets done by a group that is focused on doing
it.  Our initial BOF request was to the IESG as a whole, largely because
there was some doubt as to whether CDN peering was more sensibly handled as
part of Applications, Operations, Routing, or Internet.

On the smaller question of relationship with WREC specifically, again I
don't think that there is much of an "Alliance position."  Personally, I
think it would be fine for the IESG to put the CDN peering work into WREC,
subject to two constraints:

1) I wouldn't want for the CDN peering work to be a small fraction of a
larger agenda; WREC's rechartering, if it happens in this way, should be
squarely focused on CDN peering as its primary deliverable.

2) I would want to give the IETF community as a whole a chance for a
thumbs-up/thumbs-down on the work, as a BOF does, rather than somehow
sneaking CDN peering into an existing WG.  I agree that the WREC charter
arguably encompasses CDN peering already, but I doubt that the IETF had that
specifically in mind at the point when WREC was initially chartered. So I
would argue for treating the rechartering as a BOF-like event.

Both of these have more to do with establishing the conditions for success
in a CDN peering effort than they have to do with the history of WREC.  I
understand that WREC has had some travails in the past, but I don't have any
opinion about whether those have impaired its ability to be successful in
the future. I have heard multiple people express concern about WREC's
ability to be a productive forum, but I am not in a position to judge; I
believe the ADs will have a better perspective on that than I have.

--Mark (current chair, Content Peering working group of the Content
Alliance)

Mark Stuart Day
Senior Scientist
Cisco Systems
+1 (781) 663-8310
[email-masked]

---

From: "Barry Raveendran Greene" <[email-masked]>
Date: Mon, 9 Oct 2000 09:27:37 -0700

Hello Mark,

I understand the points you are raising. First off, I support the idea of
doing this sort of work in the IETF vs competitive commercial interest
groups. It is in the Internet's best interest to have all the "competitive
parties" come together in the IETF to work on architecture and protocols
that will further the Internet's success. Right now that is not happening.

Second, there is a lot of history behind the WREC that we do not need to
rehash (i.e. the end-to-end dogma battles). It is for this reason that I
would like to see WREC finish it's work and close down. But that is my
opinion - hence a rechartering discussion should be scheduled at the next
WREC meeting.

Lastly, stacking all the various pieces of work into one WG would be too
cumbersome - bogging down the WG. IMHO - it would be better to break the
work apart into several WGs. If you look at the history of successful WGs,
the most successful WGs (i.e. things that reach draft standard status) have
been single protocol - single issue WGs. So if the
Caching/Replication/CDN/Content/ISP/Co-Location community would like to see
things reach draft standard stage, it would be in the community's best
interest to think about narrowly focused WGs working on specific
protocols/problems. If necessary, a WG just to address the architecture
could be chartered to keep all the pieces of work coordinated. Yes, there
would be push back about "too many WGs," But the community has had to do
this in the past and it can do it again.

So .... I think there should be a "CDN" BOF at the next IETF that will have
several people walk down the list of work that think could be addressed in
IETF WGs. And, WREC should meet - work on closure on the existing work - and
have a discussion on rechartering. At that point, people should start
proposing WGs to the Applications Area Directors.

Barry

> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Sunday, October 08, 2000 12:55 PM
> To: WREC Working Group; [email-masked]
> Subject: Rechartering WREC
>
>
>

---

From: Ian Cooper <[email-masked]>
Date: Sun, 08 Oct 2000 23:04:23 +0100

Mark, many thanks for your comments; I've had very similar thoughts and 
concerns myself.

>relationship, or lack thereof, to WREC before they can move forward.

I've received requests for clarification on WREC's plans by some of the 
folks involved in those other groups.  I'm very aware that they would like 
some kind of decision on our position as soon as possible in order that the 
ADs can make decisions as to whether the BoF requests should be accepted.

(WREC folks, that means we want your input!)

>However, these work items are nearly finished,

To further clarify, the taxonomy has been approved and is currently in the 
rfc-editor queue.

>  and interception proxies are

That's a useful list. Thanks!

>   would be interesting to explore how their work and resources can be

Info on the group at: http://www.content-peering.org/

>   transparency issues. These need to be coordinated.

Info on the group at: http://www.extproxy.org/

The EPSFW folks("Extensible Proxies" - have you guys finalized on a name 
yet? :) ) gave a presentation in Pittsburgh, and the group consensus there 
was that this wasn't something that WREC should take on (that said I don't 
recall any followup discussion on the mailing list, so we shouldn't assume 
anything.)

To my knowledge the Content Alliance/Peering work hasn't had any such 
review to date, and I think that it's vital we have some discussion before 
any decision is made.  I agree with Mark that at first glance it seems 
confusing that there's a proposal for a separate group and would find it 
useful - purely from a WREC management perspective - on why that proposal 
was made.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 10 Oct 2000 09:03:27 +0200

>proposing WGs to the Applications Area Directors.

Not only sending proposed WG charters in the direction of myself an 
Ned, but more importantly a general plan for content distribution.

I would like to see a one-page paper (not much more is needed, or?) 
which talks about what different components exist in a content 
network.

A list such as (but it should fit together):

  - Distribution of data from origin server to copies within administrative
    control of the owner of the data
  - Distribution of data from origin server to copies outside of <above>
  - Preloading / load on demand of caches
  - Cache discovery
  - Routing of client to closest site with data
  - Switching of client to good server within site
  - Billing / charging / statistics collection
  - HTTP / HTML extensions for cache control
  - Continuation of work on taxonomy
:
:
:

You are the one doing the list, and you then tell what on that list 
should be handled by each of the proposed wg's. I am definitly not 
saying that you have to create wg's for everything (I rather see not 
:-), but what pieces you are going to work on, and what have to wait.

And, I want a list which you all in the "wrec" area agree on. Not one 
explanation from each one of you (which I have got so far :-). I.e. 
the stories have to fit together.

     Patrik

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 10 Oct 2000 12:35:45 +0200

>  - Switching of client to good server within site

or rather: - routing of client to closest WORKING site with data

>  - Billing / charging / statistics collection

more:

- user session state management
- TLS interaction
- authentication models for multi-sited servers (having all of them 
configured with the same secret key is not optimal security-wise - loss of 
one means loss of all)

>  - Continuation of work on taxonomy

I know I shouldn't be bringing more tinder to the bonfire, but....

--
Harald Tveit Alvestrand, [email-masked]
+47 41 44 29 94
Personal email: [email-masked]

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 10 Oct 2000 14:01:08 +0200

>I know I shouldn't be bringing more tinder to the bonfire, but....

You should, as many other people.

I.e. when I get the BOF/wg proposals, I want in parallel a list of 
things which you belive should be part of a (sort of) complete model 
of this part of the Internet, and you then say that:

  - WG xxxx is proposed to work with item 1, 3, 4 and 7
  - WG yyyy is proposed to work with item 9
  - Other work items are left for future studies

I don't claim my list was complete (or by any means complete or correct).

You do the list, and you do the charters.

     Patrik

---

From: Eric Brunner-Williams <[email-masked]>
Date: Tue, 10 Oct 2000 08:50:16 -0400

> I know I shouldn't be bringing more tinder to the bonfire, but....

Cache interposition semantics on end-to-end policy evaluation and expiry
semantics is my cup of gasoline. The policy-de-jour is P3P, to which Mark
and I both ... contribute ... or er, illuminate.

I second the user session state management item, and offer a cookie in lieu
of a second cup of gasoline.

Eric