Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 8 Apr 2013 18:54:04 +0000

Hi Francois. Thanks for the thorough review. I'll incorporate your feedback. Just a few comments and clarification questions below. I should be able to publish the draft in a few days.

-----Original Message-----
From: Francois Le Faucheur (flefauch) 
Sent: Saturday, March 30, 2013 2:50 AM
To: Kent Leung (kleung)
Cc: [email-masked]
Subject: Comments on draft-ietf-cdni-requirements-05.txt

Hi Kent and all,

In addition to the comment already discussed below, here are my remaining comments (as an Individual):

OLD:
"
 GEN-4   [HIGH] The CDNI solution shall not require intra-CDN
           information ...
"
NEW:
"
 GEN-4   [HIGH] The CDNI solution shall not depend on intra-CDN
           information ...
"

KL> ok

OLD:
"
GEN-5   [HIGH] The CDNI solution shall support delivery to the user
           agent based on HTTP [RFC2616].  (Note that while delivery and
           acquisition "data plane" protocols are out of the CDNI
           solution scope, the CDNI solution "control plane" protocols
           are expected to participate in enabling, selecting or
           facilitating operations of such acquisition and delivery
           protocols.  Hence it is useful to state requirements on the
           CDNI solution in terms of which acquisition and delivery
           protocols).

GEN-6   [HIGH] The CDNI solution shall support acquisition across
           CDNs based on HTTP [RFC2616].
"
NEW:
"
GEN-5   [HIGH] The CDNI solution shall support delivery to the user
           agent based on HTTP [RFC2616].  

GEN-6   [HIGH] The CDNI solution shall support acquisition across
           CDNs based on HTTP [RFC2616].

(Note that while delivery and acquisition "data plane" protocols are out of the CDNI solution scope, the CDNI solution "control plane" protocols are expected to participate in enabling, selecting or facilitating operations of such acquisition and delivery protocols.  Hence it is useful to state requirements on the CDNI solution in terms of which acquisition and delivery protocols).
"
(Rationale: the note applies to both GEN-5 and GEN-6)

KL> ok. I've kept the note for GEN-5 and added " (The note above applies to this requirement too)" to GEN-6. Formatting remains consistent this way.

Regarding:
"
GEN-13  Removed.
"
I suggest you just remove altogether the requirements that were dropped and renumber the following ones to avoid gaps.

KL> ok. It was better to keep all the requirement numbers for discussions (i.e. clear reference) up to this point. Now we are ready for last call. We'll clean up all the removed requirements. This means the authors of the interface drafts need to update their references to the requirements draft. I can create a mapping of the numbering changes between ver -05 to -06 if that's helpful. What do you think?

Regarding:
"
CNTL-1   [HIGH] The CDNI Control interface shall allow the Upstream
            CDN to request that the Downstream CDN (and, if cascaded
            CDNs are supported by the solution, that the potential
            cascaded Downstream CDNs) perform the following actions on
            an object or object set:

            *   Mark an object or set of objects and/or its CDNI
                metadata as "stale" and revalidate them before they are
                delivered again

            *   Delete an object or set of objects and/or its CDNI
                metadata from the CDN surrogates and any storage.  Only
                the object(s) and CDNI metadata that pertain to the
                requesting Upstream CDN are allowed to be purged.
"
It is clear to me that the 2nd bullet is a [HIGH]. 
But it is not clear to me that the first bullet is really a [HIGH]. I see it as an optimisation, not a must-have. I'd rate it as a [MID] or [LOW]. In fact, does the "triggers" interface actually cope for that ?
Perhaps you can split the two bullets so they can have a different priority level.

KL> ok.  It's better to split the bullets and prioritize differently. The current triggers interface deals with delete only, AFAIK.

Regarding:
"
  CNTL-3   [HIGH] The CDNI Control interface shall support initiation
            and control by the Upstream CDN of pre-positioned CDNI
            metadata acquisition by the Downstream CDN.
"
I thought we have agreed that pre-positioning would be a [MED] whether content or metadata. CNTL-4 is already a [MED]. I suggest making CNTL-3 a [MED] also.

KL> ok. 

Regarding:
"
CNTL-10  [LOW] The CDNI Control interface may allow exchange and
            negotiation of delivery authorization mechanisms to be
            supported across the CDNs (e.g.  URI signature based
            validation).
"
This functionality has moved to the FCI. How about, you move this functionality with the rest of the text discussing the FCI requirements?

KL> ok

Regarding:
"
CNTL-12  [MED] The CDNI Control interface should allow for multiple
            content items identified by a Content Collection ID to be
            purged using a single Content Purge action.
"
I suggest moving this requirement up so it follows the first purge-related requirements i.e. place it right after CNTL-1.

KL> ok

Regarding Section 5:
I strongly recommend that:
	* you split this into separate sections for RI and FCI. 
	* in each requirement, you mention the actual interface (i.e. RI or FCI) instead of "the Request Routing Interface".
