tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search

RFC 8006

 
 
 

Content Delivery Network Interconnection (CDNI) Metadata

Part 3 of 3, p. 43 to 66
Prev Section

 


prevText      Top      ToC       Page 43 
6.  CDNI Metadata Interface

   This section specifies an interface to enable a dCDN to retrieve CDNI
   Metadata objects from a uCDN.

   The interface can be used by a dCDN to retrieve CDNI Metadata objects
   in either of two ways:

   o  Dynamically, as required by the dCDN to process received requests
      -- for example, in response to a query from a uCDN over the CDNI
      Request Routing Redirection interface (RI) [RFC7975] or in
      response to receiving a request for content from a User Agent.

   o  In advance of being required -- for example, in the case of
      pre-positioned CDNI Metadata acquisition, initiated through the
      "CDNI Control interface / Triggers" (CI/T) interface [RFC8007].

   The CDNI Metadata interface is built on the principles of HTTP web
   services.  In particular, this means that requests and responses over
   the interface are built around the transfer of representations of
   hyperlinked resources.  A resource in the context of the CDNI
   Metadata interface is any object in the object model (as described in
   Sections 3 and 4).

   CDNI Metadata servers (i.e., servers in the uCDN) are free to assign
   whatever structure they desire to the URIs for CDNI Metadata objects,
   and CDNI Metadata clients MUST NOT make any assumptions regarding the
   structure of CDNI Metadata URIs or the mapping between CDNI Metadata
   objects and their associated URIs.  Any URIs present in the examples
   in this document are purely illustrative and are not intended to
   impose a definitive structure on CDNI Metadata interface
   implementations.

Top      Up      ToC       Page 44 
6.1.  Transport

   The CDNI Metadata interface uses HTTP as the underlying protocol
   transport [RFC7230].

   The HTTP method in the request defines the operation the request
   would like to perform.  A server implementation of the CDNI Metadata
   interface MUST support the HTTP GET and HEAD methods.

   The corresponding HTTP response returns the status of the operation
   in the HTTP status code and returns the current representation of the
   resource (if appropriate) in the response body.  HTTP responses that
   contain a response body SHOULD include an entity-tag (ETag) to enable
   validation of cached versions of returned resources.

   As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata
   server implementations MAY make use of any HTTP feature when
   implementing the CDNI Metadata interface; for example, a CDNI
   Metadata server MAY make use of HTTP's caching mechanisms to indicate
   that the returned response/representation can be reused without
   re-contacting the CDNI Metadata server.

6.2.  Retrieval of CDNI Metadata Resources

   In the general case, a CDNI Metadata server makes CDNI Metadata
   objects available via unique URIs; thus, in order to retrieve CDNI
   Metadata, a CDNI Metadata client (i.e., a client in the dCDN) first
   makes an HTTP GET request for the URI of the HostIndex, which
   provides an array of hostnames for which the uCDN can delegate
   content delivery to the dCDN.

   In order to retrieve the CDNI Metadata for a particular request, the
   CDNI Metadata client processes the received HostIndex object and
   finds the corresponding HostMetadata entry (by matching the hostname
   in the request against the hostnames listed in the HostMatch
   objects).  If the HostMetadata is linked (rather than embedded), the
   CDNI Metadata client then makes an HTTP GET request for the URI
   specified in the "href" property of the Link object, which points to
   the HostMetadata object itself.

   In order to retrieve the most specific metadata for a particular
   request, the CDNI Metadata client inspects the HostMetadata for
   references to more-specific PathMetadata objects (by matching the URI
   path in the request against the path-pattern property items in any
   PathMatch objects listed in the HostMetadata object).  If a
   PathMetadata object is found to match (and is linked rather than
   embedded), the CDNI Metadata client makes another HTTP GET request
   for the PathMetadata.  Each PathMetadata object can also include

