draft-ietf-cdni-metadata-03.txt   draft-ietf-cdni-metadata-04.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: April 24, 2014 Velocix (Alcatel-Lucent) Expires: June 9, 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.
October 21, 2013 December 6, 2013
CDN Interconnect Metadata CDN Interconnect Metadata
draft-ietf-cdni-metadata-03 draft-ietf-cdni-metadata-04
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 April 24, 2014. This Internet-Draft will expire on June 9, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
skipping to change at page 2, line 32 skipping to change at page 2, line 32
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 . . . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 13 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 12
4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13
4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . 16 4.2. CDNI Metadata Property Object Descriptions . . . . . . . 15
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 . . . . . . . . . . . . . . . . . . . . 17
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 . . . . . . . . . . . . . . . . . . 19
skipping to change at page 3, line 13 skipping to change at page 3, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . . . . . . . 22
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 . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 23
5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 24 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 23
5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 24 5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 24
5.2. Authorization Metadata Capabilities . . . . . . . . . . . 24 5.2. Authorization Metadata Capabilities . . . . . . . . . . . 24
6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 25 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 25
6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 25 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 25
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 . . . . . . . . . . . . . . . . . . . . . . . . 28 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 27
6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 28 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 27
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 . . . . . . . . . . . . . . . . . . . . . . 33 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 32
6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 33 6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 33
6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 33 6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 33
6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 34 6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
7.1. GenericMetadata Type Registry . . . . . . . . . . . . . . 34 7.1. GenericMetadata Type Registry . . . . . . . . . . . . . . 34
7.1.1. GenericMetadata Sub-Registries . . . . . . . . . . . 35 7.1.1. GenericMetadata Sub-Registries . . . . . . . . . . . 35
7.1.1.1. Footprint Sub-Registry . . . . . . . . . . . . . 35 7.1.1.1. Footprint Sub-Registry . . . . . . . . . . . . . 36
7.1.1.2. Protocol Sub-Registry . . . . . . . . . . . . . . 36 7.1.1.2. Protocol Sub-Registry . . . . . . . . . . . . . . 36
7.1.1.3. Authentication Sub-Registry . . . . . . . . . . . 37 7.1.1.3. Authentication Sub-Registry . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 38 10.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Relationship to the CDNI Requirements . . . . . . . 39 Appendix A. Relationship to the CDNI Requirements . . . . . . . 39
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 40
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 11, line 12 skipping to change at page 11, line 12
3.4. Metadata Naming 3.4. Metadata Naming
GenericMetadata objects are identified by their type. The type GenericMetadata objects are identified by their type. The type
SHOULD be descriptive, and MAY be hierarchical to support aggregating SHOULD be descriptive, and MAY be hierarchical to support aggregating
groups of properties for the purpose of readability and for avoiding groups of properties for the purpose of readability and for avoiding
name conflicts between vendor extensions. A dotted alpha-numeric name conflicts between vendor extensions. A dotted alpha-numeric
notation is suggested for human readability. notation is suggested for human readability.
Metadata types defined by this document are not hierarchical. Metadata types defined by this document are not hierarchical.
Examples of GenericMetadata object type names:
LocationACL
ext.vendor1.featurex
ext.vendor1.featurey
ext.vendor2.featurex
4. Encoding-Independent CDNI Metadata Object Descriptions 4. Encoding-Independent CDNI Metadata Object Descriptions
Section 4.1 provides the definitions of each object type declared in Section 4.1 provides the definitions of each object type declared in
Section 3. These objects are described as structural objects as they Section 3. These objects are described as structural objects as they
provide the structure for the inheritance tree and identifying which provide the structure for the inheritance tree and identifying which
specific properties apply to a given User Agent content request. specific properties apply to a given User Agent content request.
Section 4.2 provides the definitions for the set of core metadata Section 4.2 provides the definitions for the set of core metadata
objects which may be contained within a GenericMetadata object. objects which may be contained within a GenericMetadata object.
These objects are described as property objects as they define the These objects are described as property objects as they define the
skipping to change at page 15, line 45 skipping to change at page 15, line 33
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: mandatory-to-enforce Property: mandatory-to-enforce
Description: Flag identifying whether or not the enforcement of Description: Flag identifying whether or not the enforcement of
the property Metadata is required. the property Metadata is required.
Type: Boolean Type: Boolean
Mandatory-to-Specify: Yes. Mandatory-to-Specify: No. Default is to treat metadata as
mandatory to enforce.
Property: safe-to-redistribute Property: safe-to-redistribute
Description: Flag identifying whether or not the property Description: Flag identifying whether or not the property
Metadata may be safely redistributed without modification. Metadata may be safely redistributed without modification.
Type: Boolean Type: Boolean
Mandatory-to-Specify: No. Default is allow transparent Mandatory-to-Specify: No. Default is allow transparent
redistribution. redistribution.
4.2. CDNI Metadata Property Object Descriptions 4.2. CDNI Metadata Property Object Descriptions
The property objects defined below are intended to be used in the
GenericMetadata object value field as defined in Section 4.1.7. All
of the objects defined below are considered both mandatory to enforce
and safe to redistribute.
4.2.1. Source Metadata 4.2.1. Source Metadata
Source Metadata provides the dCDN information about content Source Metadata provides the dCDN information about content
acquisition e.g. how to contact an uCDN Surrogate or an Origin Server acquisition e.g. how to contact an uCDN Surrogate or an Origin Server
to obtain the content to be served. The sources are not necessarily to obtain the content to be served. The sources are not necessarily
the actual Origin Servers operated by the CSP but might be a set of the actual Origin Servers operated by the CSP but might be a set of
Surrogates in the uCDN. Surrogates in the uCDN.
Property: sources Property: sources
skipping to change at page 33, line 4 skipping to change at page 32, line 30
{ {
"start": "1213948800", "start": "1213948800",
"end": "1327393200" "end": "1327393200"
} }
], ],
"type": "allow" "type": "allow"
] ]
} }
} }
] ]
} }
6.5. Extensibility 6.5. Extensibility
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. As described in Section 3.4, the HostMetadata or PathMetadata lists.
any proprietary and/or custom property Metadata SHOULD be identified
by the "ext." prefix in an appropriately descriptive type which
conveys the organization defining the property Metadata and the
function of the property Metadata.
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
content. content.
Any standard which defines a new GenericMetadata Type SHOULD also Any standard which defines a new GenericMetadata Type MUST also
define whether or not the new metadata is mandatory-to-enforce. define whether or not the new metadata is mandatory-to-enforce.
Note: Ideally, uCDNs would not delegate content requests to a dCDN Note: Ideally, uCDNs would not delegate content requests to a dCDN
which does not support the mandatory-to-enforce Metadata associated which does not support the mandatory-to-enforce Metadata associated
with the content being requested. However, even if the uCDN has a 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 priori knowledge of the Metadata supported by the dCDN (e.g., via the
CDNI capabilities interface or through out-of-band negotiation CDNI capabilities interface or through out-of-band negotiation
between CDN operators) Metadata support may fluctuate or be between CDN operators) Metadata support may fluctuate or be
inconsistent (e.g., due to mis-communication, mis-configuration, or inconsistent (e.g., due to mis-communication, mis-configuration, or
temporary outage). Thus, the dCDN MUST evaluate all Metadata temporary outage). Thus, the dCDN MUST evaluate all Metadata
skipping to change at page 34, line 4 skipping to change at page 33, line 39
priori knowledge of the Metadata supported by the dCDN (e.g., via the priori knowledge of the Metadata supported by the dCDN (e.g., via the
CDNI capabilities interface or through out-of-band negotiation CDNI capabilities interface or through out-of-band negotiation
between CDN operators) Metadata support may fluctuate or be between CDN operators) Metadata support may fluctuate or be
inconsistent (e.g., due to mis-communication, mis-configuration, or inconsistent (e.g., due to mis-communication, mis-configuration, or
temporary outage). Thus, the dCDN MUST evaluate all Metadata temporary outage). Thus, the dCDN MUST evaluate all Metadata
associated with content requests and reject any requests where associated with content requests and reject any requests where
"mandatory-to-enforce" Metadata associated with the content cannot be "mandatory-to-enforce" Metadata associated with the content cannot be
enforced. enforced.
6.5.2. Metadata Override 6.5.2. Metadata Override
It is possible that new Metadata definitions may obsolete or override It is possible that new Metadata definitions may obsolete or override
existing property Metadata (e.g., a future revision of the CDNI existing property Metadata (e.g., a future revision of the CDNI
Metadata interface may redefine the Auth Metadata or a custom vendor Metadata interface may redefine the Auth Metadata or a custom vendor
extension may implement an alternate Auth Metadata option). If extension may implement an alternate Auth Metadata option). If
multiple Metadata (e.g., cdni.v2.Auth, ext.vendor1.Auth, and multiple Metadata (e.g., cdni.v2.Auth, vendor1.Auth, and
ext.vendor2.Auth) all override an existing Metadata (e.g., cdni.Auth) vendor2.Auth) all override an existing Metadata (e.g., cdni.Auth) and
and all are marked as "mandatory-to-enforce", it may be ambiguous all are marked as "mandatory-to-enforce", it may be ambiguous which
which Metadata should be applied, especially if the functionality of Metadata should be applied, especially if the functionality of the
the Metadata conflict. Metadata conflict.
As described in Section 3.3, Metadata override only applies to As described in Section 3.3, Metadata override only applies to
Metadata objects of the same exact type, found in HostMetadata and Metadata objects of the same exact type, found in HostMetadata and
nested PathMetadata structures. The CDNI Metadata interface does not nested PathMetadata structures. The CDNI Metadata interface does not
support enforcement of dependencies between different Metadata types. support enforcement of dependencies between different Metadata types.
It is the responsibility of the CSP and the CDN operators to ensure It is the responsibility of the CSP and the CDN operators to ensure
that Metadata assigned to a given content do not conflict. that Metadata assigned to a given content do not conflict.
Note: Because Metadata is inherently ordered in GenericMetadata Note: Because Metadata is inherently ordered in GenericMetadata
lists, as well as in the PathMetadata hierarchy and PathMatch lists, lists, as well as in the PathMetadata hierarchy and PathMatch lists,
skipping to change at page 35, line 4 skipping to change at page 34, line 38
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".
7. IANA Considerations 7. IANA Considerations
This document requests the registration of the "application/cdni" This document requests the registration of the "application/cdni"
MIME Media Type under the IANA MIME Media Type registry (http:// 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. As described in into two partitions: standard and vendor defined.
Section 4.1.7 and Section 6.5, the vendor defined namespace partition
SHOULD use a namespace prefix of "ext.", while the standard namespace
partition MUST NOT.
The standard namespace partition MUST conform to the "RFC Required" The standard namespace partition is intended to contain mandatory to
policy as defined in [RFC5226]. The vendor defined namespace implement capabilities and MUST conform to the "IETF Review" policy
partition should be further partitioned into vendor specific as defined in [RFC5226]. The registry SHALL contain the generic
partitions with the prefix "ext.vendor_name.". The vendor defined metadata type name, the RFC number of the specification defining the
partition SHOULD conform to the "Expert Review" policy as defined in metadata type, the version number of the GenericMetadata set to which
[RFC5226]. The expert review is simply to prevent namespace the standard capability applies, and boolean values indicating
hoarding. The vendor specific partitions MAY conform to the "First whether or not the new type is considered mandatory-to-enforce or
Come First Served" policy as defined in [RFC5226], however, vendors safe-to-redistribute (as defined in Section 4.1.7).
defining new GenericMetadata types which conflict with other
GenericMetadata types SHOULD follow the guidelines for the
"Specification Required" policy as defined in [RFC5226].
The following table defines the initial values for the standard The following table defines the initial values for the standard
partition: partition:
+----------------+---------------+ +----------------+---------------+---------+------+------+
| type name | Specification | | Type name | Specification | Version | MTE | STR |
+----------------+---------------+ +----------------+---------------+---------+------+------+
| SourceMetadata | RFCthis | | SourceMetadata | RFCthis | 1 | true | true |
| LocationACL | RFCthis | | LocationACL | RFCthis | 1 | true | true |
| TimeWindowACL | RFCthis | | TimeWindowACL | RFCthis | 1 | true | true |
| ProtocolACL | RFCthis | | ProtocolACL | RFCthis | 1 | true | true |
| Auth | RFCthis | | Auth | RFCthis | 1 | true | true |
| Cache | RFCthis | | Cache | RFCthis | 1 | true | true |
| Grouping | RFCthis | | Grouping | RFCthis | 1 | true | true |
+----------------+---------------+ +----------------+---------------+---------+------+------+
The initial MI version number is set to 1. All of the initial
GenericMetadata types are considered mandatory to implement for
version 1. The version field should be incremented when new
GenericMetadata type sets are added to the registry.
The "vendor defined" namespace partition SHOULD conform to the
"Expert Review" policy as defined in [RFC5226]. The expert review is
intended to prevent namespace hoarding and to prevent the definition
of redundant GenericMetadata types. Vendors defining new
GenericMetadata types which conflict with existing GenericMetadata
types SHOULD follow the guidelines for the "Specification Required"
policy as defined in [RFC5226]. The Version field in the registry
MUST be set to "-1" (negative one) for non-standard GenericMetadata
types.
As with the initial GenericMetadata types defined in Section 4.2,
future GenericMetadata type registrations SHOULD specify the
information necessary for constructing and decoding the
GenericMetadata object. This information SHOULD include the list of
properties contained within the GenericMetadata object, and for each
property, the specification should include a description, a type, and
whether or not the given property is mandatory to specify.
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
skipping to change at page 36, line 14 skipping to change at page 36, line 17
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 | definition | | Type name | Description | Specification |
+---------------+---------------------------------------------------+ +--------------+------------------------------------+---------------+
| IPv4 | Single IPv4 address | | IPv4 | Single IPv4 address | RFCthis |
| IPv6 | Single IPv6 address | | IPv6 | Single IPv6 address | RFCthis |
| IPv4Range | List of contiguous IPv4 addresses denoted by a | | IPv4Range | List of contiguous IPv4 addresses | RFCthis |
| | start address and an end address separated by a | | | denoted by a start address and an | |
| | dash (e.g., 192.168.0.1-192.168.0.20), inclusive. | | | end address separated by a dash | |
| IPv6Range | List of contiguous IPv6 addresses denoted by a | | | (e.g., 192.168.0.1-192.168.0.20), | |
| | start address and an end address separated by a | | | inclusive. | |
| | dash (e.g., fc80::0001-fc80::0014), inclusive. | | IPv6Range | List of contiguous IPv6 addresses | RFCthis |
| IPv4CIDR | IPv4 address block using slash prefix length | | | denoted by a start address and an | |
| | notation (e.g., 192.168.0.16/28). | | | end address separated by a dash | |
| IPv6CIDR | IPv6 address block using slash prefix length | | | (e.g., fc80::0001-fc80::0014), | |
| | notation (e.g., fc80::0010/124). | | | inclusive. | |
| ASN | Autonomous System (AS) Number | | IPv4CIDR | IPv4 address block using slash | RFCthis |
| CountryCode | ISO 3166-1 alpha-2 code | | | prefix length notation (e.g., | |
| DVDRegion | DVD Region code (i.e., integer in the range 0-6). | | | 192.168.0.16/28). | |
+---------------+---------------------------------------------------+ | IPv6CIDR | IPv6 address block using slash | RFCthis |
| | prefix length notation (e.g., | |
| | fc80::0010/124). | |
| ASN | Autonomous System (AS) Number | RFCthis |
| CountryCode | ISO 3166-1 alpha-2 code | RFCthis |
| DVDRegion | DVD Region code (i.e., integer in | RFCthis |
| | 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 name | definition | | Protocol | Description | Specification |
+---------------+------------+ +----------+---------------+----------------------------------------+
| HTTP | TBD | | HTTP | Hypertext | RFC2616 |
| HTTPS | TBD | | | Transfer | |
| RTSP | TBD | | | Protocol -- | |
| RTMP | TBD | | | HTTP/1.1 | |
+---------------+------------+ | HTTPS | HTTP Over TLS | RFC2818 |
| RTSP | Real Time | RFC2326 |
| | Streaming | |
| | Protocol | |
| RTMP | Real-Time | http://www.adobe.com/devnet/rtmp.html |
| | Messaging | |
| | Protocol | |
| FTP | FILE TRANSFER | RFC959 |
| | PROTOCOL | |
| SFTP | SSH File | N/A |
| | Transfer | |
| | Protocol | |
| SCP | Secure Copy | N/A |
| fasp | Aspera fast, | N/A |
| | adaptive, | |
| | secure | |
| | 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
Footprint type namespace MUST conform to the "Expert Review" policy Auth namespace MUST conform to the "Expert Review" policy as defined
as defined in [RFC5226]. The expert review should verify that new in [RFC5226]. The expert review should verify that new type
type definitions do not duplicate existing type definitions and definitions do not duplicate existing type definitions and prevent
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 | definition | | Type name | Description | Specification |
+------------------+------------------------------------------------+ +----------------+--------------------------------+-----------------+
| credentials | Simple username and password authentication as | | credentials | Simple username and password | RFCthis |
| | defined by Section 4.2.6.1. | | | authentication as defined by | |
+------------------+------------------------------------------------+ | | 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 38, line 35 skipping to change at page 39, line 12
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. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-03 (work in Interconnection", draft-ietf-cdni-framework-06 (work in
progress), February 2013. progress), October 2013.
[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-05 (work in progress), February 2013. requirements-12 (work in progress), November 2013.
[I-D.zyp-json-schema]
Zyp, K. and G. Court, "A JSON Media Type for Describing
the Structure and Meaning of JSON Documents", draft-zyp-
json-schema-03 (work in progress), November 2010.
[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.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC
4151, October 2005.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 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]
Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second
Edition) - http://www.w3.org/TR/xmlbase/", January 2009. Edition) - http://www.w3.org/TR/xmlbase/", January 2009.
Appendix A. Relationship to the CDNI Requirements Appendix A. Relationship to the CDNI Requirements
 End of changes. 35 change blocks. 
117 lines changed or deleted 157 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/