draft-ietf-cdni-metadata-04.txt   draft-ietf-cdni-metadata-05.txt 
Network Working Group B. Niven-Jenkins Network Working Group B. Niven-Jenkins
Internet-Draft R. Murray Internet-Draft R. Murray
Intended status: Standards Track G. Watson Intended status: Standards Track G. Watson
Expires: June 9, 2014 Velocix (Alcatel-Lucent) Expires: August 18, 2014 Velocix (Alcatel-Lucent)
M. Caulfield M. Caulfield
K. Leung K. Leung
Cisco Systems Cisco Systems
K. Ma K. Ma
Azuki Systems, Inc. Azuki Systems, Inc.
December 6, 2013 February 14, 2014
CDN Interconnect Metadata CDN Interconnect Metadata
draft-ietf-cdni-metadata-04 draft-ietf-cdni-metadata-05
Abstract Abstract
The CDNI Metadata Interface enables interconnected CDNs to exchange The CDNI Metadata Interface enables interconnected CDNs to exchange
content distribution metadata in order to enable content acquisition content distribution metadata in order to enable content acquisition
and delivery. The CDNI metadata associated with a piece of content and delivery. The CDNI metadata associated with a piece of content
provides a downstream CDN with sufficient information for the provides a downstream CDN with sufficient information for the
downstream CDN to service content requests on behalf of an upstream downstream CDN to service content requests on behalf of an upstream
CDN. This document describes both the core set of CDNI metadata and CDN. This document describes both the core set of CDNI metadata and
the protocol for exchanging that metadata. the protocol for exchanging that metadata.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on June 9, 2014. This Internet-Draft will expire on August 18, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
3. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . 5 3. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . 5
3.1. HostIndex, HostMetadata & PathMetadata objects . . . . . 6 3.1. HostIndex, HostMetadata & PathMetadata objects . . . . . 6
3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 9 3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 9
3.3. Metadata Inheritance and Override . . . . . . . . . . . . 10 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 10
3.4. Metadata Naming . . . . . . . . . . . . . . . . . . . . . 10 3.4. Metadata Naming . . . . . . . . . . . . . . . . . . . . . 11
4. Encoding-Independent CDNI Metadata Object Descriptions . . . 11 4. Encoding-Independent CDNI Metadata Object Descriptions . . . 11
4.1. CDNI Metadata Structural Object Descriptions . . . . . . 11 4.1. CDNI Metadata Structural Object Descriptions . . . . . . 11
4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 12 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 12
4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13
4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 13 4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 13
4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . 14 4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . 14
4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 15 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 15
4.2. CDNI Metadata Property Object Descriptions . . . . . . . 15 4.2. CDNI Metadata Property Object Descriptions . . . . . . . 16
4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 16 4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 16
4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 16 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 17 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 17
4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 17 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 17
4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 17 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 18
4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 18 4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 18
4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 18 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 18
4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 19 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 19
4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 19 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 19
4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 19 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 20
4.2.5. Authorization Metadata . . . . . . . . . . . . . . . 20 4.2.5. Authorization Metadata . . . . . . . . . . . . . . . 20
4.2.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.6.1. Credentials Auth Type . . . . . . . . . . . . . . 21 4.2.6.1. Credentials Auth Type . . . . . . . . . . . . . . 21
4.2.7. Cache . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.7. Cache . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 22 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 22
4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 22 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 22
4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 23 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 24
5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 23 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 24
5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 24 5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 24
5.2. Authorization Metadata Capabilities . . . . . . . . . . . 24 5.2. Authorization Metadata Capabilities . . . . . . . . . . . 25
6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 25 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 25
6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 26 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 26
6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 27 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 27
6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 27 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 27 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 28
6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 28 6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 28
6.4.2.1. JSON Example . . . . . . . . . . . . . . . . . . 29 6.4.2.1. JSON Example . . . . . . . . . . . . . . . . . . 29
6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 32 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 33
6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 33 6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 33
6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 33 6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 34
6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 34 6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
7.1. GenericMetadata Type Registry . . . . . . . . . . . . . . 34 7.1. GenericMetadata Type Registry . . . . . . . . . . . . . . 35
7.1.1. GenericMetadata Sub-Registries . . . . . . . . . . . 35 7.1.1. GenericMetadata Sub-Registries . . . . . . . . . . . 36
7.1.1.1. Footprint Sub-Registry . . . . . . . . . . . . . 36 7.1.1.1. Footprint Sub-Registry . . . . . . . . . . . . . 36
7.1.1.2. Protocol Sub-Registry . . . . . . . . . . . . . . 36 7.1.1.2. Protocol Sub-Registry . . . . . . . . . . . . . . 37
7.1.1.3. Authentication Sub-Registry . . . . . . . . . . . 37 7.1.1.3. Authentication Sub-Registry . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 39
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 39
10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 39
10.2. Informative References . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 40
Appendix A. Relationship to the CDNI Requirements . . . . . . . 39 Appendix A. Relationship to the CDNI Requirements . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
CDNI enables a downstream CDN to service content requests on behalf CDNI enables a downstream CDN to service content requests on behalf
of an upstream CDN. The CDNI metadata associated with a piece of of an upstream CDN. The CDNI metadata associated with a piece of
content (or with a set of contents) provides a downstream CDN with content (or with a set of contents) provides a downstream CDN with
sufficient information for servicing content requests on behalf of an sufficient information for servicing content requests on behalf of an
upstream CDN in accordance with the policies defined by the upstream upstream CDN in accordance with the policies defined by the upstream
CDN. CDN.
skipping to change at page 4, line 19 skipping to change at page 4, line 19
This document focuses on the CDNI Metadata interface which enables a This document focuses on the CDNI Metadata interface which enables a
downstream CDN to obtain CDNI Metadata from an upstream CDN so that downstream CDN to obtain CDNI Metadata from an upstream CDN so that
the downstream CDN can properly process and respond to: the downstream CDN can properly process and respond to:
o Redirection Requests received over the CDNI Request Routing o Redirection Requests received over the CDNI Request Routing
protocol. protocol.
o Content Requests received directly from User Agents. o Content Requests received directly from User Agents.
Specifically this document proposes: Specifically, this document proposes:
o A data structure for mapping content requests to CDNI Metadata o A data structure for mapping content requests to CDNI Metadata
properties (Section 3). properties (Section 3).
o An initial set of CDNI Metadata properties (Section 4.2). o An initial set of CDNI Metadata properties (Section 4.2).
o A RESTful web service for the transfer of CDNI Metadata o A RESTful web service for the transfer of CDNI Metadata
(Section 6). (Section 6).
1.1. Terminology 1.1. Terminology
skipping to change at page 5, line 38 skipping to change at page 5, line 38
between CDNs. between CDNs.
Leveraging existing protocols avoids reinventing common mechanisms Leveraging existing protocols avoids reinventing common mechanisms
such as data structure encoding (e.g. XML, JSON) and data transport such as data structure encoding (e.g. XML, JSON) and data transport
(e.g. HTTP). (e.g. HTTP).
3. CDNI Metadata Data Model 3. CDNI Metadata Data Model
The CDNI Metadata Model describes a data structure for mapping The CDNI Metadata Model describes a data structure for mapping
redirection requests and content requests to metadata properties. redirection requests and content requests to metadata properties.
Metadata properties describe how to acquire, authorize, and deliver Metadata properties describe how to acquire content from an upstream
content from a downstream CDN. The data model relies on the CDN, authorize access to content, and deliver content from a
assumption that these metadata properties may be aggregated based on downstream CDN. The data model relies on the assumption that these
the hostname of the content and subsequently on the resource path of metadata properties may be aggregated based on the hostname of the
the content. The data model associates a set of CDNI Metadata content and subsequently on the resource path of the content. The
properties with a Hostname to form a default set of metadata data model associates a set of CDNI Metadata properties with a
properties for content delivered for that Hostname. That default set Hostname to form a default set of metadata properties for content
of metadata properties can be overridden by properties that apply to delivered on behalf of that Hostname. That default set of metadata
specific paths within a URI. properties can be overridden by properties that apply to specific
paths within a URI.
Different Hostnames and URI paths will be associated with different Different Hostnames and URI paths will be associated with different
sets of CDNI Metadata properties in order to describe the required sets of CDNI Metadata properties in order to describe the required
behaviour when a dCDN surrogate is processing User Agent requests for behaviour when a dCDN surrogate is processing User Agent requests for
content at that Hostname or URI path. As a result of this structure, content at that Hostname or URI path. As a result of this structure,
significant commonality may exist between the CDNI Metadata significant commonality may exist between the CDNI Metadata
properties specified for different Hostnames, different URI paths properties specified for different Hostnames, different URI paths
within a Hostname and different URI paths on different Hostnames. within a Hostname and different URI paths on different Hostnames.
For example the definition of which User Agent IP addresses should be For example the definition of which User Agent IP addresses should be
treated as being grouped together into a single network or geographic treated as being grouped together into a single network or geographic
skipping to change at page 7, line 7 skipping to change at page 7, line 8
The HostIndex links Hostnames (and/or IP addresses) to HostMetadata The HostIndex links Hostnames (and/or IP addresses) to HostMetadata
objects via HostMatch objects. HostMetadata objects contain (or objects via HostMatch objects. HostMetadata objects contain (or
reference) the default CDNI Metadata required to serve content for reference) the default CDNI Metadata required to serve content for
that host. When looking up CDNI Metadata, the downstream CDN looks that host. When looking up CDNI Metadata, the downstream CDN looks
up the requested Hostname (or IP address) in the HostIndex, from up the requested Hostname (or IP address) in the HostIndex, from
there it can find HostMetadata which describes properties for a host there it can find HostMetadata which describes properties for a host
and PathMetadata which may override those properties for given URI and PathMetadata which may override those properties for given URI
paths within the host. paths within the host.
As well as containing the default CDNI Metadata for the specified Besides containing the default CDNI Metadata for the specified
Hostname, HostMetadata and PathMetadata objects may also contain Hostname, HostMetadata and PathMetadata objects may also contain
PathMatch objects which in turn contain PathMetadata objects. PathMatch objects which in turn contain PathMetadata objects.
PathMatch objects override the CDNI Metadata in the HostMetadata PathMatch objects override the CDNI Metadata in the HostMetadata
object or one or more preceding PathMetadata objects with more object or one or more preceding PathMetadata objects with more
specific CDNI Metadata that applies to content requests matching the specific CDNI Metadata that applies to content requests matching the
pattern defined in that PathMatch object. pattern defined in that PathMatch object.
For the purposes of retrieving CDNI Metadata all other required CDNI For the purposes of retrieving CDNI Metadata all other required CDNI
Metadata objects and their properties are discoverable from the Metadata objects and their properties are discoverable from the
appropriate HostMetadata, PathMatch and PathMetadata objects for the appropriate HostMetadata, PathMatch and PathMetadata objects for the
requested content. requested content.
The relationships between the HostIndex, HostMatch, HostMetadata, The relationships between the HostIndex, HostMatch, HostMetadata,
PathMatch and PathMetadata objects are described in Figure 1. PathMatch and PathMetadata objects are described in Figure 1.
+---------+ +---------+ +------------+ +---------+ +---------+ +------------+
|HostIndex+-(*)->|HostMatch|-(1)->|HostMetadata+-------(*)------+ |HostIndex+-(*)->|HostMatch|-(1)->|HostMetadata+-------(*)------+
+---------+ +---------+ +------+-----+ | +---------+ +---------+ +------+-----+ |
| | | |
(*) | (*) |
| | | |
--> References V V --> References V V
(1) One and only one +---------+ ************************** (1) One and only one +---------+ **************************
(*) Zero or more +--->|PathMatch| *Generic Metadata Objects* (*) Zero or more +--->|PathMatch| *Generic Metadata Objects*
| +---------+ ************************** | +---------+ **************************
| | ^ | | ^
(*) (1) | (*) (1) |
| | | | | |
| V | | V |
| +------------+ | | +------------+ |
+--|PathMetadata+-------(*)------+ +--|PathMetadata+-------(*)------+
+------------+ +------------+
Key: ----> = References
Figure 1: Relationships between the HostIndex, HostMetadata & Figure 1: Relationships between the HostIndex, HostMetadata &
PathMetadata CDNI Metadata Objects PathMetadata CDNI Metadata Objects
The relationships in Figure 1 are summarised in Table 1 below. The relationships in Figure 1 are summarised in Table 1 below.
+--------------------+----------------------------------------------+ +--------------+----------------------------------------------------+
| Data Object | Objects it References | | Data Object | Objects it References |
+--------------------+----------------------------------------------+ +--------------+----------------------------------------------------+
| HostIndex | 0 or more HostMatch objects. | | HostIndex | 0 or more HostMatch objects. |
| HostMatch | 1 HostMetadata object. | | HostMatch | 1 HostMetadata object. |
| HostMetadata | 0 or more PathMatch objects. 0 or more | | HostMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. | | | GenericMetadata objects. |
| PathMatch | 1 PathMetadata object. | | PathMatch | 1 PathMetadata object. |
| PathMetadata | 0 or more PathMatch objects. 0 or more | | PathMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. | | | GenericMetadata objects. |
+--------------------+----------------------------------------------+ +--------------+----------------------------------------------------+
Table 1: Relationships between CDNI Metadata Objects Table 1: Relationships between CDNI Metadata Objects
The table below describes the HostIndex, HostMetadata and The table below describes the HostIndex, HostMetadata and
PathMetadata objects in more detail. PathMetadata objects in more detail.
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Data Object | Description | | Data Object | Description |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| HostIndex | A HostIndex object lists HostMatch objects | | HostIndex | A HostIndex object lists HostMatch objects |
skipping to change at page 8, line 49 skipping to change at page 9, line 5
| | "example.com/movies/*" and | | | "example.com/movies/*" and |
| | "example.com/music/*" which reference | | | "example.com/music/*" which reference |
| | corresponding PathMetadata objects that contain | | | corresponding PathMetadata objects that contain |
| | the CDNI Metadata objects for those more | | | the CDNI Metadata objects for those more |
| | specific URI paths. | | | specific URI paths. |
| PathMatch | A PathMatch object defines a pattern to match | | PathMatch | A PathMatch object defines a pattern to match |
| | against the requested URI path, and contains or | | | against the requested URI path, and contains or |
| | references a PathMetadata object which contains | | | references a PathMetadata object which contains |
| | (or references) the CDNI Metadata objects to be | | | (or references) the CDNI Metadata objects to be |
| | applied when a content request matches against | | | applied when a content request matches against |
| | the defined URI path pattern. | | | the defined URI path pattern. For example, a |
| | PathMatch object may include a pattern for the |
| | path "/movies/*" and may reference a |
| | PathMetadata object which contains the CDNI |
| | Metadata for content with that path. |
| PathMetadata | A PathMetadata object contains the CDNI | | PathMetadata | A PathMetadata object contains the CDNI |
| | GenericMetadata objects for content served with | | | GenericMetadata objects for content served with |
| | the associated URI path (defined in a PathMatch | | | the associated URI path (defined in a PathMatch |
| | object). A PathMetadata object may also contain | | | object). A PathMetadata object may also contain |
| | PathMatch objects in order to recursively | | | PathMatch objects in order to recursively |
| | define more specific URI paths that require | | | define more specific URI paths that require |
| | different (e.g. more specific) CDNI Metadata to | | | different (e.g. more specific) CDNI Metadata to |
| | this one. For example, the PathMetadata object | | | this one. For example, the PathMetadata object |
| | which applies to "example.com/movies/*" may | | | which applies to "example.com/movies/*" may |
| | describe CDNI Metadata which apply to that | | | describe CDNI Metadata which apply to that |
| | resource path and may contain a PathMatch | | | resource path and may contain a PathMatch |
| | object for "example.com/movies/hd/*" which | | | object for "example.com/movies/hd/*" which |
| | would reference the corresponding PathMetadata | | | would reference the corresponding PathMetadata |
| | object for the "example.com/movies/hd/" path | | | object for the "example.com/movies/hd/" path |
| | prefix. | | | prefix. |
| GenericMetadata | A GenericMetadata object contains individual | | GenericMetadata | A GenericMetadata object contains individual |
| | CDNI Metadata objects which define the specific | | | CDNI Metadata objects which define the specific |
| | policies and attributes needed to properly | | | policies and attributes needed to properly |
| | deliver the associated content. | | | deliver the associated content. For example, a |
| | GenericMetadata object may describe the source |
| | from which a CDN may acquire a piece of |
| | content. |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
Table 2: HostIndex, HostMetadata and PathMetadata CDNI Metadata Table 2: HostIndex, HostMetadata and PathMetadata CDNI Metadata
Objects Objects
3.2. Generic CDNI Metadata Object Properties 3.2. Generic CDNI Metadata Object Properties
The HostMetadata and PathMetadata objects contain or can reference The HostMetadata and PathMetadata objects contain or can reference
other CDNI Metadata objects that contain properties which describe other CDNI Metadata objects that contain properties which describe
how User Agent requests for content should be processed, for example how User Agent requests for content should be processed, for example
where to acquire the content, authorization rules that should be where to acquire the content, authorization rules that should be
applied, delivery location restrictions and so on. Each such CDNI applied, delivery location restrictions and so on. Each such CDNI
Metadata object is a specialization of a CDNI GenericMetadata object. Metadata object is a specialization of a CDNI GenericMetadata object.
The GenericMetadata object abstracts the basic information required The GenericMetadata object abstracts the basic information required
for Metadata override and opaque Metadata distribution, from the for Metadata override and Metadata distribution, from the specifics
specifics of any given property (e.g., property semantics, of any given property (e.g., property semantics, enforcement options,
enforcement options, etc.). etc.).
The GenericMetadata object defines the type of properties contained The GenericMetadata object defines the type of properties contained
within it as well as whether or not the properties are mandatory to within it as well as whether or not the properties are mandatory to
enforce. If the dCDN does not understand or support the property enforce. If the dCDN does not understand or support the property
type and the property type is mandatory to enforce, the dCDN MUST NOT type and the property type is mandatory to enforce, the dCDN MUST NOT
serve the content to the User Agent. If the dCDN does not understand serve the content to the User Agent. If the dCDN does not understand
or support the property type it is also not going to be able to or support the property type it is also not going to be able to
properly propagate the Metadata for cascaded distribution. If the properly propagate the Metadata for cascaded distribution. If the
dCDN does not understand or support the property type and the dCDN does not understand or support the property type and the
property type is not mandatory to enforce, then the GenericMetadata property type is not mandatory to enforce, then the GenericMetadata
skipping to change at page 14, line 21 skipping to change at page 14, line 29
A PatternMatch object contains the pattern string and flags that A PatternMatch object contains the pattern string and flags that
describe the PathMatch expression. describe the PathMatch expression.
Property: pattern Property: pattern
Description: A pattern for string matching. The pattern may Description: A pattern for string matching. The pattern may
contain the wildcards * and ?, where * matches any sequence of contain the wildcards * and ?, where * matches any sequence of
characters (including the empty string) and ? matches exactly characters (including the empty string) and ? matches exactly
one character. The three literals \ , * and ? should be one character. The three literals \ , * and ? should be
escaped as \\, \* and \? escaped as \\, \* and \?. All other characters are treated as
literals.
Type: String Type: String
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: case-sensitive Property: case-sensitive
Description: Flag indicating whether or not case-sensitive Description: Flag indicating whether or not case-sensitive
matching should be used. matching should be used.
skipping to change at page 17, line 24 skipping to change at page 17, line 30
Description: Access control list which applies restrictions to Description: Access control list which applies restrictions to
delivery based on client location. delivery based on client location.
Type: List of LocationRule objects Type: List of LocationRule objects
Mandatory-to-Specify: No. Default is allow all locations. Mandatory-to-Specify: No. Default is allow all locations.
4.2.2.1. LocationRule 4.2.2.1. LocationRule
A LocationRule contains or references a list of Location objects and A LocationRule contains or references a list of Footprint objects and
the corresponding action. the corresponding action.
Property: footprints Property: footprints
Description: List of footprints to which the rule applies. Description: List of footprints to which the rule applies.
Type: List of Footprint objects Type: List of Footprint objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
skipping to change at page 22, line 39 skipping to change at page 23, line 11
This section describes the simpler data types that are used for This section describes the simpler data types that are used for
properties of CDNI Metadata objects. properties of CDNI Metadata objects.
4.3.1. Link 4.3.1. Link
A link object may be used in place of any of the objects or A link object may be used in place of any of the objects or
properties described above. Links can be used to avoid duplication properties described above. Links can be used to avoid duplication
if the same metadata information is repeated within the metadata if the same metadata information is repeated within the metadata
tree. When a link replaces an object, its href property is set to tree. When a link replaces an object, its href property is set to
the URI of the resource, its rel property is set to the name of the the URI of the resource and its type property is set to the type of
property it is replacing, and its type property is set to the type of
the object it is replacing. the object it is replacing.
Property: href Property: href
Description: The URI of the of the addressable object being Description: The URI of the of the addressable object being
referenced. referenced.
Type: URI Type: URI
Mandatory-to-Specify: Yes Mandatory-to-Specify: Yes
Property: rel
Description: The Relationship between the referring object and
the object it is referencing.
Type: String
Mandatory-to-Specify: Yes
Property: type Property: type
Description: The type of the object being referenced. Description: The type of the object being referenced.
Type: String Type: String
Mandatory-to-Specify: Yes Mandatory-to-Specify: No
4.3.2. Protocol 4.3.2. Protocol
Protocol objects are used to specify registered protocols for content Protocol objects are used to specify registered protocols for content
acquisition or delivery (see Section 7.1.1.2). acquisition or delivery (see Section 7.1.1.2).
Type: String Type: String
Mandatory-to-Specify: Yes Mandatory-to-Specify: Yes
skipping to change at page 27, line 46 skipping to change at page 28, line 12
Object are resources that may be: Object are resources that may be:
o Addressable, where the object is a resource that may be retrieved o Addressable, where the object is a resource that may be retrieved
or referenced via its own URI. or referenced via its own URI.
o Embedded, where the object is contained (or inlined) within a o Embedded, where the object is contained (or inlined) within a
property of an addressable object. property of an addressable object.
In the descriptions of objects we use the term "X contains Y" to mean In the descriptions of objects we use the term "X contains Y" to mean
either Y is directly embedded in X or that Y is linked to by X. It is either Y is directly embedded in X or that Y is linked to by X. It
generally a deployment choice for the uCDN implementation to decide is generally a deployment choice for the uCDN implementation to
when and which CDNI Metadata objects to embed and which are decide when and which CDNI Metadata objects to embed and which are
separately addressable. separately addressable.
6.4.1. MIME Media Types 6.4.1. MIME Media Types
All MIME types are prefixed with "application/cdni." The MIME type All MIME types are prefixed with "application/cdni." The MIME type
for each object matches the type name of that object as defined by for each object matches the type name of that object as defined by
this document. Table 3 lists a few examples of the MIME Media Type this document. The object type name is followed by ".v" and the
for each object (resource) that is retrievable through the CDNI version number of the object type (e.g. ".v1"). Finally, the
Metadata interface. encoding type "+json" is appended. Table 3 lists a few examples of
the MIME Media Type for each object (resource) that is retrievable
through the CDNI Metadata interface.
+--------------+-------------------------------+ +--------------+---------------------------------------+
| Data Object | MIME Media Type | | Data Object | MIME Media Type |
+--------------+-------------------------------+ +--------------+---------------------------------------+
| HostIndex | application/cdni.HostIndex | | HostIndex | application/cdni.HostIndex.v1+json |
| HostMatch | application/cdni.HostMatch | | HostMatch | application/cdni.HostMatch.v1+json |
| HostMetadata | application/cdni.HostMetadata | | HostMetadata | application/cdni.HostMetadata.v1+json |
| PathMatch | application/cdni.PathMatch | | PathMatch | application/cdni.PathMatch.v1+json |
| PathMetadata | application/cdni.PathMetadata | | PathMetadata | application/cdni.PathMetadata.v1+json |
+--------------+-------------------------------+ | Source | application/cdni.Source.v1+json |
| LocationACL | application/cdni.LocationACL.v1+json |
| LocationRule | application/cdni.LocationRule.v1+json |
+--------------+---------------------------------------+
Table 3: Example MIME Media Types for CDNI Metadata objects Table 3: Example MIME Media Types for CDNI Metadata objects
See http://www.iana.org/assignments/media-types/index.html for See http://www.iana.org/assignments/media-types/index.html for
reference. reference.
6.4.2. JSON Encoding of Objects 6.4.2. JSON Encoding of Objects
CDNI Metadata objects are encoded as JSON objects containing a CDNI Metadata objects are encoded as JSON objects containing a
dictionary of (key,value) pairs where the keys are the property names dictionary of (key,value) pairs where the keys are the property names
and the values are the associated property values. and the values are the associated property values.
The keys of the dictionary are the names of the properties associated The keys of the dictionary are the names of the properties associated
with the object and are therefore dependent on the specific object with the object and are therefore dependent on the specific object
being encoded (i.e. dependent on the MIME Media Type of the returned being encoded (i.e. dependent on the MIME Media Type of the returned
resource). Likewise, the values associated with each key are resource). Likewise, the values associated with each key are
dependent on the specific object being encoded (i.e. dependent on the dependent on the specific object being encoded (i.e. dependent on
MIME Media Type of the returned resource). the MIME Media Type of the returned resource).
Dictionary keys in JSON are case sensitive and therefore by Dictionary keys in JSON are case sensitive and therefore by
convention any dictionary key defined by this document (for example convention any dictionary key defined by this document (for example
the names of CDNI Metadata object properties) MUST be represented in the names of CDNI Metadata object properties) MUST be represented in
lowercase. lowercase.
In addition to the properties specific to each object type, the keys In addition to the properties specific to each object type, the keys
defined below may be present in any object. defined below may be present in any object.
Key: base Key: base
Description: Provides a prefix for any relative URLs in the Description: Provides a prefix for any relative URLs in the
object. This is similar to the XML base tag [XML-BASE]. If object. This is similar to the XML base tag [XML-BASE]. If
absent, all URLs in the remainder of the document must be absent, all URLs in the remainder of the document must be
absolute URLs. absolute URLs.
Type: URI Type: URI
Mandatory: No Mandatory: No
Key: links Key: _links
Description: The links of this object to other addressable Description: The links of this object to other addressable
objects. Any property may be replaced by a link to an object objects. Any property may be replaced by a link to an object
with the same type as the property it replaces. with the same type as the property it replaces. The keys of
the _links dictionary are the names of the properties being
replaced. The values of the dictionary are Link objects with
href set to the URI of the object and type set to the MIME type
of the object being replaced.
Type: List of Link objects Type: Dictionary object of Link objects
Mandatory: Yes Mandatory: Yes
6.4.2.1. JSON Example 6.4.2.1. JSON Example
A downstream CDN may request the HostIndex and receive the following A downstream CDN may request the HostIndex and receive the following
object of type "application/cdni.HostIndex+json": object of type "application/cdni.HostIndex.v1+json":
{ {
"hosts": [ "hosts": [
{ {
"host": "video.example.com", "host": "video.example.com",
"links": [ "_links": {
{ "host-metadata" : {
"rel": "host-metadata", "type": "application/cdni.HostMetadata.v1+json",
"type": "application/cdni.HostMetadata",
"href": "http://metadata.example.ucdn.com/video" "href": "http://metadata.example.ucdn.com/video"
} }
] }
}, },
{ {
"host": "images.example.com", "host": "images.example.com",
"links": [ "_links": {
{ "host-metadata" : {
"rel": "host-metadata", "type": "application/cdni.HostMetadata.v1+json",
"type": "application/cdni.HostMetadata", "href": "http://metadata.example.ucdn.com/images"
"href": "http://metadata.ucdn.example.com/images"
} }
] }
} }
] ]
} }
If the incoming request has a Host header with "video.example.com" If the incoming request has a Host header with "video.example.com"
then the downstream CDN would fetch from the next metadata object then the downstream CDN would fetch the next metadata object from
from "http://metadata.ucdn.example.com/video" expecting a MIME type "http://metadata.ucdn.example.com/video" expecting a MIME type of
of "application/cdni.HostMetadata+json": "application/cdni.HostMetadata.v1+json":
{ {
"metadata": [ "metadata": [
{ {
"type": "application/cdni.SourceMetadata", "type": "application/cdni.SourceMetadata.v1+json",
"value": { "value": {
"sources": [ "sources": [
{ {
"links": [{ "_links": {
"rel": "auth", "auth": {
"type": "application/cdni.Auth", "type": "application/cdni.Auth.v1+json",
"href": "http://metadata.ucdn.example.com/auth1234" "href": "http://metadata.ucdn.example.com/auth1234"
}], }
},
"endpoint": "acq1.ucdn.example.com", "endpoint": "acq1.ucdn.example.com",
"protocol": "ftp" "protocol": "ftp"
}, },
{ {
"links": [{ "_links": {
"rel": "auth", "auth": {
"type": "application/cdni.Auth", "type": "application/cdni.Auth.v1+json",
"href": "http://metadata.ucdn.example.com/auth1234" "href": "http://metadata.ucdn.example.com/auth1234"
}], }
},
"endpoint": "acq2.ucdn.example.com", "endpoint": "acq2.ucdn.example.com",
"protocol": "http" "protocol": "http"
} }
] ]
} }
}, },
{ {
"type": "application/cdni.LocationACL", "type": "application/cdni.LocationACL.v1+json",
"value": { "value": {
"locations": [ "locations": [
{ {
"locations": [ "locations": [
{ "iprange": "192.168.0.0/16" } { "iprange": "192.168.0.0/16" }
], ],
"action": "deny" "action": "deny"
} }
] ]
} }
}, },
{ {
"type": "application/cdni.ProtocolACL", "type": "application/cdni.ProtocolACL.v1+json",
"value": { "value": {
"protocols": [ "protocols": [
{ {
"protocols": [ "protocols": [
"ftp" "ftp"
], ],
"action": "deny" "action": "deny"
} }
] ]
} }
} }
], ],
"paths": [ "paths": [
{ {
"path-pattern": { "path-pattern": {
"pattern": "/videos/trailers/*" "pattern": "/videos/trailers/*"
}, },
"links": [{ "_links": {
"rel": "path-metadata", "path-metadata": {
"type": "application/cdni.PathMetadata", "type": "application/cdni.PathMetadata.v1+json",
"href": "http://metadata.ucdn.example.com/videos/trailers" "href": "http://metadata.ucdn.example.com/videos/trailers"
}] }
}
}, },
{ {
"path-pattern": { "path-pattern": {
"pattern": "/videos/movies/*" "pattern": "/videos/movies/*"
}, },
"links": [{ "_links": {
"rel": "pathmetadata", "pathmetadata": {
"type": "application/cdni.PathMetadata", "type": "application/cdni.PathMetadata.v1+json",
"href": "http://metadata.ucdn.example.com/videos/movies" "href": "http://metadata.ucdn.example.com/videos/movies"
}] }
}
} }
] ]
} }
Suppose the path of the requested resource matches the "/video/movies Suppose the path of the requested resource matches the "/video/movies
/*" pattern, the next metadata requested would be for "http:// /*" pattern, the next metadata requested would be for "http://
metadata.ucdn.example.com/video/movies" with an expected type of metadata.ucdn.example.com/video/movies" with an expected type of
"application/cdni.PathMetadata": "application/cdni.PathMetadata.v1+json":
{ {
"metadata": [], "metadata": [],
"paths": [ "paths": [
{ {
"path-pattern": { "path-pattern": {
"pattern": "/videos/movies/hd/*" "pattern": "/videos/movies/hd/*"
}, },
"links": [{ "_links": {
"rel": "pathmetadata", "pathmetadata": {
"type": "application/cdni.PathMetadata", "type": "application/cdni.PathMetadata.v1+json",
"href": "http://metadata.ucdn.example.com/videos/movies/hd" "href": "http://metadata.ucdn.example.com/videos/movies/hd"
}] }
}
} }
] ]
} }
Finally, if the path of the requested resource also matches the "/ Finally, if the path of the requested resource also matches the "/
videos/movies/hd/*" pattern, the downstream CDN would also fetch the videos/movies/hd/*" pattern, the downstream CDN would also fetch the
following object from "http://metadata.ucdn.example.com/videos/movies following object from "http://metadata.ucdn.example.com/videos/movies
/hd" with MIME type "application/cdni.PathMetadata": /hd" with MIME type "application/cdni.PathMetadata.v1+json":
{ {
"metadata": [ "metadata": [
{ {
"type": "application/cdni.TimeWindowACL", "type": "application/cdni.TimeWindowACL.v1+json",
"value": { "value": {
"times": [ "times": [
"times": [ "times": [
{ {
"start": "1213948800", "start": "1213948800",
"end": "1327393200" "end": "1327393200"
} }
], ],
"type": "allow" "type": "allow"
] ]
skipping to change at page 32, line 44 skipping to change at page 33, line 36
The set of property Metadata may be extended with proprietary and/or The set of property Metadata may be extended with proprietary and/or
custom property Metadata. The GenericMetadata object defined in custom property Metadata. The GenericMetadata object defined in
Section 4.1.7 allows any Metadata property to be included in either Section 4.1.7 allows any Metadata property to be included in either
the HostMetadata or PathMetadata lists. the HostMetadata or PathMetadata lists.
Note: Identification of the property Metadata defining organization Note: Identification of the property Metadata defining organization
in the property Metadata type decreases the possibility of property in the property Metadata type decreases the possibility of property
Metadata type collision. The fully-qualified domain name of the Metadata type collision. The fully-qualified domain name of the
organization in reverse order may be used for this purpose. organization in reverse order may be used for this purpose.
Any document which defines a new GenericMetadata object MUST:
1. Allocate a new type in the GenericMetadata Type Registry
(Section 7).
2. Define the set of properties associated with the new type.
3. For each property, define a name, description, type, and whether
or not the property is mandatory-to-specify.
4. Specify whether or not the new type is mandatory-to-enforce (vs
optional-to-enforce).
5. Describe the semantics of the new type including its purpose and
example of a use case to which it applies.
6.5.1. Metadata Enforcement 6.5.1. Metadata Enforcement
At any given time, the set of property Metadata supported by the uCDN At any given time, the set of property Metadata supported by the uCDN
may not match the set of property Metadata supported by the dCDN. may not match the set of property Metadata supported by the dCDN.
The uCDN may or may not know which property Metadata the dCDN The uCDN may or may not know which property Metadata the dCDN
supports. In cases where the uCDN supports Metadata that the dCDN supports. In cases where the uCDN supports Metadata that the dCDN
does not, the dCDN MUST be aware of any Metadata marked as does not, the dCDN MUST be aware of any Metadata marked as
"mandatory-to-enforce". If a CDN does not understand or is unable to "mandatory-to-enforce". If a CDN does not understand or is unable to
perform the functions associated with any "mandatory-to-enforce" perform the functions associated with any "mandatory-to-enforce"
Metadata, the CDN MUST NOT service any requests for the corresponding Metadata, the CDN MUST NOT service any requests for the corresponding
skipping to change at page 34, line 19 skipping to change at page 34, line 44
lists, as well as in the PathMetadata hierarchy and PathMatch lists, lists, as well as in the PathMetadata hierarchy and PathMatch lists,
multiple conflicting Metadata types MAY be used, however, Metadata multiple conflicting Metadata types MAY be used, however, Metadata
hierarchies MUST ensure that independent PathMatch root objects are hierarchies MUST ensure that independent PathMatch root objects are
used to prevent ambiguous or conflicting Metadata definitions. used to prevent ambiguous or conflicting Metadata definitions.
6.6. Versioning 6.6. Versioning
The version of CDNI Metadata Structural objects is specified by the The version of CDNI Metadata Structural objects is specified by the
HTTP Content-Type header. Upon responding to a request for an HTTP Content-Type header. Upon responding to a request for an
object, a metadata server MUST include a Content-Type header with the object, a metadata server MUST include a Content-Type header with the
MIME-type and verison number of the object. HTTP requests sent to a MIME-type and version number of the object. HTTP requests sent to a
metadata server SHOULD include an Accept header with the MIME-type metadata server SHOULD include an Accept header with the MIME-type
and version of the expected object. Unless stated otherwise, the and version of the expected object. Unless stated otherwise, the
verison of each object defined by this document is version 1. For version of each object defined by this document is version 1. For
example: "Content-Type: application/cdni.HostIndex.v1":. example: "Content-Type: application/cdni.HostIndex.v1+json".
GenericMetadata objects include a "type" property which specifies the GenericMetadata objects include a "type" property which specifies the
MIME-type of the GenericMetadata value. This MIME-type should also MIME-type of the GenericMetadata value. This MIME-type should also
include a version. Any document which defines a new type of include a version. Any document which defines a new type of
GenericMetadata should specify the version number which it describes. GenericMetadata should specify the version number which it describes.
For example: "application/cdni.Location.v1". For example: "application/cdni.Location.v1+json".
7. IANA Considerations 7. IANA Considerations
This document requests the registration of the "application/cdni" This document requests the registration of the prefix "application/
MIME Media Type under the IANA MIME Media Type registry (http:// cdni" MIME Media Type under the IANA MIME Media Type registry (http:/
www.iana.org/assignments/media-types/index.html). /www.iana.org/assignments/media-types/index.html).
7.1. GenericMetadata Type Registry 7.1. GenericMetadata Type Registry
CDNI Metadata is distributed as a list of GenericMetadata objects CDNI Metadata is distributed as a list of GenericMetadata objects
which specify a type field and a type-specific value field, as which specify a type field and a type-specific value field, as
described in Section 4.1.7. In order to prevent namespace collisions described in Section 4.1.7. In order to prevent namespace collisions
for GenericMetadata object types a new IANA registry is requested for for GenericMetadata object types a new IANA registry is requested for
"CDNI GenericMetadata Types" namespace. The namespace shall be split "CDNI GenericMetadata Types" namespace. The namespace shall be split
into two partitions: standard and vendor defined. into two partitions: standard and vendor defined.
skipping to change at page 35, line 45 skipping to change at page 36, line 23
types. types.
As with the initial GenericMetadata types defined in Section 4.2, As with the initial GenericMetadata types defined in Section 4.2,
future GenericMetadata type registrations SHOULD specify the future GenericMetadata type registrations SHOULD specify the
information necessary for constructing and decoding the information necessary for constructing and decoding the
GenericMetadata object. This information SHOULD include the list of GenericMetadata object. This information SHOULD include the list of
properties contained within the GenericMetadata object, and for each properties contained within the GenericMetadata object, and for each
property, the specification should include a description, a type, and property, the specification should include a description, a type, and
whether or not the given property is mandatory to specify. whether or not the given property is mandatory to specify.
Any document which defines a new GenericMetadata type MUST:
1. Allocate a new type in the GenericMetadata Type Registry
(Section 7).
2. Define the set of properties associated with the new type.
3. For each property, define a name, description, type, and whether
or not the property is mandatory-to-specify.
4. Specify whether or not the new type is mandatory-to-enforce (vs
optional-to-enforce).
5. Describe the semantics of the new type including its purpose and
example of a use case to which it applies.
7.1.1. GenericMetadata Sub-Registries 7.1.1. GenericMetadata Sub-Registries
Some of the initial standard GenericMetadata objects contain Some of the initial standard GenericMetadata objects contain
enumerated types which require registration (i.e., LocationACL enumerated types which require registration (i.e., LocationACL
footprint types, ProtocolACL protocols, and Auth protocols). The footprint types, ProtocolACL protocols, and Auth protocols). The
following sections define the initial values for these following sections define the initial values for these
GenericMetadata type sub-registries. GenericMetadata type sub-registries.
7.1.1.1. Footprint Sub-Registry 7.1.1.1. Footprint Sub-Registry
The "CDNI Metadata Footprint Types" namespace defines the valid The "CDNI Metadata Footprint Types" namespace defines the valid
Footprint object type values used by the Footprint object in Footprint object type values used by the Footprint object in
Section 4.2.2.2. Additions to the Footprint type namespace MUST Section 4.2.2.2. Additions to the Footprint type namespace MUST
conform to the "Expert Review" policy as defined in [RFC5226]. The conform to the "Expert Review" policy as defined in [RFC5226]. The
expert review should verify that new type definitions do not expert review should verify that new type definitions do not
duplicate existing type definitions and prevent gratuitous additions duplicate existing type definitions and prevent gratuitous additions
to the namespace. to the namespace.
The following table defines the initial Footprint type values: The following table defines the initial Footprint type values:
+--------------+------------------------------------+---------------+ +-------------+-------------------------------------+---------------+
| Type name | Description | Specification | | Type name | Description | Specification |
+--------------+------------------------------------+---------------+ +-------------+-------------------------------------+---------------+
| IPv4 | Single IPv4 address | RFCthis | | IPv4 | Single IPv4 address | RFCthis |
| IPv6 | Single IPv6 address | RFCthis | | IPv6 | Single IPv6 address | RFCthis |
| IPv4Range | List of contiguous IPv4 addresses | RFCthis | | IPv4Range | List of contiguous IPv4 addresses | RFCthis |
| | denoted by a start address and an | | | | denoted by a start address and an | |
| | end address separated by a dash | | | | end address separated by a dash | |
| | (e.g., 192.168.0.1-192.168.0.20), | | | | (e.g., 192.168.0.1-192.168.0.20), | |
| | inclusive. | | | | inclusive. | |
| IPv6Range | List of contiguous IPv6 addresses | RFCthis | | IPv6Range | List of contiguous IPv6 addresses | RFCthis |
| | denoted by a start address and an | | | | denoted by a start address and an | |
| | end address separated by a dash | | | | end address separated by a dash | |
| | (e.g., fc80::0001-fc80::0014), | | | | (e.g., fc80::0001-fc80::0014), | |
| | inclusive. | | | | inclusive. | |
| IPv4CIDR | IPv4 address block using slash | RFCthis | | IPv4CIDR | IPv4 address block using slash | RFCthis |
| | prefix length notation (e.g., | | | | prefix length notation (e.g., | |
| | 192.168.0.16/28). | | | | 192.168.0.16/28). | |
| IPv6CIDR | IPv6 address block using slash | RFCthis | | IPv6CIDR | IPv6 address block using slash | RFCthis |
| | prefix length notation (e.g., | | | | prefix length notation (e.g., | |
| | fc80::0010/124). | | | | fc80::0010/124). | |
| ASN | Autonomous System (AS) Number | RFCthis | | ASN | Autonomous System (AS) Number | RFCthis |
| CountryCode | ISO 3166-1 alpha-2 code | RFCthis | | CountryCode | ISO 3166-1 alpha-2 code | RFCthis |
| DVDRegion | DVD Region code (i.e., integer in | RFCthis | | DVDRegion | DVD Region code (i.e., integer in | RFCthis |
| | the range 0-6). | | | | the range 0-6). | |
+--------------+------------------------------------+---------------+ +-------------+-------------------------------------+---------------+
7.1.1.2. Protocol Sub-Registry 7.1.1.2. Protocol Sub-Registry
The "CDNI Metadata Protocols" namespace defines the valid Protocol The "CDNI Metadata Protocols" namespace defines the valid Protocol
object values in Section 4.3.2, used by the SourceMetadata and object values in Section 4.3.2, used by the SourceMetadata and
ProtocolACL objects. Additions to the Protocol namespace MUST ProtocolACL objects. Additions to the Protocol namespace MUST
conform to the "Expert Review" policy as defined in [RFC5226]. The conform to the "Expert Review" policy as defined in [RFC5226]. The
expert review should verify that new type definitions do not expert review should verify that new type definitions do not
duplicate existing type definitions and prevent gratuitous additions duplicate existing type definitions and prevent gratuitous additions
to the namespace. to the namespace.
The following table defines the initial Protocol values: The following table defines the initial Protocol values:
+----------+---------------+----------------------------------------+ +----------+----------------+---------------------------------------+
| Protocol | Description | Specification | | Protocol | Description | Specification |
+----------+---------------+----------------------------------------+ +----------+----------------+---------------------------------------+
| HTTP | Hypertext | RFC2616 | | HTTP | Hypertext | RFC2616 |
| | Transfer | | | | Transfer | |
| | Protocol -- | | | | Protocol -- | |
| | HTTP/1.1 | | | | HTTP/1.1 | |
| HTTPS | HTTP Over TLS | RFC2818 | | HTTPS | HTTP Over TLS | RFC2818 |
| RTSP | Real Time | RFC2326 | | RTSP | Real Time | RFC2326 |
| | Streaming | | | | Streaming | |
| | Protocol | | | | Protocol | |
| RTMP | Real-Time | http://www.adobe.com/devnet/rtmp.html | | RTMP | Real-Time | http://www.adobe.com/devnet/rtmp.html |
| | Messaging | | | | Messaging | |
| | Protocol | | | | Protocol | |
| FTP | FILE TRANSFER | RFC959 | | FTP | FILE TRANSFER | RFC959 |
| | PROTOCOL | | | | PROTOCOL | |
| SFTP | SSH File | N/A | | SFTP | SSH File | N/A |
| | Transfer | | | | Transfer | |
| | Protocol | | | | Protocol | |
| SCP | Secure Copy | N/A | | SCP | Secure Copy | N/A |
| fasp | Aspera fast, | N/A | | fasp | Aspera fast, | N/A |
| | adaptive, | | | | adaptive, | |
| | secure | | | | secure | |
| | protocol | | | | protocol | |
+----------+---------------+----------------------------------------+ +----------+----------------+---------------------------------------+
7.1.1.3. Authentication Sub-Registry 7.1.1.3. Authentication Sub-Registry
The "CDNI Metadata Auth" namespace defines the valid Auth object The "CDNI Metadata Auth" namespace defines the valid Auth object
types used by the Auth object in Section 4.2.6. Additions to the types used by the Auth object in Section 4.2.6. Additions to the
Auth namespace MUST conform to the "Expert Review" policy as defined Auth namespace MUST conform to the "Expert Review" policy as defined
in [RFC5226]. The expert review should verify that new type in [RFC5226]. The expert review should verify that new type
definitions do not duplicate existing type definitions and prevent definitions do not duplicate existing type definitions and prevent
gratuitous additions to the namespace. gratuitous additions to the namespace.
The following table defines the initial Auth type values: The following table defines the initial Auth type values:
+----------------+--------------------------------+-----------------+ +-------------+-------------------------------------+---------------+
| Type name | Description | Specification | | Type name | Description | Specification |
+----------------+--------------------------------+-----------------+ +-------------+-------------------------------------+---------------+
| credentials | Simple username and password | RFCthis | | credentials | Simple username and password | RFCthis |
| | authentication as defined by | | | | authentication as defined by | |
| | Section 4.2.6.1. | | | | Section 4.2.6.1. | |
+----------------+--------------------------------+-----------------+ +-------------+-------------------------------------+---------------+
8. Security Considerations 8. Security Considerations
The CDNI Metadata Interface is expected to be secured as a function The CDNI Metadata Interface is expected to be secured as a function
of the transport protocol (e.g. HTTP authentication [RFC2617], HTTPS of the transport protocol (e.g. HTTP authentication [RFC2617], HTTPS
[RFC2818], or inter-domain IPSec). [RFC2818], or inter-domain IPSec).
If a malicious metadata server is contacted by a downstream CDN, the If a malicious metadata server is contacted by a downstream CDN, the
malicious server may provide metadata to the downstream CDN which malicious server may provide metadata to the downstream CDN which
denies service for any piece of content to any user agent. The denies service for any piece of content to any user agent. The
skipping to change at page 39, line 11 skipping to change at page 40, line 11
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
10.2. Informative References 10.2. Informative References
[I-D.ietf-cdni-framework] [I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN Peterson, L., Davie, B., and R. Brandenburg, "Framework
Interconnection", draft-ietf-cdni-framework-06 (work in for CDN Interconnection", draft-ietf-cdni-framework-09
progress), October 2013. (work in progress), January 2014.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-12 (work in progress), November 2013. requirements-17 (work in progress), January 2014.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
[XML-BASE] [XML-BASE]
 End of changes. 72 change blocks. 
245 lines changed or deleted 255 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/