Subject: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 17 Oct 2011 12:07:40 +0100

Colleagues,

At the last IETF I said I would try to prepare a version of the CDNI problem Statement (draft-ietf-cdni-problem-statement) that is ready for WG Last Call before IETF82 in Taipei.

As part of that I have reviewed the complete draft and made some minor editorial clean-ups to my working copy. However, there were a number of other areas where I think changes need to be made to the document that I think warrant wider WG review/consensus and I have listed them below along with the changes I am proposing.

Could you please provide your feedback on the areas/proposed text I have highlighted below as well as any other areas of the document that you think require additional work/cleanup before you consider the document is ready for a WG Last Call.

1) Section 2: Update the last paragraph to reference the WG draft for CDNI use cases and remove reference to draft-watson-cdni-use-cases, i.e.

OLD:
   Use cases for CDN Interconnection are further discussed in
   [I-D.bertrand-cdni-use-cases] (which contains a merged set of use
   cases previously presented in [I-D.watson-cdni-use-cases] and
   [I-D.bertrand-cdni-use-cases-00]).
NEW:
   Use cases for CDN Interconnection are further discussed in
   [I-D.ietf-cdni-use-cases].

2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) that are each just a couple of sentences, so I propose merging them into a single section and changing the first two sentences of section 4 appropriately, i.e.

OLD:
   This section expands on how CDNI interfaces can reuse and leverage
   existing protocols.  First the "reuse instead of reinvent" design
   principle is restated, then each inetrface is discussed individually
   with example candidate protocols that can be considered for reuse or
   leverage. 
NEW:
   This section expands on how CDNI interfaces can reuse and leverage
   existing protocols before describing each CDNI interface individually
   and highlighting example candidate protocols that could considered for
   reuse or leveraging to implement the CDNI interfaces.  

3) Section 5 is currently title "Gap Analysis of relevant Standardisation and Research Activities" but following the agreement at the last IETF to move the generic descriptions of other activities into an appendix Section 5 no longer references any research activities so I propose changing the title to" Gap Analysis of relevant Standardisation activities".

4) After the general introduction in Section 5 there are only sections that outline other research activities for Content Acquisition (section 5.1) and CDNI Metadata (Section 5.2) but there are not sections for the other CDNI interfaces (Control, Logging, Request Routing).

The reason for the lack of text is IMO because there is no current or past standardisation activity addressing those areas but the document currently does not mention that and therefore gives the impression of being incomplete.

I therefore propose making the following change to the last sentence in Section 5:

OLD:
   The following sections will summarize the existing work of the
   standard bodies above against the CDNI problem space.
NEW:
   The following sections will summarize the existing work of the
   standard bodies above against the CDNI problem space. Section 5.1
   summarises existing interfaces that could be leveraged for content
   acquisition between CDNs and Section 5.2 summarises existing metadata 
   specifications that may be applicable to CDNI. To date there is no
   existing standardisation activities in the areas of the remaining
   CDNI interfaces (CDNI Request Routing, CDNI Control and CDNI Logging).

5) I also propose using the following text for the third bullet in Section 5 unless someone can suggest more appropriate text to summarise in a sentence or two any CDN metadata related work in other standards bodies.

OLD:
   o  <TODO: Add a sentence on ITU>
NEW:
   o  CableLabs, SNIA and ITU have defined (or are working on)
      definitions for content related metadata definitions and specification
      for its distribution. However, they do not include metadata specific
      to the distribution of content within a CDN or between interconnected
      CDNs.

6) Section 10.1 lists a number of "normative references", if we adopt the proposed changes above it will end up containing "normative" references to:
   - draft-ietf-cdni-use-cases
   - draft-bertrand-cdni-experiements
   - draft-jenkins-cdni-names
   - RFC2119

After reading through the text of the Problem Statement again, I am not convinced that the Problem Statement references any of those documents normatively as the 3 CDNI related drafts are referenced in a context where they are for further information and the Problem Statement does not make use of any of the capitalised terms defined in RFC2119.

