Subject: Re: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-01.txt

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 9 Jan 2012 15:48:44 +0100

Hi Gilles and co-authors,

Thanks for this version incorporating earlier comments.
Below are a few small additional comments/suggestions (as an Individual) on the recent changes.

Francois

PS: For others who want to review the Diff against the previous version, I suggest you use:
https://tools.ietf.org/rfcdiff?url1=draft-ietf-cdni-use-cases-00&difftype=--html&submit=Go%21&url2=draft-ietf-cdni-use-cases-01

*** section 2:
"Footprint extension is expected to be the major use case for CDN Interconnection."
You replaced "a major use case" by "the major use case" . This might imply that other use cases are only "marginally" useful. 
We have been careful to only include in this document use cases that are believed to be needed and deployable in a relatively short term future. This is the key thing. Beyond that, i don't see much value in trying to be too specific about which is "the" prominent use case.
So I'd suggest to:
	* simply remove that sentence (or revert to "a major use case"),
	* and possibly expend, at the beginning of section 2, on the short-term applicability/need of the use cases listed in this document. Possibly by doing the following change:
OLD:
"
This document outlines real world use cases (not technical solutions) for interconnecting CDNs. It can be used to provide guidance
"
NEW:
"
This document outlines real world use cases (not technical solutions) for interconnecting CDNs. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once a standard CDNI solution is available. This document can be used to provide guidance
"

*** Section 2.3:
"Mastering Incoming Traffic"
The title was not immediately clear to me. How about "ISP Handling of third-party content"?

*** section 3.2.1:
"In partial failure scenarios, a CDN Provider has at least two options: (1) depending on traffic management policies, forward some requests to the CSP’s origin servers, and (2) redirect some requests toward another CDN, which must be able to serve the redirected requests."
This text implies that some of this is relevant to CDNI but does not make that explicit. I suggest you do. For example by adding something like "This second option is a use case for CDNI."

*** section 5.1:
"
o the geographic regions from where content can be delivered (i.e., the location of the Surrogates), or
o geographic locations to which content can be delivered (i.e., the location of the End Users).
"
I suggest you swap the order of these two bullet points, since the 2nd one seems like the most obvious/common of the two.

*** section 5.1:
"5.1.  Content Availability" 
To me, "availability" refers more to whether the content is available inside the CDN and is ready to be delivered to users that are allowed to access it. While, this section obviously discusses content delivery policies related to controlling which users can actually access that content, so I'd suggest changing the title, perhaps to something like "Content Delivery Restrictions" (I was going to suggest a slightly more generic title for 5.1 , but since the secure access control is discussed in a separate section 5.3, we need a term that matches the content of 5.1).

*** section 5.3:
I suggest reordering current section 5.3 before current section 5.2. This is because current section 5.3 is very related to current section 5.1, while current section 5.2 is of a different nature.

*** current section 5.3:
"
CSPs may often wish to dictate a specific protocol or set of protocols which are acceptable for delivery of their content, especially in the case where content protection or user authentication is required  (e.g., must use HTTPS, or must use URL hashing, etc.).
"
I think it is worth also explicitly describing the related, but slightly different, approach requested by CSPs whereby the CSP performs the per-request authentication/authorization decision themselves, and then leave it to the CDNs to enforce that decision (for example via validation of a signature included by the CSP).
So how about:
OLD:
"  
CSPs may often wish to dictate a specific protocol or set of protocols which are acceptable for delivery of their content, especially in the case where content protection or user authentication is required  (e.g., must use HTTPS, or must use URL hashing, etc.).
"
NEW:
"
CSPs may often wish to dictate a specific protocol or set of protocols which are acceptable for delivery of their content, especially in the case where content protection or user authentication is required  (e.g., must use HTTPS). CSPs may also wish to perform per-request authentication/authorization decision and then have the CDNs enforce that decision (e.g., must validate URL signing, etc.).
"