Top      Up      ToC       Page 45 
   references to additional more-specific metadata.  If this is the
   case, the CDNI Metadata client continues requesting PathMatch and
   PathMetadata objects recursively.  The CDNI Metadata client repeats
   this approach of processing metadata objects and retrieving (via HTTP
   GETs) any linked objects until it has all the metadata objects it
   requires in order to process the redirection request from the uCDN or
   the content request from a User Agent.

   In cases where a dCDN is not able to retrieve the entire set of CDNI
   Metadata associated with a User Agent request, or it has retrieved
   that metadata but it is stale according to standard HTTP caching
   rules and cannot be revalidated -- for example, because the uCDN is
   unreachable or returns an HTTP 4xx or 5xx status in response to some
   or all of the dCDN's CDNI Metadata requests -- the dCDN MUST NOT
   serve the requested content.

   Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to
   determine which uCDN's CDNI Metadata interface should be used to
   handle a particular User Agent request.

   When HTTP redirection (e.g., HTTP 302 redirects) is being used
   between CDNs, it is expected that the dCDN will be able to determine
   the uCDN that redirected a particular request from information
   contained in the received request (e.g., via the URI).  With
   knowledge of which uCDN routed the request, the dCDN can choose the
   correct uCDN from which to obtain the HostIndex.  Note that the
   HostIndexes served by each uCDN can be unique.

   In the case of DNS redirection, there is not always sufficient
   information carried in the DNS request from User Agents to determine
   the uCDN that redirected a particular request (e.g., when content
   from a given host is redirected to a given dCDN by more than one
   uCDN); therefore, dCDNs will have to apply local policy when deciding
   which uCDN's CDNI Metadata interface to use.

6.3.  Bootstrapping

   The URI for the HostIndex object of a given uCDN needs to be
   configured in the dCDN.  All other objects/resources are then
   discoverable from the HostIndex object by following any links in the
   HostIndex object, and through the referenced HostMetadata and
   PathMetadata objects and their GenericMetadata sub-objects.

   Manual configuration of the URI for the HostIndex object is outside
   the scope of this document.

Top      Up      ToC       Page 46 
6.4.  Encoding

   CDNI Metadata objects MUST be encoded as I-JSON objects [RFC7493]
   containing a dictionary of (key,value) pairs where the keys are the
   property names and the values are the associated property values.

   The keys of the dictionary are the names of the properties associated
   with the object and are therefore dependent on the specific object
   being encoded (i.e., dependent on the CDNI Payload Type of the
   returned resource).  Likewise, the values associated with each
   property (dictionary key) are dependent on the specific object being
   encoded (i.e., dependent on the CDNI Payload Type of the returned
   resource).

   Dictionary keys (properties) in I-JSON are case sensitive.  By
   convention, any dictionary key (property) defined by this document
   (for example, the names of CDNI Metadata object properties) MUST be
   lowercase.

6.5.  Extensibility

   The set of GenericMetadata objects can be extended with additional
   (standards-based or vendor-specific) metadata objects through the
   specification of new GenericMetadata objects.  The GenericMetadata
   object defined in Section 4.1.7 specifies a type field and a type-
   specific value field that allow any metadata to be included in either
   the HostMetadata or PathMetadata arrays.

   As with the initial GenericMetadata types defined in Section 4.2,
   future GenericMetadata types MUST specify the information necessary
   for constructing and decoding the GenericMetadata object.

   Any document that defines a new GenericMetadata type MUST:

   1.  Register the CDNI Payload Type [RFC7736] used to identify the new
       GenericMetadata type being specified.

   2.  Define the set of properties associated with the new
       GenericMetadata object.  GenericMetadata MUST NOT contain a
       property named "href" because doing so would conflict with the
       ability to detect Link objects (see Section 4.3.1).

   3.  For each property, define a name, description, type, and whether
       or not the property is mandatory-to-specify.

   4.  Describe the semantics of the new type, including its purpose,
       and provide a use case to which it applies, including an example
       encoded in I-JSON.

Top      Up      ToC       Page 47 
   5.  Describe the security and privacy consequences, for both the User
       Agent and the CDNs, of the new GenericMetadata object.

   6.  Describe any relation to, conflict with, or obsolescence of other
       existing CDNI Metadata objects.

   Note: In the case of vendor-specific extensions, vendor-identifying
   CDNI Payload Type names will decrease the possibility of
   GenericMetadata type collisions.  It is RECOMMENDED that any
   vendor-specific extensions use vendor-identifying CDNI Payload Type
   names.