It will make it much easier to read, and much more useful so we know which requirements applies to which interface.

KL> ok. Requirements will be renamed to RI-# and FCI-#. (note to self: TODO)

Regarding REQ-15 and "[Ed: chunk is treated as any content, is this needed?]"
I vote for keeping it in. Explicit is better. 

KL> ok

Regarding REQ-16 and REQ-17: I vote for [LOW]. I see Manifest-file-Manipulation approaches as nice-to-allow but not [MED].

KL> ok

Regarding REQ-19: it is a [MED] but you use "may". I think it shoudl say "should" for a [MED].
BTW: at the very end of editing , you should probably do a pass and check the shall/should/may correspond to HIGH/MED/LOW in each and every requirement. e.g. there is also a mismatch in REQ-20.

KL> ok (note to self: TODO)

Regarding REQ-20:
The list of capabilities here is a little out of date (e.g. "support for customised CDNI logging" - which is dropped) and only covers the ones related to logging while it shoudl bring up the other ones (e.g. delivery protocol). Since the actual capabilities are discussed in the FCI semantics draft, I would suggest not trying to list specific capabilities in that requirement, and instead keep it high level and probably just list the types of capabilities (e.g. mention it needs to cover capabilities associated with logging, with distribution protocols, with acquisition protocols, etc..)

KL> ok

OLD:
"
META-7   [HIGH] The CDNI Metadata Distribution interface shall allow
            the Upstream CDN to request addition and modification of
            CDNI Metadata into the Downstream CDN.
"
NEW:
"
META-7   [HIGH] The CDNI Metadata Distribution interface (possibly in conjunction with the CDNI Control interface) shall allow
            the Upstream CDN to request addition and modification of
            CDNI Metadata into the Downstream CDN.
"

KL> ok

OLD:
"
META-8   [HIGH] The CDNI Metadata Distribution interface shall allow
            removal of obsolete CDNI Metadata from the Downstream CDN
            (this could, for example, be achieved via an explicit
            removal request from the Upstream CDN or via expiration of a
            Time-To-Live associated to the Metadata).
"
NEW:
"
META-8   [HIGH] The CDNI Metadata Distribution interface (possibly in conjunction with the CDNI Control interface) shall allow
            removal of obsolete CDNI Metadata from the Downstream CDN
            (this could, for example, be achieved via an explicit
            removal request from the Upstream CDN or via expiration of a
            Time-To-Live associated to the Metadata).
"

KL> ok

OLD:
"
META-15  [HIGH] The CDNI Metadata interface shall be able to exchange
            a set of well-accepted metadata elements with specified
            semantics (e.g. start of time window, end of time window).
"
NEW:
"
META-15  [HIGH] The CDNI Metadata interface shall be able to exchange
            a set of metadata elements with specified
            semantics (e.g. start of time window, end of time window).
"

KL> ok

Regarding META-18: see thread below.

KL> The thread below is about logging customization and directional logging. Not clear about relationship to this requirement?

Regarding META-20: As documented in http://www.ietf.org/mail-archive/web/cdni/current/msg01375.html, it is felt that this requirement shoudl not be pursued for initial deliverables. Besides, there was no hard conclusion as to whether this would belong to MI or CI. This requirement should be a [MED] (instead of a [HIGH]) and I suggest you add a note indicating that there is still some thinking to be done to conclude whether this should really be MI or CI.

KL> ok

OLD:
"
LOG-1   [HIGH] The CDNI logging architecture and interface shall
           ensure reliable logging of CDNI events.
"
NEW:
"
LOG-1   [HIGH] The CDNI logging architecture and interface shall
           ensure reliable transfer of CDNI logging information across CDNs.
"

KL> ok

OLD:
"
LOG-7   [HIGH] The CDNI Logging interface shall define a log file
           format and a set of fields to be exported through the Logging
           protocol, with some granularity (e.g.  On a per content type
           basis).
"
NEW:
"
LOG-7   [HIGH] The CDNI Logging interface shall define a log file
           format and a set of fields to be exported for various CDNI logging events.
"

KL> ok

re LOG-8:
s/mechanisms/mechanism/

re LOG-14:
This requirement should be removed since it is already covered by another requirement on the CI.

KL> ok

OLD:
"
LOG-17  [HIGH] The CDNI Logging interface shall support the
           notification from Downstream CDN to Upstream CDN for the
           event that the logging retention duration or maximum size of
           logging data has exceeded.
"
NEW:
"
LOG-17  [HIGH] The CDNI Logging interface shall allow a CDN to notify another CDN about which CDNI logging information is available for transfer (and/or no longer available, say because it exceeded some logging retention period or some logging retention volume).
"
Rationale: The current wording was overly prescriptive. I think the key point is that the CDNs should inform each other about which info can be obtained. 

KL> ok