*** current section 5.3:
"The CSP may wish to blacklist specific dCDNs which lack support for these secure access features."
The CSP may want to be assured that the requested access features are applied and therefore that dCDNs that lack support for these secure access features are not used. However, I am not sure that this is to be achieved by the CSP actively blacklisting some dCDNs, rather the CSP could simply state that these access features as mandatory and then leave it up to the Authoritative CDN to exclude whichever potential dCDN that is not capable of meeting this requirement. 
So how about replacing with:
"An uCDN needs to be able to exclude dCDNs which lack support for the secure access features requested by the CSP."

There has been some discussion about the specific requirement to communicate list of blacklisted CDNs (which is a separate/broader question to the "Secure Access" topic). It might be best to progress/settle that discussion as part of the work on the requirements document. 

* current section 5.2:
OLD:
"
CSPs may desire to offer content services under their own name, even when the associated CDN service involves other CDN Providers. 
"
NEW:
"
CSPs may desire to ensure that content is delivered with URIs appearing to the endusers under their own domain name, even when the content delivery involves separate CDN Providers.
"

* current section 5.2 (possibly in other parts of the document also):
As discussed in the context of the problem-statement, "CDN Providers" may need replacement by something like "CDSP". Please align with next rev of problem-statement.

On 21 Dec 2011, at 11:34, <[email-masked]> <[email-masked]> wrote:

> Dear all,
> 
> We have posted a new revision of the use-cases draft, which incorporates the feedback received on the list and during IETF#82 meeting.
> 
> You can get a diff from the last version, using the following URL:
> http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-cases-00.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-01.txt 
> 
> Best regards,
> 
> Gilles
> 
> 
> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part de [email-masked]
> Envoyé : mercredi 21 décembre 2011 11:26
> À : [email-masked]
> Cc : [email-masked]
> Objet : [CDNi] I-D Action: draft-ietf-cdni-use-cases-01.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.
> 
> 	Title           : Use Cases for Content Delivery Network Interconnection
> 	Author(s)       : Gilles Bertrand
>                          Stephan Emile
>                          Grant Watson
>                          Trevor Burbridge
>                          Philip Eardley
>                          Kevin Ma
> 	Filename        : draft-ietf-cdni-use-cases-01.txt
> 	Pages           : 18
> 	Date            : 2011-12-21
> 
>   Content Delivery Networks (CDNs) are commonly used for improving the
>   End User experience of a content delivery service, at a reasonable
>   cost.  This document outlines real world use cases (not technical
>   solutions) for interconnecting CDNs.  It can be used to provide
>   guidance to the CDNI WG about the interconnection arrangements to be
>   supported and to validate the requirements of the various CDNI
>   interfaces.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-01.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-01.txt
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 9 Jan 2012 15:59:02 +0100

Folks,

Please review the version 01 that Gilles posted and pass on any comment soon. As agreed in Taipei, we'd like to work towards Working Group last call soon.

Cheers

Francois & Rich

PS: For memory, quotes from IETF 82 CDNI Minutes:
"
Francois: When the new version comes out, please review it and comment. Then the chairs will poll the list about issuing the WG Last Call on that new version (without waiting for next physical meeting of IETF).
"

> ftp://ftp.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-01.txt

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: <[email-masked]>
Date: Wed, 18 Jan 2012 16:19:53 +0100

Hi François and all,

I have uploaded a new version including all your suggestions:
http://www.ietf.org/internet-drafts/draft-ietf-cdni-use-cases-02.txt 

Differences with previous versions:
http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt 

Best regards,

Gilles

-----Message d'origine-----
De : Francois Le Faucheur [mailto:[email-masked]] 
Envoyé : lundi 9 janvier 2012 15:49
À : BERTRAND Gilles RD-CORE-ISS
Cc : [email-masked]
Objet : Re: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-01.txt

Francois

*** section 2:
"Footprint extension is expected to be the major use case for CDN Interconnection."
You replaced "a major use case" by "the major use case" . This might imply that other use cases are only "marginally" useful. 
We have been careful to only include in this document use cases that are believed to be needed and deployable in a relatively short term future. This is the key thing. Beyond that, i don't see much value in trying to be too specific about which is "the" prominent use case.
So I'd suggest to:
	* simply remove that sentence (or revert to "a major use case"),
	* and possibly expend, at the beginning of section 2, on the short-term applicability/need of the use cases listed in this document. Possibly by doing the following change:
OLD:
"
This document outlines real world use cases (not technical solutions) for interconnecting CDNs. It can be used to provide guidance "
NEW:
"
This document outlines real world use cases (not technical solutions) for interconnecting CDNs. This document focuses on use cases that correspond to identified industry needs and that are expected to be realized once a standard CDNI solution is available. This document can be used to provide guidance "

*** Section 2.3:

*** section 3.2.1:
"In partial failure scenarios, a CDN Provider has at least two options: (1) depending on traffic management policies, forward some requests to the CSP's origin servers, and (2) redirect some requests toward another CDN, which must be able to serve the redirected requests."
This text implies that some of this is relevant to CDNI but does not make that explicit. I suggest you do. For example by adding something like "This second option is a use case for CDNI."

*** section 5.1:
"
o the geographic regions from where content can be delivered (i.e., the location of the Surrogates), or o geographic locations to which content can be delivered (i.e., the location of the End Users).
"
I suggest you swap the order of these two bullet points, since the 2nd one seems like the most obvious/common of the two.

*** section 5.1:

*** section 5.3:

*** current section 5.3:
"

*** current section 5.3:

* current section 5.2:
OLD:
"

On 21 Dec 2011, at 11:34, <[email-masked]> <[email-masked]> wrote:

> http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-
> cdni-use-cases-00.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-
> cases-01.txt
> 
> Best regards,
> 
> Gilles
> 
> 
> De : [email-masked] [mailto:[email-masked]] De la part 
> de [email-masked] Envoyé : mercredi 21 décembre 2011 11:26 À 
> : [email-masked] Cc : [email-masked] Objet : [CDNi] I-D Action: 
> draft-ietf-cdni-use-cases-01.txt
> 
>

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 20 Jan 2012 13:15:29 +0100

All,

We need your input:

As per our agreement in Taipei, assuming it is ready for it, we'd like to move the use-case document through WG Last Call without unnecessarily waiting for the March 2012 meeting.

So, can you please let us know if :
	(A) you feel draft-ietf-cdni-use-cases-02.txt is ready to go through WG Last Call
	(B) you feel draft-ietf-cdni-use-cases-02.txt is NOT ready to go through WG Last Call (and ideally why)

Diff against 01:
	http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt

Diff against 00:
	http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt

Francois & Rich

---

From: Francois Le Faucheur <[email-masked]>
Date: Fri, 20 Jan 2012 13:19:07 +0100

As an individual:  (A)

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: <[email-masked]>
Date: Mon, 23 Jan 2012 11:51:22 +0100

(A)

Gilles

De : [email-masked] [mailto:[email-masked]] De la part de Francois Le Faucheur
Envoyé : vendredi 20 janvier 2012 13:19
À : [email-masked]
Objet : Re: [CDNi] Is draft-ietf-cdni-use-cases-02.txt ready to WG LastCall?

As an individual:  (A)

Francois

All,

We need your input:

Diff against 01:
            http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt <http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt> 

Diff against 00:
            http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt <http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt> 

Francois & Rich

Hi François and all,

	http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt <http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt>  

	Best regards,

	Gilles

	-----Message d'origine-----

	Cc : [email-masked]

	Francois

	 

	*** section 2:

	So I'd suggest to:

	OLD:

	"

	NEW:

	"

	 

	*** Section 2.3:

	 

	*** section 3.2.1:

	 

	*** section 5.1:

	"

	"

	 

	*** section 5.1:

	 

	*** section 5.3:

	 

	*** current section 5.3:

	"

	"

	So how about:

	OLD:

	"  

	"

	NEW:

	"

	"

	*** current section 5.3:

	 

	* current section 5.2:

	OLD:

	"

	"

	NEW:

	"

	"

	 

		Dear all,

		http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf- <http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf-> 

		cases-01.txt

		Best regards,

		Gilles

		-----Message d'origine-----

		 

		                       Stephan Emile

		                       Grant Watson

		                       Trevor Burbridge

		                       Philip Eardley

		                       Kevin Ma

		           Pages           : 18

		           Date            : 2011-12-21

		interfaces.

		CDNi mailing list

		[email-masked]

		CDNi mailing list

		[email-masked]

 

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: "Brandenburg, R. (Ray) van" <[email-masked]>
Date: Mon, 23 Jan 2012 11:35:42 +0000