Therefore, unless anyone objects I will move the references for the three CDNI related drafts to the "Informative References" section and remove the reference for RFC2119.

Thanks
Ben

---

From: "Will Li(jincheng)" <[email-masked]>
Date: Wed, 19 Oct 2011 09:24:08 +0000

Hi, Ben,

Thank you for the efforts. Two more comments.
1) In section 3, do you think it is helpful to add some description on each role (i.e. CP, Upstream CDN, Downstream CDN), and their business relationships assumed in CDNI?
  This could facilitate people to understand the figure and the draft better.
2)Another editorial one: In bullet 5 of your previous mail, changing ITU to ITU-T could be more specific.

BR, Will 

-----邮件原件-----
发件人: [email-masked] [mailto:[email-masked]] 代表 Ben Niven-Jenkins
发送时间: 2011年10月17日 19:08
收件人: [email-masked]
主题: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call

Colleagues,

OLD:

OLD:

OLD:

OLD:

Thanks
Ben

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 24 Oct 2011 15:35:24 +0100

Will,

Thanks for reviewing the draft & proposed changes, my opinion is inline below.

>  This could facilitate people to understand the figure and the draft better.

The different roles are defined as part of the terminology in Section 1.1.

I don't think the Problem Statement draft should try to describe the different business relationships as they are many and varied depending on things like the purpose of the specific CDN, the market it is deployed in etc and it would be very difficult to describe all the different business relationships and we would risk getting distracted by comments along the lines of "what about this business relationship that you haven't described" and "you haven't adequately captured how this relationship could work" etc.

Section 1.2 already states that "Readers are assumed to be familiar with the architecture, features and operation of CDNs." and I assume if readers already have that familiarity with how CDNs work & are operated then they can understand how CSPs, upstream CDNs, downstream CDNs may fit together as part of the CDNI reference model.
 
> 2)Another editorial one: In bullet 5 of your previous mail, changing ITU to ITU-T could be more specific.

Good catch! I will use ITU-T when I update the draft.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 24 Oct 2011 15:41:24 +0100

Colleagues,

The deadline for submitting Internet-Drafts prior to IETF82 is only a week away and I would like to have a new version of the CDNI Problem Statement published in time for discussion during IETF82.

So far I've only seen comments from Will Li. If you have any comments or opinions on the changes/updates I propose below please can you send them this week (but the sooner the better).

In the absence of any further comments I will assume that no one objects to the proposals and update the Problem Statement and publish the updated version before the deadline on Monday.

Thanks
Ben

---

From: "Will Li(jincheng)" <[email-masked]>
Date: Thu, 27 Oct 2011 02:34:44 +0000

Hi, Ben,

Thanks for the response, further thought in line.

> -----Original Message-----
> From: Ben Niven-Jenkins [mailto:[email-masked]]
> Sent: Monday, October 24, 2011 10:35 PM
> To: Will Li(jincheng)
> Cc: [email-masked]
> Subject: Re: 答复: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG
> Last Call
> 
> Will,
> 
> > 1) In section 3, do you think it is helpful to add some description on each role
> (i.e. CP, Upstream CDN, Downstream CDN), and their business relationships
> assumed in CDNI?

I see. Thanks.

> 
> I don't think the Problem Statement draft should try to describe the different
> business relationships as they are many and varied depending on things like the
> purpose of the specific CDN, the market it is deployed in etc and it would be very
> difficult to describe all the different business relationships and we would risk
> getting distracted by comments along the lines of "what about this business
> relationship that you haven't described" and "you haven't adequately captured
> how this relationship could work" etc.
> 
> Section 1.2 already states that "Readers are assumed to be familiar with the
> architecture, features and operation of CDNs." and I assume if readers already
> have that familiarity with how CDNs work & are operated then they can
> understand how CSPs, upstream CDNs, downstream CDNs may fit together as
> part of the CDNI reference model.
> 
Agree inappropriate description may lead confusion. However, I am thinking of some general but safe descriptions on the relationship of these roles, like 
"In a typical content delivery service, A CSP contracts with an upstream CDN to store and deliver content to User Agents; the upstream CDN further contracts with one or more downstream CDN(s) to distribute and deliver contents on uCDN’s behalf. However, these business relationships are out of scope of CDNI.", if this kind of description is safe to be added below the figure, then it can ease people to understand the following staff in this draft.

