draft-ietf-cdni-footprint-capabilities-semantics-03.txt   draft-ietf-cdni-footprint-capabilities-semantics-04.txt 
CDNI J. Seedorf CDNI J. Seedorf
Internet-Draft NEC Internet-Draft NEC
Intended status: Informational J. Peterson Intended status: Informational J. Peterson
Expires: January 21, 2015 Neustar Expires: April 30, 2015 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
July 20, 2014 October 27, 2014
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-03 draft-ietf-cdni-footprint-capabilities-semantics-04
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 and what "Footprint and
Capabilities Advertisement" is expected to offer within CDNI. The Capabilities Advertisement" is expected to offer within CDNI. The
discussion in this document has the goal to facilitate the choosing discussion in this document has the goal to facilitate the choosing
of one or more suitable protocols for "Footprint and Capabilities of one or more suitable protocols for "Footprint and Capabilities
Advertisement" within CDNI Request Routing. Advertisement" within CDNI Request Routing.
skipping to change at page 1, line 49 skipping to change at page 1, line 49
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 January 21, 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) 2014 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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 3
2. Design Decisions for Footprint and Capabilities . . . . . . . 4 2. Design Decisions for Footprint and Capabilities . . . . . . . 4
2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4 2.1. Advertising Limited Coverage . . . . . . . . . . . . . . 4
2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5 2.2. Capabilities and Dynamic Data . . . . . . . . . . . . . . 5
2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6 2.3. Advertisement versus Queries . . . . . . . . . . . . . . 6
2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7 2.4. Avoiding or Handling 'cheating' dCDNs . . . . . . . . . . 7
2.5. Focus on Main Use Cases may Simplify Things . . . . . . . 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 . . . . . . . . . . 10 5. Semantics for Capabilities Advertisement . . . . . . . . . . 11
6. Negotiation of Support for Optional Types of 6. Negotiation of Support for Optional Types of
Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 14
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 15 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 15 7.2. Redirection Mode Advertisement Object . . . . . . . . . . 15
7.3. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 15 7.3. Advertisement Object Serialization . . . . . . . . . . . 15
7.4. Logging Field Sub-Registry . . . . . . . . . . . . . . . 15 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7.5. Metadata Type Sub-Registry . . . . . . . . . . . . . . . 15 8.1. Capabilities Registry . . . . . . . . . . . . . . . . . . 16
8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8.2. Footprint Sub-Registry . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. Protocol Sub-Registry . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . 16 8.4. Redirection Mode Sub-Registry . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . 16 8.5. Logging Record Type Sub-Registry . . . . . . . . . . . . 17
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 17 8.6. Logging Field Name Sub-Registry . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 8.7. Metadata Type Sub-Registry . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
10.1. Normative References . . . . . . . . . . . . . . . . . . 18
10.2. Informative References . . . . . . . . . . . . . . . . . 19
Appendix A. Acknowledgment . . . . . . . . . . . . . . . . . . . 19
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 in the
skipping to change at page 7, line 30 skipping to change at page 7, line 35
Overall, it seems that information a dCDN advertises should (in the Overall, it seems that information a dCDN advertises should (in the
long run) be somehow qualitatively verifiable by the uCDN, though long run) be somehow qualitatively verifiable by the uCDN, though
possibly through non-real-time out-of-band audits. It is probably an possibly through non-real-time out-of-band audits. It is probably an
overly strict requirement to mandate that such verification be overly strict requirement to mandate that such verification be
possible "immediately", i.e., during the request routing process possible "immediately", i.e., during the request routing process
itself. If the uCDN can detect a cheating dCDN at a later stage, it itself. If the uCDN can detect a cheating dCDN at a later stage, it
should suffice for the uCDN to "de-incentivize" cheating because it should suffice for the uCDN to "de-incentivize" cheating because it
would negatively affect the long-term business relationship with a would negatively affect the long-term business relationship with a
particular dCDN. particular dCDN.
2.5. Focus on Main Use Cases may Simplify Things 2.5. Focusing on Main Use Cases
To narrow down semantics for "footprint" and "capabilities" in the To narrow down semantics for "footprint" and "capabilities" in the
CDNI context, it can be useful to initially focus on key use cases to CDNI context, it can be useful to initially focus on key use cases to
be addressed by the CDNI WG that are to be envisioned the main be addressed by the CDNI WG that are to be envisioned the main
deployments in the foreseeable future. In this regard, a main deployments in the foreseeable future. In this regard, a main
realistic use case is the existence of ISP-owned CDNs, which realistic use case is the existence of ISP-owned CDNs, which
essentially cover a certain operator's network. At the same time, essentially cover a certain operator's network. At the same time,
however, the possibility of overlapping footprints should not be however, the possibility of overlapping footprints should not be
excluded, i.e., the scenario where more than one dCDN claims it can excluded, i.e., the scenario where more than one dCDN claims it can
serve a given end user request. The ISPs may also choose to federate serve a given end user request. The ISPs may also choose to federate
skipping to change at page 10, line 4 skipping to change at page 10, line 10
It seems clear that "coverage/reachability" types of footprint must It seems clear that "coverage/reachability" types of footprint must
be supported within CDNI. The following such types of footprint are be supported within CDNI. The following such types of footprint are
mandatory and must be supported by the CDNI FCI: mandatory and must be supported by the CDNI FCI:
o List of ISO Country Codes o List of ISO Country Codes
o List of AS numbers o List of AS numbers
o Set of IP-prefixes o Set of IP-prefixes
A 'set of IP-prefixes' must be able to contain full IP addresses, A 'set of IP-prefixes' must be able to contain full IP addresses,
i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes with i.e., a /32 for IPv4 and a /128 for IPv6, and also IP prefixes with
an arbitrary prefix length. There must also be support for multiple an arbitrary prefix length. There must also be support for multiple
IP address versions, i.e., IPv4 and IPv6, in such a footprint. IP address versions, i.e., IPv4 and IPv6, in such a footprint.
"Resource" types of footprints are more specific than "coverage/
reachability" types of footprints, where the actual coverage/
reachability are extrapolated from the resource location (e.g.,
netmask applied to resource IP address to derive IP-prefix). The
specific methods for extrapolating coverage/reachability from
resource location are beyond the scope of this document. In the
degenerate case, the resource address could be specified as a
coverage/reachability type of footprint, in which case no
extrapolation is necessary. Resource types of footprints may expose
the internal structure of a CDN network which may be undesirable. As
such, the resource types of footprints are not considered mandatory
to support for CDNI.
For all of these mandatory-to-implement footprint types, footprints For all of these mandatory-to-implement footprint types, footprints
can be viewed as constraints for delegating requests to a dCDN: A can be viewed as constraints for delegating requests to a dCDN: A
dCDN footprint advertisement tells the uCDN the limitations for dCDN footprint advertisement tells the uCDN the limitations for
delegating a request to the dCDN. For IP prefixes or ASN(s), the delegating a request to the dCDN. For IP prefixes or ASN(s), the
footprint signals to the uCDN that it should consider the dCDN a footprint signals to the uCDN that it should consider the dCDN a
candidate only if the IP address of the request routing source falls candidate only if the IP address of the request routing source falls
within the prefix set (or ASN, respectively). The CDNI within the prefix set (or ASN, respectively). The CDNI
specifications do not define how a given uCDN determines what address specifications do not define how a given uCDN determines what address
ranges are in a particular ASN. Similarly, for country codes a uCDN ranges are in a particular ASN. Similarly, for country codes a uCDN
should only consider the dCDN a candidate if it covers the country of should only consider the dCDN a candidate if it covers the country of
skipping to change at page 12, line 49 skipping to change at page 13, line 20
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. In this respect, it seems
reasonable to define a registry which initially contains the reasonable to define a registry which initially contains the
mandatory capabilities listed above, but may be extended as needs mandatory capabilities listed above, but may be extended as needs
dictate. This document defines the registry (and the rules for dictate. This document defines the registry (and the rules for
adding new entries to the registry) for the different capability adding new entries to the registry) for the different capability
types (see Section 7). 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. The individual CDNI interface specifications which define a
given capability SHOULD define any necessary registries (and the given capability SHOULD define any necessary registries (and the
rules for adding new entries to the registry) for the values rules for adding new entries to the registry) for the values
advertised for a given capability type. advertised for a given capability 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
skipping to change at page 14, line 5 skipping to change at page 14, line 25
In general, a uCDN may ignore capabilities or types of footprint it In general, a uCDN may ignore capabilities or types of footprint it
does not understand; in this case it only selects a suitable does not understand; in this case it only selects a suitable
downstream CDN based on the types of capabilities and footprint it downstream CDN based on the types of capabilities and footprint it
understands. Similarly, if a dCDN does not use an optional understands. Similarly, if a dCDN does not use an optional
capability or footprint which is, however, supported by a uCDN, this capability or footprint which is, however, supported by a uCDN, this
causes no problem for the FCI functionality because the uCDN decides causes no problem for the FCI functionality because the uCDN decides
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. IANA Considerations 7. Capability Advertisement Object
To support extensibility, the FCI defines a generic base object
(similar to the CDNI Metadata interface GenericMetadata object)
[I-D.ietf-cdni-metadata] to facilitate a uniform set of mandatory
parsing requirements for all future FCI objects.
[Ed. Note: MI/LI object definitions will build off the base object
defined here, but will be specified in a separate draft.]
7.1. Base Advertisement Object
The FCIBase object is an abstraction for managing individual CDNI
capabilities (see Section 8.1) in an opaque manner.
Property: capability-type
Description: CDNI Capability object type.
Type: MIME Type String (from Section 8)
Mandatory-to-Specify: Yes.
Property: capabilitiy-value
Description: CDNI Capability object.
Type: Format/Type is defined by the value of capability-type
property above.
Mandatory-to-Specify: Yes.
7.2. Redirection Mode Advertisement Object
The Redirection Mode advertisement object is used to indicate support
for one or more of the modes listed in the CDNI Capabilities
Redirection Modes registry (see Section 8.4).
Property: redirection-modes
Description: List of supported CDNI Redirection Modes.
Type: List of Redirection Modes (from Section 8.4)
Mandatory-to-Specify: Yes.
[Ed. Note: Redirection Mode is not in MI/LI; it is FCI specific. We
define it here as an example for the MI/LI FCI drafts.]
7.3. Advertisement Object Serialization
{
"capabilities": [
{
"capability-type": "application/cdni.FCI.RedirectionMode.v1"
"capability-value": {
"redirection-modes": [
"DNS-I",
"HTTP-I"
]
}
},
{
"capability-type": "application/cdni.FCI.LI.s-ccid.v1"
"capability-value": {
"s-ccid-support": true
}
}
]
}
[Ed. Note: Need to add JSON serialization discussion.]
8. IANA Considerations
This document requests the registration of the following MIME Media
Type under the IANA MIME Media Type registry
(http://www.iana.org/assignments/media-types/index.html).
application/cdni.FCI.RedirectionMode.v1
8.1. Capabilities Registry
IANA registries are to be used for mandatory and optional types of IANA registries are to be used for mandatory and optional types of
footprint and capabilities. Therefore, the mandatory types of footprint and capabilities. Therefore, the mandatory types of
capabilities listed in this document (see Section 5) are to be capabilities listed in this document (see Section 5) are to be
registered with IANA. In order to prevent namespace collisions for registered with IANA. In order to prevent namespace collisions for
capabilities a new IANA registry is requested for the "CDNI capabilities a new IANA registry is requested for the "CDNI
Capabilities" namespace. The namespace shall be split into two Capabilities" namespace. The namespace shall be split into two
partitions: standard and optional. partitions: standard and optional.
The "standard" namespace partition is intended to contain mandatory The "standard" namespace partition is intended to contain mandatory
to implement capabilities and conforms to the "IETF Review" policy as to implement capabilities and conforms to the "IETF Review" policy as
defined in [RFC5226]. The registry contains the name of the standard defined in [RFC5226]. The registry contains the name of the standard
capability, the RFC number of the specification defining the capability, the RFC number of the specification defining the
capability, and the version number of the FCI capability set to which capability (including the capability advertisement object format and
the standard capability applies. serialization).
The following table defines the initial capabilities for the standard The following table defines the initial capabilities for the standard
partition: partition:
+----------------------+---------+---------+ +-----------------------------------------+---------+
| Capability | RFC | Version | | Capability | RFC |
+----------------------+---------+---------+ +-----------------------------------------+---------+
| Delivery Protocol | RFCthis | 1 | | application/cdni.FCI.RedirectionMode.v1 | RFCthis |
| | | | +-----------------------------------------+---------+
| Acquisition Protocol | RFCthis | 1 |
| | | |
| Redirection Mode | RFCthis | 1 |
| | | |
| CDNI Logging | RFCthis | 1 |
| | | |
| CDNI Metadata | RFCthis | 1 |
+----------------------+---------+---------+
The initial FCI version number is set to 1. All three initial
capabilities are considered mandatory to implement for version 1.
The version field should be incremented when new capability sets are
added to the registry.
The "optional" namespace partition conforms to the "Expert Review" The "optional" namespace partition conforms to the "Expert Review"
policy as defined in [RFC5226]. The expert review is intended to policy as defined in [RFC5226]. The expert review is intended to
prevent namespace hoarding and to prevent the definition of redundant prevent namespace hoarding and to prevent the definition of redundant
capabilities. Vendors defining new capabilities which conflict with capabilities. Vendors defining new capabilities which conflict with
existing capabilities follow the guidelines for the "Specification existing capabilities follow the guidelines for the "Specification
Required" policy as defined in [RFC5226]. The Version field in the Required" policy as defined in [RFC5226].
registry is set to "-1" (negative one) for non-standard capabilities.
7.1. Footprint Sub-Registry 8.2. Footprint Sub-Registry
The "CDNI Metadata Footprint Types" namespace defined in the CDNI The "CDNI Metadata Footprint Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the Metadata Interface document [I-D.ietf-cdni-metadata] contains the
supported footprint formats for use in footprint advertisement. No supported footprint formats for use in footprint advertisement. No
further IANA action is required here. further IANA action is required here.
7.2. Protocol Sub-Registry 8.3. Protocol Sub-Registry
The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata The "CDNI Metadata Protocols" namespace defined in the CDNI Metadata
Interface document [I-D.ietf-cdni-metadata] contains the supported Interface document [I-D.ietf-cdni-metadata] contains the supported
protocol values for the Delivery Protocol and Acquisition Protocol protocol values for the Delivery Protocol and Acquisition Protocol
capabilities. No further IANA action is required here. capabilities. No further IANA action is required here.
7.3. Redirection Mode Sub-Registry 8.4. Redirection Mode Sub-Registry
The "CDNI Capabilities Redirection Modes" namespace defines the valid The "CDNI Capabilities Redirection Modes" namespace defines the valid
redirection modes that may be advertised as supported by a CDN. redirection modes that may be advertised as supported by a CDN.
Additions to the Redirection Mode namespace conform to the "IETF Additions to the Redirection Mode namespace conform to the "IETF
Review" policy as defined in [RFC5226]. Review" policy as defined in [RFC5226].
The following table defines the initial Redirection Modes: The following table defines the initial Redirection Modes:
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
| Redirection Mode | Description | RFC | | Redirection Mode | Description | RFC |
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
| DNS-I | Iterative DNS-based Redirection | RFCthis | | DNS-I | Iterative DNS-based Redirection | RFCthis |
| | | | | | | |
| 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 |
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
7.4. Logging Field Sub-Registry 8.5. Logging Record Type Sub-Registry
The "CDNI Logging Record-Types" namespace defined in the CDNI Logging
Interface document [I-D.ietf-cdni-logging] contains the types of all
supported logging record-types. No further IANA action is required
here.
8.6. Logging Field Name Sub-Registry
The "CDNI Logging Fields Names" namespace defined in the CDNI Logging The "CDNI Logging Fields Names" namespace defined in the CDNI Logging
Interface document [I-D.ietf-cdni-logging] contains the names of all Interface document [I-D.ietf-cdni-logging] contains the names of all
supported logging fields. No further IANA action is required here. supported logging fields. No further IANA action is required here.
7.5. Metadata Type Sub-Registry 8.7. Metadata Type Sub-Registry
The "CDNI GenericMetadata Types" namespace defined in the CDNI The "CDNI GenericMetadata Types" namespace defined in the CDNI
Metadata Interface document [I-D.ietf-cdni-metadata] contains the Metadata Interface document [I-D.ietf-cdni-metadata] contains the
names of the supported GenericMetadata objects. No further IANA names of the supported GenericMetadata objects. No further IANA
action is required here. action is required here.
8. Security Considerations 9. Security Considerations
Security considerations will be discussed in a future version of this This specification describes the semantics for capabilities and
document. footprint advertisement objects in content distribution networks. It
does not, however, specify a concrete protocol for transporting those
objects, or even a specific object syntax. Specific security
mechanisms can only be selected for concrete protocols that
instantiate these semantics. This document does, however, place some
high-level security constraints on such protocols.
9. References All protocols that implement these semantics are REQUIRED to provide
integrity and authentication services. Without authentication and
integrity, an attacker could trivially deny service by forging a
footprint advertisement from a dCDN which claims the network has no
footprint or capability. This would prevent the uCDN from delegating
any requests to the dCDN. Since a pre-existing relationship between
all dCDNs and uCDNs is assumed by CDNi, the exchange of any necessary
credentials could be conducted before the FCI interface is brought
online. The authorization decision to accept advertisements would
also follow this pre-existing relationship and any contractual
obligations that it stipulates.
9.1. Normative References It is not believed that there are any serious privacy risks in
sharing footprint or capability information: it will represent highly
aggregated data about networks and at best policy-related information
about media, rather than any personally identifying information.
However, particular dCDNs may wish to share information about their
footprint with a uCDN but not with other, competing dCDNs. For
example, if a dCDN incurs an outage that reduces footprint coverage
temporarily, that may be information the dCDN would want to share
confidentially with the uCDN. Protocols implementing these semantics
SHOULD provide confidentiality services.
As specified in this document, the security requirements of the FCI
could be met by hop-by-hop transport-layer security mechanisms
coupled with domain certificates as credentials. There is no
apparent need for further object-level security in this framework, as
the trust relationships it defines are bilateral relationships
between uCDNs and dCDNs rather than transitive relationships.
10. References
10.1. Normative References
[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, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[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,
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.
9.2. Informative References 10.2. Informative References
[I-D.ietf-cdni-framework] [I-D.ietf-cdni-framework]
Peterson, L., Davie, B., and R. Brandenburg, "Framework Peterson, L., Davie, B., and R. Brandenburg, "Framework
for CDN Interconnection", draft-ietf-cdni-framework-14 for CDN Interconnection", draft-ietf-cdni-framework-14
(work in progress), June 2014. (work in progress), June 2014.
[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-12 (work in progress), July 2014. logging-14 (work in progress), October 2014.
[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., Leung, K.,
and K. Ma, "CDN Interconnection Metadata", draft-ietf- and K. Ma, "CDN Interconnection Metadata", draft-ietf-
cdni-metadata-07 (work in progress), July 2014. cdni-metadata-07 (work in progress), July 2014.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", draft-ietf-cdni- Interconnection (CDNI) Requirements", draft-ietf-cdni-
requirements-17 (work in progress), January 2014. requirements-17 (work in progress), January 2014.
 End of changes. 27 change blocks. 
57 lines changed or deleted 186 lines changed or added

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