Subject: [CDNi] Second batch of comments from review of draft-ietf-cdni-metadata-00.txt

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Fri, 26 Oct 2012 16:59:01 +0000

Hello,

Below are my second batch of comments (as an Individual).
I hope this is useful.

Francois

General comments:
=================
* When used, MUST/SHOULD/MAY are used appropriately. But I recommend you do a pass to verify that there is enough MUST to capture everything that is mandatory for an implementation. For example, I am not sure there is an explicit statement stating that all the objects/properties listed in section 3 and 4 MUST be supported.

* You provide examples of both JSON and XML encoding, which is very nice. I suggest you start driving a discussion on the list as to which should be picked. Perhaps you could try list key pros&cons of each on the list?
When you have decided , you could then replace "example encodings" by a specification of the encoding.

Specific Comments/Suggestions
==================

* Section 4.3.1 Link
"
A link object may be used in place of any of the objects described above.
"
I think this should be replaced by:
"
A link object may be used in place of any of the objects or properties described above.
" 
because for example in the Source object (Property: auth + Property: endpoints + Property: protocol) each property (e.g. Protocol) can be specified individually using a link. Is this right?

* section 4.3.2 Protocol:
"
This type only appears in Links. 
"
This is confusing because the Protocol type already appears in multiple objects , for example in 
"
4.2.1.1.  Source
      Property: auth
         Description: Authentication method to use when requesting
         content from this source.
         Type: Auth
         Mandatory-to-Specify: No.  Default is no authentication is
         required.
      Property: endpoints
         Description: Origins from which the dCDN can acquire content.
         Type: List of EndPoint
         Mandatory-to-Specify: Yes.
      Property: protocol
         Description: Protocol to use for content acquisition.
         Type: Protocol
         Mandatory-to-Specify: Yes.
"
Assuming I understand what you want to do correctly, perhaps you could call the type define din 4.3.2 with a different name e.g. "ProtocolID" and this special type would only appear inside a Link. Would that work? Or am I entirely missing what you want to do here?

* section 4.3.2 Protocol:
"
The following examples are illustrative:
   o  http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD
   o  http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH
   o  http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q
"
I think it would be useful to use a URI if that saved you from managing an IANA register (e.g. because there exist a URI that unambiguously points to the spec you want to reference e.g. http://datatracker.ietf.org/doc/rfc2616/) but that will probably not work with /rtmp/releaseP.Q. So what is the benefit of using a URI here over defining an IANA register for these protocol IDs?

* section 5:
OLD:
"
The interface can be used by a Downstream CDN to retrieve CDNI
   Metadata objects either dynamically as required by the Downstream CDN
   to process received requests (for example in response to receiving a
   CDNI Request Routing request from an Upstream CDN or in response to
   receiving a request for content from a User Agent) or in advance of
   being required.
"
NEW:
"
The interface can be used by a Downstream CDN to retrieve CDNI
   Metadata objects either dynamically as required by the Downstream CDN
   to process received requests (for example in response to receiving a
   CDNI Request Routing request from an Upstream CDN or in response to
   receiving a request for content from a User Agent) or in advance of
   being required (for example in case of Pre-positioned CDNI Metadata acquisition).
"

* section 5.2:
OLD:
"
the HostIndex which
   provides the CDNI Metadata client with a list of Hostnames that the
   upstream CDN may delegate to the downstream CDN.
"
NEW:
"
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.
"

* section 5.2:
"
The CDNI
   metadata client then makes a GET request for the URI specified in the
   href key of that Host's entry in the HostIndex.
"
I have a couple of issue with that sentence:
	1) the HostMetadata are found in the HostMatch entry for which there was a match on the Host, so the text news tweaking.
	2) while the HostMetadata may contain a href to the Metadata, I think it could also actually contain the Metadata itself. If correct then, you need to tweak text to discuss both options. If incorrect then, you may need to tweak the text in section 4 that describes HostMatch.
The same comment applies also to the following paragraph re PathMetadata.

*section 5.2:
OLD:
"
 When application level redirection (e.g.  HTTP 302 redirects) is
   being used between CDNs, it is expected that the downstream CDN will
   be able to determine the upstream CDN that redirected a particular
   request from information contained in the received request (e.g. via
   the URI in case of HTTP redirection across CDNs).
"
NEW:
"
 When application level redirection (e.g.  HTTP 302 redirects) is
   being used between CDNs, it is expected that the downstream CDN will
   be able to determine the upstream CDN that redirected a particular
   request from information contained in the received request (e.g. via
   the URI).
"

