Subject: [CDNi] First cut at draft CDNI Charter

From: Francois Le Faucheur <[email-masked]>
Date: Sun, 13 Mar 2011 19:02:30 +0100

Hi,

Rich, Ben and I have put together a first draft for a CDNI WG charter to kick-off discussions in anticipation of the BOF.
Please have a look at it below and provide comments and suggestions.

Cheers

Francois & Rich

PS: It can also be downloaded from the IETF BOK wiki :
http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/Draft-CDNI-Charter-v01.2.txt

Content Delivery Networks Interconnection (CDNI) - Draft Charter
----------------------------------------------------------------

Description of Working Group
============================

A Content Delivery Network (CDN) is an infrastructure of network elements operating at layer 4 through layer 7, arranged for the efficient distribution and delivery of digital content. Such content includes, but is not limited to, web pages and images delivered via HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to multiple Content Service Providers (CSPs).

CDNs provide numerous benefits: a shared platform for multi-service content delivery, reduced transmission costs for cacheable content, improved quality of experience for end users and increased robustness of delivery. For these reasons they are frequently used for large-scale content delivery.

As a result of the significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Subject to the policy of the CSP, it is generally desirable that a given item of content can be delivered to an end user regardless of that end user's location or attachment network. This creates a requirement for interconnecting (previously) standalone CDNs so they can interoperate and collectively behave as a single delivery infrastructure.

The goal of the CDNI (Content Delivery Network Interconnection) Working Group is to define the necessary set of protocols to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents).

The working group will focus on the following items:

- A "problem statement" document providing a description of the problem and a common terminology.

- A "use case" document describing scenarios for usage and applications of the CDNI solution and protocols

- A "framework" document providing a description of the different components of the CDNI solution and how they interact with and relate to one another.

- A "requirements" document. This document lists the requirements for CDNI architecture and the protocols to support it. In particular, this document will focus on identifying a reasonable set of more urgent and important requirements that will be addressed in the initial set of CDNI protocols and solutions produced by the working group.

- A detailed specification of the protocols for the interconnection & interoperation of:

	o CDNI request-routing systems. In particular, this protocol will allow an upstream CDN request routing system to query a downstream CDN request routing system at request routing time, in order to facilitate the redirection of the end user request by the upstream CDN towards the downstream CDN. In accordance with the requirements document, this protocol may also allow a downstream CDN to communicate information to an upstream CDN request routing system to facilitate its request redirection decisions.

	o CDNI metadata distribution systems. This protocol will allow the CDNs to exchange distribution metadata of inter-CDN scope. Distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore to CDNs (for example, this may include geo-blocking information, availability window or access control mechanisms to be enforced)

	o CDNI logging systems, This protocol will allow CDN logging systems to exchange logging information associated with actions that are relevant across CDNs (such as content distribution, content delivery and content routing actions) for purposes of accounting, analytics, monitoring, etc.

	o CDN control systems. In particular, this protocol will allow an upstream CDN to remove or invalidate content in a downstream CDN.

For the above protocols, the working group will leverage existing protocols where appropriate.

The working group will only define solutions for aspects of the CDN Interconnection problem space that require direct communication or interoperation between CDNs.

In particular, the WG will not define:
- New session, transport or network protocols.
- New protocols for delivering content from a CDN to an End User/User Agent.
- New protocols for ingestion of content or metadata between a CSP and a CDN.
- New protocols for acquiring content across CDNs.
- Protocols and algorithms for intra-CDN operations.

The WG will work with other WGs to assess, and where appropriate, extend protocols developed by those WGs, in order to realize the CDNI requirements and CDNI protocols. For example, the WG may assess the suitability of the ALTO protocol as a protocol to enable downstream CDNs to exchange information which may aid an upstream CDN with making CDNI request routing decisions.

Goals & Milestones
==================

