idnits 2.17.1 draft-ietf-cdni-metadata-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 27, 2015) is 3196 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Object' is mentioned on line 326, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'ISO3166-1' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5861 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-11 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 7540 (Obsoleted by RFC 9113) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Niven-Jenkins 3 Internet-Draft R. Murray 4 Intended status: Standards Track Velocix (Alcatel-Lucent) 5 Expires: January 28, 2016 M. Caulfield 6 Cisco Systems 7 K. Ma 8 Ericsson 9 July 27, 2015 11 CDN Interconnection Metadata 12 draft-ietf-cdni-metadata-11 14 Abstract 16 The Content Delivery Networks Interconnection (CDNI) metadata 17 interface enables interconnected Content Delivery Networks (CDNs) to 18 exchange content distribution metadata in order to enable content 19 acquisition and delivery. The CDNI metadata associated with a piece 20 of content provides a downstream CDN with sufficient information for 21 the downstream CDN to service content requests on behalf of an 22 upstream CDN. This document describes both a base set of CDNI 23 metadata and the protocol for exchanging that metadata. 25 Requirements Language 27 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 28 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 29 document are to be interpreted as described in RFC 2119 [RFC2119]. 31 Status of This Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on January 28, 2016. 48 Copyright Notice 50 Copyright (c) 2015 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5 68 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 69 3. CDNI Metadata object model . . . . . . . . . . . . . . . . . 6 70 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, 71 PatternMatch and PathMetadata objects . . . . . . . . . . 8 72 3.2. Generic CDNI Metadata Objects . . . . . . . . . . . . . . 10 73 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13 74 4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 14 75 4.1. Definitions of the CDNI structural metadata objects . . . 15 76 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15 77 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 16 78 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17 79 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 18 80 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 19 81 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 20 82 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 21 83 4.2. Definitions of the initial set of CDNI Generic Metadata 84 objects . . . . . . . . . . . . . . . . . . . . . . . . . 23 85 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 23 86 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 24 87 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 25 88 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 27 89 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 28 90 4.2.3. TimeWindowACL . . . . . . . . . . . . . . . . . . . . 29 91 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 31 92 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 32 93 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 32 94 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 33 95 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 34 96 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 34 97 4.2.7. Auth . . . . . . . . . . . . . . . . . . . . . . . . 35 98 4.2.7.1. BasicAuth . . . . . . . . . . . . . . . . . . . . 36 99 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 37 100 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 38 101 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 38 102 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 39 103 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 39 104 4.3.4. Time . . . . . . . . . . . . . . . . . . . . . . . . 40 105 4.3.5. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 40 106 4.3.6. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 40 107 4.3.7. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 40 108 4.3.8. CountryCode . . . . . . . . . . . . . . . . . . . . . 41 109 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 41 110 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 41 111 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 42 112 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 43 113 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 44 114 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 44 115 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 45 116 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 46 117 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 46 118 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 47 119 6.9. Media Types . . . . . . . . . . . . . . . . . . . . . . . 47 120 6.10. Complete CDNI Metadata Example . . . . . . . . . . . . . 48 121 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 122 7.1. CDNI Metadata Footprint Types Registry . . . . . . . . . 53 123 7.2. CDNI Metadata Protocol Types Registry . . . . . . . . . . 54 124 7.3. CDNI Metadata Auth Types Registry . . . . . . . . . . . . 54 125 8. Security Considerations . . . . . . . . . . . . . . . . . . . 54 126 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 55 127 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 55 128 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 55 129 8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 56 130 8.5. Securing the CDNI Metadata interface . . . . . . . . . . 56 131 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 132 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 57 133 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 134 11.1. Normative References . . . . . . . . . . . . . . . . . . 57 135 11.2. Informative References . . . . . . . . . . . . . . . . . 58 136 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 138 1. Introduction 140 Content Delivery Networks Interconnection (CDNI) [RFC6707] enables a 141 downstream Content Delivery Network (dCDN) to service content 142 requests on behalf of an upstream CDN (uCDN). 144 The CDNI metadata interface is discussed in [RFC7336] along with four 145 other interfaces that may be used to compose a CDNI solution (CDNI 146 Control interface, CDNI Request Routing Redirection interface, CDNI 147 Footprint & Capabilities Advertisement interface and CDNI Logging 148 interface). [RFC7336] describes each interface, and the 149 relationships between them. The requirements for the CDNI metadata 150 interface are specified in [RFC7337]. 152 The CDNI metadata associated with a piece of content (or with a set 153 of content) provides a dCDN with sufficient information for servicing 154 content requests on behalf of an uCDN in accordance with the policies 155 defined by the uCDN. 157 This document focuses on the CDNI metadata interface which enables a 158 dCDN to obtain CDNI metadata from an uCDN so that the dCDN can 159 properly process and respond to: 161 o Redirection requests received over the CDNI Request Routing 162 Redirection interface [I-D.ietf-cdni-redirection]. 164 o Content requests received directly from User Agents. 166 Specifically, this document specifies: 168 o A data structure for mapping content requests and redirection 169 requests to CDNI metadata objects (Section 3 and Section 4.1). 171 o An initial set of CDNI Generic metadata objects (Section 4.2). 173 o A HTTP web service for the transfer of CDNI metadata (Section 6). 175 1.1. Terminology 177 This document reuses the terminology defined in [RFC6707]. 179 Additionally, the following terms are used throughout this document 180 and are defined as follows: 182 o Object - a collection of properties. 184 o Property - a key and value pair where the key is a property name 185 and the value is the property value or another object. 187 This document uses the phrase "[Object] A contains [Object] B" for 188 simplicity when a strictly accurate phrase would be "[Object] A 189 contains or references (via a Link object) [Object] B". 191 1.2. Supported Metadata Capabilities 193 Only the metadata for a small set of initial capabilities is 194 specified in this document. This set provides the minimum amount of 195 metadata for basic CDN interoperability while still meeting the 196 requirements set forth by [RFC7337]. 198 The following high-level functionality can be configured via the CDNI 199 metadata objects specified in Section 4: 201 o Acquisition Source: Metadata for allowing a dCDN to fetch content 202 from a uCDN. 204 o Delivery Access Control: Metadata for restricting (or permitting) 205 access to content based on any of the following factors: 207 * Location 209 * Time Window 211 * Delivery Protocol 213 o Delivery Authorization: Metadata for authorizing dCDN user agent 214 requests. 216 o Cache Control: Metadata for controlling cache behavior of the 217 dCDN. 219 The metadata encoding described by this document is extensible in 220 order to allow for future additions to this list. 222 The set of metadata specified in this document, covering the initial 223 capabilities above, is only able to support CDN interconnection for 224 the delivery of content by a dCDN using HTTPv1.1 [RFC7230] and for a 225 dCDN to be able to acquire content from a uCDN using either HTTPv1.1 226 or HTTPv1.1 over TLS [RFC2818]. 228 Supporting CDN interconnection for the delivery of content using 229 unencrypted HTTPv2.0 [RFC7540] (as well as for a dCDN to acquire 230 content using unencrypted HTTPv2.0 or HTTPv2.0 over TLS) requires the 231 registration of these protocol names in the CDNI Metadata Protocol 232 Registry. 234 Supporting CDN interconnection for the delivery of content using 235 HTTPv1.1 over TLS or HTTPv2.0 over TLS requires specifying additional 236 metadata objects to carry the properties required to establish a TLS 237 session, for example metadata to describe the certificate to use as 238 part of the TLS handshake. 240 2. Design Principles 242 The CDNI metadata interface was designed to achieve the following 243 objectives: 245 1. Cacheability of CDNI metadata objects. 247 2. Deterministic mapping from redirection requests and content 248 requests to CDNI metadata properties. 250 3. Support for DNS redirection as well as application-specific 251 redirection (for example HTTP redirection). 253 4. Minimal duplication of CDNI metadata. 255 5. Leveraging of existing protocols. 257 Cacheability improves the latency of acquiring metadata while 258 maintaining its freshness, and therefore improves the latency of 259 serving content requests and redirection requests, without 260 sacrificing accuracy. The CDNI metadata interface uses HTTP and its 261 existing caching mechanisms to achieve CDNI metadata cacheability. 263 Deterministic mappings from content to metadata properties eliminates 264 ambiguity and ensures that policies are applied consistently by all 265 dCDNs. 267 Support for both HTTP and DNS redirection ensures that the CDNI 268 metadata interface can be used for HTTP and DNS redirection and also 269 meets the same design principles for both HTTP and DNS based 270 redirection schemes. 272 Minimal duplication of CDNI metadata provides space efficiency on 273 storage in the CDNs, on caches in the network, and across the network 274 between CDNs. 276 Leveraging existing protocols avoids reinventing common mechanisms 277 such as data structure encoding (by leveraging I-JSON [RFC7493]) and 278 data transport (by leveraging HTTP [RFC7230]). 280 3. CDNI Metadata object model 282 The CDNI metadata object model describes a data structure for mapping 283 redirection requests and content requests to metadata properties. 284 Metadata properties describe how to acquire content from an uCDN, 285 authorize access to content, and deliver content from a dCDN. The 286 object model relies on the assumption that these metadata properties 287 may be aggregated based on the hostname of the content and 288 subsequently on the resource path (URI) of the content. The object 289 model associates a set of CDNI metadata properties with a Hostname to 290 form a default set of metadata properties for content delivered on 291 behalf of that Hostname. That default set of metadata properties can 292 be overridden by properties that apply to specific paths within a 293 URI. 295 Different Hostnames and URI paths will be associated with different 296 sets of CDNI metadata properties in order to describe the required 297 behaviour when a dCDN surrogate or request router is processing User 298 Agent requests for content at that Hostname or URI path. As a result 299 of this structure, significant commonality may exist between the CDNI 300 metadata properties specified for different Hostnames, different URI 301 paths within a Hostname and different URI paths on different 302 Hostnames. For example the definition of which User Agent IP 303 addresses should be treated as being grouped together into a single 304 network or geographic location is likely to be common for a number of 305 different Hostnames. Another example is that although a uCDN is 306 likely to have several different policies configured to express geo- 307 blocking rules, it is likely that a single geo-blocking policy would 308 be applied to multiple Hostnames delivered through the CDN. 310 In order to enable the CDNI metadata for a given Hostname or URI Path 311 to be decomposed into sets of CDNI metadata properties that can be 312 reused by multiple Hostnames and URI Paths, the CDNI metadata 313 interface specified in this document splits the CDNI metadata into a 314 number of objects. Efficiency is improved by enabling a single CDNI 315 metadata object (that is shared across Hostname and/or URI paths) to 316 be retrieved and stored by a dCDN once, even if it is referenced by 317 the CDNI metadata of multiple Hostnames or of multiple URI paths. 319 Important Note: Any CDNI metadata object A that contains another CDNI 320 metadata object B may, instead of including the second object B 321 embedded within object A, include a Link object that contains a URI 322 that can be dereferenced to retrieve the complete serialized 323 representation of the second metadata object B. The remainder of 324 this document uses the phrase "[Object] A contains [Object] B" for 325 simplicity when a strictly accurate phrase would be "[Object] A 326 contains or references (via a Link object) [Object] B". It is 327 generally a deployment choice for the uCDN implementation to decide 328 when and which CDNI metadata objects to embed and which to make 329 available as separate resources via Link objects. 331 Section 3.1 introduces a high level description of the HostIndex, 332 HostMatch, HostMetadata, PathMatch, PatternMatch and PathMetadata 333 objects and describes the relationships between those objects. 335 Section 3.2 introduces a high level description of the CDNI 336 GenericMetadata object which represents the level at which CDNI 337 metadata override occurs between HostMetadata and PathMetadata 338 objects. 340 Section 4 describes in detail the specific CDNI metadata objects and 341 properties specified by this document which can be contained within a 342 CDNI GenericMetadata object. 344 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch and 345 PathMetadata objects 347 The relationships between the HostIndex, HostMatch, HostMetadata, 348 PathMatch, PatternMatch and PathMetadata objects are described in 349 Figure 1. 351 +---------+ +---------+ +------------+ 352 |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ 353 +---------+ +---------+ +------+-----+ | 354 | | 355 (*) | 356 | V 357 --> Contains or References V ****************** 358 (1) One and only one +---------+ *Generic Metadata* 359 (*) Zero or more +--->|PathMatch| * Objects * 360 | +----+---++ ****************** 361 | | | ^ 362 (*) (1) (1) +------------+ | 363 | | +->|PatternMatch| | 364 | V +------------+ | 365 | +------------+ | 366 +--+PathMetadata+-------(*)------+ 367 +------------+ 369 Figure 1: Relationships between CDNI Metadata Objects (Diagram 370 Representation) 372 A HostIndex object (see Section 4.1.1) contains a list of HostMatch 373 objects (see Section 4.1.2) that contain Hostnames (and/or IP 374 addresses) for which content requests may be delegated to the dCDN. 375 The HostIndex is the starting point for accessing the uCDN CDNI 376 metadata data store. It enables the dCDN to deterministically 377 discover, on receipt of a User Agent request for content, which other 378 CDNI metadata objects it requires in order to deliver the requested 379 content. 381 The HostIndex links Hostnames (and/or IP addresses) to HostMetadata 382 objects (see Section 4.1.3) via HostMatch objects. A HostMatch 383 object defines a Hostname (or IP address) to match against a 384 requested host and contains a HostMetadata object. 386 HostMetadata objects contain the default CDNI metadata within 387 GenericMetadata objects (see Section 4.1.7) required to serve content 388 for that host. When looking up CDNI metadata, the dCDN looks up the 389 requested Hostname (or IP address) against the HostMatch entries in 390 the HostIndex, from there it can find HostMetadata which describes 391 the default properties for each host as well as PathMetadata objects 392 (see Section 4.1.6), via PathMatch objects (see Section 4.1.4), which 393 may override those properties for given URI paths within the host. 394 The CDNI metadata contained in HostMetadata objects is applied to 395 content requests for which there is not more specific metadata, i.e. 396 for content requests that do not match any of the PathMatch objects 397 contained by that HostMetadata object and its child PathMetadata 398 objects. 400 HostMetadata can also contain PathMatch objects. PathMatch objects 401 define patterns, contained inside PatternMatch objects (see 402 Section 4.1.5), to match against the requested URI path, and contain 403 PathMetadata objects which contain the GenericMetadata objects to be 404 applied when a content request matches against the defined URI path 405 pattern. PatternMatch objects contain the pattern strings and flags 406 that describe the URI path that a PathMatch applies to. 408 PathMetadata objects override the CDNI metadata in the HostMetadata 409 object or one or more parent PathMetadata objects with more specific 410 CDNI metadata that applies to content requests matching the URI 411 pattern defined in the PatternMatch object of that PathMatch object. 412 A PathMetadata object may also contain PathMatch objects in order to 413 recursively define more specific URI paths that require different 414 (e.g., more specific) CDNI metadata to this one. 416 A GenericMetadata object contains individual CDNI metadata objects 417 which define the specific policies and attributes needed to properly 418 deliver the associated content. For example, a GenericMetadata 419 object may describe the source from which a CDN may acquire a piece 420 of content. The GenericMetadata object is an atomic unit that may be 421 referenced by HostMetadata and/or PathMetadata objects. 423 For example, if "example.com" is a content provider, a HostMatch 424 object may include an entry for "example.com" with the URI of the 425 associated HostMetadata object. The HostMetadata object for 426 "example.com" describes the metadata properties which apply to 427 "example.com" and could contain PathMatches for "example.com/ 428 movies/*" and "example.com/music/*", which in turn reference 429 corresponding PathMetadata objects that contain the CDNI metadata 430 objects for those more specific URI paths. The PathMetadata object 431 for "example.com/movies/*" describes CDNI metadata which apply to 432 that URI path and could contain a PathMatch object for 433 "example.com/movies/hd/*" which would reference the corresponding 434 PathMetadata object for the "example.com/movies/hd/" path prefix. 436 The relationships in Figure 1 are also represented in tabular format 437 in Table 1 below. 439 +--------------+----------------------------------------------------+ 440 | Data Object | Objects it contains or references | 441 +--------------+----------------------------------------------------+ 442 | HostIndex | 0 or more HostMatch objects. | 443 | HostMatch | 1 HostMetadata object. | 444 | HostMetadata | 0 or more PathMatch objects. 0 or more | 445 | | GenericMetadata objects. | 446 | PathMatch | 1 PatternMatch object. 1 PathMetadata object. | 447 | PatternMatch | Does not contain or reference any other objects. | 448 | PathMetadata | 0 or more PathMatch objects. 0 or more | 449 | | GenericMetadata objects. | 450 +--------------+----------------------------------------------------+ 452 Table 1: Relationships between CDNI Metadata Objects 453 (Table Representation) 455 3.2. Generic CDNI Metadata Objects 457 The HostMetadata and PathMetadata objects contain other CDNI metadata 458 objects that contain properties which describe how User Agent 459 requests for content should be processed, for example where to 460 acquire the content from, authorization rules that should be applied, 461 geo-blocking restrictions and so on. Each such CDNI metadata object 462 is a specialization of a CDNI GenericMetadata object. The 463 GenericMetadata object abstracts the basic information required for 464 metadata override and metadata distribution, from the specifics of 465 any given property (e.g., property semantics, enforcement options, 466 etc.). 468 The GenericMetadata object defines the type of properties contained 469 within it as well as whether or not the properties are "mandatory-to- 470 enforce". If the dCDN does not understand or support the property 471 type and the property type is "mandatory-to-enforce", the dCDN MUST 472 NOT serve the content to the User Agent. If the dCDN does not 473 understand or support the property type and the property type is not 474 "mandatory-to-enforce", then that GenericMetadata object may be 475 safely ignored and the dCDN MUST process the content request in 476 accordance with the rest of the CDNI metadata. 478 Although a CDN MUST NOT serve content to a User Agent if a 479 "mandatory-to-enforce" property cannot be enforced, it may be "safe- 480 to-redistribute" that metadata to another CDN without modification. 481 For example, in the cascaded CDN case, a transit CDN (tCDN) may pass 482 through "mandatory-to-enforce" metadata to a dCDN. For metadata 483 which does not require customization or translation (i.e., metadata 484 that is "safe-to-redistribute"), the data representation received off 485 the wire MAY be stored and redistributed without being natively 486 understood or supported by the transit CDN. However, for metadata 487 which requires translation, transparent redistribution of the uCDN 488 metadata values might not be appropriate. Certain metadata may be 489 safely, though possibly not optimally, redistributed unmodified. For 490 example, source acquisition address may not be optimal if 491 transparently redistributed, but might still work. 493 Redistribution safety MUST be specified for each GenericMetadata. If 494 a CDN does not understand or support a given GenericMetadata property 495 type and the property type is not "safe-to-redistribute", before 496 redistributing the metadata, the CDN MUST set the "incomprehensible" 497 flag for the GenericMetadata object that it did not understand and 498 was marked as not "safe-to-redistribute". The "incomprehensible" 499 flag signals to a dCDN that the metadata was not properly transformed 500 by the transit CDN. A CDN MUST NOT attempt to use metadata that has 501 been marked as "incomprehensible" by a uCDN. 503 Transit CDNs MUST NOT change the value of "mandatory-to-enforce" or 504 "safe-to-redistribute" when propagating metadata to a dCDN. Although 505 a transit CDN may set the value of "incomprehensible" to true, a 506 transit CDN MUST NOT change the value of "incomprehensible" from true 507 to false. 509 Table 2 describes the action to be taken by a transit CDN (tCDN) for 510 the different combinations of "mandatory-to-enforce" (MtE) and "safe- 511 to-redistribute" (StR) properties, when the tCDN either does or does 512 not understand the metadata in question: 514 +-------+-------+------------+--------------------------------------+ 515 | MtE | StR | Metadata | Action | 516 | | | Understood | | 517 | | | by tCDN | | 518 +-------+-------+------------+--------------------------------------+ 519 | False | True | True | Can serve and redistribute. | 520 | False | True | False | Can serve and redistribute. | 521 | False | False | False | Can serve. MUST set | 522 | | | | "incomprehensible" to True when | 523 | | | | redistributing. | 524 | False | False | True | Can serve. Can redistribute either | 525 | | | | by transforming not StR metadata (if | 526 | | | | the CDN knows how to do so safely), | 527 | | | | otherwise MUST set | 528 | | | | "incomprehensible" to True when | 529 | | | | redistributing. | 530 | True | True | True | Can serve and redistribute. | 531 | True | True | False | MUST NOT serve but can redistribute. | 532 | True | False | True | Can serve. Can redistribute either | 533 | | | | by transforming not StR metadata (if | 534 | | | | the CDN knows how to do so safely), | 535 | | | | otherwise MUST set | 536 | | | | "incomprehensible" to True when | 537 | | | | redistributing. | 538 | True | False | False | MUST NOT serve. MUST set | 539 | | | | "incomprehensible" to True when | 540 | | | | redistributing. | 541 +-------+-------+------------+--------------------------------------+ 543 Table 2: Action to be taken by a tCDN for the different combinations 544 of MtE and StR properties 546 Table 3 describes the action to be taken by a dCDN for the different 547 combinations of "mandatory-to-enforce" (MtE) and "incomprehensible" 548 (Incomp) properties, when the dCDN either does or does not understand 549 the metadata in question: 551 +-------+--------+--------------+-----------------------------------+ 552 | MtE | Incomp | Metadata | Action | 553 | | | Understood | | 554 | | | by dCDN | | 555 +-------+--------+--------------+-----------------------------------+ 556 | False | False | True | Can serve. | 557 | False | True | True | Can serve but MUST NOT | 558 | | | | interpret/apply any metadata | 559 | | | | marked incomprehensible. | 560 | False | False | False | Can serve. | 561 | False | True | False | Can serve but MUST NOT | 562 | | | | interpret/apply any metadata | 563 | | | | marked incomprehensible. | 564 | True | False | True | Can serve. | 565 | True | True | True | MUST NOT serve. | 566 | True | False | False | MUST NOT serve. | 567 | True | True | False | MUST NOT serve. | 568 +-------+--------+--------------+-----------------------------------+ 570 Table 3: Action to be taken by a dCDN for the different combinations 571 of MtE and Incomp properties 573 3.3. Metadata Inheritance and Override 575 In the metadata object model, a HostMetadata object may contain 576 multiple PathMetadata objects (via PathMatch objects). Each 577 PathMetadata object may in turn contain other PathMetadata objects. 578 HostMetadata and PathMetadata objects form an inheritance tree where 579 each node in the tree inherits or overrides the property values set 580 by its parent. 582 GenericMetadata objects of a given type override all GenericMetadata 583 objects of the same type previously defined by any parent object in 584 the tree. GenericMetadata objects of a given type previously defined 585 by a parent object in the tree are inherited when no object of the 586 same type is defined by the child object. For example, if 587 HostMetadata for the host "example.com" contains GenericMetadata 588 objects of type LocationACL and TimeWindowACL, while a PathMetadata 589 object which applies to "example.com/movies/*" defines an alternate 590 GenericMetadata object of type TimeWindowACL, then: 592 o the TimeWindowACL defined in the PathMetadata would override the 593 TimeWindowACL defined in the HostMetadata for all User Agent 594 requests for content under "example.com/movies/", and 596 o the LocationACL defined in the HostMetadata would be inherited for 597 all User Agent requests for content under "example.com/movies/". 599 A single HostMetadata or PathMetadata object MUST NOT contain 600 multiple GenericMetadata objects of the same type. If a list of 601 GenericMetadata contains objects of duplicate types, the receiver 602 MUST ignore all but the first object of each type. 604 4. CDNI Metadata objects 606 Section 4.1 provides the definitions of each metadata object type 607 introduced in Section 3. These metadata objects are described as 608 structural metadata objects as they provide the structure for the 609 inheritance tree and identify which specific GenericMetadata objects 610 apply to a given User Agent content request. 612 Section 4.2 provides the definitions for a base set of core metadata 613 objects which can be contained within a GenericMetadata object. 614 These metadata objects govern how User Agent requests for content are 615 handled. GenericMetadata objects can contain other GenericMetadata 616 sub-objects (i.e., GenericMetadata sub-objects contained within the 617 GenericMetadata object that refers to that GenericMetadata sub- 618 object). As with all CDNI metadata objects, the value of the 619 GenericMetadata sub-objects can be either a complete serialized 620 representation of the sub-object, or a Link object that contains a 621 URI that can be dereferenced to retrieve the complete serialized 622 representation of the property sub-object. 624 Section 6.5 discusses the ability to extend the base set of 625 GenericMetadata objects specified in this document with additional 626 standards based or vendor specific GenericMetadata objects that may 627 be defined in the future in separate documents. 629 dCDNs and tCDNs MUST support parsing of all CDNI metadata objects 630 specified in this document. A dCDN does not have to implement the 631 underlying functionality represented by the metadata object, though 632 that may restrict the content that a given dCDN can serve. uCDNs as 633 generators of CDNI metadata only need to support generating the CDNI 634 metadata that they need in order to express the policies and 635 treatment required by the content they are describing. 637 CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] 638 containing a dictionary of (key,value) pairs where the keys are the 639 property names and the values are the associated property values. 640 See Section 6.4 for more details of the specific encoding rules for 641 CDNI metadata objects. 643 Note: In the following sections, the term "mandatory-to-specify" is 644 used to convey which properties MUST be included for a given 645 structural or GenericMetadata object. When mandatory-to-specify is 646 specified as "Yes" by this document for an individual property, it 647 means that if the object containing that property is included in a 648 metadata response, then the mandatory-to-specify property MUST also 649 be included (directly or by reference) in the response, e.g., a 650 HostMatch property object without a host to match against does not 651 make sense, therefore, the host property is mandatory-to-specify 652 inside a HostMatch object. 654 4.1. Definitions of the CDNI structural metadata objects 656 Each of the sub-sections below describe the structural objects 657 introduced in Section 3.1. 659 4.1.1. HostIndex 661 The HostIndex object is the entry point into the CDNI metadata 662 hierarchy. It contains a list of HostMatch objects. An incoming 663 content request is checked against the Hostname (or IP address) 664 specified by each of the listed HostMatch objects to find the 665 HostMatch object which applies to the request. 667 Property: hosts 669 Description: List of HostMatch objects. Hosts (HostMatch 670 objects) MUST be evaluated in the order they appear and the 671 first HostMatch object that matches the content request being 672 processed MUST be used. 674 Type: List of HostMatch objects 676 Mandatory-to-Specify: Yes. 678 Example HostIndex object containing two HostMatch objects, where the 679 first HostMatch object is embedded and the second HostMatch object is 680 referenced: 682 { 683 "hosts": [ 684 { 685 686 }, 687 { 688 "type": "application/cdni.HostMatch.v1+json", 689 "href": "http://metadata.ucdn.example/hostmatch1234" 690 } 691 ] 692 } 694 4.1.2. HostMatch 696 The HostMatch object contains a Hostname or IP address to match 697 against content requests. The HostMatch object also contains a 698 HostMetadata object to apply if a match is found. 700 Property: host 702 Description: String (Hostname or IP address) to match against 703 the requested host. In order for a Hostname or IP address in a 704 content request to match the Hostname or IP address in the host 705 property the value when converted to lowercase in the content 706 request MUST be identical to the value of the host property 707 when converted to lowercase. IPv4 addresses MUST be encoded as 708 specified by the 'IPv4address' rule in Section 3.2.2 of 709 [RFC3986]. IPv6 addresses MUST be encoded in one of the IPv6 710 address formats specified in [RFC5952] although receivers MUST 711 support all IPv6 address formats specified in [RFC4291]. 713 Type: String 715 Mandatory-to-Specify: Yes. 717 Property: host-metadata 719 Description: CDNI metadata to apply when delivering content 720 that matches this host. 722 Type: HostMetadata 724 Mandatory-to-Specify: Yes. 726 Example HostMatch object with an embedded HostMetadata object: 728 { 729 "host": "video.example.com", 730 "host-metadata" : { 731 732 } 733 } 735 Example HostMatch object referencing (via a Link object, see 736 Section 4.3.1) a HostMetadata object: 738 { 739 "host": "video.example.com", 740 "host-metadata" : { 741 "type": "application/cdni.HostMetadata.v1+json", 742 "href": "http://metadata.ucdn.example/host1234" 743 } 744 } 746 4.1.3. HostMetadata 748 A HostMetadata object contains the CDNI metadata properties for 749 content served for a particular host (defined in the HostMatch 750 object) and possibly child PathMatch objects. 752 Property: metadata 754 Description: List of host related metadata. 756 Type: List of GenericMetadata objects 758 Mandatory-to-Specify: Yes. 760 Property: paths 762 Description: Path specific rules. Path patterns (PathMatch 763 objects) MUST be evaluated in the order they appear and the 764 first PathMatch object that matches the content request being 765 processed MUST be used. 767 Type: List of PathMatch objects 769 Mandatory-to-Specify: No. 771 Example HostMetadata object containing a number of embedded 772 GenericMetadata objects that will describe the default metadata for 773 the host and a single embedded PathMatch object that will describe 774 the CDNI metadata for that path which overrides the default metadata 775 for the host: 777 { 778 "metadata": [ 779 { 780 781 }, 782 { 783 784 }, 786 ... 788 { 789 790 } 791 ], 792 "paths": [ 793 { 794 795 } 796 ] 797 } 799 4.1.4. PathMatch 801 A PathMatch object contains a pattern within a PatternMatch object to 802 match against a resource's URI path and contains a PathMetadata 803 object to apply if the resource's URI path matches the pattern within 804 the PatternMatch object. 806 Property: path-pattern 808 Description: Pattern to match against the requested resource's 809 URI path, i.e., against the [RFC3986] path-absolute. 811 Type: PatternMatch 813 Mandatory-to-Specify: Yes. 815 Property: path-metadata 817 Description: CDNI metadata to apply when delivering content 818 that matches the associated PatternMatch. 820 Type: PathMetadata 822 Mandatory-to-Specify: Yes. 824 Example PathMatch object referencing the PathMetadata object to use 825 for URIs that match the case-sensitive URI path pattern "/movies/*" 826 (contained within an embedded PatternMatch object): 828 { 829 "path-pattern": { 830 "pattern": "/movies/*", 831 "case-sensitive": true 832 }, 833 "path-metadata": { 834 "type": "application/cdni.PathMetadata.v1+json", 835 "href": "http://metadata.ucdn.example/host1234/pathDCE" 836 } 837 } 839 4.1.5. PatternMatch 841 A PatternMatch object contains the pattern string and flags that 842 describe the PathMatch expression. 844 Property: pattern 846 Description: A pattern for string matching. The pattern may 847 contain the wildcards * and ?, where * matches any sequence of 848 characters (including the empty string) and ? matches exactly 849 one character. The three literals $, * and ? should be escaped 850 as $$, $* and $?. All other characters are treated as literals. 852 Type: String 854 Mandatory-to-Specify: Yes. 856 Property: case-sensitive 858 Description: Flag indicating whether or not case-sensitive 859 matching should be used. 861 Type: Boolean 863 Mandatory-to-Specify: No. Default is case-insensitive match. 865 Property: ignore-query-string 867 Description: List of query parameters which should be ignored 868 when searching for a pattern match. Matching against query 869 parameters to ignore MUST be case-insensitive. If all query 870 parameters should be ignored then the list MUST be empty. 872 Type: List of String 874 Mandatory-to-Specify: No. Default is to include query strings 875 when matching. 877 Example PatternMatch object that matches the case-sensitive URI path 878 pattern "/movies/*". All query parameters will be ignored when 879 matching URIs requested from surrogates by content clients against 880 this path pattern: 882 { 883 "pattern": "/movies/*", 884 "case-sensitive": true, 885 "ignore-query-string": [] 886 } 888 Example PatternMatch object that matches the case-sensitive URI path 889 pattern "/movies/*". The query parameter "sessionid" will be ignored 890 when matching URIs requested from surrogates by content clients 891 against this path pattern: 893 { 894 "pattern": "/movies/*", 895 "case-sensitive": true, 896 "ignore-query-string": ["sessionid"] 897 } 899 4.1.6. PathMetadata 901 A PathMetadata object contains the CDNI metadata properties for 902 content requests that match against the associated URI path (defined 903 in a PathMatch object) and possibly child PathMatch objects. 905 Note that if DNS-based redirection is employed, then a dCDN will be 906 unable to evaulate any metadata at the PathMetadata level or below 907 against the content redirection request at request routing time 908 because only the hostname of the content request is available at 909 request routing time. dCDNs SHOULD still process any metadata at the 910 PathMetadata level or below before responding to the redirection 911 request in order to detect if any unsupported metadata is specifed. 912 If any metadata is included and marked as "mandatory-to-enforce" 913 which is not supported by the dCDN then the dCDN SHOULD NOT redirect 914 the the content redirection request to itself in order to avoid 915 receiving content requests that it is not able to satisfy/serve. 917 Property: metadata 919 Description: List of path related metadata. 921 Type: List of GenericMetadata objects 923 Mandatory-to-Specify: Yes. 925 Property: paths 927 Description: Path specific rules. First match applies. 929 Type: List of PathMatch objects 931 Mandatory-to-Specify: No. 933 Example PathMetadata object containing a number of embedded 934 GenericMetadata objects that describe the metadata to apply for the 935 URI path defined in the parent PathMatch object. 937 { 938 "metadata": [ 939 { 940 941 }, 942 { 943 944 }, 946 ... 948 { 949 950 } 951 ], 952 } 954 4.1.7. GenericMetadata 956 A GenericMetadata object is a wrapper for managing individual CDNI 957 metadata properties in an opaque manner. 959 Property: generic-metadata-type 961 Description: Case-insensitive CDNI metadata object type. 963 Type: String containing the Media Type of the object contained 964 in the generic-metadata-value property. 966 Mandatory-to-Specify: Yes. 968 Property: generic-metadata-value 969 Description: CDNI metadata object. 971 Type: Format/Type is defined by the value of generic-metadata- 972 type property above. 974 Mandatory-to-Specify: Yes. 976 Property: mandatory-to-enforce 978 Description: Flag identifying whether or not the enforcement of 979 the property metadata is required. 981 Type: Boolean 983 Mandatory-to-Specify: No. Default is to treat metadata as 984 mandatory to enforce (i.e., a value of True). 986 Property: safe-to-redistribute 988 Description: Flag identifying whether or not the property 989 metadata may be safely redistributed without modification. 991 Type: Boolean 993 Mandatory-to-Specify: No. Default is allow transparent 994 redistribution (i.e., a value of True). 996 Property: incomprehensible 998 Description: Flag identifying whether or not any CDN in the 999 chain of delegation has failed to understand and/or failed to 1000 properly transform this metadata object. Note: This flag only 1001 applies to metadata objects whose safe-to-redistribute property 1002 has a value of False. 1004 Type: Boolean 1006 Mandatory-to-Specify: No. Default is comprehensible (i.e., a 1007 value of False). 1009 Example GenericMetadata object containing a metadata object that 1010 applies to the applicable URI path and/or host (within a parent 1011 PathMetadata and/or HostMetadata object): 1013 { 1014 "mandatory-to-enforce": true, 1015 "generic-metadata-type": , 1016 "generic-metadata-value": 1017 { 1018 1019 } 1020 } 1022 4.2. Definitions of the initial set of CDNI Generic Metadata objects 1024 The objects defined below are intended to be used in the 1025 GenericMetadata object generic-metadata-value field as defined in 1026 Section 4.1.7 and their generic-metadata-type property MUST be set to 1027 the appropriate Media Type as defined in Table 4. 1029 4.2.1. SourceMetadata 1031 Source metadata provides the dCDN with information about content 1032 acquisition, i.e., how to contact an uCDN Surrogate or an Origin 1033 Server to obtain the content to be served. The sources are not 1034 necessarily the actual Origin Servers operated by the CSP but might 1035 be a set of Surrogates in the uCDN. 1037 Property: sources 1039 Description: Sources from which the dCDN can acquire content, 1040 listed in order of preference. 1042 Type: List of Source objects (see Section 4.2.1.1) 1044 Mandatory-to-Specify: No. Default is to use static 1045 configuration, out-of-band from the metadata interface. 1047 Example SourceMetadata object (which contains two Source objects) 1048 that describes which servers the dCDN should use for acquiring 1049 content for the applicable URI path and/or host: 1051 { 1052 "mandatory-to-enforce": true, 1053 "generic-metadata-type": "application/cdni.SourceMetadata.v1+json" 1054 "generic-metadata-value": 1055 { 1056 "sources": [ 1057 { 1058 "generic-metadata-type": 1059 "application/cdni.Source.v1+json" 1060 "generic-metadata-value": 1061 { 1062 "endpoints": [ 1063 "a.service123.ucdn.example", 1064 "b.service123.ucdn.example" 1065 ], 1066 "protocol": "http1.1" 1067 } 1068 }, 1069 { 1070 "generic-metadata-type": 1071 "application/cdni.Source.v1+json" 1072 "generic-metadata-value": 1073 { 1074 "endpoints": ["origin.service123.example"], 1075 "protocol": "http1.1" 1076 } 1077 } 1078 ] 1079 } 1080 } 1082 4.2.1.1. Source 1084 A Source object describes the source to be used by the dCDN for 1085 content acquisition, e.g., a Surrogate within the uCDN or an 1086 alternate Origin Server, the protocol to be used and any 1087 authentication method to be used when contacting that source. 1089 Endpoints within a Source object MUST be treated as equivalent/equal 1090 so a uCDN can specify a list of sources in preference order and for 1091 each source/preference rank a uCDN can specify a list of endpoints 1092 that are equivalent, e.g., a pool of servers that are not behind a 1093 load balancer. 1095 Property: acquisition-auth 1097 Description: Authentication method to use when requesting 1098 content from this source. 1100 Type: Auth (see Section 4.2.7) 1102 Mandatory-to-Specify: No. Default is no authentication 1103 required. 1105 Property: endpoints 1107 Description: Origins from which the dCDN can acquire content. 1108 If multiple endpoints are specified they are all equal, i.e., 1109 the list is not in preference order, for example a pool of 1110 servers behind a load balancer. 1112 Type: List of Endpoint objects (See Section 4.3.3) 1114 Mandatory-to-Specify: Yes. 1116 Property: protocol 1118 Description: Network retrieval protocol to use when requesting 1119 content from this source. 1121 Type: Protocol (see Section 4.3.2) 1123 Mandatory-to-Specify: Yes. 1125 Example Source object that describes a pair of endpoints (servers) 1126 the dCDN can use for acquiring content for the applicable host and/or 1127 URI path: 1129 { 1130 "generic-metadata-type": "application/cdni.Source.v1+json" 1131 "generic-metadata-value": 1132 { 1133 "endpoints": [ 1134 "a.service123.ucdn.example", 1135 "b.service123.ucdn.example" 1136 ], 1137 "protocol": "http1.1" 1138 } 1139 } 1141 4.2.2. LocationACL Metadata 1143 LocationACL metadata defines which locations a User Agent needs to be 1144 in, in order to be able to receive the associated content. 1146 A LocationACL which does not include a locations property results in 1147 an action of allow, meaning that delivery can be performed regardless 1148 of the User Agent's location. The action from the first footprint to 1149 match against the User Agent's location is the action a CDN MUST 1150 take. If two or more footprints overlap, the first footprint that 1151 matches against the User Agent's location determines the action a CDN 1152 MUST take. If the locations property is included but is empty, or if 1153 none of the listed footprints matches the User Agent's location, then 1154 the result is an action of deny. 1156 Although the LocationACL, TimeWindowACL (see Section 4.2.3), and 1157 ProtocolACL (see Section 4.2.4) are independent GenericMetadata 1158 objects, they may provide conflicting information to a dCDN, e.g., a 1159 content request which is simultaneously allowed based on the 1160 LocationACL and denied based on the TimeWindowACL. The dCDN MUST use 1161 the logical AND of all ACLs (where 'allow' is true and 'deny' is 1162 false) to determine whether or not a request should be allowed. 1164 Property: locations 1166 Description: Access control list which allows or denies 1167 (blocks) delivery based on the User Agent's location. 1169 Type: List of LocationRule objects (see Section 4.2.2.1) 1171 Mandatory-to-Specify: No. Default is allow all locations. 1173 Example LocationACL object that allows the dCDN to deliver content to 1174 any location/IP address: 1176 { 1177 "mandatory-to-enforce": true, 1178 "generic-metadata-type": "application/cdni.LocationACL.v1+json" 1179 "generic-metadata-value": 1180 { 1181 } 1182 } 1184 Example LocationACL object (which contains a LocationRule object 1185 which itself contains a Footprint object) that only allows the dCDN 1186 to deliver content to User Agents in the USA: 1188 { 1189 "mandatory-to-enforce": true, 1190 "generic-metadata-type": "application/cdni.LocationACL.v1+json" 1191 "generic-metadata-value": 1192 { 1193 "locations": [ 1194 { 1195 "generic-metadata-type": 1196 "application/cdni.LocationRule.v1+json" 1197 "generic-metadata-value": 1198 { 1199 "action": "allow", 1200 "footprints": [ 1201 { 1202 "generic-metadata-type": 1203 "application/cdni.Footprint.v1+json" 1204 "generic-metadata-value": 1205 { 1206 "footprint-type": "countrycode", 1207 "footprint-value": ["us"] 1208 } 1209 } 1210 ] 1211 } 1212 } 1213 ] 1214 } 1215 } 1217 4.2.2.1. LocationRule 1219 A LocationRule contains or references a list of Footprint objects and 1220 the corresponding action. 1222 Property: footprints 1224 Description: List of footprints to which the rule applies. 1226 Type: List of Footprint objects (see Section 4.2.2.2) 1228 Mandatory-to-Specify: Yes. 1230 Property: action 1232 Description: Defines whether the rule specifies locations to 1233 allow or deny. 1235 Type: Enumeration [allow|deny] encoded as a lowercase string 1236 Mandatory-to-Specify: No. Default is deny. 1238 Example LocationRule object (which contains a Footprint object) that 1239 allows the dCDN to deliver content to clients in the USA: 1241 { 1242 "generic-metadata-type": 1243 "application/cdni.LocationRule.v1+json" 1244 "generic-metadata-value": 1245 { 1246 "action": "allow", 1247 "footprints": [ 1248 { 1249 "generic-metadata-type": 1250 "application/cdni.Footprint.v1+json" 1251 "generic-metadata-value": 1252 { 1253 "footprint-type": "countrycode", 1254 "footprint-value": ["us"] 1255 } 1256 } 1257 ] 1258 } 1259 } 1261 4.2.2.2. Footprint 1263 A Footprint object describes the footprint to which a LocationRule 1264 may be applied to, e.g., an IPv4 address range or a geographic 1265 location. 1267 Property: footprint-type 1269 Description: Registered footprint type. The footprint types 1270 specified by this document are: "ipv4cidr" (IPv4CIDR, see 1271 Section 4.3.5), "ipv6cidr" (IPv6CIDR, see Section 4.3.6), "asn" 1272 (Autonomous System Number, see Section 4.3.7) and "countrycode" 1273 (Country Code, see Section 4.3.8). 1275 Type: Lowercase String 1277 Mandatory-to-Specify: Yes. 1279 Property: footprint-value 1281 Description: List of footprint values conforming to the 1282 specification associated with the registered footprint type. 1284 Type: List of footprints 1286 Mandatory-to-Specify: Yes. 1288 Example Footprint object describing a footprint covering the USA: 1290 { 1291 "generic-metadata-type": 1292 "application/cdni.Footprint.v1+json" 1293 "generic-metadata-value": 1294 { 1295 "footprint-type": "countrycode", 1296 "footprint-value": ["us"] 1297 } 1298 } 1300 Example Footprint object describing a footprint covering the IP 1301 address ranges 192.0.2.0/24 and 198.51.100.0/24: 1303 { 1304 "generic-metadata-type": 1305 "application/cdni.Footprint.v1+json" 1306 "generic-metadata-value": 1307 { 1308 "footprint-type": "ipv4cidr", 1309 "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] 1310 } 1311 } 1313 4.2.3. TimeWindowACL 1315 TimeWindowACL metadata defines time-based restrictions. 1317 A TimeWindowACL which does not include a times property results in an 1318 action of allow, meaning that delivery can be performed regardless of 1319 the time of the User Agent's request. The action from the first 1320 window to match against the current time is the action a CDN MUST 1321 take. If two or more windows overlap, the first window that matches 1322 against the current time determines the action a CDN MUST take. If 1323 the times property is included but is empty, or if none of the listed 1324 windows matches the current time, then the result is an action of 1325 deny. 1327 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1328 independent GenericMetadata objects, they may provide conflicting 1329 information to a dCDN, e.g., a content request which is 1330 simultaneously allowed based on the LocationACL and denied based on 1331 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1332 (where 'allow' is true and 'deny' is false) to determine whether or 1333 not a request should be allowed. 1335 Property: times 1337 Description: Access control list which allows or denies 1338 (blocks) delivery based on the time of a User Agent's request. 1340 Type: List of TimeWindowRule objects (see Section 4.2.3.1) 1342 Mandatory-to-Specify: No. Default is allow all time windows. 1344 Example TimeWIndowACL object (which contains a TimeWindowRule object 1345 which itself contains a TimeWIndow object) that only allows the dCDN 1346 to deliver content to clients between 09:00AM 01/01/2000 UTC and 1347 17:00AM 01/01/2000 UTC: 1349 { 1350 "mandatory-to-enforce": true, 1351 "generic-metadata-type": "application/cdni.TimeWindowACL.v1+json" 1352 "generic-metadata-value": 1353 { 1354 "times": [ 1355 { 1356 "generic-metadata-type": 1357 "application/cdni.TimeWindowRule.v1+json" 1358 "generic-metadata-value": 1359 { 1360 "action": "allow", 1361 "windows": [ 1362 { 1363 "generic-metadata-type": 1364 "application/cdni.TimeWindow.v1+json" 1365 "generic-metadata-value": 1366 { 1367 "start": 946717200, 1368 "end": 946746000 1369 } 1370 } 1371 ] 1372 } 1373 } 1374 ] 1375 } 1376 } 1378 4.2.3.1. TimeWindowRule 1380 A TimeWindowRule contains or references a list of TimeWindow objects 1381 and the corresponding action. 1383 Property: windows 1385 Description: List of time windows to which the rule applies. 1387 Type: List of TimeWindow objects (see Section 4.2.3.2) 1389 Mandatory-to-Specify: Yes. 1391 Property: action 1393 Description: Defines whether the rule specifies time windows to 1394 allow or deny. 1396 Type: Enumeration [allow|deny] encoded as a lowercase string 1398 Mandatory-to-Specify: No. Default is deny. 1400 Example TimeWIndowRule object (which contains a TimeWIndow object) 1401 that only allows the dCDN to deliver content to clients between 1402 09:00AM 01/01/2000 UTC and 17:00AM 01/01/2000 UTC: 1404 { 1405 "generic-metadata-type": 1406 "application/cdni.TimeWindowRule.v1+json" 1407 "generic-metadata-value": 1408 { 1409 "action": "allow", 1410 "windows": [ 1411 { 1412 "generic-metadata-type": 1413 "application/cdni.TimeWindow.v1+json" 1414 "generic-metadata-value": 1415 { 1416 "start": 946717200, 1417 "end": 946746000 1418 } 1419 } 1420 ] 1421 } 1422 } 1424 4.2.3.2. TimeWindow 1426 A TimeWindow object describes a time range which may be applied by an 1427 TimeWindowACL, e.g., start 946717200 (i.e., 09:00AM 01/01/2000 UTC), 1428 end: 946746000 (i.e., 17:00AM 01/01/2000 UTC). 1430 Property: start 1432 Description: The start time of the window. 1434 Type: Time (see Section 4.3.4) 1436 Mandatory-to-Specify: Yes. 1438 Property: end 1440 Description: The end time of the window. 1442 Type: Time (see Section 4.3.4) 1444 Mandatory-to-Specify: Yes. 1446 Example TimeWIndow object that describes a time window from 09:00AM 1447 01/01/2000 UTC to 17:00AM 01/01/2000 UTC: 1449 { 1450 "generic-metadata-type": 1451 "application/cdni.TimeWindow.v1+json" 1452 "generic-metadata-value": 1453 { 1454 "start": 946717200, 1455 "end": 946746000 1456 } 1457 } 1459 4.2.4. ProtocolACL Metadata 1461 ProtocolACL metadata defines delivery protocol restrictions. 1463 A ProtocolACL which does not include a protocol-acl property results 1464 in an action of allow, meaning that delivery can be performed 1465 regardless of the protocol of the User Agent's request. The action 1466 from the first protocol to match against the request protocol is the 1467 action a CDN MUST take. If two or more request protocols overlap, 1468 the first protocol that matches thre request protocol determines the 1469 action a CDN MUST take. If the protocol-acl property is included but 1470 is empty, or if none of the listed protocol matches the request 1471 protocol, then the result is an action of deny. 1473 Although the LocationACL, TimeWindowACL, and ProtocolACL are 1474 independent GenericMetadata objects, they may provide conflicting 1475 information to a dCDN, e.g., a content request which is 1476 simultaneously allowed based on the ProtocolACL and denied based on 1477 the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs 1478 (where 'allow' is true and 'deny' is false) to determine whether or 1479 not a request should be allowed. 1481 Property: protocol-acl 1483 Description: Description: Access control list which allows or 1484 denies (blocks) delivery based on delivery protocol. 1486 Type: List of ProtocolRule objects (see Section 4.2.4.1) 1488 Mandatory-to-Specify: No. Default is allow all protocols. 1490 Example ProtocolACL object (which contains a ProtocolRule object) 1491 that only allows the dCDN to deliver content using HTTP/1.1: 1493 { 1494 "mandatory-to-enforce": true, 1495 "generic-metadata-type": "application/cdni.ProtocolACL.v1+json" 1496 "generic-metadata-value": 1497 { 1498 "protocol-acl": [ 1499 { 1500 "generic-metadata-type": 1501 "application/cdni.ProtocolRule.v1+json" 1502 "generic-metadata-value": 1503 { 1504 "action": "allow", 1505 "protocols": ["http1.1"] 1506 } 1507 } 1508 ] 1509 } 1510 } 1512 4.2.4.1. ProtocolRule 1514 A ProtocolRule contains or references a list of Protocol objects. 1515 ProtocolRule objects are used to construct a ProtocolACL to apply 1516 restrictions to content acquisition or delivery. 1518 Property: protocols 1520 Description: List of protocols to which the rule applies. 1522 Type: List of Protocols (see Section 4.3.2) 1524 Mandatory-to-Specify: Yes. 1526 Property: action 1528 Description: Defines whether the rule specifies protocols to 1529 allow or deny. 1531 Type: Enumeration [allow|deny] encoded as a lowercase string 1533 Mandatory-to-Specify: No. Default is deny. 1535 Example ProtocolRule object (which contains a ProtocolRule object) 1536 that includes the protocol HTTP/1.1: 1538 { 1539 "generic-metadata-type": 1540 "application/cdni.ProtocolRule.v1+json" 1541 "generic-metadata-value": 1542 { 1543 "action": "allow", 1544 "protocols": ["http1.1"] 1545 } 1546 } 1548 4.2.5. DeliveryAuthorization Metadata 1550 Delivery Authorization defines authorization methods for the delivery 1551 of content to User Agents. 1553 Property: delivery-auth-methods 1555 Description: Options for authorizing content requests. 1556 Delivery for a content request is authorized if any of the 1557 authorization methods in the list is satisfied for that 1558 request. 1560 Type: List of Auth objects (see Section 4.2.7) 1562 Mandatory-to-Specify: No. Default is no authorization 1563 required. 1565 4.2.6. Cache 1567 A Cache object describes the cache control parameters to be applied 1568 to the content by intermediate caches. 1570 Property: ignore-query-string 1572 Description: Allows a Surrogate to ignore URI query string 1573 parameters when comparing the requested URI against the URIs in 1574 its cache for equivalence. Matching against query parameters 1575 to ignore MUST be case-insensitive. Each query parameter to 1576 ignore is specified in the list. If all query parameters 1577 should be ignored, then the list MUST be specified and MUST be 1578 empty. 1580 Type: List of String 1582 Mandatory-to-Specify: No. Default is to consider query string 1583 parameters when comparing URIs. 1585 Example Cache object that instructs the dCDN to ignore all query 1586 parameters: 1588 { 1589 "generic-metadata-type": 1590 "application/cdni.Cache.v1+json" 1591 "generic-metadata-value": 1592 { 1593 "ignore-query-string": [] 1594 } 1595 } 1597 Example Cache object that instructs the dCDN to ignore the (case- 1598 insensitive) query parameters named "sessionid" and "random": 1600 { 1601 "generic-metadata-type": 1602 "application/cdni.Cache.v1+json" 1603 "generic-metadata-value": 1604 { 1605 "ignore-query-string": ["sessionid", "random"] 1606 } 1607 } 1609 4.2.7. Auth 1611 An Auth object defines authentication and authorization methods to be 1612 used during content acquisition and content delivery, respectively. 1614 Property: auth-type 1616 Description: Registered Auth type (see Section 4.2.7.1 and 1617 Section 7.3). 1619 Type: String 1621 Mandatory-to-Specify: Yes. 1623 Property: auth-value 1625 Description: An object conforming to the specification 1626 associated with the Registered Auth type. 1628 Type: GenericMetadata Object 1630 Mandatory-to-Specify: Yes. 1632 Example Auth object (which contains a BasicAuth object, see 1633 Section 4.2.7.1): 1635 { 1636 "generic-metadata-type": 1637 "application/cdni.Auth.v1+json" 1638 "generic-metadata-value": 1639 { 1640 "auth-type": "httpbasic", 1641 "auth-value": 1642 { 1643 "generic-metadata-type": 1644 "application/cdni.BasicAuth.v1+json" 1645 "generic-metadata-value": 1646 { 1647 "username": "user", 1648 "password": "pass" 1649 } 1650 } 1651 } 1652 } 1654 4.2.7.1. BasicAuth 1656 BasicAuth is a Registered Auth type defining an object for 1657 encapsulating user credentials (i.e., username and password) for use 1658 with HTTP Basic Authentication (see Section 7.3). The BasicAuth 1659 object contains the following properties: 1661 Property: username 1663 Description: Identification of user. 1665 Type: String 1666 Mandatory-to-Specify: Yes. 1668 Property: password 1670 Description: Password for user identified by username property. 1672 Type: String 1674 Mandatory-to-Specify: Yes. 1676 Example BasicAuth object containing the username "user" and password 1677 "pass": 1679 { 1680 "generic-metadata-type": 1681 "application/cdni.BasicAuth.v1+json" 1682 "generic-metadata-value": 1683 { 1684 "username": "user", 1685 "password": "pass" 1686 } 1687 } 1689 4.2.8. Grouping 1691 A Grouping object identifies a large group of content to which a 1692 given asset belongs. 1694 Property: ccid 1696 Description: Content Collection identifier for an application- 1697 specific purpose such as logging. 1699 Type: String 1701 Mandatory-to-Specify: No. Default is an empty string. 1703 Property: sid 1705 Description: Session identifier for an application-specific 1706 purpose such as logging. 1708 Type: String 1710 Mandatory-to-Specify: No. Default is an empty string. 1712 Example Grouping object that specifies a Content Collection 1713 Identifier and a Session identifier for the content associated with 1714 the Grouping object's parent HostMetdata or PathMetadata: 1716 { 1717 "generic-metadata-type": 1718 "application/cdni.Grouping.v1+json" 1719 "generic-metadata-value": 1720 { 1721 "ccid": "ABCD", 1722 "sid": "EFGH" 1723 } 1724 } 1726 4.3. CDNI Metadata Simple Data Type Descriptions 1728 This section describes the simple data types that are used for 1729 properties of CDNI metadata objects. 1731 4.3.1. Link 1733 A Link object may be used in place of any of the objects or 1734 properties described above. Link objects can be used to avoid 1735 duplication if the same metadata information is repeated within the 1736 metadata tree. When a Link object replaces another object, its href 1737 property is set to the URI of the resource and its type property is 1738 set to the Media Type of the object it is replacing. 1740 dCDNs can detect the presence of a Link object instead of another 1741 metadata object by detecting the presence of a property named "href" 1742 within the object. This measn that GenericMetadata types MUST NOT 1743 contain a property named "href" because doing so would conflict with 1744 the ability for dCDNs to detect Link objects being used to reference 1745 a GenericMetadata object. 1747 Property: href 1749 Description: The URI of the addressable object being 1750 referenced. 1752 Type: String 1754 Mandatory-to-Specify: Yes 1756 Property: type 1758 Description: The type of the object being referenced. 1760 Type: String 1762 Mandatory-to-Specify: No 1764 Example Link object referencing a HostMetadata object: 1766 { 1767 "type": "application/cdni.HostMetadata.v1+json", 1768 "href": "http://metadata.ucdn.example/host1234" 1769 } 1771 4.3.2. Protocol 1773 Protocol objects are used to specify registered protocols for content 1774 acquisition or delivery (see Section 7.2). 1776 Type: String 1778 Example: 1780 "http1.1" 1782 4.3.3. Endpoint 1784 A Hostname (with optional port) or an IP address (with optional 1785 port). 1787 Note: All implementations MUST support IPv4 addresses encoded as 1788 specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. 1789 IPv6 addresses MUST be encoded in one of the IPv6 address formats 1790 specified in [RFC5952] although receivers MUST support all IPv6 1791 address formats specified in [RFC4291]. 1793 Type: String 1795 Example Hostname: 1797 "http://metadata.ucdn.example/host1234" 1799 Example IPv4 address: 1801 "192.0.2.1" 1803 Example IPv6 address (with port number): 1805 "[2001:db8::1]:81" 1807 4.3.4. Time 1809 A time value expressed in seconds since Unix epoch in the UTC 1810 timezone. 1812 Type: Integer 1814 Example Time representing 09:00AM 01/01/2000 UTC: 1816 946717200 1818 4.3.5. IPv4CIDR 1820 An IPv4address CIDR block encoded as specified by the 'IPv4address' 1821 rule in Section 3.2.2 of [RFC3986] followed by a / followed by an 1822 unsigned integer representing the leading bits of the routing prefix 1823 (i.e. IPv4 CIDR notation). Single IP addresses can be expressed as 1824 /32. 1826 Type: String 1828 Example IPv4 CIDR: 1830 "192.0.2.0/24" 1832 4.3.6. IPv6CIDR 1834 An IPv6address CIDR block encoded in one of the IPv6 address formats 1835 specified in [RFC5952] followed by a / followed by an unsigned 1836 integer representing the leading bits of the routing prefix (i.e. 1837 IPv6 CIDR notation). Single IP addresses can be expressed as /128. 1839 Type: String 1841 Example IPv6 CIDR: 1843 "2001:db8::/32" 1845 4.3.7. ASN 1847 An Autonomous System Number encoded as a string consisting of the 1848 characters "as" (in lowercase) followed by the Autonomous System 1849 number. 1851 Type: String 1853 Example ASN: 1855 "as64496" 1857 4.3.8. CountryCode 1859 An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. 1861 Type: String 1863 Example Country Code representing the USA: 1865 "us" 1867 5. CDNI Metadata Capabilities 1869 CDNI metadata is used to convey information pertaining to content 1870 delivery from uCDN to dCDN. For optional metadata, it may be useful 1871 for the uCDN to know if the dCDN supports the underlying 1872 functionality described by the metadata, prior to delegating any 1873 content requests to the dCDN. If some metadata is "mandatory-to- 1874 enforce", and the dCDN does not support it, any delegated requests 1875 for content that requires that metadata will fail. The uCDN will 1876 likely want to avoid delegating those requests to that dCDN. 1877 Likewise, for any metadata which may be assigned optional values, it 1878 may be useful for the uCDN to know which values a dCDN supports, 1879 prior to delegating any content requests to that dCDN. If the 1880 optional value assigned to a given piece of content's metadata is not 1881 supported by the dCDN, any delegated requests for that content may 1882 fail, so again the uCDN is likely to want to avoid delegating those 1883 requests to that dCDN. 1885 The CDNI Footprint and Capabilities Interface (FCI) [RFC7336] 1886 provides a means of advertising capabilities from dCDN to uCDN. 1887 Support for optional metadata and support for optional metadata 1888 values may be advertised using the FCI. 1890 6. CDNI Metadata interface 1892 This section specifies an interface to enable a dCDN to retrieve CDNI 1893 metadata objects from a uCDN. 1895 The interface can be used by a dCDN to retrieve CDNI metadata objects 1896 either: 1898 o Dynamically as required by the dCDN to process received requests. 1899 For example in response to a query from an uCDN over the CDNI 1900 Request Routing Redirection interface (RI) 1901 [I-D.ietf-cdni-redirection] or in response to receiving a request 1902 for content from a User Agent. Or; 1904 o In advance of being required. For example in the case of pre- 1905 positioned CDNI metadata acquisition. 1907 The CDNI metadata interface is built on the principles of HTTP web 1908 services. In particular, this means that requests and responses over 1909 the interface are built around the transfer of representations of 1910 hyperlinked resources. A resource in the context of the CDNI 1911 metadata interface is any object in the object model (as described in 1912 Section 3 and Section 4). 1914 To retrieve CDNI metadata, a CDNI metadata client (i.e., a client in 1915 the dCDN) first makes a HTTP GET request for the URI of the HostIndex 1916 which provides the CDNI metadata client with a list of Hostnames for 1917 which the uCDN may delegate content delivery to the dCDN. The CDNI 1918 metadata client can then obtain any other CDNI metadata objects by 1919 making a HTTP GET requests for any linked metadata objects it 1920 requires. 1922 CDNI metadata servers (i.e., servers in the uCDN) are free to assign 1923 whatever structure they desire to the URIs for CDNI metadata objects 1924 and CDNI metadata clients MUST NOT make any assumptions regarding the 1925 structure of CDNI metadata URIs or the mapping between CDNI metadata 1926 objects and their associated URIs. Therefore any URIs present in the 1927 examples in this document are purely illustrative and are not 1928 intended to impose a definitive structure on CDNI metadata interface 1929 implementations. 1931 6.1. Transport 1933 The CDNI metadata interface uses HTTP as the underlying protocol 1934 transport. 1936 The HTTP Method in the request defines the operation the request 1937 would like to perform. A server implementation of the CDNI metadata 1938 interface MUST support the HTTP GET and HEAD methods. 1940 The corresponding HTTP Response returns the status of the operation 1941 in the HTTP Status Code and returns the current representation of the 1942 resource (if appropriate) in the Response Body. HTTP Responses from 1943 servers implementing the CDNI metadata interface that contain a 1944 response body SHOULD include an ETag to enable validation of cached 1945 versions of returned resources. 1947 The CDNI metadata interface specified in this document is a read-only 1948 interface. Therefore support for other HTTP methods such as PUT, 1949 POST and DELETE etc. is not specified. A server implementation of 1950 the CDNI metadata interface SHOULD reject all methods other than GET 1951 and HEAD. 1953 As the CDNI metadata interface builds on top of HTTP, CDNI metadata 1954 server implementations MAY make use of any HTTP feature when 1955 implementing the CDNI metadata interface, for example a CDNI metadata 1956 server MAY make use of HTTP's caching mechanisms to indicate that the 1957 returned response/representation can be reused without re-contacting 1958 the CDNI metadata server. 1960 6.2. Retrieval of CDNI Metadata resources 1962 In the general case a CDNI metadata server makes CDNI metadata 1963 objects available via a unique URIs and therefore in order to 1964 retrieve CDNI metadata, a CDNI metadata client first makes a HTTP GET 1965 request for the URI of the HostIndex which provides the CDNI metadata 1966 client with a list of Hostnames for which the uCDN may delegate 1967 content delivery to the dCDN. 1969 In order to retrieve the CDNI metadata for a particular request the 1970 CDNI metadata client processes the received HostIndex object and 1971 finds the corresponding HostMetadata entry (by matching the hostname 1972 in the request against the hostnames listed in the HostMatch 1973 objects). If the HostMetadata is linked (rather than embedded), the 1974 CDNI metadata client then makes a GET request for the URI specified 1975 in the href property of the Link object which points to the 1976 HostMetadata object itself. 1978 In order to retrieve the most specific metadata for a particular 1979 request, the CDNI metadata client inspects the HostMetadata for 1980 references to more specific PathMetadata objects (by matching the URI 1981 path in the request against the path-patterns in the PathMatch). If 1982 any PathMetadata match the request (and are linked rather than 1983 embedded), the CDNI metadata client makes another GET request for the 1984 PathMetadata. Each PathMetadata object may also include references 1985 to yet more specific metadata. If this is the case, the CDNI 1986 metadata client continues requesting PathMatch and PathMetadata 1987 objects recursively. The CDNI metadata client repeats this approach 1988 of processing metadata objects and retrieving (via HTTP GETs) any 1989 linked objects until it has all the metadata objects it requires in 1990 order to process a redirection request from an uCDN or a content 1991 request from a User Agent. 1993 In cases where a dCDN is not able to retrieve the entire set of CDNI 1994 metadata associated with a User Agent request, for example because 1995 the uCDN is uncontactable or returns an HTTP 4xx or 5xx status in 1996 response to some or all of the dCDN's CDNI metadata requests, the 1997 dCDN MUST NOT serve the requested content unless the dCDN has stale 1998 versions of all the required metadata and the stale-if-error Cache- 1999 Control extension [RFC5861] was included in all previous responses 2000 that are required but cannot currently be retrieved. The dCDN can 2001 continue to serve other content for which it can retrieve (or for 2002 which it has fresh responses cached) all the required metadata even 2003 if some non-applicable part of the metadata tree is missing. 2005 Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to 2006 determine which uCDN's CDNI metadata should be used to handle a 2007 particular User Agent request. 2009 When application level redirection (e.g., HTTP 302 redirects) is 2010 being used between CDNs, it is expected that the dCDN will be able to 2011 determine the uCDN that redirected a particular request from 2012 information contained in the received request (e.g., via the URI). 2013 With knowledge of which uCDN routed the request, the dCDN can choose 2014 the correct uCDN from which to obtain the HostIndex. Note that the 2015 HostIndex served by each uCDN may be unique. 2017 In the case of DNS redirection there is not always sufficient 2018 information carried in the DNS request from User Agents to determine 2019 the uCDN that redirected a particular request (e.g., when content 2020 from a given host is redirected to a given dCDN by more than one 2021 uCDN) and therefore dCDNs may have to apply local policy when 2022 deciding which uCDN's metadata to apply. 2024 6.3. Bootstrapping 2026 The URI for the HostIndex object of a given uCDN needs to be either 2027 configured in, or discovered by, the dCDN. All other objects/ 2028 resources are then discoverable from the HostIndex object by 2029 following any links in the HostIndex object and the referenced 2030 HostMetadata and PathMetadata objects and their GenericMetadata sub- 2031 objects. 2033 If the URI for the HostIndex object is not manually configured in the 2034 dCDN then the HostIndex URI could be discovered. A mechanism 2035 allowing the dCDN to discover the URI of the HostIndex is outside the 2036 scope of this document. 2038 6.4. Encoding 2040 CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] 2041 containing a dictionary of (key,value) pairs where the keys are the 2042 property names and the values are the associated property values. 2044 The keys of the dictionary are the names of the properties associated 2045 with the object and are therefore dependent on the specific object 2046 being encoded (i.e., dependent on the Media Type of the returned 2047 resource). Likewise, the values associated with each property 2048 (dictionary key) are dependent on the specific object being encoded 2049 (i.e., dependent on the Media Type of the returned resource). 2051 Dictionary keys (properties) in I-JSON are case sensitive. By 2052 convention any dictionary key (property) defined by this document 2053 (for example the names of CDNI metadata object properties) MUST be 2054 represented in lowercase. 2056 6.5. Extensibility 2058 The set of GenericMetadata objects may be extended with additional 2059 (standards based or vendor specific) metadata objects through the 2060 specification of new GenericMetadata objects. The GenericMetadata 2061 object defined in Section 4.1.7 specifies a type field and a type- 2062 specific value field that allows any metadata to be included in 2063 either the HostMetadata or PathMetadata lists. 2065 As with the initial GenericMetadata types defined in Section 4.2, 2066 future GenericMetadata types MUST specify the information necessary 2067 for constructing and decoding the GenericMetadata object. 2069 Any document which defines a new GenericMetadata type SHOULD: 2071 1. Specify the Media Type used to identify the new GenericMetadata 2072 type being specified. 2074 2. Define the set of properties associated with the new type 2075 contained within the GenericMetadata object. GenericMetadata 2076 types MUST NOT contain a property named "href" because doing so 2077 would conflict with the ability for dCDNs to detect Link objects 2078 being used to reference a GenericMetadata object. 2080 3. For each property, define a name, description, type, and whether 2081 or not the property is mandatory-to-specify. 2083 4. Describe the semantics of the new type including its purpose and 2084 example of a use case to which it applies including an example 2085 encoded in I-JSON. 2087 Note: In the case of vendor specific extensions, identification 2088 within the type name defined for a GenericMetadata object, of the 2089 organization that defined the new GenericMetadata object decreases 2090 the possibility of GenericMetadata type collisions. 2092 6.6. Metadata Enforcement 2094 At any given time, the set of GenericMetadata types supported by the 2095 uCDN may not match the set of GenericMetadata types supported by the 2096 dCDN. 2098 In the cases where a uCDN sends metadata containing a GenericMetadata 2099 type that a dCDN does not support, the dCDN MUST enforce the 2100 semantics of the "mandatory-to-enforce" property. If a dCDN does not 2101 understand or is unable to perform the functions associated with any 2102 "mandatory-to-enforce" metadata, the dCDN MUST NOT service any 2103 requests for the corresponding content. 2105 Note: Ideally, uCDNs would not delegate content requests to a dCDN 2106 which does not support the "mandatory-to-enforce" metadata associated 2107 with the content being requested. However, even if the uCDN has a 2108 priori knowledge of the metadata supported by the dCDN (e.g., via the 2109 CDNI capabilities interface or through out-of-band negotiation 2110 between CDN operators) metadata support may fluctuate or be 2111 inconsistent (e.g., due to mis-communication, mis-configuration, or 2112 temporary outage). Thus, the dCDN MUST always evaluate all metadata 2113 associated with redirection requests and content requests and reject 2114 any requests where "mandatory-to-enforce" metadata associated with 2115 the content cannot be enforced. 2117 6.7. Metadata Conflicts 2119 It is possible that new metadata definitions may obsolete or conflict 2120 with existing GenericMetadata (e.g., a future revision of the CDNI 2121 metadata interface may redefine the Auth GenericMetadata object or a 2122 custom vendor extension may implement an alternate Auth metadata 2123 option). If multiple metadata (e.g., cdni.Auth.v2, vendor1.Auth, and 2124 vendor2.Auth) all conflict with an existing GenericMetadata object 2125 (e.g., cdni.Auth) and all are marked as "mandatory-to-enforce", it 2126 may be ambiguous which metadata should be applied, especially if the 2127 functionality of the metadata overlap. 2129 As described in Section 3.3, metadata override only applies to 2130 metadata objects of the same exact type, found in HostMetadata and 2131 nested PathMetadata structures. The CDNI metadata interface does not 2132 support enforcement of dependencies between different metadata types. 2133 It is the responsibility of the CSP and the CDN operators to ensure 2134 that metadata assigned to a given content do not conflict. 2136 Note: Because metadata is inherently ordered in GenericMetadata 2137 lists, as well as in the PathMetadata hierarchy and PathMatch lists, 2138 multiple conflicting metadata types MAY be used, however, metadata 2139 hierarchies MUST ensure that independent PathMatch root objects are 2140 used to prevent ambiguous or conflicting metadata definitions. 2142 6.8. Versioning 2144 The version of CDNI metadata objects is conveyed inside the Media 2145 Type that is included in the HTTP Content-Type header. Upon 2146 responding to a request for an object, a CDNI metadata server MUST 2147 include a Content-Type header with the Media Type containing the 2148 version number of the object. HTTP requests sent to a metadata 2149 server SHOULD include an Accept header with the Media Type (which 2150 includes the version) of the expected object. Metadata clients can 2151 specify multiple Media Types in the Accept header, for example if a 2152 metadata client is capable of processing two different versions of 2153 the same type of object (defined by different Media Types) it may 2154 decide to include both in the Accept header. The version of each 2155 object defined by this document is version 1. For example: "Content- 2156 Type: application/cdni.HostIndex.v1+json". 2158 GenericMetadata objects include a "type" property which specifies the 2159 Media Type of the GenericMetadata value. This Media Type should also 2160 include a version. Any document which defines a new GenericMetadata 2161 type MUST specify the version number which it describes. For 2162 example: "application/cdni.Location.v1+json". 2164 6.9. Media Types 2166 All Media Types for CDNI metadata objects are prefixed with 2167 "application/cdni.". The Media Type for each object then contains 2168 the object name of that object as defined by this document. The 2169 object type name is followed by ".v" and the version number of the 2170 object type (e.g., ".v1"). Finally, the encoding type "+json" is 2171 appended. Table 4 lists the Media Type for the metadata objects 2172 (resources) that are specified in this document. 2174 +-----------------------+-------------------------------------------+ 2175 | Data Object | MIME Media Type | 2176 +-----------------------+-------------------------------------------+ 2177 | HostIndex | application/cdni.HostIndex.v1+json | 2178 | HostMatch | application/cdni.HostMatch.v1+json | 2179 | HostMetadata | application/cdni.HostMetadata.v1+json | 2180 | PathMatch | application/cdni.PathMatch.v1+json | 2181 | PatternMatch | application/cdni.PatternMatch.v1+json | 2182 | PathMetadata | application/cdni.PathMetadata.v1+json | 2183 | GenericMetadata | application/cdni.GenericMetadata.v1+json | 2184 | SourceMetadata | application/cdni.SourceMetadata.v1+json | 2185 | Source | application/cdni.Source.v1+json | 2186 | LocationACL | application/cdni.LocationACL.v1+json | 2187 | LocationRule | application/cdni.LocationRule.v1+json | 2188 | Footprint | application/cdni.Footprint.v1+json | 2189 | TimeWindowACL | application/cdni.TimeWindowACL.v1+json | 2190 | TimeWindowRule | application/cdni.TimeWindowRule.v1+json | 2191 | TimeWindow | application/cdni.TineWindow.v1+json | 2192 | ProtocolACL | application/cdni.ProtocolACL.v1+json | 2193 | ProtocolRule | application/cdni.ProtocolRule.v1+json | 2194 | DeliveryAuthorization | application/ | 2195 | | cdni.DeliveryAuthorization.v1+json | 2196 | Cache | application/cdni.Cache.v1+json | 2197 | Grouping | application/cdni.Grouping.v1+json | 2198 | Auth | application/cdni.Auth.v1+json | 2199 | BasicAuth | application/cdni.BasicAuth.v1+json | 2200 +-----------------------+-------------------------------------------+ 2202 Table 4: MIME Media Types for CDNI Metadata objects 2204 6.10. Complete CDNI Metadata Example 2206 A dCDN may request the HostIndex and receive the following object of 2207 type "application/cdni.HostIndex.v1+json": 2209 { 2210 "hosts": [ 2211 { 2212 "host": "video.example.com", 2213 "_links": { 2214 "host-metadata" : { 2215 "type": "application/cdni.HostMetadata.v1+json", 2216 "href": "http://metadata.ucdn.example/host1234" 2217 } 2218 } 2219 }, 2220 { 2221 "host": "images.example.com", 2222 "_links": { 2223 "host-metadata" : { 2224 "type": "application/cdni.HostMetadata.v1+json", 2225 "href": "http://metadata.ucdn.example/host5678" 2226 } 2227 } 2228 } 2229 ] 2230 } 2232 If the incoming request has a Host header with "video.example.com" 2233 then the dCDN would fetch the next metadata object from 2234 "http://metadata.ucdn.example/host1234" expecting a MIME media type 2235 of "application/cdni.HostMetadata.v1+json": 2237 { 2238 "metadata": [ 2239 { 2240 "generic-metadata-type": 2241 "application/cdni.SourceMetadata.v1+json", 2242 "generic-metadata-value": { 2243 "sources": [ 2244 { 2245 "_links": { 2246 "acquisition-auth": { 2247 "auth-type": "application/cdni.Auth.v1+json", 2248 "href": "http://metadata.ucdn.example/auth1234" 2249 } 2250 }, 2251 "endpoint": "acq1.ucdn.example", 2252 "protocol": "http1.1" 2253 }, 2254 { 2255 "_links": { 2256 "acquisition-auth": { 2257 "auth-type": "application/cdni.Auth.v1+json", 2258 "href": "http://metadata.ucdn.example/auth1234" 2259 } 2260 }, 2261 "endpoint": "acq2.ucdn.example", 2262 "protocol": "http1.1" 2263 } 2264 ] 2265 } 2266 }, 2267 { 2268 "generic-metadata-type": 2269 "application/cdni.LocationACL.v1+json", 2270 "generic-metadata-value": { 2271 "locations": [ 2272 { 2273 "footprints": [ 2274 { 2275 "footprint-type": "IPv4CIDR", 2276 "footprint-value": "192.0.2.0/24" 2277 } 2278 ], 2279 "action": "deny" 2280 } 2281 ] 2282 } 2283 }, 2284 { 2285 "generic-metadata-type": 2286 "application/cdni.ProtocolACL.v1+json", 2287 "generic-metadata-value": { 2288 "protocol-acl": [ 2289 { 2290 "protocols": [ 2291 "http1.1" 2292 ], 2293 "action": "allow" 2294 } 2295 ] 2296 } 2297 } 2298 ], 2299 "paths": [ 2300 { 2301 "path-pattern": { 2302 "pattern": "/video/trailers/*" 2303 }, 2304 "_links": { 2305 "path-metadata": { 2306 "type": "application/cdni.PathMetadata.v1+json", 2307 "href": "http://metadata.ucdn.example/host1234/pathABC" 2308 } 2309 } 2310 }, 2311 { 2312 "path-pattern": { 2313 "pattern": "/video/movies/*" 2314 }, 2315 "_links": { 2316 "path-metadata": { 2317 "type": "application/cdni.PathMetadata.v1+json", 2318 "href": "http://metadata.ucdn.example/host1234/pathDCE" 2319 } 2320 } 2321 } 2322 ] 2323 } 2325 Suppose the path of the requested resource matches the "/video/ 2326 movies/*" pattern, the next metadata requested would be for 2327 "http://metadata.ucdn.example/host1234/movies" with an expected type 2328 of "application/cdni.PathMetadata.v1+json": 2330 { 2331 "metadata": [], 2332 "paths": [ 2333 { 2334 "path-pattern": { 2335 "pattern": "/videos/movies/hd/*" 2336 }, 2337 "_links": { 2338 "pathmetadata": { 2339 "type": "application/cdni.PathMetadata.v1+json", 2340 "href": 2341 "http://metadata.ucdn.example/host1234/pathABC/path123" 2342 } 2343 } 2344 } 2345 ] 2346 } 2348 Finally, if the path of the requested resource also matches the 2349 "/videos/movies/hd/*" pattern, the dCDN would also fetch the 2350 following object from "http://metadata.ucdn.example/host1234/movies/ 2351 hd" with MIME media type "application/cdni.PathMetadata.v1+json": 2353 { 2354 "metadata": [ 2355 { 2356 "generic-metadata-type": 2357 "application/cdni.TimeWindowACL.v1+json", 2358 "generic-metadata-value": { 2359 "times": [ 2360 "windows": [ 2361 { 2362 "start": "1213948800", 2363 "end": "1327393200" 2364 } 2365 ], 2366 "action": "allow" 2367 ] 2368 } 2369 } 2370 ] 2371 } 2373 7. IANA Considerations 2375 This document requests the registration of the following MIME Media 2376 Type under the IANA MIME Media Type registry 2377 (http://www.iana.org/assignments/media-types/index.html). 2379 application/cdni.HostIndex.v1+json 2381 application/cdni.HostMatch.v1+json 2383 application/cdni.HostMetadata.v1+json 2385 application/cdni.PathMatch.v1+json 2387 application/cdni.PatternMatch.v1+json 2389 application/cdni.PathMetadata.v1+json 2391 application/cdni.GenericMetadata.v1+json 2393 application/cdni.SourceMetadata.v1+json 2395 application/cdni.Source.v1+json 2397 application/cdni.LocationACL.v1+json 2399 application/cdni.LocationRule.v1+json 2400 application/cdni.Footprint.v1+json 2402 application/cdni.TimeWindowACL.v1+json 2404 application/cdni.TimeWindowRule.v1+json 2406 application/cdni.TimeWindow.v1+json 2408 application/cdni.ProtocolACL.v1+json 2410 application/cdni.ProtocolRule.v1+json 2412 application/cdni.DeliveryAuthorization.v1+json 2414 application/cdni.Cache.v1+json 2416 application/cdni.Grouping.v1+json 2418 application/cdni.Auth.v1+json 2420 application/cdni.BasicAuth.v1+json 2422 7.1. CDNI Metadata Footprint Types Registry 2424 The IANA is requested to create a new "CDNI Metadata Footprint Types" 2425 registry. The "CDNI Metadata Footprint Types" namespace defines the 2426 valid Footprint object type values used by the Footprint object in 2427 Section 4.2.2.2. Additions to the Footprint type namespace conform 2428 to the "Expert Review" policy as defined in [RFC5226]. The expert 2429 reviewer should verify that new type definitions do not duplicate 2430 existing type definitions and prevent gratuitous additions to the 2431 namespace. 2433 The following table defines the initial Footprint Registry values: 2435 +----------------+-------------------------------+---------------+ 2436 | Footprint Type | Description | Specification | 2437 +----------------+-------------------------------+---------------+ 2438 | ipv4cidr | IPv4 CIDR address block | RFCthis | 2439 | ipv6cidr | IPv6 CIDR address block | RFCthis | 2440 | asn | Autonomous System (AS) Number | RFCthis | 2441 | countrycode | ISO 3166-1 alpha-2 code | RFCthis | 2442 +----------------+-------------------------------+---------------+ 2444 7.2. CDNI Metadata Protocol Types Registry 2446 The IANA is requested to create a new "CDNI Metadata Protocol Types" 2447 registry. The "CDNI Metadata Protocol Types" namespace defines the 2448 valid Protocol object values in Section 4.3.2, used by the 2449 SourceMetadata and ProtocolACL objects. Additions to the Protocol 2450 namespace conform to the "Expert Review" policy as defined in 2451 [RFC5226]. The expert review should verify that new protocol 2452 definitions do not duplicate existing protocol definitions and 2453 prevent gratuitous additions to the namespace. 2455 The following table defines the initial Protocol values: 2457 +--------------+------------------------------------+---------------+ 2458 | Protocol | Description | Specification | 2459 | Type | | | 2460 +--------------+------------------------------------+---------------+ 2461 | http1.1 | Hypertext Transfer Protocol -- | RFC7230 | 2462 | | HTTP/1.1 | | 2463 | https1.1 | HTTP/1.1 Over TLS | RFC2818 | 2464 +--------------+------------------------------------+---------------+ 2466 7.3. CDNI Metadata Auth Types Registry 2468 The IANA is requested to create a new "CDNI Metadata Auth Types" 2469 registry. The "CDNI Metadata Auth Type" namespace defines the valid 2470 Auth object types used by the Auth object in Section 4.2.7. 2471 Additions to the Auth Type namespace conform to the "Expert Review" 2472 policy as defined in [RFC5226]. The expert review should verify that 2473 new type definitions do not duplicate existing type definitions and 2474 prevent gratuitous additions to the namespace. 2476 The following table defines the initial Auth type values: 2478 +-----------+---------------------------------------+---------------+ 2479 | Auth Type | Description | Specification | 2480 +-----------+---------------------------------------+---------------+ 2481 | httpbasic | Username and password authentication | RFCthis | 2482 | | for use with HTTP Basic | | 2483 | | authentication. | | 2484 +-----------+---------------------------------------+---------------+ 2486 8. Security Considerations 2487 8.1. Authentication 2489 Unauthorized access to metadata could result in denial of service. A 2490 malicious metadata server, proxy server or an attacker performing a 2491 "man in the middle" attack could provide malicious metadata to a dCDN 2492 that either: 2494 o Denies service for one or more pieces of content to one or more 2495 User Agents; or 2497 o Directs dCDNs to contact malicious origin servers instead of the 2498 actual origin servers. 2500 Unauthorized access to metadata could also enable a malicious 2501 metadata client to continuously issue large metadata requests in 2502 order to overload a uCDN's metadata server(s). 2504 Unauthorized access to metadata could result in leakage of private 2505 information. A malicious metadata client could request metadata in 2506 order to gain access to origin servers, as well as information 2507 pertaining to content restrictions. 2509 An implementation of the CDNI metadata interface SHOULD use mutual 2510 authentication to prevent unauthorized access to metadata. 2512 8.2. Confidentiality 2514 Unauthorized viewing of metadata could result in leakage of private 2515 information. A third party could intercept metadata transactions in 2516 order to gain access to origin servers, as well as information 2517 pertaining to content restrictions. 2519 An implementation of the CDNI metadata interface SHOULD use strong 2520 encryption to prevent unauthorized interception of metadata. 2522 8.3. Integrity 2524 Unauthorized modification of metadata could result in denial of 2525 service. A malicious metadata server, proxy server or an attacker 2526 performing a "man in the middle" attack" could modify metadata 2527 destined to a dCDN in order to deny service for one or more pieces of 2528 content to one or more user agents. A malicious metadata server, 2529 proxy server or an attacker performing a "Man in the middle" attack 2530 could modify metadata so that dCDNs are directed to contact to 2531 malicious origin servers instead of the actual origin servers. 2533 An implementation of the CDNI metadata interface SHOULD use strong 2534 encryption and mutual authentication to prevent unauthorized 2535 modification of metadata. 2537 8.4. Privacy 2539 Content provider origin and policy information is conveyed through 2540 the CDNI metadata interface. The distribution of this information to 2541 another CDN may introduce potential privacy concerns for some content 2542 providers, for example because dCDNs accepting content requests for a 2543 content provider's content may be able to obtain additional 2544 information & usage patterns relating to the users of a content 2545 provider's services. Content providers with such concerns can 2546 instruct their CDN partners not to use CDN interconnects when 2547 delivering that content provider's content. 2549 8.5. Securing the CDNI Metadata interface 2551 An implementation of the CDNI metadata interface MUST support TLS 2552 transport as per [RFC2818] and [RFC7230]. The use of TLS for 2553 transport of the CDNI metadata interface messages allows: 2555 o The dCDN and uCDN to authenticate each other. 2557 and, once they have mutually authenticated each other, it allows: 2559 o The dCDN and uCDN to authorize each other (to ensure they are 2560 transmitting/receiving CDNI metadata requests & responses from an 2561 authorized CDN). 2563 o CDNI metadata interface requests and responses to be transmitted 2564 with confidentiality. 2566 o The integrity of the CDNI metadata interface requests and 2567 responses to be protected during the exchange. 2569 In an environment where any such protection is required, TLS MUST be 2570 used (including authentication of the remote end) by the server-side 2571 (uCDN) and the client-side (dCDN) of the CDNI metadata interface 2572 unless alternate methods are used for ensuring the confidentiality of 2573 the information in the CDNI metadata interface requests and responses 2574 (such as setting up an IPsec tunnel between the two CDNs or using a 2575 physically secured internal network between two CDNs that are owned 2576 by the same corporate entity). 2578 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 2579 followed. 2581 9. Acknowledgements 2583 The authors would like to thank David Ferguson, Francois Le Faucheur, 2584 Jan Seedorf and Matt Miller for their valuable comments and input to 2585 this document. 2587 10. Contributing Authors 2589 [RFC Editor Note: Please move the contents of this section to the 2590 Authors' Addresses section prior to publication as an RFC.] 2592 Grant Watson 2593 Velocix (Alcatel-Lucent) 2594 3 Ely Road 2595 Milton, Cambridge CB24 6AA 2596 UK 2598 Email: gwatson@velocix.com 2600 Kent Leung 2601 Cisco Systems 2602 3625 Cisco Way 2603 San Jose, 95134 2604 USA 2606 Email: kleung@cisco.com 2608 11. References 2610 11.1. Normative References 2612 [ISO3166-1] 2613 "https://www.iso.org/obp/ui/#search". 2615 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2616 Requirement Levels", BCP 14, RFC 2119, 2617 DOI 10.17487/RFC2119, March 1997, 2618 . 2620 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 2621 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2622 2006, . 2624 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 2625 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 2626 DOI 10.17487/RFC5226, May 2008, 2627 . 2629 [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale 2630 Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, 2631 . 2633 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 2634 Address Text Representation", RFC 5952, 2635 DOI 10.17487/RFC5952, August 2010, 2636 . 2638 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 2639 Protocol (HTTP/1.1): Message Syntax and Routing", 2640 RFC 7230, DOI 10.17487/RFC7230, June 2014, 2641 . 2643 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 2644 "Recommendations for Secure Use of Transport Layer 2645 Security (TLS) and Datagram Transport Layer Security 2646 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2647 2015, . 2649 11.2. Informative References 2651 [I-D.ietf-cdni-redirection] 2652 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 2653 Redirection Interface for CDN Interconnection", draft- 2654 ietf-cdni-redirection-11 (work in progress), July 2015. 2656 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, 2657 DOI 10.17487/RFC2818, May 2000, 2658 . 2660 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 2661 Resource Identifier (URI): Generic Syntax", STD 66, 2662 RFC 3986, DOI 10.17487/RFC3986, January 2005, 2663 . 2665 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 2666 Distribution Network Interconnection (CDNI) Problem 2667 Statement", RFC 6707, DOI 10.17487/RFC6707, September 2668 2012, . 2670 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 2671 "Framework for Content Distribution Network 2672 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 2673 August 2014, . 2675 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 2676 Network Interconnection (CDNI) Requirements", RFC 7337, 2677 DOI 10.17487/RFC7337, August 2014, 2678 . 2680 [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, 2681 DOI 10.17487/RFC7493, March 2015, 2682 . 2684 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 2685 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 2686 DOI 10.17487/RFC7540, May 2015, 2687 . 2689 Authors' Addresses 2691 Ben Niven-Jenkins 2692 Velocix (Alcatel-Lucent) 2693 3 Ely Road 2694 Milton, Cambridge CB24 6AA 2695 UK 2697 Email: ben@velocix.com 2699 Rob Murray 2700 Velocix (Alcatel-Lucent) 2701 3 Ely Road 2702 Milton, Cambridge CB24 6AA 2703 UK 2705 Email: rmurray@velocix.com 2707 Matt Caulfield 2708 Cisco Systems 2709 1414 Massachusetts Avenue 2710 Boxborough, MA 01719 2711 USA 2713 Phone: +1 978 936 9307 2714 Email: mcaulfie@cisco.com 2715 Kevin J. Ma 2716 Ericsson 2717 43 Nagog Park 2718 Acton, MA 01720 2719 USA 2721 Phone: +1 978-844-5100 2722 Email: kevin.j.ma@ericsson.com