Subject: [CDNi] Working Group Last Call on draft-ietf-cdni-problem-statement-01

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 6 Dec 2011 19:57:53 +0100

All,

This is the start of a two-week working group last call on draft-ietf-cdni-problem-statement-01.txt:
http://tools.ietf.org/html/draft-ietf-cdni-problem-statement

This working group last call will end 20 Dec 2011. Please send your comments to the CDNI mailing list.

Francois & Rich

On 18 Nov 2011, at 01:06, Francois Le Faucheur wrote:

> Hello,
> 
> There was clear support at the IETF-82 CDNI meeting to progress draft-ietf-cdni-problem-statement-01 to working group Last Call. We will do so in a week or so unless we hear opposition on the list.
> 
> Cheers
> 
> Francois & Rich
> 
> 
> _______________________________________________
> CDNi mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cdni

---

From: Francois Le Faucheur <[email-masked]>
Date: Mon, 26 Dec 2011 12:31:56 +0100

Folks,
We have not received much comments on the Problem Statement. To make sure everyone has the chance to review the document despite the holiday break, we'll extend the WG Last Call by two weeks ie till 3 January 2012.
Cheers
Francois & Rich

---

From: Francois Le Faucheur <[email-masked]>
Date: Tue, 27 Dec 2011 15:13:04 +0100

Hello,

Below are the detailed comments from my review of draft-ietf-cdni-problem-statement-01.
They are split into:
	* Comments (which do, or may, entail some change in intended meaning)
	* Terminology (some of them potentially affecting working group terminology beyond this single document)
	* Editorials
I'd like these comments to be addressed, but in general I think the document is in a very good shape to move forward.

Francois

COMMENTS
==========

*** in section 1:
OLD:
"However, the footprint of a given CDN in charge of
   delivering a given content may not expand close enough to the End
   User's current location or attachment network to realize the cost
   benefit and user experience that a more distributed CDN would
   provide.
"
NEW:
"
However, a given CDN in charge of
   delivering a given content may not have a footprint that expands close enough to the End
   User's current location or attachment network, or may not have the necessary resources, to realize the user experience and cost
   benefit that a more distributed CDN infrastructure would allow.
"

*** section 1:
OLD:
"
This creates a requirement for interconnecting standalone
   CDNs so that their collective CDN footprint can be leveraged for the
   end-to-end delivery of content from Content Service Providers (CSPs)
   to End Users.
"
NEW:
"
This creates a requirement for interconnecting standalone
   CDNs so that their collective CDN footprint and resources can be leveraged for the
   end-to-end delivery of content from Content Service Providers (CSPs)
   to End Users.
"

*** section 1 and section 5:
I find the term "gap analysis" in section 5 title somewhat misleading since it might suggest that other standards organization already address the problem and the remaining work is to fill in a few gaps, while the situation is that the problem is not addressed but we want to investigate whether some related work of other standards organization could be leveraged. Hence:
OLD:
"
5.  Gap Analysis of relevant Standardization Activities
"
NEW:
"
5.  Relevant Work from Other Standardization Activities
"

OLD:
"
Section 5 provides a gap analysis against the
   work of other standards organizations.
"
NEW:
"
Section 5 discusses the relevant work of other standards organizations.
"

*** section 1.1:
We may want to provide a "positive" definition rather than a "negative" definition for dynamic acquisition. Hence:
OLD:
"
Dynamic content acquisition: Dynamic content acquisition is where a
   CDN acquires content from the content source in response to an End
   User requesting that content from the CDN.  In the context of CDN
   Interconnection, dynamic acquisition means that a downstream CDN does
   not acquire the content from content sources (including upstream
   CDNs) until a request for that content has been delegated to the
   downstream CDN by an Upstream CDN.
"
NEW:
"
Dynamic content acquisition: Dynamic content acquisition is where a
   CDN acquires content from the content source in response to an End
   User requesting that content from the CDN.  In the context of CDN
   Interconnection, dynamic acquisition means that a downstream CDN acquires the content from content sources (including upstream
   CDNs) at the time when a request for that content is delegated to the
   downstream CDN by an Upstream CDN (and that specific content is not yet available in the downstream CDN).
"

OLD:
"
Dynamic CDNI metadata acquisition: In the context of CDN
   Interconnection, dynamic CDNI metadata acquisition means that a
   downstream CDN does not acquire CDNI metadata for content from the
   upstream CDN until a request for that content has been delegated to
   the downstream CDN by an Upstream CDN.
