Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 3 May 2012 13:56:02 +0200

On 26 Apr 2012, at 23:46, Kevin J Ma wrote:

> Hi Ben,
> 
>> I agree with what you said, i.e. CSPs handle fancy policy and then grant
>> tokens/whatever that the dCDN can validate to ensure they are only
>> delivering to End Users the CSP has granted access too.
> 
> I do not disagree with your statement.  I just will note that if the CSP
> is nolonger in control of which dCDN the request will ultimately be delegated
> to, the "whatever" has to be enforced across all dCDNs.

Agreed. And this is why the CDNI working group has to agree on the definition of "whatever". At this stage I think the expectation is that the "whatever" that has to be enforced by the dCDN will comprise:
	*a* a few explicit basic policies (geo-blocking, time-woindow) 
	*b* a validation of pre-authorization performed by CSP (URI signing, token)
	*c* possibly an escape call-back to the uCDN for double-checking (as presented by Larry in Paris and agreed to).

With respect to the use-case document, I support the idea that the document discusses the notion of how do we ensure that the dCDN can enforce CSP policies. But I believe we need to be careful and explicitly distinguish between:
	 (i) arbitrarily sophisticated specific creative CSP policies and 
	(ii) a small set of basic policies to be signaled through CDNI protocol; 
and we need to explain how *b* and *c* can be used to support the fancy policies of (i) relying on basic policies of (ii).

If we agree on these premises, I recommend the use-case discussion on policy enforcement be expanded to convey these points.

Cheers

Francois

