idnits 2.17.1 draft-ietf-cdni-metadata-09.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 (March 4, 2015) is 3334 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) -- 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 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-08 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7230 (Obsoleted by RFC 9110, RFC 9112) Summary: 2 errors (**), 0 flaws (~~), 2 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: September 5, 2015 M. Caulfield 6 Cisco Systems 7 K. Ma 8 Ericsson 9 March 4, 2015 11 CDN Interconnection Metadata 12 draft-ietf-cdni-metadata-09 14 Abstract 16 The CDNI Metadata interface enables interconnected CDNs to exchange 17 content distribution metadata in order to enable content acquisition 18 and delivery. The CDNI metadata associated with a piece of content 19 provides a downstream CDN with sufficient information for the 20 downstream CDN to service content requests on behalf of an upstream 21 CDN. This document describes both a base set of CDNI metadata and 22 the protocol for exchanging that metadata. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on September 5, 2015. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5 67 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 68 3. CDNI Metadata model . . . . . . . . . . . . . . . . . . . . . 6 69 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, 70 PatternMatch and PathMetadata objects . . . . . . . . . . 8 71 3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 11 72 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 14 73 4. Encoding-Independent CDNI Metadata Object Descriptions . . . 14 74 4.1. Descriptions of the CDNI Structural Metadata Objects . . 15 75 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15 76 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 16 78 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 17 79 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 17 80 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 18 81 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 19 82 4.2. Description of the CDNI Generic Metadata Objects . . . . 20 83 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 20 84 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 21 85 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 21 86 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 22 87 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 23 88 4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 23 89 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 24 90 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 24 91 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 25 92 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 25 93 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 26 94 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 26 95 4.2.7. Grouping . . . . . . . . . . . . . . . . . . . . . . 27 96 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 27 97 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 27 98 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 28 99 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 28 100 4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 28 101 4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 28 102 4.3.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 28 103 4.3.6.1. CredentialAuth Type . . . . . . . . . . . . . . . 29 104 4.3.7. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 29 105 4.3.8. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 30 106 4.3.9. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 30 107 4.3.10. CountryCode . . . . . . . . . . . . . . . . . . . . . 30 108 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 30 109 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 31 110 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 31 111 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 32 112 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 33 113 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 34 114 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 34 115 6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 35 116 6.4.2.1. Encoded CDNI Metadata Example . . . . . . . . . . 36 117 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 40 118 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 41 119 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 41 120 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 42 121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 122 7.1. CDNI Metadata Footprint Types Registry . . . . . . . . . 43 123 7.2. CDNI Metadata Protocol Types Registry . . . . . . . . . . 44 124 7.3. CDNI Metadata Auth Types Registry . . . . . . . . . . . . 44 125 8. Security Considerations . . . . . . . . . . . . . . . . . . . 45 126 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 45 127 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 46 128 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 46 129 8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 46 130 8.5. Securing the CDNI Metadata interface . . . . . . . . . . 46 131 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47 132 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 47 133 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 134 11.1. Normative References . . . . . . . . . . . . . . . . . . 48 135 11.2. Informative References . . . . . . . . . . . . . . . . . 48 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 49 138 1. Introduction 140 Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables 141 a downstream CDN to service content requests on behalf of an upstream 142 CDN. 144 The CDNI Metadata interface is discussed in [RFC7336] along with four 145 other interfaces that may be used to compose a CDNI solution (CDNI 146 Control interface, CDNI Request Routing Redirection interface, CDNI 147 Footprint & Capabilities Advertisement interface and CDNI Logging 148 interface). [RFC7336] describes each interface, and the 149 relationships between them. The requirements for the CDNI metadata 150 interface are specified in [RFC7337]. 152 The CDNI metadata associated with a piece of content (or with a set 153 of content) provides a downstream CDN with sufficient information for 154 servicing content requests on behalf of an upstream CDN in accordance 155 with the policies defined by the upstream CDN. 157 This document focuses on the CDNI Metadata interface which enables a 158 downstream CDN to obtain CDNI Metadata from an upstream CDN so that 159 the downstream CDN can properly process and respond to: 161 o Redirection requests received over the CDNI Request Routing 162 Redirection interface. 164 o Content requests received directly from User Agents. 166 Specifically, this document specifies: 168 o A data structure for mapping content requests and redirection 169 requests to CDNI Metadata objects (Section 3 and Section 4.1). 171 o An initial set of CDNI Generic Metadata objects (Section 4.2). 173 o A RESTful web service for the transfer of CDNI Metadata 174 (Section 6). 176 1.1. Terminology 178 This document reuses the terminology defined in [RFC6707]. 180 Additionally, the following terms are used throughout this document 181 and are defined as follows: 183 o Object - a collection of properties. 185 o Property - a key and value pair where the key is a property name 186 and the value is the property value or an object. 188 1.2. Supported Metadata Capabilities 190 Only the metadata for a small set of initial capabilities is 191 specified in this document. This set provides the minimum amount of 192 metadata for basic CDN interoperability while still meeting the 193 requirements set forth by [RFC7337]. 195 The following high-level functionality is configured via the metadata 196 described in Section 4: 198 o Acquisition Source: Metadata for allowing a dCDN to fetch content 199 from a uCDN. 201 o Delivery Access Control: Metadata for restricting (or permitting) 202 access to content based on any of the following factors: 204 * Location 206 * Time Window 208 * Delivery Protocol 210 o Delivery Authorization: Metadata for authorizing dCDN user agent 211 requests. 213 o Cache Control: Metadata for controlling cache behavior of the 214 dCDN. 216 The metadata encoding described by this document is extensible in 217 order to allow for future additions to this list. 219 The set of metadata specified in this document, covering the initial 220 capabilities above, is only able to support CDN interconnection for 221 the delivery of content by a dCDN using HTTPv1.1 and for a dCDN to be 222 able to acquire content from a uCDN using either HTTPv1.1 or HTTPv1.1 223 over TLS. 225 Supporting CDN interconnection for the delivery of content using 226 unencrypted HTTPv2.0 (as well as for a dCDN to acquire content using 227 unencrypted HTTPv2.0 or HTTPv2.0 over TLS) requires the registration 228 of these protocol names in the CDNI Metadata Protocol Registry. 230 Supporting CDN interconnection for the delivery of content using 231 HTTPv1.1 over TLS or HTTPv2.0 over TLS requires specifying additional 232 metadata objects to carry the properties required to establish a TLS 233 session, for example metadata to describe the certificate to use as 234 part of the TLS handshake. 236 2. Design Principles 238 The CDNI Metadata interface was designed to achieve the following 239 objectives: 241 1. Cacheability of CDNI metadata objects. 243 2. Deterministic mapping from redirection requests and content 244 requests to CDNI metadata properties. 246 3. Support for DNS redirection as well as application-specific 247 redirection (for example HTTP redirection). 249 4. Minimal duplication of CDNI metadata. 251 5. Leveraging of existing protocols. 253 Cacheability improves the latency of acquiring metadata while 254 maintaining its freshness, and therefore improves the latency of 255 serving content requests and redirection requests, without 256 sacrificing accuracy. The CDNI Metadata interface uses HTTP and its 257 existing caching mechanisms to achieve CDNI metadata cacheability. 259 Deterministic mappings from content to metadata properties eliminates 260 ambiguity and ensures that policies are applied consistently by all 261 downstream CDNs. 263 Support for both HTTP and DNS redirection ensures that the CDNI 264 Metadata interface can be used for HTTP and DNS redirection and also 265 meets the same design principles for both HTTP and DNS based 266 redirection schemes. 268 Minimal duplication of CDNI metadata provides space efficiency on 269 storage in the CDNs, on caches in the network, and across the network 270 between CDNs. 272 Leveraging existing protocols avoids reinventing common mechanisms 273 such as data structure encoding (e.g., JSON) and data transport 274 (e.g., HTTP). 276 3. CDNI Metadata model 278 The CDNI Metadata model describes a data structure for mapping 279 redirection requests and content requests to metadata properties. 280 Metadata properties describe how to acquire content from an upstream 281 CDN, authorize access to content, and deliver content from a 282 downstream CDN. The data model relies on the assumption that these 283 metadata properties may be aggregated based on the hostname of the 284 content and subsequently on the resource path of the content. The 285 data model associates a set of CDNI Metadata properties with a 286 Hostname to form a default set of metadata properties for content 287 delivered on behalf of that Hostname. That default set of metadata 288 properties can be overridden by properties that apply to specific 289 paths within a URI. 291 Different Hostnames and URI paths will be associated with different 292 sets of CDNI Metadata properties in order to describe the required 293 behaviour when a dCDN surrogate is processing User Agent requests for 294 content at that Hostname or URI path. As a result of this structure, 295 significant commonality may exist between the CDNI Metadata 296 properties specified for different Hostnames, different URI paths 297 within a Hostname and different URI paths on different Hostnames. 298 For example the definition of which User Agent IP addresses should be 299 treated as being grouped together into a single network or geographic 300 location is likely to be common for a number of different Hostnames. 301 Another example is that although a uCDN is likely to have several 302 different policies configured to express geo-blocking rules, it is 303 likely that a single geo-blocking policy would be applied to multiple 304 Hostnames delivered through the CDN. 306 In order to enable the CDNI Metadata for a given Hostname or URI Path 307 to be decomposed into sets of CDNI Metadata properties that can be 308 reused by multiple Hostnames and URI Paths, the CDNI Metadata 309 interface specified in this document splits the CDNI Metadata into a 310 number of objects. Efficiency is improved by enabling a single CDNI 311 Metadata object (that is shared across Hostname and/or URI paths) to 312 be retrieved and stored by a dCDN once, even if it is referenced by 313 the CDNI Metadata of multiple Hostnames or of multiple URI paths. 315 Section 3.1 introduces a high level description of the HostIndex, 316 HostMatch, HostMetadata, PathMatch, PatternMatch and PathMetadata 317 objects and describes the relationships between those objects. 319 Section 3.2 introduces a high level description of the CDNI 320 GenericMetadata object which represents the level at which CDNI 321 Metadata override occurs between HostMetadata and PathMetadata 322 objects. 324 Section 4 describes in detail the specific CDNI Metadata objects and 325 properties which may be contained within a CDNI GenericMetadata 326 object. 328 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch and 329 PathMetadata objects 331 A HostIndex object contains (or references) a list of Hostnames (and/ 332 or IP addresses) for which content requests may be delegated to the 333 downstream CDN. The HostIndex is the starting point for accessing 334 the uCDN CDNI Metadata data store. It enables the dCDN to 335 deterministically discover, on receipt of a User Agent request for 336 content, which other CDNI Metadata objects it requires in order to 337 deliver the requested content. 339 The HostIndex links Hostnames (and/or IP addresses) to HostMetadata 340 objects via HostMatch objects. HostMetadata objects contain (or 341 reference) the default CDNI Metadata required to serve content for 342 that host. When looking up CDNI Metadata, the downstream CDN looks 343 up the requested Hostname (or IP address) against the HostMatch 344 entries in the HostIndex, from there it can find HostMetadata which 345 describes properties for a host and PathMetadata which may override 346 those properties for given URI paths within the host. 348 HostMetadata and PathMetadata objects may also contain PathMatch 349 objects which in turn contain PathMetadata objects. PathMetadata 350 objects override the CDNI Metadata in the HostMetadata object or one 351 or more preceding PathMetadata objects with more specific CDNI 352 Metadata that applies to content requests matching the pattern 353 defined in the PatternMatch object of that PathMatch object. 355 For the purposes of retrieving CDNI Metadata, all other required CDNI 356 Metadata objects and their properties are discoverable from the 357 appropriate HostMetadata, PathMatch and PathMetadata objects for the 358 requested content. 360 The relationships between the HostIndex, HostMatch, HostMetadata, 361 PathMatch, PatternMatch and PathMetadata objects are described in 362 Figure 1. 364 +---------+ +---------+ +------------+ 365 |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ 366 +---------+ +---------+ +------+-----+ | 367 | | 368 (*) | 369 | V 370 --> Contains or References V ****************** 371 (1) One and only one +---------+ *Generic Metadata* 372 (*) Zero or more +--->|PathMatch| * Objects * 373 | +----+---++ ****************** 374 | | | ^ 375 (*) (1) (1) +------------+ | 376 | | +->|PatternMatch| | 377 | V +------------+ | 378 | +------------+ | 379 +--+PathMetadata+-------(*)------+ 380 +------------+ 382 Figure 1: Relationships between CDNI Metadata Objects (Diagram 383 Representation) 385 The relationships in Figure 1 are also represented in tabular format 386 in Table 1 below. 388 +--------------+----------------------------------------------------+ 389 | Data Object | Objects it contains or references | 390 +--------------+----------------------------------------------------+ 391 | HostIndex | 0 or more HostMatch objects. | 392 | HostMatch | 1 HostMetadata object. | 393 | HostMetadata | 0 or more PathMatch objects. 0 or more | 394 | | GenericMetadata objects. | 395 | PathMatch | 1 PatternMatch object. 1 PathMetadata object. | 396 | PatternMatch | Does not contain or reference any other objects. | 397 | PathMetadata | 0 or more PathMatch objects. 0 or more | 398 | | GenericMetadata objects. | 399 +--------------+----------------------------------------------------+ 401 Table 1: Relationships between CDNI Metadata Objects 402 (Table Representation) 404 The table below describes the HostIndex, HostMatch, HostMetadata, 405 PathMatch, PatternMatch and PathMetadata objects in more detail. 407 +-----------------+-------------------------------------------------+ 408 | Data Object | Description | 409 +-----------------+-------------------------------------------------+ 410 | HostIndex | A HostIndex object lists HostMatch objects | 411 | HostMatch | A HostMatch object defines a hostname (or IP | 412 | | address) to match against a requested host, and | 413 | | contains (or references) a HostMetadata object | 414 | | which contains (or references) CDNI Metadata | 415 | | objects to be applied when a request matches | 416 | | against the hostname. For example, if | 417 | | "example.com" is a content provider, a | 418 | | HostMatch object may include an entry for | 419 | | "example.com" with the URI of the associated | 420 | | HostMetadata object. | 421 | HostMetadata | A HostMetadata object contains (or references) | 422 | | the default CDNI Metadata objects for content | 423 | | served from that host, i.e., the CDNI Metadata | 424 | | objects for content requests that do not match | 425 | | any of the PathMatch objects contained (or | 426 | | referenced) by that HostMetadata object. For | 427 | | example, a HostMetadata object may describe the | 428 | | metadata properties which apply to | 429 | | "example.com" and may contain PathMatches for | 430 | | "example.com/movies/*" and | 431 | | "example.com/music/*" which in turn reference | 432 | | corresponding PathMetadata objects that contain | 433 | | the CDNI Metadata objects for those more | 434 | | specific URI paths. | 435 | PathMatch | A PathMatch object defines a pattern (inside a | 436 | | PatternMatch object which the PathMatch object | 437 | | contains or references) to match against the | 438 | | requested URI path, and contains (or | 439 | | references) a PathMetadata object which | 440 | | contains (or references) the CDNI Metadata | 441 | | objects to be applied when a content request | 442 | | matches against the defined URI path pattern. | 443 | | For example, a PathMatch object may include a | 444 | | PatternMatch object containing a pattern for | 445 | | the path "/movies/*" and may reference a | 446 | | PathMetadata object which contains (or | 447 | | references) the CDNI Metadata for content with | 448 | | that path. | 449 | PatternMatch | A PatternMatch object contains the pattern | 450 | | string and flags that describe the URI path | 451 | | that a PathMatch applies to. | 452 | PathMetadata | A PathMetadata object contains (or references) | 453 | | the CDNI GenericMetadata objects for content | 454 | | served with the associated URI path (defined in | 455 | | a PathMatch object). A PathMetadata object may | 456 | | also contain (or reference) PathMatch objects | 457 | | in order to recursively define more specific | 458 | | URI paths that require different (e.g., more | 459 | | specific) CDNI Metadata to this one. For | 460 | | example, the PathMetadata object which applies | 461 | | to "example.com/movies/*" may describe CDNI | 462 | | Metadata which apply to that URI path and may | 463 | | contain a PathMatch object for | 464 | | "example.com/movies/hd/*" which would reference | 465 | | the corresponding PathMetadata object for the | 466 | | "example.com/movies/hd/" path prefix. | 467 | GenericMetadata | A GenericMetadata object contains (or | 468 | | references) individual CDNI Metadata objects | 469 | | which define the specific policies and | 470 | | attributes needed to properly deliver the | 471 | | associated content. For example, a | 472 | | GenericMetadata object may describe the source | 473 | | from which a CDN may acquire a piece of | 474 | | content. The GenericMetadata object is an | 475 | | atomic unit that may be referenced by | 476 | | HostMetadata and/or PathMetadata objects, but | 477 | | SHOULD NOT contain references to other CDNI | 478 | | Metadata objects. The member objects of a | 479 | | specific CDNI Metadata object MAY be referenced | 480 | | by the GenericMetadata object. | 481 +-----------------+-------------------------------------------------+ 483 Table 2: HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch 484 and PathMetadata CDNI Metadata Objects 486 3.2. Generic CDNI Metadata Object Properties 488 The HostMetadata and PathMetadata objects contain or can reference 489 other CDNI Metadata objects that contain properties which describe 490 how User Agent requests for content should be processed, for example 491 where to acquire the content, authorization rules that should be 492 applied, delivery location restrictions and so on. Each such CDNI 493 Metadata object is a specialization of a CDNI GenericMetadata object. 494 The GenericMetadata object abstracts the basic information required 495 for Metadata override and Metadata distribution, from the specifics 496 of any given property (e.g., property semantics, enforcement options, 497 etc.). 499 The GenericMetadata object defines the type of properties contained 500 within it as well as whether or not the properties are "mandatory-to- 501 enforce". If the dCDN does not understand or support the property 502 type and the property type is "mandatory-to-enforce", the dCDN MUST 503 NOT serve the content to the User Agent. If the dCDN does not 504 understand or support the property type and the property type is not 505 "mandatory-to-enforce", then that GenericMetadata object may be 506 safely ignored and the dCDN MUST process the content request in 507 accordance with the rest of the CDNI metadata. 509 Although a CDN MUST NOT serve content to a User Agent if a 510 "mandatory-to-enforce" property cannot be enforced, it may be "safe- 511 to-redistribute" that metadata to another CDN without modification. 512 For example, in the cascaded CDN case, a transit CDN may pass through 513 "mandatory-to-enforce" metadata to a downstream CDN. For Metadata 514 which does not require customization or translation (i.e., metadata 515 that is "safe-to-redistribute"), the data representation received off 516 the wire MAY be stored and redistributed without being natively 517 understood or supported by the transit CDN. However, for Metadata 518 which requires translation, transparent redistribution of the uCDN 519 Metadata values might not be appropriate. Certain Metadata may be 520 safely, though possibly not optimally, redistributed unmodified. For 521 example, source acquisition address may not be optimal if 522 transparently redistributed, but might still work. 524 Redistribution safety MUST be specified for each GenericMetadata. If 525 a CDN does not understand or support a given GenericMetadata property 526 type and the property type is not "safe-to-redistribute", before 527 redistributing the metadata, the CDN MUST set the "incomprehensible" 528 flag for the GenericMetadata property that it did not understand and 529 was marked as not "safe-to-redistribute". The "incomprehensible" 530 flag signals to a dCDN that the metadata was not properly transformed 531 by the transit CDN. A CDN MUST NOT attempt to use metadata that has 532 been marked as "incomprehensible" by a uCDN. 534 Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or 535 "safe-to-redistribute" when propagating metadata to a dCDN. Although 536 a transit CDN may set the value of "incomprehensible" to true, a 537 transit CDN MUST NOT change the value of "incomprehensible" from true 538 to false. 540 The following table describes the action to be taken by a transit CDN 541 (tCDN) for the different "mandatory-to-enforce" (MtE) and "safe-to- 542 redistribute" (StR) cases, when the tCDN either does or does not 543 understand the metadata in question: 545 +-------+-------+------------+--------------------------------------+ 546 | MtE | StR | Metadata | Actions | 547 | | | Understood | | 548 +-------+-------+------------+--------------------------------------+ 549 | False | True | True | Can serve and redistribute. | 550 | False | True | False | Can serve and redistribute. | 551 | False | False | False | Can serve. MUST set | 552 | | | | "incomprehensible" to True when | 553 | | | | redistributing. | 554 | False | False | True | Can serve. Can redistribute either | 555 | | | | by transforming not StR metadata (if | 556 | | | | the CDN knows how to do so safely), | 557 | | | | otherwise MUST set | 558 | | | | "incomprehensible" to True when | 559 | | | | redistributing. | 560 | True | True | True | Can serve and redistribute. | 561 | True | True | False | MUST NOT serve but can redistribute. | 562 | True | False | True | Can serve and redistribute. | 563 | True | False | False | MUST NOT serve. MUST set | 564 | | | | "incomprehensible" to True when | 565 | | | | redistributing. | 566 +-------+-------+------------+--------------------------------------+ 568 The following table describes the action to be taken by a dCDN for 569 the different "mandatory-to-enforce" (MtE) and "incomprehensible" 570 (Incomp) cases, when the dCDN either does or does not understand the 571 metadata in question: 573 +-------+------------+--------+-------------------------------------+ 574 | MtE | Metadata | Incomp | Actions | 575 | | Understood | | | 576 +-------+------------+--------+-------------------------------------+ 577 | False | True | False | Can serve. | 578 | False | True | True | Can serve but MUST NOT | 579 | | | | interpret/apply any metadata marked | 580 | | | | incomprehensible. | 581 | False | False | False | Can serve. | 582 | False | False | True | Can serve but MUST NOT | 583 | | | | interpret/apply any metadata marked | 584 | | | | incomprehensible. | 585 | True | True | False | Can serve. | 586 | True | True | True | MUST NOT serve. | 587 | True | False | False | MUST NOT serve. | 588 | True | False | True | MUST NOT serve. | 589 +-------+------------+--------+-------------------------------------+ 591 3.3. Metadata Inheritance and Override 593 In the Metadata model, a HostMetadata object may contain (or 594 reference) multiple PathMetadata objects (via PathMatch objects). 595 Each PathMetadata object may in turn contain (or reference) other 596 PathMetadata objects. HostMetadata and PathMetadata objects form an 597 inheritance tree where each node in the tree inherits or overrides 598 the property values set by its parent. 600 GenericMetadata objects of a given type override all GenericMetadata 601 objects of the same type previously defined by any parent object in 602 the tree. GenericMetadata objects of a given type previously defined 603 by a parent object in the tree are inherited when no object of the 604 same type is defined by the child object. For example, if 605 HostMetadata for the host "example.com" contains GenericMetadata 606 objects of type LocationACL and TimeWindowACL, while a PathMetadata 607 object which applies to "example.com/movies/*" defines an alternate 608 GenericMetadata object of type TimeWindowACL, then: 610 o the TimeWindowACL defined in the PathMetadata would override the 611 TimeWindowACL defined in the HostMetadata for all User Agent 612 requests for content under "example.com/movies/", and 614 o the LocationACL defined in the HostMetadata would be inherited for 615 all User Agent requests for content under "example.com/movies/". 617 o A single HostMetadata or PathMetadata object SHOULD NOT contain 618 multiple GenericMetadata objects of the same type. If a list of 619 GenericMetadata contains objects of duplicate types, the receiver 620 MUST ignore all but the first object of each type. 622 4. Encoding-Independent CDNI Metadata Object Descriptions 624 Section 4.1 provides the definitions of each metadata object type 625 declared in Section 3. These metadata objects are described as 626 structural objects as they provide the structure for the inheritance 627 tree and identify which specific properties apply to a given User 628 Agent content request. 630 Section 4.2 provides the definitions for a base set of core metadata 631 objects which may be contained within a GenericMetadata object. 632 These metadata objects are described as property objects, as they 633 define the structure, semantics, and enforcement options for specific 634 properties of the metadata being described. Property objects govern 635 how User Agent requests for content are handled. Property objects 636 may be composed of, or contain references to, other property sub- 637 objects (i.e., property objects contained within or referenced by the 638 property object that refers to that property sub-object). In those 639 cases the value of the property sub-objects can be either a complete 640 serialized representation of the sub-object, or a Link object that 641 contains a URI that can be dereferenced to retrieve the complete 642 serialized representation of the property sub-object. 644 Section 6.5 discusses the ability to extend the base set of metadata 645 objects specified in this document with additional standards based or 646 vendor specific property objects that may be defined in the future in 647 separate documents. 649 Downstream CDNs 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 Note: In the following sections, the term "mandatory-to-specify" is 658 used to convey which property sub-objects MUST be specified for a 659 given structural or property object. When mandatory-to-specify is 660 specified as "Yes" by this document for an individual property or 661 sub-object, it means that if the property object containing that 662 property or sub-object is included in a metadata response, then the 663 mandatory-to-specify property or sub-object MUST also be included 664 (directly or by reference) in the response, e.g., a HostMatch 665 property object without a host to match against does not make sense, 666 therefore, the host is mandatory-to-specify inside a HostMatch 667 property object. 669 4.1. Descriptions of the CDNI Structural Metadata Objects 671 Each of the sub-sections below describe the structural objects 672 defined in Table 2. 674 4.1.1. HostIndex 676 The HostIndex object is the entry point into the CDNI Metadata 677 hierarchy. It contains (or references) a list of HostMatch objects. 678 An incoming content request is checked against the hostname (or IP 679 address) specified by each of the listed HostMatch objects to find 680 the HostMatch object which applies to the request. 682 Property: hosts 684 Description: List of HostMatch objects. Hosts (HostMatch 685 objects) MUST be evaluated in the order they appear and the 686 first HostMatch object that matches the content request being 687 processed MUST be used. 689 Type: List of HostMatch objects 691 Mandatory-to-Specify: Yes. 693 4.1.2. HostMatch 695 The HostMatch object contains a hostname or IP address to match 696 against content requests. The HostMatch object also contains or 697 references a HostMetadata object to apply if a match is found. 699 Property: host 701 Description: String (hostname or IP address) to match against 702 the requested host. In order for a hostname or IP address in a 703 content request to match the hostname or IP address in the host 704 property the value when converted to lowercase in the content 705 request MUST be identical to the value of the host property 706 when converted to lowercase. 708 Type: String 710 Mandatory-to-Specify: Yes. 712 Property: host-metadata 714 Description: CDNI Metadata to apply when delivering content 715 that matches this host. 717 Type: HostMetadata 719 Mandatory-to-Specify: Yes. 721 4.1.3. HostMetadata 723 A HostMetadata object contains (or references) the CDNI Metadata 724 properties for content served for a particular host (defined in the 725 HostMatch object) and possibly child PathMatch objects. 727 Property: metadata 729 Description: List of host related metadata. 731 Type: List of GenericMetadata objects 733 Mandatory-to-Specify: Yes. 735 Property: paths 737 Description: Path specific rules. Path patterns (PathMatch 738 objects) MUST be evaluated in the order they appear and the 739 first PathMatch object that matches the content request being 740 processed MUST be used. 742 Type: List of PathMatch objects 744 Mandatory-to-Specify: No. 746 4.1.4. PathMatch 748 The PathMatch object contains (or references) an expression given as 749 a PatternMatch object to match against a resource URI path and 750 contains or references a PathMetadata object to apply if a match is 751 found. 753 Property: path-pattern 755 Description: Pattern to match against the requested path, i.e., 756 against the [RFC3986] path-absolute. 758 Type: PatternMatch 760 Mandatory-to-Specify: Yes. 762 Property: path-metadata 764 Description: CDNI Metadata to apply when delivering content 765 that matches this path. 767 Type: PathMetadata 769 Mandatory-to-Specify: Yes. 771 4.1.5. PatternMatch 773 A PatternMatch object contains the pattern string and flags that 774 describe the PathMatch expression. 776 Property: pattern 778 Description: A pattern for string matching. The pattern may 779 contain the wildcards * and ?, where * matches any sequence of 780 characters (including the empty string) and ? matches exactly 781 one character. The three literals \ , * and ? should be 782 escaped as \\, \* and \?. All other characters are treated as 783 literals. 785 Type: String 787 Mandatory-to-Specify: Yes. 789 Property: case-sensitive 791 Description: Flag indicating whether or not case-sensitive 792 matching should be used. 794 Type: Boolean 796 Mandatory-to-Specify: No. Default is case-insensitive match. 798 Property: ignore-query-string 800 Description: List of query parameters which should be ignored 801 when searching for a pattern match. Matching against query 802 parameters to ignore MUST be case-insensitive. If all query 803 parameters should be ignored then the list MUST be empty. 805 Type: List of String 807 Mandatory-to-Specify: No. Default is to include query strings 808 when matching. 810 4.1.6. PathMetadata 812 A PathMetadata object contains (or references) the CDNI Metadata 813 properties for content served with the associated URI path (defined 814 in a PathMatch object) and possibly child PathMatch objects. 816 Note that if DNS-based redirection is employed, then a dCDN will be 817 unable to evaulate any metadata at the PathMetadata level or below 818 against the content redirection request at request routing time 819 because only the content request hostname is available at request 820 routing time. dCDNs SHOULD still process any metadata at the 821 PathMetadata level or below before responding to the redirection 822 request in order to detect if any unsupported metadata is specifed. 823 If any metadata is included that is not supported by the dCDN then 824 the dCDN SHOULD NOT redirect the the content redirection request to 825 itself in order to avoid receiving content requests that it is not 826 able to satisfy/serve. 828 Property: metadata 829 Description: List of path related metadata. 831 Type: List of GenericMetadata objects 833 Mandatory-to-Specify: Yes. 835 Property: paths 837 Description: Path specific rules. First match applies. 839 Type: List of PathMatch objects 841 Mandatory-to-Specify: No. 843 4.1.7. GenericMetadata 845 A GenericMetadata object is an abstraction for managing individual 846 CDNI Metadata properties in an opaque manner. 848 Property: generic-metadata-type 850 Description: Case-insensitive CDNI Metadata property object 851 type. 853 Type: String containing a MIME Media Type 855 Mandatory-to-Specify: Yes. 857 Property: generic-metadata-value 859 Description: CDNI Metadata property object. 861 Type: Format/Type is defined by the value of generic-metadata- 862 type property above. 864 Mandatory-to-Specify: Yes. 866 Property: mandatory-to-enforce 868 Description: Flag identifying whether or not the enforcement of 869 the property Metadata is required. 871 Type: Boolean 873 Mandatory-to-Specify: No. Default is to treat metadata as 874 mandatory to enforce (i.e., a value of True). 876 Property: safe-to-redistribute 877 Description: Flag identifying whether or not the property 878 Metadata may be safely redistributed without modification. 880 Type: Boolean 882 Mandatory-to-Specify: No. Default is allow transparent 883 redistribution (i.e., a value of True). 885 Property: incomprehensible 887 Description: Flag identifying whether or not any CDN in the 888 chain of delegation has failed to understand and/or failed to 889 properly transform this metadata object. Note: This flag only 890 applies to metadata objects whose safe-to-redistribute property 891 has a value of False. 893 Type: Boolean 895 Mandatory-to-Specify: No. Default is comprehensible (i.e., a 896 value of False). 898 4.2. Description of the CDNI Generic Metadata Objects 900 The property objects defined below are intended to be used in the 901 GenericMetadata object generic-metadata-value field as defined in 902 Section 4.1.7 and their generic-metadata-type property MUST be set to 903 the appropriate Media Type as defined in Table 3. 905 4.2.1. SourceMetadata 907 Source Metadata provides the dCDN information about content 908 acquisition, i.e., how to contact an uCDN Surrogate or an Origin 909 Server to obtain the content to be served. The sources are not 910 necessarily the actual Origin Servers operated by the CSP but might 911 be a set of Surrogates in the uCDN. 913 Endpoints within a source should be treated as equivalent/equal so 914 one can specify a list of sources in preference order and for each 915 source/preference rank one can specify a list of endpoints that are 916 equivalent, e.g., a pool of servers that are not behind a load 917 balancer. 919 Property: sources 921 Description: Sources from which the dCDN can acquire content, 922 listed in order of preference. 924 Type: List of Source objects 925 Mandatory-to-Specify: No. Default is to use static 926 configuration, out-of-band from the metadata interface. 928 4.2.1.1. Source 930 A Source object describes the Source which should be used by the dCDN 931 for content acquisition, e.g., a Surrogate within the uCDN or an 932 alternate Origin Server, the protocol to be used and any 933 authentication method. 935 Property: acquisition-auth 937 Description: Authentication method to use when requesting 938 content from this source. 940 Type: Auth 942 Mandatory-to-Specify: No. Default is no authentication 943 required. 945 Property: endpoints 947 Description: Origins from which the dCDN can acquire content. 948 If multiple endpoints are specified they are all equal, i.e., 949 the list is not in preference order, for example a pool of 950 servers behind a load balancer. 952 Type: List of EndPoint objects 954 Mandatory-to-Specify: Yes. 956 Property: protocol 958 Description: Network retrieval protocol to use when requesting 959 content from this source. 961 Type: Protocol 963 Mandatory-to-Specify: Yes. 965 4.2.2. LocationACL Metadata 967 LocationACL Metadata defines location-based restrictions. 969 A LocationACL which does not include a locations property results in 970 an action of allow, meaning that delivery can be performed regardless 971 of the User Agent's location. The action from the first footprint to 972 match against the User Agent's location is the action a CDN MUST 973 take. If two or more footprints overlap, the first footprint that 974 matches against the User Agent's location determines the action a CDN 975 MUST take. If the locations property is included but is empty, or if 976 none of the listed footprints matches the User Agent's location, then 977 the result is an action of deny. 979 Although the LocationACL, TimeWindowACL, and ProtocolACL are 980 independent GenericMetadata objects, they may provide conflicting 981 information to a dCDN, e.g., a content request which is 982 simultaneously allowed based on the LocationACL and denied based on 983 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 984 (where 'allow' is true and 'deny' is false) to determine whether or 985 not a request should be allowed. Thus, in the example given, the 986 request should be denied. 988 Property: locations 990 Description: Access control list which allows or denies 991 (blocks) delivery based on client location. 993 Type: List of LocationRule objects 995 Mandatory-to-Specify: No. Default is allow all locations. 997 4.2.2.1. LocationRule 999 A LocationRule contains or references a list of Footprint objects and 1000 the corresponding action. 1002 Property: footprints 1004 Description: List of footprints to which the rule applies. 1006 Type: List of Footprint objects 1008 Mandatory-to-Specify: Yes. 1010 Property: action 1012 Description: Defines whether the rule specifies locations to 1013 allow or deny. 1015 Type: Enumeration [allow|deny] 1017 Mandatory-to-Specify: No. Default is deny. 1019 4.2.2.2. Footprint 1021 A Footprint object describes the footprint to which a LocationRule 1022 may be applied to, e.g., an IPv4 address range or a geographic 1023 location. 1025 Property: footprint-type 1027 Description: Registered footprint type. The footprint types 1028 specified by this document are: IPv4CIDR (see Section 4.3.7), 1029 IPv6CIDR (see Section 4.3.8), Autonomous System Number (see 1030 Section 4.3.9) and Country Code (see Section 4.3.10). 1032 Type: String 1034 Mandatory-to-Specify: Yes. 1036 Property: footprint-value 1038 Description: Footprint object conforming to the specification 1039 associated with the registered footprint type. 1041 Type: String 1043 Mandatory-to-Specify: Yes. 1045 4.2.3. TimeWindowACL Metadata 1047 TimeWindowACL Metadata defines time-based restrictions. 1049 A TimeWindowACL which does not include a times property results in an 1050 action of allow, meaning that delivery can be performed regardless of 1051 the time of the User Agent's request. The action from the first 1052 window to match against the current time is the action a CDN MUST 1053 take. If two or more windows overlap, the first window that matches 1054 against the current time determines the action a CDN MUST take. If 1055 the times property is included but is empty, or if none of the listed 1056 windows matches the current time, then the result is an action of 1057 deny. 1059 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1060 independent GenericMetadata objects, they may provide conflicting 1061 information to a dCDN, e.g., a content request which is 1062 simultaneously allowed based on the LocationACL and denied based on 1063 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1064 (where 'allow' is true and 'deny' is false) to determine whether or 1065 not a request should be allowed. Thus, in the example given, the 1066 request should be denied. 1068 Property: times 1070 Description: Description: Access control list which allows or 1071 denies (blocks) delivery based on request time. 1073 Type: List of TimeWindowRule objects 1075 Mandatory-to-Specify: No. Default is allow all time windows. 1077 4.2.3.1. TimeWindowRule 1079 A TimeWindowRule contains or references a list of TimeWindow objects 1080 and the corresponding action. 1082 Property: windows 1084 Description: List of time windows to which the rule applies. 1086 Type: List of TimeWindow objects 1088 Mandatory-to-Specify: Yes. 1090 Property: action 1092 Description: Defines whether the rule specifies time windows to 1093 allow or deny. 1095 Type: Enumeration [allow|deny] 1097 Mandatory-to-Specify: No. Default is deny. 1099 4.2.3.2. TimeWindow 1101 A TimeWindow object describes a time range which may be applied by an 1102 TimeWindowACL, e.g., start 946717200 (i.e., 09:00AM 01/01/2000 UTC), 1103 end: 946746000 (i.e., 17:00AM 01/01/2000 UTC). 1105 Property: start 1107 Description: The start time of the window. 1109 Type: Time 1111 Mandatory-to-Specify: Yes. 1113 Property: end 1115 Description: The end time of the window. 1117 Type: Time 1119 Mandatory-to-Specify: Yes. 1121 4.2.4. ProtocolACL Metadata 1123 ProtocolACL Metadata defines delivery protocol restrictions. 1125 A ProtocolACL which does not include a protocol-acl property results 1126 in an action of allow, meaning that delivery can be performed 1127 regardless of the protocol of the User Agent's request. The action 1128 from the first protocol to match against the request protocol is the 1129 action a CDN MUST take. If two or more request protocols overlap, 1130 the first protocol that matches thre request protocol determines the 1131 action a CDN MUST take. If the protocol-acl property is included but 1132 is empty, or if none of the listed protocol matches the request 1133 protocol, then the result is an action of deny. 1135 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1136 independent GenericMetadata objects, they may provide conflicting 1137 information to a dCDN, e.g., a content request which is 1138 simultaneously allowed based on the ProtocolACL and denied based on 1139 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1140 (where 'allow' is true and 'deny' is false) to determine whether or 1141 not a request should be allowed. Thus, in the example given, the 1142 request should be denied. 1144 Property: protocol-acl 1146 Description: Description: Access control list which allows or 1147 denies (blocks) delivery based on delivery protocol. 1149 Type: List of ProtocolRule objects 1151 Mandatory-to-Specify: No. Default is allow all protocols. 1153 4.2.4.1. ProtocolRule 1155 A ProtocolRule contains or references a list of Protocol objects. 1156 ProtocolRule objects are used to construct a ProtocolACL to apply 1157 restrictions to content acquisition or delivery. 1159 Property: protocols 1161 Description: List of protocols to which the rule applies. 1163 Type: List of protocol objects 1164 Mandatory-to-Specify: Yes. 1166 Property: action 1168 Description: Defines whether the rule specifies protocols to 1169 allow or deny. 1171 Type: Enumeration [allow|deny] 1173 Mandatory-to-Specify: No. Default is deny. 1175 4.2.5. DeliveryAuthorization Metadata 1177 Delivery Authorization defines authorization methods for the delivery 1178 of content to User Agents. 1180 Property: delivery-auth-methods 1182 Description: Options for authorizing content requests. 1183 Delivery for a content request is authorized if any of the 1184 authorization method in the list is satisfied for that request. 1186 Type: List of Auth objects 1188 Mandatory-to-Specify: No. Default is no authorization 1189 required. 1191 4.2.6. Cache 1193 A Cache object describes the cache control parameters to be applied 1194 to the content by intermediate caches. 1196 Property: ignore-query-string 1198 Description: Allows a cache to ignore URI query string 1199 parameters while comparing URIs for equivalence. Matching 1200 against query parameters to ignore MUST be case-insensitive. 1201 Each query parameter to ignore is specified in the list. If 1202 all query parameters should be ignored, then the list MUST be 1203 specified and MUST be empty. 1205 Type: List of String 1207 Mandatory-to-Specify: No. Default is to consider query string 1208 parameters when comparing URIs. 1210 4.2.7. Grouping 1212 A Grouping object identifies a large group of content to which a 1213 given asset belongs. 1215 Property: ccid 1217 Description: Content Collection identifier for an application- 1218 specific purpose such as logging. 1220 Type: String 1222 Mandatory-to-Specify: No. Default is an empty string. 1224 Property: sid 1226 Description: Session identifier for an application-specific 1227 purpose such as logging. 1229 Type: String 1231 Mandatory-to-Specify: No. Default is an empty string. 1233 4.3. CDNI Metadata Simple Data Type Descriptions 1235 This section describes the simple data types that are used for 1236 properties of CDNI Metadata objects. 1238 4.3.1. Link 1240 A link object may be used in place of any of the objects or 1241 properties described above. Links can be used to avoid duplication 1242 if the same metadata information is repeated within the metadata 1243 tree. When a link replaces an object, its href property is set to 1244 the URI of the resource and its type property is set to the type of 1245 the object it is replacing. 1247 Property: href 1249 Description: The URI of the addressable object being 1250 referenced. 1252 Type: URI 1254 Mandatory-to-Specify: Yes 1256 Property: type 1257 Description: The type of the object being referenced. 1259 Type: String 1261 Mandatory-to-Specify: No 1263 4.3.2. Protocol 1265 Protocol objects are used to specify registered protocols for content 1266 acquisition or delivery (see Section 7.2). 1268 Type: String 1270 4.3.3. Endpoint 1272 A hostname (with optional port) or an IP address (with optional 1273 port). 1275 Note: All implementations MUST support IPv4 addresses encoded as 1276 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and 1277 MUST support all IPv6 address formats specified in [RFC4291]. Server 1278 implementations SHOULD use IPv6 address formats specified in 1279 [RFC5952]. 1281 Type: String 1283 4.3.4. URI 1285 A URI as specified in [RFC3986]. 1287 Type: String 1289 4.3.5. Time 1291 A time value expressed in seconds since Unix epoch in the UTC 1292 timezone. 1294 Type: Integer 1296 4.3.6. Auth 1298 An Auth object defines authentication and authorization methods to be 1299 used during content acquisition and content delivery, respectively. 1301 Property: auth-type 1303 Description: Registered Auth type (see Section 4.3.6.1 and 1304 Section 7.3). 1306 Type: String 1308 Mandatory-to-Specify: Yes. 1310 Property: auth-value 1312 Description: An object conforming to the specification 1313 associated with the Registered Auth type. 1315 Type: String 1317 Mandatory-to-Specify: Yes. 1319 4.3.6.1. CredentialAuth Type 1321 CredentialAuth is a Registered Auth type defining an object for 1322 encapsulating user credentials (i.e., username and password) (see 1323 Section 7.3). The CredentialAuth object contains the following 1324 properties: 1326 Property: username 1328 Description: Identification of user. 1330 Type: String 1332 Mandatory-to-Specify: Yes. 1334 Property: password 1336 Description: Password for user identified by username property. 1338 Type: String 1340 Mandatory-to-Specify: Yes. 1342 4.3.7. IPv4CIDR 1344 An IPv4address CIDR block encoded as specified by the 'IPv4address' 1345 rule in Section 3.2.2 of [RFC3986] followed by a / followed by an 1346 unsigned integer representing the leading bits of the routing prefix 1347 (i.e. IPv4 CIDR notation). Single IP addresses can be expressed as 1348 /32. 1350 Type: String 1352 4.3.8. IPv6CIDR 1354 An IPv6address CIDR block encoded in one of the IPv6 address formats 1355 specified in [RFC5952] followed by a / followed by an unsigned 1356 integer representing the leading bits of the routing prefix (i.e. 1357 IPv6 CIDR notation). Single IP addresses can be expressed as /128. 1359 Type: String 1361 4.3.9. ASN 1363 An Autonomous System Number encoded as a string consisting of the 1364 characters AS (in uppercase) followed by the Autonomous System 1365 number. For example "AS64496". 1367 Type: String 1369 4.3.10. CountryCode 1371 An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1373 Type: String 1375 5. CDNI Metadata Capabilities 1377 CDNI Metadata is used to convey information pertaining to content 1378 delivery from uCDN to dCDN. For optional metadata, it may be useful 1379 for the uCDN to know if the dCDN supports the metadata, prior to 1380 delegating any content requests to the dCDN. If optional-to- 1381 implement metadata is "mandatory-to-enforce", and the dCDN does not 1382 support it, any delegated requests for that content will fail. The 1383 uCDN will likely want to avoid delegating those requests to that 1384 dCDN. Likewise, for any metadata which may be assigned optional 1385 values, it may be useful for the uCDN to know which values a dCDN 1386 supports, prior to delegating any content requests to that dCDN. If 1387 the optional value assigned to a given piece of content's metadata is 1388 not supported by the dCDN, any delegated requests for that content 1389 may fail, so again the uCDN is likely to want to avoid delegating 1390 those requests to that dCDN. 1392 The CDNI Footprint and Capabilities Interface (FCI) [RFC7336] 1393 provides a means of advertising capabilities from dCDN to uCDN. 1394 Support for optional metadata and support for optional metadata 1395 values may be advertised using the FCI. 1397 6. CDNI Metadata interface 1399 This section specifies an interface to enable a Downstream CDN to 1400 retrieve CDNI Metadata objects from an Upstream CDN. 1402 The interface can be used by a Downstream CDN to retrieve CDNI 1403 Metadata objects either: 1405 o Dynamically as required by the Downstream CDN to process received 1406 requests. For example in response to a query from an Upstream CDN 1407 over the CDNI Request Routing Redirection interface (RI) 1408 [I-D.ietf-cdni-redirection] or in response to receiving a request 1409 for content from a User Agent. Or; 1411 o In advance of being required. For example in the case of Pre- 1412 positioned CDNI Metadata acquisition. 1414 The CDNI Metadata interface is built on the principles of RESTful web 1415 services. In particular, this means that requests and responses over 1416 the interface are built around the transfer of representations of 1417 hyperlinked resources. A resource in the context of the CDNI 1418 Metadata interface is any object in the Data Model (as described in 1419 Section 3 and Section 4). 1421 To retrieve CDNI metadata, a CDNI Metadata client (i.e., a client in 1422 the dCDN) first makes a HTTP GET request for the URI of the HostIndex 1423 which provides the CDNI Metadata client with a list of Hostnames for 1424 which the upstream CDN may delegate content delivery to the 1425 downstream CDN. The CDNI Metadata client can then obtain any other 1426 CDNI Metadata objects by making a HTTP GET requests for any linked 1427 Metadata objects it requires. 1429 CDNI Metadata servers (i.e., servers in the uCDN) are free to assign 1430 whatever structure they desire to the URIs for CDNI Metadata objects 1431 and CDNI Metadata clients MUST NOT make any assumptions regarding the 1432 structure of CDNI Metadata URIs or the mapping between CDNI Metadata 1433 objects and their associated URIs. Therefore any URIs present in the 1434 examples below are purely illustrative and are not intended to impose 1435 a definitive structure on CDNI Metadata interface implementations. 1437 6.1. Transport 1439 The CDNI Metadata interface uses HTTP as the underlying protocol 1440 transport. 1442 The HTTP Method in the request defines the operation the request 1443 would like to perform. A server implementation of the CDNI Metadata 1444 interface MUST support the HTTP GET and HEAD methods. 1446 The corresponding HTTP Response returns the status of the operation 1447 in the HTTP Status Code and returns the current representation of the 1448 resource (if appropriate) in the Response Body. HTTP Responses from 1449 servers implementing the CDNI Metadata interface that contain a 1450 response body SHOULD include an ETag to enable validation of cached 1451 versions of returned resources. 1453 The CDNI Metadata interface specified in this document is a read-only 1454 interface. Therefore support for other HTTP methods such as PUT, 1455 POST and DELETE etc. is not specified. A server implementation of 1456 the CDNI Metadata interface SHOULD reject all methods other than GET 1457 and HEAD. 1459 As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata 1460 server implementations MAY make use of any HTTP feature when 1461 implementing the CDNI Metadata interface, for example a CDNI Metadata 1462 server MAY make use of HTTP's caching mechanisms to indicate that the 1463 returned response/representation can be reused without re-contacting 1464 the CDNI Metadata server. 1466 6.2. Retrieval of CDNI Metadata resources 1468 In the general case a CDNI Metadata server makes each instance of an 1469 addressable CDNI Metadata object available via a unique URI and 1470 therefore in order to retrieve CDNI Metadata, a CDNI Metadata client 1471 first makes a HTTP GET request for the URI of the HostIndex which 1472 provides the CDNI Metadata client with a list of Hostnames for which 1473 the upstream CDN may delegate content delivery to the downstream CDN. 1475 In order to retrieve the CDNI Metadata for a particular request the 1476 CDNI Metadata client processes the received HostIndex object and 1477 finds the corresponding HostMetadata entry (by matching the hostname 1478 in the request against the hostnames listed in the HostMatch 1479 objects). If the HostMetadata is linked (rather than embedded), the 1480 CDNI metadata client then makes a GET request for the URI specified 1481 in the href property of the Link object which points to the 1482 HostMetadata object itself. 1484 In order to retrieve the most specific metadata for a particular 1485 request, the CDNI metadata client inspects the HostMetadata for 1486 references to more specific PathMetadata objects (by matching the URI 1487 path in the request against the path-patterns in the PathMatch). If 1488 any PathMetadata match the request (and are linked rather than 1489 embedded), the CDNI metadata client makes another GET request for the 1490 PathMetadata. Each PathMetadata object may also include references 1491 to yet more specific metadata. If this is the case, the CDNI 1492 metadata client continues requesting PathMatch and PathMetadata 1493 objects recursively. 1495 In cases where a dCDN is not able to retrieve the entire set of CDNI 1496 metadata associated with a User Agent request, for example because 1497 the uCDN is uncontactable or returns an HTTP 4xx or 5xx status in 1498 response to some or all of the dCDN's CDNI metadata requests, the 1499 dCDN MUST NOT serve the requested content unless the dCDN has stale 1500 versions of all the required metadata and the stale-if-error Cache- 1501 Control extension [RFC5861] was included in all previous responses 1502 that are required but cannot currently be retrieved. The dCDN can 1503 continue to serve other content for which it can retrieve (or for 1504 which it has fresh responses cached) all the required metadata even 1505 if some non-applicable part of the metadata tree is missing. 1507 Where a downstream CDN is interconnected with multiple upstream CDNs, 1508 the downstream CDN needs to determine which upstream CDN's CDNI 1509 metadata should be used to handle a particular User Agent request. 1511 When application level redirection (e.g., HTTP 302 redirects) is 1512 being used between CDNs, it is expected that the downstream CDN will 1513 be able to determine the upstream CDN that redirected a particular 1514 request from information contained in the received request (e.g., via 1515 the URI). With knowledge of which upstream CDN routed the request, 1516 the downstream CDN can choose the correct metadata server from which 1517 to obtain the HostIndex. Note that the HostIndex served by each uCDN 1518 may be unique. 1520 In the case of DNS redirection there is not always sufficient 1521 information carried in the DNS request from User Agents to determine 1522 the upstream CDN that redirected a particular request (e.g., when 1523 content from a given host is redirected to a given downstream CDN by 1524 more than one upstream CDN) and therefore downstream CDNs may have to 1525 apply local policy when deciding which upstream CDN's metadata to 1526 apply. 1528 6.3. Bootstrapping 1530 The URI for the HostIndex object of a given upstream CDN needs to be 1531 either configured in, or discovered by, the downstream CDN. All 1532 other objects/resources are then discoverable from the HostIndex 1533 object by following the links in the HostIndex object and the 1534 referenced HostMetadata and PathMetadata objects. 1536 If the URI for the HostIndex object is not manually configured in the 1537 downstream CDN then the HostIndex URI could be discovered. A 1538 mechanism allowing the downstream CDN to discover the URI of the 1539 HostIndex is outside the scope of this document. 1541 6.4. Encoding 1543 Objects are resources that may be: 1545 o Addressable, where the object is a resource that may be retrieved 1546 or referenced via its own URI. 1548 o Embedded, where the object is contained within a property of an 1549 addressable object. 1551 The descriptions of objects use the phrase "X contains Y" to mean 1552 that Y is either directly embedded in X or is linked to by X. It is 1553 generally a deployment choice for the uCDN implementation to decide 1554 when and which CDNI Metadata objects to embed and which are made 1555 separately addressable. 1557 6.4.1. MIME Media Types 1559 All MIME media types for CDNI Metadata objects are prefixed with 1560 "application/cdni.". The MIME media type for each object then 1561 contains the object name of that object as defined by this document. 1562 The object type name is followed by ".v" and the version number of 1563 the object type (e.g., ".v1"). Finally, the encoding type "+json" is 1564 appended. Table 3 lists the MIME media type for the metadata objects 1565 (resources) that are specified in this document. 1567 +-----------------------+-------------------------------------------+ 1568 | Data Object | MIME Media Type | 1569 +-----------------------+-------------------------------------------+ 1570 | HostIndex | application/cdni.HostIndex.v1+json | 1571 | HostMatch | application/cdni.HostMatch.v1+json | 1572 | HostMetadata | application/cdni.HostMetadata.v1+json | 1573 | PathMatch | application/cdni.PathMatch.v1+json | 1574 | PatternMatch | application/cdni.PatternMatch.v1+json | 1575 | PathMetadata | application/cdni.PathMetadata.v1+json | 1576 | GenericMetadata | application/cdni.GenericMetadata.v1+json | 1577 | SourceMetadata | application/cdni.SourceMetadata.v1+json | 1578 | Source | application/cdni.Source.v1+json | 1579 | LocationACL | application/cdni.LocationACL.v1+json | 1580 | LocationRule | application/cdni.LocationRule.v1+json | 1581 | Footprint | application/cdni.Footprint.v1+json | 1582 | TimeWindowACL | application/cdni.TimeWindowACL.v1+json | 1583 | TimeWindowRule | application/cdni.TimeWindowRule.v1+json | 1584 | TimeWindow | application/cdni.TineWindow.v1+json | 1585 | ProtocolACL | application/cdni.ProtocolACL.v1+json | 1586 | ProtocolRule | application/cdni.ProtocolRule.v1+json | 1587 | DeliveryAuthorization | application/ | 1588 | | cdni.DeliveryAuthorization.v1+json | 1589 | Cache | application/cdni.Cache.v1+json | 1590 | Grouping | application/cdni.Grouping.v1+json | 1591 | Auth | application/cdni.Auth.v1+json | 1592 | CredentialsAuth | application/cdni.CredentialAuth.v1+json | 1593 +-----------------------+-------------------------------------------+ 1595 Table 3: MIME Media Types for CDNI Metadata objects 1597 6.4.2. JSON Encoding of Objects 1599 A CDNI Metadata object is encoded as a JSON object containing a 1600 dictionary of (key,value) pairs where the keys are the property names 1601 and the values are the associated property values. 1603 The keys of the dictionary are the names of the properties associated 1604 with the object and are therefore dependent on the specific object 1605 being encoded (i.e., dependent on the MIME Media Type of the returned 1606 resource). Likewise, the values associated with each key are 1607 dependent on the specific object being encoded (i.e., dependent on 1608 the MIME Media Type of the returned resource). 1610 Dictionary keys in JSON are case sensitive. By convention any 1611 dictionary key defined by this document (for example the names of 1612 CDNI Metadata object properties) MUST be represented in lowercase. 1614 In addition to the properties specified for each object type, the 1615 keys defined below may be present in any object. 1617 Key: base 1619 Description: Provides a prefix for any relative URLs in the 1620 object. This is similar to the XML base tag [XML-BASE]. If 1621 absent, all URLs in the remainder of the response MUST be 1622 absolute URLs. 1624 Type: URI 1626 Mandatory: No 1628 Key: _links 1630 Description: The links from this object to other addressable 1631 objects. Any property whose value is an object may be replaced 1632 by a link to an object with the same type as the property it 1633 replaces. The keys of the _links dictionary are the names of 1634 the properties being replaced. The values of the dictionary 1635 are Link objects with href set to the URI of the object and 1636 type set to the MIME media type of the object being replaced. 1638 Type: Dictionary object of Link objects 1640 Mandatory: Yes 1642 6.4.2.1. Encoded CDNI Metadata Example 1644 A downstream CDN may request the HostIndex and receive the following 1645 object of type "application/cdni.HostIndex.v1+json": 1647 { 1648 "hosts": [ 1649 { 1650 "host": "video.example.com", 1651 "_links": { 1652 "host-metadata" : { 1653 "type": "application/cdni.HostMetadata.v1+json", 1654 "href": "http://metadata.ucdn.example/host1234" 1655 } 1656 } 1657 }, 1658 { 1659 "host": "images.example.com", 1660 "_links": { 1661 "host-metadata" : { 1662 "type": "application/cdni.HostMetadata.v1+json", 1663 "href": "http://metadata.ucdn.example/host5678" 1664 } 1665 } 1666 } 1667 ] 1668 } 1670 If the incoming request has a Host header with "video.example.com" 1671 then the downstream CDN would fetch the next metadata object from 1672 "http://metadata.ucdn.example/host1234" expecting a MIME media type 1673 of "application/cdni.HostMetadata.v1+json": 1675 { 1676 "metadata": [ 1677 { 1678 "generic-metadata-type": 1679 "application/cdni.SourceMetadata.v1+json", 1680 "generic-metadata-value": { 1681 "sources": [ 1682 { 1683 "_links": { 1684 "acquisition-auth": { 1685 "auth-type": "application/cdni.Auth.v1+json", 1686 "href": "http://metadata.ucdn.example/auth1234" 1687 } 1688 }, 1689 "endpoint": "acq1.ucdn.example", 1690 "protocol": "ftp" 1691 }, 1692 { 1693 "_links": { 1694 "acquisition-auth": { 1695 "auth-type": "application/cdni.Auth.v1+json", 1696 "href": "http://metadata.ucdn.example/auth1234" 1697 } 1698 }, 1699 "endpoint": "acq2.ucdn.example", 1700 "protocol": "http" 1701 } 1702 ] 1703 } 1704 }, 1705 { 1706 "generic-metadata-type": 1707 "application/cdni.LocationACL.v1+json", 1708 "generic-metadata-value": { 1709 "locations": [ 1710 { 1711 "footprints": [ 1712 { 1713 "footprint-type": "IPv4CIDR", 1714 "footprint-value": "192.0.2.0/24" 1715 } 1716 ], 1717 "action": "deny" 1718 } 1719 ] 1720 } 1721 }, 1722 { 1723 "generic-metadata-type": 1724 "application/cdni.ProtocolACL.v1+json", 1725 "generic-metadata-value": { 1726 "protocol-acl": [ 1727 { 1728 "protocols": [ 1729 "ftp" 1730 ], 1731 "action": "deny" 1732 } 1733 ] 1734 } 1735 } 1736 ], 1737 "paths": [ 1738 { 1739 "path-pattern": { 1740 "pattern": "/video/trailers/*" 1741 }, 1742 "_links": { 1743 "path-metadata": { 1744 "type": "application/cdni.PathMetadata.v1+json", 1745 "href": "http://metadata.ucdn.example/host1234/pathABC" 1746 } 1747 } 1748 }, 1749 { 1750 "path-pattern": { 1751 "pattern": "/video/movies/*" 1752 }, 1753 "_links": { 1754 "path-metadata": { 1755 "type": "application/cdni.PathMetadata.v1+json", 1756 "href": "http://metadata.ucdn.example/host1234/pathDCE" 1757 } 1758 } 1759 } 1760 ] 1761 } 1763 Suppose the path of the requested resource matches the "/video/ 1764 movies/*" pattern, the next metadata requested would be for 1765 "http://metadata.ucdn.example/host1234/movies" with an expected type 1766 of "application/cdni.PathMetadata.v1+json": 1768 { 1769 "metadata": [], 1770 "paths": [ 1771 { 1772 "path-pattern": { 1773 "pattern": "/videos/movies/hd/*" 1774 }, 1775 "_links": { 1776 "pathmetadata": { 1777 "type": "application/cdni.PathMetadata.v1+json", 1778 "href": 1779 "http://metadata.ucdn.example/host1234/pathABC/path123" 1780 } 1781 } 1782 } 1783 ] 1784 } 1786 Finally, if the path of the requested resource also matches the 1787 "/videos/movies/hd/*" pattern, the downstream CDN would also fetch 1788 the following object from 1789 "http://metadata.ucdn.example/host1234/movies/hd" with MIME media 1790 type "application/cdni.PathMetadata.v1+json": 1792 { 1793 "metadata": [ 1794 { 1795 "generic-metadata-type": 1796 "application/cdni.TimeWindowACL.v1+json", 1797 "generic-metadata-value": { 1798 "times": [ 1799 "windows": [ 1800 { 1801 "start": "1213948800", 1802 "end": "1327393200" 1803 } 1804 ], 1805 "action": "allow" 1806 ] 1807 } 1808 } 1809 ] 1810 } 1812 6.5. Extensibility 1814 The set of property Metadata may be extended with additional 1815 (standards based or vendor specific) property Metadata through the 1816 specification of new GenericMetadata objects. The GenericMetadata 1817 object defined in Section 4.1.7 specifies a type field and a type- 1818 specific value field that allows any Metadata property to be included 1819 in either the HostMetadata or PathMetadata lists. 1821 As with the initial GenericMetadata types defined in Section 4.2, 1822 future GenericMetadata types MUST specify the information necessary 1823 for constructing and decoding the GenericMetadata object. This 1824 information includes the list of properties contained within the 1825 GenericMetadata object, and for each property, the specification 1826 should include a description, a type, and whether or not the given 1827 property is mandatory-to-specify. 1829 Any document which defines a new GenericMetadata type has to: 1831 1. Specify the MIME Media Type used to identify the new 1832 GenericMetadata type being specified. 1834 2. Define the set of properties associated with the new type. 1836 3. For each property, define a name, description, type, and whether 1837 or not the property is mandatory-to-specify. 1839 4. Describe the semantics of the new type including its purpose and 1840 example of a use case to which it applies. 1842 Note: Identification, within the type name defined for a property 1843 Metadata object, of the organization that defined the extension 1844 property Metadata decreases the possibility of property Metadata type 1845 collisions. 1847 6.6. Metadata Enforcement 1849 At any given time, the set of GenericMetadata types supported by the 1850 uCDN may not match the set of GenericMetadata types supported by the 1851 dCDN. 1853 In the cases where a uCDN sends Metadata containing a GenericMetadata 1854 type that a dCDN does not support, the dCDN MUST enforce the 1855 semantics of the "mandatory-to-enforce" property. If a dCDN does not 1856 understand or is unable to perform the functions associated with any 1857 "mandatory-to-enforce" Metadata, the dCDN MUST NOT service any 1858 requests for the corresponding content. 1860 Note: Ideally, uCDNs would not delegate content requests to a dCDN 1861 which does not support the "mandatory-to-enforce" Metadata associated 1862 with the content being requested. However, even if the uCDN has a 1863 priori knowledge of the Metadata supported by the dCDN (e.g., via the 1864 CDNI capabilities interface or through out-of-band negotiation 1865 between CDN operators) Metadata support may fluctuate or be 1866 inconsistent (e.g., due to mis-communication, mis-configuration, or 1867 temporary outage). Thus, the dCDN MUST always evaluate all Metadata 1868 associated with content requests and reject any requests where 1869 "mandatory-to-enforce" Metadata associated with the content cannot be 1870 enforced. 1872 6.7. Metadata Conflicts 1874 It is possible that new Metadata definitions may obsolete or conflict 1875 with existing property Metadata (e.g., a future revision of the CDNI 1876 Metadata interface may redefine the Auth Metadata or a custom vendor 1877 extension may implement an alternate Auth Metadata option). If 1878 multiple Metadata (e.g., cdni.Auth.v2, vendor1.Auth, and 1879 vendor2.Auth) all conflict with an existing Metadata (e.g., 1880 cdni.Auth) and all are marked as "mandatory-to-enforce", it may be 1881 ambiguous which Metadata should be applied, especially if the 1882 functionality of the Metadata overlap. 1884 As described in Section 3.3, Metadata override only applies to 1885 Metadata objects of the same exact type, found in HostMetadata and 1886 nested PathMetadata structures. The CDNI Metadata interface does not 1887 support enforcement of dependencies between different Metadata types. 1888 It is the responsibility of the CSP and the CDN operators to ensure 1889 that Metadata assigned to a given content do not conflict. 1891 Note: Because Metadata is inherently ordered in GenericMetadata 1892 lists, as well as in the PathMetadata hierarchy and PathMatch lists, 1893 multiple conflicting Metadata types MAY be used, however, Metadata 1894 hierarchies MUST ensure that independent PathMatch root objects are 1895 used to prevent ambiguous or conflicting Metadata definitions. 1897 6.8. Versioning 1899 The version of CDNI Metadata Structural objects is conveyed inside 1900 the MIME media type that is included in the HTTP Content-Type header. 1901 Upon responding to a request for an object, a metadata server MUST 1902 include a Content-Type header with the MIME media type containing the 1903 version number of the object. HTTP requests sent to a metadata 1904 server SHOULD include an Accept header with the MIME media type 1905 (which includes the version) of the expected object. Metadata 1906 clients can specify multiple MIME media types in the Accept header, 1907 for example if a metadata client is capable of processing two 1908 different versions of the same type of object (defined by different 1909 MIME media types) it may decide to include both in the Accept header. 1910 The version of each object defined by this document is version 1. 1911 For example: "Content-Type: application/cdni.HostIndex.v1+json". 1913 GenericMetadata objects include a "type" property which specifies the 1914 MIME media type of the GenericMetadata value. This MIME media type 1915 should also include a version. Any document which defines a new type 1916 of GenericMetadata MUST specify the version number which it 1917 describes. For example: "application/cdni.Location.v1+json". 1919 7. IANA Considerations 1921 This document requests the registration of the following MIME Media 1922 Type under the IANA MIME Media Type registry 1923 (http://www.iana.org/assignments/media-types/index.html). 1925 application/cdni.HostIndex.v1+json 1927 application/cdni.HostMatch.v1+json 1929 application/cdni.HostMetadata.v1+json 1931 application/cdni.PathMatch.v1+json 1933 application/cdni.PatternMatch.v1+json 1934 application/cdni.PathMetadata.v1+json 1936 application/cdni.GenericMetadata.v1+json 1938 application/cdni.SourceMetadata.v1+json 1940 application/cdni.Source.v1+json 1942 application/cdni.LocationACL.v1+json 1944 application/cdni.LocationRule.v1+json 1946 application/cdni.Footprint.v1+json 1948 application/cdni.TimeWindowACL.v1+json 1950 application/cdni.TimeWindowRule.v1+json 1952 application/cdni.TimeWindow.v1+json 1954 application/cdni.ProtocolACL.v1+json 1956 application/cdni.ProtocolRule.v1+json 1958 application/cdni.DeliveryAuthorization.v1+json 1960 application/cdni.Cache.v1+json 1962 application/cdni.Grouping.v1+json 1964 application/cdni.Auth.v1+json 1966 application/cdni.CredentialsAuth.v1+json 1968 7.1. CDNI Metadata Footprint Types Registry 1970 The IANA is requested to create a new "CDNI Metadata Footprint Types" 1971 registry. The "CDNI Metadata Footprint Types" namespace defines the 1972 valid Footprint object type values used by the Footprint object in 1973 Section 4.2.2.2. Additions to the Footprint type namespace conform 1974 to the "Expert Review" policy as defined in [RFC5226]. The expert 1975 reviewer should verify that new type definitions do not duplicate 1976 existing type definitions and prevent gratuitous additions to the 1977 namespace. 1979 The following table defines the initial Footprint Registry values: 1981 +----------------+-------------------------------+---------------+ 1982 | Footprint Type | Description | Specification | 1983 +----------------+-------------------------------+---------------+ 1984 | IPv4CIDR | IPv4 CIDR address block | RFCthis | 1985 | IPv6CIDR | IPv6 CIDR address block | RFCthis | 1986 | ASN | Autonomous System (AS) Number | RFCthis | 1987 | CountryCode | ISO 3166-1 alpha-2 code | RFCthis | 1988 +----------------+-------------------------------+---------------+ 1990 7.2. CDNI Metadata Protocol Types Registry 1992 The IANA is requested to create a new "CDNI Metadata Protocol Types" 1993 registry. The "CDNI Metadata Protocol Types" namespace defines the 1994 valid Protocol object values in Section 4.3.2, used by the 1995 SourceMetadata and ProtocolACL objects. Additions to the Protocol 1996 namespace conform to the "Expert Review" policy as defined in 1997 [RFC5226]. The expert review should verify that new protocol 1998 definitions do not duplicate existing protocol definitions and 1999 prevent gratuitous additions to the namespace. 2001 The following table defines the initial Protocol values: 2003 +--------------+------------------------------------+---------------+ 2004 | Protocol | Description | Specification | 2005 | Type | | | 2006 +--------------+------------------------------------+---------------+ 2007 | HTTP1.1 | Hypertext Transfer Protocol -- | RFC7230 | 2008 | | HTTP/1.1 | | 2009 | HTTPS1.1 | HTTP/1.1 Over TLS | RFC2818 | 2010 +--------------+------------------------------------+---------------+ 2012 7.3. CDNI Metadata Auth Types Registry 2014 The IANA is requested to create a new "CDNI Metadata Auth Types" 2015 registry. The "CDNI Metadata Auth Type" namespace defines the valid 2016 Auth object types used by the Auth object in Section 4.3.6. 2017 Additions to the Auth Type namespace conform to the "Expert Review" 2018 policy as defined in [RFC5226]. The expert review should verify that 2019 new type definitions do not duplicate existing type definitions and 2020 prevent gratuitous additions to the namespace. 2022 The following table defines the initial Auth type values: 2024 +----------------+----------------------------------+---------------+ 2025 | Auth Type | Description | Specification | 2026 +----------------+----------------------------------+---------------+ 2027 | CredentialAuth | Simple username and password | RFCthis | 2028 | | authentication. | | 2029 +----------------+----------------------------------+---------------+ 2031 8. Security Considerations 2033 8.1. Authentication 2035 Unauthorized access to metadata could result in denial of service. A 2036 malicious metadata server, proxy server or an attacker performing a 2037 "man in the middle" attack" could provide metadata to a dCDN that 2038 denies service for one or more pieces of content to one or more user 2039 agents. A malicious metadata server (or an attacker performing a 2040 "Man in the middle" attack") could modify metadata so that dCDNs are 2041 directed to contact to malicious origin servers instead of the actual 2042 origin servers. A malicious metadata client could continuously issue 2043 large metadata requests to overload a uCDN's metadata server(s). 2045 Unauthorized access to metadata could result in denial of service. A 2046 malicious metadata server, proxy server or an attacker performing a 2047 "man in the middle" attack could provide metadata to a dCDN that 2048 either: 2050 o Denies service for one or more pieces of content to one or more 2051 User Agents; or 2053 o Directs dCDNs to contact malicious origin servers instead of the 2054 actual origin servers. 2056 Unauthorized access to metadata could also enable a malicious 2057 metadata client to continuously issue large metadata requests in 2058 order to overload a uCDN's metadata server(s). 2060 Unauthorized access to metadata could result in leakage of private 2061 information. A malicious metadata client could request metadata in 2062 order to gain access to origin servers, as well as information 2063 pertaining to content restrictions. 2065 An implementation of the CDNI Metadata interface SHOULD use mutual 2066 authentication to prevent unauthorized access to metadata. 2068 8.2. Confidentiality 2070 Unauthorized viewing of metadata could result in leakage of private 2071 information. A third party could intercept metadata transactions in 2072 order to gain access to origin servers, as well as information 2073 pertaining to content restrictions. 2075 An implementation of the CDNI Metadata interface SHOULD use strong 2076 encryption to prevent unauthorized viewing of metadata. 2078 8.3. Integrity 2080 Unauthorized modification of metadata could result in denial of 2081 service. A malicious metadata server, proxy server or an attacker 2082 performing a "man in the middle" attack" could modify metadata 2083 destined to a dCDN in order to deny service for one or more pieces of 2084 content to one or more user agents. A malicious metadata server, 2085 proxy server or an attacker performing a "Man in the middle" attack" 2086 could modify metadata so that dCDNs are directed to contact to 2087 malicious origin servers instead of the actual origin servers. 2089 An implementation of the CDNI Metadata interface SHOULD use strong 2090 encryption and mutual authentication to prevent unauthorized 2091 modification of metadata. 2093 8.4. Privacy 2095 Content provider origin and policy information is conveyed through 2096 the CDNI Metadata interface. The distribution of this information to 2097 another CDN may introduce potential privacy concerns for some content 2098 providers, for example because dCDNs accepting content requests for a 2099 content provider's content may be able to obtain additional 2100 information & usage patterns relating to the users of a content 2101 provider's services. Content providers with such concerns can 2102 instruct their CDN partners not to use CDN interconnects when 2103 delivering that content provider's content. 2105 8.5. Securing the CDNI Metadata interface 2107 An implementation of the CDNI Metadata interface MUST support TLS 2108 transport as per [RFC2818] and [RFC7230]. The use of TLS for 2109 transport of the CDNI Metadata interface messages allows: 2111 o The dCDN and uCDN to authenticate each other (to ensure they are 2112 transmitting/receiving CDNI Metadata requests & responses from an 2113 authenticated CDN). 2115 o CDNI Metadata interface requests and responses to be transmitted 2116 with confidentiality. 2118 o The integrity of the CDNI Metadata interface requests and 2119 responses to be protected during the exchange. 2121 In an environment where any such protection is required, TLS SHOULD 2122 be used (including authentication of the remote end) by the server- 2123 side (uCDN) and the client-side (dCDN) of the CDNI Metadata interface 2124 unless alternate methods are used for ensuring the confidentiality of 2125 the information in the CDNI Metadata interface requests and responses 2126 (such as setting up an IPsec tunnel between the two CDNs or using a 2127 physically secured internal network between two CDNs that are owned 2128 by the same corporate entity). 2130 An implementation of the CDNI Metadata interface MUST support the 2131 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ([RFC5288]). An 2132 implementation of the CDNI Metadata interface SHOULD prefer cipher 2133 suites which support perfect forward secrecy over cipher suites that 2134 don't. 2136 9. Acknowledgements 2138 The authors would like to thank David Ferguson and Francois Le 2139 Faucheur for their valuable comments and input to this document. 2141 10. Contributing Authors 2143 [RFC Editor Note: Please move the contents of this section to the 2144 Authors' Addresses section prior to publication as an RFC.] 2146 Grant Watson 2147 Velocix (Alcatel-Lucent) 2148 3 Ely Road 2149 Milton, Cambridge CB24 6AA 2150 UK 2152 Email: gwatson@velocix.com 2154 Kent Leung 2155 Cisco Systems 2156 3625 Cisco Way 2157 San Jose, 95134 2158 USA 2160 Email: kleung@cisco.com 2162 11. References 2164 11.1. Normative References 2166 [ISO3166-1] 2167 "https://www.iso.org/obp/ui/#search", . 2169 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2170 Requirement Levels", BCP 14, RFC 2119, March 1997. 2172 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2173 Architecture", RFC 4291, February 2006. 2175 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2176 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2177 May 2008. 2179 [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois 2180 Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, 2181 August 2008. 2183 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 2184 Content", RFC 5861, May 2010. 2186 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2187 Address Text Representation", RFC 5952, August 2010. 2189 11.2. Informative References 2191 [I-D.ietf-cdni-redirection] 2192 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 2193 Redirection Interface for CDN Interconnection", draft- 2194 ietf-cdni-redirection-08 (work in progress), February 2195 2015. 2197 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2199 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2200 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2201 3986, January 2005. 2203 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2204 Distribution Network Interconnection (CDNI) Problem 2205 Statement", RFC 6707, September 2012. 2207 [RFC7230] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol 2208 (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2209 2014. 2211 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, 2212 "Framework for Content Distribution Network 2213 Interconnection (CDNI)", RFC 7336, August 2014. 2215 [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network 2216 Interconnection (CDNI) Requirements", RFC 7337, August 2217 2014. 2219 [XML-BASE] 2220 Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second 2221 Edition) - http://www.w3.org/TR/xmlbase/", January 2009. 2223 Authors' Addresses 2225 Ben Niven-Jenkins 2226 Velocix (Alcatel-Lucent) 2227 3 Ely Road 2228 Milton, Cambridge CB24 6AA 2229 UK 2231 Email: ben@velocix.com 2233 Rob Murray 2234 Velocix (Alcatel-Lucent) 2235 3 Ely Road 2236 Milton, Cambridge CB24 6AA 2237 UK 2239 Email: rmurray@velocix.com 2241 Matt Caulfield 2242 Cisco Systems 2243 1414 Massachusetts Avenue 2244 Boxborough, MA 01719 2245 USA 2247 Phone: +1 978 936 9307 2248 Email: mcaulfie@cisco.com 2249 Kevin J. Ma 2250 Ericsson 2251 43 Nagog Park 2252 Acton, MA 01720 2253 USA 2255 Phone: +1 978-844-5100 2256 Email: kevin.j.ma@ericsson.com