(A)

Ray van Brandenburg

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: maandag 23 januari 2012 11:51
To: [email-masked]
Subject: Re: [CDNi] Is draft-ietf-cdni-use-cases-02.txt ready to WG LastCall?

(A)

Gilles

De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> De la part de Francois Le Faucheur
Envoyé : vendredi 20 janvier 2012 13:19
À : [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] Is draft-ietf-cdni-use-cases-02.txt ready to WG LastCall?

As an individual:  (A)

Francois

All,

We need your input:

Diff against 01:
            http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt<http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt>

Diff against 00:
            http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt<http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt>

Francois & Rich

On 18 Jan 2012, at 16:19, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi François and all,

Differences with previous versions:
http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt<http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt>

Best regards,

Gilles

-----Message d'origine-----
De : Francois Le Faucheur [mailto:[email-masked]]
Envoyé : lundi 9 janvier 2012 15:49
À : BERTRAND Gilles RD-CORE-ISS
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-01.txt

Francois

*** section 2:

*** Section 2.3:

*** section 3.2.1:

*** section 5.1:
"

*** section 5.1:

*** section 5.3:

*** current section 5.3:
"

*** current section 5.3:

* current section 5.2:
OLD:
"

On 21 Dec 2011, at 11:34, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Dear all,

You can get a diff from the last version, using the following URL:
http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-<http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf->
cdni-use-cases-00.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-
cases-01.txt

Best regards,

Gilles

-----Message d'origine-----
De : [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] De la part
de [email-masked]<mailto:[email-masked]> Envoyé : mercredi 21 décembre 2011 11:26 À
: [email-masked]<mailto:[email-masked]> Cc : [email-masked]<mailto:[email-masked]> Objet : [CDNi] I-D Action:
draft-ietf-cdni-use-cases-01.txt

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

_______________________________________________
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.

This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer

---

From: <[email-masked]>
Date: Mon, 23 Jan 2012 12:40:17 +0000

(A)
g-

From: [email-masked] [mailto:[email-masked]] On Behalf Of Brandenburg, R. (Ray) van
Sent: 23 January 2012 11:36
To: [email-masked]
Subject: Re: [CDNi] Is draft-ietf-cdni-use-cases-02.txt ready to WG LastCall?

(A)

Ray van Brandenburg

(A)

Gilles

As an individual:  (A)

Francois

All,

We need your input:

Diff against 01:

Diff against 00:

Francois & Rich

Best regards,

Gilles

-----Message d'origine-----
De : Francois Le Faucheur [mailto:[email-masked]]
Envoyé : lundi 9 janvier 2012 15:49
À : BERTRAND Gilles RD-CORE-ISS
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-01.txt

Francois

*** section 2:

*** Section 2.3:

*** section 3.2.1:

*** section 5.1:
"

*** section 5.1:

*** section 5.3:

*** current section 5.3:
"

*** current section 5.3:

* current section 5.2:
OLD:
"

Dear all,

Best regards,

Gilles

-----Message d'origine-----

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

---

From: Kevin J Ma <[email-masked]>
Date: Mon, 23 Jan 2012 11:46:42 -0500

(A)

--  Kevin J. Ma

From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Monday, January 23, 2012 7:40 AM
To: [email-masked]
Subject: Re: [CDNi] Is draft-ietf-cdni-use-cases-02.txt ready to WG LastCall?

(A)
g-

(A)

Ray van Brandenburg

(A)

Gilles

As an individual:  (A)

Francois

All,

We need your input:

Diff against 01:

Diff against 00:

Francois & Rich

Best regards,

Gilles

-----Message d'origine-----
De : Francois Le Faucheur [mailto:[email-masked]]
Envoyé : lundi 9 janvier 2012 15:49
À : BERTRAND Gilles RD-CORE-ISS
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [CDNi] TR: I-D Action: draft-ietf-cdni-use-cases-01.txt

