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

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 8 Apr 2014 10:12:10 +0100

Francois,

See inline for my views on a couple of your comments. I’ve snipped out your other comments that I’m fine with.

On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

> *** 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, …)

What do you mean? I’m not sure what you have in mind when you say a “summary of features supported by specified metadata”? 
 
> *** 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.

This is a useful clarification IMO, we should include it.

> *** 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 “\”?

You need to escape the escape character so that you can represent the escape character as a literal. Or in other words if I want to represent “\” I need to escape it to avoid it being mistaken for the escape character otherwise I can’t determine whether the next character is escaped or not.

> *** 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>)

There are two useful properties of having multiple endpoints within a source IMO:

1) They share common auth properties so those do not have to be repeated for each endpoint as would be the case if each endpoint was specified as a separate source.

2) Endpoints within a source should be treated as equivalent/equal so one can specify a list of sources in preference order and for each source/preference rank one can specify a list of endpoints that are equivalent, e.g. a pool of servers that are not behind a load balancer.

Ben

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 16 Apr 2014 11:59:52 +0000

Hi Ben,

Thanks for looking into all the comments. My turn now to wlak through your responses. See below:

> What do you mean? I’m not sure what you have in mind when you say a “summary of features supported by specified metadata”? 

I am thinking of a summary of what are the features of the distribution policies supported by the metadata specified in this version of the document. Something indicating that with these metadata it is possible to support geographical access control, time access control, multiple content origination , content origination authorization, …. To me it woudl be very useful for a reader to get upfront a high level understanding of what can actually be achieved (in terms of content distributon policies) across CDNs interconnected via cdni-metadata.
BTW, if there are a number of functionality that are deliberately not supported by the current spec , it woudl be worth stating so.
Otherwise one has to read the whole detailed document to get a feeling for what functionality it provides.

> This is a useful clarification IMO, we should include it.

Good.

> You need to escape the escape character so that you can represent the escape character as a literal. Or in other words if I want to represent “\” I need to escape it to avoid it being mistaken for…

I guess I was getting tired when I wrote that. Please ignore my comment.

> 1) They share common auth properties so those do not have to be repeated for each endpoint as would be the case if each endpoint was specified as a separate source.

Good point.

> 2) Endpoints within a source should be treated as equivalent/equal so one can specify a list of sources in preference order and for each source/preference rank one can specify a list of endpoints t…

I am fine with that approach, but as per my other comments, the document should be explicit about whether there is (or not) a semantics associated to order of sources  (i.e. is the order of sources meant to be a strict preference, or something else, or are they equivalent?) and whether there is a semantics associated to the order of endpoints within a source (i.e is the order of endpoints meant to be a strict preference, or something else, or are they equivalent?) . I think you recommend “priority for sources” and “equivalent for endpoints”. That works for me, but we want that to be made explicit and agreed by the group.

Francois

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 28 Apr 2014 10:32:26 +0100

Francois,

I have incorporated the editorial comments from below. Some of your comments require some discussions with my co-authors so I’ve marked them as “Design” below and we’ll follow up later with proposed resolutions for them.

Ben

On 12 Mar 2014, at 13:51, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

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

Design, will address in a follow-up e-mail.

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

Design, will address in a follow-up e-mail.

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

Done.

> *** 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 .
> “

Done.

> *** 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.
> “

Done.

> Why do you need to escape “\”?

Addressed already, no change required.

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

Design, will address in a follow-up e-mail.

> *** 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”

Depends how we address previous comment, will address in a follow-up e-mail.

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

Depends how we address previous comment, will address in a follow-up e-mail.

> *** 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?

Design, will address in a follow-up e-mail.

> *** 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? 

Design, will address in a follow-up e-mail.

> 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 multi…

Design, will address in a follow-up e-mail.

> *** 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.
> “

Done.

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

Design, will address in a follow-up e-mail.

> *** 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.
> “

Done.

> *** 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.
> “

Done.

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

Done.

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

Done.

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

Design as looking at DVD specs we may need to change the representation, will address in a follow-up e-mail.

Ben