The document shepherd is Francois Le Faucheur. The responsible AD is Alexey Melnikov. The requested RFC status is Standards Track.
This document defines a protocol by which a downstream CDN (dCDN) may query an upstream CDN (uCDN), in a CDN Interconnection (CDNI), to retrieve metadata related to a specific content asset being delivered by the dCDN, on behalf of the uCDN. The metadata provides basic content delivery information, e.g., how to acquire the content asset, as well as optional content delivery policy information, e.g., geographic, time, and delegation restrictions. The WG believes that a standardized method/protocol for organizing and conveying metadata from a uCDN to a dCDN is needed and will be useful.
2. Review and Consensus
The protocol is a straightforward RESTful API with JSON payloads.
The metadata is organized hierarchically, starting with the host and further differentiated by URI path of the content. There was a lot of discussion early on as to whether a generic metadata interface was feasible or needed; there was concern that the complexity of designing a generic metadata interface would be prohibitive.
Much effort was put into defining how the metadata should be organized, so as to allow inheritance and override within the hierarchy, as well as metadata object reuse between hierarchies. There was broad discussion in the WG on this topic. There were requirements for being able to exchange core pieces of metadata (e.g., how to acquire content), but there was also a desire to create an extensible protocol. Multiple drafts were submitted and merged to arrive at the final design. In addition to the extensible structure of the metadata, much discussion and effort was put into making sure that transit CDNs, which may or may not understand how to enforce the metadata, are able to safely redistribute the metadata or are able to recognize when redistribution of the metadata may violate content delivery policies.
The focus of the document is on providing metadata for delivering content via HTTP. While the same metadata can be used to deliver content via HTTPS, there is no metadata defined for conveying metadata specific to setting up TLS connections between the dCDN and the end user. It was discussed within the WG, but a secure solution was not deemed within the expertise of the WG. Other solutions (e.g., LURK) could be used to address the TLS connection setup problem, and a CDNI metadata extension could be added once such a solution is available.
The metadata interface provides the same TLS guidelines as the CDNI logging, redirection, and control triggers interfaces. There has been much discussion on privacy, with respect to CDNI logging and redirection and this has been considered for the CDNI metadata interface. It should be noted that the metadata interface provides information about the uCDN and CSP policies to the dCDN. Though the metadata may contain private information, none of the information is third party end user information.
An early chair review was performed by Francois Le Faucheur, raising many editorial issues and requesting clarification on path matching, metadata override, and policy enforcement in cascaded CDN scenarios; all comments were addressed. A subsequent independent review was performed by Vijay Gurbani, raising editorial comments, ambiguities, and requests for more details and more examples; all comments were addressed. A final chair review was provided by Francois Le Faucheur, raising editorial and consistency issues; all comments were addressed. Two additional independent reviews were performed by Linda Dunbar and Jan Seedorf, raising editorial comments which were all addressed. An AppsDir early review was performed by Matt Miller, raising JSON issues, the need for more examples, and editorial issues; all comments were addressed. An early AD review was conducted by Alex Melnikov, raising a number of comments around security, proper use of RFC2119 terminology, references and autodiscovery; most comments have been addressed and the remaining ones have been discussed and are to be addressed in an upcoming version.
3. Intellectual Property
Each author has confirmed conformance with BCP 78/79.
There were no IPR disclosure made against this document.
4. Other Points
There is a downward reference for RFC5861, which is not in the DownrefRegistry.
There is a downward reference for RFC6707, which is not (yet) in the DownrefRegistry. RFC6707 is identified as a Normative Reference because its terminology is reused in this document.
The IANA Considerations registers 20 new CDNI Payload Types, one for each of the GenericMetadata objects defined in the document. Both of the designated expert reviewers for the CDNI Payload Types registry are authors of this document and have approved the additions.
The IANA Considerations creates a new "CDNI Metadata Footprint Types" registry with sufficient guidelines provided to both IANA and the designated expert reviewer. The registry defines footprint types used by both the Metadata LocationACL, as well as the footprints defined in the Footprint and Capabilities Semantics document (already approved by the IESG).
The IANA Considerations creates a new "CDNI Metadata Protocols" registry with sufficient guidelines provided to both IANA and the designated expert reviewer. The registry defines delivery and acquisition protocols used by both the Metadata ProtocolACL, as well as the DeliveryProtocol and AcquisitionProtocol capabilities defined in the Footprint and Capabilities Semantics document (already approved by the IESG).
The IANA Considerations creates a new "CDNI Metadata Auth Types" registry with sufficient guidelines provided to both IANA and the designated expert reviewer. The registry is initially empty. The initial Auth type is being defined in the URI Signing document which is preparing for WGLC.