> 
> thanx.
> 
> --  Kevin J. Ma
> 
> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Ben Niven-Jenkins
>> Sent: Wednesday, April 25, 2012 1:39 PM
>> To: Francois Le Faucheur
>> Cc: [email-masked]; [email-masked]
>> Subject: Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases
>> 
>> Francois,
>> 
>> On 25 Apr 2012, at 17:45, Francois Le Faucheur wrote:
>> 
>>> I identified two remaining significant points to be addressed, and also
>> have included many suggestions to improve the document.
>>> I suggest we resolve the two significant points on the list and leave it
>> to editor/authors to decide how to dispose of the suggestions for
>> improvement offline.
>>> 
>>> Cheers
>>> 
>>> Francois
>>> 
>>> 
>>> Significant points
>>> =============
>>> 
>>> *** section 8 security considerations
>>> I have a few specific issues with the current text of the Security
>> Considerations section. But I don't really see the need to have an
>> expanded Security Considerations section in both the use-case document and
>> the problem-statement (particularly considering that the first IESG review
>> comments on problem-statement suggest expanding the security
>> considerations section there), in particular because the security
>> considerations currently brought up in use-cases are not specific to
>> individual use cases bur rather generic to the whole CDN interconnection
>> problem space.
>>> So my proposal would be to remove the whole discussion from use-cases
>> (i.e. the first 4 paragraphs) and refer to the Security Considerations
>> section of the Problem Statement e.g.. by replacing:
>>> "
>>> This document focuses on the motivational use cases for CDN
>> Interconnection, and does not analyze these threats in detail.
>>> "
>>> with:
>>> "
>>> This document focuses on the motivational use cases for CDN
>> Interconnection, and does not analyze the associated threats. Those are
>> discussed in [I-D.ietf-cdni-problem-statement].
>>> "
>> 
>> Works for me. As part of reworking the Security Considerations section in
>> the problem statement I will see what text from the use cases draft can be
>> reused.
>> 
>>> ***section A.1:
>>> I still have a problem with the text of that section.
>>> I thought we had converged on an agreement that the text would:
>>>    * explain that CSPs may take into account very
>> multiple/arbitrary/specific criteria in their policy
>>>    * explain that the CDNs are only expected to enforce a few specific
>> policy rules (e.g. geo-blocking, time window) and for enforcement of all
>> fancy CSP policy we propose that the responsibilities be divided into (1)
>> the CSP being responsible for the fancy policy decision and (ii) the CDN
>> for merely enforcing the CSP decision without having to understand the
>> policy (e.g. via URI signing).
>>> Do we not agree on that or not?
>> 
>> I agree with what you said, i.e. CSPs handle fancy policy and then grant
>> tokens/whatever that the dCDN can validate to ensure they are only
>> delivering to End Users the CSP has granted access too.
>> 
>> CDN policies should not be CSP specific - they should just cover things
>> like geo-blocking rules etc.
>> 
>> Ben
>> 
>>> 
>>> The current text says that CDN selection and surrogate selection "are
>> influenced by these policies" (referring to the fancy CSP policies). I do
>> not agree with that. I don;t think we want CDN Selection or Surrogate
>> selection to be influenced by whether a movie shoudl be available 14 or 28
>> days after DVD release, or whether a given resolution is "too high" for a
>> particular user or terminal.
>>> 
>>> Also, the paragraph keeps talking about "dCDN selection or Surrogate
>> selection" may fail for some fancy policy reasons. I don't understand what
>> it means to "fail" , but more importantly again, I don't think we want CDN
>> request routing decisions to be factoring very fancy CSP policy rules.
>>> Do we agree or not?
>>> 
>>> The last paragraphs gives examples of the CSP objectives of supporting
>> delivery policies in CDNs, and those are fine and can be achieved with the
>> set of mechanisms discussed above (i.e. goeblocking + time window + URI
>> signing).
>>> 
>>> 
>>> Suggestions for improvements
>>> =======================
>>> 
>>> ***Abstract
>>> replace "CDNI" by "CDN Interconnection".
>>> 
>>> *** section 1:
>>> expand the first instance of CDNI into "CDN Interconnection (CDNI)".
>>> 
>>> *** section 1:
>>> "Then, the document highlights the need for interoperability to
>>> exchange and enforce content delivery policies (Section 5)."
>>> I'd suggest replacing "for interoperability to exchange" by "for
>> interoperability to allow exchange" or by "for interoperability in order
>> to exchange"
>>> 
>>> *** section 1.1:
>>> Do you feel that the two additional terms are really specific to the
>> use-case document (in which case their definition should stay in this
>> document) or are they likely useful in other documents (in which case
>> their definition should be migrated to the framework document)?
>>> Personally, I would say that those terms might be useful in other
>> documents/discussions (eg I am pretty sure we'd need to refer to the
>> "Delivering CDN" in other context).
>>> 
>>> *** section 1.1:
>>> "Access CDN:
>>> A CDN that is directly connected to the End User's access."
>>> I think this definition needs to be a little more specific. "Directly
>> connected" does not mean "L2 connectivity" (because an on-net cache maybe
>> a few L2 hops away), nor does it mean "L3 connectivity" (because an OTT
>> CDN cache has IP connectivity to an enduser). I think you mean something
>> in between,  more or less that the CDN and the access are within the same
>> IP administrative domain, or something close to that. Can you try refine
>> that definition?
>>> 
>>> *** section 1.3:
>>> " o  improve the experience for the End User; for instance delivery has
>>>    lower latency (decreased round-trip-time between the user and the
>>>    delivery server) and better robustness,"
>>> To be more comprehensive in justifying the claims, how about:
>>> " o  improve the experience for the End User; for instance delivery has
>>>    lower latency (decreased round-trip-time and higher throughput
>> between the user and the
>>>    delivery server) and better robustness (ability to use multiple
>> delivery servers),"
>>> 
>>> *** section 1.3:
>>> "o  reduce the Content Service Provider's (CSP) costs, such as
>>>    datacenter capacity, space, and electricity consumption, as
>>>    popular content is delivered through the CDN rather than through
>>>    the CSP's servers."
>>> The current wording raises the question of "if it reduces the costs by
>> reducing expenses in the CSP datacenter, why does it not correspondingly
>> increase the cost by increasing expenses in the CDN (which the CDN
>> provider then charges back to the CSP)?"
>>> I think the gain is in the scale and effective pooling of CDN resources
>> across many CSPs. Could you refine the wording to explain why there is
>> indeed a net gain?
>>> 
>>> *** section 1.3:
>>> Replace:
>>> "
>>> An example is depicted in Figure 1.  Two CDN Providers establish a CDN
>> Interconnection.
>>> "
>>> with:
>>> "
>>> An example is depicted in Figure 1 where two CDN Providers establish a
>> CDN Interconnection.
>>> "
>>> (this is to minimize the redundancy with the sentence coming below: "CDN
>> Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.")
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their
>> CDNs."
>>> with:
>>> "Independently, CDN Provider 'A' and CDN Provider 'B' agree to
>> interconnect their CDNs."
>>> this is to clarify that the A<->B agreement is not specific to the 1<->A
>> agreement
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> When a User Agent requests content from CSP-1, CDN-A considers that
>> delivery by CDN-B is appropriate
>>> "
>>> with:
>>> "
>>> When a given User Agent requests content from CSP-1, CDN-A may consider
>> that delivery by CDN-B is appropriate
>>> "
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> CDN-A has delegated the handling of requests for CSP-1's content through
>> the CDN Interconnection agreement, thus, the content is actually delivered
>> from CDN-B.
>>> "
>>> with:
>>> "
>>> Through the CDN Interconnection arrangements put in place between CDN-A
>> and CDN-B (as a result of the CDN Interconnection agreement established
>> between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the
>> request to CDN-B and the content is actually delivered to the User Agent
>> by CDN-B.
>>> "
>>> (the current wording suggests that all deliveries of CSP1 content would
>> be handled by CDN-B, which is typically not the case i.e. only a subset of
>> the requests are redirected thy CDN-A to CDN-B)
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> CSP-1 benefits because it only needs to make one business agreement and
>> one physical connection, with CDN Provider 'A'
>>> "
>>> with:
>>> "
>>> CSP-1 benefits because it only needs to make one business agreement and
>> one technical arrangement with CDN Provider 'A'
>>> "
>>> (this is because the interfacing between CSP and uCDN comprises more
>> than "physical connection").
>>> 
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> CSP-1 had also gone to the trouble of making a business agreement with
>> CDN Provider 'B'
>>> "
>>> with:
>>> "
>>> CSP-1 had also gone to the trouble of making a business agreement and
>> technical arrangemement with CDN Provider 'B'
>>> "
>>> 
>>> *** section 1.3:
>>> replace:
>>> "
>>> But it does not want
>>> "
>>> with:
>>> "
>>> However, CSP-2 may not want
>>> "
>>> 
>>> *** section 2.1:
>>> after
>>> "
>>> o  without incurring additional transit and other network costs that
>>>     would result from serving content from geographically or
>>>     topologically remote Surrogates.
>>> "
>>> add:
>>> "
>>> o without incurring the cost of deploying and operating Surrogates and
>> the associated CDN infrastructure that may not be justified in the
>> corresponding geographic region (e.g. because of relatively low delivery
>> volume, or conversely because of the high investments that would be needed
>> to satisfy the high volume)
>>> "
>>> 
>>> 
>>> *** section 2.2:
>>> replace:
>>> "
>>> A large CDN Provider may also operate CDNs from several subsidiaries
>> (which may rely on different CDN technologies, see Section 4.2). In
>> certain circumstances, the CDN Provider needs to make its CDNs
>> interoperate to provide a consistent service to its customers on its whole
>> footprint.
>>> "
>>> with:
>>> "
>>> A large CDN Provider may have several subsidiaries that also each
>> operate their own CDN (which may rely on different CDN technologies, see
>> Section 4.2). In certain circumstances, the CDN Provider needs to make
>> these CDNs interoperate to provide a consistent service to its customers
>> on the whole collective footprint.
>>> "
>>> 
>>> 
>>> *** section 2.3:
>>> replace:
>>> "
>>> injected into the access network
>>> "
>>> with:
>>> "
>>> injected into the ISP network
>>> "
>>> 
>>> *** section 2.3:
>>> replace:
>>> "
>>> There are mutual benefits to the Access CDN,
>>> "
>>> with:
>>> "
>>> There are mutual benefits to the ISP (acting as an Access CDN),
>>> "
>>> 
>>> 
>>> *** section 2.3:
>>> replace:
>>> "
>>> for example, QoS and reduced round trip time.
>>> "
>>> with:
>>> "
>>> for example, reduced content startup time or increased video quality and
>> resolution of adaptive streaming content.
>>> "
>>> (I don't think RTT is very meaningful to a CSP customer)
>>> 
>>> 
>>> *** section 2.4:
>>> The nomadic user is currently defined as "moving between CDNs" which is
>> sort of a self-serving definition to justify CDN interconnection. I think
>> we should rather define the nomadic user as "moving between access
>> networks" and then justify that leveraging local CDNs can bring a lot of
>> benefits.
>>> This requires the following text edits:
>>> s/who move between CDNs/who move between access networks/
>>> s/moving between different CDN Providers/moving between different access
>> networks/
>>> 
>>> *** section 2.4:
>>> replace:
>>> "
>>> which may reside
>>> "
>>> with:
>>> "
>>> which may be located
>>> "
>>> 
>>> *** section 2.4:"
>>> I propose to remove the sentence:
>>> "
>>> The term "Nomadic" does not necessarily relate to geographic roaming.
>>> "
>>> because this point has already been fully (and better) clarified in the
>> preceding paragraph.
>>> 
>>> 
>>> 
>>> *** section 2.4:
>>> replace:
>>> "
>>> the WiFi or mobile provider
>>> "
>>> with:
>>> "
>>> the WiFi or mobile provider (NSP B)
>>> "
>>> 
>>> 
>>> *** section 3.1:
>>> replace:
>>> "
>>> needs CDN capacities
>>> "
>>> with:
>>> "
>>> needs CDN capacity
>>> "
>>> 
>>> *** section 3.2.1:
>>> The text mentions two options (use OS, use another CDN). I think the
>> section shoudl probably also mention the most obvious option (i.e. use
>> other surrogates in the same CDN). Or alternatively, clarify that the
>> considered situation is where there is a partial failure of some
>> surrogates resulting in the remaining surrogates being fully loaded.
>>> 
>>> 
>>> *** section 3.2.1:
>>> replace:
>>> "
>>> to both distribute load between origin servers and attempt content
>> acquisition from alternate origin servers when acquisition failures occur.
>> When normal content acquisition fails, a CDN may need to try other origin
>> server options,
>>> "
>>> with:
>>> "
>>> to both distribute load between content sources and attempt content
>> acquisition from alternate content sources when acquisition failures
>> occur.  When normal content acquisition fails, a CDN may need to try other
>> content source options,
>>> "
>>> (I believe everywhere else we use "origin server" to refer to the OS of
>> the CSP and "content source" as the generic term for getting content
>> including origin server and uCDN)
>>> 
>>> *** section 3.2.2:
>>> replace:
>>> "
>>> the selection of content acquisition sources should be considered.
>>> "
>>> with:
>>> "
>>> the selection of content acquisition sources should be considered and
>> facilitated.
>>> "
>>> (i.e. it is not just a matter of "thinking" about it: it must be
>> explicitly allowed or at leads made easier).
>>> 
>>> 
>>> *** section 4.1:
>>> "to serve a proportion of its traffic that requires HTTPS."
>>> can you include a reference for HTTPS?
>>> 
>>> 
>>> *** section 5:
>>> replace:
>>> "
>>> An important aspect of the above use cases
>>> "
>>> with:
>>> "
>>> An important aspect common to all the above use cases
>>> "
>>> 
>>> 
>>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line
>> 618, but no explicit reference was found in the text
>>> I'd suggest you add an explicit reference. For example, in "1.
>> Introduction" you could replace:
>>> "
>>> The document can be used to guide the definition of the requirements to
>> be supported by the various CDNI interfaces defined in [I-D.ietf-cdni-
>> problem-statement].
>>> "
>>> by
>>> "
>>> The document can be used to guide the definition of the requirements (as
>> documented in [I-D.ietf-cdni-requirements]) to be supported by the set of
>> CDNI interfaces defined in [I-D.ietf-cdni-problem-statement].
>>> "
>>> (BTW, independely of the reference issue, "the set of CDNI interfaces"
>> might read better than "the various CDNI interfaces").
>>> 
>>> 
>>> *** The document has a disclaimer for pre-RFC5378 work, but was first
>> submitted on or after 10 November 2008.  Does it really need the
>> disclaimer?
>>> _______________________________________________
>>> 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: Fri, 4 May 2012 17:28:26 +0200

Hi Kevin,

I think the discussion below touches on two topics:
	*A* delivery policies to be communicated and enforced by a dCDN
	*B* potential interactions between request-routing and the ability of a CDN to enforce an aspect of policy 

Regarding *A*, I expressed my thoughts in http://www.ietf.org/mail-archive/web/cdni/current/msg00988.html. Please let me know if that makes sense to you.

Regarding *B*: So I think your concern is "how do we deal with potential situations where an uCDN may redirect a request to a dCDN that is not capable to enforce all aspects of the distribution policy?". That is a good point.
My proposal would be:
	* let's settle on a small set of well-defined policies (as discussed in http://www.ietf.org/mail-archive/web/cdni/current/msg00988.html.) such as geoblocking + time-window + pre-authrization-enforcement (e.g. URI signing), then we may virtually eliminate the situation altogether in the common cases (at least in the initial incarnation of the CDNI solution) since all dCDNs could support that set of policies (i.e. they would be mandatory)
	* to allow flexibility in the future (e.g. to allow introduction of additional policies in subsequent versions of CDNI), let's rely on the "Capabilities Advertisement" of the Request Routing interface. This would allow the dCDN to advertise to the uCDN what sort of capabilities it supports in the area of distribution policy enforcement. The design team will look into the details of those but they might come at different levels of granularity; for example, the dCDN may allow a dCDN to say "I support the delivery policies defined in CDNI v1"  or "I support the delivery policies defined in CDNI v1 and in CDNIv2" or, if needed, "I support the delivery policies defined in CDNI v1 and the 1st subset of delivery policies defined in CDNIv2 but not the 2nd subset". This can be factored by the uCDN Request Routing system (e.g. it can consider the metadata and based on those could decide to consider the dCDN advertised policy capabilities). I am not sure we need that sort of things for our initial CDNI solution, but arguably that depends on if we can settle for a single set of delivery policies that we all make mandatory.
	* in any case, we have the "escape" mechanism discussed by Larry in Paris: if a dCDN is explicitly told so, or if it is not capable of enforcing a particular policy aspect requested in the metadata, then it can do a per-request authorization check into the uCDN.

Do you agree with the above?

To your specific question about my concern with the current text. I just don't get the point it is trying to make. For example it says:
"
dCDN delegation and Surrogate selection decisions are influenced by
   these policies:

...
   o  dCDN delegation may fail if the content resolution has been
      specified by the CSP as being too high for distribution via the
      dCDN,
"
I understand this to mean that dCDN selection by the uCDN is supped to take into account things like whether a given resolution is deemed to high by the CSP for delivery via a CDN.
I disagree with this. The uCDN should not have to be aware of that sort of policies. All it would know is whether a content is to be delivered or not (it really does not care whether this is because of excessively good resolution or any CSP-meaningful but CDN-meaningless reasons).

Again, to me the whole point of that section is precisely to clarify that CSPs may have fancy policies and that those can be enforced in a multi-CDN environment without having to make these fancy policy understood by the CDNs. The current text is suggesting quite the opposite to me. Or maybe I am misreading it.

Cheers

Francois

On 26 Apr 2012, at 23:46, Kevin J Ma wrote:

> Hi Francois,
> I agree that the CDN should enforce any policy that is defined in metadata.
> If a supported metadata dictates a restriction, regardless of any individual
> interpretation of the semantic fanciness, the restriction should be enforced.
> If a dCDN does not support a given metadata, it can express that to the uCDN,
> which should influence the inter-CDN request routing.
> 
>> it means to "fail", but more importantly again, I don't think we want CDN
> The failure could probably be a more generic delivery failure, due to
> restrictions defined in the metadata, though, the framework document
> shows the metadata checks as part of request routing decision making
> which presumably influences dCDN/Surrogate selection?
> 
> The fanciness of the policy should not matter, as long as the
> metadata which conveys the enforcement of that policy is clear and
> succinct.  The inter-CDN request routing should be aware of the
> capabilities of each dCDN and not delegate to dCDNs that lack support
> for capabilities which are deemed mandatory.
> 
> The use cases do not dictate any specific implementations.  They do not
> require request routing to implement fancy policy rules.  A valid
> implementation could wrap all the fancy policy rules into a nice neat
> boolean value.  An equally valid implementation could implement extra
> super fancy policy rules.  The use case does not mandate one or the other.
> 
> Is the concern that specific portions are not valid, or that the descriptions
> are unclear, or is the concern about an assumed implementation's fanciness?
> 
> thanx.
> 
> --  Kevin J. Ma
> 
>> Francois Le Faucheur
>> Sent: Wednesday, April 25, 2012 12:46 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases
>> 
>> To use-cases authors,
>> 
>> Below are my shepherd review comments of cdni-uses-cases.
>> 
>> I think the document is in a good shape and captures well the key targeted
>> use cases.
>> Do you feel that the two additional terms are really specific to the use-
>> case document (in which case their definition should stay in this
>> An example is depicted in Figure 1 where two CDN Providers establish a CDN
>> Interconnection.
>> "
>> "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs."
>> with:
>> (the current wording suggests that all deliveries of CSP1 content would be
>> handled by CDN-B, which is typically not the case i.e. only a subset of
>> (this is because the interfacing between CSP and uCDN comprises more than
>> "physical connection").
>> 
>> 
>> *** section 1.3:
>> replace:
>> "
>> CSP-1 had also gone to the trouble of making a business agreement with CDN
>> Provider 'B'
>> "
>> with:
>> "
>> o without incurring the cost of deploying and operating Surrogates and the
>> associated CDN infrastructure that may not be justified in the
>> A large CDN Provider may have several subsidiaries that also each operate
>> their own CDN (which may rely on different CDN technologies, see Section
>> 4.2). In certain circumstances, the CDN Provider needs to make these CDNs
>> interoperate to provide a consistent service to its customers on the whole
>> collective footprint.
>> "
>> 
>> 
>> *** section 2.3:
>> replace:
>> "
>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 618,
>> but no explicit reference was found in the text
>> The document can be used to guide the definition of the requirements to be
>> supported by the various CDNI interfaces defined in [I-D.ietf-cdni-
>> problem-statement].
>> "
>> by
>> "

---

From: <[email-masked]>
Date: Wed, 9 May 2012 17:19:21 +0200

Hi François,

Thanks for your review. We are integrating your comments. 

About your comments on Section 1.1, I definitely think the terms "Access CDN" and "Delivering CDN" are useful more broadly than just in the use cases document. Therefore, I would be in favor of moving them to the framework document as you propose.

        Access CDN:
        A CDN that includes Surrogates in the same network (e.g., same Autonomous System) as the End User. An Access CDN may have specific information about
        the End User and the network, for instance, End User's
        profile and access capabilities.

        Delivering CDN:
        The CDN that delivers the requested piece of content to
        the End User. In particular, the Delivering CDN can be an
        Access CDN.

Best regards,

Gilles

-----Message d'origine-----
De : [email-masked] [mailto:[email-masked]] De la part de Francois Le Faucheur
Envoyé : mercredi 25 avril 2012 18:46
À : [email-masked]
Cc : [email-masked]
Objet : [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases

To use-cases authors,

I think the document is in a good shape and captures well the key targeted use cases.
I identified two remaining significant points to be addressed, and also have included many suggestions to improve the document.
I suggest we resolve the two significant points on the list and leave it to editor/authors to decide how to dispose of the suggestions for improvement offline.

Cheers

Francois

Significant points
=============

*** section 8 security considerations
I have a few specific issues with the current text of the Security Considerations section. But I don't really see the need to have an expanded Security Considerations section in both the use-case document and the problem-statement (particularly considering that the first IESG review comments on problem-statement suggest expanding the security considerations section there), in particular because the security considerations currently brought up in use-cases are not specific to individual use cases bur rather generic to the whole CDN interconnection problem space.
So my proposal would be to remove the whole discussion from use-cases (i.e. the first 4 paragraphs) and refer to the Security Considerations section of the Problem Statement e.g.. by replacing:
" 
This document focuses on the motivational use cases for CDN Interconnection, and does not analyze these threats in detail.
"
with:
"
This document focuses on the motivational use cases for CDN Interconnection, and does not analyze the associated threats. Those are discussed in [I-D.ietf-cdni-problem-statement].
"

***section A.1:
I still have a problem with the text of that section.
I thought we had converged on an agreement that the text would:
	* explain that CSPs may take into account very multiple/arbitrary/specific criteria in their policy
	* explain that the CDNs are only expected to enforce a few specific policy rules (e.g. geo-blocking, time window) and for enforcement of all fancy CSP policy we propose that the responsibilities be divided into (1) the CSP being responsible for the fancy policy decision and (ii) the CDN for merely enforcing the CSP decision without having to understand the policy (e.g. via URI signing).
Do we not agree on that or not?

The current text says that CDN selection and surrogate selection "are influenced by these policies" (referring to the fancy CSP policies). I do not agree with that. I don;t think we want CDN Selection or Surrogate selection to be influenced by whether a movie shoudl be available 14 or 28 days after DVD release, or whether a given resolution is "too high" for a particular user or terminal. 

Also, the paragraph keeps talking about "dCDN selection or Surrogate selection" may fail for some fancy policy reasons. I don't understand what it means to "fail" , but more importantly again, I don't think we want CDN request routing decisions to be factoring very fancy CSP policy rules.
Do we agree or not?

The last paragraphs gives examples of the CSP objectives of supporting delivery policies in CDNs, and those are fine and can be achieved with the set of mechanisms discussed above (i.e. goeblocking + time window + URI signing).

***Abstract

*** section 1:

*** section 1:
"Then, the document highlights the need for interoperability to
  exchange and enforce content delivery policies (Section 5)."
I'd suggest replacing "for interoperability to exchange" by "for interoperability to allow exchange" or by "for interoperability in order to exchange"

*** section 1.1:
Do you feel that the two additional terms are really specific to the use-case document (in which case their definition should stay in this document) or are they likely useful in other documents (in which case their definition should be migrated to the framework document)?
Personally, I would say that those terms might be useful in other documents/discussions (eg I am pretty sure we'd need to refer to the "Delivering CDN" in other context).

*** section 1.1:
"Access CDN:
  A CDN that is directly connected to the End User's access."
I think this definition needs to be a little more specific. "Directly connected" does not mean "L2 connectivity" (because an on-net cache maybe a few L2 hops away), nor does it mean "L3 connectivity" (because an OTT CDN cache has IP connectivity to an enduser). I think you mean something in between,  more or less that the CDN and the access are within the same IP administrative domain, or something close to that. Can you try refine that definition?

*** section 1.3:
" o  improve the experience for the End User; for instance delivery has
     lower latency (decreased round-trip-time between the user and the
     delivery server) and better robustness,"
To be more comprehensive in justifying the claims, how about:
" o  improve the experience for the End User; for instance delivery has
     lower latency (decreased round-trip-time and higher throughput between the user and the
     delivery server) and better robustness (ability to use multiple delivery servers),"

*** section 1.3:
"o  reduce the Content Service Provider's (CSP) costs, such as
     datacenter capacity, space, and electricity consumption, as
     popular content is delivered through the CDN rather than through
     the CSP's servers."
The current wording raises the question of "if it reduces the costs by reducing expenses in the CSP datacenter, why does it not correspondingly increase the cost by increasing expenses in the CDN (which the CDN provider then charges back to the CSP)?"
I think the gain is in the scale and effective pooling of CDN resources across many CSPs. Could you refine the wording to explain why there is indeed a net gain?

*** section 1.3:
Replace:
"
An example is depicted in Figure 1.  Two CDN Providers establish a CDN Interconnection.
"
with:
"
An example is depicted in Figure 1 where two CDN Providers establish a CDN Interconnection.
"
(this is to minimize the redundancy with the sentence coming below: "CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs.")

*** section 1.3:
replace:
"
"CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs."
with:
"Independently, CDN Provider 'A' and CDN Provider 'B' agree to interconnect their CDNs."
this is to clarify that the A<->B agreement is not specific to the 1<->A agreement

*** section 1.3:
replace:
"
When a User Agent requests content from CSP-1, CDN-A considers that delivery by CDN-B is appropriate "
with:
"
When a given User Agent requests content from CSP-1, CDN-A may consider that delivery by CDN-B is appropriate "

*** section 1.3:
replace:
"
CDN-A has delegated the handling of requests for CSP-1's content through the CDN Interconnection agreement, thus, the content is actually delivered from CDN-B.
"
with:
"
Through the CDN Interconnection arrangements put in place between CDN-A and CDN-B (as a result of the CDN Interconnection agreement established between CDN Provider 'A' and CDN Provider 'B'), CDN-A can redirect the request to CDN-B and the content is actually delivered to the User Agent by CDN-B.
"
(the current wording suggests that all deliveries of CSP1 content would be handled by CDN-B, which is typically not the case i.e. only a subset of the requests are redirected thy CDN-A to CDN-B) 

*** section 1.3:
replace:
"
CSP-1 benefits because it only needs to make one business agreement and one physical connection, with CDN Provider 'A'
"
with:
"
CSP-1 benefits because it only needs to make one business agreement and one technical arrangement with CDN Provider 'A'
"
(this is because the interfacing between CSP and uCDN comprises more than "physical connection").

*** section 1.3:
replace:
"
CSP-1 had also gone to the trouble of making a business agreement with CDN Provider 'B'
"
with:
"
CSP-1 had also gone to the trouble of making a business agreement and technical arrangemement with CDN Provider 'B'
"

*** section 1.3:
replace:
"
But it does not want
"
with:
"

*** section 2.1:
after
"
o  without incurring additional transit and other network costs that
      would result from serving content from geographically or
      topologically remote Surrogates.
"
add:
"
o without incurring the cost of deploying and operating Surrogates and the associated CDN infrastructure that may not be justified in the corresponding geographic region (e.g. because of relatively low delivery volume, or conversely because of the high investments that would be needed to satisfy the high volume) "

*** section 2.2:
replace:
"
A large CDN Provider may also operate CDNs from several subsidiaries (which may rely on different CDN technologies, see Section 4.2). In certain circumstances, the CDN Provider needs to make its CDNs interoperate to provide a consistent service to its customers on its whole footprint.
"
with:
"
A large CDN Provider may have several subsidiaries that also each operate their own CDN (which may rely on different CDN technologies, see Section 4.2). In certain circumstances, the CDN Provider needs to make these CDNs interoperate to provide a consistent service to its customers on the whole collective footprint. 
"

*** section 2.3:
replace:
"

*** section 2.3:
replace:
"

*** section 2.3:
replace:
"
for example, QoS and reduced round trip time.
"
with:
"
for example, reduced content startup time or increased video quality and resolution of adaptive streaming content.
"
(I don't think RTT is very meaningful to a CSP customer)

*** section 2.4:
The nomadic user is currently defined as "moving between CDNs" which is sort of a self-serving definition to justify CDN interconnection. I think we should rather define the nomadic user as "moving between access networks" and then justify that leveraging local CDNs can bring a lot of benefits.
This requires the following text edits:
s/who move between CDNs/who move between access networks/
s/moving between different CDN Providers/moving between different access networks/

*** section 2.4:
replace:
"
which may reside
"
with:
"
which may be located
"

*** section 2.4:"
I propose to remove the sentence:
"
The term "Nomadic" does not necessarily relate to geographic roaming.
"
because this point has already been fully (and better) clarified in the preceding paragraph.

*** section 2.4:
replace:
"

*** section 3.1:
replace:
"
needs CDN capacities
"
with:
"
needs CDN capacity
"

*** section 3.2.1:
The text mentions two options (use OS, use another CDN). I think the section shoudl probably also mention the most obvious option (i.e. use other surrogates in the same CDN). Or alternatively, clarify that the considered situation is where there is a partial failure of some surrogates resulting in the remaining surrogates being fully loaded.

*** section 3.2.1:
replace:
"
to both distribute load between origin servers and attempt content acquisition from alternate origin servers when acquisition failures occur.  When normal content acquisition fails, a CDN may need to try other origin server options,
"
with:
"
to both distribute load between content sources and attempt content acquisition from alternate content sources when acquisition failures occur.  When normal content acquisition fails, a CDN may need to try other content source options,
"
(I believe everywhere else we use "origin server" to refer to the OS of the CSP and "content source" as the generic term for getting content including origin server and uCDN)

*** section 3.2.2:
replace:
"
the selection of content acquisition sources should be considered.
"
with:
"
the selection of content acquisition sources should be considered and facilitated.
"
(i.e. it is not just a matter of "thinking" about it: it must be explicitly allowed or at leads made easier).

*** section 4.1:

*** section 5:
replace:
"

*** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on line 618, but no explicit reference was found in the text
I'd suggest you add an explicit reference. For example, in "1.  Introduction" you could replace:
"
The document can be used to guide the definition of the requirements to be supported by the various CDNI interfaces defined in [I-D.ietf-cdni-problem-statement].
"
by
"
The document can be used to guide the definition of the requirements (as documented in [I-D.ietf-cdni-requirements]) to be supported by the set of CDNI interfaces defined in [I-D.ietf-cdni-problem-statement].
"
(BTW, independely of the reference issue, "the set of CDNI interfaces" might read better than "the various CDNI interfaces").

*** The document has a disclaimer for pre-RFC5378 work, but was first  submitted on or after 10 November 2008.  Does it really need the disclaimer?
_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 9 May 2012 17:47:31 +0200

Hi Larry,

Can you confirm this can be done in next rev of cdni-framework?

Tx

Francois

---

From: "Peterson, Larry" <[email-masked]>
Date: Wed, 9 May 2012 13:05:59 -0400

Yes... Generally, it would be good to do a survey of terminology
various docs have introduced recently, and converge on the core
definitions.

Larry

---

From: Kevin J Ma <[email-masked]>
Date: Wed, 9 May 2012 19:32:04 -0400

Hi Francois,

>       * to allow flexibility in the future (e.g. to allow introduction of
> additional policies in subsequent versions of CDNI), let's rely on the
> "Capabilities Advertisement" of the Request Routing interface.

Just to clarify, are you proposing that the list of supported metadata
are exchanged in the RR capabilities, but, the metadata would still be
applied to the individual (or groups of) content items?

I would agree with this, noting that the actual metadata value applied
to any given content asset may still be rejected later.

>       * in any case, we have the "escape" mechanism

I agree that rejection support (per the META-13 requirement) is needed.

> levels of granularity; for example, the dCDN may allow a dCDN to say "I
> support the delivery policies defined in CDNI v1"  or "I support the
> delivery policies defined in CDNI v1 and in CDNIv2" or, if needed, "I
> support the delivery policies defined in CDNI v1 and the 1st subset of
> delivery policies defined in CDNIv2 but not the 2nd subset".

These examples concern me in that they might imply that only those
policies (and therefore only those metadata) officially blessed by the
CDNI working group will be allowed.  I would think that there should
be a way to include opaque and vendor defined metadata with the
capabilities advertisement as well.

>  I understand this to mean that dCDN selection by the uCDN is supped to
> take into account things like whether a given resolution is deemed to high
> by the CSP for delivery via a CDN.

The intent was to show that CP may have policies that they wish to
enforce.  If a CP has a resolution policy, this is not to imply that
the CDN needs to know the resolution, only that the CP may be
motivated by something like resolution, to define a policy.

> Again, to me the whole point of that section is precisely to clarify that
> CSPs may have fancy policies and that those can be enforced in a multi-CDN
> environment without having to make these fancy policy understood by the
> CDNs.

I agree with this statement.

> The current text is suggesting quite the opposite to me. Or maybe I
> am misreading it.

We will address this.

thanx.

--  Kevin J. Ma

> From: Francois Le Faucheur [mailto:[email-masked]]
> Sent: Friday, May 04, 2012 11:28 AM
> To: Kevin J Ma
> Cc: Francois Le Faucheur; [email-masked];
> [email-masked]
> Subject: Tie between Request-Routing and policy Re: [CDNi] Document
> Shepherd review of draft-ietf-cdni-use-cases
>
> Hi Kevin,
>
> Regarding *A*, I expressed my thoughts in http://www.ietf.org/mail-
> archive/web/cdni/current/msg00988.html. Please let me know if that makes
> sense to you.
>
> Regarding *B*: So I think your concern is "how do we deal with potential
> situations where an uCDN may redirect a request to a dCDN that is not
> capable to enforce all aspects of the distribution policy?". That is a
> good point.
> My proposal would be:
>       * let's settle on a small set of well-defined policies (as discussed
> in http://www.ietf.org/mail-archive/web/cdni/current/msg00988.html.) such
> as geoblocking + time-window + pre-authrization-enforcement (e.g. URI
> signing), then we may virtually eliminate the situation altogether in the
> common cases (at least in the initial incarnation of the CDNI solution)
> since all dCDNs could support that set of policies (i.e. they would be
> mandatory)
>       * to allow flexibility in the future (e.g. to allow introduction of
> additional policies in subsequent versions of CDNI), let's rely on the
> "Capabilities Advertisement" of the Request Routing interface. This would
> allow the dCDN to advertise to the uCDN what sort of capabilities it
> supports in the area of distribution policy enforcement. The design team
> will look into the details of those but they might come at different
> levels of granularity; for example, the dCDN may allow a dCDN to say "I
> support the delivery policies defined in CDNI v1"  or "I support the
> delivery policies defined in CDNI v1 and in CDNIv2" or, if needed, "I
> support the delivery policies defined in CDNI v1 and the 1st subset of
> delivery policies defined in CDNIv2 but not the 2nd subset". This can be
> factored by the uCDN Request Routing system (e.g. it can consider the
> metadata and based on those could decide to consider the dCDN advertised
> policy capabilities). I am not sure we need that sort of things for our
> initial CDNI solution, but arguably that depends on if we can settle for a
> single set of delivery policies that we all make mandatory.
>       * in any case, we have the "escape" mechanism discussed by Larry in
> Paris: if a dCDN is explicitly told so, or if it is not capable of
> enforcing a particular policy aspect requested in the metadata, then it
> can do a per-request authorization check into the uCDN.
>
> To your specific question about my concern with the current text. I just
> don't get the point it is trying to make. For example it says:
> "
> I understand this to mean that dCDN selection by the uCDN is supped to
> take into account things like whether a given resolution is deemed to high
> by the CSP for delivery via a CDN.
> I disagree with this. The uCDN should not have to be aware of that sort of
> policies. All it would know is whether a content is to be delivered or not
> (it really does not care whether this is because of excessively good
> resolution or any CSP-meaningful but CDN-meaningless reasons).
>
> Again, to me the whole point of that section is precisely to clarify that
> CSPs may have fancy policies and that those can be enforced in a multi-CDN
> environment without having to make these fancy policy understood by the
> CDNs. The current text is suggesting quite the opposite to me. Or maybe I
> am misreading it.
>
> Cheers
>
> Francois
>
>
> use-
> CDN
> >> this is to clarify that the A<->B agreement is not specific to the 1<-
> >A
> >> agreement
> >>
> >>
> >> *** section 1.3:
> >> replace:
> >> "
> be
> CDN
> the
> operate
> 618,
> be

---

From: Francois Le Faucheur <[email-masked]>
Date: Sat, 12 May 2012 19:15:59 +0200

> applied to the individual (or groups of) content items?

Right.
With the clarification that the RR capabilities mechanism may distribute information about which metadata/policy-rules are supported by a dCDN in an aggregate manner (e.g. indicate that a given set of metadata/policy-rules are supported) as opposed to necessary individually (e.g. listing each and every individual metadata/policy-rules).

>>      * in any case, we have the "escape" mechanism

Right.

> capabilities advertisement as well.

Agreed.
Could you check with Kent to see if this is covered in the requirements I-D and if not get it covered?

> motivated by something like resolution, to define a policy.

So we are in line, and it sounds like a wording issue.

>> The current text is suggesting quite the opposite to me. Or maybe I

Thanks

Francois

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 14 May 2012 04:19:04 +0100

>        profile and access capabilities.

Is there really something special about an "access CDN" that means we should define a specific term for it rather than just pointing out the "special" bits in prose when they are relevant?

I am slightly worried we start to introduce lots of quite specific terms when in the majority of cases the "specifics" are not relevant. For example, it seems to me that in the majority of cases we'll end up talking about in our documents the fact an "Access CDN" may have some more specific information won't be relevant at all.

I worry that having too many specific terms for specific use cases actually leads to more ambiguity, not less. To demonstrate possible ambiguities: The examples of specific information makes me wonder, is a CDN that isn't in the same network as an End User but is integrated with an NSP's policy control (so it has awareness of profiles/access capabilities) an access CDN? Or, is a CDN that is in the same network as the End User but doesn't have any specific information on profiles/access capabilities an access CDN?

>        the End User. In particular, the Delivering CDN can be an

I'd prefer "Terminating CDN" to "Delivering CDN" because I think delivering CDN may get confusing when we're talking about end to end flows. For example for a given content delivery, upstream CDN(s) may also be delivering the content to downstream CDN(s). Having some CDNs "delivering" content and other CDNs being called "Delivering CDNs" and expecting readers to differentiate between the two (slightly different) uses of the term "delivering" seems likely to cause confusion IMO.

Ben

---

From: <[email-masked]>
Date: Mon, 14 May 2012 14:55:20 +0200

Hi Ben,

We can always avoid defining terms and concepts, at the price of redundant explanations in the drafts. 

IMO, the term "delivering CDN" is immediately understandable: considering a given request, the delivering CDN is the one that delivers the requested content to the end-user. By contrast, I find the term terminating CDN more confusing (what does it terminate?). 

Best regards,

Gilles

-----Message d'origine-----
De : Ben Niven-Jenkins [mailto:[email-masked]] 
Envoyé : lundi 14 mai 2012 05:19
À : BERTRAND Gilles RD-CORE-ISS
Cc : [email-masked]; [email-masked]; [email-masked]
Objet : Re: [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases

Ben

> De : [email-masked] [mailto:[email-masked]] De la part 
> de Francois Le Faucheur Envoyé : mercredi 25 avril 2012 18:46 À : 
> [email-masked]
> Cc : [email-masked]
> (this is to minimize the redundancy with the sentence coming below: 
> CDNs.")
> (the current wording suggests that all deliveries of CSP1 content 
> would be handled by CDN-B, which is typically not the case i.e. only a 
> subset of the requests are redirected thy CDN-A to CDN-B)
> 
> 
> *** section 1.3:
> replace:
> "
> There are mutual benefits to the Access CDN, "
> with:
> "
> There are mutual benefits to the ISP (acting as an Access CDN), "
> 
> 
> *** section 2.3:
> replace:
> "
> s/who move between CDNs/who move between access networks/ s/moving 
> between different CDN Providers/moving between different access 
> networks/
> 
> *** section 2.4:
> replace:
> "
> which may reside
> "
> with:
> "
> which may be located
> "
> 
> *** section 2.4:"
> acquisition from alternate origin servers when acquisition failures occur.  When normal content acquisition fails, a CDN may need to try other origin server options, "
> with:
> "
> acquisition from alternate content sources when acquisition failures occur.  When normal content acquisition fails, a CDN may need to try other content source options, "
> (I believe everywhere else we use "origin server" to refer to the OS 
> of the CSP and "content source" as the generic term for getting 
> content including origin server and uCDN)
> 
> *** section 3.2.2:
> replace:
> "
> An important aspect of the above use cases "
> with:
> "
> An important aspect common to all the above use cases "
> 
> 
> 618, but no explicit reference was found in the text I'd suggest you add an explicit reference. For example, in "1.  Introduction" you could replace:
> "

---

From: "Dave Oran (oran)" <[email-masked]>
Date: Mon, 14 May 2012 13:01:47 +0000

> IMO, the term "delivering CDN" is immediately understandable: considering a given request, the delivering CDN is the one that delivers the requested content to the end-user. By contrast, I find the…
Movies with Arnold Schwarzenegger.

Sorry, couldn't resist... :-)

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 15 May 2012 01:37:02 +0100

> We can always avoid defining terms and concepts, at the price of redundant explanations in the drafts. 

Indeed. I guess I'm not convinced we're going to need to refer to "access CDNs" as a special case of a CDN very much. If we do decide we need the term I think the definition needs to be more precise about what exactly constitutes an access CDN versus some other kind of CDN.

> IMO, the term "delivering CDN" is immediately understandable: considering a given request, the delivering CDN is the one that delivers the requested content to the end-user. By contrast, I find the…

I was thinking it terminated the chain of CDNs performing the delivery. We can call it something else (final CDN, ultimate CDN, I'm sure others can think of more) I just think using/overloading "delivering" when we're going to be talking about delivering content in a number of different contexts is likely to cause confusion.

Ben

---

From: <[email-masked]>
Date: Wed, 16 May 2012 11:25:11 +0200

Hi Ben,

Maybe we should keep the term Access CDN in the use cases draft then, and move only the definition of the "Delivering" CDN into the problem statement.

We will clarify the definition of Access CDN.

Best regards,

Gilles

-----Message d'origine-----
Envoyé : mardi 15 mai 2012 02:37

Ben

> De : Ben Niven-Jenkins [mailto:[email-masked]] Envoyé : lundi 
> 14 mai 2012 05:19 À : BERTRAND Gilles RD-CORE-ISS Cc : 
> [email-masked]; [email-masked]; [email-masked] Objet : Re: 
> [CDNi] Document Sheperd review of draft-ietf-cdni-use-cases
> 
> 
>> *** section 8 security considerations I have a few specific issues 
>> with the current text of the Security Considerations section. But I don't really see the need to have an expanded Security Considerations section in both the use-case document and the problem-statement (particularly considering that the first IESG review comments on problem-statement suggest expanding the security considerations section there), in particular because the security considerations currently brought up in use-cases are not specific to individual use cases bur rather generic to the whole CDN interconnection problem space.
>> would be handled by CDN-B, which is typically not the case i.e. only 
>> a subset of the requests are redirected thy CDN-A to CDN-B)
>> 
>> 
>> *** section 1.3:
>> replace:
>> "

---

From: Francois Le Faucheur <[email-masked]>
Date: Wed, 16 May 2012 11:38:47 -0400

Gilles, Ben, Larry,

On 16 May 2012, at 05:25, <[email-masked]> <[email-masked]> wrote:

> Hi Ben,
> 
> Maybe we should keep the term Access CDN in the use cases draft then,

I support that.

> and move only the definition of the "Delivering" CDN into the problem statement.

Actually, let's have this term included in the Framework I-D rather (the problem statement has been posted already and does not actually need that definition).

Thanks

Francois

---

From: Francois Le Faucheur <[email-masked]>
Date: Thu, 17 May 2012 02:16:22 +0200

Larry and all,

My understanding is that:
	* problem-statement includes a set of "core" definitions. 
	* framework will be cleaned up to refer to problem-statement for all the "core" definitions (and not redefine them)
	* framework will include the additional definitions of general interest to the working group. I believe there are a few already in framework in that category. 
	* I think we are converging that:
		* "Delivering CDN" fits in the category of additional definitions to be included in the framework
		* "Access CDN" does not fit that category and shoudl not be introduced in framework.

If folks (in particular authors of other documents) feel that they have definitions that shoudl go into framework, please indicate so on the list.

Thanks

Francois

---

From: "Deventer, M.O. (Oskar) van" <[email-masked]>
Date: Thu, 31 May 2012 14:22:34 +0000

Dear Larry and Francois,

> various docs have introduced recently, and converge on the core 
CDNi terminology is also under development by the ETSI CDNi activity ([email-masked]). So while we are harmonizing terminology between IETF documents, we should also consider the relevant ETSI documents.

These are the relevant ETSI document:
Use cases and requirements: http://docbox.etsi.org/MCD/Open/Latest_Drafts/cdn-i013v0011.pdf
Architecture and information flows: http://docbox.etsi.org/TISPAN/Open/NGN_LATEST_DRAFTS/RELEASE_INDEPENDENT/02086_ts182032_cdn-i_architecture_v004.pdf

Here is an initial analysis of CDNi terminology and approaches by ETSI and IETF.

-The terms "distribution" and "delivery" seem to consistent between ETSI and IETF. The first term is intra- and inter-CDN, whereas the second term is about delivery to a user agent.

-There may to be an inconsistency between the IETF and ETSI definitions of Upstream CDN and Downstream CDN. The IETF Problem Statement defines these in terms of redirection (upstream redirects to downstream). ETSI defines these in terms of distribution (upstream closer to Content Provider, downstream closer to Consumer). Especially in case of HAS content, there may be no redirection for individual chunks (segments, fragments), whereas we would still consider the chunk-delivering-CDN the "downstream CDN". Would this require a refinement of the IETF definition?

-Unlike ETSI, IETF has no terminology for segmented content yet. This is work in progress on http://tools.ietf.org/id/draft-brandenburg-cdni-has-00.txt, and we are trying to remain aligned.

-The IETF Framework document defines four interfaces (or five, if one counts the moving-of-content), whereas ETSI has only two (or three, if one counts ...). These are the ETSI ones:
   -Interconnection Control: ... is used for controlling interconnection peer and transferred over this point information related to CDN capabilities and status, including footprint exchange, capability exchange, interconnection status reporting and network usage/performance logging.
   -Request Routing and Content Control: ... is used for requesting content and to transfer content related information, including content metadata exchange, content requests and content status reporting.
The reason for having only two interfaces is that having more interfaces than needed takes unnecessary implementation complexity and additional configuration and management effort. Can you tell me why IETF CDNi has four interfaces, and why two is not enough?

-IETF has a rather loose definition of Content: "Any form of digital data [including] continuous media."
ETSI has a more strict and CDNi-functional definition of Content Item: "A uniquely addressable content element in a CDN. A content item is defined by the fact that it has its own Content Metadata associated with it. It is the object of content distribution and request routing operations in a CDN. Example of Content Items are a video file/ stream, an audio file/stream, an image file or segmented content together with an associated manifest file."
Would it make sense to add this definition of "Content Item" to the Problem Statement or Framework documents?

-ETSI distinguishes logging ("recording event ...") from reporting ("providing access to recorded events ..."). This includes the possibility that the dCDN processes the logged information, e.g. into a standardized, possibly aggregated format. IETF uses only the term logging. Does this preclude reporting processed logging information between CDNs?

Depending on the response to this analysis, I would be happy to draft some refined definitions. Thank you.

Best regards,

Oskar

ETSI rapporteur on CDNi work items

Dr. ir. M.O. (Oskar) van Deventer
TNO - Innovation for Life
Senior Scientist Media Networking
Media & Network Services
T +31 (0)88 866 70 78
M +31 (0)65 191 49 18
E [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur
Sent: Thursday, 17 May, 2012 02:16
To: Peterson, Larry
Cc: [email-masked]
Subject: Re: [CDNi] Two additional definitions for cdni-framework

Larry and all,

Thanks

Francois

>>> *** Unused Reference: 'I-D.ietf-cdni-requirements' is defined on 
>>> line 618, but no explicit reference was found in the text I'd suggest you add an explicit reference. For example, in "1.  Introduction" you could replace:
>>> "

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni
This e-mail and its contents are subject to the DISCLAIMER at http://www.tno.nl/emaildisclaimer