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

From: Kevin Ma J <[email-masked]>
Date: Wed, 25 Jun 2014 01:01:52 +0000

Hi Francois,

  We were looking for clarification wrt to the following comment:

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

  I think we intentionally made the metadata delivery protocol agnostic.
  - LocationACL, TimeWindowACL, and Grouping are all protocol agnostic.
  - Source and ProtocolACL specify lists of protocols, but are not themselves protocol specific.
  - Cache only deals with query strings, which is scheme agnostic and works with any URI.
  - Auth is also protocol agnostic.  Though credential auth can be used with HTTP,
    the specification of username and password is not itself protocol specific.
  The CDNI logging draft specifies an HTTP specific logging format, and thus requires variant
  considerations for 1.x vs 2.x vs w/ TLS; I don't see metadata requiring this distinction.
  I'm not sure that adding text to discuss HTTP variants is necessary.  If you agree, then
  we will disregard this portion of the comment?  If you still think we need some text,
  would it be sufficient to simply state that all the defined metadata is protocol agnostic?

thanx!

--  Kevin J. Ma

-----Original Message-----
From: CDNi [mailto:[email-masked]] On Behalf Of Ben Niven-Jenkins
Sent: Monday, April 28, 2014 5:32 AM
To: Francois Le Faucher
Cc: [email-masked]; [email-masked]
Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4]

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:
> 
> *** 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, ...)

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

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.

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

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.

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

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

_______________________________________________
CDNi mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/cdni

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Thu, 26 Jun 2014 08:43:15 +0000

Hello Kevin,

>  would it be sufficient to simply state that all the defined metadata is protocol agnostic?

I feel that the reader should be told very explicitely whether he can use this version of cdni-metadata (i) for content delivery via HTTP v1.0, HTTPv1.1, HTTPv2 x with/without TLS and (ii) for content acquisition via HTTPv1.1, HTTPv2 x with/without TLS.

For example, right now, if I look at the “Protocol Sub-registry” (section 7.1.1.2 in cdni-metadata-06), I see:
“
   | HTTP|  Hypertext   Transfer    Protocol --  HTTP/1.1       |                                       |
   | HTTPS    | HTTP Over TLS  | RFC2818         
