idnits 2.17.1 draft-ietf-cdni-metadata-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3111 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Object' is mentioned on line 346, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5861 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-13 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft R. Murray 4 Intended status: Standards Track Velocix (Alcatel-Lucent) 5 Expires: April 21, 2016 M. Caulfield 6 Cisco Systems 7 K. Ma 8 Ericsson 9 October 19, 2015 11 CDN Interconnection Metadata 12 draft-ietf-cdni-metadata-12 14 Abstract 16 The Content Delivery Networks Interconnection (CDNI) metadata 17 interface enables interconnected Content Delivery Networks (CDNs) to 18 exchange content distribution metadata in order to enable content 19 acquisition and delivery. The CDNI metadata associated with a piece 20 of content provides a downstream CDN with sufficient information for 21 the downstream CDN to service content requests on behalf of an 22 upstream CDN. This document describes both a base set of CDNI 23 metadata and the protocol for exchanging that metadata. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on April 21, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5 68 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 69 3. CDNI Metadata object model . . . . . . . . . . . . . . . . . 7 70 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, 71 PatternMatch and PathMetadata objects . . . . . . . . . . 8 72 3.2. Generic CDNI Metadata Objects . . . . . . . . . . . . . . 11 73 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 14 74 4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 15 75 4.1. Definitions of the CDNI structural metadata objects . . . 16 76 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 17 78 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 18 79 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 19 80 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 20 81 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 21 82 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 22 83 4.2. Definitions of the initial set of CDNI Generic Metadata 84 objects . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 24 86 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 25 87 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 26 88 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 28 89 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 28 90 4.2.3. TimeWindowACL . . . . . . . . . . . . . . . . . . . . 29 91 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 30 92 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 31 93 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 32 94 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 33 95 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 34 96 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 34 97 4.2.7. Auth . . . . . . . . . . . . . . . . . . . . . . . . 35 98 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 36 99 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 37 100 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 37 101 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 38 102 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 38 103 4.3.4. Time . . . . . . . . . . . . . . . . . . . . . . . . 38 104 4.3.5. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 39 105 4.3.6. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 39 106 4.3.7. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 39 107 4.3.8. CountryCode . . . . . . . . . . . . . . . . . . . . . 39 108 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 40 109 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 40 110 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 41 111 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 42 112 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 43 113 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 43 114 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 44 115 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 44 116 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 45 117 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 45 118 6.9. Media Types . . . . . . . . . . . . . . . . . . . . . . . 46 119 6.10. Complete CDNI Metadata Example . . . . . . . . . . . . . 47 120 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 121 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 50 122 7.1.1. CDNI MI HostIndex Payload Type . . . . . . . . . . . 51 123 7.1.2. CDNI MI HostMatch Payload Type . . . . . . . . . . . 51 124 7.1.3. CDNI MI HostMetadata Payload Type . . . . . . . . . . 52 125 7.1.4. CDNI MI PathMatch Payload Type . . . . . . . . . . . 52 126 7.1.5. CDNI MI PatternMatch Payload Type . . . . . . . . . . 52 127 7.1.6. CDNI MI PathMetadata Payload Type . . . . . . . . . . 52 128 7.1.7. CDNI MI SourceMetadata Payload Type . . . . . . . . . 52 129 7.1.8. CDNI MI Source Payload Type . . . . . . . . . . . . . 53 130 7.1.9. CDNI MI LocationACL Payload Type . . . . . . . . . . 53 131 7.1.10. CDNI MI LocationRule Payload Type . . . . . . . . . . 53 132 7.1.11. CDNI MI Footprint Payload Type . . . . . . . . . . . 53 133 7.1.12. CDNI MI TimeWindowACL Payload Type . . . . . . . . . 53 134 7.1.13. CDNI MI TimeWindowRule Payload Type . . . . . . . . . 54 135 7.1.14. CDNI MI TimeWindow Payload Type . . . . . . . . . . . 54 136 7.1.15. CDNI MI ProtocolACL Payload Type . . . . . . . . . . 54 137 7.1.16. CDNI MI ProtocolRule Payload Type . . . . . . . . . . 54 138 7.1.17. CDNI MI DeliveryAuthorization Payload Type . . . . . 54 139 7.1.18. CDNI MI Cache Payload Type . . . . . . . . . . . . . 55 140 7.1.19. CDNI MI Auth Payload Type . . . . . . . . . . . . . . 55 141 7.1.20. CDNI MI Grouping Payload Type . . . . . . . . . . . . 55 142 7.2. CDNI Metadata Footprint Types Registry . . . . . . . . . 55 143 7.3. CDNI Metadata Protocol Types Registry . . . . . . . . . . 56 144 7.4. CDNI Metadata Auth Types Registry . . . . . . . . . . . . 56 145 8. Security Considerations . . . . . . . . . . . . . . . . . . . 57 146 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 57 147 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 57 148 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 58 149 8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 58 150 8.5. Securing the CDNI Metadata interface . . . . . . . . . . 58 151 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 59 152 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 59 153 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 154 11.1. Normative References . . . . . . . . . . . . . . . . . . 59 155 11.2. Informative References . . . . . . . . . . . . . . . . . 60 156 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 158 1. Introduction 160 Content Delivery Networks Interconnection (CDNI) [RFC6707] enables a 161 downstream Content Delivery Network (dCDN) to service content 162 requests on behalf of an upstream CDN (uCDN). 164 The CDNI metadata interface is discussed in [RFC7336] along with four 165 other interfaces that may be used to compose a CDNI solution (CDNI 166 Control interface, CDNI Request Routing Redirection interface, CDNI 167 Footprint & Capabilities Advertisement interface and CDNI Logging 168 interface). [RFC7336] describes each interface, and the 169 relationships between them. The requirements for the CDNI metadata 170 interface are specified in [RFC7337]. 172 The CDNI metadata associated with a piece of content (or with a set 173 of content) provides a dCDN with sufficient information for servicing 174 content requests on behalf of an uCDN in accordance with the policies 175 defined by the uCDN. 177 This document focuses on the CDNI metadata interface which enables a 178 dCDN to obtain CDNI metadata from an uCDN so that the dCDN can 179 properly process and respond to: 181 o Redirection requests received over the CDNI Request Routing 182 Redirection interface [I-D.ietf-cdni-redirection]. 184 o Content requests received directly from User Agents. 186 Specifically, this document specifies: 188 o A data structure for mapping content requests and redirection 189 requests to CDNI metadata objects (Section 3 and Section 4.1). 191 o An initial set of CDNI Generic metadata objects (Section 4.2). 193 o A HTTP web service for the transfer of CDNI metadata (Section 6). 195 1.1. Terminology 197 This document reuses the terminology defined in [RFC6707]. 199 Additionally, the following terms are used throughout this document 200 and are defined as follows: 202 o Object - a collection of properties. 204 o Property - a key and value pair where the key is a property name 205 and the value is the property value or another object. 207 This document uses the phrase "[Object] A contains [Object] B" for 208 simplicity when a strictly accurate phrase would be "[Object] A 209 contains or references (via a Link object) [Object] B". 211 1.2. Supported Metadata Capabilities 213 Only the metadata for a small set of initial capabilities is 214 specified in this document. This set provides the minimum amount of 215 metadata for basic CDN interoperability while still meeting the 216 requirements set forth by [RFC7337]. 218 The following high-level functionality can be configured via the CDNI 219 metadata objects specified in Section 4: 221 o Acquisition Source: Metadata for allowing a dCDN to fetch content 222 from a uCDN. 224 o Delivery Access Control: Metadata for restricting (or permitting) 225 access to content based on any of the following factors: 227 * Location 229 * Time Window 231 * Delivery Protocol 233 o Delivery Authorization: Metadata for authorizing dCDN user agent 234 requests. 236 o Cache Control: Metadata for controlling cache behavior of the 237 dCDN. 239 The metadata encoding described by this document is extensible in 240 order to allow for future additions to this list. 242 The set of metadata specified in this document, covering the initial 243 capabilities above, is only able to support CDN interconnection for 244 the delivery of content by a dCDN using HTTPv1.1 [RFC7230] and for a 245 dCDN to be able to acquire content from a uCDN using either HTTPv1.1 246 or HTTPv1.1 over TLS [RFC2818]. 248 Supporting CDN interconnection for the delivery of content using 249 unencrypted HTTPv2.0 [RFC7540] (as well as for a dCDN to acquire 250 content using unencrypted HTTPv2.0 or HTTPv2.0 over TLS) requires the 251 registration of these protocol names in the CDNI Metadata Protocol 252 Registry. 254 Supporting CDN interconnection for the delivery of content using 255 HTTPv1.1 over TLS or HTTPv2.0 over TLS requires specifying additional 256 metadata objects to carry the properties required to establish a TLS 257 session, for example metadata to describe the certificate to use as 258 part of the TLS handshake. 260 2. Design Principles 262 The CDNI metadata interface was designed to achieve the following 263 objectives: 265 1. Cacheability of CDNI metadata objects. 267 2. Deterministic mapping from redirection requests and content 268 requests to CDNI metadata properties. 270 3. Support for DNS redirection as well as application-specific 271 redirection (for example HTTP redirection). 273 4. Minimal duplication of CDNI metadata. 275 5. Leveraging of existing protocols. 277 Cacheability improves the latency of acquiring metadata while 278 maintaining its freshness, and therefore improves the latency of 279 serving content requests and redirection requests, without 280 sacrificing accuracy. The CDNI metadata interface uses HTTP and its 281 existing caching mechanisms to achieve CDNI metadata cacheability. 283 Deterministic mappings from content to metadata properties eliminates 284 ambiguity and ensures that policies are applied consistently by all 285 dCDNs. 287 Support for both HTTP and DNS redirection ensures that the CDNI 288 metadata interface can be used for HTTP and DNS redirection and also 289 meets the same design principles for both HTTP and DNS based 290 redirection schemes. 292 Minimal duplication of CDNI metadata provides space efficiency on 293 storage in the CDNs, on caches in the network, and across the network 294 between CDNs. 296 Leveraging existing protocols avoids reinventing common mechanisms 297 such as data structure encoding (by leveraging I-JSON [RFC7493]) and 298 data transport (by leveraging HTTP [RFC7230]). 300 3. CDNI Metadata object model 302 The CDNI metadata object model describes a data structure for mapping 303 redirection requests and content requests to metadata properties. 304 Metadata properties describe how to acquire content from an uCDN, 305 authorize access to content, and deliver content from a dCDN. The 306 object model relies on the assumption that these metadata properties 307 may be aggregated based on the hostname of the content and 308 subsequently on the resource path (URI) of the content. The object 309 model associates a set of CDNI metadata properties with a Hostname to 310 form a default set of metadata properties for content delivered on 311 behalf of that Hostname. That default set of metadata properties can 312 be overridden by properties that apply to specific paths within a 313 URI. 315 Different Hostnames and URI paths will be associated with different 316 sets of CDNI metadata properties in order to describe the required 317 behaviour when a dCDN surrogate or request router is processing User 318 Agent requests for content at that Hostname or URI path. As a result 319 of this structure, significant commonality may exist between the CDNI 320 metadata properties specified for different Hostnames, different URI 321 paths within a Hostname and different URI paths on different 322 Hostnames. For example the definition of which User Agent IP 323 addresses should be treated as being grouped together into a single 324 network or geographic location is likely to be common for a number of 325 different Hostnames. Another example is that although a uCDN is 326 likely to have several different policies configured to express geo- 327 blocking rules, it is likely that a single geo-blocking policy would 328 be applied to multiple Hostnames delivered through the CDN. 330 In order to enable the CDNI metadata for a given Hostname or URI Path 331 to be decomposed into sets of CDNI metadata properties that can be 332 reused by multiple Hostnames and URI Paths, the CDNI metadata 333 interface specified in this document splits the CDNI metadata into a 334 number of objects. Efficiency is improved by enabling a single CDNI 335 metadata object (that is shared across Hostname and/or URI paths) to 336 be retrieved and stored by a dCDN once, even if it is referenced by 337 the CDNI metadata of multiple Hostnames or of multiple URI paths. 339 Important Note: Any CDNI metadata object A that contains another CDNI 340 metadata object B may, instead of including the second object B 341 embedded within object A, include a Link object that contains a URI 342 that can be dereferenced to retrieve the complete serialized 343 representation of the second metadata object B. The remainder of 344 this document uses the phrase "[Object] A contains [Object] B" for 345 simplicity when a strictly accurate phrase would be "[Object] A 346 contains or references (via a Link object) [Object] B". It is 347 generally a deployment choice for the uCDN implementation to decide 348 when and which CDNI metadata objects to embed and which to make 349 available as separate resources via Link objects. 351 Section 3.1 introduces a high level description of the HostIndex, 352 HostMatch, HostMetadata, PathMatch, PatternMatch and PathMetadata 353 objects and describes the relationships between those objects. 355 Section 3.2 introduces a high level description of the CDNI 356 GenericMetadata object which represents the level at which CDNI 357 metadata override occurs between HostMetadata and PathMetadata 358 objects. 360 Section 4 describes in detail the specific CDNI metadata objects and 361 properties specified by this document which can be contained within a 362 CDNI GenericMetadata object. 364 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch and 365 PathMetadata objects 367 The relationships between the HostIndex, HostMatch, HostMetadata, 368 PathMatch, PatternMatch and PathMetadata objects are described in 369 Figure 1. 371 +---------+ +---------+ +------------+ 372 |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ 373 +---------+ +---------+ +------+-----+ | 374 | | 375 (*) | 376 | V 377 --> Contains or References V ****************** 378 (1) One and only one +---------+ *Generic Metadata* 379 (*) Zero or more +--->|PathMatch| * Objects * 380 | +----+---++ ****************** 381 | | | ^ 382 (*) (1) (1) +------------+ | 383 | | +->|PatternMatch| | 384 | V +------------+ | 385 | +------------+ | 386 +--+PathMetadata+-------(*)------+ 387 +------------+ 389 Figure 1: Relationships between CDNI Metadata Objects (Diagram 390 Representation) 392 A HostIndex object (see Section 4.1.1) contains a list of HostMatch 393 objects (see Section 4.1.2) that contain Hostnames (and/or IP 394 addresses) for which content requests may be delegated to the dCDN. 395 The HostIndex is the starting point for accessing the uCDN CDNI 396 metadata data store. It enables the dCDN to deterministically 397 discover, on receipt of a User Agent request for content, which other 398 CDNI metadata objects it requires in order to deliver the requested 399 content. 401 The HostIndex links Hostnames (and/or IP addresses) to HostMetadata 402 objects (see Section 4.1.3) via HostMatch objects. A HostMatch 403 object defines a Hostname (or IP address) to match against a 404 requested host and contains a HostMetadata object. 406 HostMetadata objects contain the default CDNI metadata within 407 GenericMetadata objects (see Section 4.1.7) required to serve content 408 for that host. When looking up CDNI metadata, the dCDN looks up the 409 requested Hostname (or IP address) against the HostMatch entries in 410 the HostIndex, from there it can find HostMetadata which describes 411 the default properties for each host as well as PathMetadata objects 412 (see Section 4.1.6), via PathMatch objects (see Section 4.1.4), which 413 may override those properties for given URI paths within the host. 414 The CDNI metadata contained in HostMetadata objects is applied to 415 content requests for which there is not more specific metadata, i.e. 416 for content requests that do not match any of the PathMatch objects 417 contained by that HostMetadata object and its child PathMetadata 418 objects. 420 HostMetadata can also contain PathMatch objects. PathMatch objects 421 define patterns, contained inside PatternMatch objects (see 422 Section 4.1.5), to match against the requested URI path, and contain 423 PathMetadata objects which contain the GenericMetadata objects to be 424 applied when a content request matches against the defined URI path 425 pattern. PatternMatch objects contain the pattern strings and flags 426 that describe the URI path that a PathMatch applies to. 428 PathMetadata objects override the CDNI metadata in the HostMetadata 429 object or one or more parent PathMetadata objects with more specific 430 CDNI metadata that applies to content requests matching the URI 431 pattern defined in the PatternMatch object of that PathMatch object. 432 A PathMetadata object may also contain PathMatch objects in order to 433 recursively define more specific URI paths that require different 434 (e.g., more specific) CDNI metadata to this one. 436 A GenericMetadata object contains individual CDNI metadata objects 437 which define the specific policies and attributes needed to properly 438 deliver the associated content. For example, a GenericMetadata 439 object may describe the source from which a CDN may acquire a piece 440 of content. The GenericMetadata object is an atomic unit that may be 441 referenced by HostMetadata and/or PathMetadata objects. 443 For example, if "example.com" is a content provider, a HostMatch 444 object may include an entry for "example.com" with the URI of the 445 associated HostMetadata object. The HostMetadata object for 446 "example.com" describes the metadata properties which apply to 447 "example.com" and could contain PathMatches for "example.com/ 448 movies/*" and "example.com/music/*", which in turn reference 449 corresponding PathMetadata objects that contain the CDNI metadata 450 objects for those more specific URI paths. The PathMetadata object 451 for "example.com/movies/*" describes CDNI metadata which apply to 452 that URI path and could contain a PathMatch object for 453 "example.com/movies/hd/*" which would reference the corresponding 454 PathMetadata object for the "example.com/movies/hd/" path prefix. 456 The relationships in Figure 1 are also represented in tabular format 457 in Table 1 below. 459 +--------------+----------------------------------------------------+ 460 | Data Object | Objects it contains or references | 461 +--------------+----------------------------------------------------+ 462 | HostIndex | 0 or more HostMatch objects. | 463 | HostMatch | 1 HostMetadata object. | 464 | HostMetadata | 0 or more PathMatch objects. 0 or more | 465 | | GenericMetadata objects. | 466 | PathMatch | 1 PatternMatch object. 1 PathMetadata object. | 467 | PatternMatch | Does not contain or reference any other objects. | 468 | PathMetadata | 0 or more PathMatch objects. 0 or more | 469 | | GenericMetadata objects. | 470 +--------------+----------------------------------------------------+ 472 Table 1: Relationships between CDNI Metadata Objects 473 (Table Representation) 475 3.2. Generic CDNI Metadata Objects 477 The HostMetadata and PathMetadata objects contain other CDNI metadata 478 objects that contain properties which describe how User Agent 479 requests for content should be processed, for example where to 480 acquire the content from, authorization rules that should be applied, 481 geo-blocking restrictions and so on. Each such CDNI metadata object 482 is a specialization of a CDNI GenericMetadata object. The 483 GenericMetadata object abstracts the basic information required for 484 metadata override and metadata distribution, from the specifics of 485 any given property (e.g., property semantics, enforcement options, 486 etc.). 488 The GenericMetadata object defines the type of properties contained 489 within it as well as whether or not the properties are "mandatory-to- 490 enforce". If the dCDN does not understand or support the property 491 type and the property type is "mandatory-to-enforce", the dCDN MUST 492 NOT serve the content to the User Agent. If the dCDN does not 493 understand or support the property type and the property type is not 494 "mandatory-to-enforce", then that GenericMetadata object may be 495 safely ignored and the dCDN MUST process the content request in 496 accordance with the rest of the CDNI metadata. 498 Although a CDN MUST NOT serve content to a User Agent if a 499 "mandatory-to-enforce" property cannot be enforced, it may be "safe- 500 to-redistribute" that metadata to another CDN without modification. 501 For example, in the cascaded CDN case, a transit CDN (tCDN) may pass 502 through "mandatory-to-enforce" metadata to a dCDN. For metadata 503 which does not require customization or translation (i.e., metadata 504 that is "safe-to-redistribute"), the data representation received off 505 the wire MAY be stored and redistributed without being natively 506 understood or supported by the transit CDN. However, for metadata 507 which requires translation, transparent redistribution of the uCDN 508 metadata values might not be appropriate. Certain metadata may be 509 safely, though possibly not optimally, redistributed unmodified. For 510 example, source acquisition address may not be optimal if 511 transparently redistributed, but might still work. 513 Redistribution safety MUST be specified for each GenericMetadata. If 514 a CDN does not understand or support a given GenericMetadata property 515 type and the property type is not "safe-to-redistribute", before 516 redistributing the metadata, the CDN MUST set the "incomprehensible" 517 flag for the GenericMetadata object that it did not understand and 518 was marked as not "safe-to-redistribute". The "incomprehensible" 519 flag signals to a dCDN that the metadata was not properly transformed 520 by the transit CDN. A CDN MUST NOT attempt to use metadata that has 521 been marked as "incomprehensible" by a uCDN. 523 Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or 524 "safe-to-redistribute" when propagating metadata to a dCDN. Although 525 a transit CDN may set the value of "incomprehensible" to true, a 526 transit CDN MUST NOT change the value of "incomprehensible" from true 527 to false. 529 Table 2 describes the action to be taken by a transit CDN (tCDN) for 530 the different combinations of "mandatory-to-enforce" (MtE) and "safe- 531 to-redistribute" (StR) properties, when the tCDN either does or does 532 not understand the metadata in question: 534 +-------+-------+------------+--------------------------------------+ 535 | MtE | StR | Metadata | Action | 536 | | | Understood | | 537 | | | by tCDN | | 538 +-------+-------+------------+--------------------------------------+ 539 | False | True | True | Can serve and redistribute. | 540 | False | True | False | Can serve and redistribute. | 541 | False | False | False | Can serve. MUST set | 542 | | | | "incomprehensible" to True when | 543 | | | | redistributing. | 544 | False | False | True | Can serve. Can redistribute either | 545 | | | | by transforming not StR metadata (if | 546 | | | | the CDN knows how to do so safely), | 547 | | | | otherwise MUST set | 548 | | | | "incomprehensible" to True when | 549 | | | | redistributing. | 550 | True | True | True | Can serve and redistribute. | 551 | True | True | False | MUST NOT serve but can redistribute. | 552 | True | False | True | Can serve. Can redistribute either | 553 | | | | by transforming not StR metadata (if | 554 | | | | the CDN knows how to do so safely), | 555 | | | | otherwise MUST set | 556 | | | | "incomprehensible" to True when | 557 | | | | redistributing. | 558 | True | False | False | MUST NOT serve. MUST set | 559 | | | | "incomprehensible" to True when | 560 | | | | redistributing. | 561 +-------+-------+------------+--------------------------------------+ 563 Table 2: Action to be taken by a tCDN for the different combinations 564 of MtE and StR properties 566 Table 3 describes the action to be taken by a dCDN for the different 567 combinations of "mandatory-to-enforce" (MtE) and "incomprehensible" 568 (Incomp) properties, when the dCDN either does or does not understand 569 the metadata in question: 571 +-------+--------+--------------+-----------------------------------+ 572 | MtE | Incomp | Metadata | Action | 573 | | | Understood | | 574 | | | by dCDN | | 575 +-------+--------+--------------+-----------------------------------+ 576 | False | False | True | Can serve. | 577 | False | True | True | Can serve but MUST NOT | 578 | | | | interpret/apply any metadata | 579 | | | | marked incomprehensible. | 580 | False | False | False | Can serve. | 581 | False | True | False | Can serve but MUST NOT | 582 | | | | interpret/apply any metadata | 583 | | | | marked incomprehensible. | 584 | True | False | True | Can serve. | 585 | True | True | True | MUST NOT serve. | 586 | True | False | False | MUST NOT serve. | 587 | True | True | False | MUST NOT serve. | 588 +-------+--------+--------------+-----------------------------------+ 590 Table 3: Action to be taken by a dCDN for the different combinations 591 of MtE and Incomp properties 593 3.3. Metadata Inheritance and Override 595 In the metadata object model, a HostMetadata object may contain 596 multiple PathMetadata objects (via PathMatch objects). Each 597 PathMetadata object may in turn contain other PathMetadata objects. 598 HostMetadata and PathMetadata objects form an inheritance tree where 599 each node in the tree inherits or overrides the property values set 600 by its parent. 602 GenericMetadata objects of a given type override all GenericMetadata 603 objects of the same type previously defined by any parent object in 604 the tree. GenericMetadata objects of a given type previously defined 605 by a parent object in the tree are inherited when no object of the 606 same type is defined by the child object. For example, if 607 HostMetadata for the host "example.com" contains GenericMetadata 608 objects of type LocationACL and TimeWindowACL, while a PathMetadata 609 object which applies to "example.com/movies/*" defines an alternate 610 GenericMetadata object of type TimeWindowACL, then: 612 o the TimeWindowACL defined in the PathMetadata would override the 613 TimeWindowACL defined in the HostMetadata for all User Agent 614 requests for content under "example.com/movies/", and 616 o the LocationACL defined in the HostMetadata would be inherited for 617 all User Agent requests for content under "example.com/movies/". 619 A single HostMetadata or PathMetadata object MUST NOT contain 620 multiple GenericMetadata objects of the same type. If a list of 621 GenericMetadata contains objects of duplicate types, the receiver 622 MUST ignore all but the first object of each type. 624 4. CDNI Metadata objects 626 Section 4.1 provides the definitions of each metadata object type 627 introduced in Section 3. These metadata objects are described as 628 structural metadata objects as they provide the structure for the 629 inheritance tree and identify which specific GenericMetadata objects 630 apply to a given User Agent content request. 632 Section 4.2 provides the definitions for a base set of core metadata 633 objects which can be contained within a GenericMetadata object. 634 These metadata objects govern how User Agent requests for content are 635 handled. GenericMetadata objects can contain other GenericMetadata 636 sub-objects (i.e., GenericMetadata sub-objects contained within the 637 GenericMetadata object that refers to that GenericMetadata sub- 638 object). As with all CDNI metadata objects, the value of the 639 GenericMetadata sub-objects can be either a complete serialized 640 representation of the sub-object, or a Link object that contains a 641 URI that can be dereferenced to retrieve the complete serialized 642 representation of the property sub-object. 644 Section 6.5 discusses the ability to extend the base set of 645 GenericMetadata objects specified in this document with additional 646 standards based or vendor specific GenericMetadata objects that may 647 be defined in the future in separate documents. 649 dCDNs and tCDNs MUST support parsing of all CDNI metadata objects 650 specified in this document. A dCDN does not have to implement the 651 underlying functionality represented by the metadata object, though 652 that may restrict the content that a given dCDN can serve. uCDNs as 653 generators of CDNI metadata only need to support generating the CDNI 654 metadata that they need in order to express the policies and 655 treatment required by the content they are describing. 657 CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] 658 containing a dictionary of (key,value) pairs where the keys are the 659 property names and the values are the associated property values. 660 See Section 6.4 for more details of the specific encoding rules for 661 CDNI metadata objects. 663 Note: In the following sections, the term "mandatory-to-specify" is 664 used to convey which properties MUST be included for a given 665 structural or GenericMetadata object. When mandatory-to-specify is 666 specified as "Yes" by this document for an individual property, it 667 means that if the object containing that property is included in a 668 metadata response, then the mandatory-to-specify property MUST also 669 be included (directly or by reference) in the response, e.g., a 670 HostMatch property object without a host to match against does not 671 make sense, therefore, the host property is mandatory-to-specify 672 inside a HostMatch object. 674 4.1. Definitions of the CDNI structural metadata objects 676 Each of the sub-sections below describe the structural objects 677 introduced in Section 3.1. 679 4.1.1. HostIndex 681 The HostIndex object is the entry point into the CDNI metadata 682 hierarchy. It contains a list of HostMatch objects. An incoming 683 content request is checked against the Hostname (or IP address) 684 specified by each of the listed HostMatch objects to find the 685 HostMatch object which applies to the request. 687 Property: hosts 689 Description: List of HostMatch objects. Hosts (HostMatch 690 objects) MUST be evaluated in the order they appear and the 691 first HostMatch object that matches the content request being 692 processed MUST be used. 694 Type: List of HostMatch objects 696 Mandatory-to-Specify: Yes. 698 Example HostIndex object containing two HostMatch objects, where the 699 first HostMatch object is embedded and the second HostMatch object is 700 referenced: 702 { 703 "hosts": [ 704 { 705 706 }, 707 { 708 "type": "MI.HostMatch.v1", 709 "href": "http://metadata.ucdn.example/hostmatch1234" 710 } 711 ] 712 } 714 4.1.2. HostMatch 716 The HostMatch object contains a Hostname or IP address to match 717 against content requests. The HostMatch object also contains a 718 HostMetadata object to apply if a match is found. 720 Property: host 722 Description: String (Hostname or IP address) to match against 723 the requested host. In order for a Hostname or IP address in a 724 content request to match the Hostname or IP address in the host 725 property the value when converted to lowercase in the content 726 request MUST be identical to the value of the host property 727 when converted to lowercase. IPv4 addresses MUST be encoded as 728 specified by the 'IPv4address' rule in Section 3.2.2 of 729 [RFC3986]. IPv6 addresses MUST be encoded in one of the IPv6 730 address formats specified in [RFC5952] although receivers MUST 731 support all IPv6 address formats specified in [RFC4291]. 733 Type: String 735 Mandatory-to-Specify: Yes. 737 Property: host-metadata 739 Description: CDNI metadata to apply when delivering content 740 that matches this host. 742 Type: HostMetadata 744 Mandatory-to-Specify: Yes. 746 Example HostMatch object with an embedded HostMetadata object: 748 { 749 "host": "video.example.com", 750 "host-metadata" : { 751 752 } 753 } 755 Example HostMatch object referencing (via a Link object, see 756 Section 4.3.1) a HostMetadata object: 758 { 759 "host": "video.example.com", 760 "host-metadata" : { 761 "type": "MI.HostMetadata.v1", 762 "href": "http://metadata.ucdn.example/host1234" 763 } 764 } 766 4.1.3. HostMetadata 768 A HostMetadata object contains the CDNI metadata properties for 769 content served for a particular host (defined in the HostMatch 770 object) and possibly child PathMatch objects. 772 Property: metadata 774 Description: List of host related metadata. 776 Type: List of GenericMetadata objects 778 Mandatory-to-Specify: Yes. 780 Property: paths 782 Description: Path specific rules. Path patterns (PathMatch 783 objects) MUST be evaluated in the order they appear and the 784 first PathMatch object that matches the content request being 785 processed MUST be used. 787 Type: List of PathMatch objects 789 Mandatory-to-Specify: No. 791 Example HostMetadata object containing a number of embedded 792 GenericMetadata objects that will describe the default metadata for 793 the host and a single embedded PathMatch object that will describe 794 the CDNI metadata for that path which overrides the default metadata 795 for the host: 797 { 798 "metadata": [ 799 { 800 801 }, 802 { 803 804 }, 806 ... 808 { 809 810 } 811 ], 812 "paths": [ 813 { 814 815 } 816 ] 817 } 819 4.1.4. PathMatch 821 A PathMatch object contains a pattern within a PatternMatch object to 822 match against a resource's URI path and contains a PathMetadata 823 object to apply if the resource's URI path matches the pattern within 824 the PatternMatch object. 826 Property: path-pattern 828 Description: Pattern to match against the requested resource's 829 URI path, i.e., against the [RFC3986] path-absolute. 831 Type: PatternMatch 833 Mandatory-to-Specify: Yes. 835 Property: path-metadata 837 Description: CDNI metadata to apply when delivering content 838 that matches the associated PatternMatch. 840 Type: PathMetadata 842 Mandatory-to-Specify: Yes. 844 Example PathMatch object referencing the PathMetadata object to use 845 for URIs that match the case-sensitive URI path pattern "/movies/*" 846 (contained within an embedded PatternMatch object): 848 { 849 "path-pattern": { 850 "pattern": "/movies/*", 851 "case-sensitive": true 852 }, 853 "path-metadata": { 854 "type": "MI.PathMetadata.v1", 855 "href": "http://metadata.ucdn.example/host1234/pathDCE" 856 } 857 } 859 4.1.5. PatternMatch 861 A PatternMatch object contains the pattern string and flags that 862 describe the PathMatch expression. 864 Property: pattern 866 Description: A pattern for string matching. The pattern may 867 contain the wildcards * and ?, where * matches any sequence of 868 characters (including the empty string) and ? matches exactly 869 one character. The three literals $, * and ? should be escaped 870 as $$, $* and $?. All other characters are treated as literals. 872 Type: String 874 Mandatory-to-Specify: Yes. 876 Property: case-sensitive 878 Description: Flag indicating whether or not case-sensitive 879 matching should be used. 881 Type: Boolean 883 Mandatory-to-Specify: No. Default is case-insensitive match. 885 Property: ignore-query-string 887 Description: List of query parameters which should be ignored 888 when searching for a pattern match. Matching against query 889 parameters to ignore MUST be case-insensitive. If all query 890 parameters should be ignored then the list MUST be empty. 892 Type: List of String 894 Mandatory-to-Specify: No. Default is to include query strings 895 when matching. 897 Example PatternMatch object that matches the case-sensitive URI path 898 pattern "/movies/*". All query parameters will be ignored when 899 matching URIs requested from surrogates by content clients against 900 this path pattern: 902 { 903 "pattern": "/movies/*", 904 "case-sensitive": true, 905 "ignore-query-string": [] 906 } 908 Example PatternMatch object that matches the case-sensitive URI path 909 pattern "/movies/*". The query parameter "sessionid" will be ignored 910 when matching URIs requested from surrogates by content clients 911 against this path pattern: 913 { 914 "pattern": "/movies/*", 915 "case-sensitive": true, 916 "ignore-query-string": ["sessionid"] 917 } 919 4.1.6. PathMetadata 921 A PathMetadata object contains the CDNI metadata properties for 922 content requests that match against the associated URI path (defined 923 in a PathMatch object) and possibly child PathMatch objects. 925 Note that if DNS-based redirection is employed, then a dCDN will be 926 unable to evaulate any metadata at the PathMetadata level or below 927 against the content redirection request at request routing time 928 because only the hostname of the content request is available at 929 request routing time. dCDNs SHOULD still process any metadata at the 930 PathMetadata level or below before responding to the redirection 931 request in order to detect if any unsupported metadata is specifed. 932 If any metadata is included and marked as "mandatory-to-enforce" 933 which is not supported by the dCDN then the dCDN SHOULD NOT redirect 934 the the content redirection request to itself in order to avoid 935 receiving content requests that it is not able to satisfy/serve. 937 Property: metadata 939 Description: List of path related metadata. 941 Type: List of GenericMetadata objects 943 Mandatory-to-Specify: Yes. 945 Property: paths 947 Description: Path specific rules. First match applies. 949 Type: List of PathMatch objects 951 Mandatory-to-Specify: No. 953 Example PathMetadata object containing a number of embedded 954 GenericMetadata objects that describe the metadata to apply for the 955 URI path defined in the parent PathMatch object. 957 { 958 "metadata": [ 959 { 960 961 }, 962 { 963 964 }, 966 ... 968 { 969 970 } 971 ], 972 } 974 4.1.7. GenericMetadata 976 A GenericMetadata object is a wrapper for managing individual CDNI 977 metadata properties in an opaque manner. 979 Property: generic-metadata-type 981 Description: Case-insensitive CDNI metadata object type. 983 Type: String containing the CDNI Payload Type of the object 984 contained in the generic-metadata-value property. 986 Mandatory-to-Specify: Yes. 988 Property: generic-metadata-value 989 Description: CDNI metadata object. 991 Type: Format/Type is defined by the value of generic-metadata- 992 type property above. 994 Mandatory-to-Specify: Yes. 996 Property: mandatory-to-enforce 998 Description: Flag identifying whether or not the enforcement of 999 the property metadata is required. 1001 Type: Boolean 1003 Mandatory-to-Specify: No. Default is to treat metadata as 1004 mandatory to enforce (i.e., a value of True). 1006 Property: safe-to-redistribute 1008 Description: Flag identifying whether or not the property 1009 metadata may be safely redistributed without modification. 1011 Type: Boolean 1013 Mandatory-to-Specify: No. Default is allow transparent 1014 redistribution (i.e., a value of True). 1016 Property: incomprehensible 1018 Description: Flag identifying whether or not any CDN in the 1019 chain of delegation has failed to understand and/or failed to 1020 properly transform this metadata object. Note: This flag only 1021 applies to metadata objects whose safe-to-redistribute property 1022 has a value of False. 1024 Type: Boolean 1026 Mandatory-to-Specify: No. Default is comprehensible (i.e., a 1027 value of False). 1029 Example GenericMetadata object containing a metadata object that 1030 applies to the applicable URI path and/or host (within a parent 1031 PathMetadata and/or HostMetadata object): 1033 { 1034 "mandatory-to-enforce": true, 1035 "safe-to-redistribute": true, 1036 "incomprehensible": false, 1037 "generic-metadata-type": , 1038 "generic-metadata-value": 1039 { 1040 1041 } 1042 } 1044 4.2. Definitions of the initial set of CDNI Generic Metadata objects 1046 The objects defined below are intended to be used in the 1047 GenericMetadata object generic-metadata-value field as defined in 1048 Section 4.1.7 and their generic-metadata-type property MUST be set to 1049 the appropriate CDNI Payload Type as defined in Table 4. 1051 4.2.1. SourceMetadata 1053 Source metadata provides the dCDN with information about content 1054 acquisition, i.e., how to contact an uCDN Surrogate or an Origin 1055 Server to obtain the content to be served. The sources are not 1056 necessarily the actual Origin Servers operated by the CSP but might 1057 be a set of Surrogates in the uCDN. 1059 Property: sources 1061 Description: Sources from which the dCDN can acquire content, 1062 listed in order of preference. 1064 Type: List of Source objects (see Section 4.2.1.1) 1066 Mandatory-to-Specify: No. Default is to use static 1067 configuration, out-of-band from the metadata interface. 1069 Example SourceMetadata object (which contains two Source objects) 1070 that describes which servers the dCDN should use for acquiring 1071 content for the applicable URI path and/or host: 1073 { 1074 "generic-metadata-type": "MI.SourceMetadata.v1" 1075 "generic-metadata-value": 1076 { 1077 "sources": [ 1078 { 1079 "endpoints": [ 1080 "a.service123.ucdn.example", 1081 "b.service123.ucdn.example" 1082 ], 1083 "protocol": "http1.1" 1084 }, 1085 { 1086 "endpoints": ["origin.service123.example"], 1087 "protocol": "http1.1" 1088 } 1089 ] 1090 } 1091 } 1093 4.2.1.1. Source 1095 A Source object describes the source to be used by the dCDN for 1096 content acquisition, e.g., a Surrogate within the uCDN or an 1097 alternate Origin Server, the protocol to be used and any 1098 authentication method to be used when contacting that source. 1100 Endpoints within a Source object MUST be treated as equivalent/equal 1101 so a uCDN can specify a list of sources in preference order and for 1102 each source/preference rank a uCDN can specify a list of endpoints 1103 that are equivalent, e.g., a pool of servers that are not behind a 1104 load balancer. 1106 Property: acquisition-auth 1108 Description: Authentication method to use when requesting 1109 content from this source. 1111 Type: Auth (see Section 4.2.7) 1113 Mandatory-to-Specify: No. Default is no authentication 1114 required. 1116 Property: endpoints 1118 Description: Origins from which the dCDN can acquire content. 1119 If multiple endpoints are specified they are all equal, i.e., 1120 the list is not in preference order, for example a pool of 1121 servers behind a load balancer. 1123 Type: List of Endpoint objects (See Section 4.3.3) 1125 Mandatory-to-Specify: Yes. 1127 Property: protocol 1129 Description: Network retrieval protocol to use when requesting 1130 content from this source. 1132 Type: Protocol (see Section 4.3.2) 1134 Mandatory-to-Specify: Yes. 1136 Example Source object that describes a pair of endpoints (servers) 1137 the dCDN can use for acquiring content for the applicable host and/or 1138 URI path: 1140 { 1141 "endpoints": [ 1142 "a.service123.ucdn.example", 1143 "b.service123.ucdn.example" 1144 ], 1145 "protocol": "http1.1" 1146 } 1148 4.2.2. LocationACL Metadata 1150 LocationACL metadata defines which locations a User Agent needs to be 1151 in, in order to be able to receive the associated content. 1153 A LocationACL which does not include a locations property results in 1154 an action of allow, meaning that delivery can be performed regardless 1155 of the User Agent's location. The action from the first footprint to 1156 match against the User Agent's location is the action a CDN MUST 1157 take. If two or more footprints overlap, the first footprint that 1158 matches against the User Agent's location determines the action a CDN 1159 MUST take. If the locations property is included but is empty, or if 1160 none of the listed footprints matches the User Agent's location, then 1161 the result is an action of deny. 1163 Although the LocationACL, TimeWindowACL (see Section 4.2.3), and 1164 ProtocolACL (see Section 4.2.4) are independent GenericMetadata 1165 objects, they may provide conflicting information to a dCDN, e.g., a 1166 content request which is simultaneously allowed based on the 1167 LocationACL and denied based on the TimeWindowACL. The dCDN MUST use 1168 the logical AND of all ACLs (where 'allow' is true and 'deny' is 1169 false) to determine whether or not a request should be allowed. 1171 Property: locations 1173 Description: Access control list which allows or denies 1174 (blocks) delivery based on the User Agent's location. 1176 Type: List of LocationRule objects (see Section 4.2.2.1) 1178 Mandatory-to-Specify: No. Default is allow all locations. 1180 Example LocationACL object that allows the dCDN to deliver content to 1181 any location/IP address: 1183 { 1184 "generic-metadata-type": "MI.LocationACL.v1" 1185 "generic-metadata-value": 1186 { 1187 } 1188 } 1190 Example LocationACL object (which contains a LocationRule object 1191 which itself contains a Footprint object) that only allows the dCDN 1192 to deliver content to User Agents in the USA: 1194 { 1195 "generic-metadata-type": "MI.LocationACL.v1" 1196 "generic-metadata-value": 1197 { 1198 "locations": [ 1199 { 1200 "action": "allow", 1201 "footprints": [ 1202 { 1203 "footprint-type": "countrycode", 1204 "footprint-value": ["us"] 1205 } 1206 ] 1207 } 1208 ] 1209 } 1210 } 1212 4.2.2.1. LocationRule 1214 A LocationRule contains or references a list of Footprint objects and 1215 the corresponding action. 1217 Property: footprints 1219 Description: List of footprints to which the rule applies. 1221 Type: List of Footprint objects (see Section 4.2.2.2) 1223 Mandatory-to-Specify: Yes. 1225 Property: action 1227 Description: Defines whether the rule specifies locations to 1228 allow or deny. 1230 Type: Enumeration [allow|deny] encoded as a lowercase string 1232 Mandatory-to-Specify: No. Default is deny. 1234 Example LocationRule object (which contains a Footprint object) that 1235 allows the dCDN to deliver content to clients in the USA: 1237 { 1238 "action": "allow", 1239 "footprints": [ 1240 { 1241 "footprint-type": "countrycode", 1242 "footprint-value": ["us"] 1243 } 1244 ] 1245 } 1246 } 1248 4.2.2.2. Footprint 1250 A Footprint object describes the footprint to which a LocationRule 1251 may be applied to, e.g., an IPv4 address range or a geographic 1252 location. 1254 Property: footprint-type 1256 Description: Registered footprint type. The footprint types 1257 specified by this document are: "ipv4cidr" (IPv4CIDR, see 1258 Section 4.3.5), "ipv6cidr" (IPv6CIDR, see Section 4.3.6), "asn" 1259 (Autonomous System Number, see Section 4.3.7) and "countrycode" 1260 (Country Code, see Section 4.3.8). 1262 Type: Lowercase String 1264 Mandatory-to-Specify: Yes. 1266 Property: footprint-value 1268 Description: List of footprint values conforming to the 1269 specification associated with the registered footprint type. 1270 Footprint values may be simple strings (e.g., IPv4CIDR, 1271 IPv5CIDR, ASN, and CountryCode), however, other Footprint 1272 objects may be defined in the future, along with a more complex 1273 encoding (e.g., GPS coordinate tuples). 1275 Type: List of footprints 1277 Mandatory-to-Specify: Yes. 1279 Example Footprint object describing a footprint covering the USA: 1281 { 1282 "footprint-type": "countrycode", 1283 "footprint-value": ["us"] 1284 } 1286 Example Footprint object describing a footprint covering the IP 1287 address ranges 192.0.2.0/24 and 198.51.100.0/24: 1289 { 1290 "footprint-type": "ipv4cidr", 1291 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 1292 } 1294 4.2.3. TimeWindowACL 1296 TimeWindowACL metadata defines time-based restrictions. 1298 A TimeWindowACL which does not include a times property results in an 1299 action of allow, meaning that delivery can be performed regardless of 1300 the time of the User Agent's request. The action from the first 1301 window to match against the current time is the action a CDN MUST 1302 take. If two or more windows overlap, the first window that matches 1303 against the current time determines the action a CDN MUST take. If 1304 the times property is included but is empty, or if none of the listed 1305 windows matches the current time, then the result is an action of 1306 deny. 1308 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1309 independent GenericMetadata objects, they may provide conflicting 1310 information to a dCDN, e.g., a content request which is 1311 simultaneously allowed based on the LocationACL and denied based on 1312 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1313 (where 'allow' is true and 'deny' is false) to determine whether or 1314 not a request should be allowed. 1316 Property: times 1318 Description: Access control list which allows or denies 1319 (blocks) delivery based on the time of a User Agent's request. 1321 Type: List of TimeWindowRule objects (see Section 4.2.3.1) 1323 Mandatory-to-Specify: No. Default is allow all time windows. 1325 Example TimeWIndowACL object (which contains a TimeWindowRule object 1326 which itself contains a TimeWIndow object) that only allows the dCDN 1327 to deliver content to clients between 09:00AM 01/01/2000 UTC and 1328 17:00AM 01/01/2000 UTC: 1330 { 1331 "generic-metadata-type": "MI.TimeWindowACL.v1" 1332 "generic-metadata-value": 1333 { 1334 "times": [ 1335 { 1336 "action": "allow", 1337 "windows": [ 1338 { 1339 "start": 946717200, 1340 "end": 946746000 1341 } 1342 ] 1343 } 1344 ] 1345 } 1346 } 1348 4.2.3.1. TimeWindowRule 1350 A TimeWindowRule contains or references a list of TimeWindow objects 1351 and the corresponding action. 1353 Property: windows 1355 Description: List of time windows to which the rule applies. 1357 Type: List of TimeWindow objects (see Section 4.2.3.2) 1359 Mandatory-to-Specify: Yes. 1361 Property: action 1363 Description: Defines whether the rule specifies time windows to 1364 allow or deny. 1366 Type: Enumeration [allow|deny] encoded as a lowercase string 1368 Mandatory-to-Specify: No. Default is deny. 1370 Example TimeWIndowRule object (which contains a TimeWIndow object) 1371 that only allows the dCDN to deliver content to clients between 1372 09:00AM 01/01/2000 UTC and 17:00AM 01/01/2000 UTC: 1374 { 1375 "action": "allow", 1376 "windows": [ 1377 { 1378 "start": 946717200, 1379 "end": 946746000 1380 } 1381 ] 1382 } 1384 4.2.3.2. TimeWindow 1386 A TimeWindow object describes a time range which may be applied by an 1387 TimeWindowACL, e.g., start 946717200 (i.e., 09:00AM 01/01/2000 UTC), 1388 end: 946746000 (i.e., 17:00AM 01/01/2000 UTC). 1390 Property: start 1392 Description: The start time of the window. 1394 Type: Time (see Section 4.3.4) 1396 Mandatory-to-Specify: Yes. 1398 Property: end 1400 Description: The end time of the window. 1402 Type: Time (see Section 4.3.4) 1404 Mandatory-to-Specify: Yes. 1406 Example TimeWIndow object that describes a time window from 09:00AM 1407 01/01/2000 UTC to 17:00AM 01/01/2000 UTC: 1409 { 1410 "start": 946717200, 1411 "end": 946746000 1412 } 1414 4.2.4. ProtocolACL Metadata 1416 ProtocolACL metadata defines delivery protocol restrictions. 1418 A ProtocolACL which does not include a protocol-acl property results 1419 in an action of allow, meaning that delivery can be performed 1420 regardless of the protocol of the User Agent's request. The action 1421 from the first protocol to match against the request protocol is the 1422 action a CDN MUST take. If two or more request protocols overlap, 1423 the first protocol that matches thre request protocol determines the 1424 action a CDN MUST take. If the protocol-acl property is included but 1425 is empty, or if none of the listed protocol matches the request 1426 protocol, then the result is an action of deny. 1428 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1429 independent GenericMetadata objects, they may provide conflicting 1430 information to a dCDN, e.g., a content request which is 1431 simultaneously allowed based on the ProtocolACL and denied based on 1432 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1433 (where 'allow' is true and 'deny' is false) to determine whether or 1434 not a request should be allowed. 1436 Property: protocol-acl 1438 Description: Description: Access control list which allows or 1439 denies (blocks) delivery based on delivery protocol. 1441 Type: List of ProtocolRule objects (see Section 4.2.4.1) 1443 Mandatory-to-Specify: No. Default is allow all protocols. 1445 Example ProtocolACL object (which contains a ProtocolRule object) 1446 that only allows the dCDN to deliver content using HTTP/1.1: 1448 { 1449 "generic-metadata-type": "MI.ProtocolACL.v1" 1450 "generic-metadata-value": 1451 { 1452 "protocol-acl": [ 1453 { 1454 "action": "allow", 1455 "protocols": ["http1.1"] 1456 } 1457 ] 1458 } 1459 } 1461 4.2.4.1. ProtocolRule 1463 A ProtocolRule contains or references a list of Protocol objects. 1464 ProtocolRule objects are used to construct a ProtocolACL to apply 1465 restrictions to content acquisition or delivery. 1467 Property: protocols 1469 Description: List of protocols to which the rule applies. 1471 Type: List of Protocols (see Section 4.3.2) 1473 Mandatory-to-Specify: Yes. 1475 Property: action 1477 Description: Defines whether the rule specifies protocols to 1478 allow or deny. 1480 Type: Enumeration [allow|deny] encoded as a lowercase string 1482 Mandatory-to-Specify: No. Default is deny. 1484 Example ProtocolRule object (which contains a ProtocolRule object) 1485 that includes the protocol HTTP/1.1: 1487 { 1488 "action": "allow", 1489 "protocols": ["http1.1"] 1490 } 1492 4.2.5. DeliveryAuthorization Metadata 1494 Delivery Authorization defines authorization methods for the delivery 1495 of content to User Agents. 1497 Property: delivery-auth-methods 1499 Description: Options for authorizing content requests. 1500 Delivery for a content request is authorized if any of the 1501 authorization methods in the list is satisfied for that 1502 request. 1504 Type: List of Auth objects (see Section 4.2.7) 1506 Mandatory-to-Specify: No. Default is no authorization 1507 required. 1509 Example DeliveryAuthorization object (which contains an Auth object): 1511 { 1512 "generic-metadata-type": "MI.DeliveryAuthorization.v1" 1513 "generic-metadata-value": 1514 { 1515 "delivery-auth-methods": [ 1516 { 1517 "auth-type": , 1518 "auth-value": 1519 { 1520 1521 } 1522 } 1523 ] 1524 } 1525 } 1527 4.2.6. Cache 1529 A Cache object describes the cache control parameters to be applied 1530 to the content by intermediate caches. 1532 Property: ignore-query-string 1534 Description: Allows a Surrogate to ignore URI query string 1535 parameters when comparing the requested URI against the URIs in 1536 its cache for equivalence. Matching against query parameters 1537 to ignore MUST be case-insensitive. Each query parameter to 1538 ignore is specified in the list. If all query parameters 1539 should be ignored, then the list MUST be specified and MUST be 1540 empty. 1542 Type: List of String 1544 Mandatory-to-Specify: No. Default is to consider query string 1545 parameters when comparing URIs. 1547 Example Cache object that instructs the dCDN to ignore all query 1548 parameters: 1550 { 1551 "generic-metadata-type": 1552 "MI.Cache.v1" 1553 "generic-metadata-value": 1554 { 1555 "ignore-query-string": [] 1556 } 1557 } 1559 Example Cache object that instructs the dCDN to ignore the (case- 1560 insensitive) query parameters named "sessionid" and "random": 1562 { 1563 "generic-metadata-type": 1564 "MI.Cache.v1" 1565 "generic-metadata-value": 1566 { 1567 "ignore-query-string": ["sessionid", "random"] 1568 } 1569 } 1571 4.2.7. Auth 1573 An Auth object defines authentication and authorization methods to be 1574 used during content acquisition and content delivery, respectively. 1576 Property: auth-type 1578 Description: Registered Auth type (Section 7.4). 1580 Type: String 1582 Mandatory-to-Specify: Yes. 1584 Property: auth-value 1585 Description: An object conforming to the specification 1586 associated with the Registered Auth type. 1588 Type: GenericMetadata Object 1590 Mandatory-to-Specify: Yes. 1592 Example Auth object: 1594 { 1595 "generic-metadata-type": 1596 "MI.Auth.v1" 1597 "generic-metadata-value": 1598 { 1599 "auth-type": , 1600 "auth-value": 1601 { 1602 1603 } 1604 } 1605 } 1607 4.2.8. Grouping 1609 A Grouping object identifies a large group of content to which a 1610 given asset belongs. 1612 Property: ccid 1614 Description: Content Collection identifier for an application- 1615 specific purpose such as logging. 1617 Type: String 1619 Mandatory-to-Specify: No. Default is an empty string. 1621 Example Grouping object that specifies a Content Collection 1622 Identifier for the content associated with the Grouping object's 1623 parent HostMetdata or PathMetadata: 1625 { 1626 "generic-metadata-type": 1627 "MI.Grouping.v1" 1628 "generic-metadata-value": 1629 { 1630 "ccid": "ABCD", 1631 } 1632 } 1634 4.3. CDNI Metadata Simple Data Type Descriptions 1636 This section describes the simple data types that are used for 1637 properties of CDNI metadata objects. 1639 4.3.1. Link 1641 A Link object may be used in place of any of the objects or 1642 properties described above. Link objects can be used to avoid 1643 duplication if the same metadata information is repeated within the 1644 metadata tree. When a Link object replaces another object, its href 1645 property is set to the URI of the resource and its type property is 1646 set to the CDNI Payload Type of the object it is replacing. 1648 dCDNs can detect the presence of a Link object instead of another 1649 metadata object by detecting the presence of a property named "href" 1650 within the object. This means that GenericMetadata types MUST NOT 1651 contain a property named "href" because doing so would conflict with 1652 the ability for dCDNs to detect Link objects being used to reference 1653 a GenericMetadata object. 1655 Property: href 1657 Description: The URI of the addressable object being 1658 referenced. 1660 Type: String 1662 Mandatory-to-Specify: Yes 1664 Property: type 1666 Description: The type of the object being referenced. 1668 Type: String 1670 Mandatory-to-Specify: No 1672 Example Link object referencing a HostMetadata object: 1674 { 1675 "type": "MI.HostMetadata.v1", 1676 "href": "http://metadata.ucdn.example/host1234" 1677 } 1679 4.3.2. Protocol 1681 Protocol objects are used to specify registered protocols for content 1682 acquisition or delivery (see Section 7.3). 1684 Type: String 1686 Example: 1688 "http1.1" 1690 4.3.3. Endpoint 1692 A Hostname (with optional port) or an IP address (with optional 1693 port). 1695 Note: All implementations MUST support IPv4 addresses encoded as 1696 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. 1697 IPv6 addresses MUST be encoded in one of the IPv6 address formats 1698 specified in [RFC5952] although receivers MUST support all IPv6 1699 address formats specified in [RFC4291]. 1701 Type: String 1703 Example Hostname: 1705 "http://metadata.ucdn.example/host1234" 1707 Example IPv4 address: 1709 "192.0.2.1" 1711 Example IPv6 address (with port number): 1713 "[2001:db8::1]:81" 1715 4.3.4. Time 1717 A time value expressed in seconds since Unix epoch in the UTC 1718 timezone. 1720 Type: Integer 1722 Example Time representing 09:00AM 01/01/2000 UTC: 1724 946717200 1726 4.3.5. IPv4CIDR 1728 An IPv4address CIDR block encoded as specified by the 'IPv4address' 1729 rule in Section 3.2.2 of [RFC3986] followed by a / followed by an 1730 unsigned integer representing the leading bits of the routing prefix 1731 (i.e. IPv4 CIDR notation). Single IP addresses can be expressed as 1732 /32. 1734 Type: String 1736 Example IPv4 CIDR: 1738 "192.0.2.0/24" 1740 4.3.6. IPv6CIDR 1742 An IPv6address CIDR block encoded in one of the IPv6 address formats 1743 specified in [RFC5952] followed by a / followed by an unsigned 1744 integer representing the leading bits of the routing prefix (i.e. 1745 IPv6 CIDR notation). Single IP addresses can be expressed as /128. 1747 Type: String 1749 Example IPv6 CIDR: 1751 "2001:db8::/32" 1753 4.3.7. ASN 1755 An Autonomous System Number encoded as a string consisting of the 1756 characters "as" (in lowercase) followed by the Autonomous System 1757 number. 1759 Type: String 1761 Example ASN: 1763 "as64496" 1765 4.3.8. CountryCode 1767 An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1769 Type: String 1771 Example Country Code representing the USA: 1773 "us" 1775 5. CDNI Metadata Capabilities 1777 CDNI metadata is used to convey information pertaining to content 1778 delivery from uCDN to dCDN. For optional metadata, it may be useful 1779 for the uCDN to know if the dCDN supports the underlying 1780 functionality described by the metadata, prior to delegating any 1781 content requests to the dCDN. If some metadata is "mandatory-to- 1782 enforce", and the dCDN does not support it, any delegated requests 1783 for content that requires that metadata will fail. The uCDN will 1784 likely want to avoid delegating those requests to that dCDN. 1785 Likewise, for any metadata which may be assigned optional values, it 1786 may be useful for the uCDN to know which values a dCDN supports, 1787 prior to delegating any content requests to that dCDN. If the 1788 optional value assigned to a given piece of content's metadata is not 1789 supported by the dCDN, any delegated requests for that content may 1790 fail, so again the uCDN is likely to want to avoid delegating those 1791 requests to that dCDN. 1793 The CDNI Footprint and Capabilities Interface (FCI) [RFC7336] 1794 provides a means of advertising capabilities from dCDN to uCDN. 1795 Support for optional metadata and support for optional metadata 1796 values may be advertised using the FCI. 1798 6. CDNI Metadata interface 1800 This section specifies an interface to enable a dCDN to retrieve CDNI 1801 metadata objects from a uCDN. 1803 The interface can be used by a dCDN to retrieve CDNI metadata objects 1804 either: 1806 o Dynamically as required by the dCDN to process received requests. 1807 For example in response to a query from an uCDN over the CDNI 1808 Request Routing Redirection interface (RI) 1809 [I-D.ietf-cdni-redirection] or in response to receiving a request 1810 for content from a User Agent. Or; 1812 o In advance of being required. For example in the case of pre- 1813 positioned CDNI metadata acquisition. 1815 The CDNI metadata interface is built on the principles of HTTP web 1816 services. In particular, this means that requests and responses over 1817 the interface are built around the transfer of representations of 1818 hyperlinked resources. A resource in the context of the CDNI 1819 metadata interface is any object in the object model (as described in 1820 Section 3 and Section 4). 1822 To retrieve CDNI metadata, a CDNI metadata client (i.e., a client in 1823 the dCDN) first makes a HTTP GET request for the URI of the HostIndex 1824 which provides the CDNI metadata client with a list of Hostnames for 1825 which the uCDN may delegate content delivery to the dCDN. The CDNI 1826 metadata client can then obtain any other CDNI metadata objects by 1827 making a HTTP GET requests for any linked metadata objects it 1828 requires. 1830 CDNI metadata servers (i.e., servers in the uCDN) are free to assign 1831 whatever structure they desire to the URIs for CDNI metadata objects 1832 and CDNI metadata clients MUST NOT make any assumptions regarding the 1833 structure of CDNI metadata URIs or the mapping between CDNI metadata 1834 objects and their associated URIs. Therefore any URIs present in the 1835 examples in this document are purely illustrative and are not 1836 intended to impose a definitive structure on CDNI metadata interface 1837 implementations. 1839 6.1. Transport 1841 The CDNI metadata interface uses HTTP as the underlying protocol 1842 transport. 1844 The HTTP Method in the request defines the operation the request 1845 would like to perform. A server implementation of the CDNI metadata 1846 interface MUST support the HTTP GET and HEAD methods. 1848 The corresponding HTTP Response returns the status of the operation 1849 in the HTTP Status Code and returns the current representation of the 1850 resource (if appropriate) in the Response Body. HTTP Responses from 1851 servers implementing the CDNI metadata interface that contain a 1852 response body SHOULD include an ETag to enable validation of cached 1853 versions of returned resources. 1855 The CDNI metadata interface specified in this document is a read-only 1856 interface. Therefore support for other HTTP methods such as PUT, 1857 POST and DELETE etc. is not specified. A server implementation of 1858 the CDNI metadata interface SHOULD reject all methods other than GET 1859 and HEAD. 1861 As the CDNI metadata interface builds on top of HTTP, CDNI metadata 1862 server implementations MAY make use of any HTTP feature when 1863 implementing the CDNI metadata interface, for example a CDNI metadata 1864 server MAY make use of HTTP's caching mechanisms to indicate that the 1865 returned response/representation can be reused without re-contacting 1866 the CDNI metadata server. 1868 6.2. Retrieval of CDNI Metadata resources 1870 In the general case a CDNI metadata server makes CDNI metadata 1871 objects available via a unique URIs and therefore in order to 1872 retrieve CDNI metadata, a CDNI metadata client first makes a HTTP GET 1873 request for the URI of the HostIndex which provides the CDNI metadata 1874 client with a list of Hostnames for which the uCDN may delegate 1875 content delivery to the dCDN. 1877 In order to retrieve the CDNI metadata for a particular request the 1878 CDNI metadata client processes the received HostIndex object and 1879 finds the corresponding HostMetadata entry (by matching the hostname 1880 in the request against the hostnames listed in the HostMatch 1881 objects). If the HostMetadata is linked (rather than embedded), the 1882 CDNI metadata client then makes a GET request for the URI specified 1883 in the href property of the Link object which points to the 1884 HostMetadata object itself. 1886 In order to retrieve the most specific metadata for a particular 1887 request, the CDNI metadata client inspects the HostMetadata for 1888 references to more specific PathMetadata objects (by matching the URI 1889 path in the request against the path-patterns in the PathMatch). If 1890 any PathMetadata match the request (and are linked rather than 1891 embedded), the CDNI metadata client makes another GET request for the 1892 PathMetadata. Each PathMetadata object may also include references 1893 to yet more specific metadata. If this is the case, the CDNI 1894 metadata client continues requesting PathMatch and PathMetadata 1895 objects recursively. The CDNI metadata client repeats this approach 1896 of processing metadata objects and retrieving (via HTTP GETs) any 1897 linked objects until it has all the metadata objects it requires in 1898 order to process a redirection request from an uCDN or a content 1899 request from a User Agent. 1901 In cases where a dCDN is not able to retrieve the entire set of CDNI 1902 metadata associated with a User Agent request, for example because 1903 the uCDN is uncontactable or returns an HTTP 4xx or 5xx status in 1904 response to some or all of the dCDN's CDNI metadata requests, the 1905 dCDN MUST NOT serve the requested content unless the dCDN has stale 1906 versions of all the required metadata and the stale-if-error Cache- 1907 Control extension [RFC5861] was included in all previous responses 1908 that are required but cannot currently be retrieved. The dCDN can 1909 continue to serve other content for which it can retrieve (or for 1910 which it has fresh responses cached) all the required metadata even 1911 if some non-applicable part of the metadata tree is missing. 1913 Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to 1914 determine which uCDN's CDNI metadata should be used to handle a 1915 particular User Agent request. 1917 When application level redirection (e.g., HTTP 302 redirects) is 1918 being used between CDNs, it is expected that the dCDN will be able to 1919 determine the uCDN that redirected a particular request from 1920 information contained in the received request (e.g., via the URI). 1921 With knowledge of which uCDN routed the request, the dCDN can choose 1922 the correct uCDN from which to obtain the HostIndex. Note that the 1923 HostIndex served by each uCDN may be unique. 1925 In the case of DNS redirection there is not always sufficient 1926 information carried in the DNS request from User Agents to determine 1927 the uCDN that redirected a particular request (e.g., when content 1928 from a given host is redirected to a given dCDN by more than one 1929 uCDN) and therefore dCDNs may have to apply local policy when 1930 deciding which uCDN's metadata to apply. 1932 6.3. Bootstrapping 1934 The URI for the HostIndex object of a given uCDN needs to be either 1935 configured in, or discovered by, the dCDN. All other objects/ 1936 resources are then discoverable from the HostIndex object by 1937 following any links in the HostIndex object and the referenced 1938 HostMetadata and PathMetadata objects and their GenericMetadata sub- 1939 objects. 1941 If the URI for the HostIndex object is not manually configured in the 1942 dCDN then the HostIndex URI could be discovered. A mechanism 1943 allowing the dCDN to discover the URI of the HostIndex is outside the 1944 scope of this document. 1946 6.4. Encoding 1948 CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] 1949 containing a dictionary of (key,value) pairs where the keys are the 1950 property names and the values are the associated property values. 1952 The keys of the dictionary are the names of the properties associated 1953 with the object and are therefore dependent on the specific object 1954 being encoded (i.e., dependent on the CDNI Payload Type of the 1955 returned resource). Likewise, the values associated with each 1956 property (dictionary key) are dependent on the specific object being 1957 encoded (i.e., dependent on the CDNI Payload Type of the returned 1958 resource). 1960 Dictionary keys (properties) in I-JSON are case sensitive. By 1961 convention any dictionary key (property) defined by this document 1962 (for example the names of CDNI metadata object properties) MUST be 1963 represented in lowercase. 1965 6.5. Extensibility 1967 The set of GenericMetadata objects may be extended with additional 1968 (standards based or vendor specific) metadata objects through the 1969 specification of new GenericMetadata objects. The GenericMetadata 1970 object defined in Section 4.1.7 specifies a type field and a type- 1971 specific value field that allows any metadata to be included in 1972 either the HostMetadata or PathMetadata lists. 1974 As with the initial GenericMetadata types defined in Section 4.2, 1975 future GenericMetadata types MUST specify the information necessary 1976 for constructing and decoding the GenericMetadata object. 1978 Any document which defines a new GenericMetadata type SHOULD: 1980 1. Specify the CDNI Payload Type used to identify the new 1981 GenericMetadata type being specified. 1983 2. Define the set of properties associated with the new type 1984 contained within the GenericMetadata object. GenericMetadata 1985 types MUST NOT contain a property named "href" because doing so 1986 would conflict with the ability for dCDNs to detect Link objects 1987 being used to reference a GenericMetadata object. 1989 3. For each property, define a name, description, type, and whether 1990 or not the property is mandatory-to-specify. 1992 4. Describe the semantics of the new type including its purpose and 1993 example of a use case to which it applies including an example 1994 encoded in I-JSON. 1996 Note: In the case of vendor specific extensions, identification 1997 within the type name defined for a GenericMetadata object, of the 1998 organization that defined the new GenericMetadata object decreases 1999 the possibility of GenericMetadata type collisions. 2001 6.6. Metadata Enforcement 2003 At any given time, the set of GenericMetadata types supported by the 2004 uCDN may not match the set of GenericMetadata types supported by the 2005 dCDN. 2007 In the cases where a uCDN sends metadata containing a GenericMetadata 2008 type that a dCDN does not support, the dCDN MUST enforce the 2009 semantics of the "mandatory-to-enforce" property. If a dCDN does not 2010 understand or is unable to perform the functions associated with any 2011 "mandatory-to-enforce" metadata, the dCDN MUST NOT service any 2012 requests for the corresponding content. 2014 Note: Ideally, uCDNs would not delegate content requests to a dCDN 2015 which does not support the "mandatory-to-enforce" metadata associated 2016 with the content being requested. However, even if the uCDN has a 2017 priori knowledge of the metadata supported by the dCDN (e.g., via the 2018 CDNI capabilities interface or through out-of-band negotiation 2019 between CDN operators) metadata support may fluctuate or be 2020 inconsistent (e.g., due to mis-communication, mis-configuration, or 2021 temporary outage). Thus, the dCDN MUST always evaluate all metadata 2022 associated with redirection requests and content requests and reject 2023 any requests where "mandatory-to-enforce" metadata associated with 2024 the content cannot be enforced. 2026 6.7. Metadata Conflicts 2028 It is possible that new metadata definitions may obsolete or conflict 2029 with existing GenericMetadata (e.g., a future revision of the CDNI 2030 metadata interface may redefine the Auth GenericMetadata object or a 2031 custom vendor extension may implement an alternate Auth metadata 2032 option). If multiple metadata (e.g., MI.Auth.v2, vendor1.Auth, and 2033 vendor2.Auth) all conflict with an existing GenericMetadata object 2034 (e.g., MI.Auth.v1) and all are marked as "mandatory-to-enforce", it 2035 may be ambiguous which metadata should be applied, especially if the 2036 functionality of the metadata overlap. 2038 As described in Section 3.3, metadata override only applies to 2039 metadata objects of the same exact type, found in HostMetadata and 2040 nested PathMetadata structures. The CDNI metadata interface does not 2041 support enforcement of dependencies between different metadata types. 2042 It is the responsibility of the CSP and the CDN operators to ensure 2043 that metadata assigned to a given content do not conflict. 2045 Note: Because metadata is inherently ordered in GenericMetadata 2046 lists, as well as in the PathMetadata hierarchy and PathMatch lists, 2047 multiple conflicting metadata types MAY be used, however, metadata 2048 hierarchies MUST ensure that independent PathMatch root objects are 2049 used to prevent ambiguous or conflicting metadata definitions. 2051 6.8. Versioning 2053 The version of CDNI metadata objects is conveyed inside the CDNI 2054 Payload Type that is included in the HTTP Content-Type header. Upon 2055 responding to a request for an object, a CDNI metadata server MUST 2056 include a Content-Type header with the CDNI Payload Type containing 2057 the version number of the object. HTTP requests sent to a metadata 2058 server SHOULD include an Accept header with the CDNI Payload Type 2059 (which includes the version) of the expected object. Metadata 2060 clients can specify multiple CDNI Payload Types in the Accept header, 2061 for example if a metadata client is capable of processing two 2062 different versions of the same type of object (defined by different 2063 CDNI Payload Types) it may decide to include both in the Accept 2064 header. The version of each object defined by this document is 2065 version 1. For example: "Content-Type: application/cdni; 2066 ptype=MI.HostIndex.v1". 2068 GenericMetadata objects include a "type" property which specifies the 2069 CDNI Payload Type of the GenericMetadata value. This CDNI Payload 2070 Type should also include a version. Any document which defines a new 2071 GenericMetadata type MUST specify the version number which it 2072 describes. For example: "MI.Location.v1". 2074 6.9. Media Types 2076 All CDNI metadata objects use the Media Type "application/cdni". The 2077 CDNI Payload Type for each object then contains the object name of 2078 that object as defined by this document, prefixed with "MI.". 2079 Table 4 lists the CDNI Paylod Type for the metadata objects 2080 (resources) that are specified in this document. 2082 +-----------------------+-----------------------------+ 2083 | Data Object | CDNI Payload Type | 2084 +-----------------------+-----------------------------+ 2085 | HostIndex | MI.HostIndex.v1 | 2086 | HostMatch | MI.HostMatch.v1 | 2087 | HostMetadata | MI.HostMetadata.v1 | 2088 | PathMatch | MI.PathMatch.v1 | 2089 | PatternMatch | MI.PatternMatch.v1 | 2090 | PathMetadata | MI.PathMetadata.v1 | 2091 | GenericMetadata | MI.SourceMetadata.v1 | 2092 | Source | MI.Source.v1 | 2093 | LocationACL | MI.LocationACL.v1 | 2094 | LocationRule | MI.LocationRule.v1 | 2095 | Footprint | MI.Footprint.v1 | 2096 | TimeWindowACL | MI.TimeWindowACL.v1 | 2097 | TimeWindowRule | MI.TimeWindowRule.v1 | 2098 | TimeWindow | MI.TineWindow.v1 | 2099 | ProtocolACL | MI.ProtocolACL.v1 | 2100 | ProtocolRule | MI.ProtocolRule.v1 | 2101 | DeliveryAuthorization | MI.DeliveryAuthorization.v1 | 2102 | Cache | MI.Cache.v1 | 2103 | Auth | MI.Auth.v1 | 2104 | Grouping | MI.Grouping.v1 | 2105 +-----------------------+-----------------------------+ 2107 Table 4: CDNI Payload Types for CDNI Metadata objects 2109 6.10. Complete CDNI Metadata Example 2111 A dCDN may request the HostIndex and receive the following object 2112 with a CDNI payload type of "MI.HostIndex.v1": 2114 { 2115 "hosts": [ 2116 { 2117 "host": "video.example.com", 2118 "host-metadata" : { 2119 "type": "MI.HostMetadata.v1", 2120 "href": "http://metadata.ucdn.example/host1234" 2121 } 2122 }, 2123 { 2124 "host": "images.example.com", 2125 "host-metadata" : { 2126 "type": "MI.HostMetadata.v1", 2127 "href": "http://metadata.ucdn.example/host5678" 2128 } 2129 } 2130 ] 2131 } 2133 If the incoming request has a Host header with "video.example.com" 2134 then the dCDN would fetch the next metadata object from 2135 "http://metadata.ucdn.example/host1234" expecting a CDNI payload type 2136 of "MI.HostMetadata.v1": 2138 { 2139 "metadata": [ 2140 { 2141 "generic-metadata-type": 2142 "MI.SourceMetadata.v1", 2143 "generic-metadata-value": { 2144 "sources": [ 2145 { 2146 "endpoint": "acq1.ucdn.example", 2147 "protocol": "http1.1" 2148 }, 2149 { 2150 "endpoint": "acq2.ucdn.example", 2151 "protocol": "http1.1" 2152 } 2153 ] 2154 } 2155 }, 2156 { 2157 "generic-metadata-type": 2158 "MI.LocationACL.v1", 2159 "generic-metadata-value": { 2160 "locations": [ 2161 { 2162 "footprints": [ 2163 { 2164 "footprint-type": "IPv4CIDR", 2165 "footprint-value": "192.0.2.0/24" 2166 } 2167 ], 2168 "action": "deny" 2169 } 2170 ] 2171 } 2172 }, 2173 { 2174 "generic-metadata-type": 2175 "MI.ProtocolACL.v1", 2176 "generic-metadata-value": { 2177 "protocol-acl": [ 2178 { 2179 "protocols": [ 2180 "http1.1" 2181 ], 2182 "action": "allow" 2183 } 2184 ] 2185 } 2186 } 2187 ], 2188 "paths": [ 2189 { 2190 "path-pattern": { 2191 "pattern": "/video/trailers/*" 2192 }, 2193 "path-metadata": { 2194 "type": "MI.PathMetadata.v1", 2195 "href": "http://metadata.ucdn.example/host1234/pathABC" 2196 } 2197 }, 2198 { 2199 "path-pattern": { 2200 "pattern": "/video/movies/*" 2201 }, 2202 "path-metadata": { 2203 "type": "MI.PathMetadata.v1", 2204 "href": "http://metadata.ucdn.example/host1234/pathDCE" 2206 } 2207 } 2208 ] 2209 } 2211 Suppose the path of the requested resource matches the "/video/ 2212 movies/*" pattern, the next metadata requested would be for 2213 "http://metadata.ucdn.example/host1234/movies" with an expected CDNI 2214 payload type of "MI.PathMetadata.v1": 2216 { 2217 "metadata": [], 2218 "paths": [ 2219 { 2220 "path-pattern": { 2221 "pattern": "/videos/movies/hd/*" 2222 }, 2223 "path-metadata": { 2224 "type": "MI.PathMetadata.v1", 2225 "href": 2226 "http://metadata.ucdn.example/host1234/pathABC/path123" 2227 } 2228 } 2229 ] 2230 } 2232 Finally, if the path of the requested resource also matches the 2233 "/videos/movies/hd/*" pattern, the dCDN would also fetch the 2234 following object from "http://metadata.ucdn.example/host1234/movies/ 2235 hd" with CDNI payload type "MI.PathMetadata.v1": 2237 { 2238 "metadata": [ 2239 { 2240 "generic-metadata-type": 2241 "MI.TimeWindowACL.v1", 2242 "generic-metadata-value": { 2243 "times": [ 2244 "windows": [ 2245 { 2246 "start": "1213948800", 2247 "end": "1327393200" 2248 } 2249 ], 2250 "action": "allow" 2251 ] 2252 } 2253 } 2254 ] 2255 } 2257 7. IANA Considerations 2259 7.1. CDNI Payload Types 2261 This document requests the registration of the following CDNI Payload 2262 Types under the IANA CDNI Payload Type registry: 2264 +-----------------------------+---------------+ 2265 | Payload Type | Specification | 2266 +-----------------------------+---------------+ 2267 | MI.HostIndex.v1 | RFCthis | 2268 | MI.HostMatch.v1 | RFCthis | 2269 | MI.HostMetadata.v1 | RFCthis | 2270 | MI.PathMatch.v1 | RFCthis | 2271 | MI.PatternMatch.v1 | RFCthis | 2272 | MI.PathMetadata.v1 | RFCthis | 2273 | MI.SourceMetadata.v1 | RFCthis | 2274 | MI.Source.v1 | RFCthis | 2275 | MI.LocationACL.v1 | RFCthis | 2276 | MI.LocationRule.v1 | RFCthis | 2277 | MI.Footprint.v1 | RFCthis | 2278 | MI.TimeWindowACL.v1 | RFCthis | 2279 | MI.TimeWindowRule.v1 | RFCthis | 2280 | MI.TimeWindow.v1 | RFCthis | 2281 | MI.ProtocolACL.v1 | RFCthis | 2282 | MI.ProtocolRule.v1 | RFCthis | 2283 | MI.DeliveryAuthorization.v1 | RFCthis | 2284 | MI.Cache.v1 | RFCthis | 2285 | MI.Auth.v1 | RFCthis | 2286 | MI.Grouping.v1 | RFCthis | 2287 +-----------------------------+---------------+ 2289 [RFC Editor: Please replace RFCthis with the published RFC number for 2290 this document.] 2292 7.1.1. CDNI MI HostIndex Payload Type 2294 Purpose: The purpose of this payload type is to distinguish HostIndex 2295 MI objects (and any associated capabilitiy advertisement) 2297 Interface: MI/FCI 2299 Encoding: see Section 4.1.1 2301 7.1.2. CDNI MI HostMatch Payload Type 2303 Purpose: The purpose of this payload type is to distinguish HostMatch 2304 MI objects (and any associated capabilitiy advertisement) 2306 Interface: MI/FCI 2308 Encoding: see Section 4.1.2 2310 7.1.3. CDNI MI HostMetadata Payload Type 2312 Purpose: The purpose of this payload type is to distinguish 2313 HostMetadata MI objects (and any associated capabilitiy 2314 advertisement) 2316 Interface: MI/FCI 2318 Encoding: see Section 4.1.3 2320 7.1.4. CDNI MI PathMatch Payload Type 2322 Purpose: The purpose of this payload type is to distinguish PathMatch 2323 MI objects (and any associated capabilitiy advertisement) 2325 Interface: MI/FCI 2327 Encoding: see Section 4.1.4 2329 7.1.5. CDNI MI PatternMatch Payload Type 2331 Purpose: The purpose of this payload type is to distinguish 2332 PatternMatch MI objects (and any associated capabilitiy 2333 advertisement) 2335 Interface: MI/FCI 2337 Encoding: see Section 4.1.5 2339 7.1.6. CDNI MI PathMetadata Payload Type 2341 Purpose: The purpose of this payload type is to distinguish 2342 PathMetadata MI objects (and any associated capabilitiy 2343 advertisement) 2345 Interface: MI/FCI 2347 Encoding: see Section 4.1.6 2349 7.1.7. CDNI MI SourceMetadata Payload Type 2351 Purpose: The purpose of this payload type is to distinguish 2352 SourceMetadata MI objects (and any associated capabilitiy 2353 advertisement) 2355 Interface: MI/FCI 2357 Encoding: see Section 4.2.1 2359 7.1.8. CDNI MI Source Payload Type 2361 Purpose: The purpose of this payload type is to distinguish Source MI 2362 objects (and any associated capabilitiy advertisement) 2364 Interface: MI/FCI 2366 Encoding: see Section 4.2.1.1 2368 7.1.9. CDNI MI LocationACL Payload Type 2370 Purpose: The purpose of this payload type is to distinguish 2371 LocationACL MI objects (and any associated capabilitiy advertisement) 2373 Interface: MI/FCI 2375 Encoding: see Section 4.2.2 2377 7.1.10. CDNI MI LocationRule Payload Type 2379 Purpose: The purpose of this payload type is to distinguish 2380 LocationRule MI objects (and any associated capabilitiy 2381 advertisement) 2383 Interface: MI/FCI 2385 Encoding: see Section 4.2.2.1 2387 7.1.11. CDNI MI Footprint Payload Type 2389 Purpose: The purpose of this payload type is to distinguish Footprint 2390 MI objects (and any associated capabilitiy advertisement) 2392 Interface: MI/FCI 2394 Encoding: see Section 4.2.2.2 2396 7.1.12. CDNI MI TimeWindowACL Payload Type 2398 Purpose: The purpose of this payload type is to distinguish 2399 TimeWindowACL MI objects (and any associated capabilitiy 2400 advertisement) 2402 Interface: MI/FCI 2404 Encoding: see Section 4.2.3 2406 7.1.13. CDNI MI TimeWindowRule Payload Type 2408 Purpose: The purpose of this payload type is to distinguish 2409 TimeWindowRule MI objects (and any associated capabilitiy 2410 advertisement) 2412 Interface: MI/FCI 2414 Encoding: see Section 4.2.3.1 2416 7.1.14. CDNI MI TimeWindow Payload Type 2418 Purpose: The purpose of this payload type is to distinguish 2419 TimeWindow MI objects (and any associated capabilitiy advertisement) 2421 Interface: MI/FCI 2423 Encoding: see Section 4.2.3.2 2425 7.1.15. CDNI MI ProtocolACL Payload Type 2427 Purpose: The purpose of this payload type is to distinguish 2428 ProtocolACL MI objects (and any associated capabilitiy advertisement) 2430 Interface: MI/FCI 2432 Encoding: see Section 4.2.4 2434 7.1.16. CDNI MI ProtocolRule Payload Type 2436 Purpose: The purpose of this payload type is to distinguish 2437 ProtocolRule MI objects (and any associated capabilitiy 2438 advertisement) 2440 Interface: MI/FCI 2442 Encoding: see Section 4.2.4.1 2444 7.1.17. CDNI MI DeliveryAuthorization Payload Type 2446 Purpose: The purpose of this payload type is to distinguish 2447 DeliveryAuthorization MI objects (and any associated capabilitiy 2448 advertisement) 2450 Interface: MI/FCI 2452 Encoding: see Section 4.2.5 2454 7.1.18. CDNI MI Cache Payload Type 2456 Purpose: The purpose of this payload type is to distinguish Cache MI 2457 objects (and any associated capabilitiy advertisement) 2459 Interface: MI/FCI 2461 Encoding: see Section 4.2.6 2463 7.1.19. CDNI MI Auth Payload Type 2465 Purpose: The purpose of this payload type is to distinguish Auth MI 2466 objects (and any associated capabilitiy advertisement) 2468 Interface: MI/FCI 2470 Encoding: see Section 4.2.7 2472 7.1.20. CDNI MI Grouping Payload Type 2474 Purpose: The purpose of this payload type is to distinguish Grouping 2475 MI objects (and any associated capabilitiy advertisement) 2477 Interface: MI/FCI 2479 Encoding: see Section 4.2.8 2481 7.2. CDNI Metadata Footprint Types Registry 2483 The IANA is requested to create a new "CDNI Metadata Footprint Types" 2484 registry in the "Content Delivery Networks Interconnection (CDNI) 2485 Parameters" category. The "CDNI Metadata Footprint Types" namespace 2486 defines the valid Footprint object type values used by the Footprint 2487 object in Section 4.2.2.2. Additions to the Footprint type namespace 2488 conform to the "Specification Required" policy as defined in 2489 [RFC5226]. The designated expert will verify that new type 2490 definitions do not duplicate existing type definitions and prevent 2491 gratuitous additions to the namespace. 2493 The following table defines the initial Footprint Registry values: 2495 +----------------+-------------------------------+---------------+ 2496 | Footprint Type | Description | Specification | 2497 +----------------+-------------------------------+---------------+ 2498 | ipv4cidr | IPv4 CIDR address block | RFCthis | 2499 | ipv6cidr | IPv6 CIDR address block | RFCthis | 2500 | asn | Autonomous System (AS) Number | RFCthis | 2501 | countrycode | ISO 3166-1 alpha-2 code | RFCthis | 2502 +----------------+-------------------------------+---------------+ 2504 [RFC Editor: Please replace RFCthis with the published RFC number for 2505 this document.] 2507 7.3. CDNI Metadata Protocol Types Registry 2509 The IANA is requested to create a new "CDNI Metadata Protocol Types" 2510 registry in the "Content Delivery Networks Interconnection (CDNI) 2511 Parameters" category. The "CDNI Metadata Protocol Types" namespace 2512 defines the valid Protocol object values in Section 4.3.2, used by 2513 the SourceMetadata and ProtocolACL objects. Additions to the 2514 Protocol namespace conform to the "Specification Required" policy as 2515 defined in [RFC5226], where the specification defines the Protocol 2516 Type and the protocol to which it is associated. The designated 2517 expert will verify that new protocol definitions do not duplicate 2518 existing protocol definitions and prevent gratuitous additions to the 2519 namespace. 2521 The following table defines the initial Protocol values corresponding 2522 to the HTTP and HTTPS protocols: 2524 +----------+-----------------------+---------------+----------------+ 2525 | Protocol | Description | Type | Protocol | 2526 | Type | | Specification | Specification | 2527 +----------+-----------------------+---------------+----------------+ 2528 | http1.1 | Hypertext Transfer | RFCthis | RFC7230 | 2529 | | Protocol -- HTTP/1.1 | | | 2530 | https1.1 | HTTP/1.1 Over TLS | RFCthis | RFC2818 | 2531 +----------+-----------------------+---------------+----------------+ 2533 [RFC Editor: Please replace RFCthis with the published RFC number for 2534 this document.] 2536 7.4. CDNI Metadata Auth Types Registry 2538 The IANA is requested to create a new "CDNI Metadata Auth Types" 2539 registry in the "Content Delivery Networks Interconnection (CDNI) 2540 Parameters" category. The "CDNI Metadata Auth Type" namespace 2541 defines the valid Auth object types used by the Auth object in 2542 Section 4.2.7. Additions to the Auth Type namespace conform to the 2543 "Specification Required" policy as defined in [RFC5226]. The 2544 designated expert will verify that new type definitions do not 2545 duplicate existing type definitions and prevent gratuitous additions 2546 to the namespace. 2548 The registry will initially be unpopulated: 2550 +-----------+-------------+---------------+ 2551 | Auth Type | Description | Specification | 2552 +-----------+-------------+---------------+ 2553 +-----------+-------------+---------------+ 2555 8. Security Considerations 2557 8.1. Authentication 2559 Unauthorized access to metadata could result in denial of service. A 2560 malicious metadata server, proxy server or an attacker performing a 2561 "man in the middle" attack could provide malicious metadata to a dCDN 2562 that either: 2564 o Denies service for one or more pieces of content to one or more 2565 User Agents; or 2567 o Directs dCDNs to contact malicious origin servers instead of the 2568 actual origin servers. 2570 Unauthorized access to metadata could also enable a malicious 2571 metadata client to continuously issue large metadata requests in 2572 order to overload a uCDN's metadata server(s). 2574 Unauthorized access to metadata could result in leakage of private 2575 information. A malicious metadata client could request metadata in 2576 order to gain access to origin servers, as well as information 2577 pertaining to content restrictions. 2579 An implementation of the CDNI metadata interface SHOULD use mutual 2580 authentication to prevent unauthorized access to metadata. 2582 8.2. Confidentiality 2584 Unauthorized viewing of metadata could result in leakage of private 2585 information. A third party could intercept metadata transactions in 2586 order to gain access to origin servers, as well as information 2587 pertaining to content restrictions. 2589 An implementation of the CDNI metadata interface SHOULD use strong 2590 encryption to prevent unauthorized interception of metadata. 2592 8.3. Integrity 2594 Unauthorized modification of metadata could result in denial of 2595 service. A malicious metadata server, proxy server or an attacker 2596 performing a "man in the middle" attack" could modify metadata 2597 destined to a dCDN in order to deny service for one or more pieces of 2598 content to one or more user agents. A malicious metadata server, 2599 proxy server or an attacker performing a "Man in the middle" attack 2600 could modify metadata so that dCDNs are directed to contact to 2601 malicious origin servers instead of the actual origin servers. 2603 An implementation of the CDNI metadata interface SHOULD use strong 2604 encryption and mutual authentication to prevent unauthorized 2605 modification of metadata. 2607 8.4. Privacy 2609 Content provider origin and policy information is conveyed through 2610 the CDNI metadata interface. The distribution of this information to 2611 another CDN may introduce potential privacy concerns for some content 2612 providers, for example because dCDNs accepting content requests for a 2613 content provider's content may be able to obtain additional 2614 information & usage patterns relating to the users of a content 2615 provider's services. Content providers with such concerns can 2616 instruct their CDN partners not to use CDN interconnects when 2617 delivering that content provider's content. 2619 8.5. Securing the CDNI Metadata interface 2621 An implementation of the CDNI metadata interface MUST support TLS 2622 transport as per [RFC2818] and [RFC7230]. The use of TLS for 2623 transport of the CDNI metadata interface messages allows: 2625 o The dCDN and uCDN to authenticate each other. 2627 and, once they have mutually authenticated each other, it allows: 2629 o The dCDN and uCDN to authorize each other (to ensure they are 2630 transmitting/receiving CDNI metadata requests & responses from an 2631 authorized CDN). 2633 o CDNI metadata interface requests and responses to be transmitted 2634 with confidentiality. 2636 o The integrity of the CDNI metadata interface requests and 2637 responses to be protected during the exchange. 2639 In an environment where any such protection is required, TLS MUST be 2640 used (including authentication of the remote end) by the server-side 2641 (uCDN) and the client-side (dCDN) of the CDNI metadata interface 2642 unless alternate methods are used for ensuring the confidentiality of 2643 the information in the CDNI metadata interface requests and responses 2644 (such as setting up an IPsec tunnel between the two CDNs or using a 2645 physically secured internal network between two CDNs that are owned 2646 by the same corporate entity). 2648 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 2649 followed. 2651 9. Acknowledgements 2653 The authors would like to thank David Ferguson, Francois Le Faucheur, 2654 Jan Seedorf and Matt Miller for their valuable comments and input to 2655 this document. 2657 10. Contributing Authors 2659 [RFC Editor Note: Please move the contents of this section to the 2660 Authors' Addresses section prior to publication as an RFC.] 2662 Grant Watson 2663 Velocix (Alcatel-Lucent) 2664 3 Ely Road 2665 Milton, Cambridge CB24 6AA 2666 UK 2668 Email: gwatson@velocix.com 2670 Kent Leung 2671 Cisco Systems 2672 3625 Cisco Way 2673 San Jose, 95134 2674 USA 2676 Email: kleung@cisco.com 2678 11. References 2680 11.1. Normative References 2682 [ISO3166-1] 2683 "https://www.iso.org/obp/ui/#search". 2685 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2686 Requirement Levels", BCP 14, RFC 2119, 2687 DOI 10.17487/RFC2119, March 1997, 2688 . 2690 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2691 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2692 2006, . 2694 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2695 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2696 DOI 10.17487/RFC5226, May 2008, 2697 . 2699 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 2700 Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, 2701 . 2703 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2704 Address Text Representation", RFC 5952, 2705 DOI 10.17487/RFC5952, August 2010, 2706 . 2708 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2709 Protocol (HTTP/1.1): Message Syntax and Routing", 2710 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2711 . 2713 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2714 "Recommendations for Secure Use of Transport Layer 2715 Security (TLS) and Datagram Transport Layer Security 2716 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2717 2015, . 2719 11.2. Informative References 2721 [I-D.ietf-cdni-redirection] 2722 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 2723 Redirection Interface for CDN Interconnection", draft- 2724 ietf-cdni-redirection-13 (work in progress), October 2015. 2726 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2727 DOI 10.17487/RFC2818, May 2000, 2728 . 2730 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2731 Resource Identifier (URI): Generic Syntax", STD 66, 2732 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2733 . 2735 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2736 Distribution Network Interconnection (CDNI) Problem 2737 Statement", RFC 6707, DOI 10.17487/RFC6707, September 2738 2012, . 2740 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 2741 "Framework for Content Distribution Network 2742 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 2743 August 2014, . 2745 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 2746 Network Interconnection (CDNI) Requirements", RFC 7337, 2747 DOI 10.17487/RFC7337, August 2014, 2748 . 2750 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 2751 DOI 10.17487/RFC7493, March 2015, 2752 . 2754 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2755 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2756 DOI 10.17487/RFC7540, May 2015, 2757 . 2759 Authors' Addresses 2761 Ben Niven-Jenkins 2762 Velocix (Alcatel-Lucent) 2763 3 Ely Road 2764 Milton, Cambridge CB24 6AA 2765 UK 2767 Email: ben@velocix.com 2769 Rob Murray 2770 Velocix (Alcatel-Lucent) 2771 3 Ely Road 2772 Milton, Cambridge CB24 6AA 2773 UK 2775 Email: rmurray@velocix.com 2776 Matt Caulfield 2777 Cisco Systems 2778 1414 Massachusetts Avenue 2779 Boxborough, MA 01719 2780 USA 2782 Phone: +1 978 936 9307 2783 Email: mcaulfie@cisco.com 2785 Kevin J. Ma 2786 Ericsson 2787 43 Nagog Park 2788 Acton, MA 01720 2789 USA 2791 Phone: +1 978-844-5100 2792 Email: kevin.j.ma@ericsson.com