"
NEW:
"
Dynamic CDNI metadata acquisition: In the context of CDN
   Interconnection, dynamic CDNI metadata acquisition means that a
   downstream CDN acquires CDNI metadata for content from the
   upstream CDN at the time when a request for that content is delegated to
   the downstream CDN by an Upstream CDN (and that specific CDNI metadata is not yet available in the downstream CDN).
"

*** section 4.2:
Regarding:
"
   o  Search for CDNI Metadata records where the downstream CDN does not
      know the specific Metadata record(s) it requires but does know
      some property of the record it is searching for.  For example, it
      may know the value of the HTTP Host header received in a HTTP
      request and it wants to obtain the CDNI Metadata for that host so
      that it can determine how to further process the received HTTP
      request.
"
I think the word "Search" (and some of the text) is somewhat misleading as it may suggest there is a need for some specific "search" functionality. I think what is likely required from the interface is the ability to access subset of metadata information and do recursive requests (ie walk down a tree).
So how about:
OLD:
"
  o  Make direct requests for CDNI Metadata records where the
      downstream CDN knows the identity of the Metadata record(s) it
      requires.
   o  Search for CDNI Metadata records where the downstream CDN does not
      know the specific Metadata record(s) it requires but does know
      some property of the record it is searching for.  For example, it
      may know the value of the HTTP Host header received in a HTTP
      request and it wants to obtain the CDNI Metadata for that host so
      that it can determine how to further process the received HTTP
      request.
"
NEW:
"
  o  Make direct requests for CDNI Metadata records
  o  Make recursive requests for CDNI metadata so as to walk down a tree of records with inter-record relationships.
"

section 3:
regarding:
" As part of the development of the CDNI interfaces and solutions it
   will also be necessary to agree on common mechanisms for how to
   identify and name the data objects that are to be interchanged
   between interconnected CDNs, as well as how to describe which policy
   should be used when doing so.
"
I don't quite get the meaning/value of the last part of the sentence (ie "as well as how to describe which policy should be used when doing so". 
Should we just remove this last part of the sentence?
If not, can it be clarified:
	* do we really need to specify how to "describe policies that are to be used when exchanging data objects"? 
	* are those really "policies"? or are they "procedures" defining the exchange?

*** section 4.1:
Some of the text of section 4.1 is possibly a little more detailed/prescriptive than really needed here. I think it is fine as long as we make it slightly clearer that all of this is "expectation/examples" and not intended to be prescriptive). Hence the few following minor changes:
OLD:
"
but at a minimum would need to contain
"
NEW:
"
but at a minimum is expected to include
"

OLD:
"
a Redirection Response from the downstream CDN needs to contain
"
NEW:
"
a Redirection Response from the downstream CDN is expected to contain
"

*** section 4.1:
OLD:
"
this is expected to include the application specific redirection response(s) to return to the requesting User Agent.
"
NEW:
"
this is expected to include the information necessary to construct the application specific redirection response(s) to return to the requesting User Agent.
"

*** section 4.1:
OLD:
"
this could be in the form of a URI that the upstream CDN could return in a HTTP 302 response.
"
NEW:
"
this could include a URI that the upstream CDN could return in a HTTP 3xx response.
"

*** section 4.3:
I am concerned that the phrases of "content Start/Pause/Stop" may suggest that the CDN needs to be aware of Video Player level actions initiated by the end-user (ie Pause), so I suggest to tweak text to avoid this confusion. Possibly: 
OLD:
"
   o  Real-time or near-real time events before, during or after content
      delivery, e.g. content Start/Pause/Stop events, etc.
"
NEW:
"
   o  Real-time or near-real time events before, during or after content
      delivery, e.g. content delivery interruption.
"

*** section 5:
OLD:
"
Although OIPF and ATIS specifications include the
      interaction with a CDN, the CDN specifications are coupled with
      their IPTV specifications.
"
NEW:
"
Although OIPF and ATIS IIF specifications include the
      interaction with a CDN, the CDN specifications are coupled with
      their IPTV specifications and do not cover interconnection of CDNs.
"

*** section 5:
I recommend we add a statement about ATIS CSF and relationship to IETF CDNI. I'd suggest, adding one bullet for ATIS CSF , after the 2nd bullet (that discusses OIPF and ATIS IIF) along the lines of:
NEW:
"
ATIS Cloud Service Forum (CSF) concerns itself with the interconnection of CDNs. The ATIS CSF focuses on defining use cases and requirements for such CDN interconnection, which are expected to be considered as input into the work of the CDNI WG. At the time of writing this document, ATIS CSF is not specifying the corresponding protocols or interfaces and is expected to leverage the work of the IETF CDNI working group for those. 
"