WG Creation + 6 months: 	Submit CDNI problem statement to IESG as Informational
WG Creation + 9 months: 	Submit CDNI use cases to IESG as Informational
WG Creation + 12 months: 	Submit CDNI framework to IESG as Informational
WG Creation + 12 months: 	Submit CDNI requirements to IESG as Informational
WG Creation + 18 months: 	Submit specification of the CDNI Request Routing protocol to IESG as Proposed Standard
WG Creation + 18 months: 	Submit specification of the CDNI Logging protocol to IESG as Proposed Standard
WG Creation + 18 months: 	Submit specification of the CDNI Control protocol to IESG as proposed Standard
WG Creation + 24 months: 	Submit specification of the CDNI Metadata Distribution protocol to IESG as Proposed Standard
WG Creation + 24 months: 	Recharter or dissolve

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 21 Mar 2011 12:45:19 -0400

Francois,

  Should specification of a base set of metadata be part of the charter?

thanx.

--  Kevin J. Ma

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francois Le Faucheur
> Sent: Sunday, March 13, 2011 2:03 PM
> To: [email-masked]
> Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
> Subject: [CDNi] First cut at draft CDNI Charter
> 
> Hi,
> 
> Rich, Ben and I have put together a first draft for a CDNI WG charter to kick-
> off discussions in anticipation of the BOF.
> A Content Delivery Network (CDN) is an infrastructure of network elements
> operating at layer 4 through layer 7, arranged for the efficient distribution
> and delivery of digital content. Such content includes, but is not limited to,
> web pages and images delivered via HTTP, and streaming of continuous media
> delivered via HTTP, RTSP, RTMP, etc. CDNs typically provide services to
> multiple Content Service Providers (CSPs).
> 
> CDNs provide numerous benefits: a shared platform for multi-service content
> delivery, reduced transmission costs for cacheable content, improved quality
> of experience for end users and increased robustness of delivery. For these
> reasons they are frequently used for large-scale content delivery.
> 
> As a result of the significant growth in content delivered over IP networks,
> existing CDN providers are scaling up their infrastructure and many Network
> Service Providers and Enterprise Service Providers are deploying their own
> CDNs. Subject to the policy of the CSP, it is generally desirable that a given
> item of content can be delivered to an end user regardless of that end user's
> location or attachment network. This creates a requirement for interconnecting
> (previously) standalone CDNs so they can interoperate and collectively behave
> as a single delivery infrastructure.
> 
> The goal of the CDNI (Content Delivery Network Interconnection) Working Group
> is to define the necessary set of protocols to allow the interconnection of
> separately administered CDNs in support of the end-to-end delivery of content
> from CSPs through multiple CDNs and ultimately to end users (via their
> respective User Agents).
> 
> - A "framework" document providing a description of the different components
> of the CDNI solution and how they interact with and relate to one another.
> 
> - A "requirements" document. This document lists the requirements for CDNI
> architecture and the protocols to support it. In particular, this document
> will focus on identifying a reasonable set of more urgent and important
> requirements that will be addressed in the initial set of CDNI protocols and
> solutions produced by the working group.
> 
> 	o CDNI request-routing systems. In particular, this protocol will allow
> an upstream CDN request routing system to query a downstream CDN request
> routing system at request routing time, in order to facilitate the redirection
> of the end user request by the upstream CDN towards the downstream CDN. In
> accordance with the requirements document, this protocol may also allow a
> downstream CDN to communicate information to an upstream CDN request routing
> system to facilitate its request redirection decisions.
> 
> 	o CDNI metadata distribution systems. This protocol will allow the CDNs
> to exchange distribution metadata of inter-CDN scope. Distribution metadata
> refers to the subset of content metadata that is relevant to the distribution
> of the content and therefore to CDNs (for example, this may include geo-
> blocking information, availability window or access control mechanisms to be
> enforced)
> 
> 	o CDNI logging systems, This protocol will allow CDN logging systems to
> exchange logging information associated with actions that are relevant across
> CDNs (such as content distribution, content delivery and content routing
> actions) for purposes of accounting, analytics, monitoring, etc.
> 
> 	o CDN control systems. In particular, this protocol will allow an
> upstream CDN to remove or invalidate content in a downstream CDN.
> 
> The working group will only define solutions for aspects of the CDN
> Interconnection problem space that require direct communication or
> interoperation between CDNs.
> 
> The WG will work with other WGs to assess, and where appropriate, extend
> protocols developed by those WGs, in order to realize the CDNI requirements
> and CDNI protocols. For example, the WG may assess the suitability of the ALTO
> protocol as a protocol to enable downstream CDNs to exchange information which
> may aid an upstream CDN with making CDNI request routing decisions.
> 
> 
> Goals & Milestones
> ==================
> 
> WG Creation + 24 months: 	Submit specification of the CDNI Metadata
> Distribution protocol to IESG as Proposed Standard
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 21 Mar 2011 18:02:45 +0100

