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

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

Francois,

Some comments inline.

On 20 Mar 2014, at 18:33, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

> *** section 4.2.2, 4.2.3 and 4.2.4.
> It appears that the three types of allow/deny (LocationACL, TimeWindowACL and ProtocolACL) and independent of each other.
> So I can say , for this content:
> 	(i) allow it in this Footprint and block it everywhere else

Yes

> 	(ii) allow it in this timewindow and block it at any other time.

Yes

and you can also express: allow it in this footprint for this time window and block it from any other footprint or in any other time window.

> Is it possible to say , for this content:
> 	(i) allow it in this timewindow from this footprint

> 	(ii) allow it in a different timewindow ffrom this other footprint

> 	(iii) block it otherwise?

No

> Either way, can you ensure there is a discussion about that (perhpas it comes up further down in the document and I have not seen it)?
> If you feel this extra flexibility is not needed, then please state so (and ideally indicate whether it could be added in teh future without breaking all the current object structure). If this flexibility is supported , then please add a note/example explaining how. 

If we want to support policies that allow us to express complex combinations of different types of ACL that could be done but I think it introduces quite a bit of extra complexity so I’d like to understand the use case for needing it better first.

Do content providers rely on CDNs to enforce such combinations of different time windows in different footprints. Or do they use ACLs in the CDN to enforce broad policy by footprint and/or time window and use other mechanisms such as URI signing & not returning URIs to User Agents outside of the time window by their CMS for more fine grained control?

> *** section 4.2.4
> “
>     Property: action
>         Description: Defines whether the rule specifies protocols to
>         allow or deny.
> ...
>      Property: direction
>         Description: Defines whether the ProtocolRule specifies
>         protocols for acquisition or delivery.
> “
> I don’t quite get the semantics of this object when direction=acquisition. 
> If it conditions how the dCDN is meant to change protocol to acquire the content , then it shoudl not be cast as an allow/deny, but probably more as  part of the “source” object that defines acquisition behaviour.

I don’t remember why the direction property got introduced and I’m struggling to think of a reason for it. Protocol ACLs are for defining delivery protocols. Acquisition protocols should be specified in the Source object.

Unless one of my co-authors can recall why we introduced it, I suggest we remove the direction property altogether.

> *** section 4.2.6:
> "An Auth object defines authentication and authorization methods “ while 4.2.5 says "authorization methods “. Is it authorization  or both authentication and authorisation?

Good question. I think it can be either. IIRC we’re reusing the same Auth object to convey Authorisation of User Agent requests (if it’s included in a HostMetadata or PathMetadata object) and also Authentication and/or Authorisation to an Acquisition Source (if it is included in the auth property of a Source object).

That’s probably not obvious because we don’t actually specify Auth types that cover authorisation of user agent requests.

> *** section 4.2.7
> “
>         Mandatory-to-Specify: No.  Default is to consider query string
>         parameters when comparing URIs or to rely on other properties
>         of the Cache object.
> “ 
> What does “rely on other properties of the Cache object” actually mean? there is no other properties in that object.

I’m not sure to be honest. I think we anticipated having other modifiers in the Cache object at some point, which we never included in the end, but I don’t recall.

> *** general question about multiple instances of objects.
> Is it correct that one expects only a single instance of top level objects inside a given generic metadata object?
> For example, there shoudl only be a single sources Metadata object (which obvisouly can contain a list), but I should not have two sources, right?

Correct.

> Is this explicitely stated somewhere? Can you ensure it is stated and it is also stated what happens if you receive two of the same objects (only keep the first one? in case of transit, redistribute or drop the other instances?)

I think we can say that uCDN MUST NOT include more than one of the same object and that if they do then dCDN SHOULD use the first one in the list.

I don’t have a strong opinion one way or the other in the case of transit. 
 
> *** section 6.2 :
> “
> If any
>   PathMetadata match the request (and are linked rather than embedded),
>   the CDNI metadata client makes another GET request for the
>   PathMetadata.
> "
> The fact that the text says “match” instead of “matches” raises teh question of what hapens when more than one does match. Looking back at 4.1.3, I don’t see the answer to that question. I may have already commented on that question. In any case, please make sure this is specified (I would suggest  in 4.1.3 and possibly in section 6.2 where you describe the un-pilling of metadata).

I’d suggest first match wins, but you’re right we should specify it somewhere.