> > At the last IETF I said I would try to prepare a version of the CDNI problem
> Statement (draft-ietf-cdni-problem-statement) that is ready for WG Last Call
> before IETF82 in Taipei.
> >
> > As part of that I have reviewed the complete draft and made some minor
> editorial clean-ups to my working copy. However, there were a number of other
> areas where I think changes need to be made to the document that I think
> warrant wider WG review/consensus and I have listed them below along with
> the changes I am proposing.
> >
> > Could you please provide your feedback on the areas/proposed text I have
> highlighted below as well as any other areas of the document that you think
> require additional work/cleanup before you consider the document is ready for a
> WG Last Call.
> >
> > 1) Section 2: Update the last paragraph to reference the WG draft for CDNI use
> cases and remove reference to draft-watson-cdni-use-cases, i.e.
> >
> > OLD:
> > 2) Section 4 contains an introduction and 2 sub-sections (4.1 & 4.2) that are each
> just a couple of sentences, so I propose merging them into a single section and
> changing the first two sentences of section 4 appropriately, i.e.
> >
> > OLD:
> > 3) Section 5 is currently title "Gap Analysis of relevant Standardisation and
> Research Activities" but following the agreement at the last IETF to move the
> generic descriptions of other activities into an appendix Section 5 no longer
> references any research activities so I propose changing the title to" Gap Analysis
> of relevant Standardisation activities".
> >
> > 4) After the general introduction in Section 5 there are only sections that
> outline other research activities for Content Acquisition (section 5.1) and CDNI
> Metadata (Section 5.2) but there are not sections for the other CDNI interfaces
> (Control, Logging, Request Routing).
> >
> > The reason for the lack of text is IMO because there is no current or past
> standardisation activity addressing those areas but the document currently does
> not mention that and therefore gives the impression of being incomplete.
> >
> > 5) I also propose using the following text for the third bullet in Section 5 unless
> someone can suggest more appropriate text to summarise in a sentence or two
> any CDN metadata related work in other standards bodies.
> >
> > OLD:
> > 6) Section 10.1 lists a number of "normative references", if we adopt the
> proposed changes above it will end up containing "normative" references to:
> > After reading through the text of the Problem Statement again, I am not
> convinced that the Problem Statement references any of those documents
> normatively as the 3 CDNI related drafts are referenced in a context where they
> are for further information and the Problem Statement does not make use of
> any of the capitalised terms defined in RFC2119.
> >
> > Therefore, unless anyone objects I will move the references for the three CDNI
> related drafts to the "Informative References" section and remove the reference
> for RFC2119.
> >
> >
> > Thanks
> > Ben
> >

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 27 Oct 2011 11:59:14 +0100

Will,

> "In a typical content delivery service, A CSP contracts with an upstream CDN to store and deliver content to User Agents; the upstream CDN further contracts with one or more downstream CDN(s) to di…

I took another look at the draft and my proposal is to add a couple of sentences to the bottom of the first paragraph of the Introduction (Section 1) as follows:

OLD:
   This creates a requirement for interconnecting standalone
   CDNs so that their collective CDN footprint can be leveraged for the
   end-to-end delivery of content from Content Service Providers (CSPs)
   to End Users.  However, no standards or open specifications currently
   exist to facilitate such CDN interconnection.
NEW:
   This creates a requirement for interconnecting standalone
   CDNs so that their collective CDN footprint can be leveraged for the
   end-to-end delivery of content from Content Service Providers (CSPs)
   to End Users.  However, no standards or open specifications currently
   exist to facilitate such CDN interconnection. For example, a CSP could
   contract with an "authoritative" CDN for the delivery content and that CDN
   could contract with one or more downstream CDN(s) to distribute and
   deliver some or all of the content on behalf of the authoritative CDN.
   The formation and details of any business relationships between a CSP and 
   a CDN and between one CDN and another CDN are out of scope of this 
   document.

