draft-ietf-cdni-metadata-19.txt   draft-ietf-cdni-metadata-20.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: January 9, 2017 M. Caulfield Expires: February 3, 2017 M. Caulfield
Cisco Systems Cisco Systems
K. Ma K. Ma
Ericsson Ericsson
July 8, 2016 August 2, 2016
CDN Interconnection Metadata CDN Interconnection Metadata
draft-ietf-cdni-metadata-19 draft-ietf-cdni-metadata-20
Abstract Abstract
The Content Delivery Networks Interconnection (CDNI) metadata The Content Delivery Networks Interconnection (CDNI) metadata
interface enables interconnected Content Delivery Networks (CDNs) to interface enables interconnected Content Delivery Networks (CDNs) to
exchange content distribution metadata in order to enable content exchange content distribution metadata in order to enable content
acquisition and delivery. The CDNI metadata associated with a piece acquisition and delivery. The CDNI metadata associated with a piece
of content provides a downstream CDN with sufficient information for of content provides a downstream CDN with sufficient information for
the downstream CDN to service content requests on behalf of an the downstream CDN to service content requests on behalf of an
upstream CDN. This document describes both a base set of CDNI upstream CDN. This document describes both a base set of CDNI
skipping to change at page 1, line 47 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 January 9, 2017. This Internet-Draft will expire on February 3, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 39 skipping to change at page 2, line 39
3.2. Generic CDNI Metadata Objects . . . . . . . . . . . . . . 10 3.2. Generic CDNI Metadata Objects . . . . . . . . . . . . . . 10
3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13
4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 14 4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 14
4.1. Definitions 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 . . . . . . . . . . . . . . . . . . . . . . 15 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 15
4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17
4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 18 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 18
4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 19 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 19
4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 20 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 20
4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 22 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 21
4.2. Definitions of the initial set of CDNI Generic Metadata 4.2. Definitions of the initial set of CDNI Generic Metadata
objects . . . . . . . . . . . . . . . . . . . . . . . . . 23 objects . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 23 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 23
4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 24 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 24
4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 25 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 25
4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 27 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 27
4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 28 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 27
4.2.3. TimeWindowACL . . . . . . . . . . . . . . . . . . . . 29 4.2.3. TimeWindowACL . . . . . . . . . . . . . . . . . . . . 29
4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 30 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 30
4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 31 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 31
4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 32 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 31
4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 33 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 32
4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 33 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 33
4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 34 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 34
4.2.7. Auth . . . . . . . . . . . . . . . . . . . . . . . . 35 4.2.7. Auth . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 36 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 37
4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 36 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 37
4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 36 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 37
4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 38 4.3.1.1. Link Loop Prevention . . . . . . . . . . . . . . 39
4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 38 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 39
4.3.4. Time . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 39
4.3.5. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 39 4.3.4. Time . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3.6. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 39 4.3.5. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 40
4.3.7. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 39 4.3.6. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 40
4.3.8. CountryCode . . . . . . . . . . . . . . . . . . . . . 40 4.3.7. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 41
5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 40 4.3.8. CountryCode . . . . . . . . . . . . . . . . . . . . . 41
6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 40 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 41
6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 41 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 42
6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 42 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 42
6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 43 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 43
6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 43 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 44
6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 44 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 44
6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 45 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 45
6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 45 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 46
6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 46 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 46
6.9. Media Types . . . . . . . . . . . . . . . . . . . . . . . 46 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 47
6.10. Complete CDNI Metadata Example . . . . . . . . . . . . . 47 6.9. Media Types . . . . . . . . . . . . . . . . . . . . . . . 48
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51 6.10. Complete CDNI Metadata Example . . . . . . . . . . . . . 48
7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 51 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1.1. CDNI MI HostIndex Payload Type . . . . . . . . . . . 52 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 52
7.1.2. CDNI MI HostMatch Payload Type . . . . . . . . . . . 52 7.1.1. CDNI MI HostIndex Payload Type . . . . . . . . . . . 53
7.1.3. CDNI MI HostMetadata Payload Type . . . . . . . . . . 53 7.1.2. CDNI MI HostMatch Payload Type . . . . . . . . . . . 53
7.1.4. CDNI MI PathMatch Payload Type . . . . . . . . . . . 53 7.1.3. CDNI MI HostMetadata Payload Type . . . . . . . . . . 54
7.1.5. CDNI MI PatternMatch Payload Type . . . . . . . . . . 53 7.1.4. CDNI MI PathMatch Payload Type . . . . . . . . . . . 54
7.1.6. CDNI MI PathMetadata Payload Type . . . . . . . . . . 53 7.1.5. CDNI MI PatternMatch Payload Type . . . . . . . . . . 54
7.1.7. CDNI MI SourceMetadata Payload Type . . . . . . . . . 53 7.1.6. CDNI MI PathMetadata Payload Type . . . . . . . . . . 54
7.1.8. CDNI MI Source Payload Type . . . . . . . . . . . . . 54 7.1.7. CDNI MI SourceMetadata Payload Type . . . . . . . . . 54
7.1.9. CDNI MI LocationACL Payload Type . . . . . . . . . . 54 7.1.8. CDNI MI Source Payload Type . . . . . . . . . . . . . 55
7.1.10. CDNI MI LocationRule Payload Type . . . . . . . . . . 54 7.1.9. CDNI MI LocationACL Payload Type . . . . . . . . . . 55
7.1.11. CDNI MI Footprint Payload Type . . . . . . . . . . . 54 7.1.10. CDNI MI LocationRule Payload Type . . . . . . . . . . 55
7.1.12. CDNI MI TimeWindowACL Payload Type . . . . . . . . . 54 7.1.11. CDNI MI Footprint Payload Type . . . . . . . . . . . 55
7.1.13. CDNI MI TimeWindowRule Payload Type . . . . . . . . . 55 7.1.12. CDNI MI TimeWindowACL Payload Type . . . . . . . . . 55
7.1.14. CDNI MI TimeWindow Payload Type . . . . . . . . . . . 55 7.1.13. CDNI MI TimeWindowRule Payload Type . . . . . . . . . 56
7.1.15. CDNI MI ProtocolACL Payload Type . . . . . . . . . . 55 7.1.14. CDNI MI TimeWindow Payload Type . . . . . . . . . . . 56
7.1.16. CDNI MI ProtocolRule Payload Type . . . . . . . . . . 55 7.1.15. CDNI MI ProtocolACL Payload Type . . . . . . . . . . 56
7.1.17. CDNI MI DeliveryAuthorization Payload Type . . . . . 55 7.1.16. CDNI MI ProtocolRule Payload Type . . . . . . . . . . 56
7.1.18. CDNI MI Cache Payload Type . . . . . . . . . . . . . 56 7.1.17. CDNI MI DeliveryAuthorization Payload Type . . . . . 56
7.1.19. CDNI MI Auth Payload Type . . . . . . . . . . . . . . 56 7.1.18. CDNI MI Cache Payload Type . . . . . . . . . . . . . 57
7.1.20. CDNI MI Grouping Payload Type . . . . . . . . . . . . 56 7.1.19. CDNI MI Auth Payload Type . . . . . . . . . . . . . . 57
7.2. CDNI Metadata Footprint Types Registry . . . . . . . . . 56 7.1.20. CDNI MI Grouping Payload Type . . . . . . . . . . . . 57
7.3. CDNI Metadata Protocol Types Registry . . . . . . . . . . 57 7.2. CDNI Metadata Footprint Types Registry . . . . . . . . . 57
7.3. CDNI Metadata Protocol Types Registry . . . . . . . . . . 58
8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 8. Security Considerations . . . . . . . . . . . . . . . . . . . 58
8.1. Authentication and Integrity . . . . . . . . . . . . . . 58 8.1. Authentication and Integrity . . . . . . . . . . . . . . 59
8.2. Confidentiality and Privacy . . . . . . . . . . . . . . . 58 8.2. Confidentiality and Privacy . . . . . . . . . . . . . . . 59
8.3. Securing the CDNI Metadata interface . . . . . . . . . . 59 8.3. Securing the CDNI Metadata interface . . . . . . . . . . 60
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60
10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 59 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 60
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 60 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 61
11.1. Normative References . . . . . . . . . . . . . . . . . . 60 11.1. Normative References . . . . . . . . . . . . . . . . . . 61
11.2. Informative References . . . . . . . . . . . . . . . . . 62 11.2. Informative References . . . . . . . . . . . . . . . . . 63
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64
1. Introduction 1. Introduction
Content Delivery Networks Interconnection (CDNI) [RFC6707] enables a Content Delivery Networks Interconnection (CDNI) [RFC6707] enables a
downstream Content Delivery Network (dCDN) to service content downstream Content Delivery Network (dCDN) to service content
requests on behalf of an upstream CDN (uCDN). 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 can be used to compose a CDNI solution (CDNI other interfaces that can be used to compose a CDNI solution (CDNI
Control interface, CDNI Request Routing Redirection interface, CDNI Control interface, CDNI Request Routing Redirection interface, CDNI
skipping to change at page 16, line 21 skipping to change at page 16, line 21
from the content request when converted to lowercase MUST be from the content request when converted to lowercase MUST be
identical to the value of the host property when converted to identical to the value of the host property when converted to
lowercase. All implementations MUST support IPv4 addresses lowercase. All implementations MUST support IPv4 addresses
encoded as specified by the 'IPv4address' rule in Section 3.2.2 encoded as specified by the 'IPv4address' rule in Section 3.2.2
of [RFC3986]. IPv6 addresses MUST be encoded in one of the of [RFC3986]. IPv6 addresses MUST be encoded in one of the
IPv6 address formats specified in [RFC5952] although receivers IPv6 address formats specified in [RFC5952] although receivers
MUST support all IPv6 address formats specified in [RFC4291]. MUST support all IPv6 address formats specified in [RFC4291].
Hostnames MUST conform to the Domain Name System (DNS) syntax Hostnames MUST conform to the Domain Name System (DNS) syntax
defined in [RFC1034] and [RFC1123]. Internationalized Domain defined in [RFC1034] and [RFC1123]. Internationalized Domain
Names (IDN) must first be transformed to the IDNA encoding as Names (IDN) must first be transformed to the IDNA encoding as
per [RFC3490]. per [RFC5891].
Type: Endpoint Type: Endpoint
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
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.
skipping to change at page 18, line 30 skipping to change at page 18, line 30
"paths": [ "paths": [
{ {
<Properties of embedded PathMatch object> <Properties of embedded PathMatch object>
} }
] ]
} }
4.1.4. PathMatch 4.1.4. PathMatch
A PathMatch object contains PatternMatch object with a path to match A PathMatch object contains PatternMatch object with a path to match
against a resource's URI path, as well as a PathMetadata object with against a resource's URI path, as well as how to handle URI query
GenericMetadata to apply if the resource's URI path matches the parameters. The PathMatch also contains a PathMetadata object with
pattern within the PatternMatch object. GenericMetadata to apply if the resource's URI matches the pattern
within the PatternMatch object.
Property: path-pattern Property: path-pattern
Description: Pattern to match against the requested resource's Description: Pattern to match against the requested resource's
URI path, i.e., against the [RFC3986] path-absolute. URI.
Type: PatternMatch Type: PatternMatch
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: path-metadata Property: path-metadata
Description: CDNI metadata to apply when delivering content Description: CDNI metadata to apply when delivering content
that matches the associated PatternMatch. that matches the associated PatternMatch.
skipping to change at page 19, line 27 skipping to change at page 19, line 27
} }
} }
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 pattern expression. describe the pattern expression.
Property: pattern Property: pattern
Description: A pattern for string matching. The pattern can Description: A pattern for matching against the URI path, i.e.,
contain the wildcards * and ?, where * matches any sequence of against the [RFC3986] path-absolute. The pattern can contain
characters (including the empty string) and ? matches exactly the wildcards * and ?, where * matches any sequence of
one character. The three literals $, * and ? should be escaped [RFC3986] pchar or "/" characters (including the empty string)
as $$, $* and $? (where $ is the designated escape character). and ? matches exactly one [RFC3986] pchar character. The three
All other characters are treated as literals. literals $, * and ? MUST be escaped as $$, $* and $? (where $
is the designated escape character). All other characters are
treated as literals.
Type: String Type: String
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: case-sensitive Property: case-sensitive
Description: Flag indicating whether or not case-sensitive Description: Flag indicating whether or not case-sensitive
matching should be used. Note: Case-insensitivity applies to matching should be used. Note: Case-insensitivity applies to
ALPHA characters in the URI path prior to percent-decoding ALPHA characters in the URI path prior to percent-decoding
[RFC3986]. [RFC3986].
Type: Boolean Type: Boolean
Mandatory-to-Specify: No. Default is case-insensitive match. Mandatory-to-Specify: No. Default is case-insensitive match.
Property: ignore-query-string
Description: Array of query parameters which should be ignored
when searching for a pattern match. Matching against query
parameters to ignore MUST be case-insensitive. If all query
parameters should be ignored then the list MUST be empty.
Type: Array of String
Mandatory-to-Specify: No. Default is to include query strings
when matching.
Example PatternMatch object that matches the case-sensitive URI path Example PatternMatch object that matches the case-sensitive URI path
pattern "/movies/*". All query parameters will be ignored when pattern "/movies/*". All query parameters will be ignored when
matching URIs requested from surrogates by content clients against matching URIs requested from surrogates by content clients against
this path pattern: this path pattern:
{ {
"pattern": "/movies/*", "pattern": "/movies/*",
"case-sensitive": true, "case-sensitive": true
"ignore-query-string": []
} }
Example PatternMatch object that matches the case-sensitive URI path Example PatternMatch object that matches the case-sensitive URI path
pattern "/movies/*". The query parameter "sessionid" will be ignored pattern "/movies/*". Only the query parameter "sessionid" will be
when matching URIs requested from surrogates by content clients evaluated when matching URIs requested from surrogates by content
against this path pattern: clients against this path pattern:
{ {
"pattern": "/movies/*", "pattern": "/movies/*",
"case-sensitive": true, "case-sensitive": true
"ignore-query-string": ["sessionid"]
} }
4.1.6. PathMetadata 4.1.6. PathMetadata
A PathMetadata object contains the CDNI metadata properties for A PathMetadata object contains the CDNI metadata properties for
content requests that match against the associated URI path (defined content requests that match against the associated URI path (defined
in a PathMatch object). in a PathMatch object).
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 evaluate any metadata at the PathMetadata level or below unable to evaluate any metadata at the PathMetadata level or below
skipping to change at page 34, line 26 skipping to change at page 34, line 26
} }
] ]
} }
} }
4.2.6. Cache 4.2.6. Cache
A Cache object describes the cache control parameters to be applied A Cache object describes the cache control parameters to be applied
to the content by intermediate caches. to the content by intermediate caches.
Property: ignore-query-string Cache keys are generated from the URI of the content request
[RFC7234]. In some cases, a CDN or content provider might want
certain path segments or query parameters to be excluded from the
cache key generation. The Cache object provides guidance on what
parts of the path and query string to include.
Description: Allows a Surrogate to ignore URI query string Property: exclude-path-pattern
parameters [RFC3986] when comparing the requested URI against
the URIs in its cache for equivalence. Matching query Description: A pattern for matching against the URI path, i.e.,
parameters to ignore MUST be case-insensitive. Each query against the [RFC3986] path-absolute. The pattern can contain
parameter to ignore is specified in the list. If all query the wildcards * and ?, where * matches any sequence of
[RFC3986] pchar or "/" characters (including the empty string)
and ? matches exactly one [RFC3986] pchar character. The three
literals $, * and ? MUST be escaped as $$, $* and $? (where $
is the designated escape character). All other characters are
treated as literals. Cache key generation MUST only include
the portion of the path-absolute that matches the wildcard
portions of the pattern. Note: Inconsistency between the
PatternMatch pattern Section 4.1.5 and the exclude-path-pattern
can result in inefficient caching.
Type: String
Mandatory-to-Specify: No. Default is to use the full URI path-
absolute to generate the cache key.
Property: include-query-strings
Description: Allows a Surrogate to specify the URI query string
parameters [RFC3986] to include when comparing the requested
URI against the URIs in its cache for equivalence. Matching
query parameters MUST be case-insensitive. If all query
parameters should be ignored, then the list MUST be specified parameters should be ignored, then the list MUST be specified
and MUST be empty. and MUST be empty. If a query parameter appears multiple times
in the query string, each instance value MUST be aggregated
prior to comparison. For consistent cache key generation,
query parameters SHOULD be evaluated in the order specified in
this array.
Type: Array of String Type: Array of String
Mandatory-to-Specify: No. Default is to consider query string Mandatory-to-Specify: No. Default is to consider all query
parameters when comparing URIs. string parameters when comparing URIs.
Example Cache object that instructs the dCDN to ignore all query Example Cache object that instructs the dCDN to use the full URI path
parameters: and ignore all query parameters:
{ {
"generic-metadata-type": "MI.Cache", "generic-metadata-type": "MI.Cache",
"generic-metadata-value": "generic-metadata-value":
{ {
"ignore-query-string": [] "include-query-strings": []
} }
} }
Example Cache object that instructs the dCDN to ignore the (case-
insensitive) query parameters named "sessionid" and "random": Example Cache object that instructs the dCDN to exclude the "CDNX"
path prefix and only include the (case-insensitive) query parameters
named "mediaid" and "providerid":
{ {
"generic-metadata-type": "MI.Cache", "generic-metadata-type": "MI.Cache",
"generic-metadata-value": "generic-metadata-value":
{ {
"ignore-query-string": ["sessionid", "random"] "exclude-path-pattern": "/CDNX/*",
"include-query-strings": ["mediaid", "providerid"]
}
}
Example Cache object that instructs the dCDN to exclude the "CDNX"
path prefix, but includes all query parameters:
{
"generic-metadata-type": "MI.Cache",
"generic-metadata-value":
{
"exclude-path-pattern": "/CDNX/*"
} }
} }
4.2.7. Auth 4.2.7. Auth
An Auth object defines authentication and authorization methods to be An Auth object defines authentication and authorization methods to be
used during content acquisition and content delivery, respectively. used during content acquisition and content delivery, respectively.
Note: This document does not define any Auth methods. Individual Note: This document does not define any Auth methods. Individual
Auth methods are being defined separately (e.g., URI Signing Auth methods are being defined separately (e.g., URI Signing
skipping to change at page 37, line 25 skipping to change at page 38, line 25
Description: The URI of the addressable object being Description: The URI of the addressable object being
referenced. referenced.
Type: String Type: String
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: type Property: type
Description: The type of the object being referenced. Description: The CDNI Payload type of the object being
referenced.
Type: String Type: String
Mandatory-to-Specify: No. If the container specifies the type Mandatory-to-Specify: No. If the container specifies the type
(e.g., the HostIndex object contains an array of HostMatch (e.g., the HostIndex object contains an array of HostMatch
objects, so a Link object in the list of HostMatch objects must objects, so a Link object in the list of HostMatch objects must
reference a HostMatch), then it is not necessary to explicitly reference a HostMatch), then it is not necessary to explicitly
specify a type. specify a type.
Example Link object referencing a HostMatch object: Example Link object referencing a HostMatch object:
skipping to change at page 38, line 16 skipping to change at page 39, line 16
"hosts": [ "hosts": [
{ {
<Properties of embedded HostMatch object> <Properties of embedded HostMatch object>
}, },
{ {
"href": "https://metadata.ucdn.example/hostmatch1234" "href": "https://metadata.ucdn.example/hostmatch1234"
} }
] ]
} }
4.3.1.1. Link Loop Prevention
When following a Link, CDNI metadata clients SHOULD verify that the
CDNI Payload Type of the object retrieved matches the expected CDNI
Payload Type, as indicated by the link object. For GenericMetadata
objects, type checks will prevent self references; however, incorrect
linking can result in circular references for structural metadtata
objects, specifically, PathMatch and PathMetadata objects Figure 1.
To prevent the circular references, CDNI metadata clients SHOULD
verify that no duplicate Links occur for PathMatch or PathMetadata
objects.
4.3.2. Protocol 4.3.2. Protocol
Protocol objects are used to specify registered protocols for content Protocol objects are used to specify registered protocols for content
acquisition or delivery (see Section 7.3). acquisition or delivery (see Section 7.3).
Type: String Type: String
Example: Example:
"http/1.1" "http/1.1"
skipping to change at page 38, line 39 skipping to change at page 39, line 51
A Hostname (with optional port) or an IP address (with optional A Hostname (with optional port) or an IP address (with optional
port). port).
All implementations MUST support IPv4 addresses encoded as specified All implementations MUST support IPv4 addresses encoded as specified
by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. IPv6 by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. IPv6
addresses MUST be encoded in one of the IPv6 address formats addresses MUST be encoded in one of the IPv6 address formats
specified in [RFC5952] although receivers MUST support all IPv6 specified in [RFC5952] although receivers MUST support all IPv6
address formats specified in [RFC4291]. Hostnames MUST conform to address formats specified in [RFC4291]. Hostnames MUST conform to
the Domain Name System (DNS) syntax defined in [RFC1034] and the Domain Name System (DNS) syntax defined in [RFC1034] and
[RFC1123]. Internationalized Domain Names (IDN) must first be [RFC1123]. Internationalized Domain Names (IDN) must first be
transformed to the IDNA encoding as per [RFC3490]. transformed to the IDNA encoding as per [RFC5891].
Type: String Type: String
Example Hostname: Example Hostname:
"metadata.ucdn.example" "metadata.ucdn.example"
Example IPv4 address: Example IPv4 address:
"192.0.2.1" "192.0.2.1"
skipping to change at page 42, line 5 skipping to change at page 43, line 15
The HTTP Method in the request defines the operation the request The HTTP Method in the request defines the operation the request
would like to perform. A server implementation of the CDNI metadata would like to perform. A server implementation of the CDNI metadata
interface MUST support the HTTP GET and HEAD methods. interface MUST support the HTTP GET and HEAD methods.
The corresponding HTTP Response returns the status of the operation The corresponding HTTP Response returns the status of the operation
in the HTTP Status Code and returns the current representation of the in the HTTP Status Code and returns the current representation of the
resource (if appropriate) in the Response Body. HTTP Responses that resource (if appropriate) in the Response Body. HTTP Responses that
contain a response body SHOULD include an ETag to enable validation contain a response body SHOULD include an ETag to enable validation
of cached versions of returned resources. of cached versions of returned resources.
The CDNI metadata interface specified in this document is a read-only
interface. A server implementation of the CDNI metadata interface
MUST reject attempts by a CDNI metadata client to update the CDNI
metadata, including all requests with HTTP Method PUT, POST or
DELETE.
As the CDNI metadata interface builds on top of HTTP, CDNI metadata As the CDNI metadata interface builds on top of HTTP, CDNI metadata
server implementations MAY make use of any HTTP feature when server implementations MAY make use of any HTTP feature when
implementing the CDNI metadata interface, for example, a CDNI implementing the CDNI metadata interface, for example, a CDNI
metadata server MAY make use of HTTP's caching mechanisms to indicate metadata server MAY make use of HTTP's caching mechanisms to indicate
that the returned response/representation can be reused without re- that the returned response/representation can be reused without re-
contacting the CDNI metadata server. contacting 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 CDNI metadata In the general case, a CDNI metadata server makes CDNI metadata
skipping to change at page 46, line 22 skipping to change at page 47, line 22
properties in the JSON payload. The CDNI Payload Type uniquely properties in the JSON payload. The CDNI Payload Type uniquely
identifies the specification defining that object, including any identifies the specification defining that object, including any
relation to, conflicts with, or obsolescence of other metadata. relation to, conflicts with, or obsolescence of other metadata.
There is no explicit version mapping requirement, however, for ease There is no explicit version mapping requirement, however, for ease
of understanding, metadata creators SHOULD make new versions of of understanding, metadata creators SHOULD make new versions of
metadata easily visible via the CDNI Payload Type, e.g., by appending metadata easily visible via the CDNI Payload Type, e.g., by appending
a version string. Note: A version string is optional on the first a version string. Note: A version string is optional on the first
version, e.g., MI.HostIndex, but could be added for subsequent version, e.g., MI.HostIndex, but could be added for subsequent
versions, e.g., MI.HostIndex.v2, MI.HostIndex.v3, etc. versions, e.g., MI.HostIndex.v2, MI.HostIndex.v3, etc.
In some cases, structural metadata Section 4.1 may be included Except when referenced by a Link object, nested metadata objects
without explicit type designation. [Ed. Note: There are a couple (i.e., structural metadata below the HostIndex; Source objects;
options here: 1) require that all structural metadata is referenced Location, TimeWindow, and Protocol Rule objects; and Footprint and
via link, so that the link type is present, or 2) require that all TimeWindow objects) can be serialized into a JSON payload without
structural metadata be versioned together, so that one can always explicit CDNI Payload Type information. The type is inferred from
tell the version of an embedded structural object based on the the outer structural metadata, generic metadata, or auth object CDNI
version of the outer-most structural object, referenced in the Payload Type. To avoid ambiguity when revising nestable metadata
Content-Type.] objects, any outer metadata object(s) MUST be reversioned and
allocated new CDNI Payload Type(s) at the same time. For example,
the MI.HostIndex object defined in this document contains an array of
MI.HostMatch objects, which each in turn contains a MI.HostMetadata
object. If a new MI.HostMetadata.v2 object were required, the outer
MI.HostIndex and MI.HostMatch objects would need to be revised, e.g.,
to MI.HostIndex.v2 and MI.HostMatch.v2, respectively. Similarly, if
a new MI.TimeWindowRule.v2 object was required, the outer
MI.TimeWindowACL object would need to be revised, e.g., to
MI.TimeWindowACL.v2; the MI.TimeWindowRule.v2 object, though, could
still contain MI.TimeWindow objects, if so specified.
HTTP requests sent to a metadata server SHOULD include an Accept HTTP requests sent to a metadata server SHOULD include an Accept
header with the CDNI Payload Type of the expected object. Metadata header with the CDNI Payload Type of the expected object. Metadata
clients can specify multiple CDNI Payload Types in the Accept header, clients can specify multiple CDNI Payload Types in the Accept header,
for example, if a metadata client is capable of processing two for example, if a metadata client is capable of processing two
different versions of the same type of object (defined by different different versions of the same type of object (defined by different
CDNI Payload Types) it might decide to include both in the Accept CDNI Payload Types) it might decide to include both in the Accept
header. header.
6.9. Media Types 6.9. Media Types
skipping to change at page 61, line 5 skipping to change at page 62, line 5
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts -
Application and Support", STD 3, RFC 1123, Application and Support", STD 3, RFC 1123,
DOI 10.17487/RFC1123, October 1989, DOI 10.17487/RFC1123, October 1989,
<http://www.rfc-editor.org/info/rfc1123>. <http://www.rfc-editor.org/info/rfc1123>.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications (IDNA)",
RFC 3490, DOI 10.17487/RFC3490, March 2003,
<http://www.rfc-editor.org/info/rfc3490>.
[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, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, DOI 10.17487/RFC4291, February Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <http://www.rfc-editor.org/info/rfc4291>. 2006, <http://www.rfc-editor.org/info/rfc4291>.
[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,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC5891] Klensin, J., "Internationalized Domain Names in
Applications (IDNA): Protocol", RFC 5891,
DOI 10.17487/RFC5891, August 2010,
<http://www.rfc-editor.org/info/rfc5891>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<http://www.rfc-editor.org/info/rfc5952>. <http://www.rfc-editor.org/info/rfc5952>.
[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, DOI 10.17487/RFC6707, September Statement", RFC 6707, DOI 10.17487/RFC6707, September
2012, <http://www.rfc-editor.org/info/rfc6707>. 2012, <http://www.rfc-editor.org/info/rfc6707>.
skipping to change at page 62, line 15 skipping to change at page 63, line 15
11.2. Informative References 11.2. Informative References
[I-D.ietf-cdni-control-triggers] [I-D.ietf-cdni-control-triggers]
Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / Murray, R. and B. Niven-Jenkins, "CDNI Control Interface /
Triggers", draft-ietf-cdni-control-triggers-15 (work in Triggers", draft-ietf-cdni-control-triggers-15 (work in
progress), May 2016. progress), May 2016.
[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-18 (work in progress), April 2016. ietf-cdni-redirection-19 (work in progress), July 2016.
[I-D.ietf-cdni-uri-signing] [I-D.ietf-cdni-uri-signing]
Leung, K., Faucheur, F., Brandenburg, R., Downey, B., and Leung, K., Faucheur, F., Brandenburg, R., Downey, B., and
M. Fisher, "URI Signing for CDN Interconnection (CDNI)", M. Fisher, "URI Signing for CDN Interconnection (CDNI)",
draft-ietf-cdni-uri-signing-09 (work in progress), June draft-ietf-cdni-uri-signing-09 (work in progress), June
2016. 2016.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000, DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>. <http://www.rfc-editor.org/info/rfc2818>.
[RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet
Autonomous System (AS) Number Space", RFC 6793, Autonomous System (AS) Number Space", RFC 6793,
DOI 10.17487/RFC6793, December 2012, DOI 10.17487/RFC6793, December 2012,
<http://www.rfc-editor.org/info/rfc6793>. <http://www.rfc-editor.org/info/rfc6793>.
[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
RFC 7234, DOI 10.17487/RFC7234, June 2014,
<http://www.rfc-editor.org/info/rfc7234>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
August 2014, <http://www.rfc-editor.org/info/rfc7336>. August 2014, <http://www.rfc-editor.org/info/rfc7336>.
[RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution
Network Interconnection (CDNI) Requirements", RFC 7337, Network Interconnection (CDNI) Requirements", RFC 7337,
DOI 10.17487/RFC7337, August 2014, DOI 10.17487/RFC7337, August 2014,
<http://www.rfc-editor.org/info/rfc7337>. <http://www.rfc-editor.org/info/rfc7337>.
 End of changes. 33 change blocks. 
133 lines changed or deleted 186 lines changed or added

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