OLD:
"
LOG-18  [MED] The CDNI Logging interface should support the ability
           for the Downstream CDN to include the Content Collection ID
           and Session ID fields in CDNI log entries generated for HTTP
           Adaptive Streaming content.  This fields can be supported by
           the "customizable" log format which is expected to be defined
           independently of HTTP Adaptive Streaming.
"
NEW:
"
LOG-18  [MED] The CDNI Logging interface should support the ability
           for the Downstream CDN to include the Content Collection ID
           and Session ID fields in CDNI log entries generated for HTTP
           Adaptive Streaming content.
"
Rationale: again custom log likely not supported initially.

KL> ok

Kent

Francois

On 12 Mar 2013, at 17:53, Kent Leung (kleung) <[email-masked]> wrote:

> Hi Francois. Comments below in "KL>".
> 
> -----Original Message-----
> From: Francois Le Faucheur (flefauch)
> Sent: Tuesday, March 12, 2013 7:08 AM
> To: Kent Leung (kleung)
> Cc: [email-masked]
> Subject: Re: [CDNi] draft-ietf-cdni-requirements-05.txt
> 
> Kent and all,
> 
> I have received consistent feed-back from two CDN operators and a Content Provider that the CDNI solution ought to support:
> 	*A* enforcement of caching directives by dCDN that are different to the ones signalled in the HTTP headers
> 	*B* choice of ignoring/factoring query string in dCDN caching
> 	*C* rate-pacing by the dCDN on behalf of the uCDN (for Progressive 
> Download)
> 
> *A* and *B* are already mostly covered in META-18 but it is listed as [LOW]. I would recommend we raise META-18 to [MED].
> 
> KL> That sounds reasonable to me. Unless others object, this requirement will be set to MED priority in the next version.
> 
> I don't think *C* is covered. I would recommend we add rate-pacing as a 3rd example of "surrogate cache behaviour" in META-18. 
> 
> KL> I can see some value of this feature. I'll see how the debate settles before updating the draft.
> 
> I will bring this up in the CDNI session today, but wanted to give folks some heads-up.
> 
> KL> Thanks for the heads up.
> 
> I also have other comments on -05 which I will either pass on to Kent directly or post on the list.
> 
> KL> Thanks.
> 
> Kent
> 
> 
> Cheers
> 
> Francois
> 
> 
> 
> "
>  META-18  [LOW] The CDNI Metadata Distribution interface may allow
>            signaling of CDNI-relevant surrogate cache behavior
>            parameters.  For example, this could potentially include:
> 
>            *   control of whether the query string of HTTP URI is to be
>                ignored by surrogate cache
> 
>            *   content revalidation parameters (e.g.  TTL)
> "
> 
> 
> On 6 Mar 2013, at 18:08, Kent Leung (kleung) <[email-masked]> wrote:
> 
>> Hi folks. The requirements draft was updated based on the feedback from the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS), draft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-logging.
>> 
>> In preparation for the next WG session, the edits were published in the draft for review. Please provide your comments to the list of requirement changes below.  Thanks.
>> 
>> 1. New CDNI Control Interface requirement
>> 
>>        a. Based on recommendations in ID-HAS, CCID is introduced for HAS content without the need for HAS-aware CDN.
>> 
>>        CNTL-12  [MED] The CDNI Control interface should allow for multiple	
>> 	            content items identified by a Content Collection ID to be	
>> 	            purged using a single Content Purge action.
>> 
>> 2. New CDNI Request Routing Interface requirements
>> 
>>         a. This is an explicit requirement for RRI to support per-chunk request routing. Since the chunk is same as any content, it's not clear if the requirement is needed?
>> 
>>         REQ-15  [HIGH] The CDNI Request-Routing interface shall allow for	
>> 	           per-chunk request routing of HTTP Adaptive Streaming content.	
>> 	           [Ed: chunk is treated as any content, is this needed?]	
>> 		
>>         b. Manifest rewrite by uCDN is considered as optional feature in the ID-HAS, should the priority be LOW instead of MED?
>> 
>>         REQ-16  [MED] The CDNI Request-Routing interface should allow the	
>> 	           Upstream CDN to use the information conveyed by the	
>> 	           Downstream CDN during the Recursive Request Routing process	
>> 	           to rewrite an HTTP Adaptive Streaming manifest file.  [Ed:	
>> 	           should this be LOW?]	
>> 
>>          c. Manifest rewrite by uCDN for URI Signing is considered as optional feature in the ID-HAS, should the priority be LOW instead of MED?
>> 		
>>          REQ-17  [MED] The CDNI Request-Routing interface should allow the	
>> 	           Upstream CDN to re-sign the invariant portion of the chunk	
>> 	           URIs embedded in the HTTP Adaptive Streaming manifest file.	
>> 	           [Ed: should this be LOW?]	
>> 		
>>         d. Use of cookie for URI Signing is is considered as optional feature in the ID-HAS, should the priority be LOW instead of MED?
>> 
>>         REQ-18  [MED] The CDNI Request-routing interface should allow the use	
>> 	           of HTTP cookie to associate the chunks with the HTTP Adaptive	
>> 	           Stream manifest file (which is verified by the URI signature)	
>> 	           basedon the Authorization Group ID (which is an identifier	
>> 	           used to correlate the manifest file to the related chunks).	
>> 	           [Ed: should this be LOW?]	
>> 
>>         e. 	LOW instead of MED priority?	
>> 
>>         REQ-19  [MED] The CDNI Request-Routing interface may allow for an	
>> 	           efficient method of transferring request routing information	
>> 	           for multiple chunks from the Downstream CDN to the Upstream	
>> 	           CDN as part of the recursive request routing process.  [Ed:	
>> 	           should this be LOW?]	
>> 	
>>         f. Based on ID-HAS and logging drafts, the following requirement was introduced to log HAS content and customization of the logging.
>> 	
>>         REQ-20  [MED] The CDNI Request-Routing/Footprint and Advertising	
>> 	           interface shall support advertisement of the following	
>> 	           capabilities:	
>> 		
>> 	           *   support for customized CDNI Logging	
>> 		
>> 	           *   support of Content Collection ID logging	
>> 		
>> 	           *   support for Session ID logging
>> 
>> 3. Removed CDNI Metadata Distribution Interface requirement.
>> 
>>         a. Based on the metadata draft, there is no need for dCDN to indicate to the uCDN the result of delivering the metadata since the "pull" or "triggered pull" model is used (i.e. dCDN request for metadata from uCDN).
>> 
>> META-13  [HIGH] The CDNI Metadata Distribution interface shall	 		
>>           provide indication by the Downstream CDN to the Upstream CDN	 		
>>           of whether the CDNI metadata (and corresponding future	 		
>>           request redirections) is accepted or rejected.  When	 		
>>           rejected, the CDNI Metadata Distribution protocol Must allow	 		
>>           the Downstream CDN to provide information about the cause of	 		
>>           the rejection.	 		
>> 
>> 4. New CDNI Metadata Distribution Interface requirements
>> 
>>       a. Based on ID-HAS's recommendations, this is introduced.
>> 
>>       META-19  [HIGH] The CDNI Metadata interface shall provide indication	
>> 	            of related content (e.g.  HTTP Adaptive Bit Rate chunks) by	
>> 	            the Content Collection ID (CCID) metadata.  This could be	
>> 	            used by the Downstream CDN for operations on the group of	
>> 	            content.  For example, this could potentially include:	
>> 		
>> 	            *   content acquisition for the entire set of files when one	
>> 	                piece of content is requested	
>> 		
>> 	            *   local file management and storage bundles all the files	
>> 	                for the content	
>> 		
>> 	            *   purging the entire set of files associated with the	
>> 	                content	
>> 		
>> 	            *   logging of the delivery of the content for the session	
>> 	                when at least one file in the set was delivered	
>> 		
>>       b. Based on the logging draft, this is introduced.
>> 
>>       META-20  [HIGH] The CDNI Metadata Distribution interface shall	
>> 	            support an OPTIONAL mechanism allowing the Upstream CDN to	
>> 	            indicate to the Downstream CDN which CDNI Log fields are to	
>> 	            be provided for all, for specific sets of, or for specific	
>> 	            content items delivered using HTTP.  A CDNI implementation	
>> 	            that does not support this optional CDNI Metadata	
>> 	            Distribution Interface mechanism MUST ignore this log format	
>> 	            indication and generate CDNI logging format for HTTP	
>> 	            Adaptive Streaming using the default set of CDNI Logging	
>> 	            fields.	
>> 		
>>       c. Based on the ID-HAS's recommendations, this is introduced.
>> 
>>       META-21  [MED] The CDNI Metadata Distribution interface shall allow	
>> 	            the Upstream CDN to signal to the Downstream CDN the Content	
>> 	            Collection ID value for all, for specific sets of, or for	
>> 	            specific content items delivered using HTTP.  Whenever the	
>> 	            Downstream CDN is instructed by the Upstream CDN to report	
>> 	            the Content Collection ID field in the log records, the	
>> 	            Downstream CDN is to use the value provided through the CDNI	
>> 	            Metadata interface for the corresponding content.  Note the	
>> 	            Session ID field along with Content Collection ID may be	
>> 	            used for HTTP Adaptive Streaming content.	
>> 		
>>       d. Based on ID-HAS's recommendations, this is introduced.
>> 
>>       META-22  [MED] The CDNI Metadata Distribution interface shall allow	
>> 	            the Upstream CDN to signal to the Downstream CDN the	
>> 	            Authorization Group ID value for all the related HTTP	
>> 	            Adaptive Streamin content (i.e. manifest file and chunks).	
>> 	            The authorization result of a content (e.g. manifest file)	
>> 	            is transferred over to related content (e.g. chunks).  [Ed:	
>> 	            need to improve wording?]
>> 
>> 5. Remove CDNI Logging Interface requirement
>> 
>>       a. It is deemed unnecessary for dCDN to obtain logs from uCDN, which has access to all the logs for trouble-shooting and auditing.
>> 
>> LOG-4   [HIGH] The CDNI Logging interface shall provide logging of	 	
>>          distribution performed by the Upstream CDN as a result of	 		
>>          acquisition request by the Downstream CDN.
>> 
>> 6. Add CDNI Logging Interface requirements
>> 
>>         a. Based on the logging draft, this is introduced.
>> 
>>         LOG-17  [HIGH] The CDNI Logging interface shall support the	
>> 	           notification from Downstream CDN to Upstream CDN for the	
>> 	           event that the logging retention duration or maximum size of	
>> 	           logging data has exceeded.	
>> 		
>>         b. Based on the ID-HAS, CCID is a field to report in the log. Also, based on the logging draft, Session ID is another field needed in the log.
>> 
>>         LOG-18  [MED] The CDNI Logging interface should support the ability	
>> 	           for the Downstream CDN to include the Content Collection ID	
>> 	           and Session ID fields in CDNI log entries generated for HTTP	
>> 	           Adaptive Streaming content.  This fields can be supported by	
>> 	           the "customizable" log format which is expected to be defined	
>> 	           independently of HTTP Adaptive Streaming.
>> 
>> Kent
>> 
>> -----Original Message-----
>> From: [email-masked] [mailto:[email-masked]] On Behalf 
>> Of [email-masked]
>> Sent: Saturday, February 23, 2013 1:16 PM
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: [CDNi] I-D Action: draft-ietf-cdni-requirements-05.txt
>> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Content Delivery Networks Interconnection Working Group of the IETF.
>> 
>> 	Title           : Content Distribution Network Interconnection (CDNI) Requirements
>> 	Author(s)       : Kent Leung
>>                         Yiu Lee
>> 	Filename        : draft-ietf-cdni-requirements-05.txt
>> 	Pages           : 23
>> 	Date            : 2013-02-23
>> 
>> Abstract:
>>  Content Delivery Networks (CDNs) are frequently used for large-scale  
>> content delivery.  As a result, existing CDN providers are scaling up  
>> their infrastructure and many Network Service Providers (NSPs) are  
>> deploying their own CDNs.  There is 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.  The Content Distribution Network  
>> Interconnection (CDNI) working group has been chartered to develop an  
>> interoperable and scalable solution for such CDN interconnection.
>> 
>>  The goal of the present document is to outline the requirements for  
>> the solution and interfaces to be specified by the CDNI working  
>> group.  This draft is a work in progress and requirements may be  
>> added, modified, or removed by the working group.
>> 
>> Requirements Language
>> 
>>  The key words "High Priority", "Medium Priority" and "Low Priority"
>>  in this document are to be interpreted in the following way:
>> 
>>  o  "High Priority" indicates requirements that are to be supported by
>>     the CDNI interfaces.  A requirement is stated as "High Priority"
>>     when it is established by the working group that it can be met
>>     without compromising the targeted schedule for WG deliverables, or
>>     when it is established that specifying a solution without meeting
>>     this requirement would not make sense and would justify re-
>>     adjusting the WG schedule, or both.  This is tagged as "[HIGH]".
>> 
>>  o  "Medium Priority" indicates requirements that are to be supported
>>     by the CDNI interfaces unless the WG realizes at a later stage
>>     that attempting to meet this requirement would compromise the
>>     overall WG schedule (for example it would involve complexities
>>     that would result in significantly delaying the deliverables).
>>     This is tagged as "[MED]".
>> 
>>  o  "Low Priority" indicates requirements that are to be supported by
>>     the CDNI interfaces provided that dedicating WG resources to this
>>     work does not prevent addressing "High Priority" and "Medium
>>     Priority" requirements and that attempting to meet this
>>     requirement would not compromise the overall WG schedule.  This is
>>     tagged as "[LOW]".
>> 
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-cdni-requirements
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-cdni-requirements-05
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-cdni-requirements-05
>> 
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> 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: Kevin J Ma <[email-masked]>
Date: Mon, 8 Apr 2013 21:17:19 -0400