Francois

*** section 2:

*** Section 2.3:

*** section 3.2.1:

*** section 5.1:
"

*** section 5.1:

*** section 5.3:

*** current section 5.3:
"

*** current section 5.3:

* current section 5.2:
OLD:
"

Dear all,

Best regards,

Gilles

-----Message d'origine-----

Francois Le Faucheur
Distinguished Engineer
Corporate Development

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

 Think before you print.

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 23 Jan 2012 14:01:24 -0800

I'm for (A).

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Friday, January 20, 2012 4:15 AM
To: [email-masked]
Subject: [CDNi] Is draft-ietf-cdni-use-cases-02.txt ready to WG Last Call?

All,

We need your input:

Diff against 01:

Diff against 00:

Francois & Rich

---

From: Martin Stiemerling <[email-masked]>
Date: Wed, 25 Jan 2012 15:27:03 +0000

An (A) from my side. 

  Martin

[email-masked]

NEC Laboratories Europe - Network Research Division NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road, London W3 6BL | Registered in England 2832014 

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Francois Le Faucheur
> Sent: Friday, January 20, 2012 1:15 PM
> To: [email-masked]
> As per our agreement in Taipei, assuming it is ready for it, we'd like to move
> the use-case document through WG Last Call without unnecessarily waiting for
> the March 2012 meeting.
> 
> 	http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-
> use-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt
> 
> Diff against 00:
> 	http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-
> use-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt
> 
> Francois & Rich
> 
> 
> > http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-
> cases-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt
> >
> > Best regards,
> >
> > Gilles
> >
> > https://tools.ietf.org/rfcdiff?url1=draft-ietf-cdni-use-cases-00&difftype=--
> html&submit=Go%21&url2=draft-ietf-cdni-use-cases-01
> >
> >
> >
> > *** section 2:
> > You replaced "a major use case" by "the major use case" . This might imply
> that other use cases are only "marginally" useful.
> > We have been careful to only include in this document use cases that are
> believed to be needed and deployable in a relatively short term future. This is
> the key thing. Beyond that, i don't see much value in trying to be too specific
> about which is "the" prominent use case.
> > So I'd suggest to:
> > 	* and possibly expend, at the beginning of section 2, on the short-term
> applicability/need of the use cases listed in this document. Possibly by doing the
> following change:
> > OLD:
> > "
> > This document outlines real world use cases (not technical solutions) for
> interconnecting CDNs. It can be used to provide guidance "
> > NEW:
> > "
> > This document outlines real world use cases (not technical solutions) for
> interconnecting CDNs. This document focuses on use cases that correspond to
> identified industry needs and that are expected to be realized once a standard
> CDNI solution is available. This document can be used to provide guidance "
> >
> >
> > *** Section 2.3:
> > "In partial failure scenarios, a CDN Provider has at least two options: (1)
> depending on traffic management policies, forward some requests to the CSP's
> origin servers, and (2) redirect some requests toward another CDN, which must
> be able to serve the redirected requests."
> > This text implies that some of this is relevant to CDNI but does not make that
> explicit. I suggest you do. For example by adding something like "This second
> option is a use case for CDNI."
> >
> >
> > *** section 5.1:
> > "
> > o the geographic regions from where content can be delivered (i.e., the
> location of the Surrogates), or o geographic locations to which content can be
> delivered (i.e., the location of the End Users).
> > "
> > I suggest you swap the order of these two bullet points, since the 2nd one
> seems like the most obvious/common of the two.
> >
> >
> > *** section 5.1:
> > To me, "availability" refers more to whether the content is available inside
> the CDN and is ready to be delivered to users that are allowed to access it.
> While, this section obviously discusses content delivery policies related to
> controlling which users can actually access that content, so I'd suggest changing
> the title, perhaps to something like "Content Delivery Restrictions" (I was going
> to suggest a slightly more generic title for 5.1 , but since the secure access
> control is discussed in a separate section 5.3, we need a term that matches the
> content of 5.1).
> >
> >
> > *** section 5.3:
> > I suggest reordering current section 5.3 before current section 5.2. This is
> because current section 5.3 is very related to current section 5.1, while current
> section 5.2 is of a different nature.
> >
> >
> > *** current section 5.3:
> > "
> > CSPs may often wish to dictate a specific protocol or set of protocols which
> are acceptable for delivery of their content, especially in the case where
> content protection or user authentication is required  (e.g., must use HTTPS, or
> must use URL hashing, etc.).
> > "
> > I think it is worth also explicitly describing the related, but slightly different,
> approach requested by CSPs whereby the CSP performs the per-request
> authentication/authorization decision themselves, and then leave it to the CDNs
> to enforce that decision (for example via validation of a signature included by
> the CSP).
> > So how about:
> > OLD:
> > "
> > CSPs may often wish to dictate a specific protocol or set of protocols which
> are acceptable for delivery of their content, especially in the case where
> content protection or user authentication is required  (e.g., must use HTTPS, or
> must use URL hashing, etc.).
> > "
> > NEW:
> > "
> > CSPs may often wish to dictate a specific protocol or set of protocols which
> are acceptable for delivery of their content, especially in the case where
> content protection or user authentication is required  (e.g., must use HTTPS).
> CSPs may also wish to perform per-request authentication/authorization
> decision and then have the CDNs enforce that decision (e.g., must validate URL
> signing, etc.).
> > "
> >
> >
> > *** current section 5.3:
> > The CSP may want to be assured that the requested access features are
> applied and therefore that dCDNs that lack support for these secure access
> features are not used. However, I am not sure that this is to be achieved by the
> CSP actively blacklisting some dCDNs, rather the CSP could simply state that
> these access features as mandatory and then leave it up to the Authoritative
> CDN to exclude whichever potential dCDN that is not capable of meeting this
> requirement.
> > "An uCDN needs to be able to exclude dCDNs which lack support for the
> secure access features requested by the CSP."
> >
> > There has been some discussion about the specific requirement to
> communicate list of blacklisted CDNs (which is a separate/broader question to
> the "Secure Access" topic). It might be best to progress/settle that discussion as
> part of the work on the requirements document.
> >
> >
> > * current section 5.2:
> > OLD:
> > "
> > CSPs may desire to offer content services under their own name, even when
> the associated CDN service involves other CDN Providers.
> > "
> > NEW:
> > "
> > CSPs may desire to ensure that content is delivered with URIs appearing to
> the endusers under their own domain name, even when the content delivery
> involves separate CDN Providers.
> > "
> >
> > As discussed in the context of the problem-statement, "CDN Providers" may
> need replacement by something like "CDSP". Please align with next rev of
> problem-statement.
> >
> >
> >
> >> We have posted a new revision of the use-cases draft, which incorporates
> the feedback received on the list and during IETF#82 meeting.
> >>
> >> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Content Delivery Networks
> Interconnection Working Group of the IETF.
> >>

---

From: Scott Wainner <[email-masked]>
Date: Thu, 26 Jan 2012 10:51:42 -0500

(A) assuming Kent's comments are addressed.

Scott Wainner

On 1/20/12 7:15 AM, Francois Le Faucheur (flefauch) wrote:
>
> All,
>
> We need your input:
>
> As per our agreement in Taipei, assuming it is ready for it, we'd like 
> to move the use-case document through WG Last Call without 
> unnecessarily waiting for the March 2012 meeting.
>
>         (B) you feel draft-ietf-cdni-use-cases-02.txt is NOT ready to 
> go through WG Last Call (and ideally why)
>
> Diff against 01:
> <http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt>
>
> Diff against 00:
> <http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.txt>
>
> Francois & Rich
>
>
> <http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-use-cases-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt>
> >
> > Best regards,
> >
> > Gilles
> >
> <https://tools.ietf.org/rfcdiff?url1=draft-ietf-cdni-use-cases-00&difftype=--html&submit=Go%21&url2=draft-ietf-cdni-use-cases-01>
> >
> >
> >
> > *** section 2:
> > You replaced "a major use case" by "the major use case" . This might 
> imply that other use cases are only "marginally" useful.
> > We have been careful to only include in this document use cases that 
> are believed to be needed and deployable in a relatively short term 
> future. This is the key thing. Beyond that, i don't see much value in 
> trying to be too specific about which is "the" prominent use case.
> > So I'd suggest to:
> >       * and possibly expend, at the beginning of section 2, on the 
> short-term applicability/need of the use cases listed in this 
> document. Possibly by doing the following change:
> > OLD:
> > "
> > This document outlines real world use cases (not technical 
> solutions) for interconnecting CDNs. It can be used to provide guidance "
> > NEW:
> > "
> > This document outlines real world use cases (not technical 
> solutions) for interconnecting CDNs. This document focuses on use 
> cases that correspond to identified industry needs and that are 
> expected to be realized once a standard CDNI solution is available. 
> This document can be used to provide guidance "
> >
> >
> > *** Section 2.3:
> > "In partial failure scenarios, a CDN Provider has at least two 
> options: (1) depending on traffic management policies, forward some 
> requests to the CSP's origin servers, and (2) redirect some requests 
> toward another CDN, which must be able to serve the redirected requests."
> > This text implies that some of this is relevant to CDNI but does not 
> make that explicit. I suggest you do. For example by adding something 
> like "This second option is a use case for CDNI."
> >
> >
> > *** section 5.1:
> > "
> > o the geographic regions from where content can be delivered (i.e., 
> the location of the Surrogates), or o geographic locations to which 
> content can be delivered (i.e., the location of the End Users).
> > "
> > I suggest you swap the order of these two bullet points, since the 
> 2nd one seems like the most obvious/common of the two.
> >
> >
> > *** section 5.1:
> > To me, "availability" refers more to whether the content is 
> available inside the CDN and is ready to be delivered to users that 
> are allowed to access it. While, this section obviously discusses 
> content delivery policies related to controlling which users can 
> actually access that content, so I'd suggest changing the title, 
> perhaps to something like "Content Delivery Restrictions" (I was going 
> to suggest a slightly more generic title for 5.1 , but since the 
> secure access control is discussed in a separate section 5.3, we need 
> a term that matches the content of 5.1).
> >
> >
> > *** section 5.3:
> > I suggest reordering current section 5.3 before current section 5.2. 
> This is because current section 5.3 is very related to current section 
> 5.1, while current section 5.2 is of a different nature.
> >
> >
> > *** current section 5.3:
> > "
> > CSPs may often wish to dictate a specific protocol or set of 
> protocols which are acceptable for delivery of their content, 
> especially in the case where content protection or user authentication 
> is required  (e.g., must use HTTPS, or must use URL hashing, etc.).
> > "
> > I think it is worth also explicitly describing the related, but 
> slightly different, approach requested by CSPs whereby the CSP 
> performs the per-request authentication/authorization decision 
> themselves, and then leave it to the CDNs to enforce that decision 
> (for example via validation of a signature included by the CSP).
> > So how about:
> > OLD:
> > "
> > CSPs may often wish to dictate a specific protocol or set of 
> protocols which are acceptable for delivery of their content, 
> especially in the case where content protection or user authentication 
> is required  (e.g., must use HTTPS, or must use URL hashing, etc.).
> > "
> > NEW:
> > "
> > CSPs may often wish to dictate a specific protocol or set of 
> protocols which are acceptable for delivery of their content, 
> especially in the case where content protection or user authentication 
> is required  (e.g., must use HTTPS). CSPs may also wish to perform 
> per-request authentication/authorization decision and then have the 
> CDNs enforce that decision (e.g., must validate URL signing, etc.).
> > "
> >
> >
> > *** current section 5.3:
> > The CSP may want to be assured that the requested access features 
> are applied and therefore that dCDNs that lack support for these 
> secure access features are not used. However, I am not sure that this 
> is to be achieved by the CSP actively blacklisting some dCDNs, rather 
> the CSP could simply state that these access features as mandatory and 
> then leave it up to the Authoritative CDN to exclude whichever 
> potential dCDN that is not capable of meeting this requirement.
> > "An uCDN needs to be able to exclude dCDNs which lack support for 
> the secure access features requested by the CSP."
> >
> communicate list of blacklisted CDNs (which is a separate/broader 
> question to the "Secure Access" topic). It might be best to 
> progress/settle that discussion as part of the work on the 
> requirements document.
> >
> >
> > * current section 5.2:
> > OLD:
> > "
> > CSPs may desire to offer content services under their own name, even 
> when the associated CDN service involves other CDN Providers.
> > "
> > NEW:
> > "
> > CSPs may desire to ensure that content is delivered with URIs 
> appearing to the endusers under their own domain name, even when the 
> content delivery involves separate CDN Providers.
> > "
> >
> > As discussed in the context of the problem-statement, "CDN 
> Providers" may need replacement by something like "CDSP". Please align 
> with next rev of problem-statement.
> >
> >
> >
> >> We have posted a new revision of the use-cases draft, which 
> incorporates the feedback received on the list and during IETF#82 meeting.
> >>
> directories. This draft is a work item of the Content Delivery 
> Networks Interconnection Working Group of the IETF.
> >>

---

From: HeXiaoyan <[email-masked]>
Date: Sun, 29 Jan 2012 10:03:47 +0800

(A).

Best Regards
Xiaoyan(Susan) He

> Sent: Friday, January 20, 2012 8:15 PM
> To: [email-masked]
> As per our agreement in Taipei, assuming it is ready for it, we'd like to
move the
> use-case document through WG Last Call without unnecessarily waiting for
the
> March 2012 meeting.
> 	(A) you feel draft-ietf-cdni-use-cases-02.txt is ready to go through
WG Last
> Call
> 	(B) you feel draft-ietf-cdni-use-cases-02.txt is NOT ready to go
through WG
> Last Call (and ideally why)
> 
> Diff against 01:
>
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni
-us
e-cases-01.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.tx
t
> Diff against 00:
http://tools.ietf.org//rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-cdni
-us
e-cases-00.txt&url2=http://tools.ietf.org/id/draft-ietf-cdni-use-cases-02.tx
t
> > Differences with previous versions:
http://tools.ietf.org//rfcdiff?url1=http://www.ietf.org/id/draft-ietf-cdni-u
se-cas
> es-01.txt&url2=http://www.ietf.org/id/draft-ietf-cdni-use-cases-02.txt
> >
> > Best regards,
> >
> > Gilles
> >
> > Below are a few small additional comments/suggestions (as an Individual)
on
> the recent changes.
> >
> > Francois
> >
> > PS: For others who want to review the Diff against the previous version,
I
> suggest you use:
html
> &submit=Go%21&url2=draft-ietf-cdni-use-cases-01
> >
> >
> >
> > *** section 2:
imply
> > 	* and possibly expend, at the beginning of section 2, on the
short-term
> origin servers, and (2) redirect some requests toward another CDN, which
> must be able to serve the redirected requests."
make that
> controlling which users can actually access that content, so I'd suggest
> changing the title, perhaps to something like "Content Delivery
Restrictions" (I
> was going to suggest a slightly more generic title for 5.1 , but since the
secure
> access control is discussed in a separate section 5.3, we need a term that
> matches the content of 5.1).
> >
> >
> > *** section 5.3:
This is
> content protection or user authentication is required  (e.g., must use
HTTPS,
> or must use URL hashing, etc.).
> > "
> authentication/authorization decision themselves, and then leave it to the
> CDNs to enforce that decision (for example via validation of a signature
> included by the CSP).
> > So how about:
> > OLD:
> > "
> content protection or user authentication is required  (e.g., must use
HTTPS,
> or must use URL hashing, etc.).
> > "
> > NEW:
> > "
> > "The CSP may wish to blacklist specific dCDNs which lack support for
these
> secure access features."
> the "Secure Access" topic). It might be best to progress/settle that
discussion
> as part of the work on the requirements document.
> >
> >
> > * current section 5.2:
> > OLD:
> > "
when
> >> We have posted a new revision of the use-cases draft, which
incorporates