draft-ietf-cdni-metadata-09.txt   draft-ietf-cdni-metadata-10.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 Velocix (Alcatel-Lucent) Intended status: Standards Track Velocix (Alcatel-Lucent)
Expires: September 5, 2015 M. Caulfield Expires: January 7, 2016 M. Caulfield
Cisco Systems Cisco Systems
K. Ma K. Ma
Ericsson Ericsson
March 4, 2015 July 6, 2015
CDN Interconnection Metadata CDN Interconnection Metadata
draft-ietf-cdni-metadata-09 draft-ietf-cdni-metadata-10
Abstract Abstract
The CDNI Metadata interface enables interconnected CDNs to exchange The Content Delivery Networks Interconnection (CDNI) Metadata
content distribution metadata in order to enable content acquisition interface enables interconnected Content Delivery Networks (CDNs) to
and delivery. The CDNI metadata associated with a piece of content exchange content distribution metadata in order to enable content
provides a downstream CDN with sufficient information for the acquisition and delivery. The CDNI metadata associated with a piece
downstream CDN to service content requests on behalf of an upstream of content provides a downstream CDN with sufficient information for
CDN. This document describes both a base set of CDNI metadata and the downstream CDN to service content requests on behalf of an
the protocol for exchanging that metadata. upstream CDN. This document describes both a base set of CDNI
metadata and the protocol for exchanging that metadata.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 46 skipping to change at page 1, line 47
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 September 5, 2015. This Internet-Draft will expire on January 7, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5
2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6
3. CDNI Metadata model . . . . . . . . . . . . . . . . . . . . . 6 3. CDNI Metadata model . . . . . . . . . . . . . . . . . . . . . 7
3.1. HostIndex, HostMatch, HostMetadata, PathMatch, 3.1. HostIndex, HostMatch, HostMetadata, PathMatch,
PatternMatch and PathMetadata objects . . . . . . . . . . 8 PatternMatch and PathMetadata objects . . . . . . . . . . 8
3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 11 3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 10
3.3. Metadata Inheritance and Override . . . . . . . . . . . . 14 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13
4. Encoding-Independent CDNI Metadata Object Descriptions . . . 14 4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 14
4.1. Descriptions of the CDNI Structural Metadata Objects . . 15 4.1. Definitions of the CDNI structural metadata objects . . . 15
4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15
4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 16 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 16
4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 16 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17
4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 17 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 17 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 19
4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 18 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 20
4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 19 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 21
4.2. Description of the CDNI Generic Metadata Objects . . . . 20 4.2. Definitions of the initial set of CDNI Generic Metadata
4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 20 objects . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 21 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 23
4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 21 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 24
4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 22 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 25
4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 23 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 27
4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 23 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 28
4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 24 4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 28
4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 24 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 29
4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 25 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 29
4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 25 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 30
4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 26 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 30
4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 31
4.2.7. Grouping . . . . . . . . . . . . . . . . . . . . . . 27 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 31
4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 27 4.2.7. Grouping . . . . . . . . . . . . . . . . . . . . . . 32
4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 27 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 32
4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 28 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 28 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 33
4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 33
4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 28 4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.6.1. CredentialAuth Type . . . . . . . . . . . . . . . 29 4.3.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 33
4.3.7. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 29 4.3.6.1. CredentialAuth Type . . . . . . . . . . . . . . . 34
4.3.8. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 30 4.3.7. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 34
4.3.9. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.8. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 35
4.3.10. CountryCode . . . . . . . . . . . . . . . . . . . . . 30 4.3.9. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 35
5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 30 4.3.10. CountryCode . . . . . . . . . . . . . . . . . . . . . 35
6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 31 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 35
6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 36
6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 32 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 36
6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 33 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 37
6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 38
6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 34 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 39
6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 35 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 39
6.4.2.1. Encoded CDNI Metadata Example . . . . . . . . . . 36 6.4.2. I-JSON Encoding of Objects . . . . . . . . . . . . . 40
6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 40 6.4.2.1. Encoded CDNI Metadata Example . . . . . . . . . . 41
6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 41 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 45
6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 41 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 46
6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 42 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 46
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 47
7.1. CDNI Metadata Footprint Types Registry . . . . . . . . . 43 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
7.2. CDNI Metadata Protocol Types Registry . . . . . . . . . . 44 7.1. CDNI Metadata Footprint Types Registry . . . . . . . . . 48
7.3. CDNI Metadata Auth Types Registry . . . . . . . . . . . . 44 7.2. CDNI Metadata Protocol Types Registry . . . . . . . . . . 49
8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 7.3. CDNI Metadata Auth Types Registry . . . . . . . . . . . . 49
8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 45 8. Security Considerations . . . . . . . . . . . . . . . . . . . 50
8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 46 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 50
8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 46 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 51
8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 46 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 51
8.5. Securing the CDNI Metadata interface . . . . . . . . . . 46 8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 51
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 8.5. Securing the CDNI Metadata interface . . . . . . . . . . 51
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 47 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 52
11.1. Normative References . . . . . . . . . . . . . . . . . . 48 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
11.2. Informative References . . . . . . . . . . . . . . . . . 48 11.1. Normative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 11.2. Informative References . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
1. Introduction 1. Introduction
Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables
a downstream CDN to service content requests on behalf of an upstream a downstream Content Delivery Network (dCDN) to service content
CDN. requests on behalf of an upstream CDN (uCDN).
The CDNI Metadata interface is discussed in [RFC7336] along with four The CDNI Metadata interface is discussed in [RFC7336] along with four
other interfaces that may be used to compose a CDNI solution (CDNI other interfaces that may be used to compose a CDNI solution (CDNI
Control interface, CDNI Request Routing Redirection interface, CDNI Control interface, CDNI Request Routing Redirection interface, CDNI
Footprint & Capabilities Advertisement interface and CDNI Logging Footprint & Capabilities Advertisement interface and CDNI Logging
interface). [RFC7336] describes each interface, and the interface). [RFC7336] describes each interface, and the
relationships between them. The requirements for the CDNI metadata relationships between them. The requirements for the CDNI metadata
interface are specified in [RFC7337]. interface are specified in [RFC7337].
The CDNI metadata associated with a piece of content (or with a set The CDNI metadata associated with a piece of content (or with a set
of content) provides a downstream CDN with sufficient information for of content) provides a dCDN with sufficient information for servicing
servicing content requests on behalf of an upstream CDN in accordance content requests on behalf of an uCDN in accordance with the policies
with the policies defined by the upstream CDN. defined by the uCDN.
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 dCDN to obtain CDNI Metadata from an uCDN so that the dCDN can
the downstream CDN can properly process and respond to: properly process and respond to:
o Redirection requests received over the CDNI Request Routing o Redirection requests received over the CDNI Request Routing
Redirection interface. Redirection interface [I-D.ietf-cdni-redirection].
o Content requests received directly from User Agents. o Content requests received directly from User Agents.
Specifically, this document specifies: Specifically, this document specifies:
o A data structure for mapping content requests and redirection o A data structure for mapping content requests and redirection
requests to CDNI Metadata objects (Section 3 and Section 4.1). requests to CDNI Metadata objects (Section 3 and Section 4.1).
o An initial set of CDNI Generic Metadata objects (Section 4.2). o An initial set of CDNI Generic Metadata objects (Section 4.2).
skipping to change at page 5, line 38 skipping to change at page 5, line 41
requests. requests.
o Cache Control: Metadata for controlling cache behavior of the o Cache Control: Metadata for controlling cache behavior of the
dCDN. dCDN.
The metadata encoding described by this document is extensible in The metadata encoding described by this document is extensible in
order to allow for future additions to this list. order to allow for future additions to this list.
The set of metadata specified in this document, covering the initial The set of metadata specified in this document, covering the initial
capabilities above, is only able to support CDN interconnection for capabilities above, is only able to support CDN interconnection for
the delivery of content by a dCDN using HTTPv1.1 and for a dCDN to be the delivery of content by a dCDN using HTTPv1.1 [RFC7230] and for a
able to acquire content from a uCDN using either HTTPv1.1 or HTTPv1.1 dCDN to be able to acquire content from a uCDN using either HTTPv1.1
over TLS. or HTTPv1.1 over TLS [RFC2818].
Supporting CDN interconnection for the delivery of content using Supporting CDN interconnection for the delivery of content using
unencrypted HTTPv2.0 (as well as for a dCDN to acquire content using unencrypted HTTPv2.0 [I-D.ietf-httpbis-http2] (as well as for a dCDN
unencrypted HTTPv2.0 or HTTPv2.0 over TLS) requires the registration to acquire content using unencrypted HTTPv2.0 or HTTPv2.0 over TLS)
of these protocol names in the CDNI Metadata Protocol Registry. requires the registration of these protocol names in the CDNI
Metadata Protocol Registry.
Supporting CDN interconnection for the delivery of content using Supporting CDN interconnection for the delivery of content using
HTTPv1.1 over TLS or HTTPv2.0 over TLS requires specifying additional HTTPv1.1 over TLS or HTTPv2.0 over TLS requires specifying additional
metadata objects to carry the properties required to establish a TLS metadata objects to carry the properties required to establish a TLS
session, for example metadata to describe the certificate to use as session, for example metadata to describe the certificate to use as
part of the TLS handshake. part of the TLS handshake.
2. Design Principles 2. Design Principles
The CDNI Metadata interface was designed to achieve the following The CDNI Metadata interface was designed to achieve the following
skipping to change at page 6, line 30 skipping to change at page 6, line 33
5. Leveraging of existing protocols. 5. Leveraging of existing protocols.
Cacheability improves the latency of acquiring metadata while Cacheability improves the latency of acquiring metadata while
maintaining its freshness, and therefore improves the latency of maintaining its freshness, and therefore improves the latency of
serving content requests and redirection requests, without serving content requests and redirection requests, without
sacrificing accuracy. The CDNI Metadata interface uses HTTP and its sacrificing accuracy. The CDNI Metadata interface uses HTTP and its
existing caching mechanisms to achieve CDNI metadata cacheability. existing caching mechanisms to achieve CDNI metadata cacheability.
Deterministic mappings from content to metadata properties eliminates Deterministic mappings from content to metadata properties eliminates
ambiguity and ensures that policies are applied consistently by all ambiguity and ensures that policies are applied consistently by all
downstream CDNs. dCDNs.
Support for both HTTP and DNS redirection ensures that the CDNI Support for both HTTP and DNS redirection ensures that the CDNI
Metadata interface can be used for HTTP and DNS redirection and also Metadata interface can be used for HTTP and DNS redirection and also
meets the same design principles for both HTTP and DNS based meets the same design principles for both HTTP and DNS based
redirection schemes. redirection schemes.
Minimal duplication of CDNI metadata provides space efficiency on Minimal duplication of CDNI metadata provides space efficiency on
storage in the CDNs, on caches in the network, and across the network storage in the CDNs, on caches in the network, and across the network
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., JSON) and data transport such as data structure encoding (e.g., I-JSON [RFC7492]) and data
(e.g., HTTP). transport (e.g., HTTP [RFC7230]).
3. CDNI Metadata model 3. CDNI Metadata 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 content from an upstream Metadata properties describe how to acquire content from an uCDN,
CDN, authorize access to content, and deliver content from a authorize access to content, and deliver content from a dCDN. The
downstream CDN. The data model relies on the assumption that these data model relies on the assumption that these metadata properties
metadata properties may be aggregated based on the hostname of the may be aggregated based on the hostname of the content and
content and subsequently on the resource path of the content. The subsequently on the resource path of the content. The data model
data model associates a set of CDNI Metadata properties with a associates a set of CDNI Metadata properties with a Hostname to form
Hostname to form a default set of metadata properties for content a default set of metadata properties for content delivered on behalf
delivered on behalf of that Hostname. That default set of metadata of that Hostname. That default set of metadata properties can be
properties can be overridden by properties that apply to specific overridden by properties that apply to specific paths within a URI.
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 35 skipping to change at page 7, line 43
In order to enable the CDNI Metadata for a given Hostname or URI Path In order to enable the CDNI Metadata for a given Hostname or URI Path
to be decomposed into sets of CDNI Metadata properties that can be to be decomposed into sets of CDNI Metadata properties that can be
reused by multiple Hostnames and URI Paths, the CDNI Metadata reused by multiple Hostnames and URI Paths, the CDNI Metadata
interface specified in this document splits the CDNI Metadata into a interface specified in this document splits the CDNI Metadata into a
number of objects. Efficiency is improved by enabling a single CDNI number of objects. Efficiency is improved by enabling a single CDNI
Metadata object (that is shared across Hostname and/or URI paths) to Metadata object (that is shared across Hostname and/or URI paths) to
be retrieved and stored by a dCDN once, even if it is referenced by be retrieved and stored by a dCDN once, even if it is referenced by
the CDNI Metadata of multiple Hostnames or of multiple URI paths. the CDNI Metadata of multiple Hostnames or of multiple URI paths.
Important Note: Any CDNI Metadata object that contains another CDNI
Metadata object may, instead of including the second object embedded
within itself, include a Link object that contains a URI that can be
dereferenced to retrieve the complete serialized representation of
the second metadata object. The remainder of this document uses the
phrase "[Object] X contains [Object] Y" for simplicity when a
strictly accurate phrase would be "[Object] X contains or references
(via a Link object) [Object] Y".
Section 3.1 introduces a high level description of the HostIndex, Section 3.1 introduces a high level description of the HostIndex,
HostMatch, HostMetadata, PathMatch, PatternMatch and PathMetadata HostMatch, HostMetadata, PathMatch, PatternMatch and PathMetadata
objects and describes the relationships between those objects. objects and describes the relationships between those objects.
Section 3.2 introduces a high level description of the CDNI Section 3.2 introduces a high level description of the CDNI
GenericMetadata object which represents the level at which CDNI GenericMetadata object which represents the level at which CDNI
Metadata override occurs between HostMetadata and PathMetadata Metadata override occurs between HostMetadata and PathMetadata
objects. objects.
Section 4 describes in detail the specific CDNI Metadata objects and Section 4 describes in detail the specific CDNI Metadata objects and
properties which may be contained within a CDNI GenericMetadata properties which may be contained within a CDNI GenericMetadata
object. object.
3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch and 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch and
PathMetadata objects PathMetadata objects
A HostIndex object contains (or references) a list of Hostnames (and/ A HostIndex object (see Section 4.1.1) contains a list of HostMatch
or IP addresses) for which content requests may be delegated to the objects (see Section 4.1.2) that contain Hostnames (and/or IP
downstream CDN. The HostIndex is the starting point for accessing addresses) for which content requests may be delegated to the dCDN.
the uCDN CDNI Metadata data store. It enables the dCDN to The HostIndex is the starting point for accessing the uCDN CDNI
deterministically discover, on receipt of a User Agent request for Metadata data store. It enables the dCDN to deterministically
content, which other CDNI Metadata objects it requires in order to discover, on receipt of a User Agent request for content, which other
deliver the requested content. CDNI Metadata objects it requires in order to deliver the requested
content.
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 (see Section 4.1.3) via HostMatch objects. A HostMatch
reference) the default CDNI Metadata required to serve content for object defines a hostname (or IP address) to match against a
that host. When looking up CDNI Metadata, the downstream CDN looks requested host and contains a HostMetadata object.
up the requested Hostname (or IP address) against the HostMatch
entries in the HostIndex, from there it can find HostMetadata which
describes properties for a host and PathMetadata which may override
those properties for given URI paths within the host.
HostMetadata and PathMetadata objects may also contain PathMatch HostMetadata objects contain the default CDNI Metadata within
objects which in turn contain PathMetadata objects. PathMetadata GenericMetadata objects (see Section 4.1.7) required to serve content
objects override the CDNI Metadata in the HostMetadata object or one for that host. When looking up CDNI Metadata, the dCDN looks up the
or more preceding PathMetadata objects with more specific CDNI requested Hostname (or IP address) against the HostMatch entries in
Metadata that applies to content requests matching the pattern the HostIndex, from there it can find HostMetadata which describes
defined in the PatternMatch object of that PathMatch object. the default properties for each host as well as PathMetadata objects
(see Section 4.1.6), via PathMatch objects (see Section 4.1.4), which
may override those properties for given URI paths within the host.
The CDNI metadata contained in HostMetadata objects is applied to
content requests for which there is not more specific metadata, i.e.
for content requests that do not match any of the PathMatch objects
contained by that HostMetadata object and its child PathMetadata
objects.
For the purposes of retrieving CDNI Metadata, all other required CDNI HostMetadata may also contain PathMatch objects. PathMatch objects
Metadata objects and their properties are discoverable from the define patterns, contained inside PatternMatch objects (see
appropriate HostMetadata, PathMatch and PathMetadata objects for the Section 4.1.5), to match against the requested URI path, and contain
requested content. PathMetadata objects which contain the GenericMetadata objects to be
applied when a content request matches against the defined URI path
pattern. PatternMatch objects contain the pattern strings and flags
that describe the URI path that a PathMatch applies to.
PathMetadata objects override the CDNI Metadata in the HostMetadata
object or one or more preceding PathMetadata objects with more
specific CDNI Metadata that applies to content requests matching the
URI pattern defined in the PatternMatch object of that PathMatch
object. A PathMetadata object may also contain PathMatch objects in
order to recursively define more specific URI paths that require
different (e.g., more specific) CDNI Metadata to this one.
A GenericMetadata object contains individual CDNI Metadata objects
which define the specific policies and attributes needed to properly
deliver the associated content. For example, a GenericMetadata
object may describe the source from which a CDN may acquire a piece
of content. The GenericMetadata object is an atomic unit that may be
referenced by HostMetadata and/or PathMetadata objects.
For example, if "example.com" is a content provider, a HostMatch
object may include an entry for "example.com" with the URI of the
associated HostMetadata object. The HostMetadata object for
"example.com" describes the metadata properties which apply to
"example.com" and could contain PathMatches for "example.com/
movies/*" and "example.com/music/*", which in turn reference
corresponding PathMetadata objects that contain the CDNI Metadata
objects for those more specific URI paths. The PathMetadata object
for "example.com/movies/*" describes CDNI Metadata which apply to
that URI path and could contain a PathMatch object for
"example.com/movies/hd/*" which would reference the corresponding
PathMetadata object for the "example.com/movies/hd/" path prefix.
The relationships between the HostIndex, HostMatch, HostMetadata, The relationships between the HostIndex, HostMatch, HostMetadata,
PathMatch, PatternMatch and PathMetadata objects are described in PathMatch, PatternMatch and PathMetadata objects are described in
Figure 1. Figure 1.
+---------+ +---------+ +------------+ +---------+ +---------+ +------------+
|HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+
+---------+ +---------+ +------+-----+ | +---------+ +---------+ +------+-----+ |
| | | |
(*) | (*) |
skipping to change at page 9, line 45 skipping to change at page 10, line 45
| | GenericMetadata objects. | | | GenericMetadata objects. |
| PathMatch | 1 PatternMatch object. 1 PathMetadata object. | | PathMatch | 1 PatternMatch object. 1 PathMetadata object. |
| PatternMatch | Does not contain or reference any other objects. | | PatternMatch | Does not contain or reference any other objects. |
| 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
(Table Representation) (Table Representation)
The table below describes the HostIndex, HostMatch, HostMetadata,
PathMatch, PatternMatch and PathMetadata objects in more detail.
+-----------------+-------------------------------------------------+
| Data Object | Description |
+-----------------+-------------------------------------------------+
| HostIndex | A HostIndex object lists HostMatch objects |
| HostMatch | A HostMatch object defines a hostname (or IP |
| | address) to match against a requested host, and |
| | contains (or references) a HostMetadata object |
| | which contains (or references) CDNI Metadata |
| | objects to be applied when a request matches |
| | against the hostname. For example, if |
| | "example.com" is a content provider, a |
| | HostMatch object may include an entry for |
| | "example.com" with the URI of the associated |
| | HostMetadata object. |
| HostMetadata | A HostMetadata object contains (or references) |
| | the default CDNI Metadata objects for content |
| | served from that host, i.e., the CDNI Metadata |
| | objects for content requests that do not match |
| | any of the PathMatch objects contained (or |
| | referenced) by that HostMetadata object. For |
| | example, a HostMetadata object may describe the |
| | metadata properties which apply to |
| | "example.com" and may contain PathMatches for |
| | "example.com/movies/*" and |
| | "example.com/music/*" which in turn reference |
| | corresponding PathMetadata objects that contain |
| | the CDNI Metadata objects for those more |
| | specific URI paths. |
| PathMatch | A PathMatch object defines a pattern (inside a |
| | PatternMatch object which the PathMatch object |
| | contains or references) to match against the |
| | requested URI path, and contains (or |
| | references) a PathMetadata object which |
| | contains (or references) the CDNI Metadata |
| | objects to be applied when a content request |
| | matches against the defined URI path pattern. |
| | For example, a PathMatch object may include a |
| | PatternMatch object containing a pattern for |
| | the path "/movies/*" and may reference a |
| | PathMetadata object which contains (or |
| | references) the CDNI Metadata for content with |
| | that path. |
| PatternMatch | A PatternMatch object contains the pattern |
| | string and flags that describe the URI path |
| | that a PathMatch applies to. |
| PathMetadata | A PathMetadata object contains (or references) |
| | the CDNI GenericMetadata objects for content |
| | served with the associated URI path (defined in |
| | a PathMatch object). A PathMetadata object may |
| | also contain (or reference) PathMatch objects |
| | in order to recursively define more specific |
| | URI paths that require different (e.g., more |
| | specific) CDNI Metadata to this one. For |
| | example, the PathMetadata object which applies |
| | to "example.com/movies/*" may describe CDNI |
| | Metadata which apply to that URI path and may |
| | contain a PathMatch object for |
| | "example.com/movies/hd/*" which would reference |
| | the corresponding PathMetadata object for the |
| | "example.com/movies/hd/" path prefix. |
| GenericMetadata | A GenericMetadata object contains (or |
| | references) individual CDNI Metadata objects |
| | which define the specific policies and |
| | attributes needed to properly deliver the |
| | associated content. For example, a |
| | GenericMetadata object may describe the source |
| | from which a CDN may acquire a piece of |
| | content. The GenericMetadata object is an |
| | atomic unit that may be referenced by |
| | HostMetadata and/or PathMetadata objects, but |
| | SHOULD NOT contain references to other CDNI |
| | Metadata objects. The member objects of a |
| | specific CDNI Metadata object MAY be referenced |
| | by the GenericMetadata object. |
+-----------------+-------------------------------------------------+
Table 2: HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch
and PathMetadata CDNI Metadata 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 Metadata distribution, from the specifics for Metadata override and Metadata distribution, from the specifics
of any given property (e.g., property semantics, enforcement options, of any given property (e.g., property semantics, 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 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 NOT serve the content to the User Agent. If the dCDN does not
skipping to change at page 12, line 9 skipping to change at page 11, line 24
NOT serve the content to the User Agent. If the dCDN does not NOT serve the content to the User Agent. If the dCDN does not
understand or support the property type and the property type is not understand or support the property type and the property type is not
"mandatory-to-enforce", then that GenericMetadata object may be "mandatory-to-enforce", then that GenericMetadata object may be
safely ignored and the dCDN MUST process the content request in safely ignored and the dCDN MUST process the content request in
accordance with the rest of the CDNI metadata. accordance with the rest of the CDNI metadata.
Although a CDN MUST NOT serve content to a User Agent if a Although a CDN MUST NOT serve content to a User Agent if a
"mandatory-to-enforce" property cannot be enforced, it may be "safe- "mandatory-to-enforce" property cannot be enforced, it may be "safe-
to-redistribute" that metadata to another CDN without modification. to-redistribute" that metadata to another CDN without modification.
For example, in the cascaded CDN case, a transit CDN may pass through For example, in the cascaded CDN case, a transit CDN may pass through
"mandatory-to-enforce" metadata to a downstream CDN. For Metadata "mandatory-to-enforce" metadata to a dCDN. For Metadata which does
which does not require customization or translation (i.e., metadata not require customization or translation (i.e., metadata that is
that is "safe-to-redistribute"), the data representation received off "safe-to-redistribute"), the data representation received off the
the wire MAY be stored and redistributed without being natively wire MAY be stored and redistributed without being natively
understood or supported by the transit CDN. However, for Metadata understood or supported by the transit CDN. However, for Metadata
which requires translation, transparent redistribution of the uCDN which requires translation, transparent redistribution of the uCDN
Metadata values might not be appropriate. Certain Metadata may be Metadata values might not be appropriate. Certain Metadata may be
safely, though possibly not optimally, redistributed unmodified. For safely, though possibly not optimally, redistributed unmodified. For
example, source acquisition address may not be optimal if example, source acquisition address may not be optimal if
transparently redistributed, but might still work. transparently redistributed, but might still work.
Redistribution safety MUST be specified for each GenericMetadata. If Redistribution safety MUST be specified for each GenericMetadata. If
a CDN does not understand or support a given GenericMetadata property a CDN does not understand or support a given GenericMetadata property
type and the property type is not "safe-to-redistribute", before type and the property type is not "safe-to-redistribute", before
skipping to change at page 12, line 36 skipping to change at page 11, line 51
flag signals to a dCDN that the metadata was not properly transformed flag signals to a dCDN that the metadata was not properly transformed
by the transit CDN. A CDN MUST NOT attempt to use metadata that has by the transit CDN. A CDN MUST NOT attempt to use metadata that has
been marked as "incomprehensible" by a uCDN. been marked as "incomprehensible" by a uCDN.
Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or
"safe-to-redistribute" when propagating metadata to a dCDN. Although "safe-to-redistribute" when propagating metadata to a dCDN. Although
a transit CDN may set the value of "incomprehensible" to true, a a transit CDN may set the value of "incomprehensible" to true, a
transit CDN MUST NOT change the value of "incomprehensible" from true transit CDN MUST NOT change the value of "incomprehensible" from true
to false. to false.
The following table describes the action to be taken by a transit CDN Table 2 describes the action to be taken by a transit CDN (tCDN) for
(tCDN) for the different "mandatory-to-enforce" (MtE) and "safe-to- the different combinations of "mandatory-to-enforce" (MtE) and "safe-
redistribute" (StR) cases, when the tCDN either does or does not to-redistribute" (StR) properties, when the tCDN either does or does
understand the metadata in question: not understand the metadata in question:
+-------+-------+------------+--------------------------------------+ +-------+-------+------------+--------------------------------------+
| MtE | StR | Metadata | Actions | | MtE | StR | Metadata | Action |
| | | Understood | | | | | Understood | |
| | | by tCDN | |
+-------+-------+------------+--------------------------------------+ +-------+-------+------------+--------------------------------------+
| False | True | True | Can serve and redistribute. | | False | True | True | Can serve and redistribute. |
| False | True | False | Can serve and redistribute. | | False | True | False | Can serve and redistribute. |
| False | False | False | Can serve. MUST set | | False | False | False | Can serve. MUST set |
| | | | "incomprehensible" to True when | | | | | "incomprehensible" to True when |
| | | | redistributing. | | | | | redistributing. |
| False | False | True | Can serve. Can redistribute either | | False | False | True | Can serve. Can redistribute either |
| | | | by transforming not StR metadata (if | | | | | by transforming not StR metadata (if |
| | | | the CDN knows how to do so safely), | | | | | the CDN knows how to do so safely), |
| | | | otherwise MUST set | | | | | otherwise MUST set |
| | | | "incomprehensible" to True when | | | | | "incomprehensible" to True when |
| | | | redistributing. | | | | | redistributing. |
| True | True | True | Can serve and redistribute. | | True | True | True | Can serve and redistribute. |
| True | True | False | MUST NOT serve but can redistribute. | | True | True | False | MUST NOT serve but can redistribute. |
| True | False | True | Can serve and redistribute. | | True | False | True | Can serve and redistribute. |
| True | False | False | MUST NOT serve. MUST set | | True | False | False | MUST NOT serve. MUST set |
| | | | "incomprehensible" to True when | | | | | "incomprehensible" to True when |
| | | | redistributing. | | | | | redistributing. |
+-------+-------+------------+--------------------------------------+ +-------+-------+------------+--------------------------------------+
The following table describes the action to be taken by a dCDN for Table 2: Action to be taken by a tCDN for the different combinations
the different "mandatory-to-enforce" (MtE) and "incomprehensible" of MtE and StR properties
(Incomp) cases, when the dCDN either does or does not understand the
metadata in question:
+-------+------------+--------+-------------------------------------+ Table 3 describes the action to be taken by a dCDN for the different
| MtE | Metadata | Incomp | Actions | combinations of "mandatory-to-enforce" (MtE) and "incomprehensible"
| | Understood | | | (Incomp) properties, when the dCDN either does or does not understand
+-------+------------+--------+-------------------------------------+ the metadata in question:
| False | True | False | Can serve. |
| False | True | True | Can serve but MUST NOT | +-------+--------------+--------+-----------------------------------+
| | | | interpret/apply any metadata marked | | MtE | Metadata | Incomp | Action |
| | | | incomprehensible. | | | Understood | | |
| False | False | False | Can serve. | | | by dCDN | | |
| False | False | True | Can serve but MUST NOT | +-------+--------------+--------+-----------------------------------+
| | | | interpret/apply any metadata marked | | False | True | False | Can serve. |
| | | | incomprehensible. | | False | True | True | Can serve but MUST NOT |
| True | True | False | Can serve. | | | | | interpret/apply any metadata |
| True | True | True | MUST NOT serve. | | | | | marked incomprehensible. |
| True | False | False | MUST NOT serve. | | False | False | False | Can serve. |
| True | False | True | MUST NOT serve. | | False | False | True | Can serve but MUST NOT |
+-------+------------+--------+-------------------------------------+ | | | | interpret/apply any metadata |
| | | | marked incomprehensible. |
| True | True | False | Can serve. |
| True | True | True | MUST NOT serve. |
| True | False | False | MUST NOT serve. |
| True | False | True | MUST NOT serve. |
+-------+--------------+--------+-----------------------------------+
Table 3: Action to be taken by a dCDN for the different combinations
of MtE and Incomp properties
3.3. Metadata Inheritance and Override 3.3. Metadata Inheritance and Override
In the Metadata model, a HostMetadata object may contain (or In the Metadata model, a HostMetadata object may contain (or
reference) multiple PathMetadata objects (via PathMatch objects). reference) multiple PathMetadata objects (via PathMatch objects).
Each PathMetadata object may in turn contain (or reference) other Each PathMetadata object may in turn contain (or reference) other
PathMetadata objects. HostMetadata and PathMetadata objects form an PathMetadata objects. HostMetadata and PathMetadata objects form an
inheritance tree where each node in the tree inherits or overrides inheritance tree where each node in the tree inherits or overrides
the property values set by its parent. the property values set by its parent.
skipping to change at page 14, line 36 skipping to change at page 14, line 10
requests for content under "example.com/movies/", and requests for content under "example.com/movies/", and
o the LocationACL defined in the HostMetadata would be inherited for o the LocationACL defined in the HostMetadata would be inherited for
all User Agent requests for content under "example.com/movies/". all User Agent requests for content under "example.com/movies/".
o A single HostMetadata or PathMetadata object SHOULD NOT contain o A single HostMetadata or PathMetadata object SHOULD NOT contain
multiple GenericMetadata objects of the same type. If a list of multiple GenericMetadata objects of the same type. If a list of
GenericMetadata contains objects of duplicate types, the receiver GenericMetadata contains objects of duplicate types, the receiver
MUST ignore all but the first object of each type. MUST ignore all but the first object of each type.
4. Encoding-Independent CDNI Metadata Object Descriptions 4. CDNI Metadata objects
Section 4.1 provides the definitions of each metadata object type Section 4.1 provides the definitions of each metadata object type
declared in Section 3. These metadata objects are described as introduced in Section 3. These metadata objects are described as
structural objects as they provide the structure for the inheritance structural metadata objects as they provide the structure for the
tree and identify which specific properties apply to a given User inheritance tree and identify which specific properties apply to a
Agent content request. given User Agent content request.
Section 4.2 provides the definitions for a base set of core metadata Section 4.2 provides the definitions for a base set of core metadata
objects which may be contained within a GenericMetadata object. objects which may be contained within a GenericMetadata object.
These metadata objects are described as property objects, as they These metadata objects are described as property objects, as they
define the structure, semantics, and enforcement options for specific define the structure, semantics, and enforcement options for specific
properties of the metadata being described. Property objects govern properties of the metadata being described. Property objects govern
how User Agent requests for content are handled. Property objects how User Agent requests for content are handled. Property objects
may be composed of, or contain references to, other property sub- may be composed of, or contain references to, other property sub-
objects (i.e., property objects contained within or referenced by the objects (i.e., property objects contained within or referenced by the
property object that refers to that property sub-object). In those property object that refers to that property sub-object). As with
cases the value of the property sub-objects can be either a complete all CDNI Metadata object, the value of the property sub-objects can
serialized representation of the sub-object, or a Link object that be either a complete serialized representation of the sub-object, or
contains a URI that can be dereferenced to retrieve the complete a Link object that contains a URI that can be dereferenced to
serialized representation of the property sub-object. retrieve the complete serialized representation of the property sub-
object.
Section 6.5 discusses the ability to extend the base set of metadata Section 6.5 discusses the ability to extend the base set of metadata
objects specified in this document with additional standards based or objects specified in this document with additional standards based or
vendor specific property objects that may be defined in the future in vendor specific property objects that may be defined in the future in
separate documents. separate documents.
Downstream CDNs MUST support parsing of all CDNI metadata objects dCDNs and tCDNs MUST support parsing of all CDNI metadata objects
specified in this document. A dCDN does not have to implement the specified in this document. A dCDN does not have to implement the
underlying functionality represented by the metadata object, though underlying functionality represented by the metadata object, though
that may restrict the content that a given dCDN can serve. uCDNs as that may restrict the content that a given dCDN can serve. uCDNs as
generators of CDNI Metadata only need to support generating the CDNI generators of CDNI Metadata only need to support generating the CDNI
metadata that they need in order to express the policies and metadata that they need in order to express the policies and
treatment required by the content they are describing. treatment required by the content they are describing.
Note: In the following sections, the term "mandatory-to-specify" is Note: In the following sections, the term "mandatory-to-specify" is
used to convey which property sub-objects MUST be specified for a used to convey which properties MUST be included for a given
given structural or property object. When mandatory-to-specify is structural or property object. When mandatory-to-specify is
specified as "Yes" by this document for an individual property or specified as "Yes" by this document for an individual property, it
sub-object, it means that if the property object containing that means that if the object containing that property is included in a
property or sub-object is included in a metadata response, then the metadata response, then the mandatory-to-specify property MUST also
mandatory-to-specify property or sub-object MUST also be included be included (directly or by reference) in the response, e.g., a
(directly or by reference) in the response, e.g., a HostMatch HostMatch property object without a host to match against does not
property object without a host to match against does not make sense, make sense, therefore, the host property is mandatory-to-specify
therefore, the host is mandatory-to-specify inside a HostMatch inside a HostMatch object.
property object.
4.1. Descriptions of the CDNI Structural Metadata Objects 4.1. Definitions of the CDNI structural metadata objects
Each of the sub-sections below describe the structural objects Each of the sub-sections below describe the structural objects
defined in Table 2. introduced in Section 3.1.
4.1.1. HostIndex 4.1.1. HostIndex
The HostIndex object is the entry point into the CDNI Metadata The HostIndex object is the entry point into the CDNI Metadata
hierarchy. It contains (or references) a list of HostMatch objects. hierarchy. It contains a list of HostMatch objects. An incoming
An incoming content request is checked against the hostname (or IP content request is checked against the hostname (or IP address)
address) specified by each of the listed HostMatch objects to find specified by each of the listed HostMatch objects to find the
the HostMatch object which applies to the request. HostMatch object which applies to the request.
Property: hosts Property: hosts
Description: List of HostMatch objects. Hosts (HostMatch Description: List of HostMatch objects. Hosts (HostMatch
objects) MUST be evaluated in the order they appear and the objects) MUST be evaluated in the order they appear and the
first HostMatch object that matches the content request being first HostMatch object that matches the content request being
processed MUST be used. processed MUST be used.
Type: List of HostMatch objects Type: List of HostMatch objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Example HostIndex object containing two HostMatch objects, where the
first HostMatch object is embedded and the second HostMatch object is
referenced:
{
"hosts": [
{
<Properties of embedded HostMatch object>
},
{
"type": "application/cdni.HostMatch.v1+json",
"href": "http://metadata.ucdn.example/hostmatch1234"
}
]
}
4.1.2. HostMatch 4.1.2. HostMatch
The HostMatch object contains a hostname or IP address to match The HostMatch object contains a hostname or IP address to match
against content requests. The HostMatch object also contains or against content requests. The HostMatch object also contains or
references a HostMetadata object to apply if a match is found. references a HostMetadata object to apply if a match is found.
Property: host Property: host
Description: String (hostname or IP address) to match against Description: String (hostname or IP address) to match against
the requested host. In order for a hostname or IP address in a the requested host. In order for a hostname or IP address in a
skipping to change at page 16, line 39 skipping to change at page 16, line 33
Property: host-metadata Property: host-metadata
Description: CDNI Metadata to apply when delivering content Description: CDNI Metadata to apply when delivering content
that matches this host. that matches this host.
Type: HostMetadata Type: HostMetadata
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Example HostMatch object with an embedded HostMetadata object:
{
"host": "video.example.com",
"host-metadata" : {
<Properties of embedded HostMetadata object>
}
}
Example HostMatch object referencing a HostMetadata object:
{
"host": "video.example.com",
"host-metadata" : {
"type": "application/cdni.HostMetadata.v1+json",
"href": "http://metadata.ucdn.example/host1234"
}
}
4.1.3. HostMetadata 4.1.3. HostMetadata
A HostMetadata object contains (or references) the CDNI Metadata A HostMetadata object contains (or references) the CDNI Metadata
properties for content served for a particular host (defined in the properties for content served for a particular host (defined in the
HostMatch object) and possibly child PathMatch objects. HostMatch object) and possibly child PathMatch objects.
Property: metadata Property: metadata
Description: List of host related metadata. Description: List of host related metadata.
skipping to change at page 17, line 16 skipping to change at page 17, line 30
Description: Path specific rules. Path patterns (PathMatch Description: Path specific rules. Path patterns (PathMatch
objects) MUST be evaluated in the order they appear and the objects) MUST be evaluated in the order they appear and the
first PathMatch object that matches the content request being first PathMatch object that matches the content request being
processed MUST be used. processed MUST be used.
Type: List of PathMatch objects Type: List of PathMatch objects
Mandatory-to-Specify: No. Mandatory-to-Specify: No.
Example HostMetadata object containing a number of embedded
GenericMetadata objects that will describe the default metadata for
the host and a single embedded PathMatch object that will describe
the CDNI metadata for that path which overrides the default metadata
for the host:
{
"metadata": [
{
<Properties of 1st embedded GenericMetadata object>
},
{
<Properties of 2nd embedded GenericMetadata object>
},
...
{
<Properties of Nth embedded GenericMetadata object>
}
],
"paths": [
{
<Properties of embedded PathMatch object>
}
]
}
4.1.4. PathMatch 4.1.4. PathMatch
The PathMatch object contains (or references) an expression given as The PathMatch object contains (or references) an expression given as
a PatternMatch object to match against a resource URI path and a PatternMatch object to match against a resource URI path and
contains or references a PathMetadata object to apply if a match is contains or references a PathMetadata object to apply if a match is
found. found.
Property: path-pattern Property: path-pattern
Description: Pattern to match against the requested path, i.e., Description: Pattern to match against the requested path, i.e.,
skipping to change at page 17, line 41 skipping to change at page 19, line 5
Property: path-metadata Property: path-metadata
Description: CDNI Metadata to apply when delivering content Description: CDNI Metadata to apply when delivering content
that matches this path. that matches this path.
Type: PathMetadata Type: PathMetadata
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Example PathMatch object referencing the PathMetadata object to use
for URIs that match the case-sensitive URI path pattern "/movies/*"
(contained within an embedded PatternMatch object):
{
"path-pattern": {
"pattern": "/movies/*",
"case-sensitive": true
},
"path-metadata": {
"type": "application/cdni.PathMetadata.v1+json",
"href": "http://metadata.ucdn.example/host1234/pathDCE"
}
}
4.1.5. PatternMatch 4.1.5. PatternMatch
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
skipping to change at page 18, line 32 skipping to change at page 20, line 10
Description: List of query parameters which should be ignored Description: List of query parameters which should be ignored
when searching for a pattern match. Matching against query when searching for a pattern match. Matching against query
parameters to ignore MUST be case-insensitive. If all query parameters to ignore MUST be case-insensitive. If all query
parameters should be ignored then the list MUST be empty. parameters should be ignored then the list MUST be empty.
Type: List of String Type: List of String
Mandatory-to-Specify: No. Default is to include query strings Mandatory-to-Specify: No. Default is to include query strings
when matching. when matching.
Example PatternMatch object that matches the case-sensitive URI path
pattern "/movies/*". The query parameter "sessionid" will be ignored
when matching URIs requested from surrogates by content clients
against this path pattern:
{
"pattern": "/movies/*",
"case-sensitive": true,
"ignore-query-string": ["sessionid"]
}
4.1.6. PathMetadata 4.1.6. PathMetadata
A PathMetadata object contains (or references) the CDNI Metadata A PathMetadata object contains (or references) the CDNI Metadata
properties for content served with the associated URI path (defined properties for content served with the associated URI path (defined
in a PathMatch object) and possibly child PathMatch objects. in a PathMatch object) and possibly child PathMatch objects.
Note that if DNS-based redirection is employed, then a dCDN will be Note that if DNS-based redirection is employed, then a dCDN will be
unable to evaulate any metadata at the PathMetadata level or below unable to evaulate any metadata at the PathMetadata level or below
against the content redirection request at request routing time against the content redirection request at request routing time
because only the content request hostname is available at request because only the content request hostname is available at request
skipping to change at page 19, line 15 skipping to change at page 21, line 4
Type: List of GenericMetadata objects Type: List of GenericMetadata objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: paths Property: paths
Description: Path specific rules. First match applies. Description: Path specific rules. First match applies.
Type: List of PathMatch objects Type: List of PathMatch objects
Mandatory-to-Specify: No. Mandatory-to-Specify: No.
Example PathMetadata object containing a number of embedded
GenericMetadata objects that will describe the metadata to apply for
the path defined in the parent PathMatch object. that will describe
the CDNI metadata for that path which overrides the default metadata
for the host:
{
"metadata": [
{
<Properties of 1st embedded GenericMetadata object>
},
{
<Properties of 2nd embedded GenericMetadata object>
},
...
{
<Properties of Nth embedded GenericMetadata object>
}
],
}
4.1.7. GenericMetadata 4.1.7. GenericMetadata
A GenericMetadata object is an abstraction for managing individual A GenericMetadata object is an abstraction for managing individual
CDNI Metadata properties in an opaque manner. CDNI Metadata properties in an opaque manner.
Property: generic-metadata-type Property: generic-metadata-type
Description: Case-insensitive CDNI Metadata property object Description: Case-insensitive CDNI Metadata property object
type. type.
skipping to change at page 20, line 25 skipping to change at page 22, line 38
chain of delegation has failed to understand and/or failed to chain of delegation has failed to understand and/or failed to
properly transform this metadata object. Note: This flag only properly transform this metadata object. Note: This flag only
applies to metadata objects whose safe-to-redistribute property applies to metadata objects whose safe-to-redistribute property
has a value of False. has a value of False.
Type: Boolean Type: Boolean
Mandatory-to-Specify: No. Default is comprehensible (i.e., a Mandatory-to-Specify: No. Default is comprehensible (i.e., a
value of False). value of False).
4.2. Description of the CDNI Generic Metadata Objects Example GenericMetadata object containing a metadata object that
applies to the applicable URI path and/or host (within a parent
PathMetadata and/or HostMetadata object):
{
"mandatory-to-enforce": true,
"generic-metadata-type": <MIME Media Type of this metadata object>,
"generic-metadata-value":
{
<Properties of this metadata object>
}
}
4.2. Definitions of the initial set of CDNI Generic Metadata objects
The property objects defined below are intended to be used in the The property objects defined below are intended to be used in the
GenericMetadata object generic-metadata-value field as defined in GenericMetadata object generic-metadata-value field as defined in
Section 4.1.7 and their generic-metadata-type property MUST be set to Section 4.1.7 and their generic-metadata-type property MUST be set to
the appropriate Media Type as defined in Table 3. the appropriate Media Type as defined in Table 4.
4.2.1. SourceMetadata 4.2.1. SourceMetadata
Source Metadata provides the dCDN information about content Source Metadata provides the dCDN information about content
acquisition, i.e., how to contact an uCDN Surrogate or an Origin acquisition, i.e., how to contact an uCDN Surrogate or an Origin
Server to obtain the content to be served. The sources are not Server to obtain the content to be served. The sources are not
necessarily the actual Origin Servers operated by the CSP but might necessarily the actual Origin Servers operated by the CSP but might
be a set of Surrogates in the uCDN. be a set of Surrogates in the uCDN.
Endpoints within a source should be treated as equivalent/equal so Endpoints within a source should be treated as equivalent/equal so
skipping to change at page 21, line 4 skipping to change at page 23, line 32
source/preference rank one can specify a list of endpoints that are source/preference rank one can specify a list of endpoints that are
equivalent, e.g., a pool of servers that are not behind a load equivalent, e.g., a pool of servers that are not behind a load
balancer. balancer.
Property: sources Property: sources
Description: Sources from which the dCDN can acquire content, Description: Sources from which the dCDN can acquire content,
listed in order of preference. listed in order of preference.
Type: List of Source objects Type: List of Source objects
Mandatory-to-Specify: No. Default is to use static Mandatory-to-Specify: No. Default is to use static
configuration, out-of-band from the metadata interface. configuration, out-of-band from the metadata interface.
Example SourceMetadata object (which contains two Source objects)
that describes which servers the dCDN should use for acquiring
content for the applicable URI path and/or host:
{
"mandatory-to-enforce": true,
"generic-metadata-type": "application/cdni.SourceMetadata.v1+json"
"generic-metadata-value":
{
"sources": [
{
"generic-metadata-type":
"application/cdni.Source.v1+json"
"generic-metadata-value":
{
"endpoints": [
"a.service123.ucdn.example",
"b.service123.ucdn.example"
],
"protocol": "HTTP1.1"
}
},
{
"generic-metadata-type":
"application/cdni.Source.v1+json"
"generic-metadata-value":
{
"endpoints": ["origin.service123.example"],
"protocol": "HTTP1.1"
}
}
]
}
}
4.2.1.1. Source 4.2.1.1. Source
A Source object describes the Source which should be used by the dCDN A Source object describes the Source which should be used by the dCDN
for content acquisition, e.g., a Surrogate within the uCDN or an for content acquisition, e.g., a Surrogate within the uCDN or an
alternate Origin Server, the protocol to be used and any alternate Origin Server, the protocol to be used and any
authentication method. authentication method.
Property: acquisition-auth Property: acquisition-auth
Description: Authentication method to use when requesting Description: Authentication method to use when requesting
skipping to change at page 21, line 44 skipping to change at page 25, line 25
Property: protocol Property: protocol
Description: Network retrieval protocol to use when requesting Description: Network retrieval protocol to use when requesting
content from this source. content from this source.
Type: Protocol Type: Protocol
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Example Source object that describes a server the dCDN should use for
acquiring content for the applicable URI path and/or host:
{
"generic-metadata-type": "application/cdni.Source.v1+json"
"generic-metadata-value":
{
"endpoints": [
"a.service123.ucdn.example",
"b.service123.ucdn.example"
],
"protocol": "HTTP1.1"
}
}
4.2.2. LocationACL Metadata 4.2.2. LocationACL Metadata
LocationACL Metadata defines location-based restrictions. LocationACL Metadata defines location-based restrictions.
A LocationACL which does not include a locations property results in A LocationACL which does not include a locations property results in
an action of allow, meaning that delivery can be performed regardless an action of allow, meaning that delivery can be performed regardless
of the User Agent's location. The action from the first footprint to of the User Agent's location. The action from the first footprint to
match against the User Agent's location is the action a CDN MUST match against the User Agent's location is the action a CDN MUST
take. If two or more footprints overlap, the first footprint that take. If two or more footprints overlap, the first footprint that
matches against the User Agent's location determines the action a CDN matches against the User Agent's location determines the action a CDN
skipping to change at page 22, line 28 skipping to change at page 26, line 23
Property: locations Property: locations
Description: Access control list which allows or denies Description: Access control list which allows or denies
(blocks) delivery based on client location. (blocks) 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.
Example LocationACL object that allows the dCDN to deliver content to
any location/IP address:
{
"mandatory-to-enforce": true,
"generic-metadata-type": "application/cdni.LocationACL.v1+json"
"generic-metadata-value":
{
}
}
Example LocationACL object (which contains a LocationRule object
which itself contains a Footprint object) that only allows the dCDN
to deliver content to clients in the USA:
{
"mandatory-to-enforce": true,
"generic-metadata-type": "application/cdni.LocationACL.v1+json"
"generic-metadata-value":
{
"locationss": [
{
"generic-metadata-type":
"application/cdni.LocationRule.v1+json"
"generic-metadata-value":
{
"action": "allow",
"footprints": [
{
"generic-metadata-type":
"application/cdni.Footprint.v1+json"
"generic-metadata-value":
{
"footprint-type": "countrycode",
"footprint-value": "us"
}
}
]
}
}
]
}
}
4.2.2.1. LocationRule 4.2.2.1. LocationRule
A LocationRule contains or references a list of Footprint 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.
Property: action Property: action
Description: Defines whether the rule specifies locations to Description: Defines whether the rule specifies locations to
allow or deny. allow or deny.
Type: Enumeration [allow|deny] Type: Enumeration [allow|deny] encoded as a lowercase string
Mandatory-to-Specify: No. Default is deny. Mandatory-to-Specify: No. Default is deny.
4.2.2.2. Footprint 4.2.2.2. Footprint
A Footprint object describes the footprint to which a LocationRule A Footprint object describes the footprint to which a LocationRule
may be applied to, e.g., an IPv4 address range or a geographic may be applied to, e.g., an IPv4 address range or a geographic
location. location.
Property: footprint-type Property: footprint-type
Description: Registered footprint type. The footprint types Description: Registered footprint type. The footprint types
specified by this document are: IPv4CIDR (see Section 4.3.7), specified by this document are: "ipv4cidr" (IPv4CIDR, see
IPv6CIDR (see Section 4.3.8), Autonomous System Number (see Section 4.3.7), "ipv6cidr" (IPv6CIDR, see Section 4.3.8), "asn"
Section 4.3.9) and Country Code (see Section 4.3.10). (Autonomous System Number, see Section 4.3.9) and "countrycode"
(Country Code, see Section 4.3.10).
Type: String Type: Lowercase String
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: footprint-value Property: footprint-value
Description: Footprint object conforming to the specification Description: Footprint object conforming to the specification
associated with the registered footprint type. associated with the registered footprint type.
Type: String Type: String
skipping to change at page 24, line 32 skipping to change at page 29, line 35
Type: List of TimeWindow objects Type: List of TimeWindow objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: action Property: action
Description: Defines whether the rule specifies time windows to Description: Defines whether the rule specifies time windows to
allow or deny. allow or deny.
Type: Enumeration [allow|deny] Type: Enumeration [allow|deny] encoded as a lowercase string
Mandatory-to-Specify: No. Default is deny. Mandatory-to-Specify: No. Default is deny.
4.2.3.2. TimeWindow 4.2.3.2. TimeWindow
A TimeWindow object describes a time range which may be applied by an A TimeWindow object describes a time range which may be applied by an
TimeWindowACL, e.g., start 946717200 (i.e., 09:00AM 01/01/2000 UTC), TimeWindowACL, e.g., start 946717200 (i.e., 09:00AM 01/01/2000 UTC),
end: 946746000 (i.e., 17:00AM 01/01/2000 UTC). end: 946746000 (i.e., 17:00AM 01/01/2000 UTC).
Property: start Property: start
skipping to change at page 25, line 48 skipping to change at page 31, line 4
Mandatory-to-Specify: No. Default is allow all protocols. Mandatory-to-Specify: No. Default is allow all protocols.
4.2.4.1. ProtocolRule 4.2.4.1. ProtocolRule
A ProtocolRule contains or references a list of Protocol objects. A ProtocolRule contains or references a list of Protocol objects.
ProtocolRule objects are used to construct a ProtocolACL to apply ProtocolRule objects are used to construct a ProtocolACL to apply
restrictions to content acquisition or delivery. restrictions to content acquisition or delivery.
Property: protocols Property: protocols
Description: List of protocols to which the rule applies. Description: List of protocols to which the rule applies.
Type: List of protocol objects Type: List of Protocol objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: action Property: action
Description: Defines whether the rule specifies protocols to Description: Defines whether the rule specifies protocols to
allow or deny. allow or deny.
Type: Enumeration [allow|deny] Type: Enumeration [allow|deny] encoded as a lowercase string
Mandatory-to-Specify: No. Default is deny. Mandatory-to-Specify: No. Default is deny.
4.2.5. DeliveryAuthorization Metadata 4.2.5. DeliveryAuthorization Metadata
Delivery Authorization defines authorization methods for the delivery Delivery Authorization defines authorization methods for the delivery
of content to User Agents. of content to User Agents.
Property: delivery-auth-methods Property: delivery-auth-methods
skipping to change at page 31, line 7 skipping to change at page 36, line 7
may fail, so again the uCDN is likely to want to avoid delegating may fail, so again the uCDN is likely to want to avoid delegating
those requests to that dCDN. those requests to that dCDN.
The CDNI Footprint and Capabilities Interface (FCI) [RFC7336] The CDNI Footprint and Capabilities Interface (FCI) [RFC7336]
provides a means of advertising capabilities from dCDN to uCDN. provides a means of advertising capabilities from dCDN to uCDN.
Support for optional metadata and support for optional metadata Support for optional metadata and support for optional metadata
values may be advertised using the FCI. values may be advertised using the FCI.
6. CDNI Metadata interface 6. CDNI Metadata interface
This section specifies an interface to enable a Downstream CDN to This section specifies an interface to enable a dCDN to retrieve CDNI
retrieve CDNI Metadata objects from an Upstream CDN. Metadata objects from a uCDN.
The interface can be used by a Downstream CDN to retrieve CDNI The interface can be used by a dCDN to retrieve CDNI Metadata objects
Metadata objects either: either:
o Dynamically as required by the Downstream CDN to process received o Dynamically as required by the dCDN to process received requests.
requests. For example in response to a query from an Upstream CDN For example in response to a query from an uCDN over the CDNI
over the CDNI Request Routing Redirection interface (RI) Request Routing Redirection interface (RI)
[I-D.ietf-cdni-redirection] or in response to receiving a request [I-D.ietf-cdni-redirection] or in response to receiving a request
for content from a User Agent. Or; for content from a User Agent. Or;
o In advance of being required. For example in the case of Pre- o In advance of being required. For example in the case of pre-
positioned CDNI Metadata acquisition. positioned CDNI Metadata acquisition.
The CDNI Metadata interface is built on the principles of RESTful web The CDNI Metadata interface is built on the principles of RESTful web
services. In particular, this means that requests and responses over services. In particular, this means that requests and responses over
the interface are built around the transfer of representations of the interface are built around the transfer of representations of
hyperlinked resources. A resource in the context of the CDNI hyperlinked resources. A resource in the context of the CDNI
Metadata interface is any object in the Data Model (as described in Metadata interface is any object in the Data Model (as described in
Section 3 and Section 4). Section 3 and Section 4).
To retrieve CDNI metadata, a CDNI Metadata client (i.e., a client in To retrieve CDNI metadata, a CDNI Metadata client (i.e., a client in
the dCDN) first makes a HTTP GET request for the URI of the HostIndex the dCDN) first makes a HTTP GET request for the URI of the HostIndex
which provides the CDNI Metadata client with a list of Hostnames for which provides the CDNI Metadata client with a list of Hostnames for
which the upstream CDN may delegate content delivery to the which the uCDN may delegate content delivery to the dCDN. The CDNI
downstream CDN. The CDNI Metadata client can then obtain any other Metadata client can then obtain any other CDNI Metadata objects by
CDNI Metadata objects by making a HTTP GET requests for any linked making a HTTP GET requests for any linked Metadata objects it
Metadata objects it requires. requires.
CDNI Metadata servers (i.e., servers in the uCDN) are free to assign CDNI Metadata servers (i.e., servers in the uCDN) are free to assign
whatever structure they desire to the URIs for CDNI Metadata objects whatever structure they desire to the URIs for CDNI Metadata objects
and CDNI Metadata clients MUST NOT make any assumptions regarding the and CDNI Metadata clients MUST NOT make any assumptions regarding the
structure of CDNI Metadata URIs or the mapping between CDNI Metadata structure of CDNI Metadata URIs or the mapping between CDNI Metadata
objects and their associated URIs. Therefore any URIs present in the objects and their associated URIs. Therefore any URIs present in the
examples below are purely illustrative and are not intended to impose examples below are purely illustrative and are not intended to impose
a definitive structure on CDNI Metadata interface implementations. a definitive structure on CDNI Metadata interface implementations.
6.1. Transport 6.1. Transport
skipping to change at page 32, line 32 skipping to change at page 37, line 32
returned response/representation can be reused without re-contacting returned response/representation can be reused without re-contacting
the CDNI Metadata server. the CDNI Metadata server.
6.2. Retrieval of CDNI Metadata resources 6.2. Retrieval of CDNI Metadata resources
In the general case a CDNI Metadata server makes each instance of an In the general case a CDNI Metadata server makes each instance of an
addressable CDNI Metadata object available via a unique URI and addressable CDNI Metadata object available via a unique URI and
therefore in order to retrieve CDNI Metadata, a CDNI Metadata client therefore in order to retrieve CDNI Metadata, a CDNI Metadata client
first makes a HTTP GET request for the URI of the HostIndex which first makes a HTTP GET request for the URI of the HostIndex which
provides the CDNI Metadata client with a list of Hostnames for which provides the CDNI Metadata client with a list of Hostnames for which
the upstream CDN may delegate content delivery to the downstream CDN. the uCDN may delegate content delivery to the dCDN.
In order to retrieve the CDNI Metadata for a particular request the In order to retrieve the CDNI Metadata for a particular request the
CDNI Metadata client processes the received HostIndex object and CDNI Metadata client processes the received HostIndex object and
finds the corresponding HostMetadata entry (by matching the hostname finds the corresponding HostMetadata entry (by matching the hostname
in the request against the hostnames listed in the HostMatch in the request against the hostnames listed in the HostMatch
objects). If the HostMetadata is linked (rather than embedded), the objects). If the HostMetadata is linked (rather than embedded), the
CDNI metadata client then makes a GET request for the URI specified CDNI metadata client then makes a GET request for the URI specified
in the href property of the Link object which points to the in the href property of the Link object which points to the
HostMetadata object itself. HostMetadata object itself.
skipping to change at page 33, line 17 skipping to change at page 38, line 17
the uCDN is uncontactable or returns an HTTP 4xx or 5xx status in the uCDN is uncontactable or returns an HTTP 4xx or 5xx status in
response to some or all of the dCDN's CDNI metadata requests, the response to some or all of the dCDN's CDNI metadata requests, the
dCDN MUST NOT serve the requested content unless the dCDN has stale dCDN MUST NOT serve the requested content unless the dCDN has stale
versions of all the required metadata and the stale-if-error Cache- versions of all the required metadata and the stale-if-error Cache-
Control extension [RFC5861] was included in all previous responses Control extension [RFC5861] was included in all previous responses
that are required but cannot currently be retrieved. The dCDN can that are required but cannot currently be retrieved. The dCDN can
continue to serve other content for which it can retrieve (or for continue to serve other content for which it can retrieve (or for
which it has fresh responses cached) all the required metadata even which it has fresh responses cached) all the required metadata even
if some non-applicable part of the metadata tree is missing. if some non-applicable part of the metadata tree is missing.
Where a downstream CDN is interconnected with multiple upstream CDNs, Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to
the downstream CDN needs to determine which upstream CDN's CDNI determine which uCDN's CDNI metadata should be used to handle a
metadata should be used to handle a particular User Agent request. particular User Agent request.
When application level redirection (e.g., HTTP 302 redirects) is When application level redirection (e.g., HTTP 302 redirects) is
being used between CDNs, it is expected that the downstream CDN will being used between CDNs, it is expected that the dCDN will be able to
be able to determine the upstream CDN that redirected a particular determine the uCDN that redirected a particular request from
request from information contained in the received request (e.g., via information contained in the received request (e.g., via the URI).
the URI). With knowledge of which upstream CDN routed the request, With knowledge of which uCDN routed the request, the dCDN can choose
the downstream CDN can choose the correct metadata server from which the correct metadata server from which to obtain the HostIndex. Note
to obtain the HostIndex. Note that the HostIndex served by each uCDN that the HostIndex served by each uCDN may be unique.
may be unique.
In the case of DNS redirection there is not always sufficient In the case of DNS redirection there is not always sufficient
information carried in the DNS request from User Agents to determine information carried in the DNS request from User Agents to determine
the upstream CDN that redirected a particular request (e.g., when the uCDN that redirected a particular request (e.g., when content
content from a given host is redirected to a given downstream CDN by from a given host is redirected to a given dCDN by more than one
more than one upstream CDN) and therefore downstream CDNs may have to uCDN) and therefore dCDNs may have to apply local policy when
apply local policy when deciding which upstream CDN's metadata to deciding which uCDN's metadata to apply.
apply.
6.3. Bootstrapping 6.3. Bootstrapping
The URI for the HostIndex object of a given upstream CDN needs to be The URI for the HostIndex object of a given uCDN needs to be either
either configured in, or discovered by, the downstream CDN. All configured in, or discovered by, the dCDN. All other objects/
other objects/resources are then discoverable from the HostIndex resources are then discoverable from the HostIndex object by
object by following the links in the HostIndex object and the following the links in the HostIndex object and the referenced
referenced HostMetadata and PathMetadata objects. HostMetadata and PathMetadata objects.
If the URI for the HostIndex object is not manually configured in the If the URI for the HostIndex object is not manually configured in the
downstream CDN then the HostIndex URI could be discovered. A dCDN then the HostIndex URI could be discovered. A mechanism
mechanism allowing the downstream CDN to discover the URI of the allowing the dCDN to discover the URI of the HostIndex is outside the
HostIndex is outside the scope of this document. scope of this document.
6.4. Encoding 6.4. Encoding
Objects are resources that may be: Objects 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 within a property of an o Embedded, where the object is contained within a property of an
addressable object. addressable object.
skipping to change at page 34, line 28 skipping to change at page 39, line 28
when and which CDNI Metadata objects to embed and which are made when and which CDNI Metadata objects to embed and which are made
separately addressable. separately addressable.
6.4.1. MIME Media Types 6.4.1. MIME Media Types
All MIME media types for CDNI Metadata objects are prefixed with All MIME media types for CDNI Metadata objects are prefixed with
"application/cdni.". The MIME media type for each object then "application/cdni.". The MIME media type for each object then
contains the object name of that object as defined by this document. contains the object name of that object as defined by this document.
The object type name is followed by ".v" and the version number of The object type name is followed by ".v" and the version number of
the object type (e.g., ".v1"). Finally, the encoding type "+json" is the object type (e.g., ".v1"). Finally, the encoding type "+json" is
appended. Table 3 lists the MIME media type for the metadata objects appended. Table 4 lists the MIME media type for the metadata objects
(resources) that are specified in this document. (resources) that are specified in this document.
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| Data Object | MIME Media Type | | Data Object | MIME Media Type |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
| HostIndex | application/cdni.HostIndex.v1+json | | HostIndex | application/cdni.HostIndex.v1+json |
| HostMatch | application/cdni.HostMatch.v1+json | | HostMatch | application/cdni.HostMatch.v1+json |
| HostMetadata | application/cdni.HostMetadata.v1+json | | HostMetadata | application/cdni.HostMetadata.v1+json |
| PathMatch | application/cdni.PathMatch.v1+json | | PathMatch | application/cdni.PathMatch.v1+json |
| PatternMatch | application/cdni.PatternMatch.v1+json | | PatternMatch | application/cdni.PatternMatch.v1+json |
skipping to change at page 35, line 33 skipping to change at page 40, line 33
| ProtocolACL | application/cdni.ProtocolACL.v1+json | | ProtocolACL | application/cdni.ProtocolACL.v1+json |
| ProtocolRule | application/cdni.ProtocolRule.v1+json | | ProtocolRule | application/cdni.ProtocolRule.v1+json |
| DeliveryAuthorization | application/ | | DeliveryAuthorization | application/ |
| | cdni.DeliveryAuthorization.v1+json | | | cdni.DeliveryAuthorization.v1+json |
| Cache | application/cdni.Cache.v1+json | | Cache | application/cdni.Cache.v1+json |
| Grouping | application/cdni.Grouping.v1+json | | Grouping | application/cdni.Grouping.v1+json |
| Auth | application/cdni.Auth.v1+json | | Auth | application/cdni.Auth.v1+json |
| CredentialsAuth | application/cdni.CredentialAuth.v1+json | | CredentialsAuth | application/cdni.CredentialAuth.v1+json |
+-----------------------+-------------------------------------------+ +-----------------------+-------------------------------------------+
Table 3: MIME Media Types for CDNI Metadata objects Table 4: MIME Media Types for CDNI Metadata objects
6.4.2. JSON Encoding of Objects 6.4.2. I-JSON Encoding of Objects
A CDNI Metadata object is encoded as a JSON object containing a A CDNI Metadata object is encoded as an I-JSON object [RFC7492]
dictionary of (key,value) pairs where the keys are the property names containing a dictionary of (key,value) pairs where the keys are the
and the values are the associated property values. property names 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 dependent on the specific object being encoded (i.e., dependent on
the MIME Media Type of the returned resource). the MIME Media Type of the returned resource).
Dictionary keys in JSON are case sensitive. By convention any Dictionary keys in JSON are case sensitive. By convention any
dictionary key defined by this document (for example the names of dictionary key defined by this document (for example the names of
skipping to change at page 36, line 31 skipping to change at page 41, line 31
Description: The links from this object to other addressable Description: The links from this object to other addressable
objects. Any property whose value is an object may be replaced objects. Any property whose value is an object may be replaced
by a link to an object with the same type as the property it by a link to an object with the same type as the property it
replaces. The keys of the _links dictionary are the names of replaces. The keys of the _links dictionary are the names of
the properties being replaced. The values of the dictionary the properties being replaced. The values of the dictionary
are Link objects with href set to the URI of the object and are Link objects with href set to the URI of the object and
type set to the MIME media type of the object being replaced. type set to the MIME media type of the object being replaced.
Type: Dictionary object of Link objects Type: Dictionary object of Link objects
Mandatory: Yes Mandatory: No
6.4.2.1. Encoded CDNI Metadata Example 6.4.2.1. Encoded CDNI Metadata Example
A downstream CDN may request the HostIndex and receive the following A dCDN may request the HostIndex and receive the following object of
object of type "application/cdni.HostIndex.v1+json": type "application/cdni.HostIndex.v1+json":
{ {
"hosts": [ "hosts": [
{ {
"host": "video.example.com", "host": "video.example.com",
"_links": { "_links": {
"host-metadata" : { "host-metadata" : {
"type": "application/cdni.HostMetadata.v1+json", "type": "application/cdni.HostMetadata.v1+json",
"href": "http://metadata.ucdn.example/host1234" "href": "http://metadata.ucdn.example/host1234"
} }
skipping to change at page 37, line 29 skipping to change at page 42, line 29
"host-metadata" : { "host-metadata" : {
"type": "application/cdni.HostMetadata.v1+json", "type": "application/cdni.HostMetadata.v1+json",
"href": "http://metadata.ucdn.example/host5678" "href": "http://metadata.ucdn.example/host5678"
} }
} }
} }
] ]
} }
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 the next metadata object from then the dCDN would fetch the next metadata object from
"http://metadata.ucdn.example/host1234" expecting a MIME media type "http://metadata.ucdn.example/host1234" expecting a MIME media type
of "application/cdni.HostMetadata.v1+json": of "application/cdni.HostMetadata.v1+json":
{ {
"metadata": [ "metadata": [
{ {
"generic-metadata-type": "generic-metadata-type":
"application/cdni.SourceMetadata.v1+json", "application/cdni.SourceMetadata.v1+json",
"generic-metadata-value": { "generic-metadata-value": {
"sources": [ "sources": [
{ {
"_links": { "_links": {
"acquisition-auth": { "acquisition-auth": {
"auth-type": "application/cdni.Auth.v1+json", "auth-type": "application/cdni.Auth.v1+json",
"href": "http://metadata.ucdn.example/auth1234" "href": "http://metadata.ucdn.example/auth1234"
} }
}, },
"endpoint": "acq1.ucdn.example", "endpoint": "acq1.ucdn.example",
"protocol": "ftp" "protocol": "HTTP1.1"
}, },
{ {
"_links": { "_links": {
"acquisition-auth": { "acquisition-auth": {
"auth-type": "application/cdni.Auth.v1+json", "auth-type": "application/cdni.Auth.v1+json",
"href": "http://metadata.ucdn.example/auth1234" "href": "http://metadata.ucdn.example/auth1234"
} }
}, },
"endpoint": "acq2.ucdn.example", "endpoint": "acq2.ucdn.example",
"protocol": "http" "protocol": "HTTP1.1"
} }
] ]
} }
}, },
{ {
"generic-metadata-type": "generic-metadata-type":
"application/cdni.LocationACL.v1+json", "application/cdni.LocationACL.v1+json",
"generic-metadata-value": { "generic-metadata-value": {
"locations": [ "locations": [
{ {
skipping to change at page 38, line 38 skipping to change at page 43, line 38
] ]
} }
}, },
{ {
"generic-metadata-type": "generic-metadata-type":
"application/cdni.ProtocolACL.v1+json", "application/cdni.ProtocolACL.v1+json",
"generic-metadata-value": { "generic-metadata-value": {
"protocol-acl": [ "protocol-acl": [
{ {
"protocols": [ "protocols": [
"ftp" "HTTP1.1"
], ],
"action": "deny" "action": "allow"
} }
] ]
} }
} }
], ],
"paths": [ "paths": [
{ {
"path-pattern": { "path-pattern": {
"pattern": "/video/trailers/*" "pattern": "/video/trailers/*"
}, },
skipping to change at page 39, line 48 skipping to change at page 44, line 48
"type": "application/cdni.PathMetadata.v1+json", "type": "application/cdni.PathMetadata.v1+json",
"href": "href":
"http://metadata.ucdn.example/host1234/pathABC/path123" "http://metadata.ucdn.example/host1234/pathABC/path123"
} }
} }
} }
] ]
} }
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 "/videos/movies/hd/*" pattern, the dCDN would also fetch the
the following object from following object from "http://metadata.ucdn.example/host1234/movies/
"http://metadata.ucdn.example/host1234/movies/hd" with MIME media hd" with MIME media type "application/cdni.PathMetadata.v1+json":
type "application/cdni.PathMetadata.v1+json":
{ {
"metadata": [ "metadata": [
{ {
"generic-metadata-type": "generic-metadata-type":
"application/cdni.TimeWindowACL.v1+json", "application/cdni.TimeWindowACL.v1+json",
"generic-metadata-value": { "generic-metadata-value": {
"times": [ "times": [
"windows": [ "windows": [
{ {
skipping to change at page 44, line 8 skipping to change at page 49, line 8
to the "Expert Review" policy as defined in [RFC5226]. The expert to the "Expert Review" policy as defined in [RFC5226]. The expert
reviewer should verify that new type definitions do not duplicate reviewer should verify that new type definitions do not duplicate
existing type definitions and prevent gratuitous additions to the existing type definitions and prevent gratuitous additions to the
namespace. namespace.
The following table defines the initial Footprint Registry values: The following table defines the initial Footprint Registry values:
+----------------+-------------------------------+---------------+ +----------------+-------------------------------+---------------+
| Footprint Type | Description | Specification | | Footprint Type | Description | Specification |
+----------------+-------------------------------+---------------+ +----------------+-------------------------------+---------------+
| IPv4CIDR | IPv4 CIDR address block | RFCthis | | ipv4cidr | IPv4 CIDR address block | RFCthis |
| IPv6CIDR | IPv6 CIDR address block | RFCthis | | ipv6cidr | IPv6 CIDR address block | RFCthis |
| 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 |
+----------------+-------------------------------+---------------+ +----------------+-------------------------------+---------------+
7.2. CDNI Metadata Protocol Types Registry 7.2. CDNI Metadata Protocol Types Registry
The IANA is requested to create a new "CDNI Metadata Protocol Types" The IANA is requested to create a new "CDNI Metadata Protocol Types"
registry. The "CDNI Metadata Protocol Types" namespace defines the registry. The "CDNI Metadata Protocol Types" namespace defines the
valid Protocol object values in Section 4.3.2, used by the valid Protocol object values in Section 4.3.2, used by the
SourceMetadata and ProtocolACL objects. Additions to the Protocol SourceMetadata and ProtocolACL objects. Additions to the Protocol
namespace conform to the "Expert Review" policy as defined in namespace conform to the "Expert Review" policy as defined in
[RFC5226]. The expert review should verify that new protocol [RFC5226]. The expert review should verify that new protocol
skipping to change at page 47, line 11 skipping to change at page 52, line 11
o The dCDN and uCDN to authenticate each other (to ensure they are o The dCDN and uCDN to authenticate each other (to ensure they are
transmitting/receiving CDNI Metadata requests & responses from an transmitting/receiving CDNI Metadata requests & responses from an
authenticated CDN). authenticated CDN).
o CDNI Metadata interface requests and responses to be transmitted o CDNI Metadata interface requests and responses to be transmitted
with confidentiality. with confidentiality.
o The integrity of the CDNI Metadata interface requests and o The integrity of the CDNI Metadata interface requests and
responses to be protected during the exchange. responses to be protected during the exchange.
In an environment where any such protection is required, TLS SHOULD In an environment where any such protection is required, TLS MUST be
be used (including authentication of the remote end) by the server- used (including authentication of the remote end) by the server-side
side (uCDN) and the client-side (dCDN) of the CDNI Metadata interface (uCDN) and the client-side (dCDN) of the CDNI Metadata interface
unless alternate methods are used for ensuring the confidentiality of unless alternate methods are used for ensuring the confidentiality of
the information in the CDNI Metadata interface requests and responses the information in the CDNI Metadata interface requests and responses
(such as setting up an IPsec tunnel between the two CDNs or using a (such as setting up an IPsec tunnel between the two CDNs or using a
physically secured internal network between two CDNs that are owned physically secured internal network between two CDNs that are owned
by the same corporate entity). by the same corporate entity).
An implementation of the CDNI Metadata interface MUST support the When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ([RFC5288]). An followed.
implementation of the CDNI Metadata interface SHOULD prefer cipher
suites which support perfect forward secrecy over cipher suites that
don't.
9. Acknowledgements 9. Acknowledgements
The authors would like to thank David Ferguson and Francois Le The authors would like to thank David Ferguson and Francois Le
Faucheur for their valuable comments and input to this document. Faucheur for their valuable comments and input to this document.
10. Contributing Authors 10. Contributing Authors
[RFC Editor Note: Please move the contents of this section to the [RFC Editor Note: Please move the contents of this section to the
Authors' Addresses section prior to publication as an RFC.] Authors' Addresses section prior to publication as an RFC.]
skipping to change at page 48, line 10 skipping to change at page 53, line 10
San Jose, 95134 San Jose, 95134
USA USA
Email: kleung@cisco.com Email: kleung@cisco.com
11. References 11. References
11.1. Normative References 11.1. Normative References
[ISO3166-1] [ISO3166-1]
"https://www.iso.org/obp/ui/#search", . "https://www.iso.org/obp/ui/#search".
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[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.
skipping to change at page 48, line 32 skipping to change at page 53, line 32
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale
Content", RFC 5861, May 2010. Content", RFC 5861, May 2010.
[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.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
11.2. Informative References 11.2. Informative References
[I-D.ietf-cdni-redirection] [I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection Interface for CDN Interconnection", draft- Redirection Interface for CDN Interconnection", draft-
ietf-cdni-redirection-08 (work in progress), February ietf-cdni-redirection-10 (work in progress), July 2015.
2015.
[I-D.ietf-httpbis-http2]
Belshe, M., Peon, R., and M. Thomson, "Hypertext Transfer
Protocol version 2", draft-ietf-httpbis-http2-17 (work in
progress), February 2015.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
skipping to change at page 49, line 13 skipping to change at page 54, line 25
2014. 2014.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014. Interconnection (CDNI)", RFC 7336, August 2014.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", RFC 7337, August Interconnection (CDNI) Requirements", RFC 7337, August
2014. 2014.
[RFC7492] Bhatia, M., Zhang, D., and M. Jethanandani, "Analysis of
Bidirectional Forwarding Detection (BFD) Security
According to the Keying and Authentication for Routing
Protocols (KARP) Design Guidelines", RFC 7492, March 2015.
[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.
Authors' Addresses Authors' Addresses
Ben Niven-Jenkins Ben Niven-Jenkins
Velocix (Alcatel-Lucent) Velocix (Alcatel-Lucent)
3 Ely Road 3 Ely Road
Milton, Cambridge CB24 6AA Milton, Cambridge CB24 6AA
 End of changes. 89 change blocks. 
349 lines changed or deleted 549 lines changed or added

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