Hello Kevin,

>  Should specification of a base set of metadata be part of the charter?

Yes, I would expect that the "CDNI Metadata Exchange Protocol" discussed in the draft charter below would define both such a set of distribution metadata and how to exchange it (e.g. define both a schema and methods to exchange information elements from that schema).

We tried cover that in the following text:
"
	o CDNI metadata distribution systems. This protocol will allow the CDNs to exchange distribution metadata of inter-CDN scope. Distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore to CDNs (for example, this may include geo-blocking information, availability window or access control mechanisms to be enforced)
"

Let us know if you have suggestions to enhance this text.

Thanks

Francois

>> Content Delivery Networks Interconnection (CDNI) - Draft Charter

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

Cisco Systems France, Société à responsabiité limitée, Rue Camille Desmoulins – Imm Atlantis Zac Forum Seine Ilot 7 92130 Issy les Moulineaux, Au capital de 91.470 €, 349 166 561 RCS Nanterre, Directeur de la publication: Jean-Luc Michel Givone.

For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 21 Mar 2011 17:52:07 -0400

Francois,

  I have been thinking about the protocol and metadata as being
  analogous to SNMP and MIBs, respectively.  I see a need for a
  standard set of base metadata, that CDNs should implement.  I
  also see the ability for vendors to define their own metadata
  for new features that they support.  I would think a metadata
  definition language, and a baseline set of metadata specified
  in that language, should also be in the goals and milestones?
  do we anticipate reusing an existing definition language?

  perhaps changing "set of protocols" to "set of protocols and metadata"
  in the following sentance:

    "The goal of the CDNI (Content Delivery Network Interconnection) Working Group is to define the necessary set of protocols and metadata to allow the interconnection of separately administered CDNs"

  adding a sentance like the following, after the sentance that starts
  with "For the above protocols,":

    "A baseline set of metadata, capable of supporting the the scenarios described in the "use case" document, will be defined."

  and possibly including one or two additional goals, e.g.:

    "WG Creation + 24 months:       Submit specification of the CDNI Metadata Definition Language to IESG as Proposed Standard
     WG Creation + 24 months:       Submit specification of the CDNI Base Metadata Definition to IESG as Proposed Standard"

thanx.

--  Kevin J. Ma

From: Francois Le Faucheur [mailto:[email-masked]]
Sent: Monday, March 21, 2011 1:03 PM
To: Kevin J Ma
Cc: Francois Le Faucheur; [email-masked]; Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Subject: Re: [CDNi] First cut at draft CDNI Charter

Hello Kevin,

Francois,

Thanks

Francois

thanx.

--  Kevin J. Ma

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of
Francois Le Faucheur
Sent: Sunday, March 13, 2011 2:03 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
Subject: [CDNi] First cut at draft CDNI Charter

Hi,

Cheers

Francois & Rich

PS: It can also be downloaded from the IETF BOK wiki :
http://trac.tools.ietf.org/bof/trac/attachment/wiki/WikiStart/Draft-CDNI-
Charter-v01.2.txt

- A "problem statement" document providing a description of the problem and a
common terminology.

- A "use case" document describing scenarios for usage and applications of the
CDNI solution and protocols

- A detailed specification of the protocols for the interconnection &
interoperation of:

For the above protocols, the working group will leverage existing protocols
where appropriate.