6.6.  Metadata Enforcement

   At any given time, the set of GenericMetadata types supported by the
   uCDN might not match the set of GenericMetadata types supported by
   the dCDN.

   In cases where a uCDN sends metadata containing a GenericMetadata
   type that a dCDN does not support, the dCDN MUST enforce the
   semantics of the mandatory-to-enforce property.  If a dCDN does not
   understand or is unable to perform the functions associated with any
   mandatory-to-enforce metadata, the dCDN MUST NOT service any requests
   for the corresponding content.

   Note: Ideally, uCDNs would not delegate content requests to a dCDN
   that does not support the mandatory-to-enforce metadata associated
   with the content being requested.  However, even if the uCDN has
   a priori knowledge of the metadata supported by the dCDN (e.g., via
   the FCI or through out-of-band negotiation between CDN operators),
   metadata support can fluctuate or be inconsistent (e.g., due to
   miscommunication, misconfiguration, or temporary outage).  Thus, the
   dCDN MUST always evaluate all metadata associated with redirection
   and content requests and reject any requests where
   mandatory-to-enforce metadata associated with the content cannot be
   enforced.

6.7.  Metadata Conflicts

   It is possible that new metadata definitions will obsolete or
   conflict with existing GenericMetadata (e.g., a future revision of
   the CDNI Metadata interface could redefine the Auth GenericMetadata
   object or a custom vendor extension could implement an alternate Auth
   metadata option).  If multiple metadata (e.g., MI.Auth.v2,
   vendor1.Auth, and vendor2.Auth) all conflict with an existing
   GenericMetadata object (i.e., MI.Auth) and all are marked as

Top      Up      ToC       Page 48 
   mandatory-to-enforce, it could be ambiguous as to which metadata
   should be applied, especially in the case of overlapping
   functionality.

   As described in Section 3.3, metadata override only applies to
   metadata objects of the same exact type found in HostMetadata and
   nested PathMetadata structures.  The CDNI Metadata interface does not
   support enforcement of dependencies between different GenericMetadata
   types.  It is the responsibility of the CSP and the CDN operators to
   ensure that metadata assigned to a given piece of content do not
   conflict.

   Note: Because metadata is inherently ordered in HostMetadata and
   PathMetadata arrays, as well as in the PathMatch hierarchy, multiple
   conflicting metadata types MAY be used; however, metadata hierarchies
   SHOULD ensure that independent PathMatch root objects are used to
   prevent ambiguous or conflicting metadata definitions.

