draft-ietf-cdni-footprint-capabilities-semantics-17.txt   draft-ietf-cdni-footprint-capabilities-semantics-18.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Standards Track J. Peterson Intended status: Standards Track J. Peterson
Expires: October 24, 2016 Neustar Expires: October 30, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
April 22, 2016 April 28, 2016
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-17 draft-ietf-cdni-footprint-capabilities-semantics-18
Abstract Abstract
This document captures the semantics of the "Footprint and This document captures the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e., the desired meaning of "Footprint" and interface, i.e., the desired meaning of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and "Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" offers within CDNI. The Capabilities Advertisement Interface (FCI)" offers within CDNI. The
document also provides guidelines for the CDNI FCI protocol. It document also provides guidelines for the CDNI FCI protocol. It
further defines a Base Advertisement Object, the necessary registries further defines a Base Advertisement Object, the necessary registries
skipping to change at page 2, line 4 skipping to change at page 2, line 4
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 24, 2016. This Internet-Draft will expire on October 30, 2016.
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 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Design Decisions for Footprint and Capabilities . . . . . . . 5 2. Design Decisions for Footprint and Capabilities . . . . . . . 5
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 5 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 5
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 6 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 6
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 7
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focusing on Capabilities with Footprint Restrictions . . 8 3. Focusing on Capabilities with Footprint Restrictions . . . . 8
3. Footprint and Capabilities Extension . . . . . . . . . . . . 8 4. Footprint and Capabilities Extension . . . . . . . . . . . . 8
4. Capability Advertisement Object . . . . . . . . . . . . . . . 10 5. Capability Advertisement Object . . . . . . . . . . . . . . . 10
4.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10 5.1. Base Advertisement Object . . . . . . . . . . . . . . . . 10
4.2. Delivery Protocol Capability Object . . . . . . . . . . . 11 5.2. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.1. Delivery Protocol Capability Object Serialization . . 11 5.3. Delivery Protocol Capability Object . . . . . . . . . . . 11
4.3. Acquisition Protocol Capability Object . . . . . . . . . 12 5.3.1. Delivery Protocol Capability Object Serialization . . 12
4.3.1. Acquisition Protocol Capability Object Serialization 12 5.4. Acquisition Protocol Capability Object . . . . . . . . . 12
4.4. Redirection Mode Capability Object . . . . . . . . . . . 13 5.4.1. Acquisition Protocol Capability Object Serialization 12
4.4.1. Redirection Mode Capability Object Serialization . . 13 5.5. Redirection Mode Capability Object . . . . . . . . . . . 13
4.5. CDNI Logging Capability Object . . . . . . . . . . . . . 14 5.5.1. Redirection Mode Capability Object Serialization . . 13
4.5.1. CDNI Logging Capability Object Serialization . . . . 15 5.6. CDNI Logging Capability Object . . . . . . . . . . . . . 14
4.6. CDNI Metadata Capability Object . . . . . . . . . . . . . 15 5.6.1. CDNI Logging Capability Object Serialization . . . . 15
4.6.1. CDNI Metadata Capability Object Serialization . . . . 16 5.7. CDNI Metadata Capability Object . . . . . . . . . . . . . 15
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 5.7.1. CDNI Metadata Capability Object Serialization . . . . 16
5.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
5.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 6.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 17
5.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18 6.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
5.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18 6.1.2. CDNI FCI AcquisitionProtocol Payload Type . . . . . . 18
5.1.4. CDNI FCI Logging Payload Type . . . . . . . . . . . . 18 6.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 18
5.1.5. CDNI FCI Metadata Payload Type . . . . . . . . . . . 18 6.1.4. CDNI FCI Logging Payload Type . . . . . . . . . . . . 18
5.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18 6.1.5. CDNI FCI Metadata Payload Type . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 6.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
7.1. Normative References . . . . . . . . . . . . . . . . . . 20 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . 21 8.1. Normative References . . . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . 20
Appendix A. Main Use Case to Consider . . . . . . . . . . . . . 21 Appendix A. Main Use Case to Consider . . . . . . . . . . . . . 21
Appendix B. Semantics for Footprint Advertisement . . . . . . . 22 Appendix B. Semantics for Footprint Advertisement . . . . . . . 22
Appendix C. Semantics for Capabilities Advertisement . . . . . . 24 Appendix C. Semantics for Capabilities Advertisement . . . . . . 24
Appendix D. Acknowledgment . . . . . . . . . . . . . . . . . . . 25 Appendix D. Acknowledgment . . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction and Scope 1. Introduction and Scope
The CDNI working group is working on a set of protocols to enable the The CDNI working group is working on a set of protocols to enable the
interconnection of multiple CDNs. This CDN interconnection (CDNI) interconnection of multiple CDNs. This CDN interconnection (CDNI)
skipping to change at page 8, line 17 skipping to change at page 8, line 19
Overall, the information a dCDN advertises (in the long run) needs to Overall, the information a dCDN advertises (in the long run) needs to
be somehow qualitatively verifiable by the uCDN, though possibly be somehow qualitatively verifiable by the uCDN, though possibly
through non-real-time out-of-band audits. It is probably an overly through non-real-time out-of-band audits. It is probably an overly
strict requirement to mandate that such verification be possible strict requirement to mandate that such verification be possible
"immediately", i.e., during the request routing process itself. If "immediately", i.e., during the request routing process itself. If
the uCDN can detect a cheating dCDN at a later stage, it might the uCDN can detect a cheating dCDN at a later stage, it might
suffice for the uCDN to "de-incentivize" cheating because it would suffice for the uCDN to "de-incentivize" cheating because it would
negatively affect the long-term business relationship with a negatively affect the long-term business relationship with a
particular dCDN. particular dCDN.
2.5. Focusing on Capabilities with Footprint Restrictions 3. Focusing on Capabilities with Footprint Restrictions
It seems reasonable to assume that in most use cases it is the uCDN Given the design considerations listed in the previous section, it
that makes the decision on selecting a certain dCDN for request seems reasonable to assume that in most cases it is the uCDN that
routing based on information the uCDN has received from this makes the decision on selecting a certain dCDN for request routing
particular dCDN. It can be assumed that 'cheating' CDNs will be based on information the uCDN has received from this particular dCDN.
dealt with via means outside the scope of CDNI and that the It can be assumed that 'cheating' CDNs will be dealt with via means
information advertised between CDNs is accurate. In addition, outside the scope of CDNI and that the information advertised between
excluding the use of qualitative information (e.g., cache proximity, CDNs is accurate. In addition, excluding the use of qualitative
delivery latency, cache load) to predict the quality of delivery information (e.g., cache proximity, delivery latency, cache load) to
would further simplify the use case allowing it to better focus on predict the quality of delivery would further simplify the use case
the basic functionality of the FCI. allowing it to better focus on the basic functionality of the FCI.
Further understanding that in most cases contractual agreements will Further understanding that in most cases contractual agreements will
define the basic coverage used in delegation decisions, the primary define the basic coverage used in delegation decisions, the primary
focus of FCI is on providing updates to the basic capabilities and focus of FCI is on providing updates to the basic capabilities and
coverage by the dCDNs. As such, FCI has choosen the semantics of coverage by the dCDNs. As such, FCI has choosen the semantics of
"capabilities with footprint restrictions". "capabilities with footprint restrictions".
3. Footprint and Capabilities Extension 4. Footprint and Capabilities Extension
Other optional "coverage/reachability" types of footprint or Other optional "coverage/reachability" types of footprint or
"resource" types of footprint may be defined by future "resource" types of footprint may be defined by future
specifications. To facilitate this, a clear process for specifying specifications. To facilitate this, a clear process for specifying
optional footprint types in an IANA registry is specified in the CDNI optional footprint types in an IANA registry is specified in the CDNI
Metadata Footprint Types registry (defined in the CDNI Metadata Metadata Footprint Types registry (defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata]). Interface document [I-D.ietf-cdni-metadata]).
This document also registers CDNI Payload Types [RFC7736] for the This document also registers CDNI Payload Types [RFC7736] for the
initial capability types (see Section 5): initial capability types (see Section 6):
o Delivery Protocol (for delivering content to the end user) o Delivery Protocol (for delivering content to the end user)
o Acquisition Protocol (for acquiring content from the uCDN or o Acquisition Protocol (for acquiring content from the uCDN or
origin server) origin server)
o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [RFC7336]) discussed in [RFC7336])
o CDNI Logging (i.e., supported logging fields) o CDNI Logging (i.e., supported logging fields)
o CDNI Metadata (i.e., supported Generic Metadata types) o CDNI Metadata (i.e., supported Generic Metadata types)
skipping to change at page 10, line 23 skipping to change at page 10, line 25
In general, a uCDN MAY ignore capabilities or types of footprints it In general, a uCDN MAY ignore capabilities or types of footprints it
does not understand; in this case it only selects a suitable dCDN does not understand; in this case it only selects a suitable dCDN
based on the types of capabilities and footprint it understands. based on the types of capabilities and footprint it understands.
Similarly, if a dCDN does not use an optional capability or footprint Similarly, if a dCDN does not use an optional capability or footprint
which is, however, supported by a uCDN, this causes no problem for which is, however, supported by a uCDN, this causes no problem for
the FCI functionality because the uCDN decides on the remaining the FCI functionality because the uCDN decides on the remaining
capabilities/footprint information that is being conveyed by the capabilities/footprint information that is being conveyed by the
dCDN. dCDN.
4. Capability Advertisement Object 5. Capability Advertisement Object
To support extensibility, the FCI defines a generic base object To support extensibility, the FCI defines a generic base object
(similar to the CDNI Metadata interface GenericMetadata object) (similar to the CDNI Metadata interface GenericMetadata object)
[I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory [I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory
parsing requirements for all future FCI objects. parsing requirements for all future FCI objects.
Future object definitions (e.g. regarding CDNI Metadata or Logging) Future object definitions (e.g. regarding CDNI Metadata or Logging)
will build off the base object defined here, but will be specified in will build off the base object defined here, but will be specified in
separate documents. separate documents.
4.1. Base Advertisement Object 5.1. Base Advertisement Object
The FCIBase object is an abstraction for managing individual CDNI The FCIBase object is an abstraction for managing individual CDNI
capabilities in an opaque manner. capabilities in an opaque manner.
Property: capability-type Property: capability-type
Description: CDNI Capability object type. Description: CDNI Capability object type.
Type: FCI specific CDNI Payload type (from the CDNI Payload Type: FCI specific CDNI Payload type (from the CDNI Payload
Types registry [RFC7736]) Types registry [RFC7736])
skipping to change at page 11, line 19 skipping to change at page 11, line 20
Property: footprints Property: footprints
Description: CDNI Capability Footprint. Description: CDNI Capability Footprint.
Type: List of CDNI Footprint objects (as defined in Type: List of CDNI Footprint objects (as defined in
[I-D.ietf-cdni-metadata]). [I-D.ietf-cdni-metadata]).
Mandatory-to-Specify: No. Mandatory-to-Specify: No.
4.2. Delivery Protocol Capability Object 5.2. Encoding
CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also
follow the recommendations of I-JSON [RFC7493]. FCI objects are
composed of a dictionary of (key,value) pairs where the keys are the
property names and the values are the associated property values.
The keys of the dictionary are the names of the properties associated
with the object and are therefore dependent on the specific object
being encoded (i.e., dependent on the CDNI Payload Type of the
capability or the CDNI Metadata Footprint Type of the footprint).
Likewise, the values associated with each property (dictionary key)
are dependent on the specific object being encoded (i.e., dependent
on the CDNI Payload Type of the capability or the CDNI Metadata
Footprint Type of the footprint).
Dictionary keys (properties) in JSON are case sensitive. By
convention, any dictionary key (property) defined by this document
MUST be lowercase.
5.3. Delivery Protocol Capability Object
The Delivery Protocol capability object is used to indicate support The Delivery Protocol capability object is used to indicate support
for one or more of the protocols listed in the CDNI Metadata Protocol for one or more of the protocols listed in the CDNI Metadata Protocol
Types registry (defined in the CDNI Metadata Interface document Types registry (defined in the CDNI Metadata Interface document
[I-D.ietf-cdni-metadata]). [I-D.ietf-cdni-metadata]).
Property: delivery-protocols Property: delivery-protocols
Description: List of supported CDNI Delivery Protocols. Description: List of supported CDNI Delivery Protocols.
Type: List of Protocol Types (from the CDNI Metadata Protocol Type: List of Protocol Types (from the CDNI Metadata Protocol
Types registry [I-D.ietf-cdni-metadata]) Types registry [I-D.ietf-cdni-metadata])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
4.2.1. Delivery Protocol Capability Object Serialization 5.3.1. Delivery Protocol Capability Object Serialization
The following shows an example of Delivery Protocol Capability Object The following shows an example of Delivery Protocol Capability Object
Serialization, for a CDN that supports only HTTP/1.1 without TLS for Serialization, for a CDN that supports only HTTP/1.1 without TLS for
content delivery. content delivery.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.DeliveryProtocol", "capability-type": "FCI.DeliveryProtocol",
"capability-value": { "capability-value": {
skipping to change at page 12, line 21 skipping to change at page 12, line 32
"http1.1", "http1.1",
] ]
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
4.3. Acquisition Protocol Capability Object 5.4. Acquisition Protocol Capability Object
The Acquisition Protocol capability object is used to indicate The Acquisition Protocol capability object is used to indicate
support for one or more of the protocols listed in the CDNI Metadata support for one or more of the protocols listed in the CDNI Metadata
Protocol Types registry (defined in the CDNI Metadata Interface Protocol Types registry (defined in the CDNI Metadata Interface
document [I-D.ietf-cdni-metadata]). document [I-D.ietf-cdni-metadata]).
Property: acquisition-protocols Property: acquisition-protocols
Description: List of supported CDNI Acquisition Protocols. Description: List of supported CDNI Acquisition Protocols.
Type: List of Protocol Types (from the CDNI Metadata Protocol Type: List of Protocol Types (from the CDNI Metadata Protocol
Types registry [I-D.ietf-cdni-metadata]) Types registry [I-D.ietf-cdni-metadata])
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
4.3.1. Acquisition Protocol Capability Object Serialization 5.4.1. Acquisition Protocol Capability Object Serialization
The following shows an example of Acquisition Protocol Capability The following shows an example of Acquisition Protocol Capability
Object Serialization, for a CDN that supports HTTP/1.1 with or Object Serialization, for a CDN that supports HTTP/1.1 with or
without TLS for content acquisition. without TLS for content acquisition.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.AcquisitionProtocol", "capability-type": "FCI.AcquisitionProtocol",
"capability-value": { "capability-value": {
skipping to change at page 13, line 22 skipping to change at page 13, line 22
"https1.1" "https1.1"
] ]
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
4.4. Redirection Mode Capability Object 5.5. Redirection Mode Capability Object
The Redirection Mode capability object is used to indicate support The Redirection Mode capability object is used to indicate support
for one or more of the modes listed in the CDNI Capabilities for one or more of the modes listed in the CDNI Capabilities
Redirection Modes registry (see Section 5.2). Redirection Modes registry (see Section 6.2).
Property: redirection-modes Property: redirection-modes
Description: List of supported CDNI Redirection Modes. Description: List of supported CDNI Redirection Modes.
Type: List of Redirection Modes (from Section 5.2) Type: List of Redirection Modes (from Section 6.2)
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
4.4.1. Redirection Mode Capability Object Serialization 5.5.1. Redirection Mode Capability Object Serialization
The following shows an example of Redirection Mode Capability Object The following shows an example of Redirection Mode Capability Object
Serialization, for a CDN that supports only iterative (but not Serialization, for a CDN that supports only iterative (but not
recursive) redirection with HTTP and DNS. recursive) redirection with HTTP and DNS.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.RedirectionMode", "capability-type": "FCI.RedirectionMode",
"capability-value": { "capability-value": {
skipping to change at page 14, line 22 skipping to change at page 14, line 22
"HTTP-I" "HTTP-I"
] ]
} }
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
4.5. CDNI Logging Capability Object 5.6. CDNI Logging Capability Object
The CDNI Logging capability object is used to indicate support for The CDNI Logging capability object is used to indicate support for
CDNI Logging record-types, as well as CDNI Logging fields which are CDNI Logging record-types, as well as CDNI Logging fields which are
marked as optional for the specified record-types marked as optional for the specified record-types
[I-D.ietf-cdni-logging]. [I-D.ietf-cdni-logging].
Property: record-type Property: record-type
Description: Supported CDNI Logging record-type. Description: Supported CDNI Logging record-type.
skipping to change at page 15, line 5 skipping to change at page 15, line 5
Type: List of Strings corresponding to entries from the CDNI Type: List of Strings corresponding to entries from the CDNI
Logging Field Names registry [I-D.ietf-cdni-logging]. Logging Field Names registry [I-D.ietf-cdni-logging].
Mandatory-to-Specify: No. Default is that all optional fields Mandatory-to-Specify: No. Default is that all optional fields
are supported. Inclusion of an empty list SHALL be understood are supported. Inclusion of an empty list SHALL be understood
to mean that none of the optional fields are supported. to mean that none of the optional fields are supported.
Otherwise, only those optional fields that are listed SHALL be Otherwise, only those optional fields that are listed SHALL be
understood to be supported. understood to be supported.
4.5.1. CDNI Logging Capability Object Serialization 5.6.1. CDNI Logging Capability Object Serialization
The following shows an example of CDNI Logging Capability Object The following shows an example of CDNI Logging Capability Object
Serialization, for a CDN that supports the optional Content Serialization, for a CDN that supports the optional Content
Collection ID logging field (but not the optional Session ID logging Collection ID logging field (but not the optional Session ID logging
field) for the "cdni_http_request_v1" record type. field) for the "cdni_http_request_v1" record type.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "FCI.Logging", "capability-type": "FCI.Logging",
skipping to change at page 15, line 45 skipping to change at page 15, line 45
"capability-value": { "capability-value": {
"record-type": "cdni_http_request_v1" "record-type": "cdni_http_request_v1"
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
4.6. CDNI Metadata Capability Object 5.7. CDNI Metadata Capability Object
The CDNI Metadata capability object is used to indicate support for The CDNI Metadata capability object is used to indicate support for
CDNI GenericMetadata types [I-D.ietf-cdni-metadata]. CDNI GenericMetadata types [I-D.ietf-cdni-metadata].
Property: metadata Property: metadata
Description: List of supported CDNI GenericMetadata types. Description: List of supported CDNI GenericMetadata types.
Type: List of Strings corresponding to entries from the CDNI Type: List of Strings corresponding to entries from the CDNI
Payload Type registry [RFC7736]) that correspond to CDNI Payload Type registry [RFC7736]) that correspond to CDNI
GenericMetadata objects. GenericMetadata objects.
Mandatory-to-Specify: Yes. It SHALL be understood that only Mandatory-to-Specify: Yes. It SHALL be understood that only
those GenericMetadata types listed are supported; an empty list those GenericMetadata types listed are supported; an empty list
SHALL be understood to mean that only structural metadata and SHALL be understood to mean that only structural metadata and
simple types are supported [I-D.ietf-cdni-metadata]. simple types are supported [I-D.ietf-cdni-metadata].
4.6.1. CDNI Metadata Capability Object Serialization 5.7.1. CDNI Metadata Capability Object Serialization
The following shows an example of CDNI Metadata Capability Object The following shows an example of CDNI Metadata Capability Object
Serialization, for a CDN that supports only the SourceMetadata Serialization, for a CDN that supports only the SourceMetadata
GenericMetadata type (i.e., it can acquire and deliver content, but GenericMetadata type (i.e., it can acquire and deliver content, but
cannot enforce and security policies, e.g., time, location, or cannot enforce and security policies, e.g., time, location, or
protocol ACLs). protocol ACLs).
{ {
"capabilities": [ "capabilities": [
{ {
skipping to change at page 17, line 19 skipping to change at page 17, line 19
"capability-value": { "capability-value": {
"metadata": [] "metadata": []
}, },
"footprints": [ "footprints": [
<Footprint objects> <Footprint objects>
] ]
} }
] ]
} }
5. IANA Considerations 6. IANA Considerations
5.1. CDNI Payload Types 6.1. CDNI Payload Types
This document requests the registration of the following CDNI Payload This document requests the registration of the following CDNI Payload
Types under the IANA CDNI Payload Type registry: Types under the IANA CDNI Payload Type registry:
+-------------------------+---------------+ +-------------------------+---------------+
| Payload Type | Specification | | Payload Type | Specification |
+-------------------------+---------------+ +-------------------------+---------------+
| FCI.DeliveryProtocol | RFCthis | | FCI.DeliveryProtocol | RFCthis |
| | | | | |
| FCI.AcquisitionProtocol | RFCthis | | FCI.AcquisitionProtocol | RFCthis |
skipping to change at page 17, line 43 skipping to change at page 17, line 43
| FCI.RedirectionMode | RFCthis | | FCI.RedirectionMode | RFCthis |
| | | | | |
| FCI.Logging | RFCthis | | FCI.Logging | RFCthis |
| | | | | |
| FCI.Metadata | RFCthis | | FCI.Metadata | 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.]
5.1.1. CDNI FCI DeliveryProtocol Payload Type 6.1.1. CDNI FCI DeliveryProtocol Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported delivery protocols advertisement objects for supported delivery protocols
Interface: FCI Interface: FCI
Encoding: see Section 4.2 Encoding: see Section 5.3
5.1.2. CDNI FCI AcquisitionProtocol Payload Type 6.1.2. CDNI FCI AcquisitionProtocol Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported acquisition protocols advertisement objects for supported acquisition protocols
Interface: FCI Interface: FCI
Encoding: see Section 4.3 Encoding: see Section 5.4
5.1.3. CDNI FCI RedirectionMode Payload Type 6.1.3. CDNI FCI RedirectionMode Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported redirection modes advertisement objects for supported redirection modes
Interface: FCI Interface: FCI
Encoding: see Section 4.4 Encoding: see Section 5.5
5.1.4. CDNI FCI Logging Payload Type 6.1.4. CDNI FCI Logging Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported CDNI Logging record-types and advertisement objects for supported CDNI Logging record-types and
optional CDNI Logging Field Names. optional CDNI Logging Field Names.
Interface: FCI Interface: FCI
Encoding: see Section 4.5 Encoding: see Section 5.6
5.1.5. CDNI FCI Metadata Payload Type 6.1.5. CDNI FCI Metadata Payload Type
Purpose: The purpose of this payload type is to distinguish FCI Purpose: The purpose of this payload type is to distinguish FCI
advertisement objects for supported CDNI GenericMetadata types. advertisement objects for supported CDNI GenericMetadata types.
Interface: FCI Interface: FCI
Encoding: see Section 4.6 Encoding: see Section 5.7
5.2. Redirection Mode Registry 6.2. Redirection Mode Registry
The IANA is requested to create a new "CDNI Capabilities Redirection The IANA is requested to create a new "CDNI Capabilities Redirection
Modes" registry in the "Content Delivery Networks Interconnection Modes" registry in the "Content Delivery Networks Interconnection
(CDNI) Parameters" category. The "CDNI Capabilities Redirection (CDNI) Parameters" category. The "CDNI Capabilities Redirection
Modes" namespace defines the valid redirection modes that can be Modes" namespace defines the valid redirection modes that can be
advertised as supported by a CDN. Additions to the Redirection Mode advertised as supported by a CDN. Additions to the Redirection Mode
namespace conform to the "IETF Review" policy as defined in namespace conform to the "IETF Review" policy as defined in
[RFC5226]. [RFC5226].
The following table defines the initial Redirection Modes: The following table defines the initial Redirection Modes:
skipping to change at page 19, line 20 skipping to change at page 19, line 20
| DNS-R | Recursive DNS-based Redirection | RFCthis | | DNS-R | Recursive DNS-based Redirection | RFCthis |
| | | | | | | |
| HTTP-I | Iterative HTTP-based Redirection | RFCthis | | HTTP-I | Iterative HTTP-based Redirection | RFCthis |
| | | | | | | |
| HTTP-R | Recursive HTTP-based Redirection | RFCthis | | HTTP-R | Recursive HTTP-based Redirection | 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.]
6. Security Considerations 7. Security Considerations
This specification describes the semantics for capabilities and This specification describes the semantics for capabilities and
footprint advertisement objects across interconnected CDNs. It does footprint advertisement objects across interconnected CDNs. It does
not, however, specify a concrete protocol for transporting those not, however, specify a concrete protocol for transporting those
objects. Specific security mechanisms can only be selected for objects. Specific security mechanisms can only be selected for
concrete protocols that instantiate these semantics. This document concrete protocols that instantiate these semantics. This document
does, however, place some high-level security constraints on such does, however, place some high-level security constraints on such
protocols. protocols.
All protocols that implement these semantics are REQUIRED to provide All protocols that implement these semantics are REQUIRED to provide
skipping to change at page 19, line 51 skipping to change at page 19, line 51
All protocols that implement these semantics are REQUIRED to provide All protocols that implement these semantics are REQUIRED to provide
confidentiality services. Some dCDNs are willing to share confidentiality services. Some dCDNs are willing to share
information about their footprint or capabilities with a uCDN but not information about their footprint or capabilities with a uCDN but not
with other, competing dCDNs. For example, if a dCDN incurs an outage with other, competing dCDNs. For example, if a dCDN incurs an outage
that reduces footprint coverage temporarily, that could be that reduces footprint coverage temporarily, that could be
information the dCDN would want to share confidentially with the information the dCDN would want to share confidentially with the
uCDN. uCDN.
As specified in this document, the security requirements of the FCI As specified in this document, the security requirements of the FCI
could be met by hop-by-hop transport-layer security mechanisms could be met by transport-layer security mechanisms coupled with
coupled with domain certificates as credentials (e.g., TLS transport domain certificates as credentials (e.g., TLS transport for HTTP as
for HTTP as per [RFC2818] and [RFC7230], with usage guidance from per [RFC2818] and [RFC7230], with usage guidance from [RFC7525])
[RFC7525]). There is no apparent need for further object-level between CDNs. There is no apparent need for further object-level
security in this framework, as the trust relationships it defines are security in this framework, as the trust relationships it defines are
bilateral relationships between uCDNs and dCDNs rather than bilateral relationships between uCDNs and dCDNs rather than
transitive relationships. transitive relationships.
7. References 8. References
7.1. Normative References 8.1. Normative References
[I-D.ietf-cdni-logging] [I-D.ietf-cdni-logging]
Faucheur, F., Bertrand, G., Oprescu, I., and R. Faucheur, F., Bertrand, G., Oprescu, I., and R.
Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni- Peterkofsky, "CDNI Logging Interface", draft-ietf-cdni-
logging-25 (work in progress), April 2016. logging-25 (work in progress), April 2016.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-15 (work in progress), April 2016. metadata-15 (work in progress), April 2016.
[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>.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Protocol (HTTP/1.1): Message Syntax and Routing", Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
RFC 7230, DOI 10.17487/RFC7230, June 2014, 2014, <http://www.rfc-editor.org/info/rfc7159>.
<http://www.rfc-editor.org/info/rfc7230>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
"Recommendations for Secure Use of Transport Layer "Framework for Content Distribution Network
Security (TLS) and Datagram Transport Layer Security Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May August 2014, <http://www.rfc-editor.org/info/rfc7336>.
2015, <http://www.rfc-editor.org/info/rfc7525>.
7.2. Informative References [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>.
8.2. Informative References
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
DOI 10.17487/RFC2818, May 2000,
<http://www.rfc-editor.org/info/rfc2818>.
[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>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, [RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
P., Ma, K., and G. Watson, "Use Cases for Content Delivery P., Ma, K., and G. Watson, "Use Cases for Content Delivery
Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
November 2012, <http://www.rfc-editor.org/info/rfc6770>. November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
"Framework for Content Distribution Network Protocol (HTTP/1.1): Message Syntax and Routing",
Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, RFC 7230, DOI 10.17487/RFC7230, June 2014,
August 2014, <http://www.rfc-editor.org/info/rfc7336>. <http://www.rfc-editor.org/info/rfc7230>.
[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>.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <http://www.rfc-editor.org/info/rfc7525>.
[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>.
Appendix A. Main Use Case to Consider Appendix A. Main Use Case to Consider
Focusing on a main use case that contains a simple (yet somewhat Focusing on a main use case that contains a simple (yet somewhat
challenging), realistic, and generally imaginable scenario can help challenging), realistic, and generally imaginable scenario can help
in narrowing down the requirements for the CDNI FCI. To this end, in narrowing down the requirements for the CDNI FCI. To this end,
the following (simplified) use case can help in clarifying the the following (simplified) use case can help in clarifying the
 End of changes. 48 change blocks. 
96 lines changed or deleted 124 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/