> In fact, does the "triggers" interface actually cope for that ?
> KL> ok.  It's better to split the bullets and prioritize differently. The
> current triggers interface deals with delete only, AFAIK.

the triggers draft covers invalidate...
the invalidate trigger type is defined in sections 5.5.1 and 6.1.1, and
an example is provided in section 7.1.2.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Kent Leung (kleung)
> Sent: Monday, April 08, 2013 2:54 PM
> To: Francois Le Faucheur (flefauch)
> Cc: [email-masked]
> Subject: Re: [CDNi] Comments on draft-ietf-cdni-requirements-05.txt
>
> Hi Francois. Thanks for the thorough review. I'll incorporate your
> feedback. Just a few comments and clarification questions below. I should
> be able to publish the draft in a few days.
>
> (Note that while delivery and acquisition "data plane" protocols are out
> of the CDNI solution scope, the CDNI solution "control plane" protocols
> are expected to participate in enabling, selecting or facilitating
> operations of such acquisition and delivery protocols.  Hence it is useful
> to state requirements on the CDNI solution in terms of which acquisition
> and delivery protocols).
> "
> KL> ok. I've kept the note for GEN-5 and added " (The note above applies
> to this requirement too)" to GEN-6. Formatting remains consistent this
> way.
>
> Regarding:
> "
> GEN-13  Removed.
> "
> I suggest you just remove altogether the requirements that were dropped
> and renumber the following ones to avoid gaps.
>
> KL> ok. It was better to keep all the requirement numbers for discussions
> (i.e. clear reference) up to this point. Now we are ready for last call.
> We'll clean up all the removed requirements. This means the authors of the
> interface drafts need to update their references to the requirements
> draft. I can create a mapping of the numbering changes between ver -05 to
> -06 if that's helpful. What do you think?
>
> Regarding:
> "
> But it is not clear to me that the first bullet is really a [HIGH]. I see
> it as an optimisation, not a must-have. I'd rate it as a [MID] or [LOW].
> In fact, does the "triggers" interface actually cope for that ?
> KL> ok.  It's better to split the bullets and prioritize differently. The
> current triggers interface deals with delete only, AFAIK.
>
>
> Regarding:
> "
> I thought we have agreed that pre-positioning would be a [MED] whether
> content or metadata. CNTL-4 is already a [MED]. I suggest making CNTL-3 a
> [MED] also.
>
> KL> ok.
>
> Regarding:
> "
> This functionality has moved to the FCI. How about, you move this
> functionality with the rest of the text discussing the FCI requirements?
>
> KL> ok
>
> Regarding:
> "
> I suggest moving this requirement up so it follows the first purge-related
> requirements i.e. place it right after CNTL-1.
>
> KL> ok
>
> Regarding Section 5:
>       * in each requirement, you mention the actual interface (i.e. RI or
> FCI) instead of "the Request Routing Interface".
> Regarding REQ-16 and REQ-17: I vote for [LOW]. I see Manifest-file-
> Manipulation approaches as nice-to-allow but not [MED].
>
> KL> ok
>
> BTW: at the very end of editing , you should probably do a pass and check
> the shall/should/may correspond to HIGH/MED/LOW in each and every
> requirement. e.g. there is also a mismatch in REQ-20.
>
> The list of capabilities here is a little out of date (e.g. "support for
> customised CDNI logging" - which is dropped) and only covers the ones
> related to logging while it shoudl bring up the other ones (e.g. delivery
> protocol). Since the actual capabilities are discussed in the FCI
> semantics draft, I would suggest not trying to list specific capabilities
> in that requirement, and instead keep it high level and probably just list
> the types of capabilities (e.g. mention it needs to cover capabilities
> associated with logging, with distribution protocols, with acquisition
> protocols, etc..)
>
> KL> ok
>
> OLD:
> "
> META-7   [HIGH] The CDNI Metadata Distribution interface (possibly in
> conjunction with the CDNI Control interface) shall allow
> META-8   [HIGH] The CDNI Metadata Distribution interface (possibly in
> conjunction with the CDNI Control interface) shall allow
> KL> The thread below is about logging customization and directional
> logging. Not clear about relationship to this requirement?
>
>
> Regarding META-20: As documented in http://www.ietf.org/mail-
> archive/web/cdni/current/msg01375.html, it is felt that this requirement
> shoudl not be pursued for initial deliverables. Besides, there was no hard
> conclusion as to whether this would belong to MI or CI. This requirement
> should be a [MED] (instead of a [HIGH]) and I suggest you add a note
> indicating that there is still some thinking to be done to conclude
> whether this should really be MI or CI.
>
> KL> ok
>
> OLD:
> "
> LOG-17  [HIGH] The CDNI Logging interface shall allow a CDN to notify
> another CDN about which CDNI logging information is available for transfer
> (and/or no longer available, say because it exceeded some logging
> retention period or some logging retention volume).
> "
> Rationale: The current wording was overly prescriptive. I think the key
> point is that the CDNs should inform each other about which info can be
> obtained.
>
> KL> ok
>
> OLD:
> "
> > I have received consistent feed-back from two CDN operators and a
> Content Provider that the CDNI solution ought to support:
> > *A* and *B* are already mostly covered in META-18 but it is listed as
> [LOW]. I would recommend we raise META-18 to [MED].
> >
> > KL> That sounds reasonable to me. Unless others object, this requirement
> will be set to MED priority in the next version.
> >
> > I don't think *C* is covered. I would recommend we add rate-pacing as a
> 3rd example of "surrogate cache behaviour" in META-18.
> >
> >> Hi folks. The requirements draft was updated based on the feedback from
> the authors of the following drafts: draft-brandenburg-cdni-has (ID-HAS),
> draft-bertrand-cdni-logging, draft-ietf-cdni-metadata, draft-ietf-cdni-
> logging.
> >>
> >> In preparation for the next WG session, the edits were published in the
> draft for review. Please provide your comments to the list of requirement
> changes below.  Thanks.
> >>
> >>        a. Based on recommendations in ID-HAS, CCID is introduced for
> HAS content without the need for HAS-aware CDN.
> >>
> >>         a. This is an explicit requirement for RRI to support per-chunk
> request routing. Since the chunk is same as any content, it's not clear if
> the requirement is needed?
> >>
> >>         b. Manifest rewrite by uCDN is considered as optional feature
> in the ID-HAS, should the priority be LOW instead of MED?
> >>
> >>          c. Manifest rewrite by uCDN for URI Signing is considered as
> optional feature in the ID-HAS, should the priority be LOW instead of MED?
> >>
> >>         d. Use of cookie for URI Signing is is considered as optional
> feature in the ID-HAS, should the priority be LOW instead of MED?
> >>
> >>         f. Based on ID-HAS and logging drafts, the following
> requirement was introduced to log HAS content and customization of the
> logging.
> >>
> >>         a. Based on the metadata draft, there is no need for dCDN to
> indicate to the uCDN the result of delivering the metadata since the
> "pull" or "triggered pull" model is used (i.e. dCDN request for metadata
> from uCDN).
> >>
> Content
> >>       a. It is deemed unnecessary for dCDN to obtain logs from uCDN,
> which has access to all the logs for trouble-shooting and auditing.
> >>
> >>         b. Based on the ID-HAS, CCID is a field to report in the log.
> Also, based on the logging draft, Session ID is another field needed in
> the log.
> >>
> >> This draft is a work item of the Content Delivery Networks
> Interconnection Working Group of the IETF.
> >>

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Tue, 9 Apr 2013 16:13:28 +0000

Thanks Kevin.. I couldn't reference the draft yesterday to confirm. There will be two requirements due to the different priority levels.

Kent

-----Original Message-----
From: Kevin J Ma [mailto:[email-masked]] 
Sent: Monday, April 08, 2013 6:17 PM
To: Kent Leung (kleung); Francois Le Faucheur (flefauch)
Cc: [email-masked]
Subject: RE: Comments on draft-ietf-cdni-requirements-05.txt

> KL> ok.  It's better to split the bullets and prioritize differently. 
> KL> The

the triggers draft covers invalidate...
the invalidate trigger type is defined in sections 5.5.1 and 6.1.1, and an example is provided in section 7.1.2.

> Of Kent Leung (kleung)
> feedback. Just a few comments and clarification questions below. I 
> should be able to publish the draft in a few days.
>
> (Note that while delivery and acquisition "data plane" protocols are 
> out of the CDNI solution scope, the CDNI solution "control plane" 
> protocols are expected to participate in enabling, selecting or 
> facilitating operations of such acquisition and delivery protocols.  
> Hence it is useful to state requirements on the CDNI solution in terms 
> of which acquisition and delivery protocols).
> "
> KL> ok. I've kept the note for GEN-5 and added " (The note above 
> KL> applies
> I suggest you just remove altogether the requirements that were 
> dropped and renumber the following ones to avoid gaps.
>
> KL> ok. It was better to keep all the requirement numbers for 
> KL> discussions
> We'll clean up all the removed requirements. This means the authors of 
> the interface drafts need to update their references to the 
> requirements draft. I can create a mapping of the numbering changes 
> between ver -05 to
> But it is not clear to me that the first bullet is really a [HIGH]. I 
> see it as an optimisation, not a must-have. I'd rate it as a [MID] or [LOW].
> KL> ok.  It's better to split the bullets and prioritize differently. 
> KL> The
> content or metadata. CNTL-4 is already a [MED]. I suggest making 
> CNTL-3 a [MED] also.
>
> KL> ok.
>
> Regarding:
> "
> I suggest moving this requirement up so it follows the first 
> purge-related requirements i.e. place it right after CNTL-1.
>
> KL> ok
>
> Regarding Section 5:
> It will make it much easier to read, and much more useful so we know 
> which requirements applies to which interface.
>
> BTW: at the very end of editing , you should probably do a pass and 
> check the shall/should/may correspond to HIGH/MED/LOW in each and 
> every requirement. e.g. there is also a mismatch in REQ-20.
>
> The list of capabilities here is a little out of date (e.g. "support 
> for customised CDNI logging" - which is dropped) and only covers the 
> ones related to logging while it shoudl bring up the other ones (e.g. 
> delivery protocol). Since the actual capabilities are discussed in the 
> FCI semantics draft, I would suggest not trying to list specific 
> capabilities in that requirement, and instead keep it high level and 
> probably just list the types of capabilities (e.g. mention it needs to 
> cover capabilities associated with logging, with distribution 
> protocols, with acquisition protocols, etc..)
>
> KL> ok
>
> OLD:
> "
> archive/web/cdni/current/msg01375.html, it is felt that this 
> requirement shoudl not be pursued for initial deliverables. Besides, 
> there was no hard conclusion as to whether this would belong to MI or 
> CI. This requirement should be a [MED] (instead of a [HIGH]) and I 
> suggest you add a note indicating that there is still some thinking to 
> be done to conclude whether this should really be MI or CI.
>
> KL> ok
>
> OLD:
> "
> another CDN about which CDNI logging information is available for 
> transfer (and/or no longer available, say because it exceeded some 
> logging retention period or some logging retention volume).
> "
> Rationale: The current wording was overly prescriptive. I think the 
> key point is that the CDNs should inform each other about which info 
> can be obtained.
>
> KL> ok
>
> OLD:
> "
> >     *A* enforcement of caching directives by dCDN that are different 
> > to
> the ones signalled in the HTTP headers
> > KL> That sounds reasonable to me. Unless others object, this 
> > KL> requirement
> > I will bring this up in the CDNI session today, but wanted to give 
> > folks
> some heads-up.
> >
> > I also have other comments on -05 which I will either pass on to 
> > Kent
> directly or post on the list.
> >
> > KL> Thanks.
> >
> > Kent
> >
> >
> > Cheers
> >
> > Francois
> >
> >
> >
> > "
> the authors of the following drafts: draft-brandenburg-cdni-has 
> (ID-HAS), draft-bertrand-cdni-logging, draft-ietf-cdni-metadata, 
> draft-ietf-cdni- logging.
> >>
> draft for review. Please provide your comments to the list of 
> requirement changes below.  Thanks.
> >>
> >>                content items identified by a Content Collection ID 
> >> to
> be
> request routing. Since the chunk is same as any content, it's not 
> clear if the requirement is needed?
> >>
> >>         REQ-15  [HIGH] The CDNI Request-Routing interface shall 
> >> allow
> for
> >>         REQ-16  [MED] The CDNI Request-Routing interface should 
> >> allow
> the
> >>          REQ-17  [MED] The CDNI Request-Routing interface should 
> >> allow
> the
> >>         REQ-18  [MED] The CDNI Request-routing interface should 
> >> allow
> the use
> >>         REQ-19  [MED] The CDNI Request-Routing interface may allow 
> >> for
> an
> "pull" or "triggered pull" model is used (i.e. dCDN request for 
> metadata from uCDN).
> >>
> >>                of related content (e.g.  HTTP Adaptive Bit Rate 
> >> chunks)
> by
> >>                the Content Collection ID (CCID) metadata.  This 
> >> could
> be
> >>                used by the Downstream CDN for operations on the 
> >> group
> of
> >>                support an OPTIONAL mechanism allowing the Upstream 
> >> CDN
> to
> >>                indicate to the Downstream CDN which CDNI Log fields 
> >> are
> to
> >>                Distribution Interface mechanism MUST ignore this 
> >> log
> format
> >>                Collection ID value for all, for specific sets of, 
> >> or
> for
> >>                specific content items delivered using HTTP.  
> >> Whenever
> the
> >>                Downstream CDN is to use the value provided through 
> >> the
> CDNI
> >>                Metadata interface for the corresponding content.  
> >> Note
> the
> >>               event that the logging retention duration or maximum 
> >> size
> of
> Also, based on the logging draft, Session ID is another field needed 
> in the log.
> >>
> >>               for the Downstream CDN to include the Content 
> >> Collection
> ID
> >>               and Session ID fields in CDNI log entries generated 
> >> for
> HTTP
> >>               Adaptive Streaming content.  This fields can be 
> >> supported
> by
> >> From: [email-masked] [mailto:[email-masked]] On 
> >> Behalf Of [email-masked]
> >>  Content Delivery Networks (CDNs) are frequently used for 
> >> large-scale content delivery.  As a result, existing CDN providers 
> >> are scaling up their infrastructure and many Network Service 
> >> Providers (NSPs) are deploying their own CDNs.  There is 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.  The Content Distribution Network Interconnection (CDNI) 
> >> working group has been chartered to develop an interoperable and scalable solution for such CDN interconnection.
> >>
> >>  The goal of the present document is to outline the requirements 
> >> for the solution and interfaces to be specified by the CDNI working

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 11 Apr 2013 09:20:58 +0000

Hello Kent,

Thanks for following up on all the comments. One clarification below:

On 8 Apr 2013, at 20:54, Kent Leung (kleung) <[email-masked]<mailto:[email-masked]>> wrote:
...

I was referring to http://www.ietf.org/mail-archive/web/cdni/current/msg01427.html  (which was embedded in the message).
This indeed relates to META-18. But the way you addressed that in -06 (i.e. MI-17) is all fine by me, so we are all good.

Thanks

Francois