Goals & Milestones
==================

WG Creation + 6 months:    Submit CDNI problem statement to IESG as
Informational
WG Creation + 9 months:    Submit CDNI use cases to IESG as Informational
WG Creation + 12 months: Submit CDNI framework to IESG as Informational
WG Creation + 12 months: Submit CDNI requirements to IESG as
Informational
WG Creation + 18 months: Submit specification of the CDNI Request Routing
protocol to IESG as Proposed Standard
WG Creation + 18 months: Submit specification of the CDNI Logging
protocol to IESG as Proposed Standard
WG Creation + 18 months: Submit specification of the CDNI Control
protocol to IESG as proposed Standard
WG Creation + 24 months: Submit specification of the CDNI Metadata
Distribution protocol to IESG as Proposed Standard
WG Creation + 24 months: Recharter or dissolve
_______________________________________________
CDNi mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/cdni

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]<mailto:[email-masked]>
Phone: +33 49 723 2619
Mobile: +33 6 19 98 50 90

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com<http://www.cisco.com>

 Think before you print.

---

From: Mark Watson <[email-masked]>
Date: Tue, 22 Mar 2011 17:23:00 -0700

Francois, all,

I briefly reviewed the proposed charter and some of the IDs. Apologies if i get anything wring below due to the brevity of that review.

I have four comments:
(1) Behind the concept of "CDNI metadata" there is the concept that interconnected CDNs might be expected, or required, to actually act on that medatadata. For example to enforce geo-location restrictions or availability windows. So you are talking about CDNs supporting specific services and in the definition of the metadata you are effectively going to define those services. I think that should be surfaced as a top level concept. "Metadata" is often of a more informative in nature. "Exchange of metadata" sounds pretty straightforward. So it may not always be clear that there are services being defined. Along with that you need to decide how CDNs ensure the services they need from other CDNs will actually be or are actually being provided: is this business-layer contractual stuff or real-time negotiation ? Can geo-restricted content pass through a CDN which does not support geo-restriction, but can pass the metadata, provided the eventual delivering CDN does support it ? How would that work ? (Not saying these need to be answered now, but they need to be asked in the scope of the work)

(2) I may have got this wrong, but there seems to be an assumption in a lot of the "request routing" text that the "request" goes first to the "authoritative CDN" - which I assume is the one closest to the CSP. Is this necessarily the case ? If the "request" is the initial DNS query isn't it possible - maybe desirable - that it first goes to the nearest CDN, perhaps the one operated by my ISP. Shouldn't it be possible that the content is simply served directly from that closest CDN without interaction further upstream ? Isn't that the goal ?