“
I think this means that:
	* with current version of spec, HTTPv1.1 can be used for acquisition
	* with current version of spec, HTTPv2 can not be used for acquisition
	* if/when the IANA “CDNI Metadata Protocol Sub-Registry" is extended by some other document to register an entry for “HTTPv2” , then it will be possible to use HTTPv2 for acquisition
	* with current version of spec, HTTPv1.0 cannot be used for acquisition
	* I am not clear if HTTPS means HTTPv1.1 over TLS, HTTPv2 over TLS or both. (I think this needs some text clarification eg rename the entry as “HTTPv1.1 over TLS" ).
	* with current version of spec, it is not possible for a dCDN to advertise in FCI that HTTPv2 is supported by dCDN (ie ProtocolACL)
	* with current version of spec, it is not possible for a dCDN to advertise in FCI that HTTPv0 is supported by dCDN (ie ProtocolACL)
	* if/when the IANA “CDNI Metadata Protocol Sub-Registry" is extended by some other document to register an entry for “HTTPv2” , then it will be possible for a dCDN to advertise in FCI that HTTPv2 is supported by dCDN (ie ProtocolACL).

My recommendation is that the document includes text to:
	* state that current spec supports HTTPv1.1 and HTTPv1.1 over TLS delivery and acquisition
	* state that all it would take to support anorther version of HTTP (eg HTTPv2 and HTTPv2 over TLS) is be to allocate the corresponding entries in the “CDNI Metadata Protocol Sub-Registry” (so these protocols can be advertised by dCDN in FCI, and can be identified as acquisition protocols in CDNI metadata). All the other functionality supported by the CDNI metadata spec (eg Time Window, location ACL,..) would just work for these additional protocols because these functions and associated elements are indeed protocol agnostic. 

Makes sense?

Francois

---

From: Kevin Ma J <[email-masked]>
Date: Thu, 26 Jun 2014 13:48:12 +0000

Hi Francois,

  Understood.  Thanks for the clarification.
  I think we should be able to add text to address this.

thanx!

--  Kevin J. Ma

-----Original Message-----
From: Francois Le Faucheur (flefauch) [mailto:[email-masked]] 
Sent: Thursday, June 26, 2014 4:43 AM
To: Kevin Ma J
Cc: Francois Le Faucheur (flefauch); Niven-Jenkins Ben; [email-masked]; [email-masked]
Subject: Re: [CDNi] WG Chair review of draft-ietf-cdni-metadata-06.txt [Batch 4]

Hello Kevin,

On 25 Jun 2014, at 03:01, Kevin Ma J <[email-masked]> wrote:

>  The CDNI logging draft specifies an HTTP specific logging format, and 
> thus requires variant  considerations for 1.x vs 2.x vs w/ TLS; I don't see metadata requiring this distinction.
>  I'm not sure that adding text to discuss HTTP variants is necessary.  
> If you agree, then  we will disregard this portion of the comment?  If 
> you still think we need some text,  would it be sufficient to simply state that all the defined metadata is protocol agnostic?

For example, right now, if I look at the "Protocol Sub-registry" (section 7.1.1.2 in cdni-metadata-06), I see:
"
   | HTTP|  Hypertext   Transfer    Protocol --  HTTP/1.1       |                                       |
   | HTTPS    | HTTP Over TLS  | RFC2818         
"
I think this means that:
	* with current version of spec, HTTPv1.1 can be used for acquisition
	* with current version of spec, HTTPv2 can not be used for acquisition
	* if/when the IANA "CDNI Metadata Protocol Sub-Registry" is extended by some other document to register an entry for "HTTPv2" , then it will be possible to use HTTPv2 for acquisition
	* with current version of spec, HTTPv1.0 cannot be used for acquisition
	* I am not clear if HTTPS means HTTPv1.1 over TLS, HTTPv2 over TLS or both. (I think this needs some text clarification eg rename the entry as "HTTPv1.1 over TLS" ).
	* with current version of spec, it is not possible for a dCDN to advertise in FCI that HTTPv2 is supported by dCDN (ie ProtocolACL)
	* with current version of spec, it is not possible for a dCDN to advertise in FCI that HTTPv0 is supported by dCDN (ie ProtocolACL)
	* if/when the IANA "CDNI Metadata Protocol Sub-Registry" is extended by some other document to register an entry for "HTTPv2" , then it will be possible for a dCDN to advertise in FCI that HTTPv2 is supported by dCDN (ie ProtocolACL).

My recommendation is that the document includes text to:
	* state that current spec supports HTTPv1.1 and HTTPv1.1 over TLS delivery and acquisition
	* state that all it would take to support anorther version of HTTP (eg HTTPv2 and HTTPv2 over TLS) is be to allocate the corresponding entries in the "CDNI Metadata Protocol Sub-Registry" (so these protocols can be advertised by dCDN in FCI, and can be identified as acquisition protocols in CDNI metadata). All the other functionality supported by the CDNI metadata spec (eg Time Window, location ACL,..) would just work for these additional protocols because these functions and associated elements are indeed protocol agnostic. 

Makes sense?

Francois

>> 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.
> 
>> *** section 4.1.6:
>> All of the objects defined below are considered both mandatory to 
>> enforce  and safe to redistribute.
>> "
>> "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.
>> "

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Thu, 26 Jun 2014 17:13:41 +0100

Francois, Colleagues,

> I feel that the reader should be told very explicitely whether he can use this version of cdni-metadata (i) for content delivery via HTTP v1.0, HTTPv1.1, HTTPv2 x with/without TLS and (ii) for cont…

Which raises the question of “what do we really mean by content delivery via HTTP/1.1?” (or HTTP/1.0 etc). So far in the WG we have talked about “HTTP” or “HTTP/1.1” in a fairly loose manner as though, for example, HTTP/1.1 is a single thing that is well defined. In reality it consists of a number of optional capabilities/etc. We don’t have anything in the draft that allows one to assume any more than “if a CDN says it supports HTTP it is able to deliver over HTTP using some (unknown) subset of HTTP features”. It would be possible to be more granular by registering additional entries in the protocol sub-registry and defining what “profile” of HTTP features they indicate support for.

What we have specified is mostly the minimum necessary to deliver something, somehow over HTTP/1.1. It’s a good foundation & framework on which others can specify additional extensions on top of.

> 	* with current version of spec, HTTPv1.0 cannot be used for acquisition

Apart from the protocol sub-registry lacking an entry for HTTP/1.0, if we’re happy with continuing with our loose definition of what delivering over a protocol means, there is nothing in the current metadata draft that prevents delivery or acquisition over HTTP/1.0.

Acquisition is slightly different to delivery when it comes to CDNI metadata support. Mainly because for some protocols, for example HTTPS/1.1 over TLS, acquisition generally doesn’t require additional metadata objects, whereas in order to support delivery of that protocol would require additional metadata objects.

> 	* I am not clear if HTTPS means HTTPv1.1 over TLS, HTTPv2 over TLS or both. (I think this needs some text clarification eg rename the entry as “HTTPv1.1 over TLS" ).

We should clarify this, but I think HTTPS == HTTPS/1.1, i.e. https:// URIs retrieve over TLS.

We may want to give what we call it some thought. Discussion of opportunistic TLS encryption for http:// URIs has come up in httpbis in the past so it’s probably important to make a distinction between HTTPS/1.1 (https:// URI over TLS) and HTTP/1.1 over TLS (http:// URI over TLS).

> 	* state that current spec supports HTTPv1.1 and HTTPv1.1 over TLS delivery and acquisition

The current spec would allow support for HTTP/1.1 for delivery and acquisition or HTTPS/1.1 for acquisition.

Additional metadata objects would need to be specified to support HTTPS/1.1 for content delivery, e.g. certificate & private key to use and how to distribute those securely (which we’ve side-stepped so far by assuming they would be specified in an extension).

> 	* state that all it would take to support anorther version of HTTP (eg HTTPv2 and HTTPv2 over TLS) is be to allocate the corresponding entries in the “CDNI Metadata Protocol Sub-Registry” (so these protocols can be advertised by dCDN in FCI, and can be identified as acquisition protocols in CDNI metadata).

To use them for acquisition, or to use HTTP/2 with http:// URIs, that is all that is required. To use HTTPS/2 for content delivery would require the same metadata extensions as for HTTPS/1.1.

Ben

> All the other functionality supported by the CDNI metadata spec (eg Time Window, location ACL,..) would just work for these additional protocols because these functions and associated elements are indeed protocol agnostic. 
> 
> Makes sense?
> 
> Francois
> 
> 
>> thanx!
>> 
>> --  Kevin J. Ma
>>