| < draft-ietf-cdni-metadata-15.txt | draft-ietf-cdni-metadata-21.txt > | |||
|---|---|---|---|---|
| Network Working Group B. Niven-Jenkins | Network Working Group B. Niven-Jenkins | |||
| Internet-Draft R. Murray | Internet-Draft R. Murray | |||
| Intended status: Standards Track Velocix (Alcatel-Lucent) | Intended status: Standards Track Velocix (Alcatel-Lucent) | |||
| Expires: October 14, 2016 M. Caulfield | Expires: March 1, 2017 M. Caulfield | |||
| Cisco Systems | Cisco Systems | |||
| K. Ma | K. Ma | |||
| Ericsson | Ericsson | |||
| April 12, 2016 | August 28, 2016 | |||
| CDN Interconnection Metadata | CDN Interconnection Metadata | |||
| draft-ietf-cdni-metadata-15 | draft-ietf-cdni-metadata-21 | |||
| Abstract | Abstract | |||
| The Content Delivery Networks Interconnection (CDNI) metadata | The Content Delivery Networks Interconnection (CDNI) metadata | |||
| interface enables interconnected Content Delivery Networks (CDNs) to | interface enables interconnected Content Delivery Networks (CDNs) to | |||
| exchange content distribution metadata in order to enable content | exchange content distribution metadata in order to enable content | |||
| acquisition and delivery. The CDNI metadata associated with a piece | acquisition and delivery. The CDNI metadata associated with a piece | |||
| of content provides a downstream CDN with sufficient information for | of content provides a downstream CDN with sufficient information for | |||
| the downstream CDN to service content requests on behalf of an | the downstream CDN to service content requests on behalf of an | |||
| upstream CDN. This document describes both a base set of CDNI | upstream CDN. This document describes both a base set of CDNI | |||
| skipping to change at page 1, line 47 ¶ | skipping to change at page 1, line 47 ¶ | |||
| Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
| Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
| working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
| Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
| Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
| and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
| time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
| material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
| This Internet-Draft will expire on October 14, 2016. | This Internet-Draft will expire on March 1, 2017. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2016 IETF Trust and the persons identified as the | Copyright (c) 2016 IETF Trust and the persons identified as the | |||
| document authors. All rights reserved. | document authors. All rights reserved. | |||
| This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
| Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
| (http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
| publication of this document. Please review these documents | publication of this document. Please review these documents | |||
| skipping to change at page 2, line 34 ¶ | skipping to change at page 2, line 34 ¶ | |||
| 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5 | 1.2. Supported Metadata Capabilities . . . . . . . . . . . . . 5 | |||
| 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 | 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 | |||
| 3. CDNI Metadata object model . . . . . . . . . . . . . . . . . 7 | 3. CDNI Metadata object model . . . . . . . . . . . . . . . . . 7 | |||
| 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, | 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, | |||
| PatternMatch and PathMetadata objects . . . . . . . . . . 8 | PatternMatch and PathMetadata objects . . . . . . . . . . 8 | |||
| 3.2. Generic CDNI Metadata Objects . . . . . . . . . . . . . . 10 | 3.2. Generic CDNI Metadata Objects . . . . . . . . . . . . . . 10 | |||
| 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13 | 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 13 | |||
| 4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 14 | 4. CDNI Metadata objects . . . . . . . . . . . . . . . . . . . . 14 | |||
| 4.1. Definitions of the CDNI structural metadata objects . . . 15 | 4.1. Definitions of the CDNI structural metadata objects . . . 15 | |||
| 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15 | 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 16 | 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17 | 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 17 | |||
| 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 18 | 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 18 | |||
| 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 19 | 4.1.5. PatternMatch . . . . . . . . . . . . . . . . . . . . 19 | |||
| 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 20 | 4.1.6. PathMetadata . . . . . . . . . . . . . . . . . . . . 20 | |||
| 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 21 | 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 21 | |||
| 4.2. Definitions of the initial set of CDNI Generic Metadata | 4.2. Definitions of the initial set of CDNI Generic Metadata | |||
| objects . . . . . . . . . . . . . . . . . . . . . . . . . 23 | objects . . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 23 | 4.2.1. SourceMetadata . . . . . . . . . . . . . . . . . . . 23 | |||
| 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 24 | 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 24 | |||
| 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 25 | 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 25 | |||
| 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 27 | 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 27 | |||
| 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 27 | 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 27 | |||
| 4.2.3. TimeWindowACL . . . . . . . . . . . . . . . . . . . . 28 | 4.2.3. TimeWindowACL . . . . . . . . . . . . . . . . . . . . 29 | |||
| 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 29 | 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 30 | |||
| 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 30 | 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 31 | |||
| 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 31 | 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 31 | |||
| 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 32 | 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 32 | |||
| 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 32 | 4.2.5. DeliveryAuthorization Metadata . . . . . . . . . . . 33 | |||
| 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 33 | 4.2.6. Cache . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 4.2.7. Auth . . . . . . . . . . . . . . . . . . . . . . . . 34 | 4.2.7. Auth . . . . . . . . . . . . . . . . . . . . . . . . 36 | |||
| 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 35 | 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 35 | 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 37 | |||
| 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 35 | 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 37 | |||
| 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 37 | 4.3.1.1. Link Loop Prevention . . . . . . . . . . . . . . 39 | |||
| 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 37 | 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 4.3.4. Time . . . . . . . . . . . . . . . . . . . . . . . . 38 | 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 39 | |||
| 4.3.5. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 38 | 4.3.4. Time . . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
| 4.3.6. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 38 | 4.3.5. IPv4CIDR . . . . . . . . . . . . . . . . . . . . . . 40 | |||
| 4.3.7. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 38 | 4.3.6. IPv6CIDR . . . . . . . . . . . . . . . . . . . . . . 40 | |||
| 4.3.8. CountryCode . . . . . . . . . . . . . . . . . . . . . 39 | 4.3.7. ASN . . . . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 39 | 4.3.8. CountryCode . . . . . . . . . . . . . . . . . . . . . 41 | |||
| 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 39 | 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 41 | |||
| 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 40 | 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 42 | |||
| 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 41 | 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
| 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 42 | 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 43 | |||
| 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 42 | 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 44 | |||
| 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 43 | 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 44 | |||
| 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 44 | 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 45 | |||
| 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 44 | 6.6. Metadata Enforcement . . . . . . . . . . . . . . . . . . 46 | |||
| 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 45 | 6.7. Metadata Conflicts . . . . . . . . . . . . . . . . . . . 46 | |||
| 6.9. Media Types . . . . . . . . . . . . . . . . . . . . . . . 45 | 6.8. Versioning . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
| 6.10. Complete CDNI Metadata Example . . . . . . . . . . . . . 46 | 6.9. Media Types . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
| 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 | 6.10. Complete CDNI Metadata Example . . . . . . . . . . . . . 48 | |||
| 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 50 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52 | |||
| 7.1.1. CDNI MI HostIndex Payload Type . . . . . . . . . . . 50 | 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 52 | |||
| 7.1.2. CDNI MI HostMatch Payload Type . . . . . . . . . . . 51 | 7.1.1. CDNI MI HostIndex Payload Type . . . . . . . . . . . 53 | |||
| 7.1.3. CDNI MI HostMetadata Payload Type . . . . . . . . . . 51 | 7.1.2. CDNI MI HostMatch Payload Type . . . . . . . . . . . 53 | |||
| 7.1.4. CDNI MI PathMatch Payload Type . . . . . . . . . . . 51 | 7.1.3. CDNI MI HostMetadata Payload Type . . . . . . . . . . 54 | |||
| 7.1.5. CDNI MI PatternMatch Payload Type . . . . . . . . . . 51 | 7.1.4. CDNI MI PathMatch Payload Type . . . . . . . . . . . 54 | |||
| 7.1.6. CDNI MI PathMetadata Payload Type . . . . . . . . . . 51 | 7.1.5. CDNI MI PatternMatch Payload Type . . . . . . . . . . 54 | |||
| 7.1.7. CDNI MI SourceMetadata Payload Type . . . . . . . . . 52 | 7.1.6. CDNI MI PathMetadata Payload Type . . . . . . . . . . 54 | |||
| 7.1.8. CDNI MI Source Payload Type . . . . . . . . . . . . . 52 | 7.1.7. CDNI MI SourceMetadata Payload Type . . . . . . . . . 54 | |||
| 7.1.9. CDNI MI LocationACL Payload Type . . . . . . . . . . 52 | 7.1.8. CDNI MI Source Payload Type . . . . . . . . . . . . . 55 | |||
| 7.1.10. CDNI MI LocationRule Payload Type . . . . . . . . . . 52 | 7.1.9. CDNI MI LocationACL Payload Type . . . . . . . . . . 55 | |||
| 7.1.11. CDNI MI Footprint Payload Type . . . . . . . . . . . 52 | 7.1.10. CDNI MI LocationRule Payload Type . . . . . . . . . . 55 | |||
| 7.1.12. CDNI MI TimeWindowACL Payload Type . . . . . . . . . 53 | 7.1.11. CDNI MI Footprint Payload Type . . . . . . . . . . . 55 | |||
| 7.1.13. CDNI MI TimeWindowRule Payload Type . . . . . . . . . 53 | 7.1.12. CDNI MI TimeWindowACL Payload Type . . . . . . . . . 55 | |||
| 7.1.14. CDNI MI TimeWindow Payload Type . . . . . . . . . . . 53 | 7.1.13. CDNI MI TimeWindowRule Payload Type . . . . . . . . . 56 | |||
| 7.1.15. CDNI MI ProtocolACL Payload Type . . . . . . . . . . 53 | 7.1.14. CDNI MI TimeWindow Payload Type . . . . . . . . . . . 56 | |||
| 7.1.16. CDNI MI ProtocolRule Payload Type . . . . . . . . . . 53 | 7.1.15. CDNI MI ProtocolACL Payload Type . . . . . . . . . . 56 | |||
| 7.1.17. CDNI MI DeliveryAuthorization Payload Type . . . . . 54 | 7.1.16. CDNI MI ProtocolRule Payload Type . . . . . . . . . . 56 | |||
| 7.1.18. CDNI MI Cache Payload Type . . . . . . . . . . . . . 54 | 7.1.17. CDNI MI DeliveryAuthorization Payload Type . . . . . 56 | |||
| 7.1.19. CDNI MI Auth Payload Type . . . . . . . . . . . . . . 54 | 7.1.18. CDNI MI Cache Payload Type . . . . . . . . . . . . . 57 | |||
| 7.1.20. CDNI MI Grouping Payload Type . . . . . . . . . . . . 54 | 7.1.19. CDNI MI Auth Payload Type . . . . . . . . . . . . . . 57 | |||
| 7.2. CDNI Metadata Footprint Types Registry . . . . . . . . . 54 | 7.1.20. CDNI MI Grouping Payload Type . . . . . . . . . . . . 57 | |||
| 7.3. CDNI Metadata Protocol Types Registry . . . . . . . . . . 55 | 7.2. CDNI Metadata Footprint Types Registry . . . . . . . . . 57 | |||
| 7.4. CDNI Metadata Auth Types Registry . . . . . . . . . . . . 56 | 7.3. CDNI Metadata Protocol Types Registry . . . . . . . . . . 58 | |||
| 8. Security Considerations . . . . . . . . . . . . . . . . . . . 56 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 58 | |||
| 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 56 | 8.1. Authentication and Integrity . . . . . . . . . . . . . . 59 | |||
| 8.2. Confidentiality . . . . . . . . . . . . . . . . . . . . . 57 | 8.2. Confidentiality and Privacy . . . . . . . . . . . . . . . 59 | |||
| 8.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 57 | 8.3. Securing the CDNI Metadata interface . . . . . . . . . . 60 | |||
| 8.4. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 57 | 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 60 | |||
| 8.5. Securing the CDNI Metadata interface . . . . . . . . . . 58 | 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 60 | |||
| 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 58 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 61 | |||
| 10. Contributing Authors . . . . . . . . . . . . . . . . . . . . 58 | 11.1. Normative References . . . . . . . . . . . . . . . . . . 61 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 | 11.2. Informative References . . . . . . . . . . . . . . . . . 63 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . 59 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 64 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . 60 | ||||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 61 | ||||
| 1. Introduction | 1. Introduction | |||
| Content Delivery Networks Interconnection (CDNI) [RFC6707] enables a | Content Delivery Networks Interconnection (CDNI) [RFC6707] enables a | |||
| downstream Content Delivery Network (dCDN) to service content | downstream Content Delivery Network (dCDN) to service content | |||
| requests on behalf of an upstream CDN (uCDN). | requests on behalf of an upstream CDN (uCDN). | |||
| The CDNI metadata interface is discussed in [RFC7336] along with four | The CDNI metadata interface is discussed in [RFC7336] along with four | |||
| other interfaces that can be used to compose a CDNI solution (CDNI | other interfaces that can be used to compose a CDNI solution (CDNI | |||
| Control interface, CDNI Request Routing Redirection interface, CDNI | Control interface, CDNI Request Routing Redirection interface, CDNI | |||
| skipping to change at page 6, line 17 ¶ | skipping to change at page 6, line 17 ¶ | |||
| interconnection for the delivery of content by a dCDN using HTTP/1.1 | interconnection for the delivery of content by a dCDN using HTTP/1.1 | |||
| [RFC7230] and for a dCDN to be able to acquire content from a uCDN | [RFC7230] and for a dCDN to be able to acquire content from a uCDN | |||
| using either HTTP/1.1 or HTTP/1.1 over TLS [RFC2818]. | using either HTTP/1.1 or HTTP/1.1 over TLS [RFC2818]. | |||
| Supporting CDN interconnection for the delivery of content using | Supporting CDN interconnection for the delivery of content using | |||
| unencrypted HTTP/2 [RFC7540] (as well as for a dCDN to acquire | unencrypted HTTP/2 [RFC7540] (as well as for a dCDN to acquire | |||
| content using unencrypted HTTP/2 or HTTP/2 over TLS) requires the | content using unencrypted HTTP/2 or HTTP/2 over TLS) requires the | |||
| registration of these protocol names in the CDNI Metadata Protocol | registration of these protocol names in the CDNI Metadata Protocol | |||
| Types registry Section 7.3. | Types registry Section 7.3. | |||
| Supporting CDN interconnection for the delivery of content using | Delivery of content using HTTP/1.1 over TLS or HTTP/2 over TLS SHOULD | |||
| HTTP/1.1 over TLS or HTTP/2 over TLS requires specifying additional | follow the guidelines set forth in [RFC7525]. Offline configuration | |||
| metadata objects to carry the properties required to establish a TLS | of TLS parameters between CDNs is beyond the scope of this document. | |||
| session, for example metadata to describe the certificate to use as | ||||
| part of the TLS handshake. | ||||
| 2. Design Principles | 2. Design Principles | |||
| The CDNI metadata interface was designed to achieve the following | The CDNI metadata interface was designed to achieve the following | |||
| objectives: | objectives: | |||
| 1. Cacheability of CDNI metadata objects; | 1. Cacheability of CDNI metadata objects; | |||
| 2. Deterministic mapping from redirection requests and content | 2. Deterministic mapping from redirection requests and content | |||
| requests to CDNI metadata properties; | requests to CDNI metadata properties; | |||
| skipping to change at page 7, line 19 ¶ | skipping to change at page 7, line 19 ¶ | |||
| such as data structure encoding (by leveraging I-JSON [RFC7493]) and | such as data structure encoding (by leveraging I-JSON [RFC7493]) and | |||
| data transport (by leveraging HTTP [RFC7230]). | data transport (by leveraging HTTP [RFC7230]). | |||
| 3. CDNI Metadata object model | 3. CDNI Metadata object model | |||
| The CDNI metadata object model describes a data structure for mapping | The CDNI metadata object model describes a data structure for mapping | |||
| redirection requests and content requests to metadata properties. | redirection requests and content requests to metadata properties. | |||
| Metadata properties describe how to acquire content from an uCDN, | Metadata properties describe how to acquire content from an uCDN, | |||
| authorize access to content, and deliver content from a dCDN. The | authorize access to content, and deliver content from a dCDN. The | |||
| object model relies on the assumption that these metadata properties | object model relies on the assumption that these metadata properties | |||
| can be aggregated based on the hostname of the content and | can be grouped based on the hostname of the content and subsequently | |||
| subsequently on the resource path (URI) of the content. The object | on the resource path (URI) of the content. The object model | |||
| model associates a set of CDNI metadata properties with a Hostname to | associates a set of CDNI metadata properties with a Hostname to form | |||
| form a default set of metadata properties for content delivered on | a default set of metadata properties for content delivered on behalf | |||
| behalf of that Hostname. That default set of metadata properties can | of that Hostname. That default set of metadata properties can be | |||
| be overridden by properties that apply to specific paths within a | overridden by properties that apply to specific paths within a URI. | |||
| URI. | ||||
| Different Hostnames and URI paths will be associated with different | Different Hostnames and URI paths will be associated with different | |||
| sets of CDNI metadata properties in order to describe the required | sets of CDNI metadata properties in order to describe the required | |||
| behaviour when a dCDN surrogate or request router is processing User | behaviour when a dCDN surrogate or request router is processing User | |||
| Agent requests for content at that Hostname and URI path. As a | Agent requests for content at that Hostname and URI path. As a | |||
| result of this structure, significant commonality could exist between | result of this structure, significant commonality could exist between | |||
| the CDNI metadata properties specified for different Hostnames, | the CDNI metadata properties specified for different Hostnames, | |||
| different URI paths within a Hostname and different URI paths on | different URI paths within a Hostname and different URI paths on | |||
| different Hostnames. For example the definition of which User Agent | different Hostnames. For example the definition of which User Agent | |||
| IP addresses should be grouped together into a single network or | IP addresses should be grouped together into a single network or | |||
| skipping to change at page 9, line 5 ¶ | skipping to change at page 9, line 5 ¶ | |||
| (*) (1) (1) +------------+ | | (*) (1) (1) +------------+ | | |||
| | | +->|PatternMatch| | | | | +->|PatternMatch| | | |||
| | V +------------+ | | | V +------------+ | | |||
| | +------------+ | | | +------------+ | | |||
| +--+PathMetadata+-------(*)------+ | +--+PathMetadata+-------(*)------+ | |||
| +------------+ | +------------+ | |||
| Figure 1: Relationships between CDNI Metadata Objects (Diagram | Figure 1: Relationships between CDNI Metadata Objects (Diagram | |||
| Representation) | Representation) | |||
| A HostIndex object (see Section 4.1.1) contains a list of HostMatch | A HostIndex object (see Section 4.1.1) contains an array of HostMatch | |||
| objects (see Section 4.1.2) that contain Hostnames (and/or IP | objects (see Section 4.1.2) that contain Hostnames (and/or IP | |||
| addresses) for which content requests might be delegated to the dCDN. | addresses) for which content requests might be delegated to the dCDN. | |||
| The HostIndex is the starting point for accessing the uCDN CDNI | The HostIndex is the starting point for accessing the uCDN CDNI | |||
| metadata data store. It enables the dCDN to deterministically | metadata data store. It enables the dCDN to deterministically | |||
| discover which CDNI metadata objects it requires in order to deliver | discover which CDNI metadata objects it requires in order to deliver | |||
| a given piece of content. | a given piece of content. | |||
| The HostIndex links Hostnames (and/or IP addresses) to HostMetadata | The HostIndex links Hostnames (and/or IP addresses) to HostMetadata | |||
| objects (see Section 4.1.3) via HostMatch objects. A HostMatch | objects (see Section 4.1.3) via HostMatch objects. A HostMatch | |||
| object defines a Hostname (or IP address) to match against a | object defines a Hostname (or IP address) to match against a | |||
| skipping to change at page 10, line 44 ¶ | skipping to change at page 10, line 44 ¶ | |||
| GenericMetadata object abstracts the basic information required for | GenericMetadata object abstracts the basic information required for | |||
| metadata override and metadata distribution, from the specifics of | metadata override and metadata distribution, from the specifics of | |||
| any given property (i.e., property semantics, enforcement options, | any given property (i.e., property semantics, enforcement options, | |||
| etc.). | etc.). | |||
| The GenericMetadata object defines the properties contained within it | The GenericMetadata object defines the properties contained within it | |||
| as well as whether or not the properties are "mandatory-to-enforce". | as well as whether or not the properties are "mandatory-to-enforce". | |||
| If the dCDN does not understand or support a "mandatory-to-enforce" | If the dCDN does not understand or support a "mandatory-to-enforce" | |||
| property, the dCDN MUST NOT serve the content. If the property is | property, the dCDN MUST NOT serve the content. If the property is | |||
| not "mandatory-to-enforce", then that GenericMetadata object can be | not "mandatory-to-enforce", then that GenericMetadata object can be | |||
| safely ignored and the dCDN MUST process the content request in | safely ignored and the content request can be processed in accordance | |||
| accordance with the rest of the CDNI metadata. | with the rest of the CDNI metadata. | |||
| Although a CDN MUST NOT serve content to a User Agent if a | Although a CDN MUST NOT serve content to a User Agent if a | |||
| "mandatory-to-enforce" property cannot be enforced, it could still be | "mandatory-to-enforce" property cannot be enforced, it could still be | |||
| "safe-to-redistribute" that metadata to another CDN without | "safe-to-redistribute" that metadata to another CDN without | |||
| modification. For example, in the cascaded CDN case, a transit CDN | modification. For example, in the cascaded CDN case, a transit CDN | |||
| (tCDN) could pass through "mandatory-to-enforce" metadata to a dCDN. | (tCDN) could pass through "mandatory-to-enforce" metadata to a dCDN. | |||
| For metadata which does not require customization or translation | For metadata which does not require customization or translation | |||
| (i.e., metadata that is "safe-to-redistribute"), the data | (i.e., metadata that is "safe-to-redistribute"), the data | |||
| representation received off the wire MAY be stored and redistributed | representation received off the wire MAY be stored and redistributed | |||
| skipping to change at page 14, line 6 ¶ | skipping to change at page 14, line 6 ¶ | |||
| GenericMetadata object of type TimeWindowACL, then: | GenericMetadata object of type TimeWindowACL, then: | |||
| o the TimeWindowACL defined in the PathMetadata would override the | o the TimeWindowACL defined in the PathMetadata would override the | |||
| TimeWindowACL defined in the HostMetadata for all User Agent | TimeWindowACL defined in the HostMetadata for all User Agent | |||
| requests for content under "example.com/movies/", and | requests for content under "example.com/movies/", and | |||
| o the LocationACL defined in the HostMetadata would be inherited for | o the LocationACL defined in the HostMetadata would be inherited for | |||
| all User Agent requests for content under "example.com/movies/". | all User Agent requests for content under "example.com/movies/". | |||
| A single HostMetadata or PathMetadata object MUST NOT contain | A single HostMetadata or PathMetadata object MUST NOT contain | |||
| multiple GenericMetadata objects of the same type. If a list of | multiple GenericMetadata objects of the same type. If an array of | |||
| GenericMetadata contains objects of duplicate types, the receiver | GenericMetadata contains objects of duplicate types, the receiver | |||
| MUST ignore all but the first object of each type. | MUST ignore all but the first object of each type. | |||
| 4. CDNI Metadata objects | 4. CDNI Metadata objects | |||
| Section 4.1 provides the definitions of each metadata object type | Section 4.1 provides the definitions of each metadata object type | |||
| introduced in Section 3. These metadata objects are described as | introduced in Section 3. These metadata objects are described as | |||
| structural metadata objects as they provide the structure for host | structural metadata objects as they provide the structure for host | |||
| and URI path-based inheritance and identify which GenericMetadata | and URI path-based inheritance and identify which GenericMetadata | |||
| objects apply to a given User Agent content request. | objects apply to a given User Agent content request. | |||
| skipping to change at page 14, line 41 ¶ | skipping to change at page 14, line 41 ¶ | |||
| standards-based or vendor specific GenericMetadata objects that might | standards-based or vendor specific GenericMetadata objects that might | |||
| be defined in the future in separate documents. | be defined in the future in separate documents. | |||
| dCDNs and tCDNs MUST support parsing of all CDNI metadata objects | dCDNs and tCDNs MUST support parsing of all CDNI metadata objects | |||
| specified in this document. A dCDN does not have to implement the | specified in this document. A dCDN does not have to implement the | |||
| underlying functionality represented by non-structural | underlying functionality represented by non-structural | |||
| GenericMetadata objects (though that might restrict the content that | GenericMetadata objects (though that might restrict the content that | |||
| a given dCDN will be able to serve). uCDNs as generators of CDNI | a given dCDN will be able to serve). uCDNs as generators of CDNI | |||
| metadata only need to support generating the CDNI metadata that they | metadata only need to support generating the CDNI metadata that they | |||
| need in order to express the policies required by the content they | need in order to express the policies required by the content they | |||
| are describing. | are describing. See Section 6.4 for more details on the specific | |||
| encoding rules for CDNI metadata objects. | ||||
| CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] | ||||
| containing a dictionary of (key,value) pairs where the keys are the | ||||
| property names and the values are the associated property values. | ||||
| See Section 6.4 for more details of the specific encoding rules for | ||||
| CDNI metadata objects. | ||||
| Note: In the following sections, the term "mandatory-to-specify" is | Note: In the following sections, the term "mandatory-to-specify" is | |||
| used to convey which properties MUST be included for a given | used to convey which properties MUST be included for a given | |||
| structural or GenericMetadata object. When mandatory-to-specify is | structural or GenericMetadata object. When mandatory-to-specify is | |||
| specified as "Yes" for an individual property, it means that if the | specified as "Yes" for an individual property, it means that if the | |||
| object containing that property is included in a metadata response, | object containing that property is included in a metadata response, | |||
| then the mandatory-to-specify property MUST also be included | then the mandatory-to-specify property MUST also be included | |||
| (directly or by reference) in the response, e.g., a HostMatch | (directly or by reference) in the response, e.g., a HostMatch | |||
| property object without a host to match against does not make sense, | property object without a host to match against does not make sense, | |||
| therefore, the host property is mandatory-to-specify inside a | therefore, the host property is mandatory-to-specify inside a | |||
| HostMatch object. | HostMatch object. | |||
| 4.1. Definitions of the CDNI structural metadata objects | 4.1. Definitions of the CDNI structural metadata objects | |||
| Each of the sub-sections below describe the structural objects | Each of the sub-sections below describe the structural objects | |||
| introduced in Section 3.1. | introduced in Section 3.1. | |||
| 4.1.1. HostIndex | 4.1.1. HostIndex | |||
| The HostIndex object is the entry point into the CDNI metadata | The HostIndex object is the entry point into the CDNI metadata | |||
| hierarchy. It contains a list of HostMatch objects. An incoming | hierarchy. It contains an array of HostMatch objects. An incoming | |||
| content request is checked against the Hostname (or IP address) | content request is checked against the Hostname (or IP address) | |||
| specified by each of the listed HostMatch objects to find the | specified by each of the listed HostMatch objects to find the | |||
| HostMatch object which applies to the request. | HostMatch object which applies to the request. | |||
| Property: hosts | Property: hosts | |||
| Description: List of HostMatch objects. Hosts (HostMatch | Description: Array of HostMatch objects. Hosts (HostMatch | |||
| objects) MUST be evaluated in the order they appear and the | objects) MUST be evaluated in the order they appear and the | |||
| first HostMatch object that matches the content request being | first HostMatch object that matches the content request being | |||
| processed MUST be used. | processed MUST be used. | |||
| Type: List of HostMatch objects | Type: Array of HostMatch objects | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Example HostIndex object containing two HostMatch objects, where the | Example HostIndex object containing two HostMatch objects, where the | |||
| first HostMatch object is embedded and the second HostMatch object is | first HostMatch object is embedded and the second HostMatch object is | |||
| referenced: | referenced: | |||
| { | { | |||
| "hosts": [ | "hosts": [ | |||
| { | { | |||
| <Properties of embedded HostMatch object> | <Properties of embedded HostMatch object> | |||
| }, | }, | |||
| { | { | |||
| "type": "MI.HostMatch", | "type": "MI.HostMatch", | |||
| "href": "http://metadata.ucdn.example/hostmatch1234" | "href": "https://metadata.ucdn.example/hostmatch1234" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| 4.1.2. HostMatch | 4.1.2. HostMatch | |||
| The HostMatch object contains a Hostname or IP address to match | The HostMatch object contains a Hostname or IP address to match | |||
| against content requests. The HostMatch object also contains a | against content requests. The HostMatch object also contains a | |||
| HostMetadata object to apply if a match is found. | HostMetadata object to apply if a match is found. | |||
| Property: host | Property: host | |||
| Description: Hostname or IP address to match against the | Description: Hostname or IP address and optional port to match | |||
| requested host. In order for a Hostname or IP address in a | against the requested host, i.e., the [RFC3986] host and port. | |||
| content request to match the Hostname or IP address in the host | In order for a Hostname or IP address in a content request to | |||
| property the value from the content request when converted to | match the Hostname or IP address in the host property the value | |||
| lowercase MUST be identical to the value of the host property | from the content request when converted to lowercase MUST be | |||
| when converted to lowercase. | identical to the value of the host property when converted to | |||
| lowercase. All implementations MUST support IPv4 addresses | ||||
| encoded as specified by the 'IPv4address' rule in Section 3.2.2 | ||||
| of [RFC3986]. IPv6 addresses MUST be encoded in one of the | ||||
| IPv6 address formats specified in [RFC5952] although receivers | ||||
| MUST support all IPv6 address formats specified in [RFC4291]. | ||||
| Hostnames MUST conform to the Domain Name System (DNS) syntax | ||||
| defined in [RFC1034] and [RFC1123]. Internationalized Domain | ||||
| Names (IDN) must first be transformed to the the A-label form | ||||
| [RFC5890] as per [RFC5891]. | ||||
| Type: Endpoint | Type: Endpoint | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: host-metadata | Property: host-metadata | |||
| Description: CDNI metadata to apply when delivering content | Description: CDNI metadata to apply when delivering content | |||
| that matches this host. | that matches this host. | |||
| skipping to change at page 16, line 49 ¶ | skipping to change at page 17, line 9 ¶ | |||
| } | } | |||
| } | } | |||
| Example HostMatch object referencing (via a Link object, see | Example HostMatch object referencing (via a Link object, see | |||
| Section 4.3.1) a HostMetadata object: | Section 4.3.1) a HostMetadata object: | |||
| { | { | |||
| "host": "video.example.com", | "host": "video.example.com", | |||
| "host-metadata" : { | "host-metadata" : { | |||
| "type": "MI.HostMetadata", | "type": "MI.HostMetadata", | |||
| "href": "http://metadata.ucdn.example/host1234" | "href": "https://metadata.ucdn.example/host1234" | |||
| } | } | |||
| } | } | |||
| 4.1.3. HostMetadata | 4.1.3. HostMetadata | |||
| A HostMetadata object contains the CDNI metadata properties for | A HostMetadata object contains the CDNI metadata properties for | |||
| content served for a particular host (defined in the HostMatch | content served for a particular host (defined in the HostMatch | |||
| object) and possibly child PathMatch objects. | object) and possibly child PathMatch objects. | |||
| Property: metadata | Property: metadata | |||
| Description: List of host related metadata. | Description: Array of host related metadata. | |||
| Type: List of GenericMetadata objects | Type: Array of GenericMetadata objects | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: paths | Property: paths | |||
| Description: Path specific rules. Path patterns (PathMatch | Description: Path specific rules. Path patterns (PathMatch | |||
| objects) MUST be evaluated in the order they appear and the | objects) MUST be evaluated in the order they appear and the | |||
| first PathMatch object that matches the content request being | first (and only the first) PathMatch object that matches the | |||
| processed MUST be used. | content request being processed MUST be used. | |||
| Type: List of PathMatch objects | Type: Array of PathMatch objects | |||
| Mandatory-to-Specify: No. | Mandatory-to-Specify: No. | |||
| Example HostMetadata object containing a number of embedded | Example HostMetadata object containing a number of embedded | |||
| GenericMetadata objects that will describe the default metadata for | GenericMetadata objects that will describe the default metadata for | |||
| the host and an embedded PathMatch object that contains a path for | the host and an embedded PathMatch object that contains a path for | |||
| which metadata exists that overrides the default metadata for the | which metadata exists that overrides the default metadata for the | |||
| host: | host: | |||
| { | { | |||
| skipping to change at page 18, line 30 ¶ | skipping to change at page 18, line 30 ¶ | |||
| "paths": [ | "paths": [ | |||
| { | { | |||
| <Properties of embedded PathMatch object> | <Properties of embedded PathMatch object> | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| 4.1.4. PathMatch | 4.1.4. PathMatch | |||
| A PathMatch object contains PatternMatch object with a path to match | A PathMatch object contains PatternMatch object with a path to match | |||
| against a resource's URI path, as well as a PathMetadata object with | against a resource's URI path, as well as how to handle URI query | |||
| GenericMetadata to apply if the resource's URI path matches the | parameters. The PathMatch also contains a PathMetadata object with | |||
| pattern within the PatternMatch object. | GenericMetadata to apply if the resource's URI matches the pattern | |||
| within the PatternMatch object. | ||||
| Property: path-pattern | Property: path-pattern | |||
| Description: Pattern to match against the requested resource's | Description: Pattern to match against the requested resource's | |||
| URI path, i.e., against the [RFC3986] path-absolute. | URI. | |||
| Type: PatternMatch | Type: PatternMatch | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: path-metadata | Property: path-metadata | |||
| Description: CDNI metadata to apply when delivering content | Description: CDNI metadata to apply when delivering content | |||
| that matches the associated PatternMatch. | that matches the associated PatternMatch. | |||
| skipping to change at page 19, line 16 ¶ | skipping to change at page 19, line 16 ¶ | |||
| for URIs that match the case-sensitive URI path pattern "/movies/*" | for URIs that match the case-sensitive URI path pattern "/movies/*" | |||
| (contained within an embedded PatternMatch object): | (contained within an embedded PatternMatch object): | |||
| { | { | |||
| "path-pattern": { | "path-pattern": { | |||
| "pattern": "/movies/*", | "pattern": "/movies/*", | |||
| "case-sensitive": true | "case-sensitive": true | |||
| }, | }, | |||
| "path-metadata": { | "path-metadata": { | |||
| "type": "MI.PathMetadata", | "type": "MI.PathMetadata", | |||
| "href": "http://metadata.ucdn.example/host1234/pathDCE" | "href": "https://metadata.ucdn.example/host1234/pathDCE" | |||
| } | } | |||
| } | } | |||
| 4.1.5. PatternMatch | 4.1.5. PatternMatch | |||
| A PatternMatch object contains the pattern string and flags that | A PatternMatch object contains the pattern string and flags that | |||
| describe the pattern expression. | describe the pattern expression. | |||
| Property: pattern | Property: pattern | |||
| Description: A pattern for string matching. The pattern can | Description: A pattern for matching against the URI path, i.e., | |||
| contain the wildcards * and ?, where * matches any sequence of | against the [RFC3986] path-absolute. The pattern can contain | |||
| characters (including the empty string) and ? matches exactly | the wildcards * and ?, where * matches any sequence of | |||
| one character. The three literals $, * and ? should be escaped | [RFC3986] pchar or "/" characters (including the empty string) | |||
| as $$, $* and $?. All other characters are treated as literals. | and ? matches exactly one [RFC3986] pchar character. The three | |||
| literals $, * and ? MUST be escaped as $$, $* and $? (where $ | ||||
| is the designated escape character). All other characters are | ||||
| treated as literals. | ||||
| Type: String | Type: String | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: case-sensitive | Property: case-sensitive | |||
| Description: Flag indicating whether or not case-sensitive | Description: Flag indicating whether or not case-sensitive | |||
| matching should be used. | matching should be used. Note: Case-insensitivity applies to | |||
| ALPHA characters in the URI path prior to percent-decoding | ||||
| [RFC3986]. | ||||
| Type: Boolean | Type: Boolean | |||
| Mandatory-to-Specify: No. Default is case-insensitive match. | Mandatory-to-Specify: No. Default is case-insensitive match. | |||
| Property: ignore-query-string | ||||
| Description: List of query parameters which should be ignored | ||||
| when searching for a pattern match. Matching against query | ||||
| parameters to ignore MUST be case-insensitive. If all query | ||||
| parameters should be ignored then the list MUST be empty. | ||||
| Type: List of String | ||||
| Mandatory-to-Specify: No. Default is to include query strings | ||||
| when matching. | ||||
| Example PatternMatch object that matches the case-sensitive URI path | Example PatternMatch object that matches the case-sensitive URI path | |||
| pattern "/movies/*". All query parameters will be ignored when | pattern "/movies/*". All query parameters will be ignored when | |||
| matching URIs requested from surrogates by content clients against | matching URIs requested from surrogates by content clients against | |||
| this path pattern: | this path pattern: | |||
| { | { | |||
| "pattern": "/movies/*", | "pattern": "/movies/*", | |||
| "case-sensitive": true, | "case-sensitive": true | |||
| "ignore-query-string": [] | ||||
| } | } | |||
| Example PatternMatch object that matches the case-sensitive URI path | Example PatternMatch object that matches the case-sensitive URI path | |||
| pattern "/movies/*". The query parameter "sessionid" will be ignored | pattern "/movies/*". Only the query parameter "sessionid" will be | |||
| when matching URIs requested from surrogates by content clients | evaluated when matching URIs requested from surrogates by content | |||
| against this path pattern: | clients against this path pattern: | |||
| { | { | |||
| "pattern": "/movies/*", | "pattern": "/movies/*", | |||
| "case-sensitive": true, | "case-sensitive": true | |||
| "ignore-query-string": ["sessionid"] | ||||
| } | } | |||
| 4.1.6. PathMetadata | 4.1.6. PathMetadata | |||
| A PathMetadata object contains the CDNI metadata properties for | A PathMetadata object contains the CDNI metadata properties for | |||
| content requests that match against the associated URI path (defined | content requests that match against the associated URI path (defined | |||
| in a PathMatch object). | in a PathMatch object). | |||
| Note that if DNS-based redirection is employed, then a dCDN will be | Note that if DNS-based redirection is employed, then a dCDN will be | |||
| unable to evaulate any metadata at the PathMetadata level or below | unable to evaluate any metadata at the PathMetadata level or below | |||
| because only the hostname of the content request is available at | because only the hostname of the content request is available at | |||
| request routing time. dCDNs SHOULD still process all PathMetadata for | request routing time. dCDNs SHOULD still process all PathMetadata for | |||
| the host before responding to the redirection request to detect if | the host before responding to the redirection request to detect if | |||
| any unsupported metadata is specifed. If any metadata not supported | any unsupported metadata is specified. If any metadata not supported | |||
| by the dCDN is marked as "mandatory-to-enforce", the dCDN SHOULD NOT | by the dCDN is marked as "mandatory-to-enforce", the dCDN SHOULD NOT | |||
| accept the content redirection request, in order to avoid receiving | accept the content redirection request, in order to avoid receiving | |||
| content requests that it will not be able to satisfy/serve. | content requests that it will not be able to satisfy/serve. | |||
| Property: metadata | Property: metadata | |||
| Description: List of path related metadata. | Description: Array of path related metadata. | |||
| Type: Array of GenericMetadata objects | ||||
| Type: List of GenericMetadata objects | ||||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: paths | Property: paths | |||
| Description: Path specific rules. First match applies. | Description: Path specific rules. Path patterns (PathMatch | |||
| objects) MUST be evaluated in the order they appear and the | ||||
| first (and only the first) PathMatch object that matches the | ||||
| content request being processed MUST be used. | ||||
| Type: List of PathMatch objects | Type: Array of PathMatch objects | |||
| Mandatory-to-Specify: No. | Mandatory-to-Specify: No. | |||
| Example PathMetadata object containing a number of embedded | Example PathMetadata object containing a number of embedded | |||
| GenericMetadata objects that describe the metadata to apply for the | GenericMetadata objects that describe the metadata to apply for the | |||
| URI path defined in the parent PathMatch object, as well as a more | URI path defined in the parent PathMatch object, as well as a more | |||
| specific PathMatch object. | specific PathMatch object. | |||
| { | { | |||
| "metadata": [ | "metadata": [ | |||
| skipping to change at page 23, line 40 ¶ | skipping to change at page 23, line 36 ¶ | |||
| acquisition, i.e., how to contact an uCDN Surrogate or an Origin | acquisition, i.e., how to contact an uCDN Surrogate or an Origin | |||
| Server to obtain the content to be served. The sources are not | Server to obtain the content to be served. The sources are not | |||
| necessarily the actual Origin Servers operated by the CSP but might | necessarily the actual Origin Servers operated by the CSP but might | |||
| be a set of Surrogates in the uCDN. | be a set of Surrogates in the uCDN. | |||
| Property: sources | Property: sources | |||
| Description: Sources from which the dCDN can acquire content, | Description: Sources from which the dCDN can acquire content, | |||
| listed in order of preference. | listed in order of preference. | |||
| Type: List of Source objects (see Section 4.2.1.1) | Type: Array of Source objects (see Section 4.2.1.1) | |||
| Mandatory-to-Specify: No. Default is to use static | Mandatory-to-Specify: No. Default is to use static | |||
| configuration, out-of-band from the metadata interface. | configuration, out-of-band from the metadata interface. | |||
| Example SourceMetadata object (which contains two Source objects) | Example SourceMetadata object (which contains two Source objects) | |||
| that describes which servers the dCDN should use for acquiring | that describes which servers the dCDN should use for acquiring | |||
| content for the applicable URI path and/or host: | content for the applicable URI path and/or host: | |||
| { | { | |||
| "generic-metadata-type": "MI.SourceMetadata", | "generic-metadata-type": "MI.SourceMetadata", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| { | { | |||
| "sources": [ | "sources": [ | |||
| { | { | |||
| "endpoints": [ | "endpoints": [ | |||
| "a.service123.ucdn.example", | "a.service123.ucdn.example", | |||
| "b.service123.ucdn.example" | "b.service123.ucdn.example" | |||
| ], | ], | |||
| "protocol": "http1.1" | "protocol": "http/1.1" | |||
| }, | }, | |||
| { | { | |||
| "endpoints": ["origin.service123.example"], | "endpoints": ["origin.service123.example"], | |||
| "protocol": "http1.1" | "protocol": "http/1.1" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| 4.2.1.1. Source | 4.2.1.1. Source | |||
| A Source object describes the source to be used by the dCDN for | A Source object describes the source to be used by the dCDN for | |||
| content acquisition (e.g., a Surrogate within the uCDN or an | content acquisition (e.g., a Surrogate within the uCDN or an | |||
| alternate Origin Server), the protocol to be used, and any | alternate Origin Server), the protocol to be used, and any | |||
| authentication method to be used when contacting that source. | authentication method to be used when contacting that source. | |||
| Endpoints within a Source object MUST be treated as equivalent/equal. | Endpoints within a Source object MUST be treated as equivalent/equal. | |||
| A uCDN can specify a list of sources in preference order within a | A uCDN can specify an array of sources in preference order within a | |||
| SourceMetadata objecct, and then for each preference ranked Source | SourceMetadata object, and then for each preference ranked Source | |||
| object, a uCDN can specify a list of endpoints that are equivalent | object, a uCDN can specify an array of endpoints that are equivalent | |||
| (e.g., a pool of servers that are not behind a load balancer). | (e.g., a pool of servers that are not behind a load balancer). | |||
| Property: acquisition-auth | Property: acquisition-auth | |||
| Description: Authentication method to use when requesting | Description: Authentication method to use when requesting | |||
| content from this source. | content from this source. | |||
| Type: Auth (see Section 4.2.7) | Type: Auth (see Section 4.2.7) | |||
| Mandatory-to-Specify: No. Default is no authentication | Mandatory-to-Specify: No. Default is no authentication | |||
| required. | required. | |||
| Property: endpoints | Property: endpoints | |||
| Description: Origins from which the dCDN can acquire content. | Description: Origins from which the dCDN can acquire content. | |||
| If multiple endpoints are specified they are all equal, i.e., | If multiple endpoints are specified they are all equal, i.e., | |||
| the list is not in preference order (e.g., a pool of servers | the list is not in preference order (e.g., a pool of servers | |||
| behind a load balancer). | behind a load balancer). | |||
| Type: List of Endpoint objects (See Section 4.3.3) | Type: Array of Endpoint objects (See Section 4.3.3) | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: protocol | Property: protocol | |||
| Description: Network retrieval protocol to use when requesting | Description: Network retrieval protocol to use when requesting | |||
| content from this source. | content from this source. | |||
| Type: Protocol (see Section 4.3.2) | Type: Protocol (see Section 4.3.2) | |||
| skipping to change at page 25, line 29 ¶ | skipping to change at page 25, line 29 ¶ | |||
| Example Source object that describes a pair of endpoints (servers) | Example Source object that describes a pair of endpoints (servers) | |||
| the dCDN can use for acquiring content for the applicable host and/or | the dCDN can use for acquiring content for the applicable host and/or | |||
| URI path: | URI path: | |||
| { | { | |||
| "endpoints": [ | "endpoints": [ | |||
| "a.service123.ucdn.example", | "a.service123.ucdn.example", | |||
| "b.service123.ucdn.example" | "b.service123.ucdn.example" | |||
| ], | ], | |||
| "protocol": "http1.1" | "protocol": "http/1.1" | |||
| } | } | |||
| 4.2.2. LocationACL Metadata | 4.2.2. LocationACL Metadata | |||
| LocationACL metadata defines which locations a User Agent needs to be | LocationACL metadata defines which locations a User Agent needs to be | |||
| in, in order to be able to receive the associated content. | in, in order to be able to receive the associated content. | |||
| A LocationACL which does not include a locations property results in | A LocationACL which does not include a locations property results in | |||
| an action of allow all, meaning that delivery can be performed | an action of allow all, meaning that delivery can be performed | |||
| regardless of the User Agent's location, otherwise a CDN MUST take | regardless of the User Agent's location, otherwise a CDN MUST take | |||
| skipping to change at page 26, line 12 ¶ | skipping to change at page 26, line 12 ¶ | |||
| content request which is simultaneously allowed based on the | content request which is simultaneously allowed based on the | |||
| LocationACL and denied based on the TimeWindowACL. The dCDN MUST use | LocationACL and denied based on the TimeWindowACL. The dCDN MUST use | |||
| the logical AND of all ACLs (where 'allow' is true and 'deny' is | the logical AND of all ACLs (where 'allow' is true and 'deny' is | |||
| false) to determine whether or not a request should be allowed. | false) to determine whether or not a request should be allowed. | |||
| Property: locations | Property: locations | |||
| Description: Access control list which allows or denies | Description: Access control list which allows or denies | |||
| (blocks) delivery based on the User Agent's location. | (blocks) delivery based on the User Agent's location. | |||
| Type: List of LocationRule objects (see Section 4.2.2.1) | Type: Array of LocationRule objects (see Section 4.2.2.1) | |||
| Mandatory-to-Specify: No. Default is allow all locations. | Mandatory-to-Specify: No. Default is allow all locations. | |||
| Example LocationACL object that allows the dCDN to deliver content to | Example LocationACL object that allows the dCDN to deliver content to | |||
| any location/IP address: | any location/IP address: | |||
| { | { | |||
| "generic-metadata-type": "MI.LocationACL", | "generic-metadata-type": "MI.LocationACL", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| { | { | |||
| skipping to change at page 27, line 7 ¶ | skipping to change at page 27, line 7 ¶ | |||
| "footprint-value": ["us"] | "footprint-value": ["us"] | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| 4.2.2.1. LocationRule | 4.2.2.1. LocationRule | |||
| A LocationRule contains or references a list of Footprint objects and | A LocationRule contains or references an array of Footprint objects | |||
| the corresponding action. | and the corresponding action. | |||
| Property: footprints | Property: footprints | |||
| Description: List of footprints to which the rule applies. | Description: Array of footprints to which the rule applies. | |||
| Type: List of Footprint objects (see Section 4.2.2.2) | Type: Array of Footprint objects (see Section 4.2.2.2) | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: action | Property: action | |||
| Description: Defines whether the rule specifies locations to | Description: Defines whether the rule specifies locations to | |||
| allow or deny. | allow or deny. | |||
| Type: Enumeration [allow|deny] encoded as a lowercase string | Type: Enumeration [allow|deny] encoded as a lowercase string | |||
| skipping to change at page 27, line 39 ¶ | skipping to change at page 27, line 39 ¶ | |||
| { | { | |||
| "action": "allow", | "action": "allow", | |||
| "footprints": [ | "footprints": [ | |||
| { | { | |||
| "footprint-type": "countrycode", | "footprint-type": "countrycode", | |||
| "footprint-value": ["us"] | "footprint-value": ["us"] | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | ||||
| 4.2.2.2. Footprint | 4.2.2.2. Footprint | |||
| A Footprint object describes the footprint to which a LocationRule | A Footprint object describes the footprint to which a LocationRule | |||
| can be applied to, e.g., an IPv4 address range or a geographic | can be applied to, e.g., an IPv4 address range or a geographic | |||
| location. | location. | |||
| Property: footprint-type | Property: footprint-type | |||
| Description: Registered footprint type (see Section 7.2). The | Description: Registered footprint type (see Section 7.2). The | |||
| skipping to change at page 28, line 13 ¶ | skipping to change at page 28, line 13 ¶ | |||
| Section 4.3.6), "asn" (Autonomous System Number, see | Section 4.3.6), "asn" (Autonomous System Number, see | |||
| Section 4.3.7) and "countrycode" (Country Code, see | Section 4.3.7) and "countrycode" (Country Code, see | |||
| Section 4.3.8). | Section 4.3.8). | |||
| Type: Lowercase String | Type: Lowercase String | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: footprint-value | Property: footprint-value | |||
| Description: List of footprint values conforming to the | Description: Array of footprint values conforming to the | |||
| specification associated with the registered footprint type. | specification associated with the registered footprint type. | |||
| Footprint values can be simple strings (e.g., IPv4CIDR, | Footprint values can be simple strings (e.g., IPv4CIDR, | |||
| IPv6CIDR, ASN, and CountryCode), however, other Footprint | IPv6CIDR, ASN, and CountryCode), however, other Footprint | |||
| objects can be defined in the future, along with a more complex | objects can be defined in the future, along with a more complex | |||
| encoding (e.g., GPS coordinate tuples). | encoding (e.g., GPS coordinate tuples). | |||
| Type: List of footprints | Type: Array of footprints | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Example Footprint object describing a footprint covering the USA: | Example Footprint object describing a footprint covering the USA: | |||
| { | { | |||
| "footprint-type": "countrycode", | "footprint-type": "countrycode", | |||
| "footprint-value": ["us"] | "footprint-value": ["us"] | |||
| } | } | |||
| Example Footprint object describing a footprint covering the IP | Example Footprint object describing a footprint covering the IP | |||
| address ranges 192.0.2.0/24 and 198.51.100.0/24: | address ranges 192.0.2.0/24 and 198.51.100.0/24: | |||
| { | { | |||
| "footprint-type": "ipv4cidr", | "footprint-type": "ipv4cidr", | |||
| "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] | "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] | |||
| } | } | |||
| Example Footprint object describing a footprint covering the IP | ||||
| address ranges 2001:db8::/32: | ||||
| { | ||||
| "footprint-type": "ipv6cidr", | ||||
| "footprint-value": ["2001:db8::/32"] | ||||
| } | ||||
| Example Footprint object describing a footprint covering the | ||||
| autonomous system 64496: | ||||
| { | ||||
| "footprint-type": "asn", | ||||
| "footprint-value": ["as64496"] | ||||
| } | ||||
| 4.2.3. TimeWindowACL | 4.2.3. TimeWindowACL | |||
| TimeWindowACL metadata defines time-based restrictions. | TimeWindowACL metadata defines time-based restrictions. | |||
| A TimeWindowACL which does not include a times property results in an | A TimeWindowACL which does not include a times property results in an | |||
| action of allow all, meaning that delivery can be performed | action of allow all, meaning that delivery can be performed | |||
| regardless of the time of the User Agent's request, otherwise a CDN | regardless of the time of the User Agent's request, otherwise a CDN | |||
| MUST take the action from the first window to match against the | MUST take the action from the first window to match against the | |||
| current time. If two or more windows overlap, the first window that | current time. If two or more windows overlap, the first window that | |||
| matches against the current time determines the action a CDN MUST | matches against the current time determines the action a CDN MUST | |||
| skipping to change at page 29, line 18 ¶ | skipping to change at page 29, line 37 ¶ | |||
| content request which is simultaneously allowed based on the | content request which is simultaneously allowed based on the | |||
| LocationACL and denied based on the TimeWindowACL. The dCDN MUST use | LocationACL and denied based on the TimeWindowACL. The dCDN MUST use | |||
| the logical AND of all ACLs (where 'allow' is true and 'deny' is | the logical AND of all ACLs (where 'allow' is true and 'deny' is | |||
| false) to determine whether or not a request should be allowed. | false) to determine whether or not a request should be allowed. | |||
| Property: times | Property: times | |||
| Description: Access control list which allows or denies | Description: Access control list which allows or denies | |||
| (blocks) delivery based on the time of a User Agent's request. | (blocks) delivery based on the time of a User Agent's request. | |||
| Type: List of TimeWindowRule objects (see Section 4.2.3.1) | Type: Array of TimeWindowRule objects (see Section 4.2.3.1) | |||
| Mandatory-to-Specify: No. Default is allow all time windows. | Mandatory-to-Specify: No. Default is allow all time windows. | |||
| Example TimeWIndowACL object (which contains a TimeWindowRule object | Example TimeWIndowACL object (which contains a TimeWindowRule object | |||
| which itself contains a TimeWIndow object) that only allows the dCDN | which itself contains a TimeWIndow object) that only allows the dCDN | |||
| to deliver content to clients between 09:00 01/01/2000 UTC and 17:00 | to deliver content to clients between 09:00 01/01/2000 UTC and 17:00 | |||
| 01/01/2000 UTC: | 01/01/2000 UTC: | |||
| { | { | |||
| "generic-metadata-type": "MI.TimeWindowACL", | "generic-metadata-type": "MI.TimeWindowACL", | |||
| skipping to change at page 29, line 47 ¶ | skipping to change at page 30, line 25 ¶ | |||
| "end": 946746000 | "end": 946746000 | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| 4.2.3.1. TimeWindowRule | 4.2.3.1. TimeWindowRule | |||
| A TimeWindowRule contains or references a list of TimeWindow objects | A TimeWindowRule contains or references an array of TimeWindow | |||
| and the corresponding action. | objects and the corresponding action. | |||
| Property: windows | Property: windows | |||
| Description: List of time windows to which the rule applies. | Description: Array of time windows to which the rule applies. | |||
| Type: List of TimeWindow objects (see Section 4.2.3.2) | Type: Array of TimeWindow objects (see Section 4.2.3.2) | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: action | Property: action | |||
| Description: Defines whether the rule specifies time windows to | Description: Defines whether the rule specifies time windows to | |||
| allow or deny. | allow or deny. | |||
| Type: Enumeration [allow|deny] encoded as a lowercase string | Type: Enumeration [allow|deny] encoded as a lowercase string | |||
| skipping to change at page 31, line 40 ¶ | skipping to change at page 32, line 23 ¶ | |||
| simultaneously allowed based on the ProtocolACL and denied based on | simultaneously allowed based on the ProtocolACL and denied based on | |||
| the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs | the TimeWindowACL. The dCDN MUST use the logical AND of all ACLs | |||
| (where 'allow' is true and 'deny' is false) to determine whether or | (where 'allow' is true and 'deny' is false) to determine whether or | |||
| not a request should be allowed. | not a request should be allowed. | |||
| Property: protocol-acl | Property: protocol-acl | |||
| Description: Description: Access control list which allows or | Description: Description: Access control list which allows or | |||
| denies (blocks) delivery based on delivery protocol. | denies (blocks) delivery based on delivery protocol. | |||
| Type: List of ProtocolRule objects (see Section 4.2.4.1) | Type: Array of ProtocolRule objects (see Section 4.2.4.1) | |||
| Mandatory-to-Specify: No. Default is allow all protocols. | Mandatory-to-Specify: No. Default is allow all protocols. | |||
| Example ProtocolACL object (which contains a ProtocolRule object) | Example ProtocolACL object (which contains a ProtocolRule object) | |||
| that only allows the dCDN to deliver content using HTTP/1.1: | that only allows the dCDN to deliver content using HTTP/1.1: | |||
| { | { | |||
| "generic-metadata-type": "MI.ProtocolACL", | "generic-metadata-type": "MI.ProtocolACL", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| { | { | |||
| "protocol-acl": [ | "protocol-acl": [ | |||
| { | { | |||
| "action": "allow", | "action": "allow", | |||
| "protocols": ["http1.1"] | "protocols": ["http/1.1"] | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| 4.2.4.1. ProtocolRule | 4.2.4.1. ProtocolRule | |||
| A ProtocolRule contains or references a list of Protocol objects and | A ProtocolRule contains or references an array of Protocol objects | |||
| the corresponding action. | and the corresponding action. | |||
| Property: protocols | Property: protocols | |||
| Description: List of protocols to which the rule applies. | Description: Array of protocols to which the rule applies. | |||
| Type: List of Protocols (see Section 4.3.2) | Type: Array of Protocols (see Section 4.3.2) | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: action | Property: action | |||
| Description: Defines whether the rule specifies protocols to | Description: Defines whether the rule specifies protocols to | |||
| allow or deny. | allow or deny. | |||
| Type: Enumeration [allow|deny] encoded as a lowercase string | Type: Enumeration [allow|deny] encoded as a lowercase string | |||
| Mandatory-to-Specify: No. Default is deny. | Mandatory-to-Specify: No. Default is deny. | |||
| Example ProtocolRule object (which contains a ProtocolRule object) | Example ProtocolRule object (which contains a ProtocolRule object) | |||
| that allows the dCDN to deliver content using HTTP/1.1: | that allows the dCDN to deliver content using HTTP/1.1: | |||
| { | { | |||
| "action": "allow", | "action": "allow", | |||
| "protocols": ["http1.1"] | "protocols": ["http/1.1"] | |||
| } | } | |||
| 4.2.5. DeliveryAuthorization Metadata | 4.2.5. DeliveryAuthorization Metadata | |||
| Delivery Authorization defines authorization methods for the delivery | Delivery Authorization defines authorization methods for the delivery | |||
| of content to User Agents. | of content to User Agents. | |||
| Property: delivery-auth-methods | Property: delivery-auth-methods | |||
| Description: Options for authorizing content requests. | Description: Options for authorizing content requests. | |||
| Delivery for a content request is authorized if any of the | Delivery for a content request is authorized if any of the | |||
| authorization methods in the list is satisfied for that | authorization methods in the list is satisfied for that | |||
| request. | request. | |||
| Type: List of Auth objects (see Section 4.2.7) | Type: Array of Auth objects (see Section 4.2.7) | |||
| Mandatory-to-Specify: No. Default is no authorization | Mandatory-to-Specify: No. Default is no authorization | |||
| required. | required. | |||
| Example DeliveryAuthorization object (which contains an Auth object): | Example DeliveryAuthorization object (which contains an Auth object): | |||
| { | { | |||
| "generic-metadata-type": "MI.DeliveryAuthorization", | "generic-metadata-type": "MI.DeliveryAuthorization", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| { | { | |||
| skipping to change at page 33, line 40 ¶ | skipping to change at page 34, line 26 ¶ | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| 4.2.6. Cache | 4.2.6. Cache | |||
| A Cache object describes the cache control parameters to be applied | A Cache object describes the cache control parameters to be applied | |||
| to the content by intermediate caches. | to the content by intermediate caches. | |||
| Property: ignore-query-string | Cache keys are generated from the URI of the content request | |||
| [RFC7234]. In some cases, a CDN or content provider might want | ||||
| certain path segments or query parameters to be excluded from the | ||||
| cache key generation. The Cache object provides guidance on what | ||||
| parts of the path and query string to include. | ||||
| Description: Allows a Surrogate to ignore URI query string | Property: exclude-path-pattern | |||
| parameters when comparing the requested URI against the URIs in | ||||
| its cache for equivalence. Matching query parameters to ignore | ||||
| MUST be case-insensitive. Each query parameter to ignore is | ||||
| specified in the list. If all query parameters should be | ||||
| ignored, then the list MUST be specified and MUST be empty. | ||||
| Type: List of String | Description: A pattern for matching against the URI path, i.e., | |||
| against the [RFC3986] path-absolute. The pattern can contain | ||||
| the wildcards * and ?, where * matches any sequence of | ||||
| [RFC3986] pchar or "/" characters (including the empty string) | ||||
| and ? matches exactly one [RFC3986] pchar character. The three | ||||
| literals $, * and ? MUST be escaped as $$, $* and $? (where $ | ||||
| is the designated escape character). All other characters are | ||||
| treated as literals. Cache key generation MUST only include | ||||
| the portion of the path-absolute that matches the wildcard | ||||
| portions of the pattern. Note: Inconsistency between the | ||||
| PatternMatch pattern Section 4.1.5 and the exclude-path-pattern | ||||
| can result in inefficient caching. | ||||
| Mandatory-to-Specify: No. Default is to consider query string | Type: String | |||
| parameters when comparing URIs. | ||||
| Example Cache object that instructs the dCDN to ignore all query | Mandatory-to-Specify: No. Default is to use the full URI path- | |||
| parameters: | absolute to generate the cache key. | |||
| Property: include-query-strings | ||||
| Description: Allows a Surrogate to specify the URI query string | ||||
| parameters [RFC3986] to include when comparing the requested | ||||
| URI against the URIs in its cache for equivalence. Matching | ||||
| query parameters MUST be case-insensitive. If all query | ||||
| parameters should be ignored, then the list MUST be specified | ||||
| and MUST be empty. If a query parameter appears multiple times | ||||
| in the query string, each instance value MUST be aggregated | ||||
| prior to comparison. For consistent cache key generation, | ||||
| query parameters SHOULD be evaluated in the order specified in | ||||
| this array. | ||||
| Type: Array of String | ||||
| Mandatory-to-Specify: No. Default is to consider all query | ||||
| string parameters when comparing URIs. | ||||
| Example Cache object that instructs the dCDN to use the full URI path | ||||
| and ignore all query parameters: | ||||
| { | { | |||
| "generic-metadata-type": "MI.Cache", | "generic-metadata-type": "MI.Cache", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| { | { | |||
| "ignore-query-string": [] | "include-query-strings": [] | |||
| } | } | |||
| } | } | |||
| Example Cache object that instructs the dCDN to ignore the (case- | Example Cache object that instructs the dCDN to exclude the "CDNX" | |||
| insensitive) query parameters named "sessionid" and "random": | path prefix and only include the (case-insensitive) query parameters | |||
| named "mediaid" and "providerid": | ||||
| { | { | |||
| "generic-metadata-type": "MI.Cache", | "generic-metadata-type": "MI.Cache", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| { | { | |||
| "ignore-query-string": ["sessionid", "random"] | "exclude-path-pattern": "/CDNX/*", | |||
| "include-query-strings": ["mediaid", "providerid"] | ||||
| } | ||||
| } | ||||
| Example Cache object that instructs the dCDN to exclude the "CDNX" | ||||
| path prefix, but includes all query parameters: | ||||
| { | ||||
| "generic-metadata-type": "MI.Cache", | ||||
| "generic-metadata-value": | ||||
| { | ||||
| "exclude-path-pattern": "/CDNX/*" | ||||
| } | } | |||
| } | } | |||
| 4.2.7. Auth | 4.2.7. Auth | |||
| An Auth object defines authentication and authorization methods to be | An Auth object defines authentication and authorization methods to be | |||
| used during content acquisition and content delivery, respectively. | used during content acquisition and content delivery, respectively. | |||
| Note: This document does not define any Auth methods. Individual | ||||
| Auth methods are being defined separately (e.g., URI Signing | ||||
| [I-D.ietf-cdni-uri-signing]). The GenericMetadata which contain Auth | ||||
| objects is defined herein for convenience and so as not to be | ||||
| specific to any particular Auth method. | ||||
| Property: auth-type | Property: auth-type | |||
| Description: Registered Auth type (Section 7.4). | Description: Auth type (The CDNI Payload Type [RFC7736] of the | |||
| GenericMetadata object contained in the auth-value property). | ||||
| Type: String | Type: String | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: auth-value | Property: auth-value | |||
| Description: An object conforming to the specification | Description: An object conforming to the specification | |||
| associated with the Registered Auth type. | associated with the Auth type. | |||
| Type: GenericMetadata Object | Type: GenericMetadata Object | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Example Auth object: | Example Auth object: | |||
| { | { | |||
| "generic-metadata-type": "MI.Auth", | "generic-metadata-type": "MI.Auth", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| skipping to change at page 35, line 33 ¶ | skipping to change at page 37, line 33 ¶ | |||
| Description: Content Collection identifier for an application- | Description: Content Collection identifier for an application- | |||
| specific purpose such as logging aggregation. | specific purpose such as logging aggregation. | |||
| Type: String | Type: String | |||
| Mandatory-to-Specify: No. Default is an empty string. | Mandatory-to-Specify: No. Default is an empty string. | |||
| Example Grouping object that specifies a Content Collection | Example Grouping object that specifies a Content Collection | |||
| Identifier for the content associated with the Grouping object's | Identifier for the content associated with the Grouping object's | |||
| parent HostMetdata and PathMetadata: | parent HostMetadata and PathMetadata: | |||
| { | { | |||
| "generic-metadata-type": "MI.Grouping", | "generic-metadata-type": "MI.Grouping", | |||
| "generic-metadata-value": | "generic-metadata-value": | |||
| { | { | |||
| "ccid": "ABCD" | "ccid": "ABCD" | |||
| } | } | |||
| } | } | |||
| 4.3. CDNI Metadata Simple Data Type Descriptions | 4.3. CDNI Metadata Simple Data Type Descriptions | |||
| skipping to change at page 36, line 25 ¶ | skipping to change at page 38, line 25 ¶ | |||
| Description: The URI of the addressable object being | Description: The URI of the addressable object being | |||
| referenced. | referenced. | |||
| Type: String | Type: String | |||
| Mandatory-to-Specify: Yes. | Mandatory-to-Specify: Yes. | |||
| Property: type | Property: type | |||
| Description: The type of the object being referenced. | Description: The CDNI Payload type of the object being | |||
| referenced. | ||||
| Type: String | Type: String | |||
| Mandatory-to-Specify: No. If the container specifies the type | Mandatory-to-Specify: No. If the container specifies the type | |||
| (e.g., the HostIndex object contains a list of HostMatch | (e.g., the HostIndex object contains an array of HostMatch | |||
| objects, so a Link object in the list of HostMatch objects must | objects, so a Link object in the list of HostMatch objects must | |||
| reference a HostMatch), then it is not necessary to explicitly | reference a HostMatch), then it is not necessary to explicitly | |||
| specify a type. | specify a type. | |||
| Example Link object referencing a HostMatch object: | Example Link object referencing a HostMatch object: | |||
| { | { | |||
| "type": "MI.HostMatch", | "type": "MI.HostMatch", | |||
| "href": "http://metadata.ucdn.example/hostmatch1234" | "href": "https://metadata.ucdn.example/hostmatch1234" | |||
| } | } | |||
| Example Link object referencing a HostMatch object, without an | Example Link object referencing a HostMatch object, without an | |||
| explicit type, inside a HostIndex object: | explicit type, inside a HostIndex object: | |||
| { | { | |||
| "hosts": [ | "hosts": [ | |||
| { | { | |||
| <Properties of embedded HostMatch object> | <Properties of embedded HostMatch object> | |||
| }, | }, | |||
| { | { | |||
| "href": "http://metadata.ucdn.example/hostmatch1234" | "href": "https://metadata.ucdn.example/hostmatch1234" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| 4.3.1.1. Link Loop Prevention | ||||
| When following a Link, CDNI metadata clients SHOULD verify that the | ||||
| CDNI Payload Type of the object retrieved matches the expected CDNI | ||||
| Payload Type, as indicated by the link object. For GenericMetadata | ||||
| objects, type checks will prevent self references; however, incorrect | ||||
| linking can result in circular references for structural metadtata | ||||
| objects, specifically, PathMatch and PathMetadata objects Figure 1. | ||||
| To prevent the circular references, CDNI metadata clients SHOULD | ||||
| verify that no duplicate Links occur for PathMatch or PathMetadata | ||||
| objects. | ||||
| 4.3.2. Protocol | 4.3.2. Protocol | |||
| Protocol objects are used to specify registered protocols for content | Protocol objects are used to specify registered protocols for content | |||
| acquisition or delivery (see Section 7.3). | acquisition or delivery (see Section 7.3). | |||
| Type: String | Type: String | |||
| Example: | Example: | |||
| "http1.1" | "http/1.1" | |||
| 4.3.3. Endpoint | 4.3.3. Endpoint | |||
| A Hostname (with optional port) or an IP address (with optional | A Hostname (with optional port) or an IP address (with optional | |||
| port). | port). | |||
| Note: All implementations MUST support IPv4 addresses encoded as | All implementations MUST support IPv4 addresses encoded as specified | |||
| specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. | by the 'IPv4address' rule in Section 3.2.2 of [RFC3986]. IPv6 | |||
| IPv6 addresses MUST be encoded in one of the IPv6 address formats | addresses MUST be encoded in one of the IPv6 address formats | |||
| specified in [RFC5952] although receivers MUST support all IPv6 | specified in [RFC5952] although receivers MUST support all IPv6 | |||
| address formats specified in [RFC4291]. | address formats specified in [RFC4291]. Hostnames MUST conform to | |||
| the Domain Name System (DNS) syntax defined in [RFC1034] and | ||||
| [RFC1123]. Internationalized Domain Names (IDN) must first be | ||||
| transformed to the A-label form [RFC5890] as per [RFC5891]. | ||||
| Type: String | Type: String | |||
| Example Hostname: | Example Hostname: | |||
| "metadata.ucdn.example" | "metadata.ucdn.example" | |||
| Example IPv4 address: | Example IPv4 address: | |||
| "192.0.2.1" | "192.0.2.1" | |||
| Example IPv6 address (with port number): | Example IPv6 address (with port number): | |||
| "[2001:db8::1]:81" | "[2001:db8::1]:81" | |||
| 4.3.4. Time | 4.3.4. Time | |||
| A time value expressed in seconds since the Unix epoch in the UTC | A time value expressed in seconds since the Unix epoch (i.e., zero | |||
| timezone. | hours, zero minutes, zero seconds, on January 1, 1970) Coordinated | |||
| Universal Time (UTC) [POSIX]. | ||||
| Type: Integer | Type: Integer | |||
| Example Time representing 09:00 01/01/2000 UTC: | Example Time representing 09:00:00 01/01/2000 UTC: | |||
| 946717200 | 946717200 | |||
| 4.3.5. IPv4CIDR | 4.3.5. IPv4CIDR | |||
| An IPv4address CIDR block encoded as specified by the 'IPv4address' | An IPv4address CIDR block encoded as specified by the 'IPv4address' | |||
| rule in Section 3.2.2 of [RFC3986] followed by a / followed by an | rule in Section 3.2.2 of [RFC3986] followed by a / followed by an | |||
| unsigned integer representing the leading bits of the routing prefix | unsigned integer representing the leading bits of the routing prefix | |||
| (i.e., IPv4 CIDR notation). Single IP addresses can be expressed as | (i.e., IPv4 CIDR notation). Single IP addresses can be expressed as | |||
| /32. | /32. | |||
| skipping to change at page 38, line 38 ¶ | skipping to change at page 41, line 4 ¶ | |||
| "192.0.2.0/24" | "192.0.2.0/24" | |||
| 4.3.6. IPv6CIDR | 4.3.6. IPv6CIDR | |||
| An IPv6address CIDR block encoded in one of the IPv6 address formats | An IPv6address CIDR block encoded in one of the IPv6 address formats | |||
| specified in [RFC5952] followed by a / followed by an unsigned | specified in [RFC5952] followed by a / followed by an unsigned | |||
| integer representing the leading bits of the routing prefix (i.e., | integer representing the leading bits of the routing prefix (i.e., | |||
| IPv6 CIDR notation). Single IP addresses can be expressed as /128. | IPv6 CIDR notation). Single IP addresses can be expressed as /128. | |||
| Type: String | Type: String | |||
| Example IPv6 CIDR: | Example IPv6 CIDR: | |||
| "2001:db8::/32" | "2001:db8::/32" | |||
| 4.3.7. ASN | 4.3.7. ASN | |||
| An Autonomous System Number encoded as a string consisting of the | An Autonomous System Number encoded as a string consisting of the | |||
| characters "as" (in lowercase) followed by the Autonomous System | characters "as" (in lowercase) followed by the Autonomous System | |||
| number. | number [RFC6793]. | |||
| Type: String | Type: String | |||
| Example ASN: | Example ASN: | |||
| "as64496" | "as64496" | |||
| 4.3.8. CountryCode | 4.3.8. CountryCode | |||
| An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. | An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. | |||
| skipping to change at page 40, line 19 ¶ | skipping to change at page 42, line 33 ¶ | |||
| The CDNI metadata interface is built on the principles of HTTP web | The CDNI metadata interface is built on the principles of HTTP web | |||
| services. In particular, this means that requests and responses over | services. In particular, this means that requests and responses over | |||
| the interface are built around the transfer of representations of | the interface are built around the transfer of representations of | |||
| hyperlinked resources. A resource in the context of the CDNI | hyperlinked resources. A resource in the context of the CDNI | |||
| metadata interface is any object in the object model (as described in | metadata interface is any object in the object model (as described in | |||
| Section 3 and Section 4). | Section 3 and Section 4). | |||
| To retrieve CDNI metadata, a CDNI metadata client (i.e., a client in | To retrieve CDNI metadata, a CDNI metadata client (i.e., a client in | |||
| the dCDN) first makes a HTTP GET request for the URI of the HostIndex | the dCDN) first makes a HTTP GET request for the URI of the HostIndex | |||
| which provides the CDNI metadata client with a list of Hostnames for | which provides the CDNI metadata client with an array of Hostnames | |||
| which the uCDN can delegate content delivery to the dCDN. The CDNI | for which the uCDN can delegate content delivery to the dCDN. The | |||
| metadata client can then obtain any other CDNI metadata objects by | CDNI metadata client can then obtain any other CDNI metadata objects | |||
| making a HTTP GET requests for any linked metadata objects it | by making a HTTP GET requests for any linked metadata objects it | |||
| requires. | requires. | |||
| CDNI metadata servers (i.e., servers in the uCDN) are free to assign | CDNI metadata servers (i.e., servers in the uCDN) are free to assign | |||
| whatever structure they desire to the URIs for CDNI metadata objects | whatever structure they desire to the URIs for CDNI metadata objects | |||
| and CDNI metadata clients MUST NOT make any assumptions regarding the | and CDNI metadata clients MUST NOT make any assumptions regarding the | |||
| structure of CDNI metadata URIs or the mapping between CDNI metadata | structure of CDNI metadata URIs or the mapping between CDNI metadata | |||
| objects and their associated URIs. Therefore any URIs present in the | objects and their associated URIs. Therefore any URIs present in the | |||
| examples in this document are purely illustrative and are not | examples in this document are purely illustrative and are not | |||
| intended to impose a definitive structure on CDNI metadata interface | intended to impose a definitive structure on CDNI metadata interface | |||
| implementations. | implementations. | |||
| 6.1. Transport | 6.1. Transport | |||
| The CDNI metadata interface uses HTTP as the underlying protocol | The CDNI metadata interface uses HTTP as the underlying protocol | |||
| transport. | transport [RFC7230]. | |||
| The HTTP Method in the request defines the operation the request | The HTTP Method in the request defines the operation the request | |||
| would like to perform. A server implementation of the CDNI metadata | would like to perform. A server implementation of the CDNI metadata | |||
| interface MUST support the HTTP GET and HEAD methods. | interface MUST support the HTTP GET and HEAD methods. | |||
| The corresponding HTTP Response returns the status of the operation | The corresponding HTTP Response returns the status of the operation | |||
| in the HTTP Status Code and returns the current representation of the | in the HTTP Status Code and returns the current representation of the | |||
| resource (if appropriate) in the Response Body. HTTP Responses that | resource (if appropriate) in the Response Body. HTTP Responses that | |||
| contain a response body SHOULD include an ETag to enable validation | contain a response body SHOULD include an ETag to enable validation | |||
| of cached versions of returned resources. | of cached versions of returned resources. | |||
| The CDNI metadata interface specified in this document is a read-only | ||||
| interface. Therefore support for other HTTP methods such as PUT, | ||||
| POST, DELETE, etc. is not specified. A server implementation of the | ||||
| CDNI metadata interface SHOULD reject all methods other than GET and | ||||
| HEAD. | ||||
| As the CDNI metadata interface builds on top of HTTP, CDNI metadata | As the CDNI metadata interface builds on top of HTTP, CDNI metadata | |||
| server implementations MAY make use of any HTTP feature when | server implementations MAY make use of any HTTP feature when | |||
| implementing the CDNI metadata interface, for example, a CDNI | implementing the CDNI metadata interface, for example, a CDNI | |||
| metadata server MAY make use of HTTP's caching mechanisms to indicate | metadata server MAY make use of HTTP's caching mechanisms to indicate | |||
| that the returned response/representation can be reused without re- | that the returned response/representation can be reused without re- | |||
| contacting the CDNI metadata server. | contacting the CDNI metadata server. | |||
| 6.2. Retrieval of CDNI Metadata resources | 6.2. Retrieval of CDNI Metadata resources | |||
| In the general case, a CDNI metadata server makes CDNI metadata | In the general case, a CDNI metadata server makes CDNI metadata | |||
| objects available via a unique URIs and thus, in order to retrieve | objects available via a unique URIs and thus, in order to retrieve | |||
| CDNI metadata, a CDNI metadata client first makes a HTTP GET request | CDNI metadata, a CDNI metadata client first makes a HTTP GET request | |||
| for the URI of the HostIndex which provides a list of Hostnames for | for the URI of the HostIndex which provides an array of Hostnames for | |||
| which the uCDN can delegate content delivery to the dCDN. | which the uCDN can delegate content delivery to the dCDN. | |||
| In order to retrieve the CDNI metadata for a particular request the | In order to retrieve the CDNI metadata for a particular request the | |||
| CDNI metadata client processes the received HostIndex object and | CDNI metadata client processes the received HostIndex object and | |||
| finds the corresponding HostMetadata entry (by matching the hostname | finds the corresponding HostMetadata entry (by matching the hostname | |||
| in the request against the hostnames listed in the HostMatch | in the request against the hostnames listed in the HostMatch | |||
| objects). If the HostMetadata is linked (rather than embedded), the | objects). If the HostMetadata is linked (rather than embedded), the | |||
| CDNI metadata client then makes a GET request for the URI specified | CDNI metadata client then makes a GET request for the URI specified | |||
| in the href property of the Link object which points to the | in the href property of the Link object which points to the | |||
| HostMetadata object itself. | HostMetadata object itself. | |||
| skipping to change at page 41, line 47 ¶ | skipping to change at page 44, line 6 ¶ | |||
| metadata client makes another GET request for the PathMetadata. Each | metadata client makes another GET request for the PathMetadata. Each | |||
| PathMetadata object can also include references to yet more specific | PathMetadata object can also include references to yet more specific | |||
| metadata. If this is the case, the CDNI metadata client continues | metadata. If this is the case, the CDNI metadata client continues | |||
| requesting PathMatch and PathMetadata objects recursively. The CDNI | requesting PathMatch and PathMetadata objects recursively. The CDNI | |||
| metadata client repeats this approach of processing metadata objects | metadata client repeats this approach of processing metadata objects | |||
| and retrieving (via HTTP GETs) any linked objects until it has all | and retrieving (via HTTP GETs) any linked objects until it has all | |||
| the metadata objects it requires in order to process the redirection | the metadata objects it requires in order to process the redirection | |||
| request from an uCDN or the content request from a User Agent. | request from an uCDN or the content request from a User Agent. | |||
| In cases where a dCDN is not able to retrieve the entire set of CDNI | In cases where a dCDN is not able to retrieve the entire set of CDNI | |||
| metadata associated with a User Agent request, for example because | metadata associated with a User Agent request, or it has retrieved | |||
| the uCDN is unreachable or returns a HTTP 4xx or 5xx status in | that metadata but it is stale according to standard HTTP caching | |||
| response to some or all of the dCDN's CDNI metadata requests, the | rules and cannot be revalidated, for example because the uCDN is | |||
| dCDN MUST NOT serve the requested content unless the dCDN has stale | unreachable or returns a HTTP 4xx or 5xx status in response to some | |||
| versions of all the required metadata and the stale-if-error Cache- | or all of the dCDN's CDNI metadata requests, the dCDN MUST NOT serve | |||
| Control extension [RFC5861] was included in all previous responses | the requested content. | |||
| that are required but cannot currently be retrieved. The dCDN can | ||||
| continue to serve other content for which it can retrieve (or for | ||||
| which it has fresh responses cached) all the required metadata even | ||||
| if some non-applicable part of the metadata tree is missing. | ||||
| Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to | Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to | |||
| determine which uCDN's CDNI metadata should be used to handle a | determine which uCDN's CDNI metadata should be used to handle a | |||
| particular User Agent request. | particular User Agent request. | |||
| When application level redirection (e.g., HTTP 302 redirects) is | When application level redirection (e.g., HTTP 302 redirects) is | |||
| being used between CDNs, it is expected that the dCDN will be able to | being used between CDNs, it is expected that the dCDN will be able to | |||
| determine the uCDN that redirected a particular request from | determine the uCDN that redirected a particular request from | |||
| information contained in the received request (e.g., via the URI). | information contained in the received request (e.g., via the URI). | |||
| With knowledge of which uCDN routed the request, the dCDN can choose | With knowledge of which uCDN routed the request, the dCDN can choose | |||
| skipping to change at page 42, line 31 ¶ | skipping to change at page 44, line 34 ¶ | |||
| In the case of DNS redirection there is not always sufficient | In the case of DNS redirection there is not always sufficient | |||
| information carried in the DNS request from User Agents to determine | information carried in the DNS request from User Agents to determine | |||
| the uCDN that redirected a particular request (e.g., when content | the uCDN that redirected a particular request (e.g., when content | |||
| from a given host is redirected to a given dCDN by more than one | from a given host is redirected to a given dCDN by more than one | |||
| uCDN) and therefore dCDNs will have to apply local policy when | uCDN) and therefore dCDNs will have to apply local policy when | |||
| deciding which uCDN's metadata to apply. | deciding which uCDN's metadata to apply. | |||
| 6.3. Bootstrapping | 6.3. Bootstrapping | |||
| The URI for the HostIndex object of a given uCDN needs to be either | The URI for the HostIndex object of a given uCDN needs to be | |||
| configured in, or discovered by, the dCDN. All other objects/ | configured in the dCDN. All other objects/resources are then | |||
| resources are then discoverable from the HostIndex object by | discoverable from the HostIndex object by following any links in the | |||
| following any links in the HostIndex object and through the | HostIndex object and through the referenced HostMetadata and | |||
| referenced HostMetadata and PathMetadata objects and their | PathMetadata objects and their GenericMetadata sub-objects. | |||
| GenericMetadata sub-objects. | ||||
| If the URI for the HostIndex object is not manually configured in the | Manual configuration of the URI for the HostIndex object is outside | |||
| dCDN then the HostIndex URI could be discovered. A mechanism | the scope of this document. | |||
| allowing the dCDN to discover the URI of the HostIndex is outside the | ||||
| scope of this document. | ||||
| 6.4. Encoding | 6.4. Encoding | |||
| CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] | CDNI metadata objects MUST be encoded as I-JSON objects [RFC7493] | |||
| containing a dictionary of (key,value) pairs where the keys are the | containing a dictionary of (key,value) pairs where the keys are the | |||
| property names and the values are the associated property values. | property names and the values are the associated property values. | |||
| The keys of the dictionary are the names of the properties associated | The keys of the dictionary are the names of the properties associated | |||
| with the object and are therefore dependent on the specific object | with the object and are therefore dependent on the specific object | |||
| being encoded (i.e., dependent on the CDNI Payload Type of the | being encoded (i.e., dependent on the CDNI Payload Type of the | |||
| returned resource). Likewise, the values associated with each | returned resource). Likewise, the values associated with each | |||
| property (dictionary key) are dependent on the specific object being | property (dictionary key) are dependent on the specific object being | |||
| encoded (i.e., dependent on the CDNI Payload Type of the returned | encoded (i.e., dependent on the CDNI Payload Type of the returned | |||
| resource). | resource). | |||
| Dictionary keys (properties) in I-JSON are case sensitive. By | Dictionary keys (properties) in I-JSON are case sensitive. By | |||
| convention any dictionary key (property) defined by this document | convention, any dictionary key (property) defined by this document | |||
| (for example the names of CDNI metadata object properties) MUST be | (for example, the names of CDNI metadata object properties) MUST be | |||
| lowercase. | lowercase. | |||
| 6.5. Extensibility | 6.5. Extensibility | |||
| The set of GenericMetadata objects can be extended with additional | The set of GenericMetadata objects can be extended with additional | |||
| (standards based or vendor specific) metadata objects through the | (standards based or vendor specific) metadata objects through the | |||
| specification of new GenericMetadata objects. The GenericMetadata | specification of new GenericMetadata objects. The GenericMetadata | |||
| object defined in Section 4.1.7 specifies a type field and a type- | object defined in Section 4.1.7 specifies a type field and a type- | |||
| specific value field that allows any metadata to be included in | specific value field that allows any metadata to be included in | |||
| either the HostMetadata or PathMetadata lists. | either the HostMetadata or PathMetadata arrays. | |||
| As with the initial GenericMetadata types defined in Section 4.2, | As with the initial GenericMetadata types defined in Section 4.2, | |||
| future GenericMetadata types MUST specify the information necessary | future GenericMetadata types MUST specify the information necessary | |||
| for constructing and decoding the GenericMetadata object. | for constructing and decoding the GenericMetadata object. | |||
| Any document which defines a new GenericMetadata type MUST: | Any document which defines a new GenericMetadata type MUST: | |||
| 1. Specify and register the CDNI Payload Type [RFC7736] used to | 1. Specify and register the CDNI Payload Type [RFC7736] used to | |||
| identify the new GenericMetadata type being specified. | identify the new GenericMetadata type being specified. | |||
| skipping to change at page 43, line 44 ¶ | skipping to change at page 45, line 43 ¶ | |||
| property named "href" because doing so would conflict with the | property named "href" because doing so would conflict with the | |||
| ability to detect Link objects (see Section 4.3.1). | ability to detect Link objects (see Section 4.3.1). | |||
| 3. Define a name, description, type, and whether or not the property | 3. Define a name, description, type, and whether or not the property | |||
| is mandatory-to-specify. | is mandatory-to-specify. | |||
| 4. Describe the semantics of the new type including its purpose and | 4. Describe the semantics of the new type including its purpose and | |||
| example of a use case to which it applies including an example | example of a use case to which it applies including an example | |||
| encoded in I-JSON. | encoded in I-JSON. | |||
| 5. Describe the security and privacy consequences, for both the | ||||
| user-agent and the CDN, of the new GenericMetadata object. | ||||
| 6. Describe any relation to, conflict with, or obsolescence of other | ||||
| existing CDNI metadata objects. | ||||
| Note: In the case of vendor specific extensions, vendor-identifying | Note: In the case of vendor specific extensions, vendor-identifying | |||
| CDNI Payload Type names will decrease the possibility of | CDNI Payload Type names will decrease the possibility of | |||
| GenericMetadata type collisions. | GenericMetadata type collisions. | |||
| 6.6. Metadata Enforcement | 6.6. Metadata Enforcement | |||
| At any given time, the set of GenericMetadata types supported by the | At any given time, the set of GenericMetadata types supported by the | |||
| uCDN might not match the set of GenericMetadata types supported by | uCDN might not match the set of GenericMetadata types supported by | |||
| the dCDN. | the dCDN. | |||
| skipping to change at page 44, line 49 ¶ | skipping to change at page 46, line 49 ¶ | |||
| be applied, especially if the functionality of the metadata overlap. | be applied, especially if the functionality of the metadata overlap. | |||
| As described in Section 3.3, metadata override only applies to | As described in Section 3.3, metadata override only applies to | |||
| metadata objects of the same exact type found in HostMetadata and | metadata objects of the same exact type found in HostMetadata and | |||
| nested PathMetadata structures. The CDNI metadata interface does not | nested PathMetadata structures. The CDNI metadata interface does not | |||
| support enforcement of dependencies between different metadata types. | support enforcement of dependencies between different metadata types. | |||
| It is the responsibility of the CSP and the CDN operators to ensure | It is the responsibility of the CSP and the CDN operators to ensure | |||
| that metadata assigned to a given piece of content do not conflict. | that metadata assigned to a given piece of content do not conflict. | |||
| Note: Because metadata is inherently ordered in HostMetadata and | Note: Because metadata is inherently ordered in HostMetadata and | |||
| PathMetadata lists, as well as in the PathMatch hierarchy, multiple | PathMetadata arrays, as well as in the PathMatch hierarchy, multiple | |||
| conflicting metadata types MAY be used, however, metadata hierarchies | conflicting metadata types MAY be used, however, metadata hierarchies | |||
| SHOULD ensure that independent PathMatch root objects are used to | SHOULD ensure that independent PathMatch root objects are used to | |||
| prevent ambiguous or conflicting metadata definitions. | prevent ambiguous or conflicting metadata definitions. | |||
| 6.8. Versioning | 6.8. Versioning | |||
| The version of CDNI metadata objects is conveyed inside the CDNI | The version of CDNI metadata objects is conveyed inside the CDNI | |||
| Payload Type that is included in the HTTP Content-Type header, for | Payload Type that is included in either the HTTP Content-Type header, | |||
| example: "Content-Type: application/cdni; ptype=MI.HostIndex". We | for example: "Content-Type: application/cdni; ptype=MI.HostIndex", | |||
| intentionally omit the ".v1" on the initial versions of metadata, for | when retrieved via a link, or in the link type (Section 4.3.1), | |||
| simplicity. Subsequent versions of those metadata MUST postpend a | generic-metadata-type (Section 4.1.7), or auth-type (Section 4.2.7) | |||
| version string (e.g., ".v2"). Upon responding to a request for an | properties in the JSON payload. The CDNI Payload Type uniquely | |||
| object, a CDNI metadata server MUST include a Content-Type header | identifies the specification defining that object, including any | |||
| with the CDNI Payload Type containing the version number (or | relation to, conflicts with, or obsolescence of other metadata. | |||
| implicitly, version 1) of the object. HTTP requests sent to a | There is no explicit version mapping requirement, however, for ease | |||
| metadata server SHOULD include an Accept header with the CDNI Payload | of understanding, metadata creators SHOULD make new versions of | |||
| Type (which includes the version) of the expected object. Metadata | metadata easily visible via the CDNI Payload Type, e.g., by appending | |||
| a version string. Note: A version string is optional on the first | ||||
| version, e.g., MI.HostIndex, but could be added for subsequent | ||||
| versions, e.g., MI.HostIndex.v2, MI.HostIndex.v3, etc. | ||||
| Except when referenced by a Link object, nested metadata objects | ||||
| (i.e., structural metadata below the HostIndex; Source objects; | ||||
| Location, TimeWindow, and Protocol Rule objects; and Footprint and | ||||
| TimeWindow objects) can be serialized into a JSON payload without | ||||
| explicit CDNI Payload Type information. The type is inferred from | ||||
| the outer structural metadata, generic metadata, or auth object CDNI | ||||
| Payload Type. To avoid ambiguity when revising nestable metadata | ||||
| objects, any outer metadata object(s) MUST be reversioned and | ||||
| allocated new CDNI Payload Type(s) at the same time. For example, | ||||
| the MI.HostIndex object defined in this document contains an array of | ||||
| MI.HostMatch objects, which each in turn contains a MI.HostMetadata | ||||
| object. If a new MI.HostMetadata.v2 object were required, the outer | ||||
| MI.HostIndex and MI.HostMatch objects would need to be revised, e.g., | ||||
| to MI.HostIndex.v2 and MI.HostMatch.v2, respectively. Similarly, if | ||||
| a new MI.TimeWindowRule.v2 object was required, the outer | ||||
| MI.TimeWindowACL object would need to be revised, e.g., to | ||||
| MI.TimeWindowACL.v2; the MI.TimeWindowRule.v2 object, though, could | ||||
| still contain MI.TimeWindow objects, if so specified. | ||||
| HTTP requests sent to a metadata server SHOULD include an Accept | ||||
| header with the CDNI Payload Type of the expected object. Metadata | ||||
| clients can specify multiple CDNI Payload Types in the Accept header, | clients can specify multiple CDNI Payload Types in the Accept header, | |||
| for example if a metadata client is capable of processing two | for example, if a metadata client is capable of processing two | |||
| different versions of the same type of object (defined by different | different versions of the same type of object (defined by different | |||
| CDNI Payload Types) it might decide to include both in the Accept | CDNI Payload Types) it might decide to include both in the Accept | |||
| header. | header. | |||
| 6.9. Media Types | 6.9. Media Types | |||
| All CDNI metadata objects use the Media Type "application/cdni". The | All CDNI metadata objects use the Media Type "application/cdni". The | |||
| CDNI Payload Type for each object then contains the object name of | CDNI Payload Type for each object then contains the object name of | |||
| that object as defined by this document, prefixed with "MI.". | that object as defined by this document, prefixed with "MI.". | |||
| Table 4 lists the CDNI Paylod Type for the metadata objects | Table 4 lists the CDNI Payload Type for the metadata objects | |||
| (resources) specified in this document. | (resources) specified in this document. | |||
| +-----------------------+--------------------------+ | +-----------------------+--------------------------+ | |||
| | Data Object | CDNI Payload Type | | | Data Object | CDNI Payload Type | | |||
| +-----------------------+--------------------------+ | +-----------------------+--------------------------+ | |||
| | HostIndex | MI.HostIndex | | | HostIndex | MI.HostIndex | | |||
| | HostMatch | MI.HostMatch | | | HostMatch | MI.HostMatch | | |||
| | HostMetadata | MI.HostMetadata | | | HostMetadata | MI.HostMetadata | | |||
| | PathMatch | MI.PathMatch | | | PathMatch | MI.PathMatch | | |||
| | PatternMatch | MI.PatternMatch | | | PatternMatch | MI.PatternMatch | | |||
| | PathMetadata | MI.PathMetadata | | | PathMetadata | MI.PathMetadata | | |||
| | SourceMetadata | MI.SourceMetadata | | | SourceMetadata | MI.SourceMetadata | | |||
| | Source | MI.Source | | | Source | MI.Source | | |||
| | LocationACL | MI.LocationACL | | | LocationACL | MI.LocationACL | | |||
| | LocationRule | MI.LocationRule | | | LocationRule | MI.LocationRule | | |||
| | Footprint | MI.Footprint | | | Footprint | MI.Footprint | | |||
| | TimeWindowACL | MI.TimeWindowACL | | | TimeWindowACL | MI.TimeWindowACL | | |||
| | TimeWindowRule | MI.TimeWindowRule | | | TimeWindowRule | MI.TimeWindowRule | | |||
| | TimeWindow | MI.TineWindow | | | TimeWindow | MI.TimeWindow | | |||
| | ProtocolACL | MI.ProtocolACL | | | ProtocolACL | MI.ProtocolACL | | |||
| | ProtocolRule | MI.ProtocolRule | | | ProtocolRule | MI.ProtocolRule | | |||
| | DeliveryAuthorization | MI.DeliveryAuthorization | | | DeliveryAuthorization | MI.DeliveryAuthorization | | |||
| | Cache | MI.Cache | | | Cache | MI.Cache | | |||
| | Auth | MI.Auth | | | Auth | MI.Auth | | |||
| | Grouping | MI.Grouping | | | Grouping | MI.Grouping | | |||
| +-----------------------+--------------------------+ | +-----------------------+--------------------------+ | |||
| Table 4: CDNI Payload Types for CDNI Metadata objects | Table 4: CDNI Payload Types for CDNI Metadata objects | |||
| skipping to change at page 47, line 11 ¶ | skipping to change at page 49, line 11 ¶ | |||
| A dCDN requests the HostIndex and receive the following object with a | A dCDN requests the HostIndex and receive the following object with a | |||
| CDNI payload type of "MI.HostIndex": | CDNI payload type of "MI.HostIndex": | |||
| { | { | |||
| "hosts": [ | "hosts": [ | |||
| { | { | |||
| "host": "video.example.com", | "host": "video.example.com", | |||
| "host-metadata" : { | "host-metadata" : { | |||
| "type": "MI.HostMetadata", | "type": "MI.HostMetadata", | |||
| "href": "http://metadata.ucdn.example/host1234" | "href": "https://metadata.ucdn.example/host1234" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "host": "images.example.com", | "host": "images.example.com", | |||
| "host-metadata" : { | "host-metadata" : { | |||
| "type": "MI.HostMetadata", | "type": "MI.HostMetadata", | |||
| "href": "http://metadata.ucdn.example/host5678" | "href": "https://metadata.ucdn.example/host5678" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| If the incoming request has a Host header with "video.example.com" | If the incoming request has a Host header with "video.example.com" | |||
| then the dCDN would fetch the HostMetadata object from | then the dCDN would fetch the HostMetadata object from | |||
| "http://metadata.ucdn.example/host1234" expecting a CDNI payload type | "https://metadata.ucdn.example/host1234" expecting a CDNI payload | |||
| of "MI.HostMetadata": | type of "MI.HostMetadata": | |||
| { | { | |||
| "metadata": [ | "metadata": [ | |||
| { | { | |||
| "generic-metadata-type": "MI.SourceMetadata", | "generic-metadata-type": "MI.SourceMetadata", | |||
| "generic-metadata-value": { | "generic-metadata-value": { | |||
| "sources": [ | "sources": [ | |||
| { | { | |||
| "endpoint": "acq1.ucdn.example", | "endpoint": ["acq1.ucdn.example"], | |||
| "protocol": "http1.1" | "protocol": "http/1.1" | |||
| }, | }, | |||
| { | { | |||
| "endpoint": "acq2.ucdn.example", | "endpoint": ["acq2.ucdn.example"], | |||
| "protocol": "http1.1" | "protocol": "http/1.1" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "generic-metadata-type": "MI.LocationACL", | "generic-metadata-type": "MI.LocationACL", | |||
| "generic-metadata-value": { | "generic-metadata-value": { | |||
| "locations": [ | "locations": [ | |||
| { | { | |||
| "footprints": [ | "footprints": [ | |||
| { | { | |||
| "footprint-type": "IPv4CIDR", | "footprint-type": "ipv4cidr", | |||
| "footprint-value": "192.0.2.0/24" | "footprint-value": ["192.0.2.0/24"] | |||
| }, | ||||
| { | ||||
| "footprint-type": "ipv6cidr", | ||||
| "footprint-value": ["2001:db8::/32"] | ||||
| }, | ||||
| { | ||||
| "footprint-type": "countrycode", | ||||
| "footprint-value": ["us"] | ||||
| }, | ||||
| { | ||||
| "footprint-type": "asn", | ||||
| "footprint-value": ["as64496"] | ||||
| } | } | |||
| ], | ], | |||
| "action": "deny" | "action": "deny" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "generic-metadata-type": "MI.ProtocolACL", | "generic-metadata-type": "MI.ProtocolACL", | |||
| "generic-metadata-value": { | "generic-metadata-value": { | |||
| "protocol-acl": [ | "protocol-acl": [ | |||
| { | { | |||
| "protocols": [ | "protocols": [ | |||
| "http1.1" | "http/1.1" | |||
| ], | ], | |||
| "action": "allow" | "action": "allow" | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| } | } | |||
| ], | ], | |||
| "paths": [ | "paths": [ | |||
| { | { | |||
| "path-pattern": { | "path-pattern": { | |||
| "pattern": "/video/trailers/*" | "pattern": "/video/trailers/*" | |||
| }, | }, | |||
| "path-metadata": { | "path-metadata": { | |||
| "type": "MI.PathMetadata", | "type": "MI.PathMetadata", | |||
| "href": "http://metadata.ucdn.example/host1234/pathABC" | "href": "https://metadata.ucdn.example/host1234/pathABC" | |||
| } | } | |||
| }, | }, | |||
| { | { | |||
| "path-pattern": { | "path-pattern": { | |||
| "pattern": "/video/movies/*" | "pattern": "/video/movies/*" | |||
| }, | }, | |||
| "path-metadata": { | "path-metadata": { | |||
| "type": "MI.PathMetadata", | "type": "MI.PathMetadata", | |||
| "href": "http://metadata.ucdn.example/host1234/pathDEF" | "href": "https://metadata.ucdn.example/host1234/pathDEF" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| Suppose the path of the requested resource matches the "/video/ | Suppose the path of the requested resource matches the "/video/ | |||
| movies/*" pattern, the next metadata requested would be for | movies/*" pattern, the next metadata requested would be for | |||
| "http://metadata.ucdn.example/host1234/pathDCE" with an expected CDNI | "https://metadata.ucdn.example/host1234/pathDCE" with an expected | |||
| payload type of "MI.PathMetadata": | CDNI payload type of "MI.PathMetadata": | |||
| { | { | |||
| "metadata": [], | "metadata": [], | |||
| "paths": [ | "paths": [ | |||
| { | { | |||
| "path-pattern": { | "path-pattern": { | |||
| "pattern": "/videos/movies/hd/*" | "pattern": "/videos/movies/hd/*" | |||
| }, | }, | |||
| "path-metadata": { | "path-metadata": { | |||
| "type": "MI.PathMetadata", | "type": "MI.PathMetadata", | |||
| "href": | "href": | |||
| "http://metadata.ucdn.example/host1234/pathDEF/path123" | "https://metadata.ucdn.example/host1234/pathDEF/path123" | |||
| } | } | |||
| } | } | |||
| ] | ] | |||
| } | } | |||
| Finally, if the path of the requested resource also matches the | Finally, if the path of the requested resource also matches the | |||
| "/videos/movies/hd/*" pattern, the dCDN would also fetch the | "/videos/movies/hd/*" pattern, the dCDN would also fetch the | |||
| following object from "http://metadata.ucdn.example/host1234/pathDEF/ | following object from | |||
| path123" with CDNI payload type "MI.PathMetadata": | "https://metadata.ucdn.example/host1234/pathDEF/path123" with CDNI | |||
| payload type "MI.PathMetadata": | ||||
| { | { | |||
| "metadata": [ | "metadata": [ | |||
| { | { | |||
| "generic-metadata-type": "MI.TimeWindowACL", | "generic-metadata-type": "MI.TimeWindowACL", | |||
| "generic-metadata-value": { | "generic-metadata-value": { | |||
| "times": [ | "times": [ | |||
| "windows": [ | "windows": [ | |||
| { | { | |||
| "start": "1213948800", | "start": "1213948800", | |||
| skipping to change at page 50, line 43 ¶ | skipping to change at page 53, line 36 ¶ | |||
| | MI.Auth | RFCthis | | | MI.Auth | RFCthis | | |||
| | MI.Grouping | RFCthis | | | MI.Grouping | RFCthis | | |||
| +--------------------------+---------------+ | +--------------------------+---------------+ | |||
| [RFC Editor: Please replace RFCthis with the published RFC number for | [RFC Editor: Please replace RFCthis with the published RFC number for | |||
| this document.] | this document.] | |||
| 7.1.1. CDNI MI HostIndex Payload Type | 7.1.1. CDNI MI HostIndex Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish HostIndex | Purpose: The purpose of this payload type is to distinguish HostIndex | |||
| MI objects (and any associated capabilitiy advertisement) | MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.1.1 | Encoding: see Section 4.1.1 | |||
| 7.1.2. CDNI MI HostMatch Payload Type | 7.1.2. CDNI MI HostMatch Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish HostMatch | Purpose: The purpose of this payload type is to distinguish HostMatch | |||
| MI objects (and any associated capabilitiy advertisement) | MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.1.2 | Encoding: see Section 4.1.2 | |||
| 7.1.3. CDNI MI HostMetadata Payload Type | 7.1.3. CDNI MI HostMetadata Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| HostMetadata MI objects (and any associated capabilitiy | HostMetadata MI objects (and any associated capability advertisement) | |||
| advertisement) | ||||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.1.3 | Encoding: see Section 4.1.3 | |||
| 7.1.4. CDNI MI PathMatch Payload Type | 7.1.4. CDNI MI PathMatch Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish PathMatch | Purpose: The purpose of this payload type is to distinguish PathMatch | |||
| MI objects (and any associated capabilitiy advertisement) | MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.1.4 | Encoding: see Section 4.1.4 | |||
| 7.1.5. CDNI MI PatternMatch Payload Type | 7.1.5. CDNI MI PatternMatch Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| PatternMatch MI objects (and any associated capabilitiy | PatternMatch MI objects (and any associated capability advertisement) | |||
| advertisement) | ||||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.1.5 | Encoding: see Section 4.1.5 | |||
| 7.1.6. CDNI MI PathMetadata Payload Type | 7.1.6. CDNI MI PathMetadata Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| PathMetadata MI objects (and any associated capabilitiy | PathMetadata MI objects (and any associated capability advertisement) | |||
| advertisement) | ||||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.1.6 | Encoding: see Section 4.1.6 | |||
| 7.1.7. CDNI MI SourceMetadata Payload Type | 7.1.7. CDNI MI SourceMetadata Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| SourceMetadata MI objects (and any associated capabilitiy | SourceMetadata MI objects (and any associated capability | |||
| advertisement) | advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.1 | Encoding: see Section 4.2.1 | |||
| 7.1.8. CDNI MI Source Payload Type | 7.1.8. CDNI MI Source Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish Source MI | Purpose: The purpose of this payload type is to distinguish Source MI | |||
| objects (and any associated capabilitiy advertisement) | objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.1.1 | Encoding: see Section 4.2.1.1 | |||
| 7.1.9. CDNI MI LocationACL Payload Type | 7.1.9. CDNI MI LocationACL Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| LocationACL MI objects (and any associated capabilitiy advertisement) | LocationACL MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.2 | Encoding: see Section 4.2.2 | |||
| 7.1.10. CDNI MI LocationRule Payload Type | 7.1.10. CDNI MI LocationRule Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| LocationRule MI objects (and any associated capabilitiy | LocationRule MI objects (and any associated capability advertisement) | |||
| advertisement) | ||||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.2.1 | Encoding: see Section 4.2.2.1 | |||
| 7.1.11. CDNI MI Footprint Payload Type | 7.1.11. CDNI MI Footprint Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish Footprint | Purpose: The purpose of this payload type is to distinguish Footprint | |||
| MI objects (and any associated capabilitiy advertisement) | MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.2.2 | Encoding: see Section 4.2.2.2 | |||
| 7.1.12. CDNI MI TimeWindowACL Payload Type | 7.1.12. CDNI MI TimeWindowACL Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| TimeWindowACL MI objects (and any associated capabilitiy | TimeWindowACL MI objects (and any associated capability | |||
| advertisement) | advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.3 | Encoding: see Section 4.2.3 | |||
| 7.1.13. CDNI MI TimeWindowRule Payload Type | 7.1.13. CDNI MI TimeWindowRule Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| TimeWindowRule MI objects (and any associated capabilitiy | TimeWindowRule MI objects (and any associated capability | |||
| advertisement) | advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.3.1 | Encoding: see Section 4.2.3.1 | |||
| 7.1.14. CDNI MI TimeWindow Payload Type | 7.1.14. CDNI MI TimeWindow Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| TimeWindow MI objects (and any associated capabilitiy advertisement) | TimeWindow MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.3.2 | Encoding: see Section 4.2.3.2 | |||
| 7.1.15. CDNI MI ProtocolACL Payload Type | 7.1.15. CDNI MI ProtocolACL Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| ProtocolACL MI objects (and any associated capabilitiy advertisement) | ProtocolACL MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.4 | Encoding: see Section 4.2.4 | |||
| 7.1.16. CDNI MI ProtocolRule Payload Type | 7.1.16. CDNI MI ProtocolRule Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| ProtocolRule MI objects (and any associated capabilitiy | ProtocolRule MI objects (and any associated capability advertisement) | |||
| advertisement) | ||||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.4.1 | Encoding: see Section 4.2.4.1 | |||
| 7.1.17. CDNI MI DeliveryAuthorization Payload Type | 7.1.17. CDNI MI DeliveryAuthorization Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish | Purpose: The purpose of this payload type is to distinguish | |||
| DeliveryAuthorization MI objects (and any associated capabilitiy | DeliveryAuthorization MI objects (and any associated capability | |||
| advertisement) | advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.5 | Encoding: see Section 4.2.5 | |||
| 7.1.18. CDNI MI Cache Payload Type | 7.1.18. CDNI MI Cache Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish Cache MI | Purpose: The purpose of this payload type is to distinguish Cache MI | |||
| objects (and any associated capabilitiy advertisement) | objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.6 | Encoding: see Section 4.2.6 | |||
| 7.1.19. CDNI MI Auth Payload Type | 7.1.19. CDNI MI Auth Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish Auth MI | Purpose: The purpose of this payload type is to distinguish Auth MI | |||
| objects (and any associated capabilitiy advertisement) | objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.7 | Encoding: see Section 4.2.7 | |||
| 7.1.20. CDNI MI Grouping Payload Type | 7.1.20. CDNI MI Grouping Payload Type | |||
| Purpose: The purpose of this payload type is to distinguish Grouping | Purpose: The purpose of this payload type is to distinguish Grouping | |||
| MI objects (and any associated capabilitiy advertisement) | MI objects (and any associated capability advertisement) | |||
| Interface: MI/FCI | Interface: MI/FCI | |||
| Encoding: see Section 4.2.8 | Encoding: see Section 4.2.8 | |||
| 7.2. CDNI Metadata Footprint Types Registry | 7.2. CDNI Metadata Footprint Types Registry | |||
| The IANA is requested to create a new "CDNI Metadata Footprint Types" | The IANA is requested to create a new "CDNI Metadata Footprint Types" | |||
| subregistry in the "Content Delivery Networks Interconnection (CDNI) | subregistry in the "Content Delivery Networks Interconnection (CDNI) | |||
| Parameters" registry. The "CDNI Metadata Footprint Types" namespace | Parameters" registry. The "CDNI Metadata Footprint Types" namespace | |||
| skipping to change at page 55, line 38 ¶ | skipping to change at page 58, line 34 ¶ | |||
| Protocol namespace conform to the "Specification Required" policy as | Protocol namespace conform to the "Specification Required" policy as | |||
| defined in [RFC5226], where the specification defines the Protocol | defined in [RFC5226], where the specification defines the Protocol | |||
| Type and the protocol to which it is associated. The designated | Type and the protocol to which it is associated. The designated | |||
| expert will verify that new protocol definitions do not duplicate | expert will verify that new protocol definitions do not duplicate | |||
| existing protocol definitions and prevent gratuitous additions to the | existing protocol definitions and prevent gratuitous additions to the | |||
| namespace. | namespace. | |||
| The following table defines the initial Protocol values corresponding | The following table defines the initial Protocol values corresponding | |||
| to the HTTP and HTTPS protocols: | to the HTTP and HTTPS protocols: | |||
| +----------+-----------------------+---------------+----------------+ | +-----------+----------------------+---------------+----------------+ | |||
| | Protocol | Description | Type | Protocol | | | Protocol | Description | Type | Protocol | | |||
| | Type | | Specification | Specification | | | Type | | Specification | Specifications | | |||
| +----------+-----------------------+---------------+----------------+ | +-----------+----------------------+---------------+----------------+ | |||
| | http1.1 | Hypertext Transfer | RFCthis | RFC7230 | | | http/1.1 | Hypertext Transfer | RFCthis | RFC7230 | | |||
| | | Protocol -- HTTP/1.1 | | | | | | Protocol -- HTTP/1.1 | | | | |||
| | https1.1 | HTTP/1.1 Over TLS | RFCthis | RFC2818 | | | https/1.1 | HTTP/1.1 Over TLS | RFCthis | RFC7230, | | |||
| +----------+-----------------------+---------------+----------------+ | | | | | RFC2818 | | |||
| +-----------+----------------------+---------------+----------------+ | ||||
| [RFC Editor: Please replace RFCthis with the published RFC number for | [RFC Editor: Please replace RFCthis with the published RFC number for | |||
| this document.] | this document.] | |||
| 7.4. CDNI Metadata Auth Types Registry | ||||
| The IANA is requested to create a new "CDNI Metadata Auth Types" | ||||
| subregistry in the "Content Delivery Networks Interconnection (CDNI) | ||||
| Parameters" registry. The "CDNI Metadata Auth Type" namespace | ||||
| defines the valid Auth object types used by the Auth object in | ||||
| Section 4.2.7. Additions to the Auth Type namespace conform to the | ||||
| "Specification Required" policy as defined in [RFC5226]. The | ||||
| designated expert will verify that new type definitions do not | ||||
| duplicate existing type definitions and prevent gratuitous additions | ||||
| to the namespace. New registrations are required to provide a clear | ||||
| description of what information the uCDN is required to provide to | ||||
| the dCDN, as well as the procedures the dCDN is required to perform | ||||
| to authorize and/or authenticate content requests. | ||||
| The registry will initially be unpopulated: | ||||
| +-----------+-------------+---------------+ | ||||
| | Auth Type | Description | Specification | | ||||
| +-----------+-------------+---------------+ | ||||
| +-----------+-------------+---------------+ | ||||
| 8. Security Considerations | 8. Security Considerations | |||
| 8.1. Authentication and Integrity | ||||
| 8.1. Authentication | A malicious metadata server, proxy server, or attacker, impersonating | |||
| an authentic uCDN metadata interface without being detected, could | ||||
| Unauthorized access to metadata could result in denial of service. A | provide false metadata to a dCDN that either: | |||
| malicious metadata server, proxy server, or an attacker performing a | ||||
| "man in the middle" attack could provide malicious metadata to a dCDN | ||||
| that either: | ||||
| o Denies service for one or more pieces of content to one or more | o Denies service for one or more pieces of content to one or more | |||
| User Agents; or | User Agents; | |||
| o Directs dCDNs to contact malicious origin servers instead of the | o Directs dCDNs to contact malicious origin servers instead of the | |||
| actual origin servers. | actual origin servers, and substitute legitimate content with | |||
| malware or slanderous alternate content; or | ||||
| o Removes delivery restrictions (e.g., LocationACL, TimeWindowACL, | ||||
| ProtocolACL, or Auth metadata), allowing access to content that | ||||
| would otherwise be denied, and thus possibly violating license | ||||
| restrictions and incurring unwarranted delivery costs. | ||||
| Unauthorized access to metadata could also enable a malicious | Unauthorized access to metadata could also enable a malicious | |||
| metadata client to continuously issue metadata requests in order to | metadata client to continuously issue metadata requests in order to | |||
| overload a uCDN's metadata server(s). | overload a uCDN's metadata server(s). | |||
| Unauthorized access to metadata could result in leakage of private | Unauthorized access to metadata could further result in leakage of | |||
| information. A malicious metadata client could request metadata in | private information. A malicious metadata client could request | |||
| order to gain access to origin servers, as well as information | metadata in order to gain access to origin servers, as well as | |||
| pertaining to content restrictions. | information pertaining to content restrictions. | |||
| An implementation of the CDNI metadata interface SHOULD use mutual | An implementation of the CDNI metadata interface MUST use mutual | |||
| authentication to prevent unauthorized access to metadata. | authentication and message authentication codes to prevent | |||
| unauthorized access to and undetected modification of metadata (see | ||||
| Section 8.3). | ||||
| 8.2. Confidentiality | 8.2. Confidentiality and Privacy | |||
| Unauthorized viewing of metadata could result in leakage of private | Unauthorized viewing of metadata could result in leakage of private | |||
| information. A third party could intercept metadata transactions in | information. Content provider origin and policy information is | |||
| order to gain access to origin servers, as well as information | conveyed through the CDNI metadata interface. A third party could | |||
| pertaining to content restrictions. | intercept metadata transactions in order to gain access to origin | |||
| servers, as well as information pertaining to content restrictions | ||||
| An implementation of the CDNI metadata interface SHOULD use strong | and usage patterns. | |||
| encryption to prevent unauthorized interception of metadata. | ||||
| 8.3. Integrity | ||||
| Unauthorized modification of metadata could result in denial of | ||||
| service. A malicious metadata server, proxy server, or an attacker | ||||
| performing a "man in the middle" attack could modify metadata | ||||
| destined to a dCDN in order to deny service for one or more pieces of | ||||
| content to one or more user agents. A malicious metadata server, | ||||
| proxy server, or an attacker performing a "Man in the middle" attack | ||||
| could also modify metadata so that dCDNs are directed to contact to | ||||
| malicious origin servers instead of the actual origin servers. | ||||
| An implementation of the CDNI metadata interface SHOULD use strong | ||||
| encryption and mutual authentication to prevent unauthorized | ||||
| modification of metadata. | ||||
| 8.4. Privacy | Note: The distribution of metadata by a uCDN to dCDNs could introduce | |||
| privacy concerns for some content providers, e.g., dCDNs accepting | ||||
| content requests for a content provider's content might be able to | ||||
| obtain additional information and usage patterns relating to the | ||||
| users of a content provider's services. Content providers with | ||||
| concerns about divulging information to dCDNs can instruct their uCDN | ||||
| partners not to use CDNI when delivering their content. | ||||
| Content provider origin and policy information is conveyed through | An implementation of the CDNI metadata interface MUST use strong | |||
| the CDNI metadata interface. The distribution of this information to | encryption to prevent unauthorized interception or monitoring of | |||
| another CDN could introduce potential privacy concerns for some | metadata (see Section 8.3). | |||
| content providers, for example, dCDNs accepting content requests for | ||||
| a content provider's content might be able to obtain additional | ||||
| information and usage patterns relating to the users of a content | ||||
| provider's services. Content providers with such concerns can | ||||
| instruct their CDN partners not to use CDN interconnects when | ||||
| delivering that content provider's content. | ||||
| An attacker performing a "man in the middle" attack could monitor | 8.3. Securing the CDNI Metadata interface | |||
| metadata in order to obtain usage patterns relating to the users of a | ||||
| content provider's services. | ||||
| An implementation of the CDNI metadata interface SHOULD use strong | An implementation of the CDNI metadata interface MUST support TLS | |||
| encryption and mutual authentication to prevent unauthorized | transport as per [RFC2818] and [RFC7230]. | |||
| monitoring of metadata. | ||||
| 8.5. Securing the CDNI Metadata interface | TLS MUST be used by the server-side (dCDN) and the client-side (uCDN) | |||
| of the CDNI metadata interface, including authentication of the | ||||
| remote end, unless alternate methods are used for ensuring the | ||||
| security of the information in the CDNI metadata interface requests | ||||
| and responses (such as setting up an IPsec tunnel between the two | ||||
| CDNs or using a physically secured internal network between two CDNs | ||||
| that are owned by the same corporate entity). | ||||
| An implementation of the CDNI metadata interface MUST support TLS | The use of TLS for transport of the CDNI metadata interface messages | |||
| transport as per [RFC2818] and [RFC7230]. The use of TLS for | allows: | |||
| transport of the CDNI metadata interface messages allows: | ||||
| o The dCDN and uCDN to authenticate each other. | o The dCDN and uCDN to authenticate each other. | |||
| and, once they have mutually authenticated each other, it allows: | and, once they have mutually authenticated each other, it allows: | |||
| o The dCDN and uCDN to authorize each other (to ensure they are | o The dCDN and uCDN to authorize each other (to ensure they are | |||
| transmitting/receiving CDNI metadata requests and responses from | transmitting/receiving CDNI metadata requests and responses from | |||
| an authorized CDN); | an authorized CDN); | |||
| o CDNI metadata interface requests and responses to be transmitted | o CDNI metadata interface requests and responses to be transmitted | |||
| with confidentiality; and | with confidentiality; and | |||
| o The integrity of the CDNI metadata interface requests and | o The integrity of the CDNI metadata interface requests and | |||
| responses to be protected during the exchange. | responses to be protected during the exchange. | |||
| In an environment where any such protection is required, TLS MUST be | ||||
| used (including authentication of the remote end) by the server-side | ||||
| (uCDN) and the client-side (dCDN) of the CDNI metadata interface | ||||
| unless alternate methods are used for ensuring the confidentiality of | ||||
| the information in the CDNI metadata interface requests and responses | ||||
| (such as setting up an IPsec tunnel between the two CDNs or using a | ||||
| physically secured internal network between two CDNs that are owned | ||||
| by the same corporate entity). | ||||
| When TLS is used, the general TLS usage guidance in [RFC7525] MUST be | When TLS is used, the general TLS usage guidance in [RFC7525] MUST be | |||
| followed. | followed. | |||
| 9. Acknowledgements | 9. Acknowledgements | |||
| The authors would like to thank David Ferguson, Francois Le Faucheur, | The authors would like to thank David Ferguson, Francois Le Faucheur, | |||
| Jan Seedorf and Matt Miller for their valuable comments and input to | Jan Seedorf and Matt Miller for their valuable comments and input to | |||
| this document. | this document. | |||
| 10. Contributing Authors | 10. Contributing Authors | |||
| skipping to change at page 59, line 25 ¶ | skipping to change at page 61, line 25 ¶ | |||
| San Jose, 95134 | San Jose, 95134 | |||
| USA | USA | |||
| Email: kleung@cisco.com | Email: kleung@cisco.com | |||
| 11. References | 11. References | |||
| 11.1. Normative References | 11.1. Normative References | |||
| [ISO3166-1] | [ISO3166-1] | |||
| "https://www.iso.org/obp/ui/#search". | The International Organization for Standardization, "Codes | |||
| for the representation of names of countries and their | ||||
| subdivisions -- Part 1: Country codes", ISO 3166-1:2013, | ||||
| 2013. | ||||
| [POSIX] Institute of Electrical and Electronics Engineers, | ||||
| "Information Technology Portable Operating System | ||||
| Interface (POSIX) Part 1: System Application Program | ||||
| Interface (API) [C Language]", IEEE P1003.1, 1990. | ||||
| [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", | ||||
| STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, | ||||
| <http://www.rfc-editor.org/info/rfc1034>. | ||||
| [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - | ||||
| Application and Support", STD 3, RFC 1123, | ||||
| DOI 10.17487/RFC1123, October 1989, | ||||
| <http://www.rfc-editor.org/info/rfc1123>. | ||||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| <http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
| [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
| Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
| RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
| <http://www.rfc-editor.org/info/rfc3986>. | <http://www.rfc-editor.org/info/rfc3986>. | |||
| [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing | |||
| Architecture", RFC 4291, DOI 10.17487/RFC4291, February | Architecture", RFC 4291, DOI 10.17487/RFC4291, February | |||
| 2006, <http://www.rfc-editor.org/info/rfc4291>. | 2006, <http://www.rfc-editor.org/info/rfc4291>. | |||
| [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an | |||
| IANA Considerations Section in RFCs", BCP 26, RFC 5226, | IANA Considerations Section in RFCs", BCP 26, RFC 5226, | |||
| DOI 10.17487/RFC5226, May 2008, | DOI 10.17487/RFC5226, May 2008, | |||
| <http://www.rfc-editor.org/info/rfc5226>. | <http://www.rfc-editor.org/info/rfc5226>. | |||
| [RFC5861] Nottingham, M., "HTTP Cache-Control Extensions for Stale | [RFC5890] Klensin, J., "Internationalized Domain Names for | |||
| Content", RFC 5861, DOI 10.17487/RFC5861, May 2010, | Applications (IDNA): Definitions and Document Framework", | |||
| <http://www.rfc-editor.org/info/rfc5861>. | RFC 5890, DOI 10.17487/RFC5890, August 2010, | |||
| <http://www.rfc-editor.org/info/rfc5890>. | ||||
| [RFC5891] Klensin, J., "Internationalized Domain Names in | ||||
| Applications (IDNA): Protocol", RFC 5891, | ||||
| DOI 10.17487/RFC5891, August 2010, | ||||
| <http://www.rfc-editor.org/info/rfc5891>. | ||||
| [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 | [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 | |||
| Address Text Representation", RFC 5952, | Address Text Representation", RFC 5952, | |||
| DOI 10.17487/RFC5952, August 2010, | DOI 10.17487/RFC5952, August 2010, | |||
| <http://www.rfc-editor.org/info/rfc5952>. | <http://www.rfc-editor.org/info/rfc5952>. | |||
| [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content | [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content | |||
| Distribution Network Interconnection (CDNI) Problem | Distribution Network Interconnection (CDNI) Problem | |||
| Statement", RFC 6707, DOI 10.17487/RFC6707, September | Statement", RFC 6707, DOI 10.17487/RFC6707, September | |||
| 2012, <http://www.rfc-editor.org/info/rfc6707>. | 2012, <http://www.rfc-editor.org/info/rfc6707>. | |||
| [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer | |||
| Protocol (HTTP/1.1): Message Syntax and Routing", | Protocol (HTTP/1.1): Message Syntax and Routing", | |||
| RFC 7230, DOI 10.17487/RFC7230, June 2014, | RFC 7230, DOI 10.17487/RFC7230, June 2014, | |||
| <http://www.rfc-editor.org/info/rfc7230>. | <http://www.rfc-editor.org/info/rfc7230>. | |||
| [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, | ||||
| DOI 10.17487/RFC7493, March 2015, | ||||
| <http://www.rfc-editor.org/info/rfc7493>. | ||||
| [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, | |||
| "Recommendations for Secure Use of Transport Layer | "Recommendations for Secure Use of Transport Layer | |||
| Security (TLS) and Datagram Transport Layer Security | Security (TLS) and Datagram Transport Layer Security | |||
| (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May | |||
| 2015, <http://www.rfc-editor.org/info/rfc7525>. | 2015, <http://www.rfc-editor.org/info/rfc7525>. | |||
| 11.2. Informative References | 11.2. Informative References | |||
| [I-D.ietf-cdni-control-triggers] | [I-D.ietf-cdni-control-triggers] | |||
| Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | Murray, R. and B. Niven-Jenkins, "CDNI Control Interface / | |||
| Triggers", draft-ietf-cdni-control-triggers-12 (work in | Triggers", draft-ietf-cdni-control-triggers-15 (work in | |||
| progress), March 2016. | progress), May 2016. | |||
| [I-D.ietf-cdni-redirection] | [I-D.ietf-cdni-redirection] | |||
| Niven-Jenkins, B. and R. Brandenburg, "Request Routing | Niven-Jenkins, B. and R. Brandenburg, "Request Routing | |||
| Redirection interface for CDN Interconnection", draft- | Redirection interface for CDN Interconnection", draft- | |||
| ietf-cdni-redirection-17 (work in progress), February | ietf-cdni-redirection-20 (work in progress), August 2016. | |||
| [I-D.ietf-cdni-uri-signing] | ||||
| Leung, K., Faucheur, F., Brandenburg, R., Downey, B., and | ||||
| M. Fisher, "URI Signing for CDN Interconnection (CDNI)", | ||||
| draft-ietf-cdni-uri-signing-09 (work in progress), June | ||||
| 2016. | 2016. | |||
| [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, | |||
| DOI 10.17487/RFC2818, May 2000, | DOI 10.17487/RFC2818, May 2000, | |||
| <http://www.rfc-editor.org/info/rfc2818>. | <http://www.rfc-editor.org/info/rfc2818>. | |||
| [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet | ||||
| Autonomous System (AS) Number Space", RFC 6793, | ||||
| DOI 10.17487/RFC6793, December 2012, | ||||
| <http://www.rfc-editor.org/info/rfc6793>. | ||||
| [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, | ||||
| Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", | ||||
| RFC 7234, DOI 10.17487/RFC7234, June 2014, | ||||
| <http://www.rfc-editor.org/info/rfc7234>. | ||||
| [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., | [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., | |||
| "Framework for Content Distribution Network | "Framework for Content Distribution Network | |||
| Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, | Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, | |||
| August 2014, <http://www.rfc-editor.org/info/rfc7336>. | August 2014, <http://www.rfc-editor.org/info/rfc7336>. | |||
| [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution | [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution | |||
| Network Interconnection (CDNI) Requirements", RFC 7337, | Network Interconnection (CDNI) Requirements", RFC 7337, | |||
| DOI 10.17487/RFC7337, August 2014, | DOI 10.17487/RFC7337, August 2014, | |||
| <http://www.rfc-editor.org/info/rfc7337>. | <http://www.rfc-editor.org/info/rfc7337>. | |||
| [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, | ||||
| DOI 10.17487/RFC7493, March 2015, | ||||
| <http://www.rfc-editor.org/info/rfc7493>. | ||||
| [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
| Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | |||
| DOI 10.17487/RFC7540, May 2015, | DOI 10.17487/RFC7540, May 2015, | |||
| <http://www.rfc-editor.org/info/rfc7540>. | <http://www.rfc-editor.org/info/rfc7540>. | |||
| [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) | [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) | |||
| Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, | Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, | |||
| December 2015, <http://www.rfc-editor.org/info/rfc7736>. | December 2015, <http://www.rfc-editor.org/info/rfc7736>. | |||
| Authors' Addresses | Authors' Addresses | |||
| End of changes. 159 change blocks. | ||||
| 405 lines changed or deleted | 507 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||