idnits 2.17.1 draft-ietf-cdni-metadata-08.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 27, 2014) is 3469 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) == Unused Reference: 'RFC2617' is defined on line 2117, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-04 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft R. Murray 4 Intended status: Standards Track Velocix (Alcatel-Lucent) 5 Expires: April 30, 2015 M. Caulfield 6 Cisco Systems 7 K. Ma 8 Ericsson 9 October 27, 2014 11 CDN Interconnection Metadata 12 draft-ietf-cdni-metadata-08 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 April 30, 2015. 47 Copyright Notice 49 Copyright (c) 2014 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 . . . . . . . . . . . . . 4 67 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5 68 3. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . 6 69 3.1. HostIndex, HostMetadata and PathMetadata objects . . . . 7 70 3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 11 71 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13 72 4. Encoding-Independent CDNI Metadata Object Descriptions . . . 14 73 4.1. Descriptions of the CDNI Structural Metadata Objects . . 15 74 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15 75 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 15 76 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 16 77 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 16 78 4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 17 79 4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . 17 80 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 18 81 4.2. Description of the CDNI Generic Metadata Objects . . . . 19 82 4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 19 83 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 20 84 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 21 85 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 21 86 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 22 87 4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 22 88 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 23 89 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 23 90 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 24 91 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 24 92 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 25 93 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 25 94 4.2.7. Grouping . . . . . . . . . . . . . . . . . . . . . . 26 96 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 26 97 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 26 98 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 27 99 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 27 100 4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 27 101 4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 27 102 4.4. Auth . . . . . . . . . . . . . . . . . . . . . . . . . . 27 103 4.4.1. CredentialAuth Type . . . . . . . . . . . . . . . . . 28 104 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 28 105 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 29 106 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 30 107 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 30 108 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 31 109 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 32 110 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 32 111 6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 32 112 6.4.2.1. Encoded CDNI Metadata Example . . . . . . . . . . 33 113 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 37 114 6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 37 115 6.5.2. Metadata Conflicts . . . . . . . . . . . . . . . . . 38 116 6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 38 117 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 118 7.1. GenericMetadata Type Registry . . . . . . . . . . . . . . 40 119 7.1.1. GenericMetadata Sub-Registries . . . . . . . . . . . 41 120 7.1.1.1. Footprint Sub-Registry . . . . . . . . . . . . . 42 121 7.1.1.2. Protocol Sub-Registry . . . . . . . . . . . . . . 42 122 7.1.1.3. Authentication Type Sub-Registry . . . . . . . . 43 123 8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 124 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 44 125 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 44 126 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 44 127 8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 45 128 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 129 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 45 130 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 131 11.1. Normative References . . . . . . . . . . . . . . . . . . 46 132 11.2. Informative References . . . . . . . . . . . . . . . . . 46 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 47 135 1. Introduction 137 Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables 138 a downstream CDN to service content requests on behalf of an upstream 139 CDN. 141 The CDNI Metadata interface is discussed in [I-D.ietf-cdni-framework] 142 along with four other interfaces that may be used to compose a CDNI 143 solution (CDNI Control interface, CDNI Request Routing Redirection 144 interface, CDNI Footprint & Capabilities Advertisement interface and 145 CDNI Logging interface). [I-D.ietf-cdni-framework] describes each 146 interface, and the relationships between them. The requirements for 147 the CDNI metadata interface are specified in 148 [I-D.ietf-cdni-requirements]. 150 The CDNI metadata associated with a piece of content (or with a set 151 of content) provides a downstream CDN with sufficient information for 152 servicing content requests on behalf of an upstream CDN in accordance 153 with the policies defined by the upstream CDN. 155 This document focuses on the CDNI Metadata interface which enables a 156 downstream CDN to obtain CDNI Metadata from an upstream CDN so that 157 the downstream CDN can properly process and respond to: 159 o Redirection requests received over the CDNI Request Routing 160 Redirection interface. 162 o Content requests received directly from User Agents. 164 Specifically, this document specifies: 166 o A data structure for mapping content requests and redirection 167 requests to CDNI Metadata objects (Section 3 and Section 4.1). 169 o An initial set of CDNI Generic Metadata objects (Section 4.2). 171 o A RESTful web service for the transfer of CDNI Metadata 172 (Section 6). 174 1.1. Terminology 176 This document reuses the terminology defined in [RFC6707]. 178 Additionally, the following terms are used throughout this document 179 and are defined as follows: 181 o Object - a collection of properties 183 o Property - a key and value pair where the key is a property name 184 and the value is the property value or an object. 186 1.2. Supported Metadata Capabilities 188 Only the metadata for a small set of initial capabilities is 189 specified in this document. This set provides the minimum amount of 190 metadata for basic CDN interoperability while still meeting the 191 requirements set forth by [I-D.ietf-cdni-requirements]. 193 The following high-level functionality is configured via the metadata 194 described in Section 4: 196 o Acquisition Source: Metadata for allowing a dCDN to fetch content 197 from a uCDN. 199 o Delivery Access Control: Metadata for restricting (or permitting) 200 access to content based on any of the following factors: 202 * Location 204 * Time Window 206 * Delivery Protocol 208 o Delivery Authorization: Metadata for authorizing dCDN user agent 209 requests. 211 o Cache Control: Metadata for controlling cache behavior of the 212 dCDN. 214 The metadata encoding described by this document is extensible in 215 order to allow for future additions to this list. 217 This document supports HTTPv1.1 for delivery and both HTTPv1.1 and 218 HTTPv1.1. over TLS for acquisition. All metadata is described in a 219 protocol-agnostic manner. 221 Supporting unencrypted HTTPv2.0 for delivery (or unencrypted HTTPv2.0 222 or HTTPv2.0 over TLS for acquisition) only requires the registration 223 of these protocol names in the CDNI Metadata Protocol Sub-Registry. 225 Supporting HTTPv1.1 over TLS or HTTPv2.0 over TLS for delivery 226 requires specifying additional metadata objects to carry the 227 properties required to establish a TLS session, for example metadata 228 to describe the certificate to use as part of the TLS handshake. 230 2. Design Principles 232 The CDNI Metadata interface was designed to achieve the following 233 objectives: 235 1. Cacheability of CDNI metadata objects. 237 2. Deterministic mapping from redirection requests and content 238 requests to CDNI metadata properties. 240 3. Support for DNS redirection as well as application-specific 241 redirection (for example HTTP redirection). 243 4. Minimal duplication of CDNI metadata. 245 5. Leveraging of existing protocols. 247 Cacheability improves the latency of acquiring metadata while 248 maintaining its freshness, and therefore improves the latency of 249 serving content requests and redirection requests, without 250 sacrificing accuracy. The CDNI Metadata interface uses HTTP and its 251 existing caching mechanisms to achieve CDNI metadata cacheability. 253 Deterministic mappings from content to metadata properties eliminates 254 ambiguity and ensures that policies are applied consistently by all 255 downstream CDNs. 257 Support for both HTTP and DNS redirection ensures that the CDNI 258 Metadata interface can be used for HTTP and DNS redirection and also 259 meets the same design principles for both HTTP and DNS based 260 redirection schemes. 262 Minimal duplication of CDNI metadata provides space efficiency on 263 storage in the CDNs, on caches in the network, and across the network 264 between CDNs. 266 Leveraging existing protocols avoids reinventing common mechanisms 267 such as data structure encoding (e.g., JSON) and data transport 268 (e.g., HTTP). 270 3. CDNI Metadata Data Model 272 The CDNI Metadata Model describes a data structure for mapping 273 redirection requests and content requests to metadata properties. 274 Metadata properties describe how to acquire content from an upstream 275 CDN, authorize access to content, and deliver content from a 276 downstream CDN. The data model relies on the assumption that these 277 metadata properties may be aggregated based on the hostname of the 278 content and subsequently on the resource path of the content. The 279 data model associates a set of CDNI Metadata properties with a 280 Hostname to form a default set of metadata properties for content 281 delivered on behalf of that Hostname. That default set of metadata 282 properties can be overridden by properties that apply to specific 283 paths within a URI. 285 Different Hostnames and URI paths will be associated with different 286 sets of CDNI Metadata properties in order to describe the required 287 behaviour when a dCDN surrogate is processing User Agent requests for 288 content at that Hostname or URI path. As a result of this structure, 289 significant commonality may exist between the CDNI Metadata 290 properties specified for different Hostnames, different URI paths 291 within a Hostname and different URI paths on different Hostnames. 292 For example the definition of which User Agent IP addresses should be 293 treated as being grouped together into a single network or geographic 294 location is likely to be common for a number of different Hostnames. 295 Another example is that although a uCDN is likely to have several 296 different policies configured to express geo-blocking rules, it is 297 likely that a single geo-blocking policy would be applied to multiple 298 Hostnames delivered through the CDN. 300 In order to enable the CDNI Metadata for a given Hostname or URI Path 301 to be decomposed into sets of CDNI Metadata properties that can be 302 reused by multiple Hostnames and URI Paths, the CDNI Metadata 303 interface specified in this document splits the CDNI Metadata into a 304 number of objects. Efficiency is improved by enabling a single CDNI 305 Metadata object (that is shared across Hostname and/or URI paths) to 306 be retrieved and stored by a dCDN once, even if it is referenced by 307 the CDNI Metadata of multiple Hostnames or of multiple URI paths. 309 Section 3.1 introduces a high level description of the HostIndex, 310 HostMetadata and PathMetadata objects and describes the relationships 311 between those objects. 313 Section 3.2 introduces a high level description of the CDNI 314 GenericMetadata object which represents the level at which CDNI 315 Metadata override occurs between HostMetadata and PathMetadata 316 objects. 318 Section 4 describes in detail the specific CDNI Metadata objects and 319 properties which may be contained within a CDNI GenericMetadata 320 object. 322 3.1. HostIndex, HostMetadata and PathMetadata objects 324 A HostIndex object contains (or references) a list of Hostnames (and/ 325 or IP addresses) for which content requests may be delegated to the 326 downstream CDN. The HostIndex is the starting point for accessing 327 the uCDN CDNI Metadata data store. It enables the dCDN to 328 deterministically discover, on receipt of a User Agent request for 329 content, which other CDNI Metadata objects it requires in order to 330 deliver the requested content. 332 The HostIndex links Hostnames (and/or IP addresses) to HostMetadata 333 objects via HostMatch objects. HostMetadata objects contain (or 334 reference) the default CDNI Metadata required to serve content for 335 that host. When looking up CDNI Metadata, the downstream CDN looks 336 up the requested Hostname (or IP address) against the HostMatch 337 entries in the HostIndex, from there it can find HostMetadata which 338 describes properties for a host and PathMetadata which may override 339 those properties for given URI paths within the host. 341 HostMetadata and PathMetadata objects may also contain PathMatch 342 objects which in turn contain PathMetadata objects. PathMetadata 343 objects override the CDNI Metadata in the HostMetadata object or one 344 or more preceding PathMetadata objects with more specific CDNI 345 Metadata that applies to content requests matching the pattern 346 defined in that PathMatch object. 348 For the purposes of retrieving CDNI Metadata, all other required CDNI 349 Metadata objects and their properties are discoverable from the 350 appropriate HostMetadata, PathMatch and PathMetadata objects for the 351 requested content. 353 The relationships between the HostIndex, HostMatch, HostMetadata, 354 PathMatch and PathMetadata objects are described in Figure 1. 356 +---------+ +---------+ +------------+ 357 |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ 358 +---------+ +---------+ +------+-----+ | 359 | | 360 (*) | 361 | V 362 --> Contains or References V ****************** 363 (1) One and only one +---------+ *Generic Metadata* 364 (*) Zero or more +--->|PathMatch| * Objects * 365 | +----+---++ ****************** 366 | | | ^ 367 (*) (1) (1) +------------+ | 368 | | +->|PatternMatch| | 369 | V +------------+ | 370 | +------------+ | 371 +--+PathMetadata+-------(*)------+ 372 +------------+ 374 Figure 1: Relationships between CDNI Metadata Objects (Diagram 375 Representation) 377 The relationships in Figure 1 are also represented in tabular format 378 in Table 1 below. 380 +--------------+----------------------------------------------------+ 381 | Data Object | Objects it contains or references | 382 +--------------+----------------------------------------------------+ 383 | HostIndex | 0 or more HostMatch objects. | 384 | HostMatch | 1 HostMetadata object. | 385 | HostMetadata | 0 or more PathMatch objects. 0 or more | 386 | | GenericMetadata objects. | 387 | PathMatch | 1 PatternMatch object. 1 PathMetadata object. | 388 | PatternMatch | Does not contain or reference any other objects. | 389 | PathMetadata | 0 or more PathMatch objects. 0 or more | 390 | | GenericMetadata objects. | 391 +--------------+----------------------------------------------------+ 393 Table 1: Relationships between CDNI Metadata Objects 394 (Table Representation) 396 The table below describes the HostIndex, HostMetadata and 397 PathMetadata objects in more detail. 399 +-----------------+-------------------------------------------------+ 400 | Data Object | Description | 401 +-----------------+-------------------------------------------------+ 402 | HostIndex | A HostIndex object lists HostMatch objects | 403 | HostMatch | A HostMatch object defines a hostname (or IP | 404 | | address) to match against a requested host, and | 405 | | contains (or references) a HostMetadata object | 406 | | which contains (or references) CDNI Metadata | 407 | | objects to be applied when a request matches | 408 | | against the hostname. For example, if | 409 | | "example.com" is a content provider, a | 410 | | HostMatch object may include an entry for | 411 | | "example.com" with the URI of the associated | 412 | | HostMetadata object. | 413 | HostMetadata | A HostMetadata object contains (or references) | 414 | | the default CDNI Metadata objects for content | 415 | | served from that host, i.e., the CDNI Metadata | 416 | | objects for content requests that do not match | 417 | | any of the PathMatch objects contained (or | 418 | | referenced) by that HostMetadata object. For | 419 | | example, a HostMetadata object may describe the | 420 | | metadata properties which apply to | 421 | | "example.com" and may contain PathMatches for | 422 | | "example.com/movies/*" and | 423 | | "example.com/music/*" which reference | 424 | | corresponding PathMetadata objects that contain | 425 | | the CDNI Metadata objects for those more | 426 | | specific URI paths. | 427 | PathMatch | A PathMatch object defines a pattern (inside a | 428 | | PatternMatch object which PathMatch object | 429 | | contains or references) to match against the | 430 | | requested URI path, and contains (or | 431 | | references) a PathMetadata object which | 432 | | contains (or references) the CDNI Metadata | 433 | | objects to be applied when a content request | 434 | | matches against the defined URI path pattern. | 435 | | For example, a PathMatch object may include a | 436 | | PatternMatch object containing a pattern for | 437 | | the path "/movies/*" and may reference a | 438 | | PathMetadata object which contains (or | 439 | | references) the CDNI Metadata for content with | 440 | | that path. | 441 | PatternMatch | A PatternMatch object contains the pattern | 442 | | string and flags that describe the URI path | 443 | | that a PathMatch applies to. | 444 | PathMetadata | A PathMetadata object contains (or references) | 445 | | the CDNI GenericMetadata objects for content | 446 | | served with the associated URI path (defined in | 447 | | a PathMatch object). A PathMetadata object may | 448 | | also contain (or reference) PathMatch objects | 449 | | in order to recursively define more specific | 450 | | URI paths that require different (e.g., more | 451 | | specific) CDNI Metadata to this one. For | 452 | | example, the PathMetadata object which applies | 453 | | to "example.com/movies/*" may describe CDNI | 454 | | Metadata which apply to that resource path and | 455 | | may contain a PathMatch object for | 456 | | "example.com/movies/hd/*" which would reference | 457 | | the corresponding PathMetadata object for the | 458 | | "example.com/movies/hd/" path prefix. | 459 | GenericMetadata | A GenericMetadata object contains (or | 460 | | references) individual CDNI Metadata objects | 461 | | which define the specific policies and | 462 | | attributes needed to properly deliver the | 463 | | associated content. For example, a | 464 | | GenericMetadata object may describe the source | 465 | | from which a CDN may acquire a piece of | 466 | | content. The GenericMetadata object is an | 467 | | atomic unit that may be referenced by | 468 | | HostMetadata and/or PathMetadata objects, but | 469 | | SHOULD NOT contain references to other CDNI | 470 | | Metadata objects. The member objects of a | 471 | | specific CDNI Metadata object MAY be referenced | 472 | | by the GenericMetadata object. | 473 +-----------------+-------------------------------------------------+ 474 Table 2: HostIndex, HostMetadata and PathMetadata CDNI Metadata 475 Objects 477 3.2. Generic CDNI Metadata Object Properties 479 The HostMetadata and PathMetadata objects contain or can reference 480 other CDNI Metadata objects that contain properties which describe 481 how User Agent requests for content should be processed, for example 482 where to acquire the content, authorization rules that should be 483 applied, delivery location restrictions and so on. Each such CDNI 484 Metadata object is a specialization of a CDNI GenericMetadata object. 485 The GenericMetadata object abstracts the basic information required 486 for Metadata override and Metadata distribution, from the specifics 487 of any given property (e.g., property semantics, enforcement options, 488 etc.). 490 The GenericMetadata object defines the type of properties contained 491 within it as well as whether or not the properties are "mandatory-to- 492 enforce". If the dCDN does not understand or support the property 493 type and the property type is "mandatory-to-enforce", the dCDN MUST 494 NOT serve the content to the User Agent. If the dCDN does not 495 understand or support the property type and the property type is not 496 "mandatory-to-enforce", then that GenericMetadata object may be 497 safely ignored and the dCDN MUST process the content request in 498 accordance with the rest of the CDNI metadata. 500 Although a CDN MUST NOT serve content to a User Agent if a 501 "mandatory-to-enforce" property cannot be enforced, it may be "safe- 502 to-redistribute" that metadata to another CDN without modification. 503 For example, in the cascaded CDN case, a transit CDN may pass through 504 "mandatory-to-enforce" metadata to a downstream CDN. For Metadata 505 which does not require customization or translation (i.e., metadata 506 that is "safe-to-redistribute"), the data representation received off 507 the wire MAY be stored and redistributed without being natively 508 understood or supported by the transit CDN. However, for Metadata 509 which requires translation, transparent redistribution of the uCDN 510 Metadata values may not be appropriate. Certain Metadata may be 511 safely, though possibly not optimally, redistributed unmodified. For 512 example, source acquisition address may not be optimal if 513 transparently redistributed, but may still work. 515 Redistribution safety MUST be specified for each GenericMetadata. If 516 a CDN does not understand or support a given GenericMetadata property 517 type and the property type is not "safe-to-redistribute", before 518 redistributing the metadata, the CDN MUST set the "incomprehensible" 519 flag for the GenericMetadata property that it did not understand and 520 was marked as not "safe-to-redistribute". The "incomprehensible" 521 flag signals to a dCDN that the metadata was not properly transformed 522 by the transit CDN. A CDN MUST NOT attempt to use metadata that has 523 been marked as "incomprehensible" by a uCDN. 525 Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or 526 "safe-to-redistribute" when propagating metadata to a dCDN. Although 527 a transit CDN may set the value of "incomprehensible" to true, a 528 transit CDN MUST NOT change the value of "incomprehensible" from true 529 to false. 531 The following table describes the action to be taken by a transit CDN 532 (tCDN) for the different "mandatory-to-enforce" (MtE) and "safe-to- 533 redistribute" (StR) cases, when the tCDN either does or does not 534 understand the metadata in question: 536 +-------+-------+------------+--------------------------------------+ 537 | MtE | StR | Metadata | Actions | 538 | | | Understood | | 539 +-------+-------+------------+--------------------------------------+ 540 | False | True | True | Can serve and redistribute. | 541 | False | True | False | Can serve and redistribute. | 542 | False | False | False | Can serve. MUST set | 543 | | | | "incomprehensible" to True when | 544 | | | | redistributing. | 545 | False | False | True | Can serve. Can redistribute either | 546 | | | | by transforming not StR metadata (if | 547 | | | | the CDN know how to do so safely), | 548 | | | | otherwise MUST set | 549 | | | | "incomprehensible" to True when | 550 | | | | redistributing. | 551 | True | True | True | Can serve and redistribute. | 552 | True | True | False | MUST NOT serve but can redistribute. | 553 | True | False | True | Can serve and redistribute. | 554 | True | False | False | MUST NOT serve. MUST set | 555 | | | | "incomprehensible" to True when | 556 | | | | redistributing. | 557 +-------+-------+------------+--------------------------------------+ 559 The following table describes the action to be taken by a dCDN for 560 the different "mandatory-to-enforce" (MtE) and "incomprehensible" 561 (Incomp) cases, when the dCDN either does or does not understand the 562 metadata in question: 564 +-------+------------+--------+-------------------------------------+ 565 | MtE | Metadata | Incomp | Actions | 566 | | Understood | | | 567 +-------+------------+--------+-------------------------------------+ 568 | False | True | False | Can serve. | 569 | False | True | True | Can serve but MUST NOT | 570 | | | | interpret/apply any metadata marked | 571 | | | | incomprehensible. | 572 | False | False | False | Can serve. | 573 | False | False | True | Can serve but MUST NOT | 574 | | | | interpret/apply any metadata marked | 575 | | | | incomprehensible. | 576 | True | True | False | Can serve. | 577 | True | True | True | Can serve but MUST NOT | 578 | | | | interpret/apply any metadata marked | 579 | | | | incomprehensible. | 580 | True | False | False | MUST NOT serve. | 581 | True | False | True | MUST NOT serve. | 582 +-------+------------+--------+-------------------------------------+ 584 3.3. Metadata Inheritance and Override 586 In the data model, a HostMetadata object may contain (or reference) 587 multiple PathMetadata objects (via PathMatch objects). Each 588 PathMetadata object may in turn contain (or reference) other 589 PathMetadata objects. HostMetadata and PathMetadata objects form an 590 inheritance tree where each node in the tree inherits or overrides 591 the property values set by its parent. 593 GenericMetadata objects of a given type override all GenericMetadata 594 objects of the same type previously defined by any parent object in 595 the tree. GenericMetadata objects of a given type previously defined 596 by a parent object in the tree are inherited when no object of the 597 same type is defined by the child object. For example, if 598 HostMetadata for the host "example.com" contains GenericMetadata 599 objects of type LocationACL and TimeWindowACL, while a PathMetadata 600 object which applies to "example.com/movies/*" defines an alternate 601 GenericMetadata object of type TimeWindowACL, then: 603 o the TimeWindowACL defined in the PathMetadata would override the 604 TimeWindowACL defined in the HostMetadata for all User Agent 605 requests for content under "example.com/movies", and 607 o the LocationACL defined in the HostMetadata would be inherited for 608 all User Agent requests for content under "example.com/movies". 610 o A single HostMetadata or PathMetadata object SHOULD NOT contain 611 multiple GenericMetadata objects of the same type. If a list of 612 GenericMetadata contains objects of duplicate types, the receiver 613 MUST ignore all but the first object of each type. 615 4. Encoding-Independent CDNI Metadata Object Descriptions 617 Section 4.1 provides the definitions of each object type declared in 618 Section 3. These objects are described as structural objects as they 619 provide the structure for the inheritance tree and identify which 620 specific properties apply to a given User Agent content request. 622 Section 4.2 provides the definitions for a base set of core metadata 623 objects which may be contained within a GenericMetadata object. 624 These objects are described as property objects, as they define the 625 structure, semantics, and enforcement options for specific properties 626 of the metadata being described. Property objects govern how User 627 Agent requests for content are handled. Property objects may be 628 composed of, or contain references to, other property sub-objects 629 (i.e., property objects contained within or referenced by the 630 property object that refers to that property sub-object). In those 631 cases the value of the property sub-objects can be either a complete 632 serialized representation of the sub-object, or a Link object that 633 contains a URI and relationship that can be dereferenced to retrieve 634 the complete serialized representation of the property sub-object. 636 Section 6.5 discusses the ability to extend the base set of metadata 637 objects specified in this document with additional standards based or 638 vendor specific property objects that may be defined in the future in 639 separate documents. 641 Downstream CDNs MUST support parsing of all CDNI metadata objects 642 specified in this document. A dCDN does not have to implement the 643 underlying functionality represented by the metadata object, though 644 that may restrict the content that a given dCDN can serve. uCDNs as 645 generators of CDNI Metadata only need to support generating the CDNI 646 metadata that they need in order to express the policies and 647 treatment required by the content they are describing. 649 Note: In the following sections, the term "mandatory-to-specify" is 650 used to convey which property sub-objects MUST be specified for a 651 given structural or property object. When mandatory-to-specify is 652 set to true on a sub-object, it implies that if the property object 653 containing that property sub-object is specified, then the mandatory- 654 to-specify property sub-object MUST also be specified, e.g., a 655 HostMatch property object without a host to match against does not 656 make sense, therefore, the host is mandatory-to-specify inside a 657 HostMatch property object. 659 4.1. Descriptions of the CDNI Structural Metadata Objects 661 Each of the sub-sections below describe the structural objects 662 defined in Table 2. 664 4.1.1. HostIndex 666 The HostIndex object is the entry point into the CDNI Metadata 667 hierarchy. It contains (or references) a list of HostMatch objects. 668 An incoming content request is checked against the hostname (or IP 669 address) specified by each of the listed HostMatch objects to find 670 the HostMatch object which applies to the request. 672 Property: hosts 674 Description: List of HostMatch objects, in priority order. 676 Type: List of HostMatch objects 678 Mandatory-to-Specify: Yes. 680 4.1.2. HostMatch 682 The HostMatch object contains a hostname or IP address to match 683 against content requests. The HostMatch object also contains or 684 references a HostMetadata object to apply if a match is found. 686 Property: host 688 Description: String (hostname or IP address) to match against 689 the requested host. 691 Type: String 693 Mandatory-to-Specify: Yes. 695 Property: host-metadata 697 Description: CDNI Metadata to apply when delivering content 698 that matches this host. 700 Type: HostMetadata 702 Mandatory-to-Specify: Yes. 704 4.1.3. HostMetadata 706 A HostMetadata object contains (or references) the CDNI Metadata 707 properties for content served for a particular host (defined in the 708 HostMatch object) and possibly child PathMatch objects. 710 Property: metadata 712 Description: List of host related metadata. 714 Type: List of GenericMetadata objects 716 Mandatory-to-Specify: Yes. 718 Property: paths 720 Description: Path specific rules. Path patterns (PathMatch 721 objects) MUST be evaluated in the order they appear and the 722 first PathMatch object that matches the content request being 723 process is applied. 725 Type: List of PathMatch objects 727 Mandatory-to-Specify: No. 729 4.1.4. PathMatch 731 The PathMatch object contains (or references) an expression given as 732 a PatternMatch object to match against a resource URI path and 733 contains or references a PathMetadata object to apply if a match is 734 found. 736 Property: path-pattern 738 Description: Pattern to match against the requested path, i.e., 739 against the [RFC3986] path-absolute. 741 Type: PatternMatch 743 Mandatory-to-Specify: Yes. 745 Property: path-metadata 747 Description: CDNI Metadata to apply when delivering content 748 that matches this path. 750 Type: PathMetadata 751 Mandatory-to-Specify: Yes. 753 4.1.5. PathMetadata 755 A PathMetadata object contains (or references) the CDNI Metadata 756 properties for content served with the associated URI path (defined 757 in a PathMatch object) and possibly child PathMatch objects. 759 Note that if DNS-based redirection is employed, then any metadata at 760 the PathMetadata level or below will be inaccessible at request 761 routing time because only the content request hostname is available 762 at request routing time. 764 Property: metadata 766 Description: List of path related metadata. 768 Type: List of GenericMetadata objects 770 Mandatory-to-Specify: Yes. 772 Property: paths 774 Description: Path specific rules. First match applies. 776 Type: List of PathMatch objects 778 Mandatory-to-Specify: No. 780 4.1.6. PatternMatch 782 A PatternMatch object contains the pattern string and flags that 783 describe the PathMatch expression. 785 Property: pattern 787 Description: A pattern for string matching. The pattern may 788 contain the wildcards * and ?, where * matches any sequence of 789 characters (including the empty string) and ? matches exactly 790 one character. The three literals \ , * and ? should be 791 escaped as \\, \* and \?. All other characters are treated as 792 literals. 794 Type: String 796 Mandatory-to-Specify: Yes. 798 Property: case-sensitive 799 Description: Flag indicating whether or not case-sensitive 800 matching should be used. 802 Type: Boolean 804 Mandatory-to-Specify: No. Default is case-insensitive match. 806 Property: ignore-query-string 808 Description: List of query parameters which should be ignored 809 when searching for a pattern match. If all query parameters 810 should be ignored then the list MUST be empty. 812 Type: List of String 814 Mandatory-to-Specify: No. Default is to include query strings 815 when matching. 817 4.1.7. GenericMetadata 819 A GenericMetadata object is an abstraction for managing individual 820 CDNI Metadata properties in an opaque manner. 822 Property: generic-metadata-type 824 Description: CDNI Metadata property object type. 826 Type: MIME Type String (from Section 7.1) 828 Mandatory-to-Specify: Yes. 830 Property: generic-metadata-value 832 Description: CDNI Metadata property object. 834 Type: Format/Type is defined by the value of generic-metadata- 835 type property above. 837 Mandatory-to-Specify: Yes. 839 Property: mandatory-to-enforce 841 Description: Flag identifying whether or not the enforcement of 842 the property Metadata is required. 844 Type: Boolean 845 Mandatory-to-Specify: No. Default is to treat metadata as 846 mandatory to enforce (i.e., true). 848 Property: safe-to-redistribute 850 Description: Flag identifying whether or not the property 851 Metadata may be safely redistributed without modification. 853 Type: Boolean 855 Mandatory-to-Specify: No. Default is allow transparent 856 redistribution (i.e., true). 858 Property: incomprehensible 860 Description: Flag identifying whether or not any CDN in the 861 chain of delegation has failed to understand and/or failed to 862 properly transform the Metadata. 864 Type: Boolean 866 Mandatory-to-Specify: No. Default is comprehensible (i.e., 867 false). 869 4.2. Description of the CDNI Generic Metadata Objects 871 The property objects defined below are intended to be used in the 872 GenericMetadata object generic-metadata-value field as defined in 873 Section 4.1.7 and their generic-metadata-type property MUST be set to 874 the appropriate Media Type as defined in Section 7.1. 876 4.2.1. Source Metadata 878 Source Metadata provides the dCDN information about content 879 acquisition, i.e., how to contact an uCDN Surrogate or an Origin 880 Server to obtain the content to be served. The sources are not 881 necessarily the actual Origin Servers operated by the CSP but might 882 be a set of Surrogates in the uCDN. 884 Endpoints within a source should be treated as equivalent/equal so 885 one can specify a list of sources in preference order and for each 886 source/preference rank one can specify a list of endpoints that are 887 equivalent, e.g., a pool of servers that are not behind a load 888 balancer. 890 Property: sources 891 Description: Sources from which the dCDN can acquire content, 892 listed in order of preference. 894 Type: List of Source objects 896 Mandatory-to-Specify: No. Default is to use static 897 configuration, out-of-band from the metadata interface. 899 4.2.1.1. Source 901 A Source object describes the Source which should be used by the dCDN 902 for content acquisition, e.g., a Surrogate within the uCDN or an 903 alternate Origin Server, the protocol to be used and any 904 authentication method. 906 Property: acquisition-auth 908 Description: Authentication method to use when requesting 909 content from this source. 911 Type: Auth 913 Mandatory-to-Specify: No. Default is no authentication 914 required. 916 Property: endpoints 918 Description: Origins from which the dCDN can acquire content. 919 If multiple endpoints are specified they are all equal, i.e., 920 the list is not in preference order, for example a pool of 921 servers behind a load balancer. 923 Type: List of EndPoint objects 925 Mandatory-to-Specify: Yes. 927 Property: protocol 929 Description: Network retrieval protocol to use when requesting 930 content from this source. 932 Type: Protocol 934 Mandatory-to-Specify: Yes. 936 4.2.2. LocationACL Metadata 938 LocationACL Metadata defines location-based restrictions. 940 A LocationACL which does not include a locations property results in 941 an action of allow, meaning that delivery can be performed regardless 942 of the User Agent's location. The action from the first footprint to 943 match against the User Agent's location is the action a CDN MUST 944 take. If two or more footprints overlap, the first footprint that 945 matches against the User Agent's location determines the action a CDN 946 MUST take. If the locations property is included but is empty, or if 947 none of the listed footprints matches the User Agent's location, then 948 the result is an action of deny. 950 Although the LocationACL, TimeWindowACL, and ProtocolACL are 951 independent GenericMetadata objects, they may provide conflicting 952 information to a dCDN, e.g., a content request which is 953 simultaneously allowed based on the LocationACL and denied based on 954 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 955 (where 'allow' is true and 'deny' is false) to determine whether or 956 not a request should be allowed. Thus, in the example given, the 957 request should be denied. 959 Property: locations 961 Description: Access control list which allows or blocks 962 delivery based on client location. 964 Type: List of LocationRule objects 966 Mandatory-to-Specify: No. Default is allow all locations. 968 4.2.2.1. LocationRule 970 A LocationRule contains or references a list of Footprint objects and 971 the corresponding action. 973 Property: footprints 975 Description: List of footprints to which the rule applies. 977 Type: List of Footprint objects 979 Mandatory-to-Specify: Yes. 981 Property: action 982 Description: Defines whether the rule specifies locations to 983 allow or deny. 985 Type: Enumeration [allow|deny] 987 Mandatory-to-Specify: No. Default is deny. 989 4.2.2.2. Footprint 991 A Footprint object describes the footprint to which a LocationRule 992 may be applied by, e.g., an IPv4 address range or a geographic 993 location. 995 Property: footprint-type 997 Description: Registered footprint type (see Section 7.1.1.1). 999 Type: String 1001 Mandatory-to-Specify: Yes. 1003 Property: footprint-value 1005 Description: Footprint object conforming to the specification 1006 associated with the registered footprint type. 1008 Type: String 1010 Mandatory-to-Specify: Yes. 1012 4.2.3. TimeWindowACL Metadata 1014 TimeWindowACL Metadata defines time-based restrictions. 1016 A TimeWindowACL which does not include a times property results in an 1017 action of allow, meaning that delivery can be performed regardless of 1018 the time of the User Agent's request. The action from the first 1019 window to match against the current time is the action a CDN MUST 1020 take. If two or more windows overlap, the first window that matches 1021 against the current time determines the action a CDN MUST take. If 1022 the times property is included but is empty, or if none of the listed 1023 windows matches the current time, then the result is an action of 1024 deny. 1026 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1027 independent GenericMetadata objects, they may provide conflicting 1028 information to a dCDN, e.g., a content request which is 1029 simultaneously allowed based on the LocationACL and denied based on 1030 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1031 (where 'allow' is true and 'deny' is false) to determine whether or 1032 not a request should be allowed. Thus, in the example given, the 1033 request should be denied. 1035 Property: times 1037 Description: Description: Access control list which allows or 1038 blocks delivery based on request time. 1040 Type: List of TimeWindowRule objects 1042 Mandatory-to-Specify: No. Default is allow all time windows. 1044 4.2.3.1. TimeWindowRule 1046 A TimeWindowRule contains or references a list of TimeWindow objects 1047 and the corresponding action. 1049 Property: windows 1051 Description: List of time windows to which the rule applies. 1053 Type: List of TimeWindow objects 1055 Mandatory-to-Specify: Yes. 1057 Property: action 1059 Description: Defines whether the rule specifies time windows to 1060 allow or deny. 1062 Type: Enumeration [allow|deny] 1064 Mandatory-to-Specify: No. Default is deny. 1066 4.2.3.2. TimeWindow 1068 A TimeWindow object describes a time range which may be applied by an 1069 TimeWindowACL, e.g., start 946717200 (i.e., 09:00AM 01/01/2000 UTC), 1070 end: 946746000 (i.e., 17:00AM 01/01/2000 UTC). 1072 Property: start 1074 Description: The start time of the window. 1076 Type: Time 1077 Mandatory-to-Specify: Yes. 1079 Property: end 1081 Description: The end time of the window. 1083 Type: Time 1085 Mandatory-to-Specify: Yes. 1087 4.2.4. ProtocolACL Metadata 1089 ProtocolACL Metadata defines delivery protocol restrictions. 1091 A ProtocolACL which does not include a protocol-acl property results 1092 in an action of allow, meaning that delivery can be performed 1093 regardless of the protocol of the User Agent's request. The action 1094 from the first protocol to match against the request protocol is the 1095 action a CDN MUST take. If two or more request protocols overlap, 1096 the first protocol that matches thre request protocol determines the 1097 action a CDN MUST take. If the protocol-acl property is included but 1098 is empty, or if none of the listed protocol matches the request 1099 protocol, then the result is an action of deny. 1101 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1102 independent GenericMetadata objects, they may provide conflicting 1103 information to a dCDN, e.g., a content request which is 1104 simultaneously allowed based on the LocationACL and denied based on 1105 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1106 (where 'allow' is true and 'deny' is false) to determine whether or 1107 not a request should be allowed. Thus, in the example given, the 1108 request should be denied. 1110 Property: protocol-acl 1112 Description: Description: Access control list which allows or 1113 blocks delivery based on delivery protocol. 1115 Type: List of ProtocolRule objects 1117 Mandatory-to-Specify: No. Default is allow all protocols. 1119 4.2.4.1. ProtocolRule 1121 A ProtocolRule contains or references a list of Protocol objects. 1122 ProtocolRule objects are used to construct a ProtocolACL to apply 1123 restrictions to content acquisition or delivery. 1125 Property: protocols 1127 Description: List of protocols to which the rule applies. 1129 Type: List of protocol objects 1131 Mandatory-to-Specify: Yes. 1133 Property: action 1135 Description: Defines whether the rule specifies protocols to 1136 allow or deny. 1138 Type: Enumeration [allow|deny] 1140 Mandatory-to-Specify: No. Default is deny. 1142 4.2.5. DeliveryAuthorization Metadata 1144 Delivery Authorization defines authorization methods for the delivery 1145 of content to User Agents. 1147 Property: delivery-auth-methods 1149 Description: Options for authorizing content requests. 1150 Delivery for a content request is authorized if any of the 1151 authorization method in the list is satisfied for that request. 1153 Type: List of Auth objects 1155 Mandatory-to-Specify: No. Default is no authorization 1156 required. 1158 4.2.6. Cache 1160 A Cache object describes the cache control parameters to be applied 1161 to the content by intermediate caches. 1163 Property: ignore-query-string 1165 Description: Allows a cache to ignore URI query string 1166 parameters while comparing URIs for equivalence. Each query 1167 parameter to ignore is specified in the list. If all query 1168 parameters should be ignored, then the list MUST be specified 1169 and MUST be empty. 1171 Type: List of String 1172 Mandatory-to-Specify: No. Default is to consider query string 1173 parameters when comparing URIs. 1175 4.2.7. Grouping 1177 A Grouping object identifies a large group of content to which a 1178 given asset belongs. 1180 Property: ccid 1182 Description: Content Collection identifier for an application- 1183 specific purpose such as logging. 1185 Type: String 1187 Mandatory-to-Specify: No. Default is an empty string. 1189 Property: sid 1191 Description: Session identifier for an application-specific 1192 purpose such as logging. 1194 Type: String 1196 Mandatory-to-Specify: No. Default is an empty string. 1198 4.3. CDNI Metadata Simple Data Type Descriptions 1200 This section describes the simple data types that are used for 1201 properties of CDNI Metadata objects. 1203 4.3.1. Link 1205 A link object may be used in place of any of the objects or 1206 properties described above. Links can be used to avoid duplication 1207 if the same metadata information is repeated within the metadata 1208 tree. When a link replaces an object, its href property is set to 1209 the URI of the resource and its type property is set to the type of 1210 the object it is replacing. 1212 Property: href 1214 Description: The URI of the addressable object being 1215 referenced. 1217 Type: URI 1219 Mandatory-to-Specify: Yes 1221 Property: type 1223 Description: The type of the object being referenced. 1225 Type: String 1227 Mandatory-to-Specify: No 1229 4.3.2. Protocol 1231 Protocol objects are used to specify registered protocols for content 1232 acquisition or delivery (see Section 7.1.1.2). 1234 Type: String 1236 4.3.3. Endpoint 1238 A hostname (with optional port) or an IP address (with optional 1239 port). 1241 Note: All implementations MUST support IPv4 addresses encoded as 1242 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and 1243 MUST support all IPv6 address formats specified in [RFC4291]. Server 1244 implementations SHOULD use IPv6 address formats specified in 1245 [RFC5952]. 1247 Type: String 1249 4.3.4. URI 1251 A URI as specified in [RFC3986]. 1253 Type: String 1255 4.3.5. Time 1257 A time value expressed in seconds since Unix epoch in the UTC 1258 timezone. 1260 Type: Integer 1262 4.4. Auth 1264 An Auth object defines authentication and authorization methods to be 1265 used during content acquisition and content delivery, respectively. 1267 Property: auth-type 1268 Description: Registered Auth type (see Section 7.1.1.3). 1270 Type: String 1272 Mandatory-to-Specify: Yes. 1274 Property: auth-value 1276 Description: An object conforming to the specification 1277 associated with the Registered Auth type. 1279 Type: String 1281 Mandatory-to-Specify: Yes. 1283 4.4.1. CredentialAuth Type 1285 CredentialAuth is a Registered Auth type defining an object for 1286 encapsulating user credentials (i.e., username and password) (see 1287 Section 7.1.1.3). The CredentialAuth object contains the following 1288 properties: 1290 Property: username 1292 Description: Identification of user. 1294 Type: String 1296 Mandatory-to-Specify: Yes. 1298 Property: password 1300 Description: Password for user identified by username property. 1302 Type: String 1304 Mandatory-to-Specify: Yes. 1306 5. CDNI Metadata Capabilities 1308 CDNI Metadata is used to convey information pertaining to content 1309 delivery from uCDN to dCDN. For optional metadata, it may be useful 1310 for the uCDN to know if the dCDN supports the metadata, prior to 1311 delegating any content requests to the dCDN. If optional-to- 1312 implement metadata is "mandatory-to-enforce", and the dCDN does not 1313 support it, any delegated requests for that content will fail. The 1314 uCDN will likely want to avoid delegating those requests to that 1315 dCDN. Likewise, for any metadata which may be assigned optional 1316 values, it may be useful for the uCDN to know which values a dCDN 1317 supports, prior to delegating any content requests to that dCDN. If 1318 the optional value assigned to a given piece of content's metadata is 1319 not supported by the dCDN, any delegated requests for that content 1320 may fail, so again the uCDN is likely to want to avoid delegating 1321 those requests to that dCDN. 1323 The CDNI Footprint and Capabilities Interface (FCI) 1324 [I-D.ietf-cdni-framework] provides a means of advertising 1325 capabilities from dCDN to uCDN. Support for optional metadata and 1326 support for optional metadata values may be advertised using the FCI. 1328 6. CDNI Metadata interface 1330 This section specifies an interface to enable a Downstream CDN to 1331 retrieve CDNI Metadata objects from an Upstream CDN. 1333 The interface can be used by a Downstream CDN to retrieve CDNI 1334 Metadata objects either 1336 o Dynamically as required by the Downstream CDN to process received 1337 requests. For example in response to a query from an Upstream CDN 1338 over the CDNI Request Routing Redirection interface (RI) 1339 [I-D.ietf-cdni-redirection] or in response to receiving a request 1340 for content from a User Agent. Or; 1342 o In advance of being required. For example in the case of Pre- 1343 positioned CDNI Metadata acquisition. 1345 The CDNI Metadata interface is built on the principles of RESTful web 1346 services. In particular, this means that requests and responses over 1347 the interface are built around the transfer of representations of 1348 hyperlinked resources. A resource in the context of the CDNI 1349 Metadata interface is any object in the Data Model (as described in 1350 Section 3 through Section 4). 1352 To retrieve CDNI metadata, a CDNI Metadata client (i.e., a client in 1353 the dCDN) first makes a HTTP GET request for the URI of the HostIndex 1354 which provides the CDNI Metadata client with a list of Hostnames for 1355 which the upstream CDN may delegate content delivery to the 1356 downstream CDN. The CDNI Metadata client can then obtain any other 1357 CDNI Metadata objects by making a HTTP GET requests for any linked 1358 Metadata objects it requires. 1360 CDNI Metadata servers (i.e., servers in the uCDN) are free to assign 1361 whatever structure they desire to the URIs for CDNI Metadata objects 1362 and CDNI Metadata clients MUST NOT make any assumptions regarding the 1363 structure of CDNI Metadata URIs or the mapping between CDNI Metadata 1364 objects and their associated URIs. Therefore any URIs present in the 1365 examples below are purely illustrative and are not intended to impose 1366 a definitive structure on CDNI Metadata interface implementations. 1368 6.1. Transport 1370 The CDNI Metadata interface uses HTTP as the underlying protocol 1371 transport. 1373 The HTTP Method in the request defines the operation the request 1374 would like to perform. A server implementation of the CDNI Metadata 1375 interface MUST support the HTTP GET and HEAD methods. 1377 The corresponding HTTP Response returns the status of the operation 1378 in the HTTP Status Code and returns the current representation of the 1379 resource (if appropriate) in the Response Body. HTTP Responses from 1380 servers implementing the CDNI Metadata interface that contain a 1381 response body SHOULD include an ETag to enable validation of cached 1382 versions of returned resources. 1384 The CDNI Metadata interface specified in this document is a read-only 1385 interface. Therefore support for other HTTP methods such as PUT, 1386 POST and DELETE etc. is not specified. A server implementation of 1387 the CDNI Metadata interface SHOULD reject all methods other than GET 1388 and HEAD. 1390 As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata 1391 server implementations MAY make use of any HTTP feature when 1392 implementing the CDNI Metadata interface, for example a CDNI Metadata 1393 server MAY make use of HTTP's caching mechanisms to indicate that the 1394 returned response/representation can be reused without re-contacting 1395 the CDNI Metadata server. 1397 6.2. Retrieval of CDNI Metadata resources 1399 In the general case a CDNI Metadata server makes each instance of an 1400 addressable CDNI Metadata object available via a unique URI and 1401 therefore in order to retrieve CDNI Metadata, a CDNI Metadata client 1402 first makes a HTTP GET request for the URI of the HostIndex which 1403 provides the CDNI Metadata client with a list of Hostnames for which 1404 the upstream CDN may delegate content delivery to the downstream CDN. 1406 In order to retrieve the CDNI Metadata for a particular request the 1407 CDNI Metadata client processes the received HostIndex object and 1408 finds the corresponding HostMetadata entry (by matching the hostname 1409 in the request against the hostnames in the HostMatch). If the 1410 HostMetadata is linked (rather than embedded), the CDNI metadata 1411 client then makes a GET request for the URI specified in the href 1412 property of the Link object which points to the HostMetadata object 1413 itself. 1415 In order to retrieve the most specific metadata for a particular 1416 request, the CDNI metadata client inspects the HostMetadata for 1417 references to more specific PathMetadata objects. If any 1418 PathMetadata match the request (and are linked rather than embedded), 1419 the CDNI metadata client makes another GET request for the 1420 PathMetadata. Each PathMetadata object may also include references 1421 to yet more specific metadata. If this is the case, the CDNI 1422 metadata client continues requesting PathMetadata recursively. 1424 Where a downstream CDN is interconnected with multiple upstream CDNs, 1425 the downstream CDN needs to determine which upstream CDN's CDNI 1426 metadata should be used to handle a particular User Agent request. 1428 When application level redirection (e.g., HTTP 302 redirects) is 1429 being used between CDNs, it is expected that the downstream CDN will 1430 be able to determine the upstream CDN that redirected a particular 1431 request from information contained in the received request (e.g., via 1432 the URI). With knowledge of which upstream CDN routed the request, 1433 the downstream CDN can choose the correct metadata server from which 1434 to obtain the HostIndex. Note that the HostIndex served by each uCDN 1435 may be unique. 1437 In the case of DNS redirection there is not always sufficient 1438 information carried in the DNS request from User Agents to determine 1439 the upstream CDN that redirected a particular request (e.g., when 1440 content from a given host is redirected to a given downstream CDN by 1441 more than one upstream CDN) and therefore downstream CDNs may have to 1442 apply local policy when deciding which upstream CDN's metadata to 1443 apply. 1445 6.3. Bootstrapping 1447 The URI for the HostIndex object of a given upstream CDN needs to be 1448 either configured in, or discovered by, the downstream CDN. All 1449 other objects/resources are then discoverable from the HostIndex 1450 object by following the links in the HostIndex object and the 1451 referenced HostMetadata and PathMetadata objects. 1453 If the URI for the HostIndex object is not manually configured in the 1454 downstream CDN then the HostIndex URI could be discovered. A 1455 mechanism allowing the downstream CDN to discover the URI of the 1456 HostIndex is outside the scope of this document. 1458 6.4. Encoding 1460 Objects are resources that may be: 1462 o Addressable, where the object is a resource that may be retrieved 1463 or referenced via its own URI. 1465 o Embedded, where the object is contained within a property of an 1466 addressable object. 1468 The descriptions of objects use the phrase "X contains Y" to mean 1469 that Y is either directly embedded in X or is linked to by X. It is 1470 generally a deployment choice for the uCDN implementation to decide 1471 when and which CDNI Metadata objects to embed and which are made 1472 separately addressable. 1474 6.4.1. MIME Media Types 1476 All MIME types for CDNI Metadata objects are prefixed with 1477 "application/cdni.". The MIME type for each object then contains the 1478 object name of that object as defined by this document. The object 1479 type name is followed by ".v" and the version number of the object 1480 type (e.g., ".v1"). Finally, the encoding type "+json" is appended. 1481 Table 3 3 lists a few examples of the MIME Media Type for some object 1482 (resource) that are retrievable through the CDNI Metadata interface. 1484 +--------------+---------------------------------------+ 1485 | Data Object | MIME Media Type | 1486 +--------------+---------------------------------------+ 1487 | HostIndex | application/cdni.HostIndex.v1+json | 1488 | HostMatch | application/cdni.HostMatch.v1+json | 1489 | HostMetadata | application/cdni.HostMetadata.v1+json | 1490 | PathMatch | application/cdni.PathMatch.v1+json | 1491 | PathMetadata | application/cdni.PathMetadata.v1+json | 1492 | Source | application/cdni.Source.v1+json | 1493 | LocationACL | application/cdni.LocationACL.v1+json | 1494 | LocationRule | application/cdni.LocationRule.v1+json | 1495 +--------------+---------------------------------------+ 1497 Table 3: Example MIME Media Types for CDNI Metadata objects 1499 6.4.2. JSON Encoding of Objects 1501 A CDNI Metadata object is encoded as a JSON object containing a 1502 dictionary of (key,value) pairs where the keys are the property names 1503 and the values are the associated property values. 1505 The keys of the dictionary are the names of the properties associated 1506 with the object and are therefore dependent on the specific object 1507 being encoded (i.e., dependent on the MIME Media Type of the returned 1508 resource). Likewise, the values associated with each key are 1509 dependent on the specific object being encoded (i.e., dependent on 1510 the MIME Media Type of the returned resource). 1512 Dictionary keys in JSON are case sensitive. By convention any 1513 dictionary key defined by this document (for example the names of 1514 CDNI Metadata object properties) MUST be represented in lowercase. 1516 In addition to the properties specified for each object type, the 1517 keys defined below may be present in any object. 1519 Key: base 1521 Description: Provides a prefix for any relative URLs in the 1522 object. This is similar to the XML base tag [XML-BASE]. If 1523 absent, all URLs in the remainder of the response MUST be 1524 absolute URLs. 1526 Type: URI 1528 Mandatory: No 1530 Key: _links 1532 Description: The links from this object to other addressable 1533 objects. Any property whose value is an object may be replaced 1534 by a link to an object with the same type as the property it 1535 replaces. The keys of the _links dictionary are the names of 1536 the properties being replaced. The values of the dictionary 1537 are Link objects with href set to the URI of the object and 1538 type set to the MIME type of the object being replaced. 1540 Type: Dictionary object of Link objects 1542 Mandatory: Yes 1544 6.4.2.1. Encoded CDNI Metadata Example 1546 A downstream CDN may request the HostIndex and receive the following 1547 object of type "application/cdni.HostIndex.v1+json": 1549 { 1550 "hosts": [ 1551 { 1552 "host": "video.example.com", 1553 "_links": { 1554 "host-metadata" : { 1555 "type": "application/cdni.HostMetadata.v1+json", 1556 "href": "http://metadata.ucdn.example/host1234" 1557 } 1558 } 1559 }, 1560 { 1561 "host": "images.example.com", 1562 "_links": { 1563 "host-metadata" : { 1564 "type": "application/cdni.HostMetadata.v1+json", 1565 "href": "http://metadata.ucdn.example/host5678" 1566 } 1567 } 1568 } 1569 ] 1570 } 1572 If the incoming request has a Host header with "video.example.com" 1573 then the downstream CDN would fetch the next metadata object from 1574 "http://metadata.ucdn.example/host1234" expecting a MIME type of 1575 "application/cdni.HostMetadata.v1+json": 1577 { 1578 "metadata": [ 1579 { 1580 "generic-metadata-type": "application/cdni.SourceMetadata.v1+json", 1581 "generic-metadata-value": { 1582 "sources": [ 1583 { 1584 "_links": { 1585 "acquisition-auth": { 1586 "auth-type": "application/cdni.Auth.v1+json", 1587 "href": "http://metadata.ucdn.example/auth1234" 1588 } 1589 }, 1590 "endpoint": "acq1.ucdn.example", 1591 "protocol": "ftp" 1592 }, 1593 { 1594 "_links": { 1595 "acquisition-auth": { 1596 "auth-type": "application/cdni.Auth.v1+json", 1597 "href": "http://metadata.ucdn.example/auth1234" 1598 } 1599 }, 1600 "endpoint": "acq2.ucdn.example", 1601 "protocol": "http" 1602 } 1603 ] 1604 } 1605 }, 1606 { 1607 "generic-metadata-type": "application/cdni.LocationACL.v1+json", 1608 "generic-metadata-value": { 1609 "locations": [ 1610 { 1611 "footprints": [ 1612 { 1613 "footprint-type": "IPv4CIDR", 1614 "footprint-value": "192.168.0.0/16" 1615 } 1616 ], 1617 "action": "deny" 1618 } 1619 ] 1620 } 1621 }, 1622 { 1623 "generic-metadata-type": "application/cdni.ProtocolACL.v1+json", 1624 "generic-metadata-value": { 1625 "protocol-acl": [ 1626 { 1627 "protocols": [ 1628 "ftp" 1629 ], 1630 "action": "deny" 1631 } 1632 ] 1633 } 1634 } 1635 ], 1636 "paths": [ 1637 { 1638 "path-pattern": { 1639 "pattern": "/video/trailers/*" 1640 }, 1641 "_links": { 1642 "path-metadata": { 1643 "type": "application/cdni.PathMetadata.v1+json", 1644 "href": "http://metadata.ucdn.example/host1234/pathABC" 1646 } 1647 } 1648 }, 1649 { 1650 "path-pattern": { 1651 "pattern": "/video/movies/*" 1652 }, 1653 "_links": { 1654 "path-metadata": { 1655 "type": "application/cdni.PathMetadata.v1+json", 1656 "href": "http://metadata.ucdn.example/host1234/pathDCE" 1657 } 1658 } 1659 } 1660 ] 1661 } 1663 Suppose the path of the requested resource matches the "/video/ 1664 movies/*" pattern, the next metadata requested would be for 1665 "http://metadata.ucdn.example/host1234/pathDCE" with an expected type 1666 of "application/cdni.PathMetadata.v1+json": 1668 { 1669 "metadata": [], 1670 "paths": [ 1671 { 1672 "path-pattern": { 1673 "pattern": "/videos/movies/hd/*" 1674 }, 1675 "_links": { 1676 "pathmetadata": { 1677 "type": "application/cdni.PathMetadata.v1+json", 1678 "href": 1679 "http://metadata.ucdn.example/host1234/pathABC/path123" 1680 } 1681 } 1682 } 1683 ] 1684 } 1686 Finally, if the path of the requested resource also matches the 1687 "/videos/movies/hd/*" pattern, the downstream CDN would also fetch 1688 the following object from 1689 "http://metadata.ucdn.example/host1234/movies/hd" with MIME type 1690 "application/cdni.PathMetadata.v1+json": 1692 { 1693 "metadata": [ 1694 { 1695 "generic-metadata-type": "application/cdni.TimeWindowACL.v1+json", 1696 "generic-metadata-value": { 1697 "times": [ 1698 "windows": [ 1699 { 1700 "start": "1213948800", 1701 "end": "1327393200" 1702 } 1703 ], 1704 "action": "allow" 1705 ] 1706 } 1707 } 1708 ] 1709 } 1711 6.5. Extensibility 1713 The set of property Metadata may be extended with additional 1714 (standards based or vendor specific) property Metadata. The 1715 GenericMetadata object defined in Section 4.1.7 allows any Metadata 1716 property to be included in either the HostMetadata or PathMetadata 1717 lists. It is expected that additional property Metadata will be 1718 defined in the future and that the documents defining those property 1719 Metadata will be registered in the CDNI GenericMetadata Types 1720 registry Section 7.1. 1722 Note: Identification, within the type name defined for a property 1723 Metadata object, of the organization that defined the extension 1724 property Metadata decreases the possibility of property Metadata type 1725 collisions. 1727 6.5.1. Metadata Enforcement 1729 At any given time, the set of GenericMetadata types supported by the 1730 uCDN may not match the set of GenericMetadata types supported by the 1731 dCDN. 1733 In the cases where a uCDN sends Metadata containing a GenericMetadata 1734 type that a dCDN does not support, the dCDN MUST enforce the 1735 semantics of the "mandatory-to-enforce" property. If a dCDN does not 1736 understand or is unable to perform the functions associated with any 1737 "mandatory-to-enforce" Metadata, the dCDN MUST NOT service any 1738 requests for the corresponding content. 1740 Note: Ideally, uCDNs would not delegate content requests to a dCDN 1741 which does not support the "mandatory-to-enforce" Metadata associated 1742 with the content being requested. However, even if the uCDN has a 1743 priori knowledge of the Metadata supported by the dCDN (e.g., via the 1744 CDNI capabilities interface or through out-of-band negotiation 1745 between CDN operators) Metadata support may fluctuate or be 1746 inconsistent (e.g., due to mis-communication, mis-configuration, or 1747 temporary outage). Thus, the dCDN MUST always evaluate all Metadata 1748 associated with content requests and reject any requests where 1749 "mandatory-to-enforce" Metadata associated with the content cannot be 1750 enforced. 1752 6.5.2. Metadata Conflicts 1754 It is possible that new Metadata definitions may obsolete or conflict 1755 with existing property Metadata (e.g., a future revision of the CDNI 1756 Metadata interface may redefine the Auth Metadata or a custom vendor 1757 extension may implement an alternate Auth Metadata option). If 1758 multiple Metadata (e.g., cdni.Auth.v2, vendor1.Auth, and 1759 vendor2.Auth) all conflict with an existing Metadata (e.g., 1760 cdni.Auth) and all are marked as "mandatory-to-enforce", it may be 1761 ambiguous which Metadata should be applied, especially if the 1762 functionality of the Metadata overlap. 1764 As described in Section 3.3, Metadata override only applies to 1765 Metadata objects of the same exact type, found in HostMetadata and 1766 nested PathMetadata structures. The CDNI Metadata interface does not 1767 support enforcement of dependencies between different Metadata types. 1768 It is the responsibility of the CSP and the CDN operators to ensure 1769 that Metadata assigned to a given content do not conflict. 1771 Note: Because Metadata is inherently ordered in GenericMetadata 1772 lists, as well as in the PathMetadata hierarchy and PathMatch lists, 1773 multiple conflicting Metadata types MAY be used, however, Metadata 1774 hierarchies MUST ensure that independent PathMatch root objects are 1775 used to prevent ambiguous or conflicting Metadata definitions. 1777 6.6. Versioning 1779 The version of CDNI Metadata Structural objects is conveyed inside 1780 the MIME-Type that is included in the HTTP Content-Type header. Upon 1781 responding to a request for an object, a metadata server MUST include 1782 a Content-Type header with the MIME-type containing the version 1783 number of the object. HTTP requests sent to a metadata server SHOULD 1784 include an Accept header with the MIME-type (which includes the 1785 version) of the expected object. Metadata clients can specify 1786 multiple MIME-types in the Accept header, for example if a metadata 1787 client is capable of processing two different versions of the same 1788 type of object (defined by different MIME-types) it may decide to 1789 include both in the Accept header. The version of each object 1790 defined by this document is version 1. For example: "Content-Type: 1791 application/cdni.HostIndex.v1+json". 1793 GenericMetadata objects include a "type" property which specifies the 1794 MIME-type of the GenericMetadata value. This MIME-type should also 1795 include a version. Any document which defines a new type of 1796 GenericMetadata MUST specify the version number which it describes. 1797 For example: "application/cdni.Location.v1+json". 1799 7. IANA Considerations 1801 This document requests the registration of the following MIME Media 1802 Type under the IANA MIME Media Type registry 1803 (http://www.iana.org/assignments/media-types/index.html). 1805 application/cdni.HostIndex.v1 1807 application/cdni.HostMetadata.v1 1809 application/cdni.PathMatch.v1 1811 application/cdni.PathMetadata.v1 1813 application/cdni.PatternMatch.v1 1815 application/cdni.GenericMetadata.v1 1817 application/cdni.SourceMetadata.v1 1819 application/cdni.Source.v1 1821 application/cdni.LocationACL.v1 1823 application/cdni.LocationRule.v1 1825 application/cdni.Footprint.v1 1827 application/cdni.TimeWindowACL.v1 1829 application/cdni.TimeWindowRule.v1 1831 application/cdni.TimeWindow.v1 1833 application/cdni.ProtocolACL.v1 1835 application/cdni.ProtocolRule.v1 1836 application/cdni.Authorization.v1 1838 application/cdni.Auth.v1 1840 application/cdni.CredentialsAuth.v1 1842 application/cdni.Cache.v1 1844 application/cdni.Grouping.v1 1846 7.1. GenericMetadata Type Registry 1848 CDNI Metadata is distributed as a list of GenericMetadata objects 1849 which specify a type field and a type-specific value field, as 1850 described in Section 4.1.7. In order to prevent namespace collisions 1851 for GenericMetadata object types a new IANA registry is requested for 1852 the "CDNI GenericMetadata Types" namespace. The namespace shall be 1853 split into two partitions: standard and optional. 1855 The standard namespace partition is intended to contain mandatory-to- 1856 implement capabilities and conforms to the "IETF Review" policy as 1857 defined in [RFC5226]. The registry contains the generic metadata 1858 type name, the RFC number of the specification defining the metadata 1859 type, the version number of the GenericMetadata set to which the 1860 standard capability applies, and boolean values indicating whether or 1861 not the new type is considered "mandatory-to-enforce" or "safe-to- 1862 redistribute" (as defined in Section 4.1.7). 1864 The following table defines the initial values for the standard 1865 partition: 1867 +------------------------------+-------------+--------+------+------+ 1868 | Type name | Specificati | Versio | MTE | STR | 1869 | | on | n | | | 1870 +------------------------------+-------------+--------+------+------+ 1871 | application/cdni.SourceMetad | RFCthis | 1 | true | true | 1872 | ata.v1 | | | | | 1873 | application/cdni.LocationACL | RFCthis | 1 | true | true | 1874 | .v1 | | | | | 1875 | application/cdni.TimeWindowA | RFCthis | 1 | true | true | 1876 | CL.v1 | | | | | 1877 | application/cdni.ProtocolACL | RFCthis | 1 | true | true | 1878 | .v1 | | | | | 1879 | application/cdni.Auth.v1 | RFCthis | 1 | true | true | 1880 | application/cdni.Cache.v1 | RFCthis | 1 | true | true | 1881 | application/cdni.Grouping.v1 | RFCthis | 1 | true | true | 1882 +------------------------------+-------------+--------+------+------+ 1883 The initial MI version number is set to 1. All of the initial 1884 GenericMetadata types are considered mandatory-to-implement for 1885 version 1. The version field should be incremented when new 1886 GenericMetadata type sets are added to the registry. 1888 The "optional" namespace partition conforms to the "Expert Review" 1889 policy as defined in [RFC5226]. The expert review is intended to 1890 prevent namespace hoarding and to prevent the definition of redundant 1891 GenericMetadata types. Vendors defining new GenericMetadata types 1892 which conflict with existing GenericMetadata types follow the 1893 guidelines for the "Specification Required" policy as defined in 1894 [RFC5226]. The Version field in the registry is set to "-1" 1895 (negative one) for non-standard GenericMetadata types. 1897 As with the initial GenericMetadata types defined in Section 4.2, 1898 future GenericMetadata type registrations will specify the 1899 information necessary for constructing and decoding the 1900 GenericMetadata object. This information includes the list of 1901 properties contained within the GenericMetadata object, and for each 1902 property, the specification should include a description, a type, and 1903 whether or not the given property is mandatory-to-specify. 1905 Any document which defines a new GenericMetadata has to: 1907 1. Allocate a new type in the GenericMetadata Type Registry 1908 (Section 7). Generic Metadata types should be descriptive and 1909 may be hierarchnical to support aggregating groups of properties 1910 for the purpose of readability and for avoiding conflicts between 1911 vendor defined extensions. A dotted alpha-numeric notation is 1912 suggested for human readability. 1914 2. Define the set of properties associated with the new type. 1916 3. For each property, define a name, description, type, and whether 1917 or not the property is mandatory-to-specify. 1919 4. Specify whether or not the new type is "mandatory-to-enforce" (vs 1920 optional-to-enforce). 1922 5. Describe the semantics of the new type including its purpose and 1923 example of a use case to which it applies. 1925 7.1.1. GenericMetadata Sub-Registries 1927 Some of the initial standard GenericMetadata objects contain 1928 enumerated types which require registration (i.e., LocationACL 1929 footprint types, ProtocolACL protocols, and Auth protocols). The 1930 following sections define the initial values for these 1931 GenericMetadata type sub-registries. 1933 7.1.1.1. Footprint Sub-Registry 1935 The IANA is requested to create a new "CDNI Metadata Footprint Types" 1936 sub-registry under the "CDNI GenericMetadata Types" registry. The 1937 "CDNI Metadata Footprint Types" namespace defines the valid Footprint 1938 object type values used by the Footprint object in Section 4.2.2.2. 1939 Additions to the Footprint type namespace conform to the "Expert 1940 Review" policy as defined in [RFC5226]. The expert review should 1941 verify that new type definitions do not duplicate existing type 1942 definitions and prevent gratuitous additions to the namespace. 1944 The following table defines the initial Footprint type values: 1946 +-------------+-------------------------------------+---------------+ 1947 | Type name | Description | Specification | 1948 +-------------+-------------------------------------+---------------+ 1949 | IPv4CIDR | IPv4 address block using slash | RFCthis | 1950 | | prefix length notation (e.g., | | 1951 | | 192.168.0.16/28). Single IP | | 1952 | | addresses can be expressed as /32. | | 1953 | IPv6CIDR | IPv6 address block using slash | RFCthis | 1954 | | prefix length notation (e.g., | | 1955 | | fc80::0010/124). Single IP | | 1956 | | addresses can be expressed as /128. | | 1957 | ASN | Autonomous System (AS) Number | RFCthis | 1958 | CountryCode | ISO 3166-1 alpha-2 code | RFCthis | 1959 +-------------+-------------------------------------+---------------+ 1961 7.1.1.2. Protocol Sub-Registry 1963 The IANA is requested to create a new "CDNI Metadata Protocols" sub- 1964 registry under the "CDNI GenericMetadata Types" registry. The "CDNI 1965 Metadata Protocols" namespace defines the valid Protocol object 1966 values in Section 4.3.2, used by the SourceMetadata and ProtocolACL 1967 objects. Additions to the Protocol namespace conform to the "Expert 1968 Review" policy as defined in [RFC5226]. The expert review should 1969 verify that new protocol definitions do not duplicate existing 1970 protocol definitions and prevent gratuitous additions to the 1971 namespace. 1973 The following table defines the initial Protocol values: 1975 +----------+----------------+---------------------------------------+ 1976 | Protocol | Description | Specification | 1977 +----------+----------------+---------------------------------------+ 1978 | HTTP | Hypertext | RFC2616 | 1979 | | Transfer | | 1980 | | Protocol -- | | 1981 | | HTTP/1.1 | | 1982 | HTTPS | HTTP Over TLS | RFC2818 | 1983 | RTSP | Real Time | RFC2326 | 1984 | | Streaming | | 1985 | | Protocol | | 1986 | RTMP | Real-Time | http://www.adobe.com/devnet/rtmp.html | 1987 | | Messaging | | 1988 | | Protocol | | 1989 | FTP | FILE TRANSFER | RFC959 | 1990 | | PROTOCOL | | 1991 | SFTP | SSH File | N/A | 1992 | | Transfer | | 1993 | | Protocol | | 1994 | SCP | Secure Copy | N/A | 1995 | fasp | Aspera fast, | N/A | 1996 | | adaptive, | | 1997 | | secure | | 1998 | | protocol | | 1999 +----------+----------------+---------------------------------------+ 2001 7.1.1.3. Authentication Type Sub-Registry 2003 The IANA is requested to create a new "CDNI Metadata Auth Types" sub- 2004 registry under the "CDNI GenericMetadata Types" registry. The "CDNI 2005 Metadata Auth Type" namespace defines the valid Auth object types 2006 used by the Auth object in Section 4.4. Additions to the Auth Type 2007 namespace conform to the "Expert Review" policy as defined in 2008 [RFC5226]. The expert review should verify that new type definitions 2009 do not duplicate existing type definitions and prevent gratuitous 2010 additions to the namespace. 2012 The following table defines the initial Auth type values: 2014 +----------------+----------------------------------+---------------+ 2015 | Type | Description | Specification | 2016 +----------------+----------------------------------+---------------+ 2017 | CredentialAuth | Simple username and password | RFCthis | 2018 | | authentication as defined by | | 2019 | | Section 4.4.1. | | 2020 +----------------+----------------------------------+---------------+ 2022 8. Security Considerations 2024 An implementation of the CDNI Metadata interface MUST support TLS 2025 transport as per [RFC2818] for message confidentiality and mutual 2026 authentication. An implementation of the CDNI Metadata interface 2027 MUST support the TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite 2028 ([RFC2818]). An implementation of the CDNI Metadata interface SHOULD 2029 prefer cipher suites which suppport perfect forward secrecy over 2030 cipher suites that do not. 2032 8.1. Authentication 2034 Unauthorized access to metadata could result in denial of service. A 2035 malicious metadata server could provide metadata to a dCDN that 2036 denies service for one or more pieces of content to one or more user 2037 agents. A malicious metadata server could also provide metadata 2038 directing dCDNs to malicious origin servers instead of the actual 2039 origin servers. A malicious client could continuously issue large 2040 metadata requests to overload the uCDN metadata server. 2042 Unauthorized access to metadata could result in leakage of private 2043 information. A malicious metadata client could request metadata in 2044 order to gain access to origin servers, as well as information 2045 pertaining to content restrictions. 2047 An implementation of the CDNI Metadata interface SHOULD use mutual 2048 authentication to prevent unauthorized access to metadata. 2050 8.2. Confidentiality 2052 Unauthorized viewing of metadata could result in leakage of private 2053 information. A third party could intercept metadata transactions in 2054 order to gain access to origin servers, as well as information 2055 pertaining to content restrictions. 2057 An implementation of the CDNI Metadata interface SHOULD use strong 2058 encryption to prevent unauthorized viewing of metadata. 2060 8.3. Integrity 2062 Unauthorized modification of metadata could result in denial of 2063 service. A malicious proxy server could modify metadata destined to 2064 a dCDN in order to deny service for one or more pieces of content to 2065 one or more user agents. A malicious proxy server could also modify 2066 metadata directing dCDNs to malicious origin servers instead of the 2067 actual origin servers. 2069 An implementation of the CDNI Metadata interface SHOULD use strong 2070 encryption and mutual authentication to prevent unauthorized 2071 modification of metadata. 2073 8.4. Privacy 2075 Content provider origin and policy information is conveyed through 2076 the CDNI Metadata interface. The distribution of this information to 2077 another CDN introduces potential content provider privacy protection 2078 concerns. 2080 The use of TLS for transport of the CDNI Metadata as discussed above 2081 protects the confidentiality of content metadata by preventing any 2082 party other than the authorized dCDN from gaining access to content 2083 metadata. 2085 9. Acknowledgements 2087 The authors would like to thank David Ferguson and Francois Le 2088 Faucheur for their valuable comments and input to this document. 2090 10. Contributing Authors 2092 [RFC Editor Note: Please move the contents of this section to the 2093 Authors' Addresses section prior to publication as an RFC.] 2095 Grant Watson 2096 Velocix (Alcatel-Lucent) 2097 3 Ely Road 2098 Milton, Cambridge CB24 6AA 2099 UK 2101 Email: gwatson@velocix.com 2103 Kent Leung 2104 Cisco Systems 2105 3625 Cisco Way 2106 San Jose, 95134 2107 USA 2109 Email: kleung@cisco.com 2111 11. References 2112 11.1. Normative References 2114 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2115 Requirement Levels", BCP 14, RFC 2119, March 1997. 2117 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2118 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2119 Authentication: Basic and Digest Access Authentication", 2120 RFC 2617, June 1999. 2122 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2124 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2125 Architecture", RFC 4291, February 2006. 2127 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2128 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2129 May 2008. 2131 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2132 Address Text Representation", RFC 5952, August 2010. 2134 11.2. Informative References 2136 [I-D.ietf-cdni-framework] 2137 Peterson, L., Davie, B., and R. Brandenburg, "Framework 2138 for CDN Interconnection", draft-ietf-cdni-framework-14 2139 (work in progress), June 2014. 2141 [I-D.ietf-cdni-redirection] 2142 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 2143 Redirection Interface for CDN Interconnection", draft- 2144 ietf-cdni-redirection-04 (work in progress), October 2014. 2146 [I-D.ietf-cdni-requirements] 2147 Leung, K. and Y. Lee, "Content Distribution Network 2148 Interconnection (CDNI) Requirements", draft-ietf-cdni- 2149 requirements-17 (work in progress), January 2014. 2151 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2152 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2153 3986, January 2005. 2155 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2156 Distribution Network Interconnection (CDNI) Problem 2157 Statement", RFC 6707, September 2012. 2159 [XML-BASE] 2160 Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second 2161 Edition) - http://www.w3.org/TR/xmlbase/", January 2009. 2163 Authors' Addresses 2165 Ben Niven-Jenkins 2166 Velocix (Alcatel-Lucent) 2167 3 Ely Road 2168 Milton, Cambridge CB24 6AA 2169 UK 2171 Email: ben@velocix.com 2173 Rob Murray 2174 Velocix (Alcatel-Lucent) 2175 3 Ely Road 2176 Milton, Cambridge CB24 6AA 2177 UK 2179 Email: rmurray@velocix.com 2181 Matt Caulfield 2182 Cisco Systems 2183 1414 Massachusetts Avenue 2184 Boxborough, MA 01719 2185 USA 2187 Phone: +1 978 936 9307 2188 Email: mcaulfie@cisco.com 2190 Kevin J. Ma 2191 Ericsson 2192 43 Nagog Park 2193 Acton, MA 01720 2194 USA 2196 Phone: +1 978-844-5100 2197 Email: kevin.j.ma@ericsson.com