RE: Some cautionary comments

["Mark Day" <markday@cisco.com>]

> What's important is that we add the appropriate verbiage to the
> I-Ds and that
> affected organizations make an appropriate statement to the IETF.

Agreed.

> Speaking of which... I presume the charter has gone out by now?
> Discussion of
> the charter died out a while back and I eagerly await formal
> chartering... and
> am keeping my fingers crossed that they can again schedule all
> the related WGs
> in one day again :)

Yes, Phil and I worked out a slightly-modified charter a little while ago
and submitted that. Text below.

--Mark

Content Distribution Internetworking (cdi)

Chairs:
Mark Day <markday@cisco.com>
Phil Rzewski <philr@inktomi.com>

Applications Area Directors:
Ned Freed <ned.freed@innosoft.com>
Patrik Faltstrom <paf@cisco.com>

Applications Area Advisor:
Patrik Faltstrom <paf@cisco.com>

Mailing lists:
General discussion: cdn@ops.ietf.org
To subscribe: cdn-request@ops.ietf.org
Archive: ftp://ops.ietf.org/pub/lists/cdn.*

Description of Working Group:

The goal of this working group is to define protocols to allow the
interoperation of separately-administered content networks.

A content network is an architecture of network elements, arranged for
efficient delivery of digital content. Such content includes, but is not
limited to, web pages and images delivered via HTTP, and streaming or
continuous media delivered via RTSP.

Caches and caching systems have been deployed for a number of years.  More
recently, a number of CDN (content distribution network or content delivery
network) services have been built and offered commercially. In addition, a
number of hardware and software vendors have developed products that enable
the construction of CDNs or CDN-like systems with "off-the-shelf" parts.
The proliferation of content-networking capabilities gives rise to interest
in interconnecting these systems and finding ways for
separately-administered networks to cooperate for better overall service

A content network has some combination of a request-routing system, a
content-delivery system, a distribution system, and an accounting system.
In some cases, such a "system" may be implemented by very simple components
or techniques.
-- The content-delivery system consists of a set of "surrogate" servers that
deliver copies of content to sets of users.
-- The request-routing system consists of mechanisms that move a client
request toward a rendezvous with a surrogate.
-- The distribution system consists of mechanisms that move content from the
origin server to the surrogates.
-- The accounting system records and aggregates information necessary for
allocating costs.
An effective content network arranges the request/content rendezvous to take
place at a surrogate that is "well suited" to a given client. Some content
networks may use IP multicast, satellite distribution, and/or
application-layer multicast as part of their implementation, but none of
these specific technologies is required in a content network.

The working group will first define requirements for the three kinds of
content internetworking: interoperation of request-routing systems,
interoperation of distribution systems, and interoperation of accounting
systems.  These requirements are intended to lead to a follow-on effort to
define protocols for interoperation of these systems.

In its initial form, the working group is not chartered to deliver those
protocols, but we encourage individual submission of internet-drafts
describing protocols intended to meet the evolving requirements.  We
anticipate rechartering of the working group to specify protocols, after the
requirements documents are stable and rough consensus emerges about the
number and relationship of such protocols.

In addition to defining requirements, the working group will develop a
number of supporting documents.  These documents are: a shared vocabulary
for the problem domain, scenarios, an overall architecture for
interoperation, and a summary of request-routing mechanisms currently in
use.  The total expected deliverables are as follows, along with notes
indicating the drafts that are a start on each document:

1. Vocabulary
	(Merged from drafts day-cdnp-model and rzewski-oacp)

2. Scenarios
	(Merged & enlarged from drafts day-cdnp-scenarios and rzewski-oacp)

3. System Architecture
	(Merged from draft-green-cdnp-gen-arch and rzewski-oacp, requirements moved
out to appropriate requirements documents)

4. Request-Routing Known Mechanisms
	(finish cain-cdnp-known-request-routing)

5. Requirements for Request-Routing
	(mostly new, partly from draft-green-cdnp-gen-arch)

6. Requirements for Distribution
	(mostly new, partly from draft-green-cdnp-gen-arch and rzewski-cndistcs)

7. Requirements for Accounting
	(finish draft-gilletti-cdnp-aaa-reqs, merge requirements from
rzewski-cnacct)

Goals and Milestones

December 2000: BOF meets.  Editors chosen for requirement documents,
protocol documents.

February 1, 2001: First drafts of all requirements due on mailing list.

March 1: "Final" versions of all group documents submitted in advance of
Minneapolis meeting. Last call period starts for all non-requirements
documents.

March 18-23: WG meets at Minneapolis IETF meeting to discuss requirements
issues, any individual protocol submissions.

May 1: New versions of requirements, incorporating discussions from meeting

June 1: Last call for requirements.

August 5-10: WG meets at London IETF to recharter for protocol design.

Internet Drafts:

http://www.ietf.org/internet-drafts/draft-day-cdnp-model-04.txt
http://www.ietf.org/internet-drafts/draft-day-cdnp-scenarios-02.txt
http://www.ietf.org/internet-drafts/draft-gilletti-cdnp-aaa-reqs-00.txt
http://www.ietf.org/internet-drafts/draft-green-cdnp-gen-arch-02.txt
http://www.ietf.org/internet-drafts/draft-cain-cdnp-known-request-routing-00
.txt
http://www.ietf.org/internet-drafts/draft-rzewski-oacp-00.txt
http://www.ietf.org/internet-drafts/draft-rzewski-cndistcs-00.txt
http://www.ietf.org/internet-drafts/draft-rzewski-cnacct-00.txt
http://www.ietf.org/internet-drafts/draft-deleuze-cdnp-dnsmap-peer-00.txt