*section 5.2:
OLD:
"
In the case of DNS redirection there is not sufficient information
   carried in the DNS request from User Agents to determine the upstream
   CDN that redirected a particular request and therefore downstream
   CDNs may have to apply local policy when deciding which upstream
   CDN's metadata to apply.
"
NEW:
"
In the case of DNS redirection there is not always sufficient information
   carried in the DNS request from User Agents to determine the upstream
   CDN that redirected a particular request (e.g. when content from a given host is redirected to a given downstream CDN by more than one upstream CDN) and therefore downstream
   CDNs may have to apply local policy when deciding which upstream
   CDN metadata to apply.
"

*section5.3 Bootstrapping:
OLD:
"
   If the URI for the HostIndex object is not manually configured in the
   downstream CDN then the HostIndex URI could be discovered via the
   CDNI Control interface.  An upstream CDN would provide the URI of the
   HostIndex object to the downstream CDN via the CDNI Control
   Interface.
"
NEW:
"
Mechanism allowing the downstream CDN to discover the URI of the HostIndex are outside the scope of this document.
"
(Depending on the base protocol leveraged to support CDNI discovery in the future, it may or may not be obvious that this would be considered part of the Control Interface, so I recommend we don't try second-guess future work and leave it open)

OLD:
"
Table 3: MIME Media Types for CDNI Metadata resources
"
NEW:
"
Table 3: Example MIME Media Types for CDNI Metadata resources
"
(this is to make it clear that the table only contains a subset)

section 5.4.2:
"
Dictionary keys in JSON are case sensitive and therefore any
   dictionary key defined by this document (for example the names of
   CDNI Metadata object properties) MUST always be represented in
   lowercase.
"
Are you saying that there was no choice and they had to be represented in lower case (as suggested by "therefore") or are you saying that we need to be case sensitive so to make it simpler you have decided to make them all lower case and therefore they MUST be encoded that way? If it is the former, please explain why. If it is the latter, then adjust text.

* section 5.5:
"
   it is suggested that proprietary and/or custom property Metadata be
   identified by the "ext."
"
Why not make this a stronger statement i.e. that "ext" MUST be used for any proprietary/custom extensions?
Also, could we specify a rule to define the how to signal "the organization defining the property Metadata" e.g. FQDN in reverse order like ".com.companyA"?

* section 5.5.1:
OLD:
"
Note: Ideally, uCDNs would not delegate content requests to a dCDN
   which does not support the Metadata 
"
NEW:
"
Note: Ideally, uCDNs would never delegate content requests to a dCDN
   which does not support the "mandatory-to-enforce" Metadata 
"

* section 5.5.1:
OLD:
"
  The dCDN
   MUST evaluate all Metadata
"
NEW:
"
  This is why the dCDN
   MUST evaluate all Metadata
"

* section 5.5.2:
"
Note: Because Metadata is inherently ordered in GenericMetadata
   lists, as well as in the PathMetadata hierarchy and PathMatch lists,
   multiple conflicting Metadata types MAY be used, however, Metadata
   hierarchies MUST ensure that independent PathMatch root objects are
   used to prevent ambiguous or conflicting Metadata definitions.
"
I don't think the term PathMatch root object is well defined. I think what you want to say is that it is OK to use conflicting metadata types as long as they actually never apply to the same content. Right? It may be simpler to express it that way.

*Appendix A:
OLD:
"
   Requirements related to pre-positioning of metadata are not met
   directly by this document.  Triggering metadata pre-positioning is
   beyond the scope of the CDNI Metadata interface.  However, the
   interface as described by this document supports pulling metadata on-
   demand for the purpose of pre-positioning.
"
NEW:
"
   Requirements related to pre-positioning of metadata are met
   by this document on the assumption that other CDNI Interfaces are to be used by the upstream CDN to trigger the pre-positioning of metadata by the downstream CDN via the CDNI Metadata Interface. 
"

*Appendix A:
I think it would be useful to discuss how requirement META-7 is met:
"
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.
"

*Appendix A:
OLD:
"
Requirement META-13 relating to feedback from the downstream CDN to
   the upstream CDN with respect to metadata
"
NEW:
"
Requirement META-13 relating to feedback from the downstream CDN to
   the upstream CDN with respect to rejected metadata
"

*Appendix A:
OLD:
"
As an
   alternative, the downstream CDN may use the CDNI Logging interface to
   convey error conditions related to metadata.
"
NEW:
"
As an
   alternative, the CDNI Logging interface could be extended to convey error conditions related to metadata.
"

*Appendix A:
"
Requirement META-18 relating to surrogate cache behavior parameters
   is supported via extensibility.  However, the example parameters in
   META-18 are not described in this document.
"
I know that META-18 is listed as [LOW] but I actually think that supporting the "control of whether the query string of HTTP URI is to be ignored by surrogate cache" is actually both useful and extremely simple to add. Would you be willing to add a simple binary property indicating whether query string is to be ignored or not?
Interestingly, the Metadata was expected to include 3 types of info: info related to acquisition, info related to authorizing, info related to how to deliver:
"
Metadata properties
   describe how to acquire, authorize, and deliver content from a
   downstream CDN.
"
The Query String ignore property would be a good example of metadata related to how to deliver.

Editorials:
=======

OLD:
"
are not intended impose
"
NEW:
"
are not intended to impose
"

OLD:
"
document.Table 3
"
NEW:
"
document. Table 3
"

section 6: IANA
OLD:
"
This document requests the registration of the "application/cdni"
   MIME type.
"
NEW:
"
This document requests the registration of the "application/cdni"
   MIME Media Type under the IANA MIME Media Type registry (http://www.iana.org/assignments/media-types/index.html).

*section 5.5.2:
OLD:
"
Metadata assigned to a given content asset
"
NEW:
"
Metadata assigned to a given content
"
(asset is not part of the CDNI terminology)

Appendix A:
OLD:
"
All metadata requirements are met either directly or indirectly by
   the CDNI Metadata Interface described in this document.  The
   following paragraphs describe notable exceptions.
"
NEW:
"
All metadata requirements are met either directly or indirectly by
   the CDNI Metadata Interface described in this document, with the clarifications or exceptions 
   described in the following paragraphs.
"

OLD:
"
"
NEW:
"
"

OLD:
"
"
NEW:
"
"

---

From: "Matt Caulfield (mcaulfie)" <[email-masked]>
Date: Fri, 26 Oct 2012 18:45:24 +0000

Thank you for the detailed comments, Francois. 

Hoping we can address both your first batch and second batch of questions relatively soon.

Matt

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Francois Le Faucheur (flefauch)
Sent: Friday, October 26, 2012 12:59 PM
To: [email-masked]
Cc: [email-masked]
Subject: [CDNi] Second batch of comments from review of draft-ietf-cdni-metadata-00.txt

Hello,

Francois

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

* Section 4.3.1 Link
"

This is confusing because the Protocol type already appears in multiple objects , for example in "

* section 5:
OLD:
"

* section 5.2:
OLD:
"
the HostIndex which

* section 5.2:
"
The CDNI

*section 5.2:
OLD:
"

*section 5.2:
OLD:
"

OLD:
"

section 5.4.2:
"

* section 5.5:
"

* section 5.5.1:
OLD:
"

* section 5.5.1:
OLD:
"
  The dCDN

* section 5.5.2:
"

*Appendix A:
OLD:
"

*Appendix A:

*Appendix A:
OLD:
"

*Appendix A:
OLD:
"
As an

*Appendix A:
"

Editorials:
=======

OLD:
"
are not intended impose
"
NEW:
"

OLD:
"
document.Table 3
"
NEW:
"
document. Table 3
"

section 6: IANA
OLD:
"

*section 5.5.2:
OLD:
"

Appendix A:
OLD:
"

OLD:
"
"
NEW:
"
"

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

---

From: "Francois Le Faucheur (flefauch)" <[email-masked]>
Date: Wed, 31 Oct 2012 18:05:01 +0000

As I just reviewed cdni-framework, I noticed the text in there (in section "4.6.  Metadata Interface") reflecting the earlier WG agreement to allow the uCDN to enforce access control checks itself. And in particular the following text:
"
As a consequence, the Metadata interface must provide a
   means for the uCDN to express its desire to retain enforcement
   for itself.  For example, this might be done by including a "check
   with me" flag in the metadata associated with certain content.
"
I believe this needs to be added to the set of metadata properties currently specified.

When you specify its detailed semantics. I'd suggest that you indicate that when the flag is set, the dCDN should perform the "check-with-uCDN" after validation of access controls that are present inside metadata. In other words, I'd picture the "Check-with-uCDN" as something that can be used "in addition" to access control rules that may be distributed to dCDN and not "instead of". This way:
	* if the uCDN wants to have full control, it does not advertise any access control in CDNI metadata
	* if the uCDN wants to delegate some simple validations (e.g. time-window specific to a content range) and enforce on top of that some finer-grain access control (e.g. per user), it can do so by advertising simple access control in CDNI Metadata + "Check-with-me" flag. This allows filtering of invalid requests (and possibly DOS attacks) in dCDN and scales better.