*** section 6.1:
regarding:
"
and [I-D.penno-alto-cdn] discusses
   how CDN Request Routing could be used as an integration point of ALTO
   into CDNs.
"
[I-D.penno-alto-cdn] is now expired and I have the impression that [I-D.jenkins-alto-cdn-use-cases]  also introduces how a CDN Request Routing system could take advantage of an ALTO service. So perhaps the sentence could be rewritten using a single refer to [I-D.jenkins-alto-cdn-use-cases] .

TERMINOLOGY
============

*** throughout the document:
In the problem statement, Metadata elements are referred to as "records". However, in all the Metadata I-Ds, those are referred to as "Metadata objects". I think we should align terminology. I don't feel very strongly one way or the other, but since all the Metadata I-Ds use "objects" it may be simpler to replace "records" in the PS with "objects" also.

***
I suggest we rename "CDN Provider" into something like "Delivery Service Provider (DSP)" (or "Content Delivery Service Provider (CDSP)") on the grounds that such entity provides a service of content delivery as opposed to providing a "CDN". It would line up well with the other terms of "Network Service Provider (NSP)" and "Content Service Provider (CSP)". 
This would require:
	* replacing all occurrences of "CDN Provider" with "DSP"
	* changing the corresponding definition in the Terminology section i.e.
OLD:
"
CDN Provider: The service provider who operates a CDN.  Note that a
   given entity may operate in more than one role.  For example, a
   company may simultaneously operate as a Content Service Provider, a
   Network Service Provider and a CDN Provider.
"
NEW
"
Delivery Service Provider (DSP): The service provider who operates a CDN and offers a service of content delivery, typically used by a Content Service Provider or another Delivery Service Provider. Note that a given entity may operate in more than one role.  For example, a company may simultaneously operate as a Content Service Provider, a Delivery Service Provider and a Network Service Provider.
"

*** section 1:
The term "CDN" is sometimes used inappropriately when referring to the "Delivery Service Provider (DSP)"  (formerly "CDN Provider"). They have separate definitions in the terminology section and we need to use the appropraite term in all occurences. For example:
OLD:
"
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.
"
NEW:
"
For example, a CSP could contract with an
   "authoritative" DSP for the delivery of content and that
   authoritative DSP could contract with one or more downstream DSP
   to distribute and deliver some or all of the content on behalf of the
   authoritative DSP.  The formation and details of any business
   relationships between a CSP and a DSP and between one DSP and another
   DSP are out of scope of this document. However, no standards or open
   specifications currently exist to facilitate the corresponding necessary interconnection of the DSP CDNs.
"

*** section 1.1:
In line with earlier comment:
OLD:
"
 Authoritative CDN: A CDN which has a direct relationship with a CSP
   for the distribution & delivery of that CSP's content.
"
NEW:
"
 Authoritative DSP: A Delivery Service Provider which operates a CDN and has a direct relationship with a CSP
   for the distribution & delivery of that CSP's content.
"

*** section 1.1:
In line with earlier comment:
OLD:
"
Over-the-top (OTT): A service, e.g. a CDN, operated by a different
   operator than the NSP to which the users of that service are
   attached.
"
NEW:
"
Over-the-top (OTT): A service, e.g. a delivery service, operated by a different
   operator than the NSP to which the users of that service are
   attached.
"

*** section 3/ Figure 1:
OLD:
"
Upstream CDN
"
NEW:
"
Authoritative DSP: 
Upstream CDN
"

OLD:
"
Downstream CDN
"
NEW:
"
DSP: 
Downstream CDN
"

*** section 1.1:
The document has a definition for the Request Routing System, for the Distribution System and for the Logging System of CDNs, but it does not have a definition for the Control System which is referred to multiple times. I think we need to add something like:
NEW:
" 
Control System: The function within a CDN responsible for bootstrapping and controlling the other components of the CDN as well as for handling interactions with external systems (e.g. such as for handling delivery service creation/update/removal requests, or handling specific service provisioning requests).
"

EDITORIALS
==========

*** throughout the document:
OLD:
"
CDNI WG
"
NEW:
"
CDNI working group
"