Ben

---

From: "Will Li(jincheng)" <[email-masked]>
Date: Fri, 28 Oct 2011 06:11:48 +0000

Hi, Ben,

Fine to me. Thanks.

> Sent: Thursday, October 27, 2011 6:59 PM
> To: Will Li(jincheng)
> Cc: [email-masked]
> > Agree inappropriate description may lead confusion. However, I am thinking of
> some general but safe descriptions on the relationship of these roles, like
> > "In a typical content delivery service, A CSP contracts with an upstream CDN to
> store and deliver content to User Agents; the upstream CDN further contracts
> with one or more downstream CDN(s) to distribute and deliver contents on
> uCDN’s behalf. However, these business relationships are out of scope of CDNI.",
> if this kind of description is safe to be added below the figure, then it can ease
> people to understand the following staff in this draft.
> 
> I took another look at the draft and my proposal is to add a couple of sentences
> to the bottom of the first paragraph of the Introduction (Section 1) as follows:
> 
> 
> OLD:

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 28 Oct 2011 01:52:50 +0200

> I took another look at the draft and my proposal is to add a couple of sentences to the bottom of the first paragraph of the Introduction (Section 1) as follows:

Works for me.

>   exist to facilitate such CDN interconnection. For example, a CSP could

The "for example" does not flow very well (it suggests this is an example of why no standards exist - aka the previous sentence).
So I'd suggest:
s/For example/As an example of scenario involving interconnection of CDNs/

>   contract with an "authoritative" CDN for the delivery content

s/delivery content/delivery of content/

> and that CDN

The same CDN is referred in the same sentence as "that CDN" and the "authoritative CDN". Might be better to always refer to it the same way:
s/that CDN/that authoritative CDN/

Francois

>   a CDN and between one CDN and another CDN are out of scope of this 

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: Francois Le Faucheur <[email-masked]>
Date: Fri, 28 Oct 2011 03:02:57 +0200

Ben and all,

(As an individual)

A few additional comments on problem-statement:

1) Appendix "A.2.  Prioritizing the CDNI Work"
I would propose that we remove that appendix altogether because:
	* the terms introduced there of "Base/Operationalized/Enhanced CDNI" do not correspond to anything really meaningful anymore for the WG now that it has been establish (ie there is "in scope" and "out of scope")
	* the requirements document is defining a specific notion of priority with High/Medium/Low priority.

2) In last paragraph of section 1 (just before section 1.1), the references to the Appendices are incorrect (ie "Appendix A.2" shows up 3 times).

3) section 3:
OLD:
The CDNI model and problem area proposed for IETF work
NEW:
The CDNI model and problem area defined for the IETF work

4) section 3:
OLD:
The CDNI model and problem area proposed
   for IETF work is illustrated in Figure 1.  The candidate problem area
   (and respectively the non-goals) for IETF work on CDN Interconnection
   are discussed in Section 3.1 (and respectively Appendix A.1 ).
NEW:
This section discusses the problem area for IETF work on CDN Interconnection. The CDNI model and problem area defined for IETF work is illustrated in Figure 1. 

5) section 3.1:
I would propose to remove this sentence :
"
 [I-D.jenkins-cdni-names] presents one
   view on how CDN data types/objects could be classified such that the
   problem space of their naming and referencing is not as large as it
   might at first appear because there is significant commonality
   between the different data types/objects required for CDNI.
"
I feel that the referenced document has served its purpose in providing some thoughts on metadata but its detailed content has received little review/comments and is being revisited as part of the work on the metadata interface.

6) section 4.3, 4.4 and 4.5 (multiple occurrences)
OLD:
a CDNI WG
NEW:
the CDNI WG

