doc: Add RFC documents

1 files changed, 1739 insertions, 0 deletions

diff --git a/doc/rfc/rfc8008.txt b/doc/rfc/rfc8008.txt
new file mode 100644
index 0000000..f4f028d
--- /dev/null
+++ b/doc/rfc/rfc8008.txt
@@ -0,0 +1,1739 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Seedorf
+Request for Comments: 8008     HFT Stuttgart - Univ. of Applied Sciences
+Category: Standards Track                                    J. Peterson
+ISSN: 2070-1721                                                  Neustar
+                                                              S. Previdi
+                                                                   Cisco
+                                                      R. van Brandenburg
+                                                                     TNO
+                                                                   K. Ma
+                                                                Ericsson
+                                                           December 2016
+
+
+    Content Delivery Network Interconnection (CDNI) Request Routing:
+                  Footprint and Capabilities Semantics
+
+Abstract
+
+   This document captures the semantics of the "Footprint and
+   Capabilities Advertisement" part of the Content Delivery Network
+   Interconnection (CDNI) Request Routing interface, i.e., the desired
+   meaning of "Footprint" and "Capabilities" in the CDNI context and
+   what the "Footprint & Capabilities Advertisement interface (FCI)"
+   offers within CDNI.  The document also provides guidelines for the
+   CDNI FCI protocol.  It further defines a Base Advertisement Object,
+   the necessary registries for capabilities and footprints, and
+   guidelines on how these registries can be extended in the future.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 7841.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc8008.
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                    [Page 1]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+Copyright Notice
+
+   Copyright (c) 2016 IETF Trust and the persons identified as the
+   document authors.  All rights reserved.
+
+   This document is subject to BCP 78 and the IETF Trust's Legal
+   Provisions Relating to IETF Documents
+   (http://trustee.ietf.org/license-info) in effect on the date of
+   publication of this document.  Please review these documents
+   carefully, as they describe your rights and restrictions with respect
+   to this document.  Code Components extracted from this document must
+   include Simplified BSD License text as described in Section 4.e of
+   the Trust Legal Provisions and are provided without warranty as
+   described in the Simplified BSD License.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                    [Page 2]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+Table of Contents
+
+   1. Introduction and Scope ..........................................4
+      1.1. Terminology ................................................5
+   2. Design Decisions for Footprint and Capabilities .................6
+      2.1. Advertising Limited Coverage ...............................6
+      2.2. Capabilities and Dynamic Data ..............................7
+      2.3. Advertisement versus Queries ...............................8
+      2.4. Avoiding or Handling "Cheating" dCDNs ......................8
+   3. Focusing on Capabilities with Footprint Restrictions ............9
+   4. Footprint and Capabilities Extension ............................9
+   5. Capability Advertisement Object ................................11
+      5.1. Base Advertisement Object .................................12
+      5.2. Encoding ..................................................12
+      5.3. Delivery Protocol Capability Object .......................13
+           5.3.1. Delivery Protocol Capability Object Serialization ..13
+      5.4. Acquisition Protocol Capability Object ....................14
+           5.4.1. Acquisition Protocol Capability Object
+                  Serialization ......................................14
+      5.5. Redirection Mode Capability Object ........................15
+           5.5.1. Redirection Mode Capability Object Serialization ...15
+      5.6. CDNI Logging Capability Object ............................16
+           5.6.1. CDNI Logging Capability Object Serialization .......17
+      5.7. CDNI Metadata Capability Object ...........................18
+           5.7.1. CDNI Metadata Capability Object Serialization ......19
+   6. IANA Considerations ............................................20
+      6.1. CDNI Payload Types ........................................20
+           6.1.1. CDNI FCI DeliveryProtocol Payload Type .............20
+           6.1.2. CDNI FCI AcquisitionProtocol Payload Type ..........20
+           6.1.3. CDNI FCI RedirectionMode Payload Type ..............20
+           6.1.4. CDNI FCI Logging Payload Type ......................21
+           6.1.5. CDNI FCI Metadata Payload Type .....................21
+      6.2. "CDNI Capabilities Redirection Modes" Registry ............21
+   7. Security Considerations ........................................22
+   8. References .....................................................23
+      8.1. Normative References ......................................23
+      8.2. Informative References ....................................24
+   Appendix A. Main Use Case to Consider .............................25
+   Appendix B. Semantics for Footprint Advertisement .................25
+   Appendix C. Semantics for Capabilities Advertisement ..............27
+   Acknowledgments ...................................................30
+   Authors' Addresses ................................................30
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                    [Page 3]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+1.  Introduction and Scope
+
+   The CDNI working group is working on a set of protocols to enable the
+   interconnection of multiple CDNs.  These CDNI protocols can serve
+   multiple purposes, as discussed in [RFC6770] -- for instance, to
+   extend the reach of a given CDN to areas in the network that are not
+   covered by that particular CDN.
+
+   The goal of this document is to achieve a clear understanding about
+   the semantics associated with the CDNI Request Routing Footprint &
+   Capabilities Advertisement interface (from now on referred to as
+   the FCI) [RFC7336], in particular the type of information a
+   downstream CDN (dCDN) "advertises" regarding its footprint and
+   capabilities.  To narrow down undecided aspects of these semantics,
+   this document tries to establish a common understanding of what the
+   FCI needs to offer and accomplish in the context of CDNI.
+
+   Deciding on specific protocols to use for the FCI is explicitly
+   outside the scope of this document.  However, we provide guidelines
+   for such FCI protocols.
+
+   We make the following general assumptions in this document:
+
+   o  The CDNs participating in the CDN interconnection have already
+      performed a bootstrap process, i.e., they have connected to each
+      other, either directly or indirectly, and can exchange information
+      amongst each other.
+
+   o  The upstream CDN (uCDN) receives footprint advertisements and/or
+      capability advertisements from a set of dCDNs.  Footprint
+      advertisements and capability advertisements need not use the same
+      underlying protocol.
+
+   o  The uCDN receives the initial Request Routing message from the
+      endpoint requesting the resource.
+
+   The CDNI problem statement [RFC6707] describes the Request Routing
+   interface as "[enabling] a Request Routing function in an Upstream
+   CDN to query a Request Routing function in a Downstream CDN to
+   determine if the Downstream CDN is able (and willing) to accept the
+   delegated Content Request."  In addition, [RFC6707] says "the CDNI
+   Request Routing interface is also expected to enable a Downstream CDN
+   to provide to the Upstream CDN (static or dynamic) information (e.g.,
+   resources, footprint, load) to facilitate selection of the Downstream
+   CDN by the Upstream CDN Request Routing system when processing
+   subsequent Content Requests from User Agents."  It thus considers
+   "resources" and "load" as capabilities to be advertised by the dCDN.
+
+
+
+
+Seedorf, et al.              Standards Track                    [Page 4]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   The range of different footprint definitions and possible
+   capabilities is very broad.  Attempting to define a comprehensive
+   advertisement solution quickly becomes intractable.  The CDNI
+   requirements document [RFC7337] lists the specific requirements for
+   the CDNI FCI in order to disambiguate footprints and capabilities
+   with respect to CDNI.  This document defines a common understanding
+   of what the terms "footprint" and "capabilities" mean in the context
+   of CDNI and details the semantics of the footprint advertisement
+   mechanism and the capability advertisement mechanism.
+
+1.1.  Terminology
+
+   This document reuses the terminology defined in [RFC6707].
+
+   Additionally, the following terms are used throughout this document
+   and are defined as follows:
+
+   o  Footprint: a description of a CDN's coverage area, i.e., the area
+      from which client requests may originate for content and to which
+      the CDN is willing to deliver content.  Note: There are many ways
+      to describe a footprint -- for example, by address range (e.g.,
+      IPv4 CIDR or IPv6 CIDR (Classless Inter-Domain Routing), network
+      ID (e.g., Autonomous System Number (ASN)), nation boundaries
+      (e.g., country code), or GPS coordinates.  This document does not
+      define or endorse the quality or suitability of any particular
+      footprint description method; rather, it only defines a method for
+      transporting known footprint descriptions in Footprint and
+      Capabilities Advertisement messages.
+
+   o  Capability: a feature of a dCDN upon whose support a uCDN relies
+      when making delegation decisions.  Support for a given feature can
+      change over time and can be restricted to a limited portion of a
+      dCDN's footprint.  Note: There are many possible dCDN features
+      that could be of interest to a uCDN.  This document does not
+      presume to define them all; rather, it describes a scheme for
+      defining new capabilities and how to transport them in Footprint
+      and Capabilities Advertisement messages.
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in RFC 2119 [RFC2119].
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                    [Page 5]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+2.  Design Decisions for Footprint and Capabilities
+
+   A large part of the difficulty in discussing the FCI lies in
+   understanding what exactly is meant when trying to define a footprint
+   in terms of "coverage" or "reachability".  While the operators of
+   CDNs pick strategic locations to situate Surrogates, a Surrogate with
+   a public IPv4 address is reachable by any endpoint on the Internet,
+   unless some policy enforcement precludes the use of the Surrogate.
+
+   Some CDNs aspire to cover the entire world; we refer to these as
+   global CDNs.  The footprint advertised by such a CDN in the CDNI
+   environment would, from a coverage or reachability perspective,
+   presumably cover all prefixes.  Potentially more interesting for CDNI
+   use cases, however, are CDNs that claim a more limited coverage area
+   but seek to interconnect with other CDNs in order to create a single
+   CDN fabric that shares resources.
+
+   Furthermore, not all capabilities need to be footprint-restricted.
+   Depending upon the use case, the optimal semantics of "footprints
+   with capability attributes" vs. "capabilities with footprint
+   restrictions" are not clear.
+
+   The key to understanding the semantics of footprint advertisements
+   and capability advertisements lies in understanding why a dCDN would
+   advertise a limited coverage area and how a uCDN would use such
+   advertisements to decide among one of several dCDNs.  The following
+   section will discuss some of the trade-offs and design decisions that
+   need to be made for the CDNI FCI.
+
+2.1.  Advertising Limited Coverage
+
+   The basic use case that would motivate a dCDN to advertise limited
+   coverage is that the CDN was built to cover only a particular portion
+   of the Internet.  For example, an ISP could purpose-build a CDN to
+   serve only their own customers by situating Surrogates in close
+   topological proximity to high concentrations of their subscribers.
+   The ISP knows the prefixes it has allocated to end users and thus can
+   easily construct a list of prefixes that its Surrogates were
+   positioned to serve.
+
+   When such a purpose-built CDN interconnects with other CDNs and
+   advertises its footprint to a uCDN, however, the original intended
+   coverage of the CDN might not represent its actual value to the
+   interconnection of CDNs.  Consider an ISP-A and ISP-B that both field
+   their own CDNs, which they interconnect via CDNI.  A given user E,
+   who is a customer of ISP-B, might happen to be topologically closer
+   to a Surrogate fielded by ISP-A, if E happens to live in a region
+   where ISP-B has few customers and ISP-A has many.  In this case, is
+
+
+
+Seedorf, et al.              Standards Track                    [Page 6]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   it ISP-A's CDN that "covers" E?  If ISP-B's CDN has a failure
+   condition, is it up to the uCDN to understand that ISP-A's Surrogates
+   are potentially available as backups, and if so, how does ISP-A
+   advertise itself as a "standby" for E?  What about the case where
+   CDNs advertising to the same uCDN express overlapping coverage (for
+   example, mixing global and limited CDNs)?
+
+   The answers to these questions greatly depend on how much information
+   the uCDN wants to use to select a dCDN.  If a uCDN has three dCDNs to
+   choose from that "cover" the IP address of user E, obviously the uCDN
+   might be interested in knowing how optimal the coverage is from each
+   of the dCDNs.  Coverage need not be binary (i.e., either provided or
+   not provided); dCDNs could advertise a coverage "score", for example,
+   and provided that they all reported scores fairly on the same scale,
+   uCDNs could use that information to make their topological optimality
+   decision.  Alternately, dCDNs could advertise the IP addresses of
+   their Surrogates rather than prefix "coverage" and let the uCDN
+   decide for itself (based on its own topological intelligence) which
+   dCDN has better resources to serve a given user.
+
+   In summary, the semantics of advertising a footprint depend on
+   whether (1) such qualitative metrics for expressing a footprint (such
+   as the coverage "score" mentioned above) are included as part of the
+   CDNI FCI or (2) the focus is just on a "binary" footprint.
+
+2.2.  Capabilities and Dynamic Data
+
+   In cases where the apparent footprints of dCDNs overlap, uCDNs might
+   also want to rely on other factors to evaluate the respective merits
+   of dCDNs.  These include facts related to the Surrogates themselves,
+   the network where the Surrogate is deployed, the nature of the
+   resource sought, and the administrative policies of the respective
+   networks.
+
+   In the absence of network-layer impediments to reaching Surrogates,
+   the choice to limit coverage is, by necessity, an administrative
+   policy.  Much policy needs to be agreed upon before CDNs can
+   interconnect, including questions of membership, compensation,
+   volumes, and so on.  A uCDN certainly will factor these sorts of
+   considerations into its decision to select a dCDN, but there is
+   probably little need for dCDNs to actually advertise them through an
+   interface -- they will be settled out-of-band as a precondition for
+   interconnection.
+
+   Other facts about the dCDN would be expressed through the interface
+   to the uCDN.  Some capabilities of a dCDN are static, and some are
+   highly dynamic.  Expressing the total storage built into its
+   Surrogates, for example, changes relatively rarely, whereas the
+
+
+
+Seedorf, et al.              Standards Track                    [Page 7]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   amount of storage in use at any given moment is highly volatile.
+   Network bandwidth similarly could be expressed either as total
+   bandwidth available to a Surrogate or based on the current state of
+   the network.  A Surrogate can at one moment lack a particular
+   resource in storage but have it the next.
+
+   The semantics of the capabilities interface will depend on how much
+   of the dCDN state needs to be pushed to the uCDN and, qualitatively,
+   how often that information needs to be updated.
+
+2.3.  Advertisement versus Queries
+
+   In a CDNI environment, each dCDN shares some of its state with the
+   uCDN.  The uCDN uses this information to build a unified picture of
+   all of the dCDNs available to it.  In architectures that share
+   detailed capability information, the uCDN could perform the entire
+   Request Routing operation down to selecting a particular Surrogate in
+   the dCDN.  However, when the uCDN needs to deal with many potential
+   dCDNs, this approach does not scale, especially for dCDNs with
+   thousands or tens of thousands of Surrogates; the volume of updates
+   to the footprint and the capability information becomes onerous.
+
+   Were the volume of FCI updates from dCDNs to exceed the volume of
+   requests to the uCDN, it might make more sense for the uCDN to query
+   dCDNs upon receiving requests (as is the case in the recursive
+   redirection mode described in [RFC7336]), instead of receiving
+   advertisements and tracking the state of dCDNs.  The advantage of
+   querying dCDNs would be that much of the dynamic data that dCDNs
+   cannot share with the uCDN would now be factored into the uCDN's
+   decision. dCDNs need not replicate any state to the uCDN -- uCDNs
+   could effectively operate in a stateless mode.
+
+   The semantics of both footprint advertisements and capability
+   advertisements depend on the service model here: are there cases
+   where a synchronous query/response model would work better for the
+   uCDN decision than a state replication model?
+
+2.4.  Avoiding or Handling "Cheating" dCDNs
+
+   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
+   sense that the dCDN provides inaccurate information to the uCDN in
+   order to convince the uCDN to select it over "competing" dCDNs.  It
+   could therefore be desirable to take away the incentive for dCDNs to
+   cheat (in information advertised) as much as possible.  One option is
+   to make the information the dCDN advertises somehow verifiable for
+   the uCDN.  On the other hand, a "cheating" dCDN might be avoided or
+
+
+
+
+Seedorf, et al.              Standards Track                    [Page 8]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   handled by the fact that there will be strong contractual agreements
+   between a uCDN and a dCDN, so that a dCDN would risk severe penalties
+   or legal consequences when caught cheating.
+
+   Overall, the information a dCDN advertises (in the long run) needs to
+   be somehow qualitatively verifiable by the uCDN, though possibly
+   through non-real-time out-of-band audits.  It is probably an overly
+   strict requirement to mandate that such verification be possible
+   "immediately", i.e., during the Request Routing process itself.  If
+   the uCDN can detect a cheating dCDN at a later stage, it might
+   suffice for the uCDN to "de-incentivize" cheating because it would
+   negatively affect the long-term business relationship with a
+   particular dCDN.
+
+3.  Focusing on Capabilities with Footprint Restrictions
+
+   Given the design considerations listed in the previous section, it
+   seems reasonable to assume that in most cases it is the uCDN that
+   makes the decision to select a certain dCDN for Request Routing based
+   on information the uCDN has received from this particular dCDN.  It
+   can be assumed that cheating dCDNs will be dealt with via means
+   outside the scope of CDNI and that the information advertised between
+   CDNs is accurate.  In addition, excluding the use of qualitative
+   information (e.g., Surrogate proximity, delivery latency, Surrogate
+   load) to predict the quality of delivery would further simplify the
+   use case, allowing it to better focus on the basic functionality of
+   the FCI.
+
+   Furthermore, understanding that in most cases contractual agreements
+   will define the basic coverage used in delegation decisions, the
+   primary focus of the FCI is on providing updates to the basic
+   capabilities and coverage by the dCDNs.  As such, the FCI has chosen
+   the semantics of "capabilities with footprint restrictions".
+
+4.  Footprint and Capabilities Extension
+
+   Other optional "coverage/reachability" footprint types or "resource"
+   footprint types may be defined by future specifications.  To
+   facilitate this, a clear process for specifying optional footprint
+   types in an IANA registry is specified in the "CDNI Metadata
+   Footprint Types" registry (defined in the CDNI Metadata interface
+   document [RFC8006]).
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                    [Page 9]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   This document also registers CDNI Payload Types [RFC7736] for the
+   initial capability types (see Section 6):
+
+   o  Delivery Protocol (for delivering content to the end user)
+
+   o  Acquisition Protocol (for acquiring content from the uCDN or
+      origin server)
+
+   o  Redirection Mode (e.g., DNS redirection vs. HTTP redirection as
+      discussed in [RFC7336])
+
+   o  CDNI Logging (i.e., supported CDNI Logging fields)
+
+   o  CDNI Metadata (i.e., supported GenericMetadata types)
+
+   Each Payload Type is prefaced with "FCI.".  Updates to capability
+   objects MUST indicate the version of the capability object in a newly
+   registered Payload Type, e.g., by appending ".v2".  Each capability
+   type MAY have a list of valid values.  Future specifications that
+   define a given capability MUST define any necessary registries (and
+   the rules for adding new entries to the registry) for the values
+   advertised for a given capability type.
+
+   The "CDNI Logging record-types" registry [RFC7937] defines all known
+   record-types, including "mandatory-to-implement" record-types.
+   Advertising support for mandatory-to-implement record-types would be
+   redundant.  CDNs SHOULD NOT advertise support for
+   mandatory-to-implement record-types.
+
+   The "CDNI Logging Field Names" registry [RFC7937] defines all known
+   CDNI Logging fields.  CDNI Logging fields may be reused by different
+   record-types and be mandatory-to-implement in some record-types, but
+   they may be optional in other record-types.  CDNs MUST advertise
+   support for optional CDNI Logging fields within the context of a
+   specific record-type.  For a given record-type, CDNs SHOULD NOT
+   advertise support for mandatory-to-implement CDNI Logging fields.
+   The following CDNI Logging fields are defined as optional for the
+   "cdni_http_request_v1" record-type [RFC7937]:
+
+   o  s-ccid
+
+   o  s-sid
+
+   [RFC8006] requires that CDNs be able to parse all the defined
+   metadata objects but does not require dCDNs to support enforcement of
+   non-structural GenericMetadata objects.  Advertising support for
+   "mandatory-to-enforce" GenericMetadata types MUST be provided.
+   Advertising support for non-mandatory-to-enforce GenericMetadata
+
+
+
+Seedorf, et al.              Standards Track                   [Page 10]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   types SHOULD be provided.  Advertisement of non-mandatory-to-enforce
+   GenericMetadata MAY be necessary, e.g., to signal temporary outages
+   and subsequent recovery.  It is expected that structural metadata
+   will be supported at all times.
+
+   The notion of optional footprint types and capability types implies
+   that certain implementations might not support all kinds of
+   footprints and capabilities.  Therefore, any FCI solution protocol
+   MUST define how the support for optional footprint types and
+   capability types will be negotiated between a uCDN and a dCDN that
+   use the particular FCI protocol.  In particular, any FCI solution
+   protocol MUST specify how to handle failure cases or non-supported
+   footprint or capability types.
+
+   In general, a uCDN MAY ignore capabilities or footprint types it does
+   not understand; in this case, it only selects a suitable dCDN based
+   on the types of capabilities and footprints it understands.
+   Similarly, if a dCDN does not use an optional capability or footprint
+   that is, however, supported by a uCDN, this causes no problem for FCI
+   functionality because the uCDN decides on the remaining
+   capabilities/footprint information that is being conveyed by
+   the dCDN.
+
+5.  Capability Advertisement Object
+
+   To support extensibility, the FCI defines a generic base object
+   (similar to the CDNI Metadata interface GenericMetadata object)
+   [RFC8006] to facilitate a uniform set of mandatory parsing
+   requirements for all future FCI objects.
+
+   Future object definitions (e.g., regarding the CDNI Metadata or CDNI
+   Logging interfaces) will build off the base object defined here but
+   will be specified in separate documents.
+
+   Note: In the following sections, the term "mandatory-to-specify" is
+   used to convey which properties MUST be included when serializing a
+   given capability object.  When mandatory-to-specify is defined as
+   "Yes" for an individual property, it means that if the object
+   containing that property is included in an FCI message, then the
+   mandatory-to-specify property MUST also be included.
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 11]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+5.1.  Base Advertisement Object
+
+   The FCIBase object is an abstraction for managing individual CDNI
+   capabilities in an opaque manner.
+
+      Property: capability-type
+
+         Description: CDNI capability object type.
+
+         Type: FCI-specific CDNI Payload Type (from the "CDNI Payload
+         Types" registry [RFC7736])
+
+         Mandatory-to-Specify: Yes.
+
+      Property: capability-value
+
+         Description: CDNI capability object.
+
+         Type: Format/Type is defined by the value of the
+         capability-type property above
+
+         Mandatory-to-Specify: Yes.
+
+      Property: footprints
+
+         Description: CDNI capability footprint.
+
+         Type: List of CDNI Footprint objects (from the "CDNI Metadata
+         Footprint Types" registry [RFC8006])
+
+         Mandatory-to-Specify: No.
+
+5.2.  Encoding
+
+   CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also
+   follow the recommendations of I-JSON (Internet 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).
+
+
+
+Seedorf, et al.              Standards Track                   [Page 12]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   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
+   for one or more of the protocols listed in the "CDNI Metadata
+   Protocol Types" registry (defined in [RFC8006]).
+
+      Property: delivery-protocols
+
+         Description: List of supported CDNI delivery protocols.
+
+         Type: List of protocol types (from the "CDNI Metadata Protocol
+         Types" registry [RFC8006])
+
+         Mandatory-to-Specify: Yes.
+
+5.3.1.  Delivery Protocol Capability Object Serialization
+
+   The following shows an example of Delivery Protocol capability object
+   serialization for a CDN that supports only HTTP/1.1 without Transport
+   Layer Security (TLS) for content delivery.
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.DeliveryProtocol",
+         "capability-value": {
+           "delivery-protocols": [
+             "http/1.1",
+           ]
+         },
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 13]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+5.4.  Acquisition Protocol Capability Object
+
+   The Acquisition Protocol capability object is used to indicate
+   support for one or more of the protocols listed in the "CDNI Metadata
+   Protocol Types" registry (defined in [RFC8006]).
+
+      Property: acquisition-protocols
+
+         Description: List of supported CDNI acquisition protocols.
+
+         Type: List of protocol types (from the "CDNI Metadata Protocol
+         Types" registry [RFC8006])
+
+         Mandatory-to-Specify: Yes.
+
+5.4.1.  Acquisition Protocol Capability Object Serialization
+
+   The following shows an example of Acquisition Protocol capability
+   object serialization for a CDN that supports HTTP/1.1 with or without
+   TLS for content acquisition.
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.AcquisitionProtocol",
+         "capability-value": {
+           "acquisition-protocols": [
+             "http/1.1",
+             "https/1.1"
+           ]
+         },
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 14]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+5.5.  Redirection Mode Capability Object
+
+   The Redirection Mode capability object is used to indicate support
+   for one or more of the modes listed in the "CDNI Capabilities
+   Redirection Modes" registry (see Section 6.2).
+
+      Property: redirection-modes
+
+         Description: List of supported CDNI redirection modes.
+
+         Type: List of redirection modes (from the "CDNI Capabilities
+         Redirection Modes" registry, defined in Section 6.2)
+
+         Mandatory-to-Specify: Yes.
+
+5.5.1.  Redirection Mode Capability Object Serialization
+
+   The following shows an example of Redirection Mode capability object
+   serialization for a CDN that supports only iterative (i.e., not
+   recursive) redirection with HTTP and DNS.
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.RedirectionMode",
+         "capability-value": {
+           "redirection-modes": [
+             "DNS-I",
+             "HTTP-I"
+           ]
+         }
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 15]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+5.6.  CDNI Logging Capability Object
+
+   The CDNI Logging capability object is used to indicate support for
+   CDNI Logging record-types, as well as CDNI Logging fields that are
+   marked as optional for the specified record-types [RFC7937].
+
+      Property: record-type
+
+         Description: Supported CDNI Logging record-type.
+
+         Type: String corresponding to an entry from the "CDNI Logging
+         record-types" registry [RFC7937]
+
+         Mandatory-to-Specify: Yes.
+
+      Property: fields
+
+         Description: List of supported CDNI Logging fields that are
+         optional for the specified record-type.
+
+         Type: List of strings corresponding to entries from the "CDNI
+         Logging Field Names" registry [RFC7937]
+
+         Mandatory-to-Specify: No.  Default is that all optional fields
+         are supported.  Omission of this field MUST be interpreted as
+         "all optional fields are supported".  An empty list MUST be
+         interpreted as "no optional fields are supported".  Otherwise,
+         if a list of fields is provided, the fields in that list MUST
+         be interpreted as "the only optional fields that are
+         supported".
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 16]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+5.6.1.  CDNI Logging Capability Object Serialization
+
+   The following shows an example of CDNI Logging capability object
+   serialization for a CDN that supports the optional Content
+   Collection ID CDNI Logging field (but not the optional Session ID
+   CDNI Logging field) for the "cdni_http_request_v1" record-type.
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.Logging",
+         "capability-value": {
+           "record-type": "cdni_http_request_v1",
+           "fields": ["s-ccid"]
+         },
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+   The next example shows the CDNI Logging capability object
+   serialization for a CDN that supports all optional fields for the
+   "cdni_http_request_v1" record-type.
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.Logging",
+         "capability-value": {
+           "record-type": "cdni_http_request_v1"
+         },
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 17]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   The final example shows the CDNI Logging capability object
+   serialization for a CDN that supports none of the optional fields for
+   the "cdni_http_request_v1" record-type.
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.Logging",
+         "capability-value": {
+           "record-type": "cdni_http_request_v1",
+           "fields": []
+         },
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+5.7.  CDNI Metadata Capability Object
+
+   The CDNI Metadata capability object is used to indicate support for
+   CDNI GenericMetadata types [RFC8006].
+
+      Property: metadata
+
+         Description: List of supported CDNI GenericMetadata types.
+
+         Type: List of strings corresponding to entries from the "CDNI
+         Payload Types" registry [RFC7736] that correspond to CDNI
+         GenericMetadata objects
+
+         Mandatory-to-Specify: Yes.  An empty list MUST be interpreted
+         as "no GenericMetadata types are supported", i.e., "only
+         structural metadata and simple types are supported"; otherwise,
+         the list must be interpreted as containing "the only
+         GenericMetadata types that are supported" (in addition to
+         structural metadata and simple types) [RFC8006].
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 18]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+5.7.1.  CDNI Metadata Capability Object Serialization
+
+   The following shows an example of CDNI Metadata capability object
+   serialization for a CDN that supports only the SourceMetadata
+   GenericMetadata type (i.e., it can acquire and deliver content but
+   cannot enforce any security policies, e.g., time, location, or
+   protocol Access Control Lists (ACLs)).
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.Metadata",
+         "capability-value": {
+           "metadata": ["MI.SourceMetadata"]
+         },
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+   The next example shows the CDNI Metadata capability object
+   serialization for a CDN that supports only structural metadata (i.e.,
+   it can parse metadata as a transit CDN but cannot enforce security
+   policies or deliver content).
+
+   {
+     "capabilities": [
+       {
+         "capability-type": "FCI.Metadata",
+         "capability-value": {
+           "metadata": []
+         },
+         "footprints": [
+           <Footprint objects>
+         ]
+       }
+     ]
+   }
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 19]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+6.  IANA Considerations
+
+6.1.  CDNI Payload Types
+
+   This document registers the following CDNI Payload Types under the
+   IANA "CDNI Payload Types" registry:
+
+                +-------------------------+---------------+
+                | Payload Type            | Specification |
+                +-------------------------+---------------+
+                | FCI.DeliveryProtocol    | RFC 8008      |
+                | FCI.AcquisitionProtocol | RFC 8008      |
+                | FCI.RedirectionMode     | RFC 8008      |
+                | FCI.Logging             | RFC 8008      |
+                | FCI.Metadata            | RFC 8008      |
+                +-------------------------+---------------+
+
+6.1.1.  CDNI FCI DeliveryProtocol Payload Type
+
+   Purpose: The purpose of this Payload Type is to distinguish FCI
+   advertisement objects for supported delivery protocols
+
+   Interface: FCI
+
+   Encoding: see Section 5.3
+
+6.1.2.  CDNI FCI AcquisitionProtocol Payload Type
+
+   Purpose: The purpose of this Payload Type is to distinguish FCI
+   advertisement objects for supported acquisition protocols
+
+   Interface: FCI
+
+   Encoding: see Section 5.4
+
+6.1.3.  CDNI FCI RedirectionMode Payload Type
+
+   Purpose: The purpose of this Payload Type is to distinguish FCI
+   advertisement objects for supported redirection modes
+
+   Interface: FCI
+
+   Encoding: see Section 5.5
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 20]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+6.1.4.  CDNI FCI Logging Payload Type
+
+   Purpose: The purpose of this Payload Type is to distinguish FCI
+   advertisement objects for supported CDNI Logging record-types and
+   optional CDNI Logging field names
+
+   Interface: FCI
+
+   Encoding: see Section 5.6
+
+6.1.5.  CDNI FCI Metadata Payload Type
+
+   Purpose: The purpose of this Payload Type is to distinguish FCI
+   advertisement objects for supported CDNI GenericMetadata types
+
+   Interface: FCI
+
+   Encoding: see Section 5.7
+
+6.2.  "CDNI Capabilities Redirection Modes" Registry
+
+   IANA has created a new "CDNI Capabilities Redirection Modes" registry
+   in the "Content Delivery Network Interconnection (CDNI) Parameters"
+   registry.  The "CDNI Capabilities Redirection Modes" namespace
+   defines the valid redirection modes that can be advertised as
+   supported by a CDN.  Additions to the "CDNI Capabilities Redirection
+   Modes" namespace conform to the IETF Review policy as defined in
+   [RFC5226].
+
+   The following table defines the initial redirection modes:
+
+    +------------------+----------------------------------+----------+
+    | Redirection Mode | Description                      | RFC      |
+    +------------------+----------------------------------+----------+
+    | DNS-I            | Iterative DNS-based Redirection  | RFC 8008 |
+    | DNS-R            | Recursive DNS-based Redirection  | RFC 8008 |
+    | HTTP-I           | Iterative HTTP-based Redirection | RFC 8008 |
+    | HTTP-R           | Recursive HTTP-based Redirection | RFC 8008 |
+    +------------------+----------------------------------+----------+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 21]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+7.  Security Considerations
+
+   This specification describes the semantics for capabilities and
+   footprint advertisement objects across interconnected CDNs.  It does
+   not, however, specify a concrete protocol for transporting those
+   objects.  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.
+
+   All protocols that implement these capabilities and footprint
+   advertisement objects 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 that claims the network has no footprint or
+   capability.  This would prevent the uCDN from delegating any requests
+   to the dCDN.  Since a preexisting relationship between all dCDNs and
+   uCDNs is assumed by CDNI, the exchange of any necessary credentials
+   could be conducted before the FCI is brought online.  The
+   authorization decision to accept advertisements would also follow
+   this preexisting relationship and any contractual obligations that it
+   stipulates.
+
+   All protocols that implement these capabilities and footprint
+   advertisement objects are REQUIRED to provide confidentiality
+   services.  Some dCDNs are willing to share information about their
+   footprints or capabilities with a uCDN but not with other, competing
+   dCDNs.  For example, if a dCDN incurs an outage that reduces
+   footprint coverage temporarily, that event could be information the
+   dCDN would want to share confidentially with the uCDN.
+
+   As specified in this document, the security requirements of the FCI
+   could be met by transport-layer security mechanisms coupled with
+   domain certificates as credentials (e.g., TLS transport for HTTP as
+   per [RFC2818] and [RFC7230], with usage guidance from [RFC7525])
+   between CDNs.  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.
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 22]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+8.  References
+
+8.1.  Normative References
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <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>.
+
+   [RFC7159]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", RFC 7159, DOI 10.17487/RFC7159,
+              March 2014, <http://www.rfc-editor.org/info/rfc7159>.
+
+   [RFC7336]  Peterson, L., Davie, B., and R. van Brandenburg, Ed.,
+              "Framework for Content Distribution Network
+              Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336,
+              August 2014, <http://www.rfc-editor.org/info/rfc7336>.
+
+   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
+              DOI 10.17487/RFC7493, March 2015,
+              <http://www.rfc-editor.org/info/rfc7493>.
+
+   [RFC7937]  Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed.,
+              and R. Peterkofsky, "Content Distribution Network
+              Interconnection (CDNI) Logging Interface", RFC 7937,
+              DOI 10.17487/RFC7937, August 2016,
+              <http://www.rfc-editor.org/info/rfc7937>.
+
+   [RFC8006]  Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
+              "Content Delivery Network Interconnection (CDNI)
+              Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016,
+              <http://www.rfc-editor.org/info/rfc8006>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 23]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+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
+              Distribution Network Interconnection (CDNI) Problem
+              Statement", RFC 6707, DOI 10.17487/RFC6707,
+              September 2012, <http://www.rfc-editor.org/info/rfc6707>.
+
+   [RFC6770]  Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley,
+              P., Ma, K., and G. Watson, "Use Cases for Content Delivery
+              Network Interconnection", RFC 6770, DOI 10.17487/RFC6770,
+              November 2012, <http://www.rfc-editor.org/info/rfc6770>.
+
+   [RFC7230]  Fielding, R., Ed., and J. Reschke, Ed., "Hypertext
+              Transfer Protocol (HTTP/1.1): Message Syntax and Routing",
+              RFC 7230, DOI 10.17487/RFC7230, June 2014,
+              <http://www.rfc-editor.org/info/rfc7230>.
+
+   [RFC7337]  Leung, K., Ed., and Y. Lee, Ed., "Content Distribution
+              Network Interconnection (CDNI) Requirements", RFC 7337,
+              DOI 10.17487/RFC7337, August 2014,
+              <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)
+              Media Type Registration", RFC 7736, DOI 10.17487/RFC7736,
+              December 2015, <http://www.rfc-editor.org/info/rfc7736>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 24]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+Appendix A.  Main Use Case to Consider
+
+   Focusing on a main use case that contains a simple (yet somewhat
+   challenging), realistic, and generally imaginable scenario can help
+   narrow down the requirements for the CDNI FCI.  To this end, the
+   following (simplified) use case can help clarify the semantics of
+   footprints and capabilities for CDNI.  In particular, the intention
+   of the use case is to clarify what information needs to be exchanged
+   on the CDNI FCI, what types of information need to be supported in a
+   mandatory fashion (and which types can be considered optional), and
+   what types of information need to be updated with respect to a priori
+   established CDNI contracts.
+
+   Use case: A given uCDN has several dCDNs.  It selects one dCDN for
+   delivery protocol A and footprint 1 and another dCDN for delivery
+   protocol B and footprint 1.  The dCDN that serves delivery protocol B
+   has a further, transitive (level-2) dCDN that serves delivery
+   protocol B in a subset of footprint 1 where the first-level dCDN
+   cannot serve delivery protocol B itself.  What happens if
+   capabilities change in the transitive level-2 dCDN that might affect
+   how the uCDN selects a level-1 dCDN (e.g., in case the level-2 dCDN
+   cannot serve delivery protocol B anymore)?  How will these changes be
+   conveyed to the uCDN?  In particular, what information does the uCDN
+   need to be able to select a new first-level dCDN, for either all of
+   footprint 1 or only the subset of footprint 1 that the transitive
+   level-2 dCDN served on behalf of the first-level dCDN?
+
+Appendix B.  Semantics for Footprint Advertisement
+
+   Roughly speaking, "footprint" can be defined as a dCDN's "ability and
+   willingness to serve".  However, in addition to simple ability and
+   willingness to serve, the uCDN could want additional information
+   before deciding which dCDN to select, e.g., "how well" a given dCDN
+   can actually serve a given end user request.  The dCDN's ability and
+   willingness to serve SHOULD be distinguished from the subjective
+   qualitative measurement of how well it can serve a given end user
+   request.  One can imagine that such additional information is
+   implicitly associated with a given footprint, due to contractual
+   agreements, Service Level Agreements (SLAs), business relationships,
+   or past perceptions of dCDN quality.  As an alternative, such
+   additional information could also be explicitly included with the
+   given footprint.
+
+   It is reasonable to assume that a significant part of the actual
+   footprint advertisement will occur out-of-band, prior to any CDNI FCI
+   advertisement, with footprints defined in contractual agreements
+   between participating CDNs.  The reason for this assumption is that
+   any contractual agreement is likely to contain specifics about the
+
+
+
+Seedorf, et al.              Standards Track                   [Page 25]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   dCDN coverage (footprint) to which the contractual agreement applies.
+   In particular, additional information to judge the delivery quality
+   associated with a given dCDN footprint might be defined in
+   contractual agreements, outside of the CDNI FCI.  Further, one can
+   assume that dCDN contractual agreements about the delivery quality
+   associated with a given footprint will probably be based on
+   high-level aggregated statistics and will not be too detailed.
+
+   Given that a large part of the footprint advertisement will be
+   defined in contractual agreements, the semantics of CDNI footprint
+   advertisement refer to answering the following question: what exactly
+   still needs to be advertised by the CDNI FCI?  For instance, updates
+   about temporal failures of part of a footprint can be useful
+   information to convey via the CDNI Request Routing interface.  Such
+   information would provide updates on information previously agreed
+   upon in contracts between the participating CDNs.  In other words,
+   the CDNI FCI is a means for a dCDN to provide changes/updates
+   regarding a footprint it has previously agreed to serve in a contract
+   with a uCDN.
+
+   Generally speaking, one can imagine two categories of footprints to
+   be advertised by a dCDN:
+
+   o  A footprint could be defined based on coverage/reachability, where
+      "coverage/reachability" refers to a set of prefixes, a geographic
+      region, or similar boundary.  The dCDN claims that it can
+      cover/reach "end user requests coming from this footprint".
+
+   o  A footprint could be defined based on resources, where "resources"
+      refers to Surrogates a dCDN claims to have (e.g., the location of
+      Surrogates/resources).  The dCDN claims that "from this footprint"
+      it can serve incoming end user requests.
+
+   For each of these footprint types, there are capabilities associated
+   with a given footprint:
+
+   o  capabilities such as delivery protocol, redirection mode, and
+      metadata, which are supported in the coverage area for a footprint
+      that is defined by coverage/reachability, or
+
+   o  capabilities of resources, such as delivery protocol, redirection
+      mode, and metadata, which apply to a footprint that is defined by
+      resources.
+
+   Resource footprint types are more specific than coverage/reachability
+   footprint types, where the actual coverage and reachability are
+   extrapolated from the resource location (e.g., a netmask applied to a
+   resource IP address to derive an IP prefix).  The specific methods
+
+
+
+Seedorf, et al.              Standards Track                   [Page 26]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   for extrapolating coverage/reachability from the resource location
+   are beyond the scope of this document.  In the degenerate case, the
+   resource address could be specified as a coverage/reachability
+   footprint type, in which case no extrapolation is necessary.
+   Resource footprint types could expose the internal structure of a
+   CDN; this could be undesirable.  As such, the resource footprint
+   types are not considered mandatory to support for CDNI.
+
+   Footprints can be viewed as constraints for delegating requests to a
+   dCDN: a dCDN footprint advertisement tells the uCDN the limitations
+   for 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
+   candidate only if the IP address of the Request Routing source falls
+   within the prefix set (or ASN, respectively).  The CDNI
+   specifications do not define how a given uCDN determines what address
+   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
+   the Request Routing source.  The CDNI specifications do not define
+   how a given uCDN determines the country of the Request Routing
+   source.  Multiple footprint constraints are additive: the
+   advertisement of different footprint types narrows the dCDN's
+   candidacy cumulatively.
+
+   Independent of the exact type of a footprint, a footprint might also
+   include the connectivity of a given dCDN to other CDNs that are able
+   to serve content to users on behalf of that dCDN, to cover cases with
+   cascaded CDNs.  Further, the dCDN needs to be able to express its
+   footprint to an interested uCDN in a comprehensive form, e.g., as a
+   data set containing the complete footprint.  However, making
+   incremental updates to express dynamic changes in state is also
+   desirable.
+
+Appendix C.  Semantics for Capabilities Advertisement
+
+   In general, the dCDN needs to be able to express its general
+   capabilities to the uCDN.  These general capabilities could indicate
+   if the dCDN supports a given service -- for instance, HTTP vs. HTTPS
+   delivery.  Furthermore, the dCDN needs to be able to express
+   particular capabilities for service delivery in a particular
+   footprint area.  For example, the dCDN might in general offer HTTPS
+   but not in some specific areas, either for maintenance reasons or
+   because the Surrogates covering this particular area cannot deliver
+   this type of service.  Hence, in certain cases a footprint and
+   capabilities are tied together and cannot be interpreted
+   independently of each other.  In such cases, i.e., where capabilities
+   need to be expressed on a per-footprint basis, it could be beneficial
+   to combine footprint advertisement and capabilities advertisement.
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 27]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   A high-level and very rough semantic for capabilities is thus the
+   following: capabilities are types of information that allow a uCDN to
+   determine if a dCDN is able (and willing) to accept (and properly
+   handle) a delegated content request.  In addition, capabilities are
+   characterized by the fact that this information can change over time
+   based on the state of the network or Surrogates.
+
+   At first glance, several broad categories of capabilities seem useful
+   to convey via an advertisement interface; however, advertising
+   capabilities that change highly dynamically (e.g., real-time delivery
+   performance metrics, CDN resource load, or other highly dynamically
+   changing QoS information) are beyond the scope of the CDNI FCI.
+   First, out of the multitude of possible metrics and capabilities, it
+   is hard to agree on a subset and the precise metrics to be used.
+   Second, it seems infeasible to specify such highly dynamically
+   changing capabilities and the corresponding metrics within a
+   reasonable time frame.
+
+   Useful capabilities refer to information that does not change highly
+   dynamically and that, in many cases, is absolutely necessary for
+   deciding on a particular dCDN for a given end user request.  For
+   instance, if an end user request concerns the delivery of a video
+   file with a certain protocol, the uCDN needs to know if a given dCDN
+   is capable of supporting this delivery protocol.
+
+   Similar to footprint advertisement, it is reasonable to assume that a
+   significant part of the actual (resource) capabilities advertisement
+   will also occur out-of-band, prior to any CDNI FCI advertisement,
+   with capabilities defined in contractual agreements between
+   participating CDNs.  The role of capability advertisement is hence
+   rather to enable the dCDN to update a uCDN on changes since a
+   contract has been set up (e.g., in case a new delivery protocol is
+   suddenly being added to the list of supported delivery protocols of a
+   given dCDN or in case a certain delivery protocol is suddenly not
+   being supported anymore due to failures).  "Capabilities
+   advertisement" thus refers to conveying information to a uCDN about
+   changes/updates to certain capabilities with respect to a given
+   contract.
+
+   Given these semantics, it needs to be decided what exact capabilities
+   are useful and how these can be expressed.  Since the details of CDNI
+   contracts are not known at the time of this writing (and the CDNI
+   interface is better off being agnostic to these contracts anyway), it
+   remains to be seen what capabilities will be used to define
+   agreements between CDNs in practice.  One implication for
+   standardization could be to initially only specify a very limited set
+   of mandatory capabilities for advertisement and have, on top of that,
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 28]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   a flexible data model that allows exchanging additional capabilities
+   when needed.  Still, agreement needs to be reached regarding which
+   capabilities (if any) will be mandatory among CDNs.
+
+   It is not feasible to enumerate all the possible options for the
+   mandatory capabilities listed above (e.g., all the potential delivery
+   protocols or metadata options) or anticipate all the future needs for
+   additional capabilities.  FCI object extensibility is necessary to
+   support future capabilities, as well as a generic protocol for
+   conveying any capability information (e.g., with common encoding,
+   error handling, and security mechanisms; further requirements for the
+   CDNI FCI are listed in [RFC7337]).
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 29]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+Acknowledgments
+
+   Jan Seedorf is partially supported by the GreenICN project
+   (GreenICN: Architecture and Applications of Green Information Centric
+   Networking), a research project supported jointly by the European
+   Commission under its 7th Framework Program (contract no. 608518) and
+   the National Institute of Information and Communications Technology
+   (NICT) in Japan (contract no. 167).  The views and conclusions
+   contained herein are those of the authors and should not be
+   interpreted as necessarily representing the official policies or
+   endorsements, either expressed or implied, of the GreenICN project,
+   the European Commission, or NICT.
+
+   Martin Stiemerling provided initial input to this document and
+   valuable comments to the ongoing discussions among the authors of
+   this document.  Thanks to Francois Le Faucheur and Scott Wainner for
+   providing valuable comments and suggestions for the text.
+
+Authors' Addresses
+
+   Jan Seedorf
+   HFT Stuttgart - University of Applied Sciences Stuttgart
+   Schellingstrasse 24
+   Stuttgart  70174
+   Germany
+
+   Phone: +49-0711-8926-2801
+   Email: jan.seedorf@hft-stuttgart.de
+
+
+   Jon Peterson
+   NeuStar
+   1800 Sutter St. Suite 570
+   Concord, CA  94520
+   United States of America
+
+   Email: jon.peterson@neustar.biz
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 30]
+
+RFC 8008        CDNI RR Footprint/Capabilities Semantics   December 2016
+
+
+   Stefano Previdi
+   Cisco Systems
+   Via Del Serafico 200
+   Rome  0144
+   Italy
+
+   Email: sprevidi@cisco.com
+
+
+   Ray van Brandenburg
+   TNO
+   Anna van Buerenplein 1
+   The Hague  2595DA
+   The Netherlands
+
+   Phone: +31-88-866-7000
+   Email: ray.vanbrandenburg@tno.nl
+
+
+   Kevin J. Ma
+   Ericsson
+   43 Nagog Park
+   Acton, MA  01720
+   United States of America
+
+   Phone: +1-978-844-5100
+   Email: kevin.j.ma@ericsson.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Seedorf, et al.              Standards Track                   [Page 31]
+