doc: Add RFC documents

1 files changed, 2048 insertions, 0 deletions

diff --git a/doc/rfc/rfc9241.txt b/doc/rfc/rfc9241.txt
new file mode 100644
index 0000000..d672cf4
--- /dev/null
+++ b/doc/rfc/rfc9241.txt
@@ -0,0 +1,2048 @@
+
+
+
+
+Internet Engineering Task Force (IETF)                        J. Seedorf
+Request for Comments: 9241                                 HFT Stuttgart
+Category: Standards Track                                        Y. Yang
+ISSN: 2070-1721                                          Yale University
+                                                                   K. Ma
+                                                                Ericsson
+                                                             J. Peterson
+                                                                 NeuStar
+                                                                J. Zhang
+                                                       Tongji University
+                                                               July 2022
+
+
+     Content Delivery Network Interconnection (CDNI) Footprint and
+Capabilities Advertisement Using Application-Layer Traffic Optimization
+                                 (ALTO)
+
+Abstract
+
+   The Content Delivery Networks Interconnection (CDNI) framework in RFC
+   6707 defines a set of protocols to interconnect CDNs to achieve
+   multiple goals, including extending the reach of a given CDN.  A CDNI
+   Request Routing Footprint & Capabilities Advertisement interface
+   (FCI) is needed to achieve the goals of a CDNI.  RFC 8008 defines the
+   FCI semantics and provides guidelines on the FCI protocol, but the
+   exact protocol is not specified.  This document defines a new
+   Application-Layer Traffic Optimization (ALTO) service, called "CDNI
+   Advertisement Service", that provides an implementation of the FCI,
+   following the guidelines defined in RFC 8008.
+
+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
+   https://www.rfc-editor.org/info/rfc9241.
+
+Copyright Notice
+
+   Copyright (c) 2022 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
+   (https://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 Revised BSD License text as described in Section 4.e of the
+   Trust Legal Provisions and are provided without warranty as described
+   in the Revised BSD License.
+
+Table of Contents
+
+   1.  Introduction
+   2.  Terminology and Background
+     2.1.  Terminology
+     2.2.  Semantics of FCI Advertisement
+     2.3.  ALTO Background and Benefits
+   3.  CDNI Advertisement Service
+     3.1.  Media Type
+     3.2.  HTTP Method
+     3.3.  Accept Input Parameters
+     3.4.  Capabilities
+     3.5.  Uses
+     3.6.  Response
+     3.7.  Examples
+       3.7.1.  IRD
+       3.7.2.  A Basic Example
+       3.7.3.  Incremental Updates
+   4.  CDNI Advertisement Service Using ALTO Network Map
+     4.1.  Network Map Footprint Type: altopid
+     4.2.  Examples
+       4.2.1.  ALTO Network Map for CDNI Advertisements
+       4.2.2.  ALTO PID Footprints in CDNI Advertisements
+       4.2.3.  Incremental Updates
+   5.  Filtered CDNI Advertisement Using CDNI Capabilities
+     5.1.  Media Type
+     5.2.  HTTP Method
+     5.3.  Accept Input Parameters
+     5.4.  Capabilities
+     5.5.  Uses
+     5.6.  Response
+     5.7.  Examples
+       5.7.1.  A Basic Example
+       5.7.2.  Incremental Updates
+   6.  Query Footprint Properties Using ALTO Property Map Service
+     6.1.  Representing Footprint Objects as Property Map Entities
+       6.1.1.  ASN Domain
+       6.1.2.  COUNTRYCODE Domain
+     6.2.  Representing CDNI Capabilities as Property Map Entity
+           Properties
+       6.2.1.  Defining Information Resource Media Type for Property
+               Type cdni-capabilities
+       6.2.2.  Intended Semantics of Property Type cdni-capabilities
+     6.3.  Examples
+       6.3.1.  Property Map
+       6.3.2.  Filtered Property Map
+       6.3.3.  Incremental Updates
+   7.  IANA Considerations
+     7.1.  application/alto-cdni+json Media Type
+     7.2.  application/alto-cdnifilter+json Media Type
+     7.3.  CDNI Metadata Footprint Types Registry
+     7.4.  ALTO Entity Domain Types Registry
+     7.5.  ALTO Entity Property Types Registry
+   8.  Security Considerations
+   9.  References
+     9.1.  Normative References
+     9.2.  Informative References
+   Acknowledgments
+   Contributors
+   Authors' Addresses
+
+1.  Introduction
+
+   The ability to interconnect multiple content delivery networks (CDNs)
+   has many benefits, including increased coverage, capability, and
+   reliability.  The Content Delivery Networks Interconnection (CDNI)
+   framework [RFC6707] defines four interfaces to interconnect CDNs: (1)
+   the CDNI Request Routing Interface, (2) the CDNI Metadata Interface,
+   (3) the CDNI Logging Interface, and (4) the CDNI Control Interface.
+
+   Among these four interfaces, the CDNI Request Routing Interface
+   provides key functions, as specified in [RFC6707]:
+
+   |  The CDNI Request Routing interface enables 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.  It also allows
+   |  the Downstream CDN to control what should be returned to the User
+   |  Agent in the redirection message by the upstream Request Routing
+   |  function.
+
+   At a high level, therefore, the scope of the CDNI Request Routing
+   Interface contains two main tasks: (1) determining if the dCDN
+   (downstream CDN) is willing to accept a delegated Content Request and
+   (2) redirecting the Content Request coming from a uCDN (upstream CDN)
+   to the proper entry point or entity in the dCDN.
+
+   Correspondingly, the Request Routing Interface is broadly divided
+   into two functionalities: (1) the CDNI Footprint & Capabilities
+   Advertisement interface (FCI) defined in [RFC8008] and (2) the CDNI
+   Request Routing Redirection interface (RI) defined in [RFC7975].
+   This document focuses on the first functionality (CDNI FCI).
+
+   Specifically, CDNI FCI allows both an Advertisement from a dCDN to a
+   uCDN (push) and a query from a uCDN to a dCDN (pull) so that the uCDN
+   knows whether it can redirect a particular user request to that dCDN.
+
+   A key component in defining the CDNI FCI is defining the objects that
+   describe the footprints and capabilities of a dCDN.  Such objects are
+   already specified in Section 5 of [RFC8008].  However, no protocol is
+   defined to transport and update such objects between a uCDN and a
+   dCDN.
+
+   To define such a protocol, this document specifies an extension of
+   the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285]
+   by introducing a new ALTO service called "CDNI Advertisement
+   Service".
+
+   Section 2.3 discusses the benefits in using ALTO as a transport
+   protocol.
+
+2.  Terminology and Background
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
+   "OPTIONAL" in this document are to be interpreted as described in
+   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
+   capitals, as shown here.
+
+   The design of CDNI FCI transport using ALTO assumes an understanding
+   of both FCI semantics and ALTO.  Hence, this document starts with a
+   non-normative review of both.
+
+2.1.  Terminology
+
+   The document uses the CDNI terms defined in [RFC6707], [RFC8006], and
+   [RFC8008].  Also, the document uses the ALTO terms defined in
+   [RFC7285] and [RFC9240].  This document uses the following
+   abbreviations:
+
+   ALTO:   Application-Layer Traffic Optimization
+
+   ASN:    Autonomous System Number
+
+   CDN:    Content Delivery Network
+
+   CDNI:   CDN Interconnection
+
+   dCDN:   Downstream CDN
+
+   FCI:    CDNI FCI, CDNI Request Routing Footprint & Capabilities
+           Advertisement interface
+
+   IRD:    Information Resource Directory in ALTO
+
+   PID:    Provider-defined Identifier in ALTO
+
+   uCDN:   Upstream CDN
+
+2.2.  Semantics of FCI Advertisement
+
+   [RFC8008] defines the semantics of CDNI FCI, provides guidance on
+   what footprint and capabilities mean in a CDNI context, and specifies
+   the requirements on the CDNI FCI transport protocol.  The definitions
+   in [RFC8008] depend on [RFC8006].  Below is a non-normative review of
+   key related points of [RFC8008] and [RFC8006].  For detailed
+   information and normative specification, the reader should refer to
+   these two RFCs.
+
+   *  Multiple types of mandatory-to-implement footprints (i.e.,
+      "ipv4cidr", "ipv6cidr", "asn", and "countrycode") are defined in
+      [RFC8006].  A "set of IP prefixes" can contain both full IP
+      addresses (i.e., a /32 for IPv4 or a /128 for IPv6) and IP
+      prefixes with an arbitrary prefix length.  There must also be
+      support for multiple IP address versions, i.e., IPv4 and IPv6, in
+      such a footprint.
+
+   *  Multiple initial types of capabilities are defined in [RFC8008]
+      including (1) Delivery Protocol, (2) Acquisition Protocol, (3)
+      Redirection Mode, (4) capabilities related to CDNI Logging, and
+      (5) capabilities related to CDNI Metadata.  They are required in
+      all cases and, therefore, considered as mandatory-to-implement
+      capabilities for all CDNI FCI implementations.
+
+   *  Footprint and capabilities are defined together and cannot be
+      interpreted independently from each other.  Specifically,
+      [RFC8008] integrates footprint and capabilities with an approach
+      of "capabilities with footprint restrictions", by expressing
+      capabilities on a per footprint basis.
+
+   *  Specifically, for all mandatory-to-implement footprint types,
+      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 Autonomous System Numbers (ASNs), 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.  Different
+      types of footprint constraints can be combined together to narrow
+      the dCDN candidacy, i.e., the uCDN should consider the dCDN a
+      candidate only if the request routing source satisfies all the
+      types of footprint constraints in the advertisement.
+
+   *  Given that a large part of Footprint and Capabilities
+      Advertisement may happen in contractual agreements, the semantics
+      of CDNI Footprint and Capabilities Advertisement refers 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 FCI.  Such information would provide updates
+      on information previously agreed to in contracts between the
+      participating CDNs.  In other words, the CDNI FCI is a means for a
+      dCDN to provide changes and updates regarding a footprint and/or
+      capabilities that it has previously agreed to serve in a contract
+      with a uCDN.  Hence, server push and incremental encoding will be
+      necessary techniques.
+
+2.3.  ALTO Background and Benefits
+
+   Application-Layer Traffic Optimization (ALTO) [RFC7285] defines an
+   approach for conveying network-layer (topology) information to
+   "guide" the resource provider selection process in distributed
+   applications that can choose among several candidate resources
+   providers to retrieve a given resource.  Usually, it is assumed that
+   an ALTO server conveys information that these applications cannot
+   measure or have difficulty measuring themselves [RFC5693].
+
+   Originally, ALTO was motivated by optimizing cross-ISP traffic
+   generated by peer-to-peer applications [RFC5693].  However, ALTO can
+   also be used for improving the Request Routing in CDNs.  In
+   particular, Section 5 of [RFC7971] explicitly mentions ALTO as a
+   candidate protocol to improve the selection of a CDN surrogate or
+   origin.
+
+   The following reasons make ALTO a suitable candidate protocol for
+   dCDN selection as part of CDNI Request Routing and, in particular,
+   for an FCI protocol:
+
+   *  Application-Layer-oriented: ALTO is a protocol specifically
+      designed to improve application-layer traffic (and application-
+      layer connections among hosts on the Internet) by providing
+      additional information to applications that these applications
+      could not easily retrieve themselves.  This matches the need of
+      CDNI, where a uCDN wants to improve application-layer CDN request
+      routing by using information (provided by a dCDN) that the uCDN
+      could not easily obtain otherwise.  Hence, ALTO can help a uCDN to
+      select a proper dCDN by first providing dCDNs' capabilities as
+      well as footprints (see Section 3) and then providing costs of
+      surrogates in a dCDN by ALTO cost maps.
+
+   *  Security: The identification between uCDNs and dCDNs is an
+      important requirement (see Section 8).  ALTO maps can be signed
+      and hence provide inherent origin protection.  Please see
+      Section 15.1.2 of [RFC7285] for detailed protection strategies.
+
+   *  RESTful design: The ALTO Protocol has undergone extensive
+      revisions in order to provide a RESTful design regarding the
+      client-server interaction specified by the protocol.  It is
+      flexible and extensible enough to handle existing and potential
+      future data formats defined by CDNI.  It can provide the
+      consistent client-server interaction model for other existing CDNI
+      interfaces or potential future extensions and therefore reduce the
+      learning cost for both users and developers, although they are not
+      in the scope of this document.  A CDNI FCI interface based on ALTO
+      would inherit this RESTful design.  Please see Section 3.
+
+   *  Error handling: The ALTO Protocol provides extensive error
+      handling in the whole request and response process (see
+      Section 8.5 of [RFC7285]).  A CDNI FCI interface based on ALTO
+      would inherit this extensive error-handling framework.  Please see
+      Section 5.
+
+   *  Map Service: The semantics of an ALTO network map is an exact
+      match for the needed information to convey a footprint by a dCDN,
+      in particular, if such a footprint is being expressed by IP prefix
+      ranges.  Please see Section 4.
+
+   *  Filtered Map Service: The ALTO map filtering service would allow a
+      uCDN to query only for parts of an ALTO map.  For example, the
+      ALTO filtered property Map Service can enable a uCDN to query
+      properties of a part of footprints efficiently.  Please see
+      Section 6.
+
+   *  Server-initiated notifications and incremental updates: When the
+      footprint or the capabilities of a dCDN change (i.e., unexpectedly
+      from the perspective of a uCDN), server-initiated notifications
+      would enable a dCDN to inform a uCDN about such changes directly.
+      Consider the case where -- due to failure -- part of the footprint
+      of the dCDN is not functioning, i.e., the CDN cannot serve content
+      to such clients with reasonable QoS.  Without server-initiated
+      notifications, the uCDN might still use a recent network and cost
+      map from the dCDN and therefore redirect requests to the dCDN that
+      it cannot serve.  Similarly, the possibility for incremental
+      updates would enable efficient conveyance of the aforementioned
+      (or similar) status changes by the dCDN to the uCDN.  The newest
+      design of ALTO supports server-pushed incremental updates
+      [RFC8895].
+
+   *  Content availability on hosts: A dCDN might want to express CDN
+      capabilities in terms of certain content types (e.g., codecs and/
+      or formats, or content from certain content providers).  ALTO
+      Entity Property Map [RFC9240] would enable a dCDN to make such
+      information available to a uCDN.  This would enable a uCDN to
+      assess whether a dCDN has the capabilities for a given type of
+      content requested.
+
+   *  Resource availability on hosts or links: The capabilities on links
+      (e.g., maximum bandwidth) or caches (e.g., average load) might be
+      useful information for a uCDN for optimized dCDN selection.  For
+      instance, if a uCDN receives a streaming request for content with
+      a certain bitrate, it needs to know if it is likely that a dCDN
+      can fulfill such stringent application-level requirements (i.e.,
+      can be expected to have enough consistent bandwidth) before it
+      redirects the request.  In general, if ALTO could convey such
+      information via ALTO Entity Property Map [RFC9240], it would
+      enable more sophisticated means for dCDN selection with ALTO.  The
+      ALTO Path Vector extension [ALTO-PATH-VECTOR] is designed to allow
+      ALTO clients to query information such as capacity regions for a
+      given set of flows.
+
+3.  CDNI Advertisement Service
+
+   The ALTO Protocol relies upon the ALTO information service framework,
+   which consists of multiple services.  All ALTO services are "provided
+   through a common transport protocol; messaging structure and
+   encoding; and transaction model" [RFC7285].  The ALTO Protocol
+   specification defines multiple initial services, e.g., the ALTO
+   Network Map Service and Cost Map Service.
+
+   This document defines a new ALTO service, called "CDNI Advertisement
+   Service", which conveys JSON [RFC8259] objects of media type
+   "application/alto-cdni+json".  These JSON objects are used to
+   transport BaseAdvertisementObject objects defined in [RFC8008].  This
+   document specifies how to transport such BaseAdvertisementObject
+   objects via the ALTO Protocol with the ALTO CDNI Advertisement
+   Service.  Similar to other ALTO services, this document defines the
+   ALTO information resource for the CDNI Advertisement Service as
+   follows.
+
+   Note that the encoding of BaseAdvertisementObject reuses the one
+   defined in [RFC8008] and therefore also follows the recommendations
+   of I-JSON (Internet JSON) [RFC7493], which is required by [RFC8008].
+
+3.1.  Media Type
+
+   The media type of the CDNI Advertisement resource is "application/
+   alto-cdni+json" (see Section 7).
+
+3.2.  HTTP Method
+
+   A CDNI Advertisement resource is requested using the HTTP GET method.
+
+3.3.  Accept Input Parameters
+
+   There are no applicable Accept Input parameters.
+
+3.4.  Capabilities
+
+   There are no applicable capabilities.
+
+3.5.  Uses
+
+   The "uses" field MUST NOT appear unless the CDNI Advertisement
+   resource depends on other ALTO information resources.  If the CDNI
+   Advertisement resource has dependent resources, the resource IDs of
+   its dependent resources MUST be included into the "uses" field.  This
+   document only defines one potential dependent resource for the CDNI
+   Advertisement resource.  See Section 4 for details of when and how to
+   use it.  Future documents may extend the CDNI Advertisement resource
+   and allow other dependent resources.
+
+3.6.  Response
+
+   The "meta" field of a CDNI Advertisement response MUST include the
+   "vtag" field defined in Section 10.3 of [RFC7285].  This field
+   provides the version of the retrieved CDNI FCI resource.
+
+   If a CDNI Advertisement response depends on other ALTO information
+   resources, it MUST include the "dependent-vtags" field, whose value
+   is an array to indicate the version tags of the resources used, where
+   each resource is specified in "uses" of its Information Resource
+   Directory (IRD) entry.
+
+   The data component of an ALTO CDNI Advertisement response is named
+   "cdni-advertisement", which is a JSON object of type
+   CDNIAdvertisementData:
+
+       object {
+         CDNIAdvertisementData cdni-advertisement;
+       } InfoResourceCDNIAdvertisement : ResponseEntityBase;
+
+       object {
+         BaseAdvertisementObject capabilities-with-footprints<0..*>;
+       } CDNIAdvertisementData;
+
+   Specifically, a CDNIAdvertisementData object is a JSON object that
+   includes only one property named "capabilities-with-footprints",
+   whose value is an array of BaseAdvertisementObject objects.  It
+   provides capabilities with footprint restrictions for the uCDN to
+   decide the dCDN selection.  If the value of this property is an empty
+   array, it means the corresponding dCDN cannot provide any mandatory-
+   to-implement CDNI capabilities for any footprints.
+
+   The syntax and semantics of BaseAdvertisementObject are well defined
+   in Section 5.1 of [RFC8008].  A BaseAdvertisementObject object
+   includes multiple properties, including "capability-type",
+   "capability-value", and "footprints", where "footprints" are defined
+   in Section 4.2.2.2 of [RFC8006].
+
+   An equivalent specification in the ALTO-style notation (see
+   Section 8.2 of [RFC7285]) creates a self-contained description of the
+   BaseAdvertisementObject.  As mentioned above, the normative
+   specification of BaseAdvertisementObject is in [RFC8008].
+
+       object {
+         JSONString capability-type;
+         JSONValue capability-value;
+         Footprint footprints<0..*>;
+       } BaseAdvertisementObject;
+
+       object {
+         JSONString footprint-type;
+         JSONString footprint-value<1..*>;
+       } Footprint;
+
+   For each BaseAdvertisementObject, the ALTO client MUST interpret
+   "footprints" appearing multiple times as if they appeared only once.
+   If "footprints" in a BaseAdvertisementObject is null or empty or does
+   not appear, the ALTO client MUST understand that the capabilities in
+   this BaseAdvertisementObject have the "global" coverage, i.e., the
+   corresponding dCDN can provide them for any Request Routing source.
+
+   Note: Further optimization of BaseAdvertisementObjects to effectively
+   provide the advertisement of capabilities with footprint restrictions
+   is certainly possible.  For example, these two examples below both
+   describe that the dCDN can provide capabilities ["http/1.1",
+   "https/1.1"] for the same footprints.  However, the latter one is
+   smaller in its size.
+
+   EXAMPLE 1
+       {
+         "meta": {...},
+         "cdni-advertisement": {
+           "capabilities-with-footprints": [
+             {
+               "capability-type": "FCI.DeliveryProtocol",
+               "capability-value": {
+                 "delivery-protocols": [
+                   "http/1.1"
+                 ]
+               },
+               "footprints": [
+                 <Footprint objects>
+               ]
+             },
+             {
+
+               "capability-type": "FCI.DeliveryProtocol",
+               "capability-value": {
+                 "delivery-protocols": [
+                   "https/1.1"
+                 ]
+               },
+               "footprints": [
+                 <Footprint objects>
+               ]
+             }
+           ]
+         }
+       }
+
+   EXAMPLE 2
+       {
+         "meta": {...},
+         "cdni-advertisement": {
+           "capabilities-with-footprints": [
+             {
+               "capability-type": "FCI.DeliveryProtocol",
+               "capability-value": {
+                 "delivery-protocols": [
+                   "https/1.1",
+                   "http/1.1"
+                 ]
+               },
+               "footprints": [
+                 <Footprint objects>
+               ]
+             }
+           ]
+         }
+       }
+
+   Since such optimizations are not required for the basic
+   interconnection of CDNs, the specifics of such mechanisms are outside
+   the scope of this document.
+
+   This document only requires the ALTO server to provide the initial
+   FCI-specific CDNI Payload Types defined in [RFC8008] as the
+   mandatory-to-implement CDNI capabilities.
+
+3.7.  Examples
+
+3.7.1.  IRD
+
+   Below is the IRD of a simple, example ALTO server.  The server
+   provides both base ALTO information resources (e.g., network maps)
+   and CDNI FCI-related information resources (e.g., CDNI Advertisement
+   resources), demonstrating a single, integrated environment.
+
+   Specifically, the IRD announces nine information resources as
+   follows:
+
+   *  two network maps,
+
+   *  one CDNI Advertisement resource without dependency,
+
+   *  one CDNI Advertisement resource depending on a network map,
+
+   *  one filtered CDNI Advertisement resource to be defined in
+      Section 5,
+
+   *  one property map including "cdni-capabilities" as its entity
+      property,
+
+   *  one filtered property map including "cdni-capabilities" and "pid"
+      as its entity properties, and
+
+   *  two update stream services:
+
+      -  one for updating CDNI Advertisement resources,
+
+      -  one for updating property maps
+
+    GET /directory HTTP/1.1
+    Host: alto.example.com
+    Accept: application/alto-directory+json,application/alto-error+json
+
+    HTTP/1.1 200 OK
+    Content-Length: 3531
+    Content-Type: application/alto-directory+json
+
+    {
+      "meta": {
+        "default-alto-network-map": "my-default-network-map"
+      },
+      "resources": {
+        "my-default-network-map": {
+          "uri": "https://alto.example.com/networkmap",
+          "media-type": "application/alto-networkmap+json"
+        },
+        "my-eu-netmap": {
+          "uri": "https://alto.example.com/myeunetmap",
+          "media-type": "application/alto-networkmap+json"
+        },
+        "my-default-cdnifci": {
+          "uri": "https://alto.example.com/cdnifci",
+          "media-type": "application/alto-cdni+json"
+        },
+        "my-cdnifci-with-pid-footprints": {
+          "uri": "https://alto.example.com/networkcdnifci",
+          "media-type": "application/alto-cdni+json",
+          "uses": [ "my-eu-netmap" ]
+        },
+        "my-filtered-cdnifci": {
+          "uri": "https://alto.example.com/cdnifci/filtered",
+          "media-type": "application/alto-cdni+json",
+          "accepts": "application/alto-cdnifilter+json"
+        },
+        "cdnifci-property-map": {
+          "uri": "https://alto.example.com/propmap/full/cdnifci",
+          "media-type": "application/alto-propmap+json",
+          "uses": [ "my-default-cdni" ],
+          "capabilities": {
+            "mappings": {
+              "ipv4": [ "my-default-cdni.cdni-capabilities" ],
+              "ipv6": [ "my-default-cdni.cdni-capabilities" ],
+              "countrycode": [
+                "my-default-cdni.cdni-capabilities" ],
+              "asn": [ "my-default-cdni.cdni-capabilities" ]
+            }
+          }
+        },
+        "filtered-cdnifci-property-map": {
+          "uri": "https://alto.example.com/propmap/lookup/cdnifci-pid",
+          "media-type": "application/alto-propmap+json",
+          "accepts": "application/alto-propmapparams+json",
+          "uses": [ "my-default-cdni", "my-default-network-map" ],
+          "capabilities": {
+            "mappings": {
+              "ipv4": [ "my-default-cdni.cdni-capabilities",
+                        "my-default-network-map.pid" ],
+              "ipv6": [ "my-default-cdni.cdni-capabilities",
+                        "my-default-network-map.pid" ],
+              "countrycode": [
+                "my-default-cdni.cdni-capabilities" ],
+              "asn": [ "my-default-cdni.cdni-capabilities" ]
+            }
+          }
+        },
+        "update-my-cdni-fci": {
+          "uri": "https://alto.example.com/updates/cdnifci",
+          "media-type": "text/event-stream",
+          "accepts": "application/alto-updatestreamparams+json",
+          "uses": [
+            "my-default-network-map",
+            "my-eu-netmap",
+            "my-default-cdnifci",
+            "my-filtered-cdnifci",
+            "my-cdnifci-with-pid-footprints"
+          ],
+          "capabilities": {
+            "incremental-change-media-types": {
+             "my-default-network-map": "application/json-patch+json",
+             "my-eu-netmap": "application/json-patch+json",
+             "my-default-cdnifci":
+             "application/merge-patch+json,application/json-patch+json",
+             "my-filtered-cdnifci":
+             "application/merge-patch+json,application/json-patch+json",
+             "my-cdnifci-with-pid-footprints":
+             "application/merge-patch+json,application/json-patch+json"
+            }
+          }
+        },
+        "update-my-props": {
+          "uri": "https://alto.example.com/updates/properties",
+          "media-type": "text/event-stream",
+          "uses": [
+            "cdnifci-property-map",
+            "filtered-cdnifci-property-map"
+          ],
+          "capabilities": {
+            "incremental-change-media-types": {
+             "cdnifci-property-map":
+             "application/merge-patch+json,application/json-patch+json",
+             "filtered-cdnifci-property-map":
+             "application/merge-patch+json,application/json-patch+json"
+            }
+          }
+        }
+      }
+    }
+
+3.7.2.  A Basic Example
+
+   This basic example demonstrates a simple CDNI Advertisement resource,
+   which does not depend on other resources.  There are three
+   BaseAdvertisementObjects in this resource and these objects'
+   capabilities are "http/1.1" delivery protocol, ["http/1.1",
+   "https/1.1"] delivery protocol, and "https/1.1" acquisition protocol,
+   respectively.
+
+     GET /cdnifci HTTP/1.1
+     Host: alto.example.com
+     Accept: application/alto-cdni+json,application/alto-error+json
+
+     HTTP/1.1 200 OK
+     Content-Length: 1411
+     Content-Type: application/alto-cdni+json
+
+     {
+       "meta": {
+         "vtag": {
+           "resource-id": "my-default-cdnifci",
+           "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
+         }
+       },
+       "cdni-advertisement": {
+         "capabilities-with-footprints": [
+           {
+             "capability-type": "FCI.DeliveryProtocol",
+             "capability-value": {
+               "delivery-protocols": [
+                 "http/1.1"
+               ]
+             },
+             "footprints": [
+               {
+                 "footprint-type": "ipv4cidr",
+                 "footprint-value": [ "192.0.2.0/24" ]
+               },
+               {
+                 "footprint-type": "ipv6cidr",
+                 "footprint-value": [ "2001:db8::/32" ]
+               }
+             ]
+           },
+           {
+             "capability-type": "FCI.DeliveryProtocol",
+             "capability-value": {
+               "delivery-protocols": [
+                 "https/1.1",
+                 "http/1.1"
+               ]
+             },
+             "footprints": [
+               {
+                 "footprint-type": "ipv4cidr",
+                 "footprint-value": [ "198.51.100.0/24" ]
+               }
+             ]
+           },
+           {
+             "capability-type": "FCI.AcquisitionProtocol",
+             "capability-value": {
+               "acquisition-protocols": [
+                 "https/1.1"
+               ]
+             },
+             "footprints": [
+               {
+                 "footprint-type": "ipv4cidr",
+                 "footprint-value": [ "203.0.113.0/24" ]
+               }
+             ]
+           }
+         ]
+       }
+     }
+
+3.7.3.  Incremental Updates
+
+   A benefit of using ALTO to provide CDNI Advertisement resources is
+   that such resources can be updated using ALTO incremental updates
+   [RFC8895].  Below is an example that also shows the benefit of having
+   both JSON merge patch and JSON patch to encode updates.
+
+   At first, an ALTO client requests updates for "my-default-cdnifci",
+   and the ALTO server returns the "control-uri" followed by the full
+   CDNI Advertisement response.  Then when there is a change in the
+   "delivery-protocols" in that "http/1.1" is removed (from ["http/1.1",
+   "https/1.1"] to only "https/1.1") due to maintenance of the
+   "http/1.1" clusters, the ALTO server regenerates the new CDNI
+   Advertisement resource and pushes the full replacement to the ALTO
+   client.  Later on, the ALTO server notifies the ALTO client that
+   "192.0.2.0/24" is added into the "ipv4" footprint object for delivery
+   protocol "https/1.1" by sending the change encoded by JSON patch to
+   the ALTO client.
+
+    POST /updates/cdnifci HTTP/1.1
+    Host: alto.example.com
+    Accept: text/event-stream,application/alto-error+json
+    Content-Type: application/alto-updatestreamparams+json
+    Content-Length: 94
+
+    {
+      "add": {
+        "my-cdnifci-stream": {
+          "resource-id": "my-default-cdnifci"
+        }
+      }
+    }
+
+    HTTP/1.1 200 OK
+    Connection: keep-alive
+    Content-Type: text/event-stream
+
+    event: application/alto-updatestreamcontrol+json
+    data: {"control-uri":
+    data: "https://alto.example.com/updates/streams/3141592653589"}
+
+    event: application/alto-cdni+json,my-cdnifci-stream
+    data: { ... full CDNI Advertisement resource ... }
+
+    event: application/alto-cdni+json,my-cdnifci-stream
+    data: {
+    data:   "meta": {
+    data:     "vtag": {
+    data:       "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716"
+    data:     }
+    data:   },
+    data:   "cdni-advertisement": {
+    data:     "capabilities-with-footprints": [
+    data:       {
+    data:         "capability-type": "FCI.DeliveryProtocol",
+    data:         "capability-value": {
+    data:           "delivery-protocols": [
+    data:             "https/1.1"
+    data:           ]
+    data:         },
+    data:         "footprints": [
+    data:           { "footprint-type": "ipv4cidr",
+    data:             "footprint-value": [ "203.0.113.0/24" ]
+    data:           }
+    data:         ]
+    data:       },
+    data:       { ... other CDNI advertisement object ... }
+    data:     ]
+    data:   }
+    data: }
+
+    event: application/json-patch+json,my-cdnifci-stream
+    data: [
+    data:   { "op": "replace",
+    data:     "path": "/meta/vtag/tag",
+    data:     "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
+    data:   },
+    data:   { "op": "add",
+    data:     "path": "/cdni-advertisement/capabilities-with-footprints
+    /0/footprints/0/footprint-value/-",
+    data:     "value": "192.0.2.0/24"
+    data:   }
+    data: ]
+
+4.  CDNI Advertisement Service Using ALTO Network Map
+
+4.1.  Network Map Footprint Type: altopid
+
+   The ALTO Protocol defines a concept called Provider-defined
+   Identifier (PID) to represent a group of IPv4 or IPv6 addresses to
+   which can be applied the same management policy.  The PID is an
+   alternative to the predefined CDNI footprint types (i.e., "ipv4cidr",
+   "ipv6cidr", "asn", and "countrycode").
+
+   To leverage this concept, this document defines a new CDNI Footprint
+   Type called "altopid".  A CDNI Advertisement resource can depend on
+   an ALTO network map resource and use "altopid" footprints to compress
+   its CDNI Footprint Payload.
+
+   Specifically, the "altopid" footprint type indicates that the
+   corresponding footprint value is a list of PIDNames as defined in
+   [RFC7285].  These PIDNames are references of PIDs in a network map
+   resource.  Hence a CDNI Advertisement resource using "altopid"
+   footprints depends on a network map.  For such a CDNI Advertisement
+   resource, the resource ID of its dependent network map MUST be
+   included in the "uses" field of its IRD entry, and the "dependent-
+   vtags" field with a reference to this network map MUST be included in
+   its response (see the example in Section 4.2.2).
+
+4.2.  Examples
+
+   The following examples use the same IRD given in Section 3.7.1.
+
+4.2.1.  ALTO Network Map for CDNI Advertisements
+
+   Below provides a sample network map whose resource ID is "my-eu-
+   netmap".  This map is referenced by the CDNI Advertisement example in
+   Section 4.2.2.
+
+    GET /myeunetmap HTTP/1.1
+    Host: alto.example.com
+    Accept: application/alto-networkmap+json,application/alto-error+json
+
+    HTTP/1.1 200 OK
+    Content-Length: 344
+    Content-Type: application/alto-networkmap+json
+
+    {
+      "meta": {
+        "vtag": [
+          { "resource-id": "my-eu-netmap",
+            "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
+          }
+        ]
+      },
+      "network-map": {
+        "south-france" : {
+          "ipv4": [ "192.0.2.0/24", "198.51.100.0/25" ],
+          "ipv6": [ "2001:db8::/32" ]
+        },
+        "germany": {
+          "ipv4": [ "203.0.113.0/24" ]
+        }
+      }
+    }
+
+4.2.2.  ALTO PID Footprints in CDNI Advertisements
+
+   This example shows a CDNI Advertisement resource that depends on a
+   network map described in Section 4.2.1.
+
+    GET /networkcdnifci HTTP/1.1
+    Host: alto.example.com
+    Accept: application/alto-cdni+json,application/alto-error+json
+
+    HTTP/1.1 200 OK
+    Content-Length: 736
+    Content-Type: application/alto-cdni+json
+
+    {
+      "meta": {
+        "dependent-vtags": [
+          {
+            "resource-id": "my-eu-netmap",
+            "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
+          }
+        ]
+      },
+      "cdni-advertisement": {
+        "capabilities-with-footprints": [
+          { "capability-type": "FCI.DeliveryProtocol",
+            "capability-value": [ "https/1.1" ],
+            "footprints": [
+              { "footprint-type": "altopid",
+                "footprint-value": [ "south-france" ]
+              }
+            ]
+          },
+          { "capability-type": "FCI.AcquisitionProtocol",
+            "capability-value": [ "https/1.1" ],
+            "footprints": [
+              { "footprint-type": "altopid",
+                "footprint-value": [ "germany", "south-france" ]
+              }
+            ]
+          }
+        ]
+      }
+    }
+
+4.2.3.  Incremental Updates
+
+   In this example, the ALTO client is interested in changes of "my-
+   cdnifci-with-pid-footprints" and its dependent network map "my-eu-
+   netmap".  Considering two changes, the first one is to change
+   footprints of the "https/1.1" delivery protocol capability, and the
+   second one is to remove the "south-france" PID from the footprints of
+   the "https/1.1" acquisition protocol capability.
+
+     POST /updates/cdnifci HTTP/1.1
+     Host: alto.example.com
+     Accept: text/event-stream,application/alto-error+json
+     Content-Type: application/alto-updatestreamparams+json
+     Content-Length: 185
+
+     {
+       "add": {
+         "my-eu-netmap-stream": {
+           "resource-id": "my-eu-netmap"
+         },
+         "my-netmap-cdnifci-stream": {
+           "resource-id": "my-cdnifci-with-pid-footprints"
+         }
+       }
+     }
+
+     HTTP/1.1 200 OK
+     Connection: keep-alive
+     Content-Type: text/event-stream
+
+     event: application/alto-updatestreamcontrol+json
+     data: {"control-uri":
+     data: "https://alto.example.com/updates/streams/3141592653590"}
+
+     event: application/alto-networkmap+json,my-eu-netmap-stream
+     data: { ... full Network Map of my-eu-netmap ... }
+
+     event: application/alto-cdnifci+json,my-netmap-cdnifci-stream
+     data: { ... full CDNI Advertisement resource ... }
+
+     event: application/json-patch+json,my-netmap-cdnifci-stream
+     data: [
+     data:   { "op": "replace",
+     data:     "path": "/meta/vtag/tag",
+     data:     "value": "dasdfa10ce8b059740bddsfasd8eb1d47853716"
+     data:   },
+     data:   { "op": "add",
+     data:     "path":
+     data:     "/cdni-advertisement/capabilities-with-footprints
+     /0/footprints/0/footprint-value/-",
+     data:     "value": "germany"
+     data:   }
+     data: ]
+
+     event: application/json-patch+json,my-netmap-cdnifci-stream
+     data: [
+     data:   { "op": "replace",
+     data:     "path": "/meta/vtag/tag",
+     data:     "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
+     data:   },
+     data:   { "op": "remove",
+     data:     "path":
+     data:     "/cdni-advertisement/capabilities-with-footprints
+     /1/footprints/0/footprint-value/1"
+     data:   }
+     data: ]
+
+5.  Filtered CDNI Advertisement Using CDNI Capabilities
+
+   Sections 3 and 4 describe the CDNI Advertisement Service that can be
+   used to enable a uCDN to get capabilities with footprint restrictions
+   from dCDNs.  However, since always getting full CDNI Advertisement
+   resources from dCDNs is inefficient, this document introduces a new
+   service named "Filtered CDNI Advertisement Service" to allow a client
+   to filter a CDNI Advertisement resource using a client-given set of
+   CDNI capabilities.  For each entry of the CDNI Advertisement
+   response, an entry will only be returned to the client if it contains
+   at least one of the client-given CDNI capabilities.  The relationship
+   between a filtered CDNI Advertisement resource and a CDNI
+   Advertisement resource is similar to the relationship between a
+   filtered network/cost map and a network/cost map.
+
+5.1.  Media Type
+
+   A filtered CDNI Advertisement resource uses the same media type
+   defined for the CDNI Advertisement resource in Section 3.1:
+   "application/alto-cdni+json".
+
+5.2.  HTTP Method
+
+   A filtered CDNI Advertisement resource is requested using the HTTP
+   POST method.
+
+5.3.  Accept Input Parameters
+
+   The input parameters for a filtered CDNI Advertisement resource are
+   supplied in the entity body of the POST request.  This document
+   specifies the input parameters with a data format indicated by the
+   media type "application/alto-cdnifilter+json", which is a JSON object
+   of type ReqFilteredCDNIAdvertisement where:
+
+      object {
+          JSONString capability-type;
+          JSONValue capability-value;
+      } CDNICapability;
+
+      object {
+          CDNICapability cdni-capabilities<0..*>;
+      } ReqFilteredCDNIAdvertisement;
+
+   with fields:
+
+   capability-type:  The same as Base Advertisement Object's
+      "capability-type" defined in Section 5.1 of [RFC8008].
+
+   capability-value:  The same as Base Advertisement Object's
+      "capability-value" defined in Section 5.1 of [RFC8008].
+
+   cdni-capabilities:  A list of CDNI capabilities defined in
+      Section 5.1 of [RFC8008] for which footprints are to be returned.
+      If this list is empty, the ALTO server MUST interpret it as a
+      request for the full CDNI Advertisement resource.  The ALTO server
+      MUST interpret entries appearing in this list multiple times as if
+      they appeared only once.  If the ALTO server does not define any
+      footprints for a CDNI capability, it MUST omit this capability
+      from the response.
+
+5.4.  Capabilities
+
+   There are no applicable capabilities.
+
+5.5.  Uses
+
+   The same rules as for the "uses" field of the CDNI Advertisement
+   resource apply (see Section 3.5).
+
+5.6.  Response
+
+   If the request is invalid, the response MUST indicate an error using
+   ALTO Protocol error handling specified in Section 8.5 of [RFC7285].
+
+   Specifically, a filtered CDNI Advertisement request is invalid if:
+
+   *  the value of "capability-type" is null;
+
+   *  the value of "capability-value" is null; or
+
+   *  the value of "capability-value" is inconsistent with "capability-
+      type".
+
+   When a request is invalid, the ALTO server MUST return an
+   "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285],
+   and the "value" field of the error message SHOULD indicate this CDNI
+   capability.
+
+   The ALTO server returns a filtered CDNI Advertisement resource for a
+   valid request.  The format of a filtered CDNI Advertisement resource
+   is the same as a full CDNI Advertisement resource (see Section 3.6).
+
+   The returned filtered CDNI Advertisement resource MUST contain all
+   the BaseAdvertisementObject objects satisfying the following
+   condition: the CDNI capability object of each included
+   BaseAdvertisementObject object MUST follow two constraints:
+
+   *  The "cdni-capabilities" field of the input includes a CDNI
+      capability object X having the same "capability-type" as it.
+
+   *  All the mandatory properties in its "capability-value" is a
+      superset of mandatory properties in "capability-value" of X
+      semantically.
+
+   See Section 5.7.1 for a concrete example.
+
+   The version tag included in the "vtag" field of the response MUST
+   correspond to the full CDNI Advertisement resource from which the
+   filtered CDNI Advertisement resource is provided.  This ensures that
+   a single, canonical version tag is used independently of any
+   filtering that is requested by an ALTO client.
+
+5.7.  Examples
+
+   The following examples use the same IRD example as in Section 3.7.1.
+
+5.7.1.  A Basic Example
+
+   This example filters the full CDNI Advertisement resource in
+   Section 3.7.2 by selecting only the "http/1.1" delivery protocol
+   capability.  Only the second BaseAdvertisementObject in the full
+   resource will be returned because the second object's capability is
+   "http/1.1" and "https/1.1" delivery protocols, which is the superset
+   of "https/1.1" delivery protocol.
+
+     POST /cdnifci/filtered HTTP/1.1
+     Host: alto.example.com
+     Accept: application/alto-cdni+json
+     Content-Type: application/cdnifilter+json
+     Content-Length: 176
+
+     {
+       "cdni-capabilities": [
+         {
+           "capability-type": "FCI.DeliveryProtocol",
+           "capability-value": {
+             "delivery-protocols": [ "https/1.1" ]
+           }
+         }
+       ]
+     }
+
+     HTTP/1.1 200 OK
+     Content-Length: 570
+     Content-Type: application/alto-cdni+json
+
+     {
+       "meta": {
+         "vtag": {
+           "resource-id": "my-filtered-cdnifci",
+           "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
+         }
+       },
+       "cdni-advertisement": {
+         "capabilities-with-footprints": [
+           {
+             "capability-type": "FCI.DeliveryProtocol",
+             "capability-value": {
+               "delivery-protocols": [
+                 "https/1.1",
+                 "http/1.1"
+               ]
+             },
+             "footprints": [
+               {
+                 "footprint-type": "ipv4cidr",
+                 "footprint-value": [ "198.51.100.0/24" ]
+               }
+             ]
+           }
+         ]
+       }
+     }
+
+5.7.2.  Incremental Updates
+
+   In this example, the ALTO client only cares about the updates of one
+   advertisement object for delivery protocol capability whose value
+   includes "https/1.1".  Thus, it adds its limitation of capabilities
+   in "input" field of the POST request.
+
+     POST /updates/cdnifci HTTP/1.1
+     Host: fcialtoupdate.example.com
+     Accept: text/event-stream,application/alto-error+json
+     Content-Type: application/alto-updatestreamparams+json
+     Content-Length: 346
+
+     {
+       "add": {
+         "my-filtered-fci-stream": {
+           "resource-id": "my-filtered-cdnifci",
+           "input": {
+             "cdni-capabilities": [
+               {
+                 "capability-type": "FCI.DeliveryProtocol",
+                 "capability-value": {
+                   "delivery-protocols": [ "https/1.1" ]
+                 }
+               }
+             ]
+           }
+         }
+       }
+     }
+
+     HTTP/1.1 200 OK
+     Connection: keep-alive
+     Content-Type: text/event-stream
+
+     event: application/alto-updatestreamcontrol+json
+     data: {"control-uri":
+     data: "https://alto.example.com/updates/streams/3141592653590"}
+
+     event: application/alto-cdni+json,my-filtered-fci-stream
+     data: { ... filtered CDNI Advertisement resource ... }
+
+     event: application/json-patch+json,my-filtered-fci-stream
+     data: [
+     data:   {
+     data:     "op": "replace",
+     data:     "path": "/meta/vtag/tag",
+     data:     "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
+     data:   },
+     data:   { "op": "add",
+     data:     "path":
+     data:     "/cdni-advertisement/capabilities-with-footprints
+     /0/footprints/0/footprint-value/-",
+     data:     "value": "192.0.2.0/24"
+     data:   }
+     data: ]
+
+6.  Query Footprint Properties Using ALTO Property Map Service
+
+   Besides the requirement of retrieving footprints of given
+   capabilities, another common requirement for uCDN is to query CDNI
+   capabilities of given footprints.
+
+   Considering each footprint as an entity with properties including
+   CDNI capabilities, a natural way to satisfy this requirement is to
+   use the ALTO property map as defined in [RFC9240].  This section
+   describes how ALTO clients look up properties for individual
+   footprints.  First, it describes how to represent footprint objects
+   as entities in the ALTO property map.  Then it describes how to
+   represent footprint capabilities as entity properties in the ALTO
+   property map.  Finally, it provides examples of the full property map
+   and the filtered property map supporting CDNI capabilities, and their
+   incremental updates.
+
+6.1.  Representing Footprint Objects as Property Map Entities
+
+   A footprint object has two properties: "footprint-type" and
+   "footprint-value".  A "footprint-value" is an array of footprint
+   values conforming to the specification associated with the registered
+   footprint type ("ipv4cidr", "ipv6cidr", "asn", "countrycode", and
+   "altopid").  Considering each ALTO entity defined in [RFC9240] also
+   has two properties: entity domain type and domain-specific
+   identifier, a straightforward approach to represent a footprint as an
+   ALTO entity is to represent its "footprint-type" as an entity domain
+   type, and its footprint value as a domain-specific identifier.
+
+   Each existing footprint type can be represented as an entity domain
+   type as follows:
+
+   *  According to [RFC9240], "ipv4" and "ipv6" are two predefined
+      entity domain types, which can be used to represent "ipv4cidr" and
+      "ipv6cidr" footprints respectively.  Note that both "ipv4" and
+      "ipv6" domains can include not only hierarchical addresses but
+      also individual addresses.  Therefore, a "ipv4cidr" or "ipv6cidr"
+      footprint with the longest prefix can also be represented by an
+      individual address entity.  When the uCDN receives a property map
+      with individual addresses in an "ipv4" or "ipv6" domain, it can
+      translate them as corresponding "ipv4cidr" or "ipv6cidr"
+      footprints with the longest prefix.
+
+   *  "pid" is also a predefined entity domain type, which can be used
+      to represent "altopid" footprints.  Note that "pid" is a resource-
+      specific entity domain.  To represent an "altopid" footprint, the
+      specifying information resource of the corresponding "pid" entity
+      domain MUST be the dependent network map used by the CDNI
+      Advertisement resource providing this "altopid" footprint.
+
+   *  However, no existing entity domain type can represent "asn" and
+      "countrycode" footprints.  To represent footprint-type "asn" and
+      "countrycode", this document registers two new entity domains in
+      Section 7 in addition to the ones in [RFC9240].
+
+   Here is an example of representing a footprint object of "ipv4cidr"
+   type as a set of "ipv4" entities in the ALTO property map.  The
+   representation of the footprint object of "ipv6cidr" type is similar.
+
+   { "footprint-type": "ipv4cidr",
+     "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"]
+   } --> "ipv4:192.0.2.0/24", "ipv4:198.51.100.0/24"
+
+   And here is an example of the corresponding footprint object of
+   "ipv4cidr" type represented by an individual address in an "ipv4"
+   domain in the ALTO property map.  The translation of the entities in
+   an "ipv6" domain is similar.
+
+   "ipv4:203.0.113.100" --> {
+     "footprint-type": "ipv4cidr",
+     "footprint-value": ["203.0.113.100/32"]
+   }
+
+6.1.1.  ASN Domain
+
+   The ASN domain associates property values with Autonomous Systems in
+   the Internet.
+
+6.1.1.1.  Entity Domain Type
+
+   The entity domain type of the ASN domain is "asn" (in lowercase).
+
+6.1.1.2.  Domain-Specific Entity Identifiers
+
+   The entity identifier of an entity in an ASN domain MUST be encoded
+   as a string consisting of the characters "as" (in lowercase) followed
+   by the ASN [RFC6793] as a decimal number without leading zeros.
+
+6.1.1.3.  Hierarchy and Inheritance
+
+   There is no hierarchy or inheritance for properties associated with
+   ASN.
+
+6.1.2.  COUNTRYCODE Domain
+
+   The COUNTRYCODE domain associates property values with countries.
+
+6.1.2.1.  Entity Domain Type
+
+   The entity domain type of the COUNTRYCODE domain is "countrycode" (in
+   lowercase).
+
+6.1.2.2.  Domain-Specific Entity Identifiers
+
+   The entity identifier of an entity in a COUNTRYCODE domain is encoded
+   as an ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase.
+
+6.1.2.3.  Hierarchy and Inheritance
+
+   There is no hierarchy or inheritance for properties associated with
+   country codes.
+
+6.2.  Representing CDNI Capabilities as Property Map Entity Properties
+
+   This document defines a new entity property type called "cdni-
+   capabilities".  An ALTO server can provide a property map resource
+   mapping the "cdni-capabilities" entity property type for a CDNI
+   Advertisement resource that it provides to an "ipv4", "ipv6", "asn",
+   or "countrycode" entity domain.
+
+6.2.1.  Defining Information Resource Media Type for Property Type cdni-
+        capabilities
+
+   The entity property type "cdni-capabilities" allows defining
+   resource-specific entity properties.  When resource-specific entity
+   properties are defined with entity property type "cdni-capabilities",
+   the defining information resource for a "cdni-capabilities" property
+   MUST be a CDNI Advertisement resource provided by the ALTO server.
+   The media type of the defining information resource for a "cdni-
+   capabilities" property is therefore:
+
+   application/alto-cdni+json
+
+6.2.2.  Intended Semantics of Property Type cdni-capabilities
+
+   The purpose of a "cdni-capabilities" property for an entity is to
+   indicate all the CDNI capabilities that a corresponding CDNI
+   Advertisement resource provides for the footprint represented by this
+   entity.  Thus, the value of a "cdni-capabilities" property MUST be a
+   JSON array.  Each element in a "cdni-capabilities" property MUST be a
+   JSON object in the format of CDNICapability (see Section 5.3).  The
+   value of a "cdni-capabilities" property for an "ipv4", "ipv6", "asn",
+   "countrycode", or "altopid" entity MUST include all the
+   CDNICapability objects satisfying the following conditions: (1) they
+   are provided by the defining CDNI Advertisement resource, and (2) the
+   represented footprint object of this entity is in their footprint
+   restrictions.
+
+6.3.  Examples
+
+   The following examples use the same IRD example given by
+   Section 3.7.1.
+
+6.3.1.  Property Map
+
+   This example shows a full property map in which entities are
+   footprints and entities' property is "cdni-capabilities".
+
+    GET /propmap/full/cdnifci HTTP/1.1
+    Host: alto.example.com
+    Accept: application/alto-propmap+json,application/alto-error+json
+
+    HTTP/1.1 200 OK
+    Content-Length: 1522
+    Content-Type: application/alto-propmap+json
+
+    {
+      "property-map": {
+        "meta": {
+          "dependent-vtags": [
+            { "resource-id": "my-default-cdnifci",
+              "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}
+          ]
+        },
+        "countrycode:us": {
+          "my-default-cdnifci.cdni-capabilities": [
+            { "capability-type": "FCI.DeliveryProtocol",
+              "capability-value": {
+                "delivery-protocols": ["http/1.1"]}}]
+        },
+        "ipv4:192.0.2.0/24": {
+          "my-default-cdnifci.cdni-capabilities": [
+            { "capability-type": "FCI.DeliveryProtocol",
+              "capability-value": {
+                "delivery-protocols": ["http/1.1"]}}]
+        },
+        "ipv4:198.51.100.0/24": {
+          "my-default-cdnifci.cdni-capabilities": [
+            { "capability-type": "FCI.DeliveryProtocol",
+              "capability-value": {
+                "delivery-protocols": ["https/1.1", "http/1.1"]}}]
+        },
+        "ipv4:203.0.113.0/24": {
+          "my-default-cdnifci.cdni-capabilities": [
+            { "capability-type": "FCI.AcquisitionProtocol",
+              "capability-value": {
+                "acquisition-protocols": ["http/1.1"]}}]
+        },
+        "ipv6:2001:db8::/32": {
+          "my-default-cdnifci.cdni-capabilities": [
+            { "capability-type": "FCI.DeliveryProtocol",
+              "capability-value": {
+                "delivery-protocols": ["http/1.1"]}}]
+        },
+        "asn:as64496": {
+          "my-default-cdnifci.cdni-capabilities": [
+            { "capability-type": "FCI.DeliveryProtocol",
+              "capability-value": {
+                "delivery-protocols": ["https/1.1", "http/1.1"]}}]
+        }
+      }
+    }
+
+6.3.2.  Filtered Property Map
+
+   This example uses the filtered property Map Service to get "pid" and
+   "cdni-capabilities" properties for two footprints "ipv4:192.0.2.0/24"
+   and "ipv6:2001:db8::/32".
+
+      POST /propmap/lookup/cdnifci-pid HTTP/1.1
+      Host: alto.example.com
+      Content-Type: application/alto-propmapparams+json
+      Accept: application/alto-propmap+json,application/alto-error+json
+      Content-Length: 181
+
+      {
+        "entities": [
+          "ipv4:192.0.2.0/24",
+          "ipv6:2001:db8::/32"
+        ],
+        "properties": [ "my-default-cdnifci.cdni-capabilities",
+                        "my-default-networkmap.pid" ]
+      }
+
+    HTTP/1.1 200 OK
+    Content-Length: 796
+    Content-Type: application/alto-propmap+json
+
+    {
+      "property-map": {
+        "meta": {
+          "dependent-vtags": [
+             {"resource-id": "my-default-cdnifci",
+               "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"},
+             {"resource-id": "my-default-networkmap",
+               "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"}
+          ]
+        },
+        "ipv4:192.0.2.0/24": {
+          "my-default-cdnifci.cdni-capabilities": [
+            {"capability-type": "FCI.DeliveryProtocol",
+             "capability-value": {"delivery-protocols": ["http/1.1"]}}],
+          "my-default-networkmap.pid": "pid1"
+        },
+        "ipv6:2001:db8::/32": {
+          "my-default-cdnifci.cdni-capabilities": [
+            {"capability-type": "FCI.DeliveryProtocol",
+             "capability-value": {"delivery-protocols": ["http/1.1"]}}],
+          "my-default-networkmap.pid": "pid3"
+        }
+      }
+    }
+
+6.3.3.  Incremental Updates
+
+   In this example, the ALTO client is interested in updates for the
+   properties "cdni-capabilities" and "pid" of two footprints
+   "ipv4:192.0.2.0/24" and "countrycode:fr".
+
+    POST /updates/properties HTTP/1.1
+    Host: alto.example.com
+    Accept: text/event-stream,application/alto-error+json
+    Content-Type: application/alto-updatestreamparams+json
+    Content-Length: 339
+
+    {
+      "add": {
+        "fci-propmap-stream": {
+          "resource-id": "filtered-cdnifci-property-map",
+          "input": {
+            "properties": [ "my-default-cdnifci.cdni-capabilities",
+                            "my-default-networkmap.pid" ],
+            "entities": [ "ipv4:192.0.2.0/24",
+                          "ipv6:2001:db8::/32" ]
+          }
+        }
+      }
+    }
+
+    HTTP/1.1 200 OK
+    Connection: keep-alive
+    Content-Type: text/event-stream
+
+    event: application/alto-updatestreamcontrol+json
+    data: {"control-uri":
+    data: "https://alto.example.com/updates/streams/1414213562373"}
+
+    event: application/alto-cdni+json,fci-propmap-stream
+    data: { ... filtered property map ... }
+
+    event: application/merge-patch+json,fci-propmap-stream
+    data: {
+    data:   "property-map": {
+    data:     "meta": {
+    data:       "dependent-vtags": [
+    data:         { "resource-id": "my-default-cdnifci",
+    data:           "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"},
+    data:         { "resource-id": "my-default-networkmap",
+    data:           "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"}
+    data:       ]
+    data:     },
+    data:     "ipv4:192.0.2.0/24": {
+    data:       "my-default-cdnifci.cdni-capabilities": [
+    data:         { "capability-type": "FCI.DeliveryProtocol",
+    data:           "capability-value": {
+    data:             "delivery-protocols": ["http/1.1", "https/1.1"]}}]
+    data:     }
+    data:   }
+    data: }
+
+    event: application/json-patch+json,fci-propmap-stream
+    data: [
+    data:   { "op": "replace",
+    data:     "path": "/meta/dependent-vtags/0/tag",
+    data:     "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4"
+    data:   },
+    data:   { "op": "replace",
+    data:     "path":
+    data:     "/property-map/countrycode:fr/my-default-networkmap.pid",
+    data:     "value": "pid5"
+    data:   }
+    data: ]
+
+7.  IANA Considerations
+
+   This document defines two new media types: "application/alto-
+   cdni+json", as described in Section 7.1, and "application/
+   cdnifilter+json", as described in Section 7.2.  It also defines a new
+   CDNI Metadata Footprint Type (Section 7.3), two new ALTO entity
+   domain types (Section 7.4), and a new ALTO entity property type
+   (Section 7.5).
+
+7.1.  application/alto-cdni+json Media Type
+
+   Type name:
+      application
+
+   Subtype name:
+      alto-cdni+json
+
+   Required parameters:
+      N/A
+
+   Optional parameters:
+      N/A
+
+   Encoding considerations:
+      Encoding considerations are identical to those specified for the
+      "application/json" media type.  See [RFC8259].
+
+   Security considerations:
+      Security considerations related to the generation and consumption
+      of ALTO Protocol messages are discussed in Section 15 of
+      [RFC7285].
+
+   Interoperability considerations:
+      N/A
+
+   Published specification:
+      Section 3 of RFC 9241
+
+   Applications that use this media type:
+      ALTO servers and ALTO clients [RFC7285] either stand alone or are
+      embedded within other applications that provide CDNI interfaces
+      for uCDNs or dCDNs.
+
+   Fragment identifier considerations:
+      N/A
+
+   Additional information:
+      Magic number(s):  N/A
+
+      File extension(s):  N/A
+
+      Macintosh file type code(s):  N/A
+
+   Person & email address to contact for further information:
+      See Authors' Addresses section.
+
+   Intended usage:
+      COMMON
+
+   Restrictions on usage:
+      N/A
+
+   Author:
+      See Authors' Addresses section.
+
+   Change controller:
+      Internet Engineering Task Force (iesg@ietf.org)
+
+7.2.  application/alto-cdnifilter+json Media Type
+
+   Type name:
+      application
+
+   Subtype name:
+      alto-cdnifilter+json
+
+   Required parameters:
+      N/A
+
+   Optional parameters:
+      N/A
+
+   Encoding considerations:
+      Encoding considerations are identical to those specified for the
+      "application/json" media type.  See [RFC8259].
+
+   Security considerations:
+      Security considerations related to the generation and consumption
+      of ALTO Protocol messages are discussed in Section 15 of
+      [RFC7285].
+
+   Interoperability considerations:
+      N/A
+
+   Published specification:
+      Section 5 of RFC 9241
+
+   Applications that use this media type:
+      ALTO servers and ALTO clients [RFC7285] either stand alone or are
+      embedded within other applications that provide CDNI interfaces
+      for uCDNs or dCDNs and supports CDNI capability-based filtering.
+
+   Fragment identifier considerations:
+      N/A
+
+   Additional information:
+      Magic number(s):  N/A
+
+      File extension(s):  N/A
+
+      Macintosh file type code(s):  N/A
+
+   Person & email address to contact for further information:
+      See Authors' Addresses section.
+
+   Intended usage:
+      COMMON
+
+   Restrictions on usage:
+      N/A
+
+   Author:
+      See Authors' Addresses section.
+
+   Change controller:
+      Internet Engineering Task Force (iesg@ietf.org)
+
+7.3.  CDNI Metadata Footprint Types Registry
+
+   This document updates the "CDNI Metadata Footprint Types" registry
+   created by Section 7.2 of [RFC8006].  A new footprint type, which is
+   listed in Table 1, has been registered.
+
+      +================+=====================+=====================+
+      | Footprint Type | Description         | Reference           |
+      +================+=====================+=====================+
+      | altopid        | A list of PID names | RFC 9241, Section 4 |
+      +----------------+---------------------+---------------------+
+
+                  Table 1: CDNI Metadata Footprint Type
+
+7.4.  ALTO Entity Domain Types Registry
+
+   This document updates the "ALTO Entity Domain Types" registry created
+   by Section 11.2 of [RFC9240].  Two new entity domain types, which are
+   listed in Table 2, have been registered.
+
+    +=============+============+=============+=============+=========+
+    | Identifier  | Entity     | Hierarchy   | Media Type  | Mapping |
+    |             | Identifier | and         | of Defining | to ALTO |
+    |             | Encoding   | Inheritance | Resource    | Address |
+    |             |            |             |             | Type    |
+    +=============+============+=============+=============+=========+
+    | asn         | See RFC    | None        | None        | false   |
+    |             | 9241,      |             |             |         |
+    |             | Section    |             |             |         |
+    |             | 6.1.1.2    |             |             |         |
+    +-------------+------------+-------------+-------------+---------+
+    | countrycode | See RFC    | None        | None        | false   |
+    |             | 9241,      |             |             |         |
+    |             | Section    |             |             |         |
+    |             | 6.1.2.2    |             |             |         |
+    +-------------+------------+-------------+-------------+---------+
+
+               Table 2: Additional ALTO Entity Domain Types
+
+7.5.  ALTO Entity Property Types Registry
+
+   This document updates the "ALTO Entity Property Types" registry
+   created by Section 11.3 of [RFC9240].  A new entity property type,
+   which is listed in Table 3, has been registered.
+
+      +===================+====================+===================+
+      | Identifier        | Intended Semantics | Media Type of     |
+      |                   |                    | Defining Resource |
+      +===================+====================+===================+
+      | cdni-capabilities | See RFC 9241,      | application/alto- |
+      |                   | Section 6.2        | cdni+json         |
+      +-------------------+--------------------+-------------------+
+
+              Table 3: Additional ALTO Entity Property Type
+
+8.  Security Considerations
+
+   As an extension of the base ALTO Protocol [RFC7285], this document
+   fits into the architecture of the base protocol, and hence Security
+   Considerations of the base protocol (Section 15 of [RFC7285]) fully
+   apply when this extension is provided by an ALTO server.
+
+   In the context of CDNI Advertisement, the following security risk
+   scenarios should be considered:
+
+   *  Authenticity and integrity of ALTO information: an attacker may
+      disguise itself as an ALTO server for a dCDN (e.g., by starting a
+      on-path attack) and provide false capabilities and footprints to a
+      uCDN using the CDNI Advertisement Service.  Such false information
+      may lead a uCDN to (1) select an incorrect dCDN to serve user
+      requests or (2) skip uCDNs in good conditions.  To address this
+      risk, protection strategies in Section 15.1.2 of [RFC7285] can be
+      applied.
+
+   *  Potential undesirable guidance from authenticated ALTO
+      information: a dCDN can provide a uCDN with limited capabilities
+      and smaller footprint coverage so that the dCDN can avoid
+      transferring traffic for a uCDN that they should have to transfer.
+      To reduce this risk, the protection strategies in Section 15.2.2
+      of [RFC7285] can be considered.
+
+   *  Confidentiality and privacy of ALTO information: footprint
+      properties integrated with ALTO property maps may expose network
+      location identifiers (e.g., IP addresses or fine-grained PIDs).
+      To address this risk, the protection strategy for risk types (1)
+      and (3) as described in Section 15.3 of [RFC7285] can be
+      considered.
+
+   *  For availability of ALTO services, an attacker may conduct
+      service-degradation attacks using services defined in this
+      document to disable ALTO services of a network.  It may request
+      potentially large, full CDNI Advertisement resources from an ALTO
+      server in a dCDN continuously in order to consume the bandwidth
+      resources of that ALTO server.  It may also query filtered
+      property Map Services with many smaller individual footprints in
+      order to consume the computation resources of the ALTO server.  To
+      mitigate these risks, the protection strategies in Section 15.5.2
+      of [RFC7285] can be applied.
+
+   Although protection strategies as described in Section 15 of
+   [RFC7285] should be applied to address aforementioned security and
+   privacy considerations, two special cases need to be included as
+   follows:
+
+   *  As required by Section 7 of [RFC8008],
+
+      |  All protocols that implement these capabilities and footprint
+      |  advertisement objects are REQUIRED to provide integrity and
+      |  authentication services.
+
+      Therefore, the uCDN (ALTO Client) MUST be authenticated to the
+      dCDN (ALTO Server).  And the dCDN (ALTO Server) MUST support HTTP
+      Digest Authentication [RFC7616] and MAY also support TLS mutual
+      authentication [RFC8446].  The authentication method will need to
+      be negotiated out of band and is out of scope for this document,
+      as is the approach for provisioning and managing these
+      credentials.
+
+   *  One specific information leakage risk introduced by this document
+      cannot be addressed by these strategies.  In particular, if a dCDN
+      A signs agreements with multiple uCDNs without any isolation, dCDN
+      A may disclose extra information of one uCDN to another one.  In
+      that case, one uCDN may redirect requests that should not have to
+      be served by dCDN A to dCDN A.
+
+      To reduce the risk, a dCDN SHOULD isolate full and/or filtered
+      CDNI Advertisement resources for different uCDNs.  It could
+      consider generating URIs of different full and/or filtered CDNI
+      Advertisement resources by hashing its company ID, a uCDN's
+      company ID as well as their agreements.  A dCDN SHOULD avoid
+      exposing all full and/or filtered CDNI Advertisement resources in
+      one of its IRDs.
+
+9.  References
+
+9.1.  Normative References
+
+   [ISO3166-1]
+              International Organization for Standardization, "Codes for
+              the representation of names of countries and their
+              subdivisions -- Part 1: Country codes", ISO 3166-1:2020,
+              August 2020.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119,
+              DOI 10.17487/RFC2119, March 1997,
+              <https://www.rfc-editor.org/info/rfc2119>.
+
+   [RFC6793]  Vohra, Q. and E. Chen, "BGP Support for Four-Octet
+              Autonomous System (AS) Number Space", RFC 6793,
+              DOI 10.17487/RFC6793, December 2012,
+              <https://www.rfc-editor.org/info/rfc6793>.
+
+   [RFC7285]  Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
+              Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
+              "Application-Layer Traffic Optimization (ALTO) Protocol",
+              RFC 7285, DOI 10.17487/RFC7285, September 2014,
+              <https://www.rfc-editor.org/info/rfc7285>.
+
+   [RFC7493]  Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
+              DOI 10.17487/RFC7493, March 2015,
+              <https://www.rfc-editor.org/info/rfc7493>.
+
+   [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
+              Digest Access Authentication", RFC 7616,
+              DOI 10.17487/RFC7616, September 2015,
+              <https://www.rfc-editor.org/info/rfc7616>.
+
+   [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,
+              <https://www.rfc-editor.org/info/rfc8006>.
+
+   [RFC8008]  Seedorf, J., Peterson, J., Previdi, S., van Brandenburg,
+              R., and K. Ma, "Content Delivery Network Interconnection
+              (CDNI) Request Routing: Footprint and Capabilities
+              Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016,
+              <https://www.rfc-editor.org/info/rfc8008>.
+
+   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
+              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
+              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
+
+   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
+              Interchange Format", STD 90, RFC 8259,
+              DOI 10.17487/RFC8259, December 2017,
+              <https://www.rfc-editor.org/info/rfc8259>.
+
+   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
+              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
+              <https://www.rfc-editor.org/info/rfc8446>.
+
+   [RFC8895]  Roome, W. and Y. Yang, "Application-Layer Traffic
+              Optimization (ALTO) Incremental Updates Using Server-Sent
+              Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
+              2020, <https://www.rfc-editor.org/info/rfc8895>.
+
+   [RFC9240]  Roome, W., Randriamasy, S., Yang, Y., Zhang, J., and K.
+              Gao, "An Extension for Application-Layer Traffic
+              Optimization (ALTO): Entity Property Maps", RFC 9240,
+              DOI 10.17487/RFC9240, July 2022,
+              <https://www.rfc-editor.org/info/rfc9240>.
+
+9.2.  Informative References
+
+   [ALTO-PATH-VECTOR]
+              Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
+              Zhang, "An ALTO Extension: Path Vector", Work in Progress,
+              Internet-Draft, draft-ietf-alto-path-vector-25, 20 March
+              2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
+              alto-path-vector-25>.
+
+   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
+              Optimization (ALTO) Problem Statement", RFC 5693,
+              DOI 10.17487/RFC5693, October 2009,
+              <https://www.rfc-editor.org/info/rfc5693>.
+
+   [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, <https://www.rfc-editor.org/info/rfc6707>.
+
+   [RFC7971]  Stiemerling, M., Kiesel, S., Scharf, M., Seidel, H., and
+              S. Previdi, "Application-Layer Traffic Optimization (ALTO)
+              Deployment Considerations", RFC 7971,
+              DOI 10.17487/RFC7971, October 2016,
+              <https://www.rfc-editor.org/info/rfc7971>.
+
+   [RFC7975]  Niven-Jenkins, B., Ed. and R. van Brandenburg, Ed.,
+              "Request Routing Redirection Interface for Content
+              Delivery Network (CDN) Interconnection", RFC 7975,
+              DOI 10.17487/RFC7975, October 2016,
+              <https://www.rfc-editor.org/info/rfc7975>.
+
+Acknowledgments
+
+   The authors thank Matt Caulfield, Danny Alex Lachos Perez, Daryl
+   Malas, and Sanjay Mishra for their timely reviews and invaluable
+   comments.  Big thanks also to the ALTO WG Chairs (Qin Wu and Vijay
+   Gurbani), all the directorate reviewers, and the IESG reviewers
+   (Martin Duke, Erik Kline, Martin Vigoureux, Murray Kucherawy, Roman
+   Danyliw, Zaheduzzaman Sarker, Éric Vyncke, and Francesca Palombini),
+   for their thorough reviews, discussions, guidance, and shepherding,
+   which further improve this document.
+
+   Jan Seedorf has been 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.
+
+   This document has also been supported by the Coordination Support
+   Action entitled 'Supporting European Experts Presence in
+   International Standardisation Activities in ICT' (StandICT.eu
+   <https://www.standict.eu/>) funded by the European Commission under
+   the Horizon 2020 Programme with Grant Agreement no. 780439.  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
+   European Commission.
+
+Contributors
+
+   Xiao Shawn Lin
+   Huawei
+   2222 Newjinqiao Rd
+   Shanghai
+   200125
+   China
+   Phone: +86-15316812351
+   Email: x.shawn.lin@gmail.com
+
+
+Authors' Addresses
+
+   Jan Seedorf
+   HFT Stuttgart - Univ. of Applied Sciences
+   Schellingstrasse 24
+   70174 Stuttgart
+   Germany
+   Phone: +49-0711-8926-2801
+   Email: jan.seedorf@hft-stuttgart.de
+
+
+   Y. Richard Yang
+   Yale University
+   51 Prospect Street
+   New Haven, CT 06511
+   United States of America
+   Phone: +1-203-432-6400
+   Email: yry@cs.yale.edu
+   URI:   http://www.cs.yale.edu/~yry/
+
+
+   Kevin J. Ma
+   Ericsson
+   43 Nagog Park
+   Acton, MA 01720
+   United States of America
+   Phone: +1-978-844-5100
+   Email: kevin.j.ma.ietf@gmail.com
+
+
+   Jon Peterson
+   NeuStar
+   1800 Sutter St., Suite 570
+   Concord, CA 94520
+   United States of America
+   Email: jon.peterson@neustar.biz
+
+
+   Jingxuan Jensen Zhang
+   Tongji University
+   4800 Cao'an Hwy
+   Shanghai
+   201804
+   China
+   Email: jingxuan.zhang@tongji.edu.cn