7) section 4.3.
As discussed in 3.1, the Request Routing interface is likely to cover two capabilities:
*  allow the upstream CDN to query the downstream CDN at request-
         routing time before redirecting the request to the downstream
         CDN
*  allow the downstream CDN to provide to the upstream CDN (static
         or dynamic) information (e.g. resources, footprint, load) to
         facilitate selection of the downstream CDN by the upstream CDN
         request routing system when processing subsequent content
         requests from User Agents.
However, section 4.3 only currently discusses candidate protocols for the first capability. So I would propose we add something along the lines of:
"As discussed in section 3.1, the CDNI Request Routing interface is also expected to enable a downstream CDN to provide to the upstream CDN (static or dynamic) information (e.g. resources, footprint, load) to facilitate selection of the downstream CDN by the upstream CDN request routing system when processing subsequent content requests from User Agents. It is expected that such functionality of the CDNI request Routing could be specified by the CDNI WG with significant leveraging of existing IETF protocols supporting the dynamic distribution of reachability information (such as BGP) or supporting queries by application element for topological information (such as ALTO).

Cheers

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: Fri, 28 Oct 2011 11:27:41 +0200

HI Ben,

Comments below:

>   [I-D.ietf-cdni-use-cases].

Agreed.

>   reuse or leveraging to implement the CDNI interfaces.  

Fine by me.

> 3) Section 5 is currently title "Gap Analysis of relevant Standardisation and Research Activities" but following the agreement at the last IETF to move the generic descriptions of other activities…

Agreed.

> 
> 4) After the general introduction in Section 5 there are only sections that outline other research activities

I think you mean "standardization activities"

> for Content Acquisition (section 5.1) and CDNI Metadata (Section 5.2) but there are not sections for the other CDNI interfaces (Control, Logging, Request Routing).
> 

Fine.

Just a couple editorial suggestions:

s/of the standard bodies above/of the standard bodies listed earlier/

s/there is no existing standardisation activities/we are not aware of any standardisation activities/

>      to the distribution of content within a CDN or between interconnected

That works for me. It would be good to get that validated by someone aware of the work of these bodies.

> Therefore, unless anyone objects I will move the references for the three CDNI related drafts to the "Informative References" section and remove the reference for RFC2119.

I agree we don't want normative ref to the other cdni drafts as the problem statement is setting the stage for the other documents.

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.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 28 Oct 2011 16:49:53 +0000

>   o  CableLabs, SNIA and ITU have defined (or are working on) definitions for content related metadata definitions and specification for its distribution.

Are we referring to these CableLabs specifications?

http://www.cablelabs.com/specifications/MD-SP-CONTENTv3.0-I01-100812.pdf
http://www.cablelabs.com/projects/metadata/specifications/specifications30.html

Do we have references for the SNIA and ITU specs as well?

-- Rich

From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur
Sent: Friday, October 28, 2011 5:28 AM
To: Ben Niven-Jenkins
Cc: [email-masked]
Subject: Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WG Last Call

HI Ben,

Comments below:

Colleagues,

OLD:

Agreed.

OLD:

Fine by me.

Agreed.

OLD:

Fine.

OLD:

Thanks

Francois

Thanks
Ben

_______________________________________________
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: <[email-masked]>
Date: Mon, 31 Oct 2011 11:32:51 +0100

Hi

For CDMI I use the ref http://snia.org/sites/default/files/CDMI_SNIA_Architecture_v1.0.pdf (even if the link is broken in http://tools.ietf.org/id/draft-stephan-cdni-usecases-metadata-00.txt )

Regards

Emile

De : [email-masked] [mailto:[email-masked]] De la part de Woundy, Richard
Envoyé : vendredi 28 octobre 2011 18:50
À : Francois Le Faucheur; Ben Niven-Jenkins
Cc : [email-masked]
Objet : Re: [CDNi] Preparing draft-ietf-cdni-problem-statement for WGLast Call

-- Rich

HI Ben,

Comments below:

Colleagues,

OLD:

Agreed.

OLD:

Fine by me.

Agreed.

OLD:

Fine.

OLD:

Thanks