(3) The problem statement already seems to assume a bunch of new "protocols" and whilst it talks about re-use of existing application protocols, I get the sense that "reuse of HTTP" means "define a new REST API with HTTP as transport", or something equivalent. It seems to me that many CDNI goals might be met with extensions to the existing protocols used for content delivery (DNS and HTTP - It's not clear to me that protocols other than these two should be a priority.) So it feels as if the problem statement already assumes quite a lot of the solution, specifically a lot of the general solution approach and system architecture.

So, for example, very superficially, it seems that many early CDNI goals might be met with careful interconnection of DNS systems, perhaps some domain name conventions and addition of CDNI metadata to HTTP responses (things like geo-restrictions and availability windows are like more advanced caching directives). Not to say this is the solution, but the problem statement should not rule it out.

(4) It might be worth comparing this with the Parc CCN work and related content-aware networking work - at least that model elegantly unifies networking and storage, embedding storage deep into a content-aware network for the very same purpose that people want to interconnect CDNs. CDNI is trying to do the same thing with existing networks, so there may be some learnings if not direct applicability.

...Mark

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 23 Mar 2011 12:16:41 +0100

Hello Mark,

Thanks for your comments. Please see below :

On 23 Mar 2011, at 01:23, Mark Watson wrote:

> (1) Behind the concept of "CDNI metadata" there is the concept that interconnected CDNs might be expected, or required, to actually act on that medatadata.
> For example to enforce geo-location restrictions or availability windows. So you are talking about CDNs supporting specific services and in the definition of the metadata you are effectively going to define those services.

Right.

> I think that should be surfaced as a top level concept. "Metadata" is often of a more informative in nature. "Exchange of metadata" sounds pretty straightforward. So it may not always be clear that there are services being defined.

We have attempted to make that clear by introducing several terms/definitions around metadata and in particular we defined the notion of "content distribution metadata" to single out the subset of all potential metadata that relates to "services" (as you call them) that CDNs need to provide.

In particular, in the Problem Statement I-D we have 
"
Content Distribution Metadata: The subset of Content Metadata that is
   relevant to the distribution of the content.  This is the metadata
   required by a CDN in order to enable and control content distribution
   and delivery by the CDN.  In a CDN Interconnection environment, some
   of the Content Distribution Metadata may have an intra-CDN scope (and
   therefore need not be communicated between CDNs), while some of the
   Content Distribution Metadata have an inter-CDN scope (and therefore
   needs to be communicated between CDNs).

   CDNI Metadata: Content Distribution Metadata with inter-CDN scope.
   For example, CDNI Metadata may include geo-blocking information (i.e.
   information defining geographical areas where the content is to be
   made available or blocked), availability windows (i.e. information
   defining time windows during which the content is to be made
   available or blocked) and access control mechanisms to be enforced
   (e.g.  URI signature validation).  CDNI Metadata may also include
   information about desired distribution policy (e.g. prepositioned vs
   dynamic acquisition) and about where/how a CDN can acquire the
   content.  CDNI Metadata may also include content management
   information (e.g. request for deletion of Content from Surrogates)
   across interconnected CDNs.
"

And in the draft charter we have:
"
	o CDNI metadata distribution systems. This protocol will allow the CDNs to exchange distribution metadata of inter-CDN scope. Distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore to CDNs (for example, this may include geo-blocking information, availability window or access control mechanisms to be enforced)
"

To make that even clearer perhaps:
	* in the Problem Statement I-D, we can replace "This is the metadata required by a CDN in order to enable and control content distribution and delivery by the CDN." by "This is the metadata required and to be processed by a CDN in order to enable and control content distribution and delivery by the CDN."
	* in the draft charter, we can replace "Distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore to CDNs" by "Distribution metadata refers to the subset of content metadata that is relevant to the distribution of the content and therefore to be processed by CDNs".

> Along with that you need to decide how CDNs ensure the services they need from other CDNs will actually be or are actually being provided: is this business-layer contractual stuff or real-time negotiation ?

We had some discussion about that on the list. I believe we converged on a model (at least initially) where it is business-layer stuff.

> Can geo-restricted content pass through a CDN which does not support geo-restriction, but can pass the metadata, provided the eventual delivering CDN does support it ? How would that work ? (Not saying these need to be answered now, but they need to be asked in the scope of the work)

Good question.

Personally, assuming that the WG decides to support cascaded CDNs in initial charter (which is an open question), then I would lean towards a simpler model (at least initially) where geo-restriction metadata only flows to another CDN if that CDN supports it. Just a personal opinion.

But in any case, I expect these sort of things would be covered in the "CDNI Framework I-D". I've added it to my checklist of things that need to be brought up in the Framework.

> 
> (2) I may have got this wrong, but there seems to be an assumption in a lot of the "request routing" text that the "request" goes first to the "authoritative CDN" - which I assume is the one closest to the CSP. Is this necessarily the case ? If the "request" is the initial DNS query isn't it possible - maybe desirable - that it first goes to the nearest CDN, perhaps the one operated by my ISP.

I agree that should be possible. One way to achieve that is where the authoritative name-server for a domain effectively delegates a subdomain to multiple name-servers (picking one dynamically based on location of the DNS query source eg ISP DNS Proxy). Because of DNS behavior (eg caching), the delegation has stickiness so that subsequent local requests would be resolved locally. But in my mind it is still more or less a model where logically the queries first go to the entity that is authoritative for the domain and that entity redirects to a local name-server (and then delegate authority for some time), only there is some protocol machinery (cache) that bypasses the actual query/redirect in subsequent requests. I can see that, alternatively, this could be looked at as a where we effectively have multiple (delegated) authoritative name-servers at the same time (and thus each local CDN is kind of the authoritative CDN).

The documents have tried address all forms of request-routing (HTTP, DNS, something else) in a generic ways. We'll have to be more specific (and more accurate) when we get to describe how a specific form of request-routing works. Again, probably the CDNI Framework would start addressing that. 

> Shouldn't it be possible that the content is simply served directly from that closest CDN without interaction further upstream ? Isn't that the goal ?

I would agree it may be a goal in some scenarios, but I wouldn't say it is _the_ goal. 
May be a good goal would be that the interactions upstream should be no more verbose than needed (in particular to achieve the desired redirection policy). Where the redirection policy is "query is to be always served by CDN of local ISP", then this may probably be achieved with very limited upstream signaling. Where the redirection policy is more complex (ie depends on CDN tariffs, inter-CDN agreements, content type, more accurate client location information than that of DNS proxy....) there may be a need for more upstream interactions.

I need to go so will come back to the remaining points later.

Thanks much

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 23 Mar 2011 15:23:19 +0100

Hi again,

Please see below:
On 23 Mar 2011, at 01:23, Mark Watson wrote:
> 
> (3) The problem statement already seems to assume a bunch of new "protocols"

Not really. In the problem statement, "protocol" is intended in the most generic sense: an agreed set of procedures & encodings across two parties. 
It may potentially be realized using an existing "IETF protocol" without extensions (but with some convention perhaps), using an existing "IETF protocol" with newly defined extensions, using an existing "IETF protocol" to transport some new schema,  or (theoretically, although that is not what we expect) using a completely new protocol.

But this does not come through clearly enough in the existing documents, and a few other people read it the same way as you. So I added a note based on the previous paragraph in the draft charter and I propose we do the same in the Problem Statement.

> and whilst it talks about re-use of existing application protocols, I get the sense that "reuse of HTTP" means "define a new REST API with HTTP as transport", or something equivalent.

Yes, definitely a candidate approach, but not the only one.

> It seems to me that many CDNI goals might be met with extensions to the existing protocols used for content delivery (DNS and HTTP - It's not clear to me that protocols other than these two should be a priority.

I believe there is agreement on that.
R31 and R32 of cdni-requirements imply this and it has been discussed on the list.

> ) So it feels as if the problem statement already assumes quite a lot of the solution, specifically a lot of the general solution approach and system architecture.

If you read the documents with the understanding that "protocol" is intended in a generic sense, you should see that it does not assume too much on the solution.

> So, for example, very superficially, it seems that many early CDNI goals might be met with careful interconnection of DNS systems, perhaps some domain name conventions and addition of CDNI metadata…

I agree it should not rule it out. 
My take is that it doesn't. In my mind this would just mean that the "CDNI metadata distribution protocol" happens to be realized using HTTP + a few extensions.
Now, as you say, I am not sure this is likely to be _the_ actual solution since it would probably not support some of the requirements put forward in cdni-requirements.

> 
> (4) It might be worth comparing this with the Parc CCN work and related content-aware networking work - at least that model elegantly unifies networking and storage, embedding storage deep into a content-aware network for the very same purpose that people want to interconnect CDNs. CDNI is trying to do the same thing with existing networks,

Right. We have a fairly modest and focused objective here (ie allow existing CDNs out there to work together, without requiring significant change of technology inside the CDNs)

> so there may be some learnings if not direct applicability.

Not clear there is direct applicability with our assumption of interconnecting CDN running existing technology, but quite possibly learnings. 

Thanks

Francois

Francois Le Faucheur
Distinguished Engineer
Corporate Development
[email-masked]
Phone: +33 49 723 2619

Cisco Systems France
Greenside
400 Ave de Roumanille
06410 Sophia Antipolis
France
Cisco.com

 Think before you print.