idnits 2.17.1 draft-ietf-cdni-metadata-07.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 (July 2, 2014) is 3580 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) ** 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-02 Summary: 4 errors (**), 0 flaws (~~), 3 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: January 3, 2015 M. Caulfield 6 K. Leung 7 Cisco Systems 8 K. Ma 9 Ericsson 10 July 2, 2014 12 CDN Interconnection Metadata 13 draft-ietf-cdni-metadata-07 15 Abstract 17 The CDNI Metadata interface enables interconnected CDNs to exchange 18 content distribution metadata in order to enable content acquisition 19 and delivery. The CDNI metadata associated with a piece of content 20 provides a downstream CDN with sufficient information for the 21 downstream CDN to service content requests on behalf of an upstream 22 CDN. This document describes both a base set of CDNI metadata and 23 the protocol for exchanging that metadata. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 3, 2015. 48 Copyright Notice 50 Copyright (c) 2014 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 4 68 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5 69 3. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . 6 70 3.1. HostIndex, HostMetadata and PathMetadata objects . . . . 7 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 . . . 15 74 4.1. Descriptions of the CDNI Structural Metadata Objects . . 16 75 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 16 76 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 16 77 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17 78 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 17 79 4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 18 80 4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . 18 81 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 19 82 4.2. Description of the CDNI Generic Metadata Objects . . . . 20 83 4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . 22 88 4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 23 89 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 23 90 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 24 91 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 24 92 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 24 93 4.2.5. Authorization Metadata . . . . . . . . . . . . . . . 25 94 4.2.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 25 95 4.2.6.1. Credentials Auth Type . . . . . . . . . . . . . . 26 97 4.2.7. Cache . . . . . . . . . . . . . . . . . . . . . . . . 26 98 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 26 99 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 27 100 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 27 101 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 28 102 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 28 103 4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 28 104 4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 28 105 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 28 106 5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 29 107 5.2. Authorization Metadata Capabilities . . . . . . . . . . . 29 108 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 29 109 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 30 110 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 31 111 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 32 112 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 32 113 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 33 114 6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 33 115 6.4.2.1. Encoded CDNI Metadata Example . . . . . . . . . . 34 116 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 38 117 6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 38 118 6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 39 119 6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 39 120 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 121 7.1. GenericMetadata Type Registry . . . . . . . . . . . . . . 40 122 7.1.1. GenericMetadata Sub-Registries . . . . . . . . . . . 42 123 7.1.1.1. Footprint Sub-Registry . . . . . . . . . . . . . 42 124 7.1.1.2. Protocol Sub-Registry . . . . . . . . . . . . . . 42 125 7.1.1.3. Authentication Sub-Registry . . . . . . . . . . . 43 126 8. Security Considerations . . . . . . . . . . . . . . . . . . . 44 127 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44 128 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 44 129 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 130 11.1. Normative References . . . . . . . . . . . . . . . . . . 45 131 11.2. Informative References . . . . . . . . . . . . . . . . . 45 132 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 134 1. Introduction 136 Content Delivery Networks Interconnection (CDNI) ([RFC6707]) enables 137 a downstream CDN to service content requests on behalf of an upstream 138 CDN. 140 The CDNI Metadata interface is discussed in [I-D.ietf-cdni-framework] 141 along with four other interfaces that may be used to compose a CDNI 142 solution (CDNI Control interface, CDNI Request Routing Redirection 143 interface, CDNI Footprint & Capabilities Advertisement interface and 144 CDNI Logging interface). [I-D.ietf-cdni-framework] describes each 145 interface, and the relationships between them. The requirements for 146 the CDNI metadata interface are specified in 147 [I-D.ietf-cdni-requirements]. 149 The CDNI metadata associated with a piece of content (or with a set 150 of content) provides a downstream CDN with sufficient information for 151 servicing content requests on behalf of an upstream CDN in accordance 152 with the policies defined by the upstream CDN. 154 This document focuses on the CDNI Metadata interface which enables a 155 downstream CDN to obtain CDNI Metadata from an upstream CDN so that 156 the downstream CDN can properly process and respond to: 158 o Redirection requests received over the CDNI Request Routing 159 Redirection interface. 161 o Content requests received directly from User Agents. 163 Specifically, this document specifies: 165 o A data structure for mapping content requests and redirection 166 requests to CDNI Metadata objects (Section 3 and Section 4.1). 168 o An initial set of CDNI Generic Metadata objects (Section 4.2). 170 o A RESTful web service for the transfer of CDNI Metadata 171 (Section 6). 173 1.1. Terminology 175 This document reuses the terminology defined in [RFC6707]. 177 Additionally, the following terms are used throughout this document 178 and are defined as follows: 180 o Object - a collection of properties 182 o Property - a key and value pair where the key is a property name 183 and the value is the property value or an object. 185 1.2. Supported Metadata Capabilities 187 Only the metadata for a small set of initial capabilities is 188 specified in this document. This set provides the minimum amount of 189 metadata for basic CDN interoperability while still meeting the 190 requirements set forth by [I-D.ietf-cdni-requirements]. 192 The following high-level functionality is configured via the metadata 193 described in Section 4: 195 o Acquisition Source: Metadata for allowing a dCDN to fetch content 196 from a uCDN. 198 o Delivery Access Control: Metadata for restricting (or permitting) 199 access to content based on any of the following factors: 201 * Location 203 * Time Window 205 * Delivery Protocol 207 o Delivery Authorization: Metadata for authorizing dCDN user agent 208 requests. 210 o Cache Control: Metadata for controlling cache behavior of the 211 dCDN. 213 The metadata encoding described by this document is extensible in 214 order allow for future additions to this list. 216 This document supports HTTPv1.1 for delivery and both HTTPv1.1 and 217 HTTPv1.1. over TLS for acquisition. All metadata is described in a 218 protocol-agnostic manner. 220 Supporting unencrypted HTTPv2.0 for delivery (or unencrypted HTTPv2.0 221 or HTTPv2.0 over TLS for acquisition) only requires the registration 222 of these protocol names in the CDNI Metadata Protocol Sub-Registry. 224 Supporting HTTPv1.1 over TLS or HTTPv2.0 over TLS for delivery 225 requires specifying additional metadata objects to carry the 226 properties required to establish a TLS session, for example metadata 227 to describe the certificate to present as part of the TLS handshake. 229 2. Design Principles 231 The CDNI Metadata interface was designed to achieve the following 232 objectives: 234 1. Cacheability of CDNI metadata objects. 236 2. Deterministic mapping from redirection requests and content 237 requests to CDNI metadata properties. 239 3. Support for DNS redirection as well as application-specific 240 redirection (for example HTTP redirection). 242 4. Minimal duplication of CDNI metadata. 244 5. Leveraging of existing protocols. 246 Cacheability improves the latency of acquiring metadata while 247 maintaining its freshness, and therefore improves the latency of 248 serving content requests and redirection requests, without 249 sacrificing accuracy. The CDNI Metadata interface uses HTTP and its 250 existing caching mechanisms to achieve CDNI metadata cacheability. 252 Deterministic mappings from content to metadata properties eliminates 253 ambiguity and ensures that policies are applied consistently by all 254 downstream CDNs. 256 Support for both HTTP and DNS redirection ensures that the CDNI 257 Metadata interface can be used for HTTP and DNS redirection and also 258 meets the same design principles for both HTTP and DNS based 259 redirection schemes. 261 Minimal duplication of CDNI metadata provides space efficiency on 262 storage in the CDNs, on caches in the network, and across the network 263 between CDNs. 265 Leveraging existing protocols avoids reinventing common mechanisms 266 such as data structure encoding (e.g. XML, JSON) and data transport 267 (e.g. HTTP). 269 3. CDNI Metadata Data Model 271 The CDNI Metadata Model describes a data structure for mapping 272 redirection requests and content requests to metadata properties. 273 Metadata properties describe how to acquire content from an upstream 274 CDN, authorize access to content, and deliver content from a 275 downstream CDN. The data model relies on the assumption that these 276 metadata properties may be aggregated based on the hostname of the 277 content and subsequently on the resource path of the content. The 278 data model associates a set of CDNI Metadata properties with a 279 Hostname to form a default set of metadata properties for content 280 delivered on behalf of that Hostname. That default set of metadata 281 properties can be overridden by properties that apply to specific 282 paths within a URI. 284 Different Hostnames and URI paths will be associated with different 285 sets of CDNI Metadata properties in order to describe the required 286 behaviour when a dCDN surrogate is processing User Agent requests for 287 content at that Hostname or URI path. As a result of this structure, 288 significant commonality may exist between the CDNI Metadata 289 properties specified for different Hostnames, different URI paths 290 within a Hostname and different URI paths on different Hostnames. 291 For example the definition of which User Agent IP addresses should be 292 treated as being grouped together into a single network or geographic 293 location is likely to be common for a number of different Hostnames. 294 Another example is that although a uCDN is likely to have several 295 different policies configured to express geo-blocking rules, it is 296 likely that a single geo-blocking policy would be applied to multiple 297 Hostnames delivered through the CDN. 299 In order to enable the CDNI Metadata for a given Hostname or URI Path 300 to be decomposed into sets of CDNI Metadata properties that can be 301 reused by multiple Hostnames and URI Paths, the CDNI Metadata 302 interface specified in this document splits the CDNI Metadata into a 303 number of objects. Efficiency is improved by enabling a single CDNI 304 Metadata object (that is shared across Hostname and/or URI paths) to 305 be retrieved and stored by a dCDN once, even if it is referenced by 306 the CDNI Metadata of multiple Hostnames or of multiple URI paths. 308 Section 3.1 introduces a high level description of the HostIndex, 309 HostMetadata and PathMetadata objects and describes the relationships 310 between those objects. 312 Section 3.2 introduces a high level description of the CDNI 313 GenericMetadata object which represents the level at which CDNI 314 Metadata override occurs between HostMetadata and PathMetadata 315 objects. 317 Section 4 describes in detail the specific CDNI Metadata objects and 318 properties which may be contained within a CDNI GenericMetadata 319 object. 321 3.1. HostIndex, HostMetadata and PathMetadata objects 323 A HostIndex object contains (or references) a list of Hostnames (and/ 324 or IP addresses) for which content requests may be delegated to the 325 downstream CDN. The HostIndex is the starting point for accessing 326 the uCDN CDNI Metadata data store. It enables the dCDN to 327 deterministically discover, on receipt of a User Agent request for 328 content, which other CDNI Metadata objects it requires in order to 329 deliver the requested content. 331 The HostIndex links Hostnames (and/or IP addresses) to HostMetadata 332 objects via HostMatch objects. HostMetadata objects contain (or 333 reference) the default CDNI Metadata required to serve content for 334 that host. When looking up CDNI Metadata, the downstream CDN looks 335 up the requested Hostname (or IP address) against the HostMatch 336 entries in the HostIndex, from there it can find HostMetadata which 337 describes properties for a host and PathMetadata which may override 338 those properties for given URI paths within the host. 340 HostMetadata and PathMetadata objects may also contain PathMatch 341 objects which in turn contain PathMetadata objects. PathMatch 342 objects override the CDNI Metadata in the HostMetadata object or one 343 or more preceding PathMetadata objects with more specific CDNI 344 Metadata that applies to content requests matching the pattern 345 defined in that PathMatch object. 347 For the purposes of retrieving CDNI Metadata, all other required CDNI 348 Metadata objects and their properties are discoverable from the 349 appropriate HostMetadata, PathMatch and PathMetadata objects for the 350 requested content. 352 The relationships between the HostIndex, HostMatch, HostMetadata, 353 PathMatch and PathMetadata objects are described in Figure 1. 355 +---------+ +---------+ +------------+ 356 |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ 357 +---------+ +---------+ +------+-----+ | 358 | | 359 (*) | 360 | V 361 --> Contains or References V ****************** 362 (1) One and only one +---------+ *Generic Metadata* 363 (*) Zero or more +--->|PathMatch| * Objects * 364 | +----+---++ ****************** 365 | | | ^ 366 (*) (1) (1) +------------+ | 367 | | +->|PatternMatch| | 368 | V +------------+ | 369 | +------------+ | 370 +--+PathMetadata+-------(*)------+ 371 +------------+ 373 Figure 1: Relationships between CDNI Metadata Objects (Diagram 374 Representation) 376 The relationships in Figure 1 are also represented in tabular format 377 in Table 1 below. 379 +--------------+----------------------------------------------------+ 380 | Data Object | Objects it contains or references | 381 +--------------+----------------------------------------------------+ 382 | HostIndex | 0 or more HostMatch objects. | 383 | HostMatch | 1 HostMetadata object. | 384 | HostMetadata | 0 or more PathMatch objects. 0 or more | 385 | | GenericMetadata objects. | 386 | PathMatch | 1 PatternMatch object. 1 PathMetadata object. | 387 | PatternMatch | Does not contain or reference any other objects. | 388 | PathMetadata | 0 or more PathMatch objects. 0 or more | 389 | | GenericMetadata objects. | 390 +--------------+----------------------------------------------------+ 392 Table 1: Relationships between CDNI Metadata Objects 393 (Table Representation) 395 The table below describes the HostIndex, HostMetadata and 396 PathMetadata objects in more detail. 398 +-----------------+-------------------------------------------------+ 399 | Data Object | Description | 400 +-----------------+-------------------------------------------------+ 401 | HostIndex | A HostIndex object lists HostMatch objects | 402 | HostMatch | A HostMatch object defines a hostname (or IP | 403 | | address) to match against a requested host, and | 404 | | contains (or references) a HostMetadata object | 405 | | which contains (or references) CDNI Metadata | 406 | | objects to be applied when a request matches | 407 | | against the hostname. For example, if | 408 | | "example.com" is a content provider, a | 409 | | HostMatch object may include an entry for | 410 | | "example.com" with the URI of the associated | 411 | | HostMetadata object. | 412 | HostMetadata | A HostMetadata object contains (or references) | 413 | | the default CDNI Metadata objects for content | 414 | | served from that host, i.e. the CDNI Metadata | 415 | | objects for content requests that do not match | 416 | | any of the PathMatch objects contained (or | 417 | | referenced) by that HostMetadata object. For | 418 | | example, a HostMetadata object may describe the | 419 | | metadata properties which apply to | 420 | | "example.com" and may contain PathMatches for | 421 | | "example.com/movies/*" and | 422 | | "example.com/music/*" which reference | 423 | | corresponding PathMetadata objects that contain | 424 | | the CDNI Metadata objects for those more | 425 | | specific URI paths. | 426 | PathMatch | A PathMatch object defines a pattern (inside a | 427 | | PatternMatch object which PathMatch object | 428 | | contains or references) to match against the | 429 | | requested URI path, and contains (or | 430 | | references) a PathMetadata object which | 431 | | contains (or references) the CDNI Metadata | 432 | | objects to be applied when a content request | 433 | | matches against the defined URI path pattern. | 434 | | For example, a PathMatch object may include a | 435 | | PatternMatch object containing a pattern for | 436 | | the path "/movies/*" and may reference a | 437 | | PathMetadata object which contains (or | 438 | | references) the CDNI Metadata for content with | 439 | | that path. | 440 | PatternMatch | A PatternMatch object contains the pattern | 441 | | string and flags that describe the URI path | 442 | | that a PathMatch applies to. | 443 | PathMetadata | A PathMetadata object contains (or references) | 444 | | the CDNI GenericMetadata objects for content | 445 | | served with the associated URI path (defined in | 446 | | a PathMatch object). A PathMetadata object may | 447 | | also contain (or reference) PathMatch objects | 448 | | in order to recursively define more specific | 449 | | URI paths that require different (e.g. more | 450 | | specific) CDNI Metadata to this one. For | 451 | | example, the PathMetadata object which applies | 452 | | to "example.com/movies/*" may describe CDNI | 453 | | Metadata which apply to that resource path and | 454 | | may contain a PathMatch object for | 455 | | "example.com/movies/hd/*" which would reference | 456 | | the corresponding PathMetadata object for the | 457 | | "example.com/movies/hd/" path prefix. | 458 | GenericMetadata | A GenericMetadata object contains (or | 459 | | references) individual CDNI Metadata objects | 460 | | which define the specific policies and | 461 | | attributes needed to properly deliver the | 462 | | associated content. For example, a | 463 | | GenericMetadata object may describe the source | 464 | | from which a CDN may acquire a piece of | 465 | | content. The GenericMetadata object is an | 466 | | atomic unit that may be referenced by | 467 | | HostMetadata and/or PathMetadata objects, but | 468 | | SHOULD NOT contain references to other CDNI | 469 | | Metadata objects. The member objects of a | 470 | | specific CDNI Metadata object MAY be referenced | 471 | | by the GenericMetadata object. | 472 +-----------------+-------------------------------------------------+ 473 Table 2: HostIndex, HostMetadata and PathMetadata CDNI Metadata 474 Objects 476 3.2. Generic CDNI Metadata Object Properties 478 The HostMetadata and PathMetadata objects contain or can reference 479 other CDNI Metadata objects that contain properties which describe 480 how User Agent requests for content should be processed, for example 481 where to acquire the content, authorization rules that should be 482 applied, delivery location restrictions and so on. Each such CDNI 483 Metadata object is a specialization of a CDNI GenericMetadata object. 484 The GenericMetadata object abstracts the basic information required 485 for Metadata override and Metadata distribution, from the specifics 486 of any given property (e.g., property semantics, enforcement options, 487 etc.). 489 The GenericMetadata object defines the type of properties contained 490 within it as well as whether or not the properties are "mandatory-to- 491 enforce". If the dCDN does not understand or support the property 492 type and the property type is "mandatory-to-enforce", the dCDN MUST 493 NOT serve the content to the User Agent. If the dCDN does not 494 understand or support the property type and the property type is not 495 "mandatory-to-enforce", then that GenericMetadata object may be 496 safely ignored and the dCDN MUST process the content request in 497 accordance with the rest of the CDNI metadata. 499 Although a CDN MUST NOT serve content to a User Agent if a 500 "mandatory-to-enforce" property cannot be enforced, it may be "safe- 501 to-redistribute" that metadata to another CDN without modification. 502 For example, in the cascaded CDN case, a transit CDN may pass through 503 "mandatory-to-enforce" metadata to a downstream CDN. For Metadata 504 which does not require customization or translation (i.e. metadata 505 that is "safe-to-redistribute"), the data representation received off 506 the wire MAY be stored and redistributed without being natively 507 understood or supported by the transit CDN.However, for Metadata 508 which requires translation, transparent redistribution of the uCDN 509 Metadata values may not be appropriate. Certain Metadata may be 510 safely, though possibly not optimally, redistributed unmodified. For 511 example, source acquisition address may not be optimal if 512 transparently redistributed, but may still work. 514 Redistribution safety MUST be specified for each GenericMetadata. If 515 a CDN does not understand or support a given GenericMetadata property 516 type and the property type is not "safe-to-redistribute", before 517 redistributing the metadata, the CDN MUST set the "incomprehensible" 518 flag for the GenericMetadata property that it did not understand and 519 was marked as not "safe-to-redistribute". The "incomprehensible" 520 flag signals to a dCDN that the metadata was not properly transformed 521 by the transit CDN. A CDN MUST NOT attempt to use metadata that has 522 been marked as "incomprehensible" by a uCDN. 524 [[Editors' Note: Do we need to clarify what is meant by 525 "Redistribution safety MUST be specified"? In Section 4.1.7 526 (GenericMetadata) we say that StR is not Mandatory-to-Specify and 527 defaults to StR=True. A strict interpretation of "MUST be specified" 528 could be that StR is Mandatory-to-Specify and could lead to dCDNs 529 rejecting requests/metadata that leave it out as the default applies 530 which would be an issue for interop. Maybe change first sentence to 531 "If a GenericMetadata object cannot be redistributed safely then it 532 MUST be marked as not safe-to-redistribute (i.e. Safe-to- 533 redistribute is set to False).]] 535 Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or 536 "safe-to-redistribute" when propogating metadata to a dCDN. Although 537 a transit CDN may set the value of "incomprehensible" to true, a 538 transit CDN MUST NOT change the value of "incomprehensible" from true 539 to false. 541 [[Editors' Note: Should a transit CDN be allowed to change the value 542 of "mandatory-to-enforce" or "safe-to-redistribute"? Changing MtE 543 from false to true should be safe from an enforcement perspective as 544 it makes delivery more restrictive? Changing StR may be ok, 545 depending upon what the metadata is (e.g., perhaps URL rewrite is 546 only needed in certain cases and the transit CDN is the one to make 547 that decision)? For simplicity, prohibiting transit CDNs from 548 changing MtE or StR seems like the simplest approach.]] 550 The following table describes the action to be taken by a transit CDN 551 (tCDN) for the different "mandatory-to-enforce" (MtE) and "safe-to- 552 redistribute" (StR) cases, when the tCDN either does or does not 553 understand the metadata in question: 555 +-------+-------+------------+--------------------------------------+ 556 | MtE | StR | Metadata | Actions allowed | 557 | | | Understood | | 558 +-------+-------+------------+--------------------------------------+ 559 | False | True | True | Can serve and redistribute. | 560 | False | True | False | Can serve and redistribute. | 561 | False | False | False | Can serve but MUST set | 562 | | | | "incomprehensible" to True when | 563 | | | | redistributing. | 564 | False | False | True | Can serve. Can redistribute either | 565 | | | | by transforming not StR metadata (if | 566 | | | | the CDN know how to do so safely), | 567 | | | | otherwise MUST set | 568 | | | | "incomprehensible" to True when | 569 | | | | redistributing. | 570 | True | True | True | Can serve and can redistribute. | 571 | True | True | False | MUST NOT serve but can redistribute. | 572 | True | False | True | Can serve and can redistribute. | 573 | True | False | False | MUST NOT serve. MUST set | 574 | | | | "incomprehensible" to True when | 575 | | | | redistributing. | 576 +-------+-------+------------+--------------------------------------+ 578 The following table describes the action to be taken by a dCDN for 579 the different "mandatory-to-enforce" (MtE), "safe-to-redistribute" 580 (StR) and "incomprehensible" (Inc) cases, when the dCDN either does 581 or does not understand the metadata in question: 583 +-------+-------+------------+------------------+-------------------+ 584 | MtE | StR | Metadata | Incomprehensible | Actions allowed | 585 | | | Understood | | | 586 +-------+-------+------------+------------------+-------------------+ 587 | False | True | True | False | Can serve. | 588 | False | True | True | True | Can serve but | 589 | | | | | MUST NOT | 590 | | | | | interpret/apply | 591 | | | | | any metadata | 592 | | | | | marked | 593 | | | | | incomprehensible. | 594 | False | True | False | False | Can serve. | 595 | False | True | False | True | Can serve but | 596 | | | | | MUST NOT | 597 | | | | | interpret/apply | 598 | | | | | any metadata | 599 | | | | | marked | 600 | | | | | incomprehensible. | 601 | False | False | True | False | Can serve. | 602 | False | False | True | True | Can serve but | 603 | | | | | MUST NOT | 604 | | | | | interpret/apply | 605 | | | | | any metadata | 606 | | | | | marked | 607 | | | | | incomprehensible. | 608 | False | False | False | False | Can serve. | 609 | False | False | False | True | Can serve but | 610 | | | | | MUST NOT | 611 | | | | | interpret/apply | 612 | | | | | any metadata | 613 | | | | | marked | 614 | | | | | incomprehensible. | 615 | True | True | True | False | Can serve. | 616 | True | True | True | True | Can serve but | 617 | | | | | MUST NOT | 618 | | | | | interpret/apply | 619 | | | | | any metadata | 620 | | | | | marked | 621 | | | | | incomprehensible. | 622 | True | True | False | False | MUST NOT serve. | 623 | True | True | False | True | MUST NOT serve. | 624 | True | False | True | False | Can serve. | 625 | True | False | True | True | Can serve but | 626 | | | | | MUST NOT | 627 | | | | | interpret/apply | 628 | | | | | any metadata | 629 | | | | | marked | 630 | | | | | incomprehensible. | 631 | True | False | False | False | MUST NOT serve. | 632 | True | False | False | True | MUST NOT serve. | 633 +-------+-------+------------+------------------+-------------------+ 635 3.3. Metadata Inheritance and Override 637 In the data model, a HostMetadata object may contain (or reference) 638 multiple PathMetadata objects (via PathMatch objects). Each 639 PathMetadata object may in turn contain (or reference) other 640 PathMetadata objects. HostMetadata and PathMetadata objects form an 641 inheritance tree where each node in the tree inherits or overrides 642 the property values set by its parent. 644 GenericMetadata objects of a given type override all GenericMetadata 645 objects of the same type previously defined by any parent object in 646 the tree. GenericMetadata objects of a given type previously defined 647 by a parent object in the tree are inherited when no object of the 648 same type is defined by the child object. For example, if 649 HostMetadata for the host "example.com" contains GenericMetadata 650 objects of type LocationACL and TimeWindowACL, while a PathMetadata 651 object which applies to "example.com/movies/*" defines an alternate 652 GenericMetadata object of type TimeWindowACL, then: 654 o the TimeWindowACL defined in the PathMetadata would override the 655 TimeWindowACL defined in the HostMetadata for all User Agent 656 requests for content under "example.com/movies", and 658 o the LocationACL defined in the HostMetadata would be inherited for 659 all User Agent requests for content under "example.com/movies". 661 4. Encoding-Independent CDNI Metadata Object Descriptions 663 Section 4.1 provides the definitions of each object type declared in 664 Section 3. These objects are described as structural objects as they 665 provide the structure for the inheritance tree and identifying which 666 specific properties apply to a given User Agent content request. 668 Section 4.2 provides the definitions for a base set of core metadata 669 objects which may be contained within a GenericMetadata object. 670 These objects are described as property objects as they define the 671 structure, semantics, and enforcement options for specific properties 672 of the metadata being described. Property objects govern how User 673 Agent requests for content are handled. Property objects may be 674 composed of or contain references to other property sub-objects (i.e. 675 property objects contained within or referenced by the property 676 object that refers to that property sub-object). In those cases the 677 value of the property sub-objects can be either a complete serialized 678 representation of the sub-object, or a Link object that contains a 679 URI and relationship that can be dereferenced to retrieve the 680 complete serialized representation of the property sub-object. 682 Section 6.5 discusses the ability to extend the base set of metadata 683 objects specified in this document with additional standards based or 684 vendor specific property objects that may be defined in the future in 685 separate documents. 687 Downstream CDNs MUST support parsing of all CDNI metadata objects 688 specified in this document. A dCDN does not have to implement the 689 underlying functionality represented by the metadata object, which 690 may restrict the content which that dCDN can serve. uCDNs as 691 generators of CDNI Metadata only need to support generating the CDNI 692 metadata that they need in order to express the policies and 693 treatment the content they are describing requires. 695 Note: In the following sections, the term "mandatory-to-specify" is 696 used to convey which property sub-objects MUST be specified for a 697 given structural or property object. When mandatory-to-specify is 698 set to true on a sub-object, it implies that if the property object 699 containing that property sub-object is specified, then the mandatory- 700 to-specify property sub-object MUST also be specified, e.g., a 701 HostMatch property object without a host to match against does not 702 make sense, therefore, the host is mandatory-to-specify inside a 703 HostMatch property object. 705 4.1. Descriptions of the CDNI Structural Metadata Objects 707 Each of the sub-sections below describe the structural objects 708 defined in Table 2. 710 4.1.1. HostIndex 712 The HostIndex object is the entry point into the CDNI Metadata 713 hierarchy. It contains (or references) a list of HostMatch objects. 714 An incoming content request is matched against the hostname inside of 715 each of the listed HostMatch objects to find the HostMatch object 716 which applies to the request. 718 Property: hosts 720 Description: List of HostMatch objects, in priority order. 722 Type: List of HostMatch objects 724 Mandatory-to-Specify: Yes. 726 4.1.2. HostMatch 728 The HostMatch object contains a hostname or IP address to match 729 against content requests. The HostMatch object also contains or 730 references a HostMetadata object to apply if a match is found. 732 Property: host 734 Description: String (hostname or IP address) to match against 735 the requested host. 737 Type: String 739 Mandatory-to-Specify: Yes. 741 Property: host-metadata 743 Description: CDNI Metadata to apply when delivering content 744 that matches this host. 746 Type: HostMetadata 747 Mandatory-to-Specify: Yes. 749 4.1.3. HostMetadata 751 The HostMetadata object contains (or references) both Metadata that 752 applies to content requests for a particular host and a list of 753 pattern matches for finding more specific Metadata based on the 754 resource path in a content request. 756 Property: metadata 758 Description: List of host related metadata. 760 Type: List of GenericMetadata objects 762 Mandatory-to-Specify: Yes. 764 Property: paths 766 Description: Path specific rules. Path patterns (PathMatch 767 objects) MUST be evaluated in the order they appear and the 768 first PathMatch object that matches the content request being 769 process is applied. 771 Type: List of PathMatch objects 773 Mandatory-to-Specify: No. 775 4.1.4. PathMatch 777 The PathMatch object contains (or references) an expression given as 778 a PatternMatch object to match against a resource URI path and 779 Metadata objects to apply if a match is found. 781 Property: path-pattern 783 Description: Pattern to match against the requested path, i.e. 784 against the [RFC3986] path-absolute. 786 Type: PatternMatch 788 Mandatory-to-Specify: Yes. 790 Property: path-metadata 792 Description: CDNI Metadata to apply when delivering content 793 that matches this pattern. 795 Type: PathMetadata 797 Mandatory-to-Specify: Yes. 799 4.1.5. PathMetadata 801 A PathMetadata object contains (or reference) the CDNI Metadata 802 properties for content served with the associated URI path (defined 803 in a PathMatch object) and possibly children PathMatch objects. 805 Note that if DNS-based redirection is employed, then any metadata at 806 the PathMetadata level or below will be inaccessible at request 807 routing time because only the content request hostname is available 808 at request routing time. 810 Property: metadata 812 Description: List of path related metadata. 814 Type: List of GenericMetadata objects 816 Mandatory-to-Specify: Yes. 818 Property: paths 820 Description: Path specific rules. First match applies. 822 Type: List of PathMatch objects 824 Mandatory-to-Specify: No. 826 4.1.6. PatternMatch 828 A PatternMatch object contains the pattern string and flags that 829 describe the PathMatch expression. 831 Property: pattern 833 Description: A pattern for string matching. The pattern may 834 contain the wildcards * and ?, where * matches any sequence of 835 characters (including the empty string) and ? matches exactly 836 one character. The three literals \ , * and ? should be 837 escaped as \\, \* and \?. All other characters are treated as 838 literals. 840 Type: String 842 Mandatory-to-Specify: Yes. 844 Property: case-sensitive 846 Description: Flag indicating whether or not case-sensitive 847 matching should be used. 849 Type: Boolean 851 Mandatory-to-Specify: No. Default is case-insensitive match. 853 Property: ignore-query-string 855 Description: List of query parameters which should be ignored 856 when searching for a pattern match. If all query parameters 857 should be ignored then the list MUST be empty. 859 Type: List of String 861 Mandatory-to-Specify: No. Default is to include query strings 862 when matching. 864 4.1.7. GenericMetadata 866 A GenericMetadata object is an abstraction for managing individual 867 CDNI Metadata properties in an opaque manner. 869 Property: generic-metadata-type 871 Description: CDNI Metadata property object type. 873 Type: String 875 Mandatory-to-Specify: Yes. 877 Property: generic-metadata-value 879 Description: CDNI Metadata property object. 881 Type: Format/Type is defined by the value of generic-metadata- 882 type property above. 884 Mandatory-to-Specify: Yes. 886 Property: mandatory-to-enforce 888 Description: Flag identifying whether or not the enforcement of 889 the property Metadata is required. 891 Type: Boolean 892 Mandatory-to-Specify: No. Default is to treat metadata as 893 mandatory to enforce. 895 Property: safe-to-redistribute 897 Description: Flag identifying whether or not the property 898 Metadata may be safely redistributed without modification. 900 Type: Boolean 902 Mandatory-to-Specify: No. Default is allow transparent 903 redistribution. 905 4.2. Description of the CDNI Generic Metadata Objects 907 The property objects defined below are intended to be used in the 908 GenericMetadata object generic-metadata-value field as defined in 909 Section 4.1.7 and their generic-metadata-type property MUST be set to 910 the appropriate Media Type as defined in [[REF]]. 912 [[Editors' note: We don't specify media types for the Generic 913 Metadata object we define anywhere. Need to do that - at a minimum 914 in the IANA section, but should we introduce/explain them elsewhere 915 in the document too?]] 917 4.2.1. Source Metadata 919 Source Metadata provides the dCDN information about content 920 acquisition e.g. how to contact an uCDN Surrogate or an Origin Server 921 to obtain the content to be served. The sources are not necessarily 922 the actual Origin Servers operated by the CSP but might be a set of 923 Surrogates in the uCDN. 925 Endpoints within a source should be treated as equivalent/equal so 926 one can specify a list of sources in preference order and for each 927 source/preference rank one can specify a list of endpoints that are 928 equivalent, e.g. a pool of servers that are not behind a load 929 balancer. 931 Property: sources 933 Description: Sources from which the dCDN can acquire content, 934 listed in order of preference. 936 Type: List of Source objects 938 Mandatory-to-Specify: No. Default is to use static 939 configuration, out of band of the metadata interface. 941 4.2.1.1. Source 943 A Source object describes the Source which should be used by the dCDN 944 for content acquisition, e.g. a Surrogate within the uCDN or an 945 alternate Origin Server, the protocol to be used and any 946 authentication method. 948 Property: auth 950 Description: Authentication method to use when requesting 951 content from this source. 953 Type: Auth 955 Mandatory-to-Specify: No. Default is no authentication is 956 required. 958 Property: endpoints 960 Description: Origins from which the dCDN can acquire content. 961 If multiple endpoints are specified they are all equal, i.e. 962 the list is not in preference order, for example a pool of 963 servers behind a load balancer. 965 Type: List of EndPoint objects 967 Mandatory-to-Specify: Yes. 969 Property: protocol 971 Description: Network retrieval protocol to use when requesting 972 content from this source. 974 Type: Protocol 976 Mandatory-to-Specify: Yes. 978 4.2.2. LocationACL Metadata 980 LocationACL Metadata defines location-based restrictions. 982 A LocationACL which does not include a locations property results in 983 an action of allow, meaning that delivery can be performed regardless 984 of the User Agent's location. The action from the first footprint to 985 match against the User Agent's location is the action a CDN MUST 986 take. If two or more footprints overlap, the first footprint that 987 matches against the User Agent's location determines the action a CDN 988 MUST take. If the locations property is included but is empty, or if 989 none of the listed footprints matches the User Agent's location then 990 the result is an action of deny. 992 Property: locations 994 Description: Description: Access control list which allows or 995 blocks delivery based on client location. 997 Type: List of LocationRule objects 999 Mandatory-to-Specify: No. Default is allow all locations. 1001 4.2.2.1. LocationRule 1003 A LocationRule contains or references a list of Footprint objects and 1004 the corresponding action. 1006 Property: footprints 1008 Description: List of footprints to which the rule applies. 1010 Type: List of Footprint objects 1012 Mandatory-to-Specify: Yes. 1014 Property: action 1016 Description: Defines whether the rule specifies locations to 1017 allow or deny. 1019 Type: Enumeration [allow|deny] 1021 Mandatory-to-Specify: No. Default is deny. 1023 4.2.2.2. Footprint 1025 A Footprint object describes the footprint to which a LocationRule 1026 may be applied by, e.g. an IPv4 address range or a geographic 1027 location. 1029 Property: footprint-type 1031 Description: Registered footprint type (see Section 7.1.1.1). 1033 Type: String 1035 Mandatory-to-Specify: Yes. 1037 Property: footprint-value 1039 Description: Footprint object conforming to the specification 1040 associated with the registered footprint type. 1042 Type: String 1044 Mandatory-to-Specify: Yes. 1046 4.2.3. TimeWindowACL Metadata 1048 TimeWindowACL Metadata defines time-based restrictions. 1050 Property: times 1052 Description: Description: Access control list which allows or 1053 blocks delivery based on request time. 1055 Type: List of TimeWindowRule objects 1057 Mandatory-to-Specify: No. Default is allow all time windows. 1059 4.2.3.1. TimeWindowRule 1061 A TimeWindowRule contains or references a list of TimeWindow objects 1062 and the corresponding action. 1064 Property: windows 1066 Description: List of time windows to which the rule applies. 1068 Type: List of TimeWindow objects 1070 Mandatory-to-Specify: Yes. 1072 Property: action 1074 Description: Defines whether the rule specifies time windows to 1075 allow or deny. 1077 Type: Enumeration [allow|deny] 1079 Mandatory-to-Specify: No. Default is deny. 1081 4.2.3.2. TimeWindow 1083 A TimeWindow object describes a time range which may be applied by an 1084 ACLRule, e.g. Start 09:00AM 01/01/2000 UTC End 17:00PM 01/01/2000 1085 UTC. 1087 Property: start 1089 Description: The start time of the window. 1091 Type: Time 1093 Mandatory-to-Specify: Yes. 1095 Property: end 1097 Description: The end time of the window. 1099 Type: Time 1101 Mandatory-to-Specify: Yes. 1103 4.2.4. ProtocolACL Metadata 1105 ProtocolACL Metadata defines delivery protocol restrictions. 1107 Property: protocols 1109 Description: Description: Access control list which allows or 1110 blocks delivery based on delivery protocol. 1112 Type: List of ProtocolRule objects 1114 Mandatory-to-Specify: No. Default is allow all protocols. 1116 4.2.4.1. ProtocolRule 1118 A ProtocolRule contains or references a list of Protocol objects. 1119 ProtocolRule objects are used to construct a ProtocolACL to apply 1120 restrictions to content acquisition or delivery. 1122 Property: protocols 1124 Description: List of protocols to which the rule applies. 1126 Type: List of protocol objects 1128 Mandatory-to-Specify: Yes. 1130 Property: action 1132 Description: Defines whether the rule specifies protocols to 1133 allow or deny. 1135 Type: Enumeration [allow|deny] 1137 Mandatory-to-Specify: No. Default is allow all protocols. 1139 4.2.5. Authorization Metadata 1141 Authorization Metadata define content authorization methods. 1143 Property: methods 1145 Description: Options for authenticating content requests. All 1146 options in the list are equally valid. 1148 Type: List of Auth objects 1150 Mandatory-to-Specify: No. Default is no authorization 1151 required. 1153 4.2.6. Auth 1155 An Auth object defines authentication and authorization methods to be 1156 used during content delivery and content acquisition. 1158 Property: auth-type 1160 Description: Registered Auth type (see Section 7.1.1.3). 1162 Type: String 1164 Mandatory-to-Specify: Yes. 1166 Property: auth-value 1168 Description: Auth object conforming to the specification 1169 associated with the registered Auth type. 1171 Type: String 1173 Mandatory-to-Specify: Yes. 1175 4.2.6.1. Credentials Auth Type 1177 Credentials Auth is a type of Auth object with type "credentials" 1178 (see Section 7.1.1.3). The CredentialsAuth object contains the 1179 following properties: 1181 Property: username 1183 Description: Identification of user. 1185 Type: String 1187 Mandatory-to-Specify: Yes. 1189 Property: password 1191 Description: Password for user identified by username property. 1193 Type: String 1195 Mandatory-to-Specify: Yes. 1197 4.2.7. Cache 1199 A Cache object describes the cache control parameters to be applied 1200 to the content by intermediate caches. 1202 Property: ignore-query-string 1204 Description: Allows a cache to ignore URI query string 1205 parameters while comparing URIs for equivalence. Each query 1206 parameter to ignore is specified in the list. If all query 1207 parameters should be ignored, then the list MUST be empty. 1209 Type: List of String 1211 Mandatory-to-Specify: No. Default is to consider query string 1212 parameters when comparing URIs. 1214 4.2.8. Grouping 1216 A Grouping object identifies a large group of content to which this 1217 content belongs. 1219 Property: ccid 1221 Description: Content Collection identifier for an application- 1222 specific purpose such as logging. 1224 Type: String 1226 Mandatory-to-Specify: No. Default is an empty string. 1228 Property: sid 1230 Description: Session identifier for an application-specific 1231 purpose such as logging. 1233 Type: String 1235 Mandatory-to-Specify: No. Default is an empty string. 1237 4.3. CDNI Metadata Simple Data Type Descriptions 1239 This section describes the simpler data types that are used for 1240 properties of CDNI Metadata objects. 1242 4.3.1. Link 1244 A link object may be used in place of any of the objects or 1245 properties described above. Links can be used to avoid duplication 1246 if the same metadata information is repeated within the metadata 1247 tree. When a link replaces an object, its href property is set to 1248 the URI of the resource and its type property is set to the type of 1249 the object it is replacing. 1251 Property: href 1253 Description: The URI of the of the addressable object being 1254 referenced. 1256 Type: URI 1258 Mandatory-to-Specify: Yes 1260 Property: metadata-object-type 1262 Description: The type of the object being referenced. 1264 Type: String 1266 Mandatory-to-Specify: No 1268 4.3.2. Protocol 1270 Protocol objects are used to specify registered protocols for content 1271 acquisition or delivery (see Section 7.1.1.2). 1273 Type: String 1275 4.3.3. Endpoint 1277 A hostname (with optional port) or an IP address (with optional 1278 port). 1280 Note: All implementations MUST support IPv4 addresses encoded as 1281 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and 1282 MUST support all IPv6 address formats specified in [RFC4291]. Server 1283 implementations SHOULD use IPv6 address formats specified in 1284 [RFC5952]. 1286 Type: String 1288 4.3.4. URI 1290 A URI as specified in [RFC3986]. 1292 Type: String 1294 4.3.5. Time 1296 A time value expressed in seconds since Unix epoch in the UTC 1297 timezone. 1299 Type: Integer 1301 5. CDNI Metadata Capabilities 1303 CDNI Metadata is used to convey information pertaining to content 1304 delivery from uCDN to dCDN. For optional metadata, it may be useful 1305 for the uCDN to know if the dCDN supports the metadata, prior to 1306 delegating any content requests to the dCDN. If optional-to- 1307 implement metadata is "mandatory-to-enforce" and the dCDN does not 1308 support it, any delegated requests for that content will fail, so the 1309 uCDN is likely to want to avoid delegating those requests to that 1310 dCDN. Likewise, for any metadata which may be assigned optional 1311 values, it may be useful for the uCDN to know which values the dCDN 1312 supports, prior to delegating any content requests to the dCDN. If 1313 the optional value assigned to a given piece of content's metadata is 1314 not supported by the dCDN, any delegated requests for that content 1315 may fail, so again the uCDN is likely to want to avoid delegating 1316 those requests to that dCDN. 1318 The CDNI Footprint and Capabilities Interface (FCI) 1319 [I-D.ietf-cdni-framework] provides a means of advertising 1320 capabilities from dCDN to uCDN. Support for optional metadata and 1321 support for optional metadata values may be advertised using the FCI. 1323 This section describes the capabilities advertisement requirements 1324 for the metadata defined in this document. 1326 5.1. Protocol ACL Capabilities 1328 The ProtoclACL object contains a list of Protocol values. The dCDN 1329 MUST advertise which delivery protocols it supports so that the uCDN 1330 knows what type of content requests it can redirect to the dCDN. If 1331 the dCDN does not support a given acquisition or delivery protocol, 1332 the uCDN should not delegate requests requiring those protocols to 1333 the dCDN as the dCDN will not be able to properly acquire or deliver 1334 the content. 1336 ProtocolRules are defined for either acquisition or delivery. For 1337 some CDNs, certain combinations of acquisition and delivery protocols 1338 may not make sense (e.g., RTSP acquisition for HTTP delivery), while 1339 other CDNs may support customized protocol adaptation. ProtocolACL 1340 capabilities are not intended to define which combinations of 1341 protocols should be used. ProtocolACL capabilties are only intended 1342 to describe which protocols the dCDN does or does not support. 1343 Protocol combination restrictions are specified in the metadata 1344 itself and associated with specific groups of content assets. 1346 5.2. Authorization Metadata Capabilities 1348 The Authorization object contains a list of Auth values. The dCDN 1349 MUST advertise in its FCI capabilities which authorization types it 1350 supports. 1352 The definition of the corresponding capabilities and the protocol 1353 used to advertise them are outside the scope of this document and are 1354 expected to be specified as part of the CDNI Footprint and 1355 Capabilities Interface. 1357 6. CDNI Metadata interface 1359 This section specifies an interface to enable a Downstream CDN to 1360 retrieve CDNI Metadata objects from an Upstream CDN. 1362 The interface can be used by a Downstream CDN to retrieve CDNI 1363 Metadata objects either 1365 o Dynamically as required by the Downstream CDN to process received 1366 requests. For example in response to a query from an Upstream CDN 1367 over the CDNI Request Routing Redirection interface (RI) 1368 [I-D.ietf-cdni-redirection] or in response to receiving a request 1369 for content from a User Agent. Or; 1371 o In advance of being required. For example in the case of Pre- 1372 positioned CDNI Metadata acquisition. 1374 The CDNI Metadata interface is built on the principles of RESTful web 1375 services. In particular, this means that requests and responses over 1376 the interface are built around the transfer of representations of 1377 hyperlinked resources. A resource in the context of the CDNI 1378 Metadata interface is any object in the Data Model (as described in 1379 Section 3 through Section 4). 1381 To retrieve CDNI metadata, a CDNI Metadata client (i.e. a client in 1382 the dCDN) first makes a HTTP GET request for the URI of the HostIndex 1383 which provides the CDNI Metadata client with a list of Hostnames for 1384 which the upstream CDN may delegate content delivery to the 1385 downstream CDN. The CDNI Metadata client can then obtain any other 1386 CDNI Metadata objects by making a HTTP GET requests for any linked 1387 Metadats objects it requires. 1389 CDNI Metadata servers (i.e. servers in the uCDN) are free to assign 1390 whatever structure they desire to the URIs for CDNI Metadata objects 1391 and CDNI Metadata clients MUST NOT make any assumptions regarding the 1392 structure of CDNI Metadata URIs or the mapping between CDNI Metadata 1393 objects and their associated URIs. Therefore any URIs present in the 1394 examples below are purely illustrative and are not intended to impose 1395 a definitive structure on CDNI Metadata interface implementations. 1397 6.1. Transport 1399 The CDNI Metadata interface uses HTTP as the underlying protocol 1400 transport. 1402 The HTTP Method in the request defines the operation the request 1403 would like to perform. A server implementation of the CDNI Metadata 1404 interface MUST support the HTTP GET and HEAD methods. 1406 The corresponding HTTP Response returns the status of the operation 1407 in the HTTP Status Code and returns the current representation of the 1408 resource (if appropriate) in the Response Body. HTTP Responses from 1409 servers implementing the CDNI Metadata interface that contain a 1410 response body SHOULD include an ETag to enable validation of cached 1411 versions of returned resources. 1413 The CDNI Metadata interface specified in this document is a read-only 1414 interface. Therefore support for other HTTP methods such as PUT, 1415 POST and DELETE etc. is not specified. An server implementation of 1416 the CDNI Metadata interface SHOULD reject all methods other than GET 1417 and HEAD. 1419 As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata 1420 server implementations MAY make use of any HTTP feature when 1421 implementing the CDNI Metadata interface, for example a CDNI Metadata 1422 server MAY make use of HTTP's caching mechanisms to indicate that the 1423 returned response/representation can be reused without re-contacting 1424 the CDNI Metadata server. 1426 6.2. Retrieval of CDNI Metadata resources 1428 In the general case a CDNI Metadata server makes each instance of an 1429 addressable CDNI Metadata object available via a unique URI and 1430 therefore in order to retrieve CDNI Metadata, a CDNI Metadata client 1431 first makes a HTTP GET request for the URI of the HostIndex which 1432 provides the CDNI Metadata client with a list of Hostnames for which 1433 the upstream CDN may delegate content delivery to the downstream CDN. 1435 In order to retrieve the CDNI Metadata for a particular request the 1436 CDNI Metadata client processes the received HostIndex object and 1437 finds the corresponding HostMetadata entry (by matching the hostname 1438 in the request against the hostnames in the HostMatch). If the 1439 HostMetadata is linked (rather than embedded), the CDNI metadata 1440 client then makes a GET request for the URI specified in the href 1441 property of the Link object which points to the HostMetadata object 1442 itself. 1444 In order to retrieve the most specific metadata for a particular 1445 request, the CDNI metadata client inspects the HostMetadata for 1446 references to more specific PathMetadata objects. If any 1447 PathMetadata match the request (and are linked rather than embedded), 1448 the CDNI metadata client makes another GET request for the 1449 PathMetadata. Each PathMetadata object may also include references 1450 to yet more specific metadata. If this is the case, the CDNI 1451 metadata client continues requesting PathMetadata recursively. 1453 Where a downstream CDN is interconnected with multiple upstream CDNs, 1454 the downstream CDN needs to determine which upstream CDN's CDNI 1455 metadata should be used to handle a particular User Agent request. 1457 When application level redirection (e.g. HTTP 302 redirects) is 1458 being used between CDNs, it is expected that the downstream CDN will 1459 be able to determine the upstream CDN that redirected a particular 1460 request from information contained in the received request (e.g. via 1461 the URI). With knowledge of which upstream CDN routed the request, 1462 the downstream CDN can choose the correct metadata server from which 1463 to obtain the HostIndex. Note that the HostIndex served by each uCDN 1464 may be unique. 1466 In the case of DNS redirection there is not always sufficient 1467 information carried in the DNS request from User Agents to determine 1468 the upstream CDN that redirected a particular request (e.g. when 1469 content from a given host is redirected to a given downstream CDN by 1470 more than one upstream CDN) and therefore downstream CDNs may have to 1471 apply local policy when deciding which upstream CDN's metadata to 1472 apply. 1474 6.3. Bootstrapping 1476 The URI for the HostIndex object of a given upstream CDN needs to be 1477 either configured in, or discovered by, the downstream CDN. All 1478 other objects/resources are then discoverable from the HostIndex 1479 object by following the links in the HostIndex object and the 1480 referenced HostMetadata and PathMetadata objects. 1482 If the URI for the HostIndex object is not manually configured in the 1483 downstream CDN then the HostIndex URI could be discovered. A 1484 mechanism allowing the downstream CDN to discover the URI of the 1485 HostIndex is outside the scope of this document. 1487 6.4. Encoding 1489 Object are resources that may be: 1491 o Addressable, where the object is a resource that may be retrieved 1492 or referenced via its own URI. 1494 o Embedded, where the object is contained within a property of an 1495 addressable object. 1497 In the descriptions of objects we use the term "X contains Y" to mean 1498 that Y is either directly embedded in X or is linked to by X. It is 1499 generally a deployment choice for the uCDN implementation to decide 1500 when and which CDNI Metadata objects to embed and which are made 1501 separately addressable. 1503 6.4.1. MIME Media Types 1505 All MIME types for CDNI Metadata objects are prefixed with 1506 "application/cdni.". The MIME type for each object then contains the 1507 object name of that object as defined by this document. The object 1508 type name is followed by ".v" and the version number of the object 1509 type (e.g. ".v1"). Finally, the encoding type "+json" is appended. 1510 Table 3 3 lists a few examples of the MIME Media Type for some object 1511 (resource) that are retrievable through the CDNI Metadata interface. 1513 +--------------+---------------------------------------+ 1514 | Data Object | MIME Media Type | 1515 +--------------+---------------------------------------+ 1516 | HostIndex | application/cdni.HostIndex.v1+json | 1517 | HostMatch | application/cdni.HostMatch.v1+json | 1518 | HostMetadata | application/cdni.HostMetadata.v1+json | 1519 | PathMatch | application/cdni.PathMatch.v1+json | 1520 | PathMetadata | application/cdni.PathMetadata.v1+json | 1521 | Source | application/cdni.Source.v1+json | 1522 | LocationACL | application/cdni.LocationACL.v1+json | 1523 | LocationRule | application/cdni.LocationRule.v1+json | 1524 +--------------+---------------------------------------+ 1526 Table 3: Example MIME Media Types for CDNI Metadata objects 1528 6.4.2. JSON Encoding of Objects 1530 A CDNI Metadata objects is encoded as a JSON object containing a 1531 dictionary of (key,value) pairs where the keys are the property names 1532 and the values are the associated property values. 1534 The keys of the dictionary are the names of the properties associated 1535 with the object and are therefore dependent on the specific object 1536 being encoded (i.e. dependent on the MIME Media Type of the returned 1537 resource). Likewise, the values associated with each key are 1538 dependent on the specific object being encoded (i.e. dependent on 1539 the MIME Media Type of the returned resource). 1541 Dictionary keys in JSON are case sensitive. By convention any 1542 dictionary key defined by this document (for example the names of 1543 CDNI Metadata object properties) MUST be represented in lowercase. 1545 In addition to the properties specified for each object type, the 1546 keys defined below may be present in any object. 1548 Key: base 1549 Description: Provides a prefix for any relative URLs in the 1550 object. This is similar to the XML base tag [XML-BASE]. If 1551 absent, all URLs in the remainder of the response MUST be 1552 absolute URLs. 1554 Type: URI 1556 Mandatory: No 1558 Key: _links 1560 Description: The links from this object to other addressable 1561 objects. Any property whose value is an object may be replaced 1562 by a link to an object with the same type as the property it 1563 replaces. The keys of the _links dictionary are the names of 1564 the properties being replaced. The values of the dictionary 1565 are Link objects with href set to the URI of the object and 1566 type set to the MIME type of the object being replaced. 1568 Type: Dictionary object of Link objects 1570 Mandatory: Yes 1572 6.4.2.1. Encoded CDNI Metadata Example 1574 [[Editor's Note: We need to double-check that the example(s) below 1575 are correct and use the latest property names/values/structures 1576 defined in the document.]] 1578 A downstream CDN may request the HostIndex and receive the following 1579 object of type "application/cdni.HostIndex.v1+json": 1581 { 1582 "hosts": [ 1583 { 1584 "host": "video.example.com", 1585 "_links": { 1586 "host-metadata" : { 1587 "type": "application/cdni.HostMetadata.v1+json", 1588 "href": "http://metadata.ucdn.example/host1234" 1589 } 1590 } 1591 }, 1592 { 1593 "host": "images.example.com", 1594 "_links": { 1595 "host-metadata" : { 1596 "type": "application/cdni.HostMetadata.v1+json", 1597 "href": "http://metadata.ucdn.example/host5678" 1598 } 1599 } 1600 } 1601 ] 1602 } 1604 If the incoming request has a Host header with "video.example.com" 1605 then the downstream CDN would fetch the next metadata object from 1606 "http://metadata.ucdn.example/host1234" expecting a MIME type of 1607 "application/cdni.HostMetadata.v1+json": 1609 { 1610 "metadata": [ 1611 { 1612 "generic-metadata-type": "application/cdni.SourceMetadata.v1+json", 1613 "generic-metadata-value": { 1614 "sources": [ 1615 { 1616 "_links": { 1617 "auth": { 1618 "auth-type": "application/cdni.Auth.v1+json", 1619 "href": "http://metadata.ucdn.example/auth1234" 1620 } 1621 }, 1622 "endpoint": "acq1.ucdn.example", 1623 "protocol": "ftp" 1624 }, 1625 { 1626 "_links": { 1627 "auth": { 1628 "auth-type": "application/cdni.Auth.v1+json", 1629 "href": "http://metadata.ucdn.example/auth1234" 1630 } 1631 }, 1632 "endpoint": "acq2.ucdn.example", 1633 "protocol": "http" 1634 } 1635 ] 1636 } 1637 }, 1638 { 1639 "generic-metadata-type": "application/cdni.LocationACL.v1+json", 1640 "generic-metadata-value": { 1641 "locations": [ 1642 { 1643 "locations": [ 1644 { 1645 "footprint-type": "IPv4CIDR", 1646 "footprint-value": "192.168.0.0/16" 1647 } 1648 ], 1649 "action": "deny" 1650 } 1651 ] 1652 } 1653 }, 1654 { 1655 "generic-metadata-type": "application/cdni.ProtocolACL.v1+json", 1656 "generic-metadata-value": { 1657 "protocols": [ 1658 { 1659 "protocols": [ 1660 "ftp" 1661 ], 1662 "action": "deny" 1663 } 1664 ] 1665 } 1666 } 1667 ], 1668 "paths": [ 1669 { 1670 "path-pattern": { 1671 "pattern": "/video/trailers/*" 1672 }, 1673 "_links": { 1674 "path-metadata": { 1675 "type": "application/cdni.PathMetadata.v1+json", 1676 "href": "http://metadata.ucdn.example/host1234/pathABC" 1678 } 1679 } 1680 }, 1681 { 1682 "path-pattern": { 1683 "pattern": "/video/movies/*" 1684 }, 1685 "_links": { 1686 "path-metadata": { 1687 "type": "application/cdni.PathMetadata.v1+json", 1688 "href": "http://metadata.ucdn.example/host1234/pathDCE" 1689 } 1690 } 1691 } 1692 ] 1693 } 1695 Suppose the path of the requested resource matches the "/video/ 1696 movies/*" pattern, the next metadata requested would be for 1697 "http://metadata.ucdn.example/host1234/movies" with an expected type 1698 of "application/cdni.PathMetadata.v1+json": 1700 { 1701 "metadata": [], 1702 "paths": [ 1703 { 1704 "path-pattern": { 1705 "pattern": "/videos/movies/hd/*" 1706 }, 1707 "_links": { 1708 "pathmetadata": { 1709 "type": "application/cdni.PathMetadata.v1+json", 1710 "href": 1711 "http://metadata.ucdn.example/host1234/pathABC/path123" 1712 } 1713 } 1714 } 1715 ] 1716 } 1718 Finally, if the path of the requested resource also matches the 1719 "/videos/movies/hd/*" pattern, the downstream CDN would also fetch 1720 the following object from 1721 "http://metadata.ucdn.example/host1234/movies/hd" with MIME type 1722 "application/cdni.PathMetadata.v1+json": 1724 { 1725 "metadata": [ 1726 { 1727 "generic-metadata-type": "application/cdni.TimeWindowACL.v1+json", 1728 "generic-metadata-value": { 1729 "times": [ 1730 "windows": [ 1731 { 1732 "start": "1213948800", 1733 "end": "1327393200" 1734 } 1735 ], 1736 "action": "allow" 1737 ] 1738 } 1739 } 1740 ] 1741 } 1743 6.5. Extensibility 1745 The set of property Metadata may be extended with additional 1746 (standards based or vendor specific) property Metadata. The 1747 GenericMetadata object defined in Section 4.1.7 allows any Metadata 1748 property to be included in either the HostMetadata or PathMetadata 1749 lists. It is expected that additional property Metadata will be 1750 defined in the future and that the documents defining those property 1751 Metadata will be registered in the CDNI GenericMetadata Types 1752 registry Section 7.1. 1754 Note: Identification, within the type name defined for a property 1755 Metadata object, of the organization that defined the extension 1756 property Metadata decreases the possibility of property Metadata type 1757 collisions. 1759 6.5.1. Metadata Enforcement 1761 At any given time, the set of property Metadata supported by the uCDN 1762 may not match the set of property Metadata supported by the dCDN. 1763 The uCDN may or may not know which property Metadata the dCDN 1764 supports. 1766 In the cases where the uCDN supports Metadata that the dCDN does not, 1767 the dCDN MUST enforce the semantics of the "mandatory-to-enforce" 1768 property. If a dCDN does not understand or is unable to perform the 1769 functions associated with any "mandatory-to-enforce" Metadata, the 1770 dCDN MUST NOT service any requests for the corresponding content. 1772 Any specification which defines a new GenericMetadata Type MUST also 1773 define whether or not the new metadata is "mandatory-to-enforce" and 1774 whether or not it is "safe-to-distribute". 1776 Note: Ideally, uCDNs would not delegate content requests to a dCDN 1777 which does not support the "mandatory-to-enforce" Metadata associated 1778 with the content being requested. However, even if the uCDN has a 1779 priori knowledge of the Metadata supported by the dCDN (e.g., via the 1780 CDNI capabilities interface or through out-of-band negotiation 1781 between CDN operators) Metadata support may fluctuate or be 1782 inconsistent (e.g., due to mis-communication, mis-configuration, or 1783 temporary outage). Thus, the dCDN MUST always evaluate all Metadata 1784 associated with content requests and reject any requests where 1785 "mandatory-to-enforce" Metadata associated with the content cannot be 1786 enforced. 1788 6.5.2. Metadata Override 1790 It is possible that new Metadata definitions may obsolete or override 1791 existing property Metadata (e.g., a future revision of the CDNI 1792 Metadata interface may redefine the Auth Metadata or a custom vendor 1793 extension may implement an alternate Auth Metadata option). If 1794 multiple Metadata (e.g., cdni.v2.Auth, vendor1.Auth, and 1795 vendor2.Auth) all override an existing Metadata (e.g., cdni.Auth) and 1796 all are marked as "mandatory-to-enforce", it may be ambiguous which 1797 Metadata should be applied, especially if the functionality of the 1798 Metadata conflict. 1800 As described in Section 3.3, Metadata override only applies to 1801 Metadata objects of the same exact type, found in HostMetadata and 1802 nested PathMetadata structures. The CDNI Metadata interface does not 1803 support enforcement of dependencies between different Metadata types. 1804 It is the responsibility of the CSP and the CDN operators to ensure 1805 that Metadata assigned to a given content do not conflict. 1807 Note: Because Metadata is inherently ordered in GenericMetadata 1808 lists, as well as in the PathMetadata hierarchy and PathMatch lists, 1809 multiple conflicting Metadata types MAY be used, however, Metadata 1810 hierarchies MUST ensure that independent PathMatch root objects are 1811 used to prevent ambiguous or conflicting Metadata definitions. 1813 6.6. Versioning 1815 The version of CDNI Metadata Structural objects is conveyed inside 1816 the MIME-Type that is included in the HTTP Content-Type header. Upon 1817 responding to a request for an object, a metadata server MUST include 1818 a Content-Type header with the MIME-type containing the version 1819 number of the object. HTTP requests sent to a metadata server SHOULD 1820 include an Accept header with the MIME-type (which includes the 1821 version) of the expected object. Metadata clients can specify 1822 multiple MIME-types in the Accept header, for example if a metadata 1823 client is capable of processing two different versions of the same 1824 type of object (defined by different MIME-types) it may decide to 1825 include both in the Accept header. The version of each object 1826 defined by this document is version 1. For example: "Content-Type: 1827 application/cdni.HostIndex.v1+json". 1829 GenericMetadata objects include a "type" property which specifies the 1830 MIME-type of the GenericMetadata value. This MIME-type should also 1831 include a version. Any document which defines a new type of 1832 GenericMetadata MUST specify the version number which it describes. 1833 For example: "application/cdni.Location.v1+json". 1835 7. IANA Considerations 1837 This document requests the registration of the prefix "application/ 1838 cdni" MIME Media Type under the IANA MIME Media Type registry 1839 (http://www.iana.org/assignments/media-types/index.html). 1841 7.1. GenericMetadata Type Registry 1843 CDNI Metadata is distributed as a list of GenericMetadata objects 1844 which specify a type field and a type-specific value field, as 1845 described in Section 4.1.7. In order to prevent namespace collisions 1846 for GenericMetadata object types a new IANA registry is requested for 1847 the "CDNI GenericMetadata Types" namespace. The namespace shall be 1848 split into two partitions: standard and optional. 1850 The standard namespace partition is intended to contain mandatory to 1851 implement capabilities and conforms to the "IETF Review" policy as 1852 defined in [RFC5226]. The registry contains the generic metadata 1853 type name, the RFC number of the specification defining the metadata 1854 type, the version number of the GenericMetadata set to which the 1855 standard capability applies, and boolean values indicating whether or 1856 not the new type is considered "mandatory-to-enforce" or "safe-to- 1857 redistribute" (as defined in Section 4.1.7). 1859 The following table defines the initial values for the standard 1860 partition: 1862 +----------------+---------------+---------+------+------+ 1863 | Type name | Specification | Version | MTE | STR | 1864 +----------------+---------------+---------+------+------+ 1865 | SourceMetadata | RFCthis | 1 | true | true | 1866 | LocationACL | RFCthis | 1 | true | true | 1867 | TimeWindowACL | RFCthis | 1 | true | true | 1868 | ProtocolACL | RFCthis | 1 | true | true | 1869 | Auth | RFCthis | 1 | true | true | 1870 | Cache | RFCthis | 1 | true | true | 1871 | Grouping | RFCthis | 1 | true | true | 1872 +----------------+---------------+---------+------+------+ 1874 The initial MI version number is set to 1. All of the initial 1875 GenericMetadata types are considered mandatory to implement for 1876 version 1. The version field should be incremented when new 1877 GenericMetadata type sets are added to the registry. 1879 The "optional" namespace partition conforms to the "Expert Review" 1880 policy as defined in [RFC5226]. The expert review is intended to 1881 prevent namespace hoarding and to prevent the definition of redundant 1882 GenericMetadata types. Vendors defining new GenericMetadata types 1883 which conflict with existing GenericMetadata types follow the 1884 guidelines for the "Specification Required" policy as defined in 1885 [RFC5226]. The Version field in the registry is set to "-1" 1886 (negative one) for non-standard GenericMetadata types. 1888 As with the initial GenericMetadata types defined in Section 4.2, 1889 future GenericMetadata type registrations will specify the 1890 information necessary for constructing and decoding the 1891 GenericMetadata object. This information includes the list of 1892 properties contained within the GenericMetadata object, and for each 1893 property, the specification should include a description, a type, and 1894 whether or not the given property is mandatory to specify. 1896 Any document which defines a new GenericMetadata has to: 1898 1. Allocate a new type in the GenericMetadata Type Registry 1899 (Section 7). Generic Metadata types should be descriptive and 1900 may be hierarchnical to support aggregating groups of properties 1901 for the purpose of readability and for avoiding conflicts between 1902 vendor defined extensions. A dotted alpha-numeric notation is 1903 suggested for human readability. 1905 2. Define the set of properties associated with the new type. 1907 3. For each property, define a name, description, type, and whether 1908 or not the property is mandatory-to-specify. 1910 4. Specify whether or not the new type is "mandatory-to-enforce" (vs 1911 optional-to-enforce). 1913 5. Describe the semantics of the new type including its purpose and 1914 example of a use case to which it applies. 1916 7.1.1. GenericMetadata Sub-Registries 1918 Some of the initial standard GenericMetadata objects contain 1919 enumerated types which require registration (i.e., LocationACL 1920 footprint types, ProtocolACL protocols, and Auth protocols). The 1921 following sections define the initial values for these 1922 GenericMetadata type sub-registries. 1924 7.1.1.1. Footprint Sub-Registry 1926 The "CDNI Metadata Footprint Types" namespace defines the valid 1927 Footprint object type values used by the Footprint object in 1928 Section 4.2.2.2. Additions to the Footprint type namespace conform 1929 to the "Expert Review" policy as defined in [RFC5226]. The expert 1930 review should verify that new type definitions do not duplicate 1931 existing type definitions and prevent gratuitous additions to the 1932 namespace. 1934 The following table defines the initial Footprint type values: 1936 +-------------+-------------------------------------+---------------+ 1937 | Type name | Description | Specification | 1938 +-------------+-------------------------------------+---------------+ 1939 | IPv4CIDR | IPv4 address block using slash | RFCthis | 1940 | | prefix length notation (e.g., | | 1941 | | 192.168.0.16/28). Single IP | | 1942 | | addresses can be expressed as /32. | | 1943 | IPv6CIDR | IPv6 address block using slash | RFCthis | 1944 | | prefix length notation (e.g., | | 1945 | | fc80::0010/124). Single IP | | 1946 | | addresses can be expressed as /128. | | 1947 | ASN | Autonomous System (AS) Number | RFCthis | 1948 | CountryCode | ISO 3166-1 alpha-2 code | RFCthis | 1949 +-------------+-------------------------------------+---------------+ 1951 7.1.1.2. Protocol Sub-Registry 1953 The "CDNI Metadata Protocols" namespace defines the valid Protocol 1954 object values in Section 4.3.2, used by the SourceMetadata and 1955 ProtocolACL objects. Additions to the Protocol namespace conform to 1956 the "Expert Review" policy as defined in [RFC5226]. The expert 1957 review should verify that new type definitions do not duplicate 1958 existing type definitions and prevent gratuitous additions to the 1959 namespace. 1961 The following table defines the initial Protocol values: 1963 +----------+----------------+---------------------------------------+ 1964 | Protocol | Description | Specification | 1965 +----------+----------------+---------------------------------------+ 1966 | HTTP | Hypertext | RFC2616 | 1967 | | Transfer | | 1968 | | Protocol -- | | 1969 | | HTTP/1.1 | | 1970 | HTTPS | HTTP Over TLS | RFC2818 | 1971 | RTSP | Real Time | RFC2326 | 1972 | | Streaming | | 1973 | | Protocol | | 1974 | RTMP | Real-Time | http://www.adobe.com/devnet/rtmp.html | 1975 | | Messaging | | 1976 | | Protocol | | 1977 | FTP | FILE TRANSFER | RFC959 | 1978 | | PROTOCOL | | 1979 | SFTP | SSH File | N/A | 1980 | | Transfer | | 1981 | | Protocol | | 1982 | SCP | Secure Copy | N/A | 1983 | fasp | Aspera fast, | N/A | 1984 | | adaptive, | | 1985 | | secure | | 1986 | | protocol | | 1987 +----------+----------------+---------------------------------------+ 1989 7.1.1.3. Authentication Sub-Registry 1991 The "CDNI Metadata Auth" namespace defines the valid Auth object 1992 types used by the Auth object in Section 4.2.6. Additions to the 1993 Auth namespace conform to the "Expert Review" policy as defined in 1994 [RFC5226]. The expert review should verify that new type definitions 1995 do not duplicate existing type definitions and prevent gratuitous 1996 additions to the namespace. 1998 The following table defines the initial Auth type values: 2000 +-------------+-------------------------------------+---------------+ 2001 | Type name | Description | Specification | 2002 +-------------+-------------------------------------+---------------+ 2003 | credentials | Simple username and password | RFCthis | 2004 | | authentication as defined by | | 2005 | | Section 4.2.6.1. | | 2006 +-------------+-------------------------------------+---------------+ 2008 8. Security Considerations 2010 The CDNI Metadata interface is expected to be secured as a function 2011 of the transport protocol (e.g. HTTP authentication [RFC2617], HTTPS 2012 [RFC2818], or inter-domain IPSec). 2014 If a malicious metadata server is contacted by a downstream CDN, the 2015 malicious server may provide metadata to the downstream CDN which 2016 denies service for any piece of content to any user agent. The 2017 malicious server may also provide metadata which directs a downstream 2018 CDN to a malicious origin server instead of the actual origin server. 2019 The dCDN is expected to authenticate the server to prevent this 2020 situation (e.g. by using HTTPS and validating the server's 2021 certificate). 2023 A malicious metadata client could request metadata for a piece of 2024 content from an upstream CDN. The metadata information may then be 2025 used to glean information regarding the uCDN or to contact an 2026 upstream origin server. The uCDN is expected to authenticate client 2027 requests to prevent this situation. 2029 9. Acknowledgements 2031 The authors would like to thank David Ferguson and Francois Le 2032 Faucheur for their valuable comments and input to this document. 2034 10. Contributing Authors 2036 [RFC Editor Note: Please move the contents of this section to the 2037 Authors' Addresses section prior to publication as an RFC.] 2039 Grant Watson 2040 Velocix (Alcatel-Lucent) 2041 3 Ely Road 2042 Milton, Cambridge CB24 6AA 2043 UK 2045 Email: gwatson@velocix.com 2047 11. References 2049 11.1. Normative References 2051 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2052 Requirement Levels", BCP 14, RFC 2119, March 1997. 2054 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 2055 Leach, P., Luotonen, A., and L. Stewart, "HTTP 2056 Authentication: Basic and Digest Access Authentication", 2057 RFC 2617, June 1999. 2059 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2061 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2062 Architecture", RFC 4291, February 2006. 2064 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2065 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2066 May 2008. 2068 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2069 Address Text Representation", RFC 5952, August 2010. 2071 11.2. Informative References 2073 [I-D.ietf-cdni-framework] 2074 Peterson, L., Davie, B., and R. Brandenburg, "Framework 2075 for CDN Interconnection", draft-ietf-cdni-framework-14 2076 (work in progress), June 2014. 2078 [I-D.ietf-cdni-redirection] 2079 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 2080 Redirection Interface for CDN Interconnection", draft- 2081 ietf-cdni-redirection-02 (work in progress), April 2014. 2083 [I-D.ietf-cdni-requirements] 2084 Leung, K. and Y. Lee, "Content Distribution Network 2085 Interconnection (CDNI) Requirements", draft-ietf-cdni- 2086 requirements-17 (work in progress), January 2014. 2088 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2089 Resource Identifier (URI): Generic Syntax", STD 66, RFC 2090 3986, January 2005. 2092 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2093 Distribution Network Interconnection (CDNI) Problem 2094 Statement", RFC 6707, September 2012. 2096 [XML-BASE] 2097 Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second 2098 Edition) - http://www.w3.org/TR/xmlbase/", January 2009. 2100 Authors' Addresses 2102 Ben Niven-Jenkins 2103 Velocix (Alcatel-Lucent) 2104 3 Ely Road 2105 Milton, Cambridge CB24 6AA 2106 UK 2108 Email: ben@velocix.com 2110 Rob Murray 2111 Velocix (Alcatel-Lucent) 2112 3 Ely Road 2113 Milton, Cambridge CB24 6AA 2114 UK 2116 Email: rmurray@velocix.com 2118 Matt Caulfield 2119 Cisco Systems 2120 1414 Massachusetts Avenue 2121 Boxborough, MA 01719 2122 USA 2124 Phone: +1 978 936 9307 2125 Email: mcaulfie@cisco.com 2127 Kent Leung 2128 Cisco Systems 2129 3625 Cisco Way 2130 San Jose 95134 2131 USA 2133 Phone: +1 408 526 5030 2134 Email: kleung@cisco.com 2135 Kevin J. Ma 2136 Ericsson 2137 43 Nagog Park 2138 Acton, MA 01720 2139 USA 2141 Phone: +1 978-844-5100 2142 Email: kevin.j.ma@ericsson.com