draft-ietf-cdni-footprint-capabilities-semantics-04.txt   draft-ietf-cdni-footprint-capabilities-semantics-05.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: April 30, 2015 Neustar Expires: September 4, 2015 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
October 27, 2014 March 3, 2015
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-04 draft-ietf-cdni-footprint-capabilities-semantics-05
Abstract Abstract
This document tries to capture the semantics of the "Footprint and This document tries to capture 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 and what "Footprint and interface, i.e., the desired meaning of "Footprint" and
Capabilities Advertisement" is expected to offer within CDNI. The "Capabilities" in the CDNI context, and what the "Footprint and
discussion in this document has the goal to facilitate the choosing Capabilities Advertisement Interface (FCI)" is expected to offer
of one or more suitable protocols for "Footprint and Capabilities within CDNI. The document also provides guidelines for a CDNI FCI
Advertisement" within CDNI Request Routing. protocol. It further defines a Base Advertisement Object, the
necessary registries for capabilities and footprints, and guidelines
how these registries may be extended in the future.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 48 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 September 4, 2015.
This Internet-Draft will expire on April 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 37 skipping to change at page 2, line 38
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7 2.5. Focusing on Main Use Cases . . . . . . . . . . . . . . . 7
3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8 3. Main Use Case to Consider . . . . . . . . . . . . . . . . . . 8
4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8 4. Semantics for Footprint Advertisement . . . . . . . . . . . . 8
5. Semantics for Capabilities Advertisement . . . . . . . . . . 11 5. Semantics for Capabilities Advertisement . . . . . . . . . . 11
6. Negotiation of Support for Optional Types of 6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 14 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 14
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Redirection Mode Advertisement Object . . . . . . . . . . 15 7.2. Redirection Mode Advertisement Object . . . . . . . . . . 15
7.3. Advertisement Object Serialization . . . . . . . . . . . 15 7.3. Example of Advertisement Object Serialization . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. Capabilities Registry . . . . . . . . . . . . . . . . . . 16 8.1. Capabilities Registry . . . . . . . . . . . . . . . . . . 16
8.2. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 16 8.2. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 16
8.3. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 17 8.3. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 17
8.4. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 17 8.4. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 17
8.5. Logging Record Type Sub-Registry . . . . . . . . . . . . 17 8.5. Logging Record Type Sub-Registry . . . . . . . . . . . . 17
8.6. Logging Field Name Sub-Registry . . . . . . . . . . . . . 17 8.6. Logging Field Name Sub-Registry . . . . . . . . . . . . . 17
8.7. Metadata Type Sub-Registry . . . . . . . . . . . . . . . 17 8.7. Metadata Type Sub-Registry . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
skipping to change at page 3, line 13 skipping to change at page 3, line 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
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 to a CDN federation. This CDN- interconnection of multiple CDNs to a CDN federation. This CDN-
federation should serve multiple purposes, as discussed in [RFC6770], federation should serve multiple purposes, as discussed in [RFC6770],
for instance, to extend the reach of a given CDN to areas in the for instance, to extend the reach of a given CDN to areas in the
network which are not covered by this particular CDN. network which are not covered by this particular CDN.
The goal of this document is to achieve a clear understanding in the The goal of this document is to achieve a clear understanding about
CDNI WG about the semantics associated with the CDNI Request Routing the semantics associated with the CDNI Request Routing Footprint &
Footprint & Capabilities Advertisement Interface (from now on Capabilities Advertisement Interface (from now on referred to as
referred to as FCI), in particular the type of information a FCI), in particular the type of information a downstream CDN
downstream CDN 'advertises' regarding its footprint and capabilities. 'advertises' regarding its footprint and capabilities. To narrow
To narrow down undecided aspects of these semantics, this document down undecided aspects of these semantics, this document tries to
tries to establish a common understanding of what the FCI should establish a common understanding of what the FCI should offer and
offer and accomplish in the context of CDN Interconnection. accomplish in the context of CDN Interconnection.
It is explicitly outside the scope of this document to decide on It is explicitly outside the scope of this document to decide on
specific protocols to use for the FCI. specific protocols to use for the FCI. However, guidelines for such
FCI protocols are provided.
General assumptions in this document: General assumptions in this document:
o The CDNs participating in the CDN federation have already o The CDNs participating in the CDN federation have already
performed a boot strap process, i.e., they have connected to each performed a boot strap process, i.e., they have connected to each
other, either directly or indirectly, and can exchange information other, either directly or indirectly, and can exchange information
amongst each other. amongst each other.
o The uCDN has received footprint and/or capability advertisements o The uCDN has received footprint and/or capability advertisements
from a set of dCDNs. Footprint advertisement and capability from a set of dCDNs. Footprint advertisement and capability
skipping to change at page 3, line 49 skipping to change at page 4, line 4
The CDNI Problem Statement [RFC6707] describes footprint and The CDNI Problem Statement [RFC6707] describes footprint and
capabilities advertisement as: "[enabling] a Request Routing function capabilities advertisement as: "[enabling] a Request Routing function
in an Upstream CDN to query a Request Routing function in a in an Upstream CDN to query a Request Routing function in a
Downstream CDN to determine if the Downstream CDN is able (and Downstream CDN to determine if the Downstream CDN is able (and
willing) to accept the delegated Content Request". In addition, the willing) to accept the delegated Content Request". In addition, the
RFC says "the CDNI Request Routing interface is also expected to RFC says "the CDNI Request Routing interface is also expected to
enable a downstream CDN to provide to the upstream CDN (static or enable a downstream CDN to provide to the upstream CDN (static or
dynamic) information (e.g., resources, footprint, load) to facilitate dynamic) information (e.g., resources, footprint, load) to facilitate
selection of the downstream CDN by the upstream CDN request routing selection of the downstream CDN by the upstream CDN request routing
system when processing subsequent content requests from User Agents". system when processing subsequent content requests from User Agents".
It thus considers "resources" and "load" as capabilities to be It thus considers "resources" and "load" as capabilities to be
advertised by the downstream CDN. advertised by the downstream CDN.
The range of different footprint definitions and possible The range of different footprint definitions and possible
capabilities is very broad. Attempting to define a comprehensive capabilities is very broad. Attempting to define a comprehensive
advertisement solution quickly becomes intractable. The CDNI advertisement solution quickly becomes intractable. The CDNI
requirements draft [I-D.ietf-cdni-requirements] lists the specific requirements draft [RFC7337] lists the specific requirements for the
requirements for the CDNI Footprint & Capabilities Advertisement CDNI Footprint & Capabilities Advertisement Interface in order to
Interface in order to disambiguate footprints and capabilities with disambiguate footprints and capabilities with respect to CDNI. This
respect to CDNI. This document attempts to distill the apparent document attempts to distill the apparent common understanding of
common understanding of what the terms 'footprint' and 'capabilities' what the terms 'footprint' and 'capabilities' mean in the context of
mean in the context of CDNI, and detail the semantics of the CDNI, and detail the semantics of the footprint advertisement
footprint advertisement mechanism and the capability advertisement mechanism and the capability advertisement mechanism.
mechanism.
2. Design Decisions for Footprint and Capabilities 2. Design Decisions for Footprint and Capabilities
A large part of the difficulty in discussing the FCI lies in A large part of the difficulty in discussing the FCI lies in
understanding what exactly is meant when trying to define footprint understanding what exactly is meant when trying to define footprint
in terms of "coverage" or "reachability." While the operators of in terms of "coverage" or "reachability." While the operators of
CDNs pick strategic locations to situate caches, a cache with a CDNs pick strategic locations to situate caches, a cache with a
public IPv4 address is reachable by any endpoint on the Internet public IPv4 address is reachable by any endpoint on the Internet
unless some policy enforcement precludes the use of the cache. unless some policy enforcement precludes the use of the cache.
skipping to change at page 6, line 45 skipping to change at page 6, line 47
CDNI WG scope, such direct selection of specific caches by the uCDN CDNI WG scope, such direct selection of specific caches by the uCDN
is out of scope). However, when the uCDN must deal with many is out of scope). However, when the uCDN must deal with many
potential dCDNs, this approach does not scale. Especially as CDNs potential dCDNs, this approach does not scale. Especially as CDNs
scale up from dozens or hundreds of caches to thousands or tens of scale up from dozens or hundreds of caches to thousands or tens of
thousands, the volume of updates to footprint and capability may thousands, the volume of updates to footprint and capability may
become onerous. become onerous.
Were the volume of updates to exceed the volumes of requests to the Were the volume of updates to exceed the volumes of requests to the
uCDN, it might make more sense for the uCDN to query dCDNs upon uCDN, it might make more sense for the uCDN to query dCDNs upon
receiving requests (as is the case in the recursive redirection mode receiving requests (as is the case in the recursive redirection mode
described in [I-D.ietf-cdni-framework]), instead of receiving described in [RFC7336]), instead of receiving advertisements and
advertisements and tracking the state of dCDNs itself. The advantage tracking the state of dCDNs itself. The advantage of querying dCDNs
of querying dCDNs would be that much of the dynamic data that dCDNs would be that much of the dynamic data that dCDNs cannot share with
cannot share with the uCDN would now be factored into the uCDN's the uCDN would now be factored into the uCDN's decision. dCDNs need
decision. dCDNs need not replicate any state to the uCDN - uCDNs not replicate any state to the uCDN - uCDNs could effectively operate
could effectively operate in a stateless mode. in a stateless mode.
The semantics of both footprint and capability advertisement depend The semantics of both footprint and capability advertisement depend
on the service model here: are there cases where a synchronous query/ on the service model here: are there cases where a synchronous query/
response model would work better for the uCDN decision than a state response model would work better for the uCDN decision than a state
replication model? replication model?
2.4. Avoiding or Handling 'cheating' dCDNs 2.4. Avoiding or Handling 'cheating' dCDNs
In a situation where more than one dCDN is willing to serve a given In a situation where more than one dCDN is willing to serve a given
end user request, it might be attractive for a dCDN to 'cheat' in the end user request, it might be attractive for a dCDN to 'cheat' in the
skipping to change at page 10, line 49 skipping to change at page 10, line 49
the request routing source. The CDNI specifications do not define the request routing source. The CDNI specifications do not define
how a given uCDN determines the country of the request routing how a given uCDN determines the country of the request routing
source. Multiple footprint constraints are additive, i.e., the source. Multiple footprint constraints are additive, i.e., the
advertisement of different types of footprint narrows the dCDN advertisement of different types of footprint narrows the dCDN
candidacy cumulatively. candidacy cumulatively.
In addition to these mandatory "coverage/reachability" types of In addition to these mandatory "coverage/reachability" types of
footprint, other optional "coverage/reachability" types of footprint footprint, other optional "coverage/reachability" types of footprint
or "resource" types of footprint may defined by future or "resource" types of footprint may 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 a IANA registry must be specified. This optional footprint types in a IANA registry is specified in
includes the specification of the level of oversight necessary (e.g., Section 8. This includes the specification of the level of oversight
WG decision or expert review) for adding new optional footprints to a necessary (e.g., WG decision or expert review) for adding new
IANA registry as well as the specification of a template regarding optional footprints to a IANA registry as well as the specification
design choices that must be captured by new optional types of of a template regarding design choices that must be captured by new
footprints. optional types of footprints.
Independent of the exact type of a footprint, a footprint might also Independent of the exact type of a footprint, a footprint might also
include the connectivity of a given dCDN to other CDNs that may be include the connectivity of a given dCDN to other CDNs that may be
able to serve content to users on behalf of that dCDN, to cover cases able to serve content to users on behalf of that dCDN, to cover cases
where there is a transitive CDN interconnection. Further, the where there is a transitive CDN interconnection. Further, the
downstream CDN must be able to express its footprint to an interested downstream CDN must be able to express its footprint to an interested
upstream CDN (uCDN) in a comprehensive form, e.g., as a data set upstream CDN (uCDN) in a comprehensive form, e.g., as a data set
containing the complete footprint. Making incremental updates, containing the complete footprint. Making incremental updates,
however, to express dynamic changes in state is also desirable. however, to express dynamic changes in state is also desirable.
skipping to change at page 12, line 52 skipping to change at page 12, line 52
Under the above considerations, the following capabilities seem Under the above considerations, the following capabilities seem
useful as 'base' capabilities, i.e., ones that are needed in any case useful as 'base' capabilities, i.e., ones that are needed in any case
and therefore constitute mandatory capabilities to be supported by and therefore constitute mandatory capabilities to be supported by
the CDNI FCI: the CDNI FCI:
o Delivery Protocol (e.g., HTTP vs. RTMP) o Delivery Protocol (e.g., HTTP vs. RTMP)
o Acquisition Protocol (for aquiring content from a uCDN) o Acquisition Protocol (for aquiring content from a uCDN)
o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as o Redirection Mode (e.g., DNS Redirection vs. HTTP Redirection as
discussed in [I-D.ietf-cdni-framework]) 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 GenericMetadata types) o CDNI Metadata (i.e., supported Generic Metadata types)
It is not feasable to enumerate all the possible options for the It is not feasable to enumerate all the possible options for the
mandatory capabilities listed above (e.g., all the potential delivery mandatory capabilities listed above (e.g., all the potential delivery
protocols or metadata options) or anticipate all the future needs for protocols or metadata options) or anticipate all the future needs for
additional capabilities. It would be unreasonable to burden the CDNI additional capabilities. It would be unreasonable to burden the CDNI
FCI specification with defining each supported capability. Instead, FCI specification with defining each supported capability. Instead,
the CDNI FCI specification should define a generic protocol for the CDNI FCI specification should define a generic protocol for
conveying any capability information. In this respect, it seems conveying any capability information (e.g. with common encoding,
reasonable to define a registry which initially contains the error handling, and security mechanism; further requirements for the
mandatory capabilities listed above, but may be extended as needs CDNI FCI Advertisement Interface are listed in [RFC7337]). In this
dictate. This document defines the registry (and the rules for respect, it seems reasonable to define a registry which initially
adding new entries to the registry) for the different capability contains the mandatory capabilities listed above, but may be extended
as needs dictate. This document defines the registry (and the rules
for adding new entries to the registry) for the different capability
types (see Section 8). Each capability type MAY have a list of valid types (see Section 8). Each capability type MAY have a list of valid
values. The individual CDNI interface specifications which define a values. Future specifications which define a given capability SHOULD
given capability SHOULD define any necessary registries (and the define any necessary registries (and the rules for adding new entries
rules for adding new entries to the registry) for the values to the registry) for the values advertised for a given capability
advertised for a given capability type. type.
The "CDNI Logging Fields Names" registry defines all supported The "CDNI Logging Fields Names" registry defines all supported
logging fields, including mandatory-to-implement logging fields. logging fields, including mandatory-to-implement logging fields.
Advertisement of support for mandatory-to-implement logging fields Advertisement of support for mandatory-to-implement logging fields
SHOULD be supported but would be redundant. CDNs SHOULD NOT SHOULD be supported but would be redundant. CDNs SHOULD NOT
advertise support for mandatory-to-implement logging fields. The advertise support for mandatory-to-implement logging fields. The
following logging fields are defined as optional in the CDNI Logging following logging fields are defined as optional in the CDNI Logging
Interface document [I-D.ietf-cdni-logging]: Interface document [I-D.ietf-cdni-logging]:
o c-ip-anonimizing o c-ip-anonimizing
skipping to change at page 14, line 32 skipping to change at page 14, line 32
on the remaining capabilities/footprint information that is being on the remaining capabilities/footprint information that is being
conveyed by the dCDN. conveyed by the dCDN.
7. Capability Advertisement Object 7. 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.
[Ed. Note: MI/LI object definitions will build off the base object Future object definitions (e.g. regarding CDNI Metadata or Logging)
defined here, but will be specified in a separate draft.] will build off the base object defined here, but will be specified in
separate documents.
7.1. Base Advertisement Object 7.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 (see Section 8.1) in an opaque manner. capabilities (see Section 8.1) in an opaque manner.
Property: capability-type Property: capability-type
Description: CDNI Capability object type. Description: CDNI Capability object type.
Type: MIME Type String (from Section 8) Type: MIME Type String (from Section 8)
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: capabilitiy-value Property: capability-value
Description: CDNI Capability object. Description: CDNI Capability object.
Type: Format/Type is defined by the value of capability-type Type: Format/Type is defined by the value of capability-type
property above. property above.
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
7.2. Redirection Mode Advertisement Object 7.2. Redirection Mode Advertisement Object
skipping to change at page 15, line 24 skipping to change at page 15, line 24
Redirection Modes registry (see Section 8.4). Redirection Modes registry (see Section 8.4).
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 8.4) Type: List of Redirection Modes (from Section 8.4)
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
[Ed. Note: Redirection Mode is not in MI/LI; it is FCI specific. We Redirection Mode is not contained in the CDNI Metadata or Logging
define it here as an example for the MI/LI FCI drafts.] specifications; it is FCI specific. It is defined here as an example
for future specifications that define further CDNI FCI objects.
7.3. Advertisement Object Serialization 7.3. Example of Advertisement Object Serialization
The following shows an example of CDNI FCI Advertisement Object
Serialization for two supported redirection modes and one supported
logging capability.
{ {
"capabilities": [ "capabilities": [
{ {
"capability-type": "application/cdni.FCI.RedirectionMode.v1" "capability-type": "application/cdni.FCI.RedirectionMode.v1"
"capability-value": { "capability-value": {
"redirection-modes": [ "redirection-modes": [
"DNS-I", "DNS-I",
"HTTP-I" "HTTP-I"
] ]
skipping to change at page 15, line 49 skipping to change at page 16, line 5
}, },
{ {
"capability-type": "application/cdni.FCI.LI.s-ccid.v1" "capability-type": "application/cdni.FCI.LI.s-ccid.v1"
"capability-value": { "capability-value": {
"s-ccid-support": true "s-ccid-support": true
} }
} }
] ]
} }
[Ed. Note: Need to add JSON serialization discussion.]
8. IANA Considerations 8. IANA Considerations
This document requests the registration of the following MIME Media This document requests the registration of the following MIME Media
Type under the IANA MIME Media Type registry Type under the IANA MIME Media Type registry
(http://www.iana.org/assignments/media-types/index.html). (http://www.iana.org/assignments/media-types/index.html).
application/cdni.FCI.RedirectionMode.v1 application/cdni.FCI.RedirectionMode.v1
8.1. Capabilities Registry 8.1. Capabilities Registry
skipping to change at page 19, line 17 skipping to change at page 19, line 17
May 2008. May 2008.
[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, September 2012. Statement", RFC 6707, September 2012.
[RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma, [RFC6770] Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
K., and G. Watson, "Use Cases for Content Delivery Network K., and G. Watson, "Use Cases for Content Delivery Network
Interconnection", RFC 6770, November 2012. Interconnection", RFC 6770, November 2012.
10.2. Informative References [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014.
[I-D.ietf-cdni-framework] [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Peterson, L., Davie, B., and R. Brandenburg, "Framework Interconnection (CDNI) Requirements", RFC 7337, August
for CDN Interconnection", draft-ietf-cdni-framework-14 2014.
(work in progress), June 2014.
10.2. Informative 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-14 (work in progress), October 2014. logging-15 (work in progress), February 2015.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
and K. Ma, "CDN Interconnection Metadata", draft-ietf- "CDN Interconnection Metadata", draft-ietf-cdni-
cdni-metadata-07 (work in progress), July 2014. metadata-08 (work in progress), October 2014.
[I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-17 (work in progress), January 2014.
Appendix A. Acknowledgment Appendix A. Acknowledgment
Jan Seedorf is partially supported by the GreenICN project (GreenICN: Jan Seedorf is partially supported by the GreenICN project (GreenICN:
Architecture and Applications of Green Information Centric Architecture and Applications of Green Information Centric
Networking), a research project supported jointly by the European Networking), a research project supported jointly by the European
Commission under its 7th Framework Program (contract no. 608518) and Commission under its 7th Framework Program (contract no. 608518) and
the National Institute of Information and Communications Technology the National Institute of Information and Communications Technology
(NICT) in Japan (contract no. 167). The views and conclusions (NICT) in Japan (contract no. 167). The views and conclusions
contained herein are those of the authors and should not be contained herein are those of the authors and should not be
 End of changes. 26 change blocks. 
74 lines changed or deleted 80 lines changed or added

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