Subject: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4]

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 12 Mar 2014 13:51:53 +0000

(Note: I stopped detailed review at 4.2.4 even if I have a few comments beyond that).

==============
General comments:

*** somewhere (probably towards the beginning of the document):
Can you make sure the applicability of the metadata defined in this documents is discussed in terms of what types of deliveries are supported (HTTP/1.0, 1.1, 2.0 , HTTPS). I suggest you base that on the text I proposed on the list for cdni-logging.
Also how about adding a summary of features supported by specified metadata (eg geolocation, time window, multipe acquisitions, …)

*** use of MUST:
I think this needs a clean-up:
o there are a number of appropriate MUST statements on detailed things, but I can’t see one statement clarifying exhaustively which object is mandatory to implement as an uCDN and as a dCDN. Can you make sure this is covered , if not already covered?
o there are a few “must” that we may want to replace with alternate phrases ( “needs to”, “has to”, …)
o there are MUSTs in the IANA section (eg 7.1). Based on the conversation we had in teh contaxt of cdni-logging, I assume these will be edited out. 

====================
Detailed comments:

*** section 4.1.3:
"First match applies.”
Might be worth turning into a full sentence explaining the context of the “match” ie when metadata is walked through to find the relevant one for a piece of content to be processed , every path-pattern is evaluated in the order they appear in paths object and then first match applies.… up to you.

*** section 4.1.5:
OLD:
“
A PathMetadata object contains the CDNI Metadata properties for
   content served with the associated URI path (defined in a PathMatch
   object).
“
NEW:
“
A PathMetadata object contains the CDNI Metadata properties for
   content served with the associated URI path (defined in a PathMatch
   object) and possibly children PathMatch objects .
“

*** section 4.1.5:
OLD:
“
Note that if CDNI metadata is used as an input to CDNI
   request routing and DNS-based redirection is employed, then any
   metadata at the PathMetadata level or below will be inaccessible at
   request routing time.
“
NEW:
“
Note that if DNS-based redirection is employed, then any
   metadata at the PathMetadata level or below will be inaccessible at
   request routing time because only the content request hostname is available at request routing time.
“

*** section 4.1.6:
"The three literals \ , * and ? should be
         escaped as \\, \* and \?. All other characters are treated as
         literals.”
Why do you need to escape “\”?

*** section 4.1.7:
“
        Property: type
         Description: CDNI Metadata property object type.
         Type: String
         Mandatory-to-Specify: Yes.

      Property: value
         Description: CDNI Metadata property object.
         Type: matches the type property above
"
To me it would be easier to follow if you renamed the properties from “type” and “value” to something like “generic-metadata-type” and "generic-metadata-value”. 
Obviously, you'd need to reflect these changes in other places.

*** section 4.1.7:
"Type: matches the type property above”
This is an exemple of things that are hard to parse currently. With the proposed change above this could read:
"Type: matches the generic-metadata-type of the property above"

*** section 4.2:
OLD:
“
The property objects defined below are intended to be used in the
   GenericMetadata object value field as defined in Section 4.1.7. 
“
NEW:
"
The property objects defined below are intended to be used in the
   GenericMetadata object generic-metadata-value propery as defined in Section 4.1.7 and their type used in the generic-metadata-type property as defined in section 4.1.7. 
“
Let me kow if this is not correct.

*** section 4.2:
“
All of the objects defined below are considered both mandatory to enforce
   and safe to redistribute.
“
is it allowed to distribute them with no-MtE or no-StR? what woudl happen then?
Would it be appropriate to state that all the objects MUST be distributed with MtE and StR? can you add a statement about behavior or receipt if received otherwise?

*** section 4..2.1:
“
Description: Sources from which the dCDN can acquire content,
         listed in priority order.”
you may want to use “preference” instead of “priority” (which is an overloaded term) and explain what it means i.e. the dCDN is expected to always use the first one , unless it does not work? or is dCDN allowed to load balance across multiple sources? should there be a mechanism to control whether it is single source + backup or multple sources? 

*** section 4.2.1.1:
Is it really useful to allow multiple endpoints within a source, given it is possible to include multiple sources?
If you keep multiple endpoints within a source, can you also clarify if there is any expected behavior from dCDN across the multiple endpoints (single <endpoint+ backup> or <load-balance over multiple>)

*** section 4.2.2:
OLD:
“
Description: Access control list which applies restrictions to
         delivery based on client location.
"
NEW:
“
Description: Access control list which allows or blocks
         delivery based on client location.
"

***section 4.2.2.1:
I assume that the rules are discussed somewhere in the document (that I have not got to yet) on usage of the LocationACLMetadata.
For example:
	* if I only include one single LocationRule object that allows Footprint1, does it mean that a delievery from outside Footprint 1 is allowed or denied?
	* if I have overlapping footprints, which applies? first one?
If these rules are not made explicit yet, please add them.

*** section 4.2.3:
OLD:
“
Description: Access control list which applies restrictions to
         delivery based on request time.
"
NEW:
“
Description: Access control list which allows or blocks 
         delivery based on request time.
"

*** section 4.2.3:
OLD:
“
Description: Access control list which applies restrictions to
         delivery based on delivery protocol.
“
NEW:
“
Description: Access control list which allows or blocks
         delivery based on delivery protocol.
“

*** section 6.2: 
"Where a downstream CDN is interconnected with multiple upstream CDNs,
   the downstream CDN must decide which upstream CDN's CDNI metadata
   should be used to handle a particular User Agent request.
”
s/must decide/needs to determine/

*** Section 6.4.2.1:
OLD:
“ 6.4.2.1.  JSON Example”
NEW:
" 6.4.2.1.  Encoded CDNI Metadata Example”

*** section 7.1.1.1”
“
DVD Region code (i.e., integer in the range 0-6). 
“
add a reference that specifies these values.