6.8.  Versioning

   The version of CDNI Metadata objects is conveyed inside the CDNI
   Payload Type that is included in either (1) the HTTP Content-Type
   header (for example, "Content-Type: application/cdni;
   ptype=MI.HostIndex" when retrieved via a link) or (2) in the link
   type (Section 4.3.1), generic-metadata-type (Section 4.1.7), or
   auth-type (Section 4.2.7) properties in the JSON payload.  The CDNI
   Payload Type uniquely identifies the specification defining that
   object, including any relation to, conflicts with, or obsolescence of
   other metadata.  There is no explicit version mapping requirement;
   however, for ease of understanding, metadata creators SHOULD make new
   versions of metadata easily visible via the CDNI Payload Type, e.g.,
   by appending a version string.  Note: A version string is optional on
   the first version (e.g., MI.HostIndex) but could be added for
   subsequent versions (MI.HostIndex.v2, MI.HostIndex.v3, etc.).

   Except when referenced by a Link object, nested metadata objects
   (i.e., structural metadata below the HostIndex; and Source,
   LocationRule, TimeWindowRule, ProtocolRule, Footprint, and TimeWindow
   objects) can be serialized into a JSON payload without explicit CDNI
   Payload Type information.  The type is inferred from the outer
   structural metadata, GenericMetadata, or Auth object CDNI Payload
   Type.  To avoid ambiguity when revising nestable metadata objects,
   any outer metadata object(s) MUST be reversioned and allocated new
   CDNI Payload Type(s) at the same time.  For example, the MI.HostIndex
   object defined in this document contains an array of MI.HostMatch
   objects, each of which in turn contains a MI.HostMetadata object.  If
   a new MI.HostMetadata.v2 object were required, the outer MI.HostIndex
   and MI.HostMatch objects would need to be revised, e.g., to

Top      Up      ToC       Page 49 
   MI.HostIndex.v2 and MI.HostMatch.v2, respectively.  Similarly, if a
   new MI.TimeWindowRule.v2 object were required, the outer
   MI.TimeWindowACL object would need to be revised, e.g., to
   MI.TimeWindowACL.v2; however, the MI.TimeWindowRule.v2 object could
   still contain MI.TimeWindow objects, if so specified.

   HTTP requests sent to a metadata server SHOULD include an Accept
   header with the CDNI Payload Type of the expected object.  Metadata
   clients can specify multiple CDNI Payload Types in the Accept header;
   for example, if a metadata client is capable of processing two
   different versions of the same type of object (defined by different
   CDNI Payload Types), it might decide to include both in the Accept
   header.

6.9.  Media Types

   All CDNI Metadata objects use the media type "application/cdni".  The
   CDNI Payload Type for each object then contains the object name of
   that object as defined by this document, prefixed with "MI.".
   Table 4 lists the CDNI Payload Types for the metadata objects
   (resources) specified in this document.

           +-----------------------+--------------------------+
           | Data Object           | CDNI Payload Type        |
           +-----------------------+--------------------------+
           | HostIndex             | MI.HostIndex             |
           | HostMatch             | MI.HostMatch             |
           | HostMetadata          | MI.HostMetadata          |
           | PathMatch             | MI.PathMatch             |
           | PatternMatch          | MI.PatternMatch          |
           | PathMetadata          | MI.PathMetadata          |
           | SourceMetadata        | MI.SourceMetadata        |
           | Source                | MI.Source                |
           | LocationACL           | MI.LocationACL           |
           | LocationRule          | MI.LocationRule          |
           | Footprint             | MI.Footprint             |
           | TimeWindowACL         | MI.TimeWindowACL         |
           | TimeWindowRule        | MI.TimeWindowRule        |
           | TimeWindow            | MI.TimeWindow            |
           | ProtocolACL           | MI.ProtocolACL           |
           | ProtocolRule          | MI.ProtocolRule          |
           | DeliveryAuthorization | MI.DeliveryAuthorization |
           | Cache                 | MI.Cache                 |
           | Auth                  | MI.Auth                  |
           | Grouping              | MI.Grouping              |
           +-----------------------+--------------------------+

           Table 4: CDNI Payload Types for CDNI Metadata Objects

Top      Up      ToC       Page 50 
6.10.  Complete CDNI Metadata Example

   A dCDN requests the HostIndex and receives the following object with
   a CDNI Payload Type of "MI.HostIndex":

   {
     "hosts": [
       {
         "host": "video.example.com",
         "host-metadata": {
           "type": "MI.HostMetadata",
           "href": "https://metadata.ucdn.example/host1234"
         }
       },
       {
         "host": "images.example.com",
         "host-metadata": {
           "type": "MI.HostMetadata",
           "href": "https://metadata.ucdn.example/host5678"
         }
       }
     ]
   }

   If the incoming request has a Host header with "video.example.com",
   then the dCDN would fetch the HostMetadata object from
   "https://metadata.ucdn.example/host1234" expecting a CDNI Payload
   Type of "MI.HostMetadata":

   {
     "metadata": [
       {
         "generic-metadata-type": "MI.SourceMetadata",
         "generic-metadata-value": {
           "sources": [
             {
               "endpoint": ["acq1.ucdn.example"],
               "protocol": "http/1.1"
             },
             {
               "endpoint": ["acq2.ucdn.example"],
               "protocol": "http/1.1"
             }
           ]
         }
       },

Top      Up      ToC       Page 51 
       {
         "generic-metadata-type": "MI.LocationACL",
         "generic-metadata-value": {
           "locations": [
             {
               "footprints": [
                 {
                   "footprint-type": "ipv4cidr",
                   "footprint-value": ["192.0.2.0/24"]
                 },
                 {
                   "footprint-type": "ipv6cidr",
                   "footprint-value": ["2001:db8::/32"]
                 },
                 {
                   "footprint-type": "countrycode",
                   "footprint-value": ["us"]
                 },
                 {
                   "footprint-type": "asn",
                   "footprint-value": ["as64496"]
                 }
               ],
               "action": "deny"
             }
           ]
         }
       },
       {
         "generic-metadata-type": "MI.ProtocolACL",
         "generic-metadata-value": {
           "protocol-acl": [
             {
               "protocols": [
                 "http/1.1"
               ],
               "action": "allow"
             }
           ]
         }
       }
     ],

Top      Up      ToC       Page 52 
     "paths": [
       {
         "path-pattern": {
           "pattern": "/videos/trailers/*"
         },
         "path-metadata": {
           "type": "MI.PathMetadata",
           "href": "https://metadata.ucdn.example/host1234/pathABC"
         }
       },
       {
         "path-pattern": {
           "pattern": "/videos/movies/*"
         },
         "path-metadata": {
           "type": "MI.PathMetadata",
           "href": "https://metadata.ucdn.example/host1234/pathDEF"
         }
       }
     ]
   }

   Suppose that the path of the requested resource matches the
   "/videos/movies/*" pattern; the next metadata requested would be for
   "https://metadata.ucdn.example/host1234/pathDEF" with an expected
   CDNI Payload Type of "MI.PathMetadata":

   {
     "metadata": [],
     "paths": [
       {
         "path-pattern": {
           "pattern": "/videos/movies/hd/*"
         },
         "path-metadata": {
           "type": "MI.PathMetadata",
           "href":
             "https://metadata.ucdn.example/host1234/pathDEF/path123"
         }
       }
     ]
   }

Top      Up      ToC       Page 53 
   Finally, if the path of the requested resource also matches the
   "/videos/movies/hd/*" pattern, the dCDN would also fetch the
   following object from
   "https://metadata.ucdn.example/host1234/pathDEF/path123" with a CDNI
   Payload Type of "MI.PathMetadata":

   {
     "metadata": [
       {
         "generic-metadata-type": "MI.TimeWindowACL",
         "generic-metadata-value": {
           "times": [
             "windows": [
               {
                 "start": "1213948800",
                 "end": "1478047392"
               }
             ],
             "action": "allow"
           ]
         }
       }
     ]
   }

   The final set of metadata that applies to the requested resource
   includes a SourceMetadata, a LocationACL, a ProtocolACL, and a
   TimeWindowACL.

Top      Up      ToC       Page 54 
7.  IANA Considerations

7.1.  CDNI Payload Types

   This document requests the registration of the following entries
   under the "CDNI Payload Types" registry hosted by IANA:

               +--------------------------+---------------+
               | Payload Type             | Specification |
               +--------------------------+---------------+
               | MI.HostIndex             | RFC 8006      |
               | MI.HostMatch             | RFC 8006      |
               | MI.HostMetadata          | RFC 8006      |
               | MI.PathMatch             | RFC 8006      |
               | MI.PatternMatch          | RFC 8006      |
               | MI.PathMetadata          | RFC 8006      |
               | MI.SourceMetadata        | RFC 8006      |
               | MI.Source                | RFC 8006      |
               | MI.LocationACL           | RFC 8006      |
               | MI.LocationRule          | RFC 8006      |
               | MI.Footprint             | RFC 8006      |
               | MI.TimeWindowACL         | RFC 8006      |
               | MI.TimeWindowRule        | RFC 8006      |
               | MI.TimeWindow            | RFC 8006      |
               | MI.ProtocolACL           | RFC 8006      |
               | MI.ProtocolRule          | RFC 8006      |
               | MI.DeliveryAuthorization | RFC 8006      |
               | MI.Cache                 | RFC 8006      |
               | MI.Auth                  | RFC 8006      |
               | MI.Grouping              | RFC 8006      |
               +--------------------------+---------------+

7.1.1.  CDNI MI HostIndex Payload Type

   Purpose: The purpose of this Payload Type is to distinguish HostIndex
   MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.1.1

Top      Up      ToC       Page 55 
7.1.2.  CDNI MI HostMatch Payload Type

   Purpose: The purpose of this Payload Type is to distinguish HostMatch
   MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.1.2

7.1.3.  CDNI MI HostMetadata Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   HostMetadata MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.1.3

7.1.4.  CDNI MI PathMatch Payload Type

   Purpose: The purpose of this Payload Type is to distinguish PathMatch
   MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.1.4

7.1.5.  CDNI MI PatternMatch Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   PatternMatch MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.1.5

7.1.6.  CDNI MI PathMetadata Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   PathMetadata MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.1.6

Top      Up      ToC       Page 56 
7.1.7.  CDNI MI SourceMetadata Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   SourceMetadata MI objects (and any associated capability
   advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.1

7.1.8.  CDNI MI Source Payload Type

   Purpose: The purpose of this Payload Type is to distinguish Source MI
   objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.1.1

7.1.9.  CDNI MI LocationACL Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   LocationACL MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.2

7.1.10.  CDNI MI LocationRule Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   LocationRule MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.2.1

7.1.11.  CDNI MI Footprint Payload Type

   Purpose: The purpose of this Payload Type is to distinguish Footprint
   MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.2.2

Top      Up      ToC       Page 57 
7.1.12.  CDNI MI TimeWindowACL Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   TimeWindowACL MI objects (and any associated capability
   advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.3

7.1.13.  CDNI MI TimeWindowRule Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   TimeWindowRule MI objects (and any associated capability
   advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.3.1

7.1.14.  CDNI MI TimeWindow Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   TimeWindow MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.3.2

7.1.15.  CDNI MI ProtocolACL Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   ProtocolACL MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.4

7.1.16.  CDNI MI ProtocolRule Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   ProtocolRule MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.4.1

Top      Up      ToC       Page 58 
7.1.17.  CDNI MI DeliveryAuthorization Payload Type

   Purpose: The purpose of this Payload Type is to distinguish
   DeliveryAuthorization MI objects (and any associated capability
   advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.5

7.1.18.  CDNI MI Cache Payload Type

   Purpose: The purpose of this Payload Type is to distinguish Cache MI
   objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.6

7.1.19.  CDNI MI Auth Payload Type

   Purpose: The purpose of this Payload Type is to distinguish Auth MI
   objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.7

7.1.20.  CDNI MI Grouping Payload Type

   Purpose: The purpose of this Payload Type is to distinguish Grouping
   MI objects (and any associated capability advertisement)

   Interface: MI/FCI

   Encoding: see Section 4.2.8

7.2.  "CDNI Metadata Footprint Types" Registry

   IANA has created a new "CDNI Metadata Footprint Types" subregistry in
   the "Content Delivery Network Interconnection (CDNI) Parameters"
   registry.  The "CDNI Metadata Footprint Types" namespace defines the
   valid Footprint object type values used by the Footprint object
   described in Section 4.2.2.2.  Additions to the "CDNI Metadata
   Footprint Types" namespace conform to the Specification Required
   policy as defined in [RFC5226].  The Designated Expert will verify
   that new type definitions do not duplicate existing type definitions

Top      Up      ToC       Page 59 
   and prevent gratuitous additions to the namespace.  New registrations
   are required to provide a clear description of how to interpret new
   footprint types.

   The following table defines the initial values for the "CDNI Metadata
   Footprint Types" registry:

    +----------------+--------------------------------+---------------+
    | Footprint Type | Description                    | Specification |
    +----------------+--------------------------------+---------------+
    | ipv4cidr       | IPv4 CIDR address block        | RFC 8006      |
    | ipv6cidr       | IPv6 CIDR address block        | RFC 8006      |
    | asn            | Autonomous System Number (ASN) | RFC 8006      |
    | countrycode    | ISO 3166-1 alpha-2 code        | RFC 8006      |
    +----------------+--------------------------------+---------------+

7.3.  "CDNI Metadata Protocol Types" Registry

   IANA has created a new "CDNI Metadata Protocol Types" subregistry in
   the "Content Delivery Network Interconnection (CDNI) Parameters"
   registry.  The "CDNI Metadata Protocol Types" namespace defines the
   valid Protocol object values (Section 4.3.2) used by the
   SourceMetadata and ProtocolACL objects.  Additions to the Protocol
   namespace conform to the Specification Required policy as defined in
   [RFC5226], where the specification defines the Protocol Type and the
   protocol to which it is associated.  The Designated Expert will
   verify that new protocol definitions do not duplicate existing
   protocol definitions and prevent gratuitous additions to the
   namespace.

   The following table defines the initial Protocol values corresponding
   to the HTTP and HTTPS protocols:

   +-----------+----------------------+---------------+----------------+
   | Protocol  | Description          | Type          | Protocol       |
   | Type      |                      | Specification | Specifications |
   +-----------+----------------------+---------------+----------------+
   | http/1.1  | Hypertext Transfer   | RFC 8006      | RFC 7230       |
   |           | Protocol -- HTTP/1.1 |               |                |
   |           |                      |               |                |
   | https/1.1 | HTTP/1.1 over TLS    | RFC 8006      | RFC 7230,      |
   |           |                      |               | RFC 2818       |
   +-----------+----------------------+---------------+----------------+

Top      Up      ToC       Page 60 
8.  Security Considerations

8.1.  Authentication and Integrity

   A malicious metadata server, proxy server, or attacker impersonating
   an authentic uCDN CDNI Metadata interface without being detected
   could provide false metadata to a dCDN that either:

   o  Denies service for one or more pieces of content to one or more
      User Agents;

   o  Directs dCDNs to contact malicious origin servers instead of the
      actual origin servers, so that malware or slanderous alternate
      content may be substituted for legitimate content; or

   o  Removes delivery restrictions (e.g., LocationACL, TimeWindowACL,
      ProtocolACL, or Auth metadata), allowing access to content that
      would otherwise be denied and thus possibly violating license
      restrictions and incurring unwarranted delivery costs.

   Unauthorized access to metadata could also enable a malicious
   metadata client to continuously issue metadata requests in order to
   overload a uCDN's metadata server or servers.

   Unauthorized access to metadata could further result in leakage of
   private information.  A malicious metadata client could request
   metadata in order to gain access to origin servers, as well as
   information pertaining to content restrictions.

   An implementation of the CDNI Metadata interface MUST use mutual
   authentication and message authentication codes to prevent
   unauthorized access to, and undetected modification of, metadata (see
   Section 8.3).

8.2.  Confidentiality and Privacy

   Unauthorized viewing of metadata could result in leakage of private
   information.  Content provider origin and policy information is
   conveyed through the CDNI Metadata interface.  A third party could
   intercept metadata transactions in order to gain access to origin
   servers, as well as information pertaining to content restrictions
   and usage patterns.

Top      Up      ToC       Page 61 
   Note: The distribution of metadata by a uCDN to dCDNs could introduce
   privacy concerns for some content providers, e.g., dCDNs accepting
   content requests for a content provider's content might be able to
   obtain additional information and usage patterns relating to the
   users of a content provider's services.  Content providers with
   concerns about divulging information to dCDNs can instruct their uCDN
   partners not to use CDNI when delivering their content.

   An implementation of the CDNI Metadata interface MUST use strong
   encryption to prevent unauthorized interception or monitoring of
   metadata (see Section 8.3).

8.3.  Securing the CDNI Metadata Interface

   An implementation of the CDNI Metadata interface MUST support TLS
   transport as per [RFC2818] and [RFC7230].

   TLS MUST be used by the server side (uCDN) and the client side (dCDN)
   of the CDNI Metadata interface, including authentication of the
   remote end, unless alternate methods are used for ensuring the
   security of the information in the CDNI Metadata interface requests
   and responses (such as setting up an IPsec tunnel between the two
   CDNs or using a physically secured internal network between two CDNs
   that are owned by the same corporate entity).

   The use of TLS for transport of the CDNI Metadata interface messages
   allows the dCDN and uCDN to authenticate each other.

   Once the dCDN and uCDN have mutually authenticated each other, TLS
   allows:

   o  The dCDN and uCDN to authorize each other (to ensure that they are
      transmitting/receiving CDNI Metadata requests and responses from
      an authorized CDN);

   o  CDNI Metadata interface requests and responses to be transmitted
      with confidentiality; and

   o  The integrity of the CDNI Metadata interface requests and
      responses to be protected during the exchange.

   When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
   followed.

Top      Up      ToC       Page 62 
9.  References

9.1.  Normative References

   [ISO3166-1]
              The International Organization for Standardization,
              "Codes for the representation of names of countries and
              their subdivisions -- Part 1: Country codes",
              ISO 3166-1:2013, 2013.

   [POSIX]    Institute of Electrical and Electronics Engineers,
              "Information Technology Portable Operating System
              Interface (POSIX) Part 1: System Application Program
              Interface (API) [C Language]", IEEE P1003.1, 1990.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC1123]  Braden, R., Ed., "Requirements for Internet Hosts -
              Application and Support", STD 3, RFC 1123,
              DOI 10.17487/RFC1123, October 1989,
              <http://www.rfc-editor.org/info/rfc1123>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.

   [RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", RFC 4291, DOI 10.17487/RFC4291,
              February 2006, <http://www.rfc-editor.org/info/rfc4291>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <http://www.rfc-editor.org/info/rfc5890>.

Top      Up      ToC       Page 63 
   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <http://www.rfc-editor.org/info/rfc5891>.

   [RFC5952]  Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
              Address Text Representation", RFC 5952,
              DOI 10.17487/RFC5952, August 2010,
              <http://www.rfc-editor.org/info/rfc5952>.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, DOI 10.17487/RFC6707,
              September 2012, <http://www.rfc-editor.org/info/rfc6707>.

   [RFC7230]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
              DOI 10.17487/RFC7493, March 2015,
              <http://www.rfc-editor.org/info/rfc7493>.

   [RFC7525]  Sheffer, Y., Holz, R., and P. Saint-Andre,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525,
              May 2015, <http://www.rfc-editor.org/info/rfc7525>.

9.2.  Informative References

   [CDNI-URI-SIGNING]
              van Brandenburg, R., Leung, K., Sorber, P., and M. Miller,
              "URI Signing for CDN Interconnection (CDNI)", Work in
              Progress, draft-ietf-cdni-uri-signing-10, October 2016.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818,
              DOI 10.17487/RFC2818, May 2000,
              <http://www.rfc-editor.org/info/rfc2818>.

   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
              Autonomous System (AS) Number Space", RFC 6793,
              DOI 10.17487/RFC6793, December 2012,
              <http://www.rfc-editor.org/info/rfc6793>.

Top      Up      ToC       Page 64 
   [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
              RFC 7234, DOI 10.17487/RFC7234, June 2014,
              <http://www.rfc-editor.org/info/rfc7234>.

   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
              "Framework for Content Distribution Network
              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
              August 2014, <http://www.rfc-editor.org/info/rfc7336>.

   [RFC7337]  Leung, K., Ed., and Y. Lee, Ed., "Content Distribution
              Network Interconnection (CDNI) Requirements", RFC 7337,
              DOI 10.17487/RFC7337, August 2014,
              <http://www.rfc-editor.org/info/rfc7337>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <http://www.rfc-editor.org/info/rfc7540>.

   [RFC7736]  Ma, K., "Content Delivery Network Interconnection (CDNI)
              Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
              December 2015, <http://www.rfc-editor.org/info/rfc7736>.

   [RFC7975]  Niven-Jenkins, B., Ed., and R. van Brandenburg, Ed.,
              "Request Routing Redirection Interface for Content
              Delivery Network (CDN) Interconnection", RFC 7975,
              DOI 10.17487/RFC7975, October 2016,
              <http://www.rfc-editor.org/info/rfc7975>.

   [RFC8007]  Murray, R. and B. Niven-Jenkins, "Content Delivery Network
              Interconnection (CDNI) Control Interface / Triggers",
              RFC 8007, DOI 10.17487/RFC8007, December 2016,
              <http://www.rfc-editor.org/info/rfc8007>.

   [RFC8008]  Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
              R., and K. Ma, "Content Delivery Network Interconnection
              (CDNI) Request Routing: Footprint and Capabilities
              Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
              <http://www.rfc-editor.org/info/rfc8008>.

Top      Up      ToC       Page 65 
Acknowledgments

   The authors would like to thank David Ferguson, Francois Le Faucheur,
   Jan Seedorf, and Matt Miller for their valuable comments and input to
   this document.

Contributors

   The authors would also like to thank Grant Watson and Kent Leung for
   their contributions to this document.

Top      Up      ToC       Page 66 
Authors' Addresses

   Ben Niven-Jenkins
   Nokia
   3 Ely Road
   Milton, Cambridge  CB24 6DD
   United Kingdom

   Email: ben.niven-jenkins@nokia.com


   Rob Murray
   Nokia
   3 Ely Road
   Milton, Cambridge  CB24 6DD
   United Kingdom

   Email: rob.murray@nokia.com


   Matt Caulfield
   Cisco Systems
   1414 Massachusetts Avenue
   Boxborough, MA  01719
   United States of America

   Phone: +1-978-936-9307
   Email: mcaulfie@cisco.com


   Kevin J. Ma
   Ericsson
   43 Nagog Park
   Acton, MA  01720
   United States of America

   Phone: +1 978-844-5100
   Email: kevin.j.ma@ericsson.com