draft-ietf-cdni-footprint-capabilities-semantics-08.txt   draft-ietf-cdni-footprint-capabilities-semantics-09.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 20, 2016 Neustar Expires: May 6, 2016 Neustar
S. Previdi S. Previdi
Cisco Cisco
R. van Brandenburg R. van Brandenburg
TNO TNO
K. Ma K. Ma
Ericsson Ericsson
October 18, 2015 November 3, 2015
CDNI Request Routing: Footprint and Capabilities Semantics CDNI Request Routing: Footprint and Capabilities Semantics
draft-ietf-cdni-footprint-capabilities-semantics-08 draft-ietf-cdni-footprint-capabilities-semantics-09
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 April 20, 2016. This Internet-Draft will expire on May 6, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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
skipping to change at page 2, line 37 skipping to change at page 2, line 37
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. 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 . . . . . . . . . . . . . . . . . . . 13 Footprint/Capabilities . . . . . . . . . . . . . . . . . . . 13
7. Capability Advertisement Object . . . . . . . . . . . . . . . 14 7. Capability Advertisement Object . . . . . . . . . . . . . . . 14
7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14 7.1. Base Advertisement Object . . . . . . . . . . . . . . . . 14
7.2. Delivery Protocol Capability Object . . . . . . . . . . . 15 7.2. Delivery Protocol Capability Object . . . . . . . . . . . 14
7.3. Acquisition Protocol Capability Object . . . . . . . . . 15 7.3. Acquisition Protocol Capability Object . . . . . . . . . 15
7.4. Redirection Mode Capability Object . . . . . . . . . . . 15 7.4. Redirection Mode Capability Object . . . . . . . . . . . 15
7.5. Capability Advertisement Object Serialization . . . . . . 16 7.5. Capability Advertisement Object Serialization . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16 8.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 16
8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17 8.1.1. CDNI FCI DeliveryProtocol Payload Type . . . . . . . 17
8.1.2. CDNI FCI AcuiqisitionProtocol Payload Type . . . . . 17 8.1.2. CDNI FCI AcuiqisitionProtocol Payload Type . . . . . 17
8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17 8.1.3. CDNI FCI RedirectionMode Payload Type . . . . . . . . 17
8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17 8.2. Redirection Mode Registry . . . . . . . . . . . . . . . . 17
9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 19
skipping to change at page 13, line 31 skipping to change at page 13, line 31
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.
Advertising support for mandatory-to-implement logging fields SHOULD Advertising support for mandatory-to-implement logging fields SHOULD
be supported but would be redundant. CDNs SHOULD NOT advertise be supported but would be redundant. CDNs SHOULD NOT advertise
support for mandatory-to-implement logging fields. The following support for mandatory-to-implement logging fields. The following
logging fields are defined as optional in the CDNI Logging Interface logging fields are defined as optional in the CDNI Logging Interface
document [I-D.ietf-cdni-logging]: document [I-D.ietf-cdni-logging]:
o c-ip-anonimizing
o s-ccid o s-ccid
o s-sid o s-sid
The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does The CDNI Metadata Interface document [I-D.ietf-cdni-metadata] does
not define any optional GenericMetadata types. Advertiseing support not define any optional GenericMetadata types. Advertiseing support
for mandatory-to-implement GenericMetadata types SHOULD be supported for mandatory-to-implement GenericMetadata types SHOULD be supported
but would be redundant. CDNs SHOULD NOT advertise support for but would be redundant. CDNs SHOULD NOT advertise support for
mandatory-to-implement GenericMetadata types. mandatory-to-implement GenericMetadata types.
skipping to change at page 18, line 29 skipping to change at page 18, line 25
+------------------+----------------------------------+---------+ +------------------+----------------------------------+---------+
[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.]
9. Security Considerations 9. Security Considerations
This specification describes the semantics for capabilities and This specification describes the semantics for capabilities and
footprint advertisement objects in content distribution networks. It footprint advertisement objects in content distribution networks. It
does not, however, specify a concrete protocol for transporting those does not, however, specify a concrete protocol for transporting those
objects, or even a specific object syntax. Specific security objects. Specific security mechanisms can only be selected for
mechanisms can only be selected for concrete protocols that concrete protocols that instantiate these semantics. This document
instantiate these semantics. This document does, however, place some does, however, place some high-level security constraints on such
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
integrity and authentication services. Without authentication and integrity and authentication services. Without authentication and
integrity, an attacker could trivially deny service by forging a integrity, an attacker could trivially deny service by forging a
footprint advertisement from a dCDN which claims the network has no footprint advertisement from a dCDN which claims the network has no
footprint or capability. This would prevent the uCDN from delegating footprint or capability. This would prevent the uCDN from delegating
any requests to the dCDN. Since a pre-existing relationship between any requests to the dCDN. Since a pre-existing relationship between
all dCDNs and uCDNs is assumed by CDNi, the exchange of any necessary all dCDNs and uCDNs is assumed by CDNi, the exchange of any necessary
credentials could be conducted before the FCI interface is brought credentials could be conducted before the FCI interface is brought
online. The authorization decision to accept advertisements would online. The authorization decision to accept advertisements would
also follow this pre-existing relationship and any contractual also follow this pre-existing relationship and any contractual
obligations that it stipulates. obligations that it stipulates.
It is not believed that there are any serious privacy risks in It is not believed that there are any serious privacy risks in
sharing footprint or capability information: it will represent highly sharing footprint or capability information: it will represent highly
aggregated data about networks and at best policy-related information aggregated data about networks and, at best, policy-related
about media, rather than any personally identifying information. information about media, rather than any personally identifying
However, particular dCDNs may wish to share information about their information. However, particular dCDNs may wish to share information
footprint with a uCDN but not with other, competing dCDNs. For about their footprint with a uCDN but not with other, competing
example, if a dCDN incurs an outage that reduces footprint coverage dCDNs. For example, if a dCDN incurs an outage that reduces
temporarily, that may be information the dCDN would want to share footprint coverage temporarily, that may be information the dCDN
confidentially with the uCDN. Protocols implementing these semantics would want to share confidentially with the uCDN. Protocols
SHOULD provide confidentiality services. implementing these semantics SHOULD provide confidentiality services.
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 hop-by-hop transport-layer security mechanisms
coupled with domain certificates as credentials. There is no coupled with domain certificates as credentials. There is no
apparent need for further object-level security in this framework, as apparent need for further object-level security in this framework, as
the trust relationships it defines are bilateral relationships the trust relationships it defines are bilateral relationships
between uCDNs and dCDNs rather than transitive relationships. between uCDNs and dCDNs rather than transitive relationships.
10. References 10. References
10.1. Normative 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, 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>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
10.2. Informative References 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-20 (work in progress), October 2015. logging-21 (work in progress), November 2015.
[I-D.ietf-cdni-media-type] [I-D.ietf-cdni-media-type]
Ma, K., "CDNI Media Type Registration", draft-ietf-cdni- Ma, K., "CDNI Media Type Registration", draft-ietf-cdni-
media-type-06 (work in progress), October 2015. media-type-06 (work in progress), October 2015.
[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-11 (work in progress), July 2015. metadata-12 (work in progress), October 2015.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>.
[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>.
 End of changes. 12 change blocks. 
27 lines changed or deleted 25 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/