Skip to main content

Shepherd writeup
draft-ietf-cdni-metadata

1. Summary

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