Francois

Thanks
Ben

 

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: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 31 Oct 2011 11:45:56 +0000

Francois,

> s/For example/As an example of scenario involving interconnection of CDNs/

I've just rearranged the ordering slightly so the "however, no standards..." comes after the example.

The paragraph nows reads:
   This creates a requirement for interconnecting standalone
   CDNs so that their collective CDN footprint can be leveraged for the
   end-to-end delivery of content from Content Service Providers (CSPs)
   to End Users.  For example, a CSP could contract with an
   "authoritative" CDN for the delivery of content and that
   authoritative CDN could contract with one or more downstream CDN(s)
   to distribute and deliver some or all of the content on behalf of the
   authoritative CDN.  The formation and details of any business
   relationships between a CSP and a CDN and between one CDN and another
   CDN are out of scope of this document.  However, no standards or open
   specifications currently exist to facilitate such CDN
   interconnection.

If you still prefer s/For example/As an example/ I can pick that up in the next revision?

> s/delivery content/delivery of content/

Done.

> s/that CDN/that authoritative CDN/

Done.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 31 Oct 2011 12:08:53 +0000

Done.

> 2) In last paragraph of section 1 (just before section 1.1), the references to the Appendices are incorrect (ie "Appendix A.2" shows up 3 times).

I've reworded the last paragraph so it doesn't refer to the appendices (as they're supposed to be removed by the RFC Editor prior to publication anyway)  and so it summarises the content of the sections in the main document body.

The paragraph now reads:
   The goal of this document is to outline the problem area of CDN
   interconnection (CDNI) for the IETF.  Section 2 discusses the use
   cases for CDN interconnection.  Section 3 presents the CDNI model and
   problem area being considered by the IETF.  Section 4 describes each
   CDNI interface individually and highlights example candidate
   protocols that could considered for reuse or leveraging to implement
   the CDNI interfaces.  Section 5 provides a gap analysis against the
   work of other standards organizations.  Section 6 describes the
   relationships between the CDNI problem space and other relevant IETF
   Working Groups.

Done.

Done. 

Done.

> 6) section 4.3, 4.4 and 4.5 (multiple occurrences)

Done throughout the document.

> "As discussed in section 3.1, the CDNI Request Routing interface is also expected to enable a downstream CDN to provide to the upstream CDN (static or dynamic) information (e.g. resources, footprin…

Done but I tweaked the wording slightly, the final words I went with are:

   Additionally, as discussed in Section 3, the CDNI Request Routing
   interface is also expected to enable a downstream CDN to provide to
   the upstream CDN (static or dynamic) information (e.g. resources,
   footprint, load) to facilitate selection of the downstream CDN by the
   upstream CDN request routing system when processing subsequent
   content requests from User Agents.  It is expected that such
   functionality of the CDNI request Routing could be specified by the
   CDNI WG with significant leveraging of existing IETF protocols
   supporting the dynamic distribution of reachability information (for
   example by leveraging existing routing protocols) or supporting
   application level queries for topological information (for example
   by leveraging ALTO).

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 31 Oct 2011 12:12:14 +0000

Francois,

Done.

Done.

> That works for me. It would be good to get that validated by someone aware of the work of these bodies.

Sure, if someone can volunteer to do that or can suggest someone who may be able to to that validation I'm happy to adjust the text according to any suggestions they make.

Ben

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 31 Oct 2011 13:04:54 +0000

> http://www.cablelabs.com/projects/metadata/specifications/specifications30.html

I believe so, the reference we have currently have for CableLabs is this URI

http://www.cablelabs.com/projects/metadata/primer/

which provides some background and has a link to the actual CableLabs metadata specifications.

> Do we have references for the SNIA and ITU specs as well?

The current reference we have for SNIA is this URI:

http://www.snia.org/tech_activities/standards/curr_standards/cdmi

which has links to the CDMI v1.0 and CDMI v1.0.1 specifications.

I'm not sure what the right ITU reference is for metadata but if someone can suggest one I will include it.

Ben