*** In Abstract and in section 1:
OLD:
"
The goal of this document is to outline the problem area of CDN
   interconnection (CDNI) for the IETF.
"
NEW:
"
The goal of this document is to outline the problem area of CDN
   interconnection for the IETF CDNI (CDN Interconnection) working group.
"

*** section 1:
OLD:
"
that could considered
"
NEW:
"
that could be considered
"

*** everywhere in the document (eg section 2 title):
OLD:
"
CDN Interconnect
"
NEW:
"
CDN Interconnection
"

*** section 1.1:
should the defined terms be ordered by alphabetical order?

*** section 1.1:
OLD:
"
(and therefore needs
" 
NEW:
"
(and therefore need
" 

*** section 1.1:
OLD:
"
Metadata that is associated with the actual Content (and not
       directly relevant to the distribution of that Content) or content
       representation.
"
NEW:
"
Metadata that is associated with the actual Content or content
       representation, and not directly relevant to the distribution of that Content. 
"

*** section 1.1:
OLD:
"
with additional constraints on Distribution and Delivery
"
NEW:
"
with additional constraints on distribution and delivery
"

*** section 1.1:
OLD:
"
acquires content from the content source prior to or independent of any End User requesting
"
NEW:
"
acquires content from the content source prior to, or independently of, any End User requesting
"

OLD:
"
acquires CDNI metadata for content prior to or independent of any End User requesting
"
NEW:
"
acquires CDNI metadata for content prior to, or independently of, any End User requesting
"

*** section 1.1:
OLD:
"
wider than just the delivery of items of Content
"
NEW:
"
wider than just providing access to items of Content
"
(this is in order to better distinguish the role of the CSP that foremost is to provide access to the content itself, versus the role of the DSP that is to "deliver" the content)

OLD:
"
which may not require any direct interaction with the CDN.
"
NEW:
"
which may not require any direct interaction with the CDN, or CDNs, involved in the distribution and delivery of the content.
"

*** section 2.
This section is intended to identify the CDNI use cases. I think it would read better if those are explicitly flagged.

OLD:
"
As they evolve their services (e.g. for seamless support of
   content services to nomadic users across affiliate NSPs) there is a
   need for interconnection of these CDNs.
"
NEW:
"
As they evolve their services (e.g. for seamless support of
   content services to nomadic users across affiliate NSPs) there is a
   need for interconnection of these CDNs, that represents a first use case for CDNI.
"

OLD:
"
Some
   NSPs are considering interconnecting their respective CDNs (as well
   as possibly over-the-top CDNs) so that this collective infrastructure
   can address the requirements of CSPs in a cost effective manner. 
"
NEW:
"
Some
   NSPs are considering interconnecting their respective CDNs (as well
   as possibly over-the-top CDNs) so that this collective infrastructure
   can address the requirements of CSPs in a cost effective manner. This represents a second use case for CDNI.
"

OLD:
"
As NSPs integrate
   their service portfolio, there is a need for interconnecting these
   CDNs.
"
NEW:
"
As NSPs integrate
   their service portfolio, there is a need for interconnecting these
   CDNs, that represent a third use case for CDNI.
"

OLD:
"
For operational reasons (e.g. disaster, flash crowd) or commercial
   reasons, an over-the-top CDN may elect to make use of another CDN
   (e.g. an NSP CDN with on-net Surrogates for a given footprint) for
   serving a subset of the user requests (e.g. requests from users
   attached to that NSP).
"
NEW:
"
"
For operational reasons (e.g. disaster, flash crowd) or commercial
   reasons, an over-the-top CDN may elect to make use of another CDN
   (e.g. an NSP CDN with on-net Surrogates for a given footprint) for
   serving a subset of the user requests (e.g. requests from users
   attached to that NSP), which results in a fourth use case for CDNI.
" 

OLD:
"
Figure 1: CDNI Problem Area
"
NEW:
"
Figure 1: CDNI Model
"

section 3:
OLD:
"
by a potential CDNI working group
"
NEW:
"
by the CDNI working group
"

section 3:
OLD:
"
The acquisition of content between interconnected CDNs is out of
   scope for CDNI and deserves some additional explanation.
"
NEW:
"
As illustrated in Figure 1, the acquisition of content between interconnected CDNs is considered out of
   scope for CDNI, which deserves some additional explanation.
"

*** section 4 title:
OLD:
"
Design Approach for Realizing the CDNI APIs  
"
NEW:
"
Design Approach for Realizing the CDNI Interfaces  
"

*** section 4:
OLD:
"
that could considered for reuse
"
NEW:
"
that could be considered for reuse
"

*** section 4:
OLD:
"
to solve CDNI 
"
NEW:
"
to realize the CDNI interfaces
"

*** section 4:
OLD:
"
Since it is not expected that these interfaces would exhibit unique session,
"
NEW:
"
Firstly, since it is not expected that these interfaces would exhibit unique session,
"

*** section 4:
OLD:
"
Although a new application protocol could be designed
"
NEW:
"
Secondly, although a new application protocol could be designed
"

*** section 4:
OLD:
"
The CDNI Request Routing interface needs to offer a mechanism
"
NEW:
"
Therefore, the CDNI Request Routing interface needs to offer a mechanism
"

*** section 4.1:
OLD:
"
without first receiving a Redirection Request from an upstream CDN,
"
NEW:
"
without first receiving a Redirection Request from an upstream CDN for the corresponding user request,
"

*** section 4.1:
OLD:
"
Some CDNs may want broader policies,
"
NEW:
"
Some CDNs may rely on simple coarse policies,
"

*** section 4.1:
OLD:
"
CDN B agrees to always take 
"
NEW:
"
CDN B agrees to always serve
"

*** section 4.2:
in order to be consistent with the terminology of section 1.1:
OLD:
"
The CDNI Metadata interface enables the Metadata function in a downstream CDN 
"
NEW:
"
The CDNI Metadata interface enables the Distribution System function in a downstream CDN 
"

*** section 4.2:
OLD:
"
The CDNI Metadata interface needs to offer a mechanism for an
   Upstream CDN to:
   o  Distribute/update/remove CDNI Metadata to a Downstream CDN.
"
NEW:
"
The CDNI Metadata interface needs to offer a mechanism for an
   Upstream CDN to:

   o  Distribute/update/remove CDNI Metadata to a Downstream CDN.
"

*** section 4.3:
OLD:
"
Such use cases place requirements on the CDNI Logging interface
"
NEW:
"
Such applications place requirements on the CDNI Logging interface
"

*** section 4.4
OLD:
"
The CDNI Control interface allows the "CDNI Control" system in interconnected CDNs
"
NEW:
"
The CDNI Control interface allows the Control System in interconnected CDNs
"

*** section 5:
OLD:
"
that could potentially be reused by CDNI.
"
NEW:
"
that could potentially be reused to realize the CDNI interfaces.
"

*** section 5:
OLD:
"
TISPAN has a dedicated specification for CDN.
"
NEW:
"
ETSI TISPAN (Telecommunications and Internet converged Services and Protocols for Advanced Networking) has a series of specifications focusing on CDN.
"

*** section 5:
OLD:
"
   o  OIPF and ATIS specify the architecture and the protocols of an IPTV solution.
"
NEW:
"
   o  The Open IPTV Forum (OIPF) and ATIS IPTV Interoperability Forum (IIF) specify the architecture and the protocols of an IPTV solution.
"

*** section 5:
OLD:
"
   o  CableLabs, SNIA and ITU have defined (or are working on)
      definitions for content related metadata definitions and
      specification for its distribution.
"
NEW:
"
   o  CableLabs, SNIA and ITU have developed (or are working on)
      definitions for content related metadata and
      specification for its distribution.
"

*** section 5.1:
OLD:
"
   TISPAN, OIPF and ATIS have specified IPTV and/or CoD services,
"
NEW:
"
   TISPAN, OIPF and ATIS IIF have specified IPTV and/or Content on Demand (CoD) services,
"

*** section 5.1:
OLD:
"
   o  The ATIS specification "IPTV Content on Demand (CoD) Service"
"
NEW:
"
   o  The ATIS IIF specification "IPTV Content on Demand (CoD) Service"
"

*** section 5.1:
OLD:
"
(or at least sufficiently addressed in other forums
"
NEW:
"
(or at least sufficiently addressed in other forums).
"

*** section 5.1:
OLD:
"
are out of scope for CDNI. CDNI may only concern itself 
"
NEW:
"
are out of the scope of the CDNI working group. The CDNI working group need only concern itself 
"

*** section 6.1:
OLD:
"
However, the work of ALTO is complementary to and does not overlap
"
NEW:
"
However, the current work of ALTO is complementary to and does not overlap
"

*** throughout the document:
OLD:
"
 [_3GP-DASH]
"
NEW:
"
 [3GP-DASH]
"