Ben

---

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

> Do content providers rely on CDNs to enforce such combinations of different time windows in different footprints. Or do they use ACLs in the CDN to enforce broad policy by footprint and/or time win…

I am not arguing we need the extra flexibility. But I recommend that the text makes it clear as to what the current properties allow and don’t allow (eg along the lines of what is said above).

If one wnated to add the extra flexibility later, do you have a feel for whether this could be achieved by extending the current properties ? or would one have to define completely new properties superseding the current ones?

> Unless one of my co-authors can recall why we introduced it, I suggest we remove the direction property altogether.

That works for me.

> Good question. I think it can be either. IIRC we’re reusing the same Auth object to convey Authorisation of User Agent requests (if it’s included in a HostMetadata or PathMetadata object) and also…

That’s a good explanation. Can you convey that in the document, and make sure “authentication”,  “authorization” and "authentication and authorization” are used accurately ?

> I’m not sure to be honest. I think we anticipated having other modifiers in the Cache object at some point, which we never included in the end, but I don’t recall.

So you could just remove “rely on other properties of the Cache object”, right?

> I think we can say that uCDN MUST NOT include more than one of the same object and that if they do then dCDN SHOULD use the first one in the list.

That works for me. 
When crafting the final text, please think carefully about whether the statement applies to all objects or whether it only applies to a subset of objects (which obviously need to be identified).

> I don’t have a strong opinion one way or the other in the case of transit. 

I don’t have a strong view either.
“redistribute" has the benefit that if a 2nd instance is used in some unexpected vendor-specifc way, this can be propagated.
“drop” has the benefit of removing what would normally be useless redundant information.
Perhaps a SHOUL drop is the way to go (ie drop unless you know better).

> I’d suggest first match wins, but you’re right we should specify it somewhere.

Good.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Mon, 28 Apr 2014 11:35:00 +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.

On 20 Mar 2014, at 18:33, Francois Le Faucheur (flefauch) <[email-masked]> wrote:

> I got down to 6.2. and need to stop now. This is a loooooong review.
> Francois
> 
> 
> *** section 4.2.2.2
> OLD:
> “
> Property: type
> “
> NEW
> “
> Property: footprint-type
> “
> (end reflect that change in rest of the document if needed) 

Done

> *** section 4.2.2.2
> OLD:
> “
> Property: value
> “
> NEW
> “
> Property: footprint-value
> “
> (end reflect that change in rest of the document if needed) 

Done

> *** section 4.2.3 and 4.2.3.1
> both have the same property name ie "Property: times”. Perhaps the property in 4.2.3.1 could be renamed to something like  “windows”

Done

> *** section 4.2.4
> 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

> If you feel this extra flexibility is not needed, then please state so (and ideally indicate whether it could be added in teh future without breaking all the current object structure). If this flex…

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

> If it conditions how the dCDN is meant to change protocol to acquire the content , then it shoudl not be cast as an allow/deny, but probably more as  part of the “source” object that defines acquis…

Done

> *** section 4.2.4
> It is not obvious to me what are the rules when things are partially specified. For example, if it says Protocol1/allow/acquisition, then is delivery of Protocol1 allowed or denied? Can you add an explicit statement about that?

Done

> *** section 4.2.4.1:
> "Type: Enumeration [allow|deny]+” : I assume the “+” should be removed?

Done.

> *** section 4.2.5
> “
>   Authorization Metadata define content authorization methods.
>      Property: methods
>         Description: Options for authenticating content requests.  All
>         options in the list are equally valid.
> "
> I assume “Options for authenticating” should read “Options for authorising”, right?
> 
> Also, similar to previous comments, I’d suggest having slightly more explicit property names. So I’d rename “methods” into something like “auth-methods"
> 
> “Content authorisation methods” is not clear. ie it is not the content that is authorised, but the request. so perhaps replace with “Content request authorisation methods” or “Delivery authorisation methods”
> 
> "All options in the list are equally valid.” I think you mean more something like “Delivery for a content request is authorized if any of the authorisation method in the list is satisfied for that request”.

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

> *** section 4.2.6:
> I understand that Auth objects are meant to be listed within the “Authorization Metadata” object (2.6.5) so shoudl section 2.4.6 not be numbered 2.4.5.1 in line with what is done above for other objects?  Is there something different here?

Done

> "An Auth object defines authentication and authorization methods “ while 4.2.5 says "authorization methods “. Is it authorization  or both authentication and authorisation?

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

> *** section 4.2.6 
> again “property: type” —> “property: auth-type”?

Done

> *** section 4.2.6:
> “
> 4.2.6.  Auth
>   An Auth object defines authentication and authorization methods to be
>   used during content delivery and content acquisition.
> 
>      Property: type
>         Description: Registered Auth type (see Section 7.1.1.3).
> ...
> 
>      Property: value
>         Description: Auth object conforming to the specification
>         associated with the registered Auth type.
> “
> There is some circular reference here: Auth is an object with a type and a value, and the value is an Auth object. I think you need to tweak wording of  the Description for the value.

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

> *** section 7.1.1.3 
> I think the section title (and registry) should be renamed from "Authentication Sub-Registry” to "Authentication Type Sub-Registry” (and “CDNI Metadata Auth” to "CDNI Metadata Auth Type”)
> 
> I recommend the text be more explicit that the IANA has to create a registry (or sub-registry) for the "CDNI Metadata Auth Type”.
> 
> s/Type name/Type/

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

> What does “rely on other properties of the Cache object” actually mean? there is no other properties in that object.

Done

> Is this explicitely stated somewhere? Can you ensure it is stated and it is also stated what happens if you receive two of the same objects (only keep the first one? in case of transit, redistribut…

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

> *** section 4.3.1:
> "      Property: type” —> "      Property: metadata-object-type”

Done

> *** section 4.3.2-4.3.5
> 4.3.2 explicitely states a Type and Mandatory-to-Specify while 4.3.3, 4.3.4 and 4.3.5 do not. Shoudln’t all sections state the Type and Mandatory-to-Specify?

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

> *** Section 5:
> OLD:
> “
> any delegated requests for that content will fail, so
>   there is no reason to delegate those requests.
> “
> NEW:
> “
> any delegated requests for that content will fail, so
>   the uCDN is likely to want to avoid delegating those requests to that dCDN.
> “

Done

> /If a the/if the/

Done

> OLD:
> “
> so there is likely
>   no reason to delegate those requests.
> “
> NEW:
> “
> so again the uCDN is likely to want to avoid delegating those requests to that dCDN.”

Done

> *** section 5:
> OLD:
> "
> The CDNI Footprint and Capabilities Interface provides a means of
>   advertising capabilities from dCDN to uCDN.  Support for optional
>   metadata and support for optional metadata values may be advertised
>   using the capabilities interface.
> “
> NEW:
> “
> The CDNI Footprint and Capabilities Interface (FCI) [I-D.ietf-cdni-framework] provides a means of
>   advertising capabilities from dCDN to uCDN.  Support for optional
>   metadata and support for optional metadata values may be advertised
>   using the FCI.
> “

Done

> *** section 5:
> OLD:
> “
> for the metadata defined in Section 4.2
> “
> NEW:
> “
> for the metadata defined in the present document.
> “

Done

> *** section 5.
> I understand there is no “optional” metadata that require capability adevrtisemnet (ie only optional values require advertisement). Since the text explained the two cases previously, I would suggest adding a statement right befrore section 5.1 stating that the present document does not define optional metadata so no capabilities advertisement are required for that, but it defines two metadata objects with optional values and the corresponding capabilities are specified in section 5.1 and 5.2.

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

> *** section 5
> Since no capabilities are defined for the Footprint types, this infers that an implementation must implement all of the footprint types defined in section 7.1.1.1. Right?
> Where is it specified in the document that implementation MUST implement all the Footprint types? Can you make sure the mandatory to implement aspects of this are clearly specified somewhere?

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

> *** section 5.1:
> I have the same comment as for section 4.2.4. ie I am not clear on why the protocol rules for acquisition as referred to as “authorisation”.
> I don’t think you need to re-explain why  it is useful to adevrtise the capabilities (eg to allow proper redirection) since this was explaine in section 5 in a generic way (and more accurately since it brought up the notion of mandatory-to-enforce).
> So I’d shorten the text in that section.
> 
> Also , this does not actually specifiy the actual capabilities nor provide a ref to where they will be defined. Can you add a statement, along the lines of “the corresponding capabilities and protocol to advertise them are outside the scope of this document and are expected to be specified in the FCI. 

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

> *** section 5.2
> I don’t think you need to re-explain why  it is useful to adevrtise the capabilities (eg to allow proper redirection) since this was explaine in section 5 in a generic way (and more accurately since it brought up the notion of mandatory-to-enforce).
> OLD:
> “
> The Authorization object contains a list of Auth values.  The dCDN
>   MUST advertise which authorization algorithms it supports so that the
>   uCDN knows what type of content requests it can redirect to the dCDN.
>   If the dCDN does not support a given authorization algorithm, the
>   uCDN should not delegate requests requiring that algorithm to the
>   dCDN as the dCDN will not be able to properly acquire the content or
>   enforce delivery restrictions.
> “
> NEW:
> “
> The Authorization object contains a list of Auth values. The dCDN
>   MUST advertise in its FCI capabilities which authorization types it supports.
> "
> 
> Also , this does not actually specifiy the actual capabilities nor provide a ref to where they will be defined. Can you add a statement, along the lines of “the corresponding capabilities and protocol to advertise them are outside the scope of this document and are expected to be specified in the FCI. 

Done.

> *** section 6:
> OLD:
> “
> for example in response to receiving a CDNI Request Routing request from an Upstream CDN
> "
> NEW:
> “
> for example in response to a query from an Upstream CDN over the CDNI Request Routing Redirection interface (RI) [I-D.ietf-cdni-redirection].
> “
> where [I-D.ietf-cdni-redirection] is added to the list of Informative References.

Done

> *** section 6:
> s/prepositioned CDNI Metadata acquisition/Pre-positioned CDNI Metadata acquisition/
> (just to align to terminology of RFC6707)

Done

> *** Section 6:
> 2nd paragraph. I suggest breaking it into two sentences for easier readability.

Done

> *** section 6:
> OLD
> “
> The CDNI Metadata interface is built on the principles of RESTful web
>   services.  This means that requests and responses over the interface
>   are built around the transfer of representations of hyperlinked
>   resources.
> “
> NEW:
> “
> The CDNI Metadata interface is built on the principles of RESTful web
>   services.  In particular, this means that requests and responses over the interface
>   are built around the transfer of representations of hyperlinked
>   resources.
> “
> (my point is that the second sentence does not hold as a definition of RESTful web services”.

Done

> *** section 6:
> I suggest that the first time the phrase “CDNI server” is use, it is clarified that this refers to the uCDN side of the CDNI Metadata interface.
> Same for “CDNI client”.

Done

> *** section 6.1:
> OLD:
> “
> Servers implementing the CDNI Metadata
>   interface MUST support the HTTP GET and HEAD methods.
> “
> NEW:
> “
> An implementation of the CDNI Metadata server MUST support the HTTP GET and HEAD methods.
> “
> 
> What about the client? MUST support GET and MAY support HEAD?

Done

> *** section 6.1:
> OLD:
> “
> Server implementations of
>   this interface SHOULD reject all methods other than GET and HEAD.
> “
> NEW:
> “
> An implementation of the CDNI Metadata server SHOULD reject all methods other than GET and HEAD.
> “

Done

> *** section 6.1: last paragraph
> Is there a reason the may statements are not “MAY” statements?
> (and then adjust text to say “an implementation of the CDNI Metatadat server …”

Done

> *** section 6.2
> “
>   In the general case a CDNI Metadata server makes each instance of an
>   addressable CDNI Metadata object available via a unique URI and
>   therefore in order to retrieve CDNI Metadata, a CDNI Metadata client
>   first makes a HTTP GET request for the URI of the HostIndex which
>   provides the CDNI Metadata client with a list of Hostnames for which
>   the upstream CDN may delegate content delivery to the downstream CDN.
> “
> This makes it sounds like it is only in the general case that the client starts with a GET on HostIndex. Is this not always true?
> If it is then , how about just saying:
> “
>   To retrieve CDNI metadata, a CDNI Metadata client
>   first makes a HTTP GET request for the URI of the HostIndex which
>   provides the CDNI Metadata client with a list of Hostnames for which
>   the upstream CDN may delegate content delivery to the downstream CDN.
> “

Done

> The fact that the text says “match” instead of “matches” raises teh question of what hapens when more than one does match. Looking back at 4.1.3, I don’t see the answer to that question. I may have…

Done

> *** section 6.2:
> s/the downstream CDN must decide/the downstream CDN needs to determine/

Done

Ben