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

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 Nov 2011 14:39:47 +0100

Hi Ben,

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

I had considered that option but I don't think that works either, because the "However..." now seems to refer to the preceding sentence (ie stuff out of scope) rather than the earlier sentences explaining that CDN interconnection is needed. 

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

That would be my vote.

Thanks.

Francois

> 
>>> contract with an "authoritative" CDN for the delivery content
>> 
>> s/delivery content/delivery of content/
> 
> Done.
> 
>>> 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/
> 
> Done.
> 
>> 
>> 
>> Francois
>> 
>>> 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
>>> 
>>> _______________________________________________
>>> CDNi mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/cdni
>> 
>> 
>> 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
>> 
>> 
> 

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: Thu, 3 Nov 2011 14:43:27 +0100

All these are fine by me. Thanks
Francois

On 31 Oct 2011, at 13:08, Ben Niven-Jenkins wrote:

> 
> On 28 Oct 2011, at 02:02, Francois Le Faucheur wrote:
> 
>> 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:
> 
> Done.
> 
>> 	* 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).
> 
> 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.
> 
>> 
>> 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
> 
> Done.
> 
>> 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. 
> 
> Done. 
> 
>> 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.
>> "
> 
> Done.
> 
>> 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
> 
> Done throughout the document.
> 
>> 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).
> 
> 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: Thu, 3 Nov 2011 17:00:47 +0000

Francois,

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

I've made this change in my working copy of -02 so it'll be reflected the next time we publish an updated version.

Ben