<?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.5.6 --> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc iprnotified="no"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?> [
 <!ENTITY nbsp    "&#160;">
 <!ENTITY zwsp   "&#8203;">
 <!ENTITY nbhy   "&#8209;">
 <!ENTITY wj     "&#8288;">
]>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-alto-cdni-request-routing-alto-22" category="std" number="9241" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" sortRefs="true" symRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.6.0 -->
  <front>
<!-- [rfced] Title: May we expand the ALTO acronym in the title?

Current:

   Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement Using ALTO

Perhaps:

   Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)

-->

    <title abbrev="CDNI FCI using Using ALTO">Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using Using ALTO</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-alto-cdni-request-routing-alto-22"/> name="RFC" value="9241"/>
    <author initials="J." surname="Seedorf" fullname="Jan Seedorf">

<!--[rfced] Jan, would you like to provide an abbreviated organization
name? If provided, then it would be used in the first-page header of
the text file to prevent the overlap shown below.
(The full organization name would still appear in the Authors' Addresses.)

Current:

Internet Engineering Task Force (IETF)                        J. Seedorf
Request for Comments: 9241     HFT Stuttgart - Univ. of Applied Sciences
Category: Standards Track                                        Y. Yang
ISSN: 2070-1721                                          Yale University
                                                                   K. Ma
-->
      <organization>HFT Stuttgart - Univ. of Applied Sciences</organization>
      <address>
        <postal>
          <street>Schellingstrasse 24</street>
          <city>Stuttgart</city>
          <code>70174</code>
          <country>Germany</country>
        </postal>
        <phone>+49-0711-8926-2801</phone>
        <email>jan.seedorf@hft-stuttgart.de</email>
      </address>
    </author>
    <author initials="Y." surname="Yang" fullname="Y. Richard Yang">
      <organization>Yale University</organization>
      <address>
        <postal>
          <street>51 Prospect Street</street>
          <city>New Haven</city>
          <code>CT 06511</code>
          <region>CT</region>
          <code>06511</code>
          <country>USA</country>
        </postal>
        <phone>+1-203-432-6400</phone>
        <email>yry@cs.yale.edu</email>
        <uri>http://www.cs.yale.edu/~yry/</uri>
      </address>
    </author>
    <author initials="K." surname="Ma" fullname="Kevin J. Ma">
      <organization>Ericsson</organization>
      <address>
        <postal>
          <street>43 Nagog Park</street>
          <city>Acton</city>
          <code>MA 01720</code>
          <region>MA</region>
          <code>01720</code>
          <country>USA</country>
        </postal>
        <phone>+1-978-844-5100</phone>
        <email>kevin.j.ma.ietf@gmail.com</email>
      </address>
    </author>
    <author initials="J." surname="Peterson" fullname="Jon Peterson">
      <organization>NeuStar</organization>
      <address>
        <postal>
          <street>1800 Sutter St St., Suite 570</street>
          <city>Concord</city>
          <code>CA 94520</code>
          <region>CA</region>
          <code>94520</code>
          <country>USA</country>
        </postal>
        <email>jon.peterson@neustar.biz</email>
      </address>
    </author>
    <author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang">
      <organization>Tongji University</organization>
      <address>
        <postal>
          <street>4800 Cao'an Hwy</street>
          <city>Shanghai</city>
          <code>201804</code>
          <country>China</country>
        </postal>
        <email>jingxuan.zhang@tongji.edu.cn</email>
      </address>
    </author>
    <date year="2022" month="February" day="17"/>
    <area>Networks</area>
    <workgroup>ALTO &amp; CDNI WGs</workgroup> month="May"/>
    <area>tsv</area>
    <workgroup>ALTO</workgroup>
    <keyword>ALTO</keyword>
    <abstract>
      <!-- Skip header line -->

<t>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
&amp; 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.</t>
<!-- [rfced] FYI, we found comments left by the authors in the XML file. We have marked these comments with [auth] for your review. Note that these comments will be removed before publication. Please let us know of any concerns.
-->
      <!-- [auth]
The Content Delivery Networks Interconnection (CDNI) framework
defines a set of protocols to interconnect CDNs, to achieve multiple
goals such as extending the reach of a given CDN to areas that are
not covered by that particular CDN. One component that is needed to
achieve the goal of CDNI described in CDNI framework is the CDNI
Request Routing Footprint &amp; Capabilities Advertisement interface
(FCI). RFC 8008 defines precisely the semantics of FCI and provides
guidelines on the FCI protocol, but the exact protocol is explicitly
outside the scope of that document. 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.
-->

    </abstract>
  </front>
  <middle>
    <!-- Skip header line -->

<section anchor="intro" numbered="true" toc="default">
      <name>Introduction</name>
<!-- [rfced] Please review the use of numbering within paragraphs and let us know if we may convert the numbered items to numbered lists.
-->
      <t>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 <xref target="RFC6707" format="default"/> 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.</t>
      <t>Among these four interfaces, the CDNI Request Routing Interface
provides key functions, as specified in <xref target="RFC6707" format="default"/>:
"The format="default"/>:</t>
      <blockquote>
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 function.</blockquote>
      <t>At a high level, therefore, the scope of the CDNI Request Routing Interface,
therefore, Interface
contains two main tasks: (1) determining if the dCDN
(downstream CDN) is willing to accept a delegated content request, request
and (2) redirecting the content request coming from a uCDN (upstream
CDN) to the proper entry point or entity in the dCDN.</t>
      <t>Correspondingly, the Request Routing Interface is broadly divided
into two functionalities: (1) the CDNI Footprint &amp; Capabilities
Advertisement interface (FCI) defined in <xref target="RFC8008" format="default"/>, format="default"/>
and (2) the CDNI Request Routing Redirection interface (RI) defined
in <xref target="RFC7975" format="default"/>. This document focuses on the
first functionality (CDNI FCI).</t>
      <t>Specifically, CDNI FCI allows both an advertisement 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.</t>
      <t>A key component in defining the CDNI FCI is defining the objects describing that describe the
footprints and capabilities of a dCDN. Such objects are already defined specified in
Section 5 of
<xref target="RFC8008" section="5" sectionFormat="of" format="default"/>. However, no protocol is defined to transport and
update such objects between a uCDN and a dCDN.</t>
      <t>To define such a protocol, this document specifies an extension of the
Application-Layer Traffic Optimization (ALTO) Protocol <xref target="RFC7285" format="default"/> protocol by
introducing a new ALTO service called "CDNI Advertisement Service".</t>
      <t><xref target="bgALTO" format="default"/> discusses the benefits in using ALTO as a transport protocol.</t>
      <!-- [auth]
The rest of this document is organized as follows. [](#background) provides
non-normative background on both CDNI FCI and ALTO. [](#cdnifci) introduces the
most basic service, called "CDNI Advertisement Service", to realize CDNI FCI
using ALTO. [](#cdnifcinetworkmap) demonstrates a key benefit of using ALTO: the
ability to integrate CDNI FCI with ALTO network maps. Such integration provides
new granularity to describe footprints. [](#filteredcdnifci) introduces
"Filtered CDNI Advertisement Service" to allow a uCDN to get footprints with
given capabilities instead of getting the full resource, which can be large.
[](#unifiedpropertymap) further shows another benefit of using ALTO: the ability
to query footprint properties using ALTO entity property map extension. In this
way, a uCDN can effectively fetch capabilities of footprints in which it is
interested. IANA and security considerations are discussed in [](#iana) and
[](#security) respectively.
-->

<!-- Skip header line -->

</section>
    <section anchor="background" numbered="true" toc="default">
      <name>Terminology and Background</name>
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
"<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>"
in this document are to be interpreted as described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/><xref target="RFC8174" format="default"/> target="RFC2119"/>
<xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
      <t>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
for
of both.</t>
      <section anchor="term" numbered="true" toc="default">
        <name>Terminology</name>
        <t>The document uses the CDNI terms defined in <xref target="RFC6707" format="default"/>, <xref target="RFC8006" format="default"/> format="default"/>, and
<xref target="RFC8008" format="default"/>. Also, the document uses the ALTO terms defined in <xref target="RFC7285" format="default"/> and
<xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>. This document uses the following
abbreviations:</t>
        <ul spacing="normal">
          <li>ALTO: Application-Layer
        <dl spacing="normal" indent="8">
          <dt>ALTO:</dt>
          <dd>Application-Layer Traffic Optimization</li>
          <li>ASN: Autonomous Optimization</dd>
          <dt>ASN:</dt>
          <dd>Autonomous System Number</li>
          <li>CDN: Content Number</dd>
          <dt>CDN:</dt>
          <dd>Content Delivery Network</li>
          <li>CDNI: CDN Interconnection</li>
          <li>dCDN: Downstream CDN</li>
          <li>FCI: CDNI Network</dd>
          <dt>CDNI:</dt>
          <dd>CDN Interconnection</dd>
          <dt>dCDN:</dt>
          <dd>Downstream CDN</dd>
          <dt>FCI:</dt>
          <dd>CDNI FCI, CDNI Request Routing Footprint &amp; Capabilities Advertisement interface</li>
          <li>IRD: Information interface</dd>
          <dt>IRD:</dt>
          <dd>Information Resource Directory in ALTO</li>
          <li>PID: Provider-defined ALTO</dd>
          <dt>PID:</dt>
          <dd>Provider-defined Identifier in ALTO</li>
          <li>uCDN: Upstream CDN</li>
        </ul> ALTO</dd>
          <dt>uCDN:</dt><dd>Upstream CDN</dd>
        </dl>
      </section>
      <section anchor="bgSemantics" numbered="true" toc="default">
        <name>Semantics of FCI Advertisement</name>
        <t><xref target="RFC8008" format="default"/> defines the semantics
of CDNI FCI, provides guidance on what Footprint footprint and Capabilities capabilities mean in a CDNI
context, and specifies the requirements on the CDNI FCI transport protocol. The
definitions in <xref target="RFC8008" format="default"/> depend on <xref target="RFC8006" format="default"/>. Below is a non-normative
review of key related points of <xref target="RFC8008" format="default"/> and <xref target="RFC8006" format="default"/>. For detailed
information and normative specification, the reader should refer to these two
RFCs.</t>
        <ul spacing="normal">
          <li>Multiple types of mandatory-to-implement footprints (i.e., ipv4cidr, ipv6cidr, asn, "ipv4cidr", "ipv6cidr", "asn",
and countrycode) "countrycode") are defined in <xref target="RFC8006" format="default"/>. A "Set "set of IP-prefixes" 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.</li>
          <li>Multiple initial types of capabilities are defined in <xref target="RFC8008" format="default"/> including
(1) Delivery Protocol, (2) Acquisition Protocol, (3) Redirection Mode, (4)
Capabilities
capabilities related to CDNI Logging, and (5) Capabilities capabilities related to CDNI
Metadata. They are required in all cases and, therefore, considered as
mandatory-to-implement capabilities for all CDNI FCI implementations.</li>
          <li>Footprint and capabilities are defined together and cannot be interpreted
independently from each other. Specifically, <xref target="RFC8008" format="default"/> integrates footprint
and capabilities with an approach of "capabilities with footprint
restrictions", by expressing capabilities on a per footprint basis.</li>
          <li>Specifically, for all mandatory-to-implement footprint types, footprints can
be viewed as constraints for delegating requests to a dCDN: A 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.</li>
          <li>Given that a large part of Footprint and Capabilities Advertisement may
happen in contractual agreements, the semantics of CDNI Footprint and
Capabilities advertisement 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/updates 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.</li>
        </ul>
      </section>
      <section anchor="bgALTO" numbered="true" toc="default">
        <name>ALTO Background and Benefits</name>
        <t>Application-Layer Traffic Optimization (ALTO) <xref target="RFC7285" format="default"/> defines an approach
for conveying network layer 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 <xref target="RFC5693" format="default"/>.</t>
        <t>Originally, ALTO was motivated by optimizing cross-ISP traffic generated by P2P peer-to-peer
applications <xref target="RFC5693" format="default"/>. However, ALTO can also be used for improving the
request routing in CDNs. In particular, Section 5 of <xref target="RFC7971" section="5" sectionFormat="of" format="default"/>
explicitly mentions ALTO as a candidate protocol to improve the selection of a
CDN surrogate or origin.</t>
        <t>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:</t>
        <ul spacing="normal">
          <li>Application Layer-oriented:
          <li>Application-Layer-oriented: ALTO is a protocol specifically designed to
improve application layer application-layer traffic (and application layer 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 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 <xref target="cdnifci" format="default"/>) and
then providing costs of surrogates in a dCDN by ALTO cost maps.</li>
          <li>Security: The identification between uCDNs and dCDNs is an important
requirement (see <xref target="security" format="default"/>). ALTO maps can be signed and hence provide
inherent origin protection. Please see Section 15.1.2 of <xref target="RFC7285" section="15.1.2" sectionFormat="of" format="default"/> for
detailed protection strategies.</li>
          <li>RESTful design: The ALTO protocol 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 <xref target="cdnifci" format="default"/>.</li>
          <li>Error-handling:
          <li>Error handling: The ALTO protocol Protocol provides extensive error-handling error handling in the
whole request and response process (see Section 8.5 of <xref target="RFC7285" section="8.5" sectionFormat="of" format="default"/>). A CDNI
FCI interface based on ALTO would inherit this extensive error-handling
framework. Please see <xref target="filteredcdnifci" format="default"/>.</li>
          <li>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 IP prefix
ranges. Please see <xref target="cdnifcinetworkmap" format="default"/>.</li>
          <li>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 <xref target="unifiedpropertymap" format="default"/>.</li>
          <li>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,
dCDN and therefore redirect requests to the dCDN which 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 server-pushed incremental updates
<xref target="RFC8895" format="default"/>.</li>
          <li>Content availability on hosts: A dCDN might want to express CDN capabilities
in terms of certain content types (e.g., codecs/ codecs and/or formats, or content from
certain content providers). ALTO Entity Property Map
<xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/> would enable a dCDN to make such
information available to a uCDN. This would enable a uCDN to access assess whether
a dCDN has the capabilities for a given type of content requested.</li>
          <li>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 <xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>,
it would enable more sophisticated means for dCDN selection with ALTO. The ALTO
Path Vector Extension extension <xref target="I-D.ietf-alto-path-vector" format="default"/> is designed to allow ALTO
clients to query information such as capacity regions for a given set of
flows.
<!-- Skip header line -->
          </li>
        </ul>
      </section>
    </section>
    <section anchor="cdnifci" numbered="true" toc="default">
      <name>CDNI Advertisement Service</name>
      <t>The ALTO protocol Protocol relies upon the ALTO Information Service framework information service framework, which
consists of multiple services. All ALTO services are "provided through a common
transport protocol, protocol; messaging structure and encoding, encoding; and transaction
model" <xref target="RFC7285" format="default"/>. The ALTO protocol Protocol specification defines multiple
initial services, e.g., the ALTO network map service and cost map service.</t>

      <t>This document defines a new ALTO service, called "CDNI Advertisement Service",
which conveys JSON <xref target="RFC8259" format="default"/> objects of media type "application/alto-cdni+json". These
JSON objects are used to transport BaseAdvertisementObject objects defined in
<xref target="RFC8008" format="default"/>. This document specifies how to transport such
BaseAdvertisementObject objects via the ALTO protocol 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.</t>
      <t>Note that the encoding of BaseAdvertisementObject reuses the one
defined in <xref target="RFC8008" format="default"/> and therefore also follows the recommendations of I-JSON
(Internet JSON) <xref target="RFC7493" format="default"/>, which is required by <xref target="RFC8008" format="default"/>.</t>
      <section anchor="cdnifcimediatype" numbered="true" toc="default">
        <name>Media Type</name>
        <t>The media type of the CDNI Advertisement resource is
"application/alto-cdni+json" (see <xref target="iana" format="default"/>).</t>
      </section>
      <section anchor="cdnifcimethod" numbered="true" toc="default">
        <name>HTTP Method</name>
        <t>A CDNI Advertisement resource is requested using the HTTP GET method.</t>
      </section>
      <section anchor="cdnifciinput" numbered="true" toc="default">
        <name>Accept Input Parameters</name>
        <t>There are no applicable Accept Input parameters.</t>
      </section>
      <section anchor="cdnifcicap" numbered="true" toc="default">
        <name>Capabilities</name>
        <t>There are no applicable capabilities.</t>
      </section>
      <section anchor="cdnifciuses" numbered="true" toc="default">
        <name>Uses</name>
        <t>The "uses" field MUST NOT <bcp14>MUST NOT</bcp14> 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 <bcp14>MUST</bcp14> be included into the "uses" field. This
document only defines one potential dependent resource for the CDNI
Advertisement resource. See <xref target="cdnifcinetworkmap" format="default"/> for details
of when and how to use it. Future documents may extend the CDNI Advertisement
resource and allow other dependent resources.</t>
      </section>
      <section anchor="cdnifciencoding" numbered="true" toc="default">
        <name>Response</name>
        <t>The "meta" field of a CDNI Advertisement response MUST <bcp14>MUST</bcp14> include the "vtag"
field defined in Section 10.3 of <xref target="RFC7285" section="10.3" sectionFormat="of" format="default"/>. This
field provides the version of the retrieved CDNI FCI resource.</t>
        <t>If a CDNI Advertisement response depends on other ALTO information resources, it
MUST
<bcp14>MUST</bcp14> 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.</t>
        <t>The data component of an ALTO CDNI Advertisement response is named
"cdni-advertisement", which is a JSON object of type CDNIAdvertisementData:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
<!-- [rfced] Please review the "type" attribute of each sourcecode element in
the XML file to ensure correctness. If the current list of preferred
values for "type"(https://www.rfc-editor.org/materials/sourcecode-types.txt)
does not contain an applicable type, then feel free to let us know. Also, it
is acceptable to leave the "type" attribute not set.

In addition, review each artwork element. Specifically, should any artwork element be tagged as sourcecode or another element?
 -->
        <sourcecode type="json"><![CDATA[
    object {
      CDNIAdvertisementData cdni-advertisement;
    } InfoResourceCDNIAdvertisement : ResponseEntityBase;

    object {
      BaseAdvertisementObject capabilities-with-footprints<0..*>;
    } CDNIAdvertisementData;
]]></artwork>
]]></sourcecode>
        <t>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.</t>
        <t>The syntax and semantics of BaseAdvertisementObject are well defined in Section
5.1 of
<xref target="RFC8008" section="5.1" sectionFormat="of" format="default"/>. A BaseAdvertisementObject object includes multiple
properties, including capability-type, capability-value, and footprints, where
footprints are defined in Section 4.2.2.2 of <xref target="RFC8006" section="4.2.2.2" sectionFormat="of" format="default"/>.</t>
        <t>To
<!-- [rfced] Section 3.6. It is unclear what is to be self-contained in the sentence below:

Current:
   To be self-contained, below is an equivalent specification of
   BaseAdvertisementObject described in the ALTO-style notation (see
   Section 8.2 of [RFC7285]).

Perhaps:
   An equivalent specification in the ALTO-style notation (see
   Section 8.2 of [RFC7285]) creates a self-contained description
   of the BaseAdvertisementObject.
-->
        <t>To be self-contained, below is an equivalent specification of
BaseAdvertisementObject described in the ALTO-style notation (see
<xref target="RFC7285" section="8.2" sectionFormat="of" format="default"/>). As mentioned above, the normative specification of
BaseAdvertisementObject is in <xref target="RFC8008" format="default"/>.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="json"><![CDATA[
    object {
      JSONString capability-type;
      JSONValue capability-value;
      Footprint footprints<0..*>;
    } BaseAdvertisementObject;

    object {
      JSONString footprint-type;
      JSONString footprint-value<1..*>;
    } Footprint;
]]></artwork>
]]></sourcecode>
        <t>For each BaseAdvertisementObject, the ALTO client MUST <bcp14>MUST</bcp14> interpret footprints
appearing multiple times as if they appeared only once. If footprints in a
BaseAdvertisementObject is null or empty or does not appearing, appear, the ALTO client MUST <bcp14>MUST</bcp14>
understand that the capabilities in this BaseAdvertisementObject have the
"global" coverage, i.e., the corresponding dCDN can provide them for any
request routing source.</t>
        <t>Note: Further optimization of BaseAdvertisement objects 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.</t>
<!-- [rfced] Section 3.6: May we break the following <artwork> into two figures of <sourcecode> and provide figure captions? Note that the other figures do not currently have captions, so this would be inconsistent with the rest of the document unless captions were provided for the other artwork and code snippets.

Current:
   EXAMPLE 1
       {
         "meta": {...},
         "cdni-advertisement": {
           "capabilities-with-footprints": [
   ...
   EXAMPLE 2
       {
         "meta": {...},
         "cdni-advertisement": {
           "capabilities-with-footprints": [
   ....
-->
        <artwork name="" type="" align="left" alt=""><![CDATA[
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>
            ]
          }
        ]
      }
    }
]]></artwork>
        <t>Since such optimizations are not required for the basic interconnection of CDNs,
the specifics of such mechanisms are outside the scope of this document.</t>
        <t>This document only requires the ALTO server to provide the initial FCI-specific
CDNI Payload Types defined in <xref target="RFC8008" format="default"/> as the mandatory-to-implement CDNI
capabilities.</t>
        <!-- [auth]
There may be other documents extending BaseAdvertisementObject and
additional CDNI capabilities. They are outside the scope of this document. To
support them, future documents can extend the specification defined in this
document.
-->

</section>
      <section anchor="cdnifciexamples" numbered="true" toc="default">
        <name>Examples</name>
        <section anchor="IRDexample" numbered="true" toc="default">
          <name>IRD</name>
          <t>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 FCI-related information resources (e.g., CDNI Advertisement
resources), demonstrating a single, integrated environment.</t>
          <t>Specifically, the IRD announces nine information resources as follows:</t>
          <ul spacing="normal">
            <li>two network maps,</li>
            <li>one CDNI Advertisement resource without dependency,</li>
            <li>one CDNI Advertisement resource depending on a network map,</li>
            <li>one filtered CDNI Advertisement resource to be defined in <xref target="filteredcdnifci" format="default"/>,</li>
            <li>one property map including "cdni-capabilities" as its entity property,</li>
            <li>one filtered property map including "cdni-capabilities" and "pid" as its entity properties, and</li>
            <li>
              <t>two update stream services:
              </t>
              <ul spacing="normal">
                <li>one for updating CDNI Advertisement resources,</li>
                <li>one for updating property maps</li>
              </ul>
            </li>
          </ul>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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"
         }
       }
     }
   }
 }
]]></artwork>
        </section>
        <section anchor="fullcdnifciexample" numbered="true" toc="default">
          <name>A Basic Example</name>
          <t>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.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  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" ]
            }
          ]
        }
      ]
    }
  }
]]></artwork>
        </section>
        <section anchor="incremental-updates" numbered="true" toc="default">
          <name>Incremental Updates</name>
          <t>A benefit of using ALTO to provide CDNI Advertisement resources is that such
resources can be updated using ALTO incremental updates <xref target="RFC8895" format="default"/>. Below is
an example that also shows the benefit of having both JSON merge patch and JSON
patch to encode updates.</t>
          <t>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.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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: ]
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="cdnifcinetworkmap" numbered="true" toc="default">
      <name>CDNI Advertisement Service using Using ALTO Network Map</name>
      <section anchor="network-map-footprint-type-altopid" numbered="true" toc="default">
        <name>Network Map Footprint Type: altopid</name>
        <t>The ALTO protocol 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 pre-defined predefined CDNI footprint
types (i.e., ipv4cidr, ipv6cidr, asn, "ipv4cidr", "ipv6cidr", "asn", and countrycode).</t> "countrycode").</t>
        <t>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.</t>
        <t>Specifically, the "altopid" footprint type indicates that the corresponding
footprint value is a list of PIDNames as defined in <xref target="RFC7285" format="default"/>.
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 ID of its dependent network map
MUST
<bcp14>MUST</bcp14> be included in the "uses" field of its IRD entry, and the "dependent-vtags"
field with a reference to this network map MUST <bcp14>MUST</bcp14> be included in its response (see
the example in <xref target="networkmapfootprint" format="default"/>).</t>
      </section>
      <section anchor="examples" numbered="true" toc="default">
        <name>Examples</name>
        <t>The following examples use the same IRD given in <xref target="IRDexample" format="default"/>.</t>
        <section anchor="networkmapexample" numbered="true" toc="default">
          <name>ALTO Network Map for CDNI Advertisements</name>
          <t>Below provides a sample network map whose resource id ID is "my-eu-netmap". This
map is referenced by the CDNI Advertisement example in <xref target="networkmapfootprint" format="default"/>.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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" ]
     }
   }
 }
]]></artwork>
        </section>
        <section anchor="networkmapfootprint" numbered="true" toc="default">
          <name>ALTO PID Footprints in CDNI Advertisements</name>
          <t>This example shows a CDNI Advertisement resource that depends on a network map
described in <xref target="networkmapexample" format="default"/>.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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" ]
           }
         ]
       }
     ]
   }
 }
]]></artwork>
        </section>
        <section anchor="incremental-updates-1" numbered="true" toc="default">
          <name>Incremental Updates</name>
          <t>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.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  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: ]
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="filteredcdnifci" numbered="true" toc="default">
      <name>Filtered CDNI Advertisement using Using CDNI Capabilities</name>
      <t><xref
      <t>Sections <xref target="cdnifci" format="default">Sections 3</xref> format="counter"/> and <xref target="cdnifcinetworkmap" format="default">4</xref> format="counter"/> describe the CDNI Advertisement Service
which
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", 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 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.</t>
      <section anchor="media-type" numbered="true" toc="default">
        <name>Media Type</name>
        <t>A filtered CDNI Advertisement resource uses the same media type defined for the
CDNI Advertisement resource in <xref target="cdnifcimediatype" format="default"/>: "application/alto-cdni+json".</t>
      </section>
      <section anchor="http-method" numbered="true" toc="default">
        <name>HTTP Method</name>
        <t>A filtered CDNI Advertisement resource is requested using the HTTP POST method.</t>
      </section>
      <section anchor="filteredcdnifciinputs" numbered="true" toc="default">
        <name>Accept Input Parameters</name>
        <t>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"
"application/alto-cdnifilter+json", which is a JSON object of type
ReqFilteredCDNIAdvertisement,
ReqFilteredCDNIAdvertisement where:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
        <sourcecode type="json"><![CDATA[
   object {
       JSONString capability-type;
       JSONValue capability-value;
   } CDNICapability;

   object {
       CDNICapability cdni-capabilities<0..*>;
   } ReqFilteredCDNIAdvertisement;

]]></artwork>
]]></sourcecode>
        <t>with fields:</t>
        <dl>
          <dt>
capability-type:  </dt>
          <dd>
            <t>The same as Base Advertisement Object's capability-type defined in Section 5.1
of
<xref target="RFC8008" section="5.1" sectionFormat="of" format="default"/>.</t>
          </dd>
          <dt>
capability-value:  </dt>
          <dd>
            <t>The same as Base Advertisement Object's capability-value defined in Section
5.1 of
<xref target="RFC8008" section="5.1" sectionFormat="of" format="default"/>.</t>
          </dd>
          <dt>
cdni-capabilities:  </dt>
          <dd>
            <t>A list of CDNI capabilities defined in Section 5.1 of <xref target="RFC8008" section="5.1" sectionFormat="of" format="default"/> for which
footprints are to be returned. If this list is empty, the ALTO
server MUST <bcp14>MUST</bcp14> interpret it as a request for the full CDNI Advertisement
resource. The ALTO server MUST <bcp14>MUST</bcp14> 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 <bcp14>MUST</bcp14> omit this capability from the
response.</t>
          </dd>
        </dl>
      </section>
      <section anchor="capabilities" numbered="true" toc="default">
        <name>Capabilities</name>
        <t>There are no applicable capabilities.</t>
      </section>
      <section anchor="uses" numbered="true" toc="default">
        <name>Uses</name>
<!-- [rfced] Section 5.5: Does the following addition improve the
readability of the sentence?

Current:
   Same to the "uses" field of the CDNI Advertisement resource (see
   Section 3.5).

Perhaps:
   The same rules as for the "uses" field of the CDNI Advertisement
   resource apply (see Section 3.5).
-->
        <t>Same to the "uses" field of the CDNI Advertisement resource (see
<xref target="cdnifciuses" format="default"/>).</t>
      </section>
      <section anchor="response" numbered="true" toc="default">
        <name>Response</name>
        <t>If the request is invalid, the response MUST <bcp14>MUST</bcp14> indicate an error, error using ALTO
protocol
Protocol error handling specified in Section 8.5 of <xref target="RFC7285" section="8.5" sectionFormat="of" format="default"/>.</t>
        <t>Specifically, a filtered CDNI Advertisement request is invalid if:</t>
        <ul spacing="normal">
          <li>the value of "capability-type" is null;</li>
          <li>the value of "capability-value" is null;</li> null; or</li>
          <li>the value of "capability-value" is inconsistent with "capability-type".</li>
        </ul>
        <t>When a request is invalid, the ALTO server MUST <bcp14>MUST</bcp14> return an
"E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of <xref target="RFC7285" section="8.5.2" sectionFormat="of" format="default"/>, and the
"value" field of the error message SHOULD <bcp14>SHOULD</bcp14> indicate this CDNI capability.</t>
        <t>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 (see <xref target="cdnifciencoding" format="default"/>.)</t> format="default"/>).</t>
        <!-- [auth]
The returned CDNI Advertisement resource MUST <bcp14>MUST</bcp14> contain only
BaseAdvertisementObject objects whose CDNI capability object is the superset of
one of CDNI capability object in "cdni-fci-capabilities". Specifically, that a
CDNI capability object A is the superset of another CDNI capability object B
means that these two CDNI capability objects have the same capability type and
mandatory properties in capability value of A MUST <bcp14>MUST</bcp14> include mandatory properties
in capability value of B semantically.
-->

<t>The returned filtered CDNI Advertisement resource MUST <bcp14>MUST</bcp14> contain all the
BaseAdvertisementObject objects satisfying the following condition: The the CDNI
capability object of each included BaseAdvertisementObject object MUST <bcp14>MUST</bcp14> follow
two constraints:</t>
        <ul spacing="normal">
          <li>The "cdni-capabilities" field of the input includes a CDNI capability object
X having the same capability type as it.</li>
          <li>All the mandatory properties in its capability value is a superset of
mandatory properties in capability value of X semantically.</li>
        </ul>
        <t>See <xref target="filteredcdnifciexample" format="default"/> for a concrete example.</t>
        <t>The version tag included in the "vtag" field of the response MUST <bcp14>MUST</bcp14> 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.</t>
      </section>
      <section anchor="examples-1" numbered="true" toc="default">
        <name>Examples</name>
        <t>The following examples use the same IRD example as in <xref target="IRDexample" format="default"/>.</t>
        <section anchor="filteredcdnifciexample" numbered="true" toc="default">
          <name>A Basic Example</name>
          <t>This example filters the full CDNI Advertisement resource in
<xref target="fullcdnifciexample" format="default"/> by selecting only the http/1.1 delivery protocol
capability. Only the second BaseAdvertisementObjects BaseAdvertisementObject in the full resource will
be returned because the second object's capability is http/1.1 and https/1.1
delivery protocols protocols, which is the superset of https/1.1 delivery protocol.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  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" ]
            }
          ]
        }
      ]
    }
  }
]]></artwork>
        </section>
        <section anchor="incremental-updates-2" numbered="true" toc="default">
          <name>Incremental Updates</name>
          <t>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.</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  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: ]
]]></artwork>
        </section>
      </section>
    </section>
    <section anchor="unifiedpropertymap" numbered="true" toc="default">
      <name>Query Footprint Properties using Using ALTO Property Map Service</name>
      <t>Besides the requirement of retrieving footprints of given capabilities, another
common requirement for uCDN is to query CDNI capabilities of given footprints.</t>
      <t>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 <xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>. 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.</t>
      <section anchor="footprinttoentities" numbered="true" toc="default">
        <name>Representing Footprint Objects as Property Map Entities</name>
        <t>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
<xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/> 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.</t>
        <t>Each existing footprint type can be represented as an entity domain type as
follows:</t>
        <ul spacing="normal">
          <li>According to <xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>, "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.</li>
          <li>"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 <bcp14>MUST</bcp14> be the dependent network map used by
the CDNI Advertisement resource providing this "altopid" footprint.</li>
          <li>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 <xref target="iana" format="default"/> in addition to the ones in
<xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" format="default"/>.</li>
        </ul>
        <t>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.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
{ "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"
]]></artwork>
        <t>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.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
"ipv4:203.0.113.100" --> {
  "footprint-type": "ipv4cidr",
  "footprint-value": ["203.0.113.100/32"]
}
]]></artwork>
        <section anchor="asn-domain" numbered="true" toc="default">
          <name>ASN Domain</name>
          <t>The ASN domain associates property values with Autonomous Systems in the
Internet.</t>
          <section anchor="entity-domain-type" numbered="true" toc="default">
            <name>Entity Domain Type</name>
            <t>The entity domain type of the ASN domain is "asn" (in lowercase).</t>
          </section>
          <section anchor="asn-entity-id" numbered="true" toc="default">
            <name>Domain-Specific Entity Identifiers</name>
            <t>The entity identifier of an entity in an ASN domain MUST <bcp14>MUST</bcp14> be encoded as a string
consisting of the characters "as" (in lowercase) followed by the ASN
<xref target="RFC6793" format="default"/> as a decimal number without leading zeros.</t>
          </section>
          <section anchor="hierarchy-and-inheritance" numbered="true" toc="default">
            <name>Hierarchy and Inheritance</name>
            <t>There is no hierarchy or inheritance for properties associated with ASN.</t>
          </section>
        </section>
        <section anchor="countrycode-domain" numbered="true" toc="default">
          <name>COUNTRYCODE Domain</name>
          <t>The COUNTRYCODE domain associates property values with countries.</t>
          <section anchor="entity-domain-type-1" numbered="true" toc="default">
            <name>Entity Domain Type</name>
            <t>The entity domain type of the COUNTRYCODE domain is "countrycode" (in lowercase).</t>
          </section>
          <section anchor="countrycode-entity-id" numbered="true" toc="default">
            <name>Domain-Specific Entity Identifiers</name>
            <t>The entity identifier of an entity in a COUNTRYCODE domain is encoded as an ISO
3166-1 alpha-2 code <xref target="ISO3166-1" format="default"/> in lowercase.</t>
          </section>
          <section anchor="hierarchy-and-inheritance-1" numbered="true" toc="default">
            <name>Hierarchy and Inheritance</name>
            <t>There is no hierarchy or inheritance for properties associated with country
codes.</t>
          </section>
        </section>
      </section>
      <section anchor="capabilitytoproperties" numbered="true" toc="default">
        <name>Representing CDNI Capabilities as Property Map Entity Properties</name>
        <t>This document defines a new entity property type called "cdni-capabilities". An
ALTO server can provide a property map resource mapping the "cdni-capablities" "cdni-capabilities"
entity property type for a CDNI Advertisement resource that it provides to an
"ipv4", "ipv6", "asn" "asn", or "countrycode" entity domain.</t>
        <section anchor="defining-information-resource-media-type-for-property-type-cdni-capabilities" numbered="true" toc="default">
          <name>Defining Information Resource Media Type for Property Type cdni-capabilities</name>
          <t>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 <bcp14>MUST</bcp14> 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:</t>
          <t>application/alto-cdni+json</t>
        </section>
        <section anchor="intended-semantics-of-property-type-cdni-capabilities" numbered="true" toc="default">
          <name>Intended Semantics of Property Type cdni-capabilities</name>
          <t>A
<!-- [rfced] Section 6.2.2: We're having difficulty parsing the following
sentence. Does the each element need to follow the format specified in Section 5.3?

Current:
   Each
   element in a "cdni-capabilities" property MUST be a JSON object as
   format of CDNICapability (see Section 5.3).

Perhaps:
   Each
   element in a "cdni-capabilities" property MUST be a JSON object in
   the format of CDNICapability (see Section 5.3).
-->
          <t>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 <bcp14>MUST</bcp14> be a JSON array. Each element in a "cdni-capabilities" property
MUST
<bcp14>MUST</bcp14> be an a JSON object as format of CDNICapability (see
<xref target="filteredcdnifciinputs" format="default"/>). The value of a "cdni-capabilities" property for an
"ipv4", "ipv6", "asn", "countrycode" "countrycode", or "altopid" entity MUST <bcp14>MUST</bcp14> include all the
CDNICapability objects satisfying the following conditions: (1) they are
provided by the defining CDNI Advertisement resource; resource, and (2) the represented
footprint object of this entity is in their footprint restrictions.</t>
        </section>
      </section>
      <section anchor="examples-2" numbered="true" toc="default">
        <name>Examples</name>
        <t>The following examples use the same IRD example given by <xref target="IRDexample" format="default"/>.</t>
        <section anchor="property-map" numbered="true" toc="default">
          <name>Property Map</name>
          <t>This example shows a full property map in which entities are footprints and
entities' property is "cdni-capabilities".</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
 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"]}}]
     }
   }
 }
]]></artwork>
        </section>
        <section anchor="filtered-property-map" numbered="true" toc="default">
          <name>Filtered Property Map</name>
          <t>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".</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
   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"
     }
   }
 }
]]></artwork>
        </section>
        <section anchor="incremental-updates-3" numbered="true" toc="default">
          <name>Incremental Updates</name>
          <t>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".</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
  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: ]
]]></artwork>
          <!-- Skip header line -->

</section>
      </section>
    </section>
    <section anchor="iana" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document defines two new media types: "application/alto-cdni+json", as
described in <xref target="iana-cdni" format="default"/>, and "application/cdnifilter+json", as described in
<xref target="iana-cdnifilter" format="default"/>. It also defines a new CDNI metadata footprint type
(<xref target="iana-footprint-type" format="default"/>), two new ALTO entity domain types
(<xref target="iana-entity-domain-type" format="default"/>), and a new ALTO entity property type
(<xref target="iana-entity-prop-type" format="default"/>).</t>
      <section anchor="iana-cdni" numbered="true" toc="default">
        <name>application/alto-cdni+json Media Type</name>
        <dl newline="true">
          <dt>
Type name:  </dt>
          <dd>
            <t>application</t>
          </dd>
          <dt>
Subtype name:  </dt>
          <dd>
            <t>alto-cdni+json</t>
          </dd>
          <dt>
Required parameters:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Optional parameters:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Encoding considerations:  </dt>
          <dd>
            <t>Encoding considerations are identical to those specified for the
"application/json" media type. See <xref target="RFC8259" format="default"/>.</t>
          </dd>
          <dt>
Security considerations:  </dt>
          <dd>
            <t>Security considerations related to the generation and consumption of ALTO
Protocol messages are discussed in Section 15 of <xref target="RFC7285" section="15" sectionFormat="of" format="default"/>.</t>
          </dd>
          <dt>
Interoperability considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Published specification:  </dt>
          <dd>
            <t><xref target="cdnifci" format="default"/> of RFCthis</t> RFC 9241</t>
          </dd>
          <dt>
Applications that use this media type:  </dt>
          <dd>
            <t>ALTO servers and ALTO clients <xref target="RFC7285" format="default"/> either stand alone or are embedded within other
applications that provides provide CDNI interfaces for uCDNs or dCDNs.</t>
          </dd>
          <dt>
Fragment identifier considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Additional information:  </dt>
          <dd>
            <dl>
              <dt>
Magic number(s):      </dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>
File extension(s):      </dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>
Macintosh file type code(s):      </dt>
              <dd>
                <t>N/A</t>
              </dd>
            </dl>
          </dd>
          <dt>
Person &amp; email address to contact for further information:  </dt>
          <dd>
            <t>See Authors' Addresses section.</t>
          </dd>
          <dt>
Intended usage:  </dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>
Restrictions on usage:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Author:  </dt>
          <dd>
            <t>See Authors' Addresses section.</t>
          </dd>
          <dt>
Change controller:  </dt>
          <dd>
            <t>Internet Engineering Task Force (mailto:iesg@ietf.org).</t> (iesg@ietf.org)</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-cdnifilter" numbered="true" toc="default">
        <name>application/alto-cdnifilter+json Media Type</name>
        <dl newline="true">
          <dt>
Type name:  </dt>
          <dd>
            <t>application</t>
          </dd>
          <dt>
Subtype name:  </dt>
          <dd>
            <t>alto-cdnifilter+json</t>
          </dd>
          <dt>
Required parameters:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Optional parameters:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Encoding considerations:  </dt>
          <dd>
            <t>Encoding considerations are identical to those specified for the
"application/json" media type. See <xref target="RFC8259" format="default"/>.</t>
          </dd>
          <dt>
Security considerations:  </dt>
          <dd>
            <t>Security considerations related to the generation and consumption of ALTO
Protocol messages are discussed in Section 15 of <xref target="RFC7285" section="15" sectionFormat="of" format="default"/>.</t>
          </dd>
          <dt>
Interoperability considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Published specification:  </dt>
          <dd>
            <t><xref target="filteredcdnifci" format="default"/> of RFCthis</t> RFC 9241</t>
          </dd>
          <dt>
Applications that use this media type:  </dt>
          <dd>
            <t>ALTO servers and ALTO clients <xref target="RFC7285" format="default"/> either stand alone or are embedded
within other applications that provides provide CDNI interfaces for uCDNs or dCDNs
and supports CDNI capability-based filtering.</t>
          </dd>
          <dt>
Fragment identifier considerations:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Additional information:  </dt>
          <dd>
            <dl>
              <dt>
Magic number(s):      </dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>
File extension(s):      </dt>
              <dd>
                <t>N/A</t>
              </dd>
              <dt>
Macintosh file type code(s):      </dt>
              <dd>
                <t>N/A</t>
              </dd>
            </dl>
          </dd>
          <dt>
Person &amp; email address to contact for further information:  </dt>
          <dd>
            <t>See Authors' Addresses section.</t>
          </dd>
          <dt>
Intended usage:  </dt>
          <dd>
            <t>COMMON</t>
          </dd>
          <dt>
Restrictions on usage:  </dt>
          <dd>
            <t>N/A</t>
          </dd>
          <dt>
Author:  </dt>
          <dd>
            <t>See Authors' Addresses section.</t>
          </dd>
          <dt>
Change controller:  </dt>
          <dd>
            <t>Internet Engineering Task Force (mailto:iesg@ietf.org).</t> (iesg@ietf.org)</t>
          </dd>
        </dl>
      </section>
      <section anchor="iana-footprint-type" numbered="true" toc="default">
        <name>CDNI Metadata Footprint Type Types Registry</name>
        <t>This document updates the CDNI "CDNI Metadata Footprint Types Registry Types" registry created by
Section 7.2 of
<xref target="RFC8006" section="7.2" sectionFormat="of" format="default"/>. A new footprint type type, which is to be registered, listed in
<xref target="tbl_footprint-type" format="default"/>.</t> format="default"/>, has been registered.</t>
        <table anchor="tbl_footprint-type" align="center">
          <name>CDNI Metadata Footprint Type</name>
          <thead>
            <tr>
              <th align="left">Footprint Type</th>
              <th align="left">Description</th>
              <th align="left">Specification</th> align="left">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">altopid</td>
              <td align="left">A list of PID names</td>
              <td align="left">
                RFC 9241, <xref target="cdnifcinetworkmap" format="default"/> of RFCthis</td> format="default"/></td>
            </tr>
          </tbody>
        </table>
        <t>[RFC Editor: Please replace RFCthis with the published RFC number for this
document.]</t>
      </section>
      <section anchor="iana-entity-domain-type" numbered="true" toc="default">
        <name>ALTO Entity Domain Type Types Registry</name>
        <t>This document updates the ALTO "ALTO Entity Domain Type Registry Types" registry created by Section
11.2 of
<xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" section="11.2" sectionFormat="of" format="default"/>. Two new entity domain types types,
which are to
be registered, listed in <xref target="tbl_entity-domain" format="default"/>.</t> format="default"/>, have been registered.</t>
        <table anchor="tbl_entity-domain" align="center">
          <name>Additional ALTO Entity Domain Types</name>
          <thead>
            <tr>
              <th align="left">Identifier</th>
              <th align="left">Entity Address Identifier Encoding</th>
              <th align="left">Hierarchy &amp; and Inheritance</th>
              <th align="left">Media Type of Defining Resource</th>
              <th align="left">Mapping to ALTO Address Type</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">asn</td>
              <td align="left">See RFC 9241, <xref target="asn-entity-id" format="default"/> of RFCthis</td> format="default"/></td>
              <td align="left">None</td>
              <td align="left">None</td>
              <td align="left">false</td>
            </tr>
            <tr>
              <td align="left">countrycode</td>
              <td align="left">See RFC 9241, <xref target="countrycode-entity-id" format="default"/> of RFCthis</td> format="default"/></td>
              <td align="left">None</td>
              <td align="left">None</td>
              <td align="left">false</td>
            </tr>
          </tbody>
        </table>
        <t>[RFC Editor: Please replace RFCthis with the published RFC number for this
document.]</t>
      </section>
      <section anchor="iana-entity-prop-type" numbered="true" toc="default">
        <name>ALTO Entity Property Type Types Registry</name>
        <t>This document updates the ALTO "ALTO Entity Property Type Registry Types" registry created by Section
11.3 of
<xref target="I-D.ietf-alto-unified-props-new" target="RFC9240" section="11.3" sectionFormat="of" format="default"/>. A new entity property type type,
which is to
be registered, listed in <xref target="tbl_prop-type-register" format="default"/>.</t> format="default"/>, has been registered.</t>
        <table anchor="tbl_prop-type-register" align="center">
          <name>Additional ALTO Entity Property Type</name>
          <thead>
            <tr>
              <th align="left">Identifier</th>
              <th align="left">Intended Semantics</th>
              <th align="left">Media Type of Defining Resource</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">cdni-capabilities</td>
              <td align="left">
                See RFC 9241, <xref target="capabilitytoproperties" format="default"/> of RFCthis</td> format="default"/></td>
              <td align="left">application/alto-cdni+json</td>
            </tr>
          </tbody>
        </table>
        <t>[RFC Editor: Please replace RFCthis with the published RFC number for this
document.]</t>
      </section>
    </section>
    <section anchor="security" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>As an extension of the base ALTO protocol Protocol <xref target="RFC7285" format="default"/>, this document fits into
the architecture of the base protocol. And protocol, and hence Security Considerations of the
base protocol (Section 15 of <xref (<xref target="RFC7285" section="15" sectionFormat="of" format="default"/>) fully apply when this extension is
provided by an ALTO server.</t>
      <t>In the context of CDNI Advertisement, the following security risk scenarios
should be considered:</t>
      <ul spacing="normal">
        <li>For authenticity
        <li>Authenticity and integrity of ALTO information, information: an attacker may disguise
itself as an ALTO server for a dCDN (e.g., by starting a man-in-the-middle
attack),
attack) and provide false capabilities and footprints to a uCDN using the
CDNI Advertisement service. Service. Such false information may lead a uCDN to (1)
select an incorrect dCDN to serve user requests, requests or (2) skip uCDNs in good
conditions. To address this risk, protection strategies in Section 15.1.2 of
<xref target="RFC7285" section="15.1.2" sectionFormat="of" format="default"/> can be applied.</li>
        <li>For potential
        <li>Potential undesirable guidance from authenticated ALTO information, 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 which that they should have
to transfer. To reduce this risk, the protection strategies in Section 15.2.2
of
<xref target="RFC7285" section="15.2.2" sectionFormat="of" format="default"/> can be considered.</li>
        <li>For confidentiality
        <li>Confidentiality and privacy of ALTO information, 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
<xref target="RFC7285" section="15.3" sectionFormat="of" format="default"/> can be considered.</li>
        <li>For availability of ALTO services, an attacker may conduct service degradation 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, 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, 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
<xref target="RFC7285" section="15.5.2" sectionFormat="of" format="default"/> can be applied.</li>
      </ul>
      <t>Although protection strategies as described in Section 15 of <xref target="RFC7285" section="15" sectionFormat="of" format="default"/> should
be applied to address aforementioned security and privacy considerations,
two special cases need to be included as follows:</t>
      <ul spacing="normal">
        <li>
          <t>As required by section 7 of <xref target="RFC8008" section="7" sectionFormat="of" format="default"/>,  </t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
"All
          <blockquote>
All protocols that implement these capabilities and footprint
advertisement objects are REQUIRED <bcp14>REQUIRED</bcp14> to provide integrity and
authentication services."
]]></artwork> services.
</blockquote>
<!-- [rfced] Section 8: Should the following sentence have references for
Digest Authentication and TLS mutual authentication?

Current:
      And the dCDN (ALTO Server) MUST support HTTP
      Digest Authentication and MAY also support TLS mutual
      authentication.
-->
          <t>
Therefore, the uCDN (ALTO Client)
MUST
<bcp14>MUST</bcp14> be authenticated to the dCDN (ALTO Server). And the dCDN (ALTO Server)
MUST
<bcp14>MUST</bcp14> support HTTP Digest Authentication and MAY <bcp14>MAY</bcp14> also support TLS mutual
authentication. 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.</t>
        </li>
        <li>
<!-- [rfced] Section 8: We're having difficulty parsing the following.
Does the uCDN redirect requests to the dCDN that has not isolated the
various uCDNs?

Current:
      In particular, if a
      dCDN signs agreements with multiple uCDNs without any isolation,
      this dCDN may disclose extra information of one uCDN to another
      one.  In that case, one uCDN may redirect requests which should
      not have to be served by this dCDN to it.

Perhaps:
      In particular, if a
      dCDN signs agreements with multiple uCDNs without any isolation,
      this dCDN may disclose extra information of one uCDN to another
      one.  In that case, one uCDN may redirect requests, which should
      not have to be served by this dCDN, to that dCDN.
-->
          <t>One specific information leakage risk introduced by this document could not cannot
be addressed by these strategies. In particular, if a dCDN signs agreements
with multiple uCDNs without any isolation, this dCDN may disclose extra
information of one uCDN to another one. In that case, one uCDN may redirect
requests which should not have to be served by this dCDN to it.  </t>
          <t>

<!-- [rfced] Section 8: Does the slash in the following mean "full and/or
filtered" or "both full and filtered"?

Current:
      To reduce the risk, a dCDN SHOULD isolate full/filtered CDNI
      Advertisement resources for different uCDNs.  It could consider
      generating URIs of different full/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/
      filtered CDNI Advertisement resources in one of its IRDs.
-->
          <t>
To reduce the risk, a dCDN <bcp14>SHOULD</bcp14> isolate full/filtered CDNI Advertisement
resources for different uCDNs. It could consider generating URIs of different
full/filtered CDNI Advertisement resources by hashing its company ID, a
uCDN's company ID as well as their agreements. A dCDN <bcp14>SHOULD</bcp14> avoid exposing
all full/filtered CDNI Advertisement resources in one of its IRDs.</t>
        </li>
      </ul>
    </section>
  </middle>
  <back>

<displayreference target="I-D.ietf-alto-path-vector" to="ALTO-PATH-VECTOR"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
<!-- [ISO3166-1] URL https://www.iso.org/standard/72482.html -->
        <reference anchor="ISO3166-1">
          <front>
            <title>ISO 3166-1: Codes
            <title>Codes for the representation of names of countries and their subdivisions -- Part 1: Country codes</title>
            <author initials="." surname="ISO (International Organization for Standardization)" fullname="ISO (International
            <author>
              <organization>International Organization for Standardization)">
              <organization/> Standardization</organization>
            </author>
            <date year="2020"/> year="2020" month="August"/>
          </front>
          <seriesInfo name="ISO" value="3166-1:2020"/>
        </reference>
<!-- [I-D.ietf-alto-unified-props-new] companion document RFC 9240 -->
        <reference anchor="I-D.ietf-alto-unified-props-new"> anchor='RFC9240' target='https://www.rfc-editor.org/info/rfc9240'>
          <front>
            <title>An ALTO
            <title>ALTO Extension: Entity Property Maps</title>
            <author fullname="Wendy Roome">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Sabine Randriamasy">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Y. Richard Yang">
              <organization>Yale University</organization>
            </author>
            <author fullname="Jingxuan Jensen Zhang">
              <organization>Tongji University</organization>
            </author>
            <author fullname="Kai Gao">
              <organization>Sichuan University</organization>
            </author>
            <date day="25" month="January" year="2022"/>
            <abstract>
              <t>   This document specifies an extension to the base Application-Layer
   Traffic Optimization (ALTO) protocol that generalizes the concept of
   "endpoint properties", which were so far tied to IP addresses, to
   entities defined by a wide set of objects.  Further, these properties
   are presented as maps, similar to the network and cost maps in the
   base ALTO protocol.  While supporting the endpoints and related
   endpoint property service defined in RFC7285, the ALTO protocol is
   extended in two major directions.  First, from endpoints restricted
   to IP addresses to entities covering a wider and extensible set of
   objects; second, from properties on specific endpoints to entire
   entity property maps.  These extensions introduce additional features
   allowing entities and property values to be specific to a given
   information resource.  This is made possible by a generic and
   flexible design of entity and property types.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-alto-unified-props-new-22"/>
        </reference>
        <reference anchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner">
              <organization/>
            </author>
            <date month="March" year="1997"/>
            <abstract>
              <t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC6793">
          <front>
            <title>BGP Support for Four-Octet Autonomous System (AS) Number Space</title>
            <author fullname="Q. Vohra" initials="Q." surname="Vohra">
              <organization/>
            </author>
            <author fullname="E. Chen" initials="E." surname="Chen">
              <organization/>
            </author>
            <date month="December" year="2012"/>
            <abstract>
              <t>The Autonomous System number is encoded as a two-octet entity in the base BGP specification.  This document describes extensions to BGP to carry the Autonomous System numbers as four-octet entities.  This document obsoletes RFC 4893 and updates RFC 4271.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6793"/>
          <seriesInfo name="DOI" value="10.17487/RFC6793"/>
        </reference>
        <reference anchor="RFC7285">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
            <author fullname="R. Alimi" initials="R." role="editor" surname="Alimi">
              <organization/>
            </author>
            <author fullname="R. Penno" initials="R." role="editor" surname="Penno">
              <organization/>
            </author>
            <author fullname="Y. Yang" initials="Y." role="editor" surname="Yang">
              <organization/>
            </author>
            <author fullname="S. Kiesel" initials="S." surname="Kiesel">
              <organization/>
            </author>
            <author fullname="S. Previdi" initials="S." surname="Previdi">
              <organization/>
            </author>
            <author fullname="W. Roome" initials="W." surname="Roome">
              <organization/>
            </author>
            <author fullname="S. Shalunov" initials="S." surname="Shalunov">
              <organization/>
            </author>
            <author fullname="R. Woundy" initials="R." surname="Woundy">
              <organization/>
            </author>
            <date month="September" year="2014"/>
            <abstract>
              <t>Applications using the Internet already have access to some topology information of Internet Service Provider (ISP) networks.  For example, views to Internet routing tables at Looking Glass servers are available and can be practically downloaded to many network application clients.  What is missing is knowledge of the underlying network topologies from the point of view of ISPs.  In other words, what an ISP prefers in terms of traffic optimization -- and a way to distribute it.</t>
              <t>The Application-Layer Traffic Optimization (ALTO) services defined in this document provide network information (e.g., basic network location structure and preferences of network paths) with the goal of modifying network resource consumption patterns while maintaining or improving application performance.  The basic information of ALTO is based on abstract maps of a network.  These maps provide a simplified view, yet enough information about a network for applications to effectively utilize them.  Additional services are built on top of the maps.</t>
              <t>This document describes a protocol implementing the ALTO services. Although the ALTO services would primarily be provided by ISPs, other entities, such as content service providers, could also provide ALTO services.  Applications that could use the ALTO services are those that have a choice to which end points to connect.  Examples of such applications are peer-to-peer (P2P) and content delivery networks.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7285"/>
          <seriesInfo name="DOI" value="10.17487/RFC7285"/>
        </reference>
        <reference anchor="RFC7493">
          <front>
            <title>The I-JSON Message Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray">
              <organization/>
            </author>
            <date month="March" year="2015"/>
            <abstract>
              <t>I-JSON (short for "Internet JSON") is a restricted profile of JSON designed to maximize interoperability and increase confidence that software can process it successfully with predictable results.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7493"/>
          <seriesInfo name="DOI" value="10.17487/RFC7493"/>
        </reference>
        <reference anchor="RFC8006">
          <front>
            <title>Content Delivery Network Interconnection (CDNI) Metadata</title>
            <author fullname="B. Niven-Jenkins" initials="B." surname="Niven-Jenkins">
              <organization/>
            </author>
            <author fullname="R. Murray" initials="R." surname="Murray">
              <organization/>
            </author>
            <author fullname="M. Caulfield" initials="M." surname="Caulfield">
              <organization/>
            </author>
            <author fullname="K. Ma" initials="K." surname="Ma">
              <organization/>
            </author>
            <date month="December" year="2016"/>
            <abstract>
              <t>The Content Delivery Network Interconnection (CDNI) Metadata interface enables interconnected Content Delivery Networks (CDNs) to exchange content distribution metadata in order to enable content acquisition and delivery.  The CDNI Metadata associated with a piece of content provides a downstream CDN with sufficient information for the downstream CDN to service content requests on behalf of an upstream CDN.  This document describes both a base set of CDNI Metadata and the protocol for exchanging that metadata.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8006"/>
          <seriesInfo name="DOI" value="10.17487/RFC8006"/>
        </reference>
        <reference anchor="RFC8008">
          <front>
            <title>Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics</title>
            <author fullname="J. Seedorf" initials="J." surname="Seedorf">
              <organization/>
            </author>
            <author fullname="J. Peterson" initials="J." surname="Peterson">
              <organization/>
            </author>
            <author fullname="S. Previdi" initials="S." surname="Previdi">
              <organization/>
            </author>
            <author fullname="R. van Brandenburg" initials="R." surname="van Brandenburg">
              <organization/>
            </author>
            <author fullname="K. Ma" initials="K." surname="Ma">
              <organization/> initials='W' surname='Roome' fullname='Wendy Roome'>
              <organization />
            </author>
            <author initials='S' surname='Randriamasy' fullname='Sabine Randriamasy'>
              <organization />
            </author>
            <author initials='Y' surname='Yang' fullname='Y. Yang'>
              <organization />
            </author>
            <author initials='J' surname='Zhang' fullname='Jingxuan Zhang'>
              <organization />
            </author>
            <author initials='K' surname='Gao' fullname='Kai Gao'>
              <organization />
            </author>
            <date month="December" year="2016"/>
            <abstract>
              <t>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 &amp; 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.</t>
            </abstract> year='2022' month='May'/>
          </front>
          <seriesInfo name="RFC" value="8008"/> value="9240"/>
          <seriesInfo name="DOI" value="10.17487/RFC8008"/>
        </reference>
        <reference anchor="RFC8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <author fullname="T. Bray" initials="T." role="editor" surname="Bray">
              <organization/>
            </author>
            <date month="December" year="2017"/>
            <abstract>
              <t>JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format.  It was derived from the ECMAScript Programming Language Standard.  JSON defines a small set of formatting rules for the portable representation of structured data.</t>
              <t>This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="90"/>
          <seriesInfo name="RFC" value="8259"/>
          <seriesInfo name="DOI" value="10.17487/RFC8259"/>
        </reference>
        <reference anchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba">
              <organization/>
            </author>
            <date month="May" year="2017"/>
            <abstract>
              <t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8895">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)</title>
            <author fullname="W. Roome" initials="W." surname="Roome">
              <organization/>
            </author>
            <author fullname="Y. Yang" initials="Y." surname="Yang">
              <organization/>
            </author>
            <date month="November" year="2020"/>
            <abstract>
              <t>The Application-Layer Traffic Optimization (ALTO) protocol (RFC 7285) provides network-related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients to achieve two benefits: (1) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes and (2) updates can be immediate, in that the ALTO server can send updates as soon as they are available.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8895"/>
          <seriesInfo name="DOI" value="10.17487/RFC8895"/> value="10.17487/RFC9240"/>
        </reference>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6793.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7285.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7493.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8006.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8008.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8259.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8895.xml"/>
      </references>
      <references>
        <name>Informative References</name>
        <reference anchor="I-D.ietf-alto-path-vector">
          <front>
            <title>An ALTO Extension: Path Vector</title>
            <author fullname="Kai Gao">
              <organization>Sichuan University</organization>
            </author>
            <author fullname="Young Lee">
              <organization>Samsung</organization>
            </author>
            <author fullname="Sabine Randriamasy">
              <organization>Nokia Bell Labs</organization>
            </author>
            <author fullname="Yang Richard Yang">
              <organization>Yale University</organization>
            </author>
            <author fullname="Jingxuan Jensen Zhang">
              <organization>Tongji University</organization>
            </author>
            <date day="2" month="February" year="2022"/>
            <abstract>
              <t>   This document is an extension to the base Application-Layer Traffic
   Optimization (ALTO) protocol.  It extends the ALTO Cost Map and ALTO
   Property Map services so that an application can decide which
   endpoint(s) to connect based on not only numerical/ordinal cost
   values but also details of the paths.  This is useful for
   applications whose performance is impacted by specified components of
   a network on the end-to-end paths, e.g., they may infer that several
   paths share common links and prevent traffic bottlenecks by avoiding
   such paths.  This extension introduces a new abstraction called
   Abstract Network Element (ANE) to represent these components and
   encodes a network path as a vector of ANEs.  Thus, it provides a more
   complete but still abstract graph representation of the underlying
   network(s) for informed traffic optimization among endpoints.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-alto-path-vector-21"/>
        </reference>
        <reference anchor="RFC5693">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Problem Statement</title>
            <author fullname="J. Seedorf" initials="J." surname="Seedorf">
              <organization/>
            </author>
            <author fullname="E. Burger" initials="E." surname="Burger">
              <organization/>
            </author>
            <date month="October" year="2009"/>
            <abstract>
              <t>Distributed applications -- such as file sharing, real-time communication, and live and on-demand media streaming -- prevalent on the Internet use a significant amount of network resources.  Such applications often transfer large amounts of data through connections established between nodes distributed across the Internet with little knowledge of the underlying network topology.  Some applications are so designed that they choose a random subset of peers from a larger set with which to exchange data.  Absent any topology information guiding such choices, or acting on suboptimal or local information obtained from measurements and statistics, these applications often make less than desirable choices.</t>
              <t>This document discusses issues related to an information-sharing service that enables applications to perform better-than-random peer selection.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5693"/>
          <seriesInfo name="DOI" value="10.17487/RFC5693"/>
        </reference>
        <reference anchor="RFC6707">
          <front>
            <title>Content Distribution Network Interconnection (CDNI) Problem Statement</title>
            <author fullname="B. Niven-Jenkins" initials="B." surname="Niven-Jenkins">
              <organization/>
            </author>
            <author fullname="F. Le Faucheur" initials="F." surname="Le Faucheur">
              <organization/>
            </author>
            <author fullname="N. Bitar" initials="N." surname="Bitar">
              <organization/>
            </author>
            <date month="September" year="2012"/>
            <abstract>
              <t>Content Delivery Networks (CDNs) provide numerous benefits for cacheable content: reduced delivery cost, improved quality of experience for End Users, and increased robustness of delivery.  For these reasons, they are frequently used for large-scale content delivery.  As a result, existing CDN Providers are scaling up their infrastructure, and many Network Service Providers (NSPs) are deploying their own CDNs.  It is generally desirable that a given content item can be delivered to an End User regardless of that End User's location or attachment network.  This is the motivation for interconnecting standalone CDNs so they can interoperate as an open content delivery infrastructure for the end-to-end delivery of content from Content Service Providers (CSPs) to End Users.  However, no standards or open specifications currently exist to facilitate such CDN Interconnection.</t>
              <t>The goal of this document is to outline the problem area of CDN Interconnection for the IETF CDNI (CDN Interconnection) working group.  This document is not an Internet Standards Track specification;  it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6707"/>
          <seriesInfo name="DOI" value="10.17487/RFC6707"/>
        </reference>
        <reference anchor="RFC7971">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Deployment Considerations</title>
            <author fullname="M. Stiemerling" initials="M." surname="Stiemerling">
              <organization/>
            </author>
            <author fullname="S. Kiesel" initials="S." surname="Kiesel">
              <organization/>
            </author>
            <author fullname="M. Scharf" initials="M." surname="Scharf">
              <organization/>
            </author>
            <author fullname="H. Seidel" initials="H." surname="Seidel">
              <organization/>
            </author>
            <author fullname="S. Previdi" initials="S." surname="Previdi">
              <organization/>
            </author>
            <date month="October" year="2016"/>
            <abstract>
              <t>Many Internet applications are used to access resources such as pieces of information or server processes that are available in several equivalent replicas on different hosts.  This includes, but is not limited to, peer-to-peer file sharing applications.  The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. This memo discusses deployment-related issues of ALTO.  It addresses different use cases of ALTO such as peer-to-peer file sharing and Content Delivery Networks (CDNs) and presents corresponding examples. The document also includes recommendations for network administrators and application designers planning to deploy ALTO, such
<!-- [I-D.ietf-alto-path-vector] MISSREF as recommendations on how to generate ALTO map information.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7971"/>
          <seriesInfo name="DOI" value="10.17487/RFC7971"/>
        </reference>
        <reference anchor="RFC7975">
          <front>
            <title>Request Routing Redirection Interface for Content Delivery Network (CDN) Interconnection</title>
            <author fullname="B. Niven-Jenkins" initials="B." role="editor" surname="Niven-Jenkins">
              <organization/>
            </author>
            <author fullname="R. van Brandenburg" initials="R." role="editor" surname="van Brandenburg">
              <organization/>
            </author>
            <date month="October" year="2016"/>
            <abstract>
              <t>The Request Routing interface comprises (1) the asynchronous advertisement of footprint and capabilities by a downstream Content Delivery Network (CDN) that allows an upstream CDN to decide whether to redirect particular user requests to that downstream CDN; and (2) the synchronous operation of an upstream CDN requesting whether a downstream CDN is prepared to accept a user request and of a downstream CDN responding with how to actually redirect the user request.  This document describes an interface for the latter part, i.e., the CDNI Request Routing Redirection interface.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7975"/>
          <seriesInfo name="DOI" value="10.17487/RFC7975"/>
        </reference> 2022 April 18  -->
        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-alto-path-vector.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5693.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6707.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7971.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7975.xml"/>
      </references>
    </references>
    <!-- Skip header line -->

<section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors thank Matt Caulfield, Danny <contact fullname="Matt Caulfield"/>, <contact fullname="Danny Alex Lachos Perez, Daryl Malas Perez"/>,
<contact fullname="Daryl Malas"/>, and
Sanjay Mishra
<contact fullname="Sanjay Mishra"/> for their timely reviews and invaluable comments. Big thanks also
to the ALTO WG Chairs (Qin Wu and Vijay Gurbani), (<contact fullname="Qin Wu"/> and <contact fullname="Vijay Gurbani"/>), all the directorate reviewers reviewers,
and the IESG reviewers (Martin Duke, Erik Kline, Martin Vigoureux, Murray
Kucherawy, Roman Danyliw, Zaheduzzaman Sarker, Eric Vyncke, (<contact fullname="Martin Duke"/>, <contact fullname="Erik Kline"/>,
<contact fullname="Martin Vigoureux"/>, <contact fullname="Murray Kucherawy"/>,
<contact fullname="Roman Danyliw"/>, <contact fullname="Zaheduzzaman Sarker"/>,
<contact fullname="√Čric Vyncke"/>, and Francesca
Palombini), <contact fullname="Francesca Palombini"/>),
for their thorough reviews, discussions, guidance guidance, and shepherding,
that
which further improve this document.</t>
      <t>Jan Seedorf
      <t><contact fullname="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.</t>
      <t>This document has also been supported by the Coordination Support Action
entitled 'Supporting European Experts Presence in lnternational International Standardisation
Activities in ICT' ("StandlCT.eu") (<eref target="https://www.standict.eu/" brackets="angle">StandICT.eu</eref>) 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.</t>
    </section>
    <section anchor="contributors" numbered="false" toc="include" removeInRFC="false"> toc="include">
      <name>Contributors</name>
      <contact initials="X." surname="Lin" fullname="Xiao Shawn Lin">
        <organization>Huawei</organization>
        <address>
          <postal>
            <street>2222 Newjinqiao Rd</street>
            <city>Shanghai</city>
            <code>200125</code>
            <country>China</country>
          </postal>
          <phone>+86-15316812351</phone>
          <email>x.shawn.lin@gmail.com</email>
        </address>
      </contact>
    </section>
  </back>
<!-- ##markdown-source:
H4sIAB2cDWIAA+19aXfj1pXgd/yKN/Q5bambpETtkpNMlFLZllOLUlJlaccn
ByRBEikSYABQKrqi/Pa+29uwkaoqp52ZeKa7VSDwlvvuvr1erxeM01ESLqIL
Nc7CSdGLo2LSC+dF2huNk7iXRX9bRXnRy9JVESdT/uXgICjiYg7fdJ6lSREl
hbqK5vF9lK3Vq6h4SLN36hqeZ6M0SaJREaeJ2nl29ep6V73h8dQbHu9C4WP1
dZoWyyyGccJkrJ6Fy3AYz+MijnJ1OYZhiziPFjjNKoeP1OWLu9edIBwOs+ge
10BDPLv2fh2FRTRNs/WFyotxEMTL7EIV2SovDvb3z/cPgjCLwgu92jzA/z2F
TS4v6Hv1H7ywP3yTB++iNfw65h+CIC9gjX8J52kC+19HebCMLwKlinTE/6Q/
08UyHBXOg3G0LGYX6hD+BUtJ0iKexBGMmaTwJE+zIosmuX4/Xy/cf5ZGy1dD
8wQ+D8JVMUszXEMP/gfGT+DL7/rqNorGaTahZ3zC34WJ9zTN4AC+/fpO3Rar
opiGWaF66m0S3/dVOlGXy+Uc1qhuR3GUjGhqmBwWGsHEt6NZNJ8DuOFBmOeR
Ojii30dxASA34/GzdAyTn+4PTuWddJUUeDLfRNkiTNb0cDkjgP7X0Xlv/3Qw
6J2dH5z0Ds72B/RrtAjj+YX6a5j0c97Ar2eArLmepz+O/P3/qa/+FCZTZ/Pw
5E08moXZ2P5CAPhTOI9o11GWw+q9bR4P1E2W5ktAYtgUPnN2+Sp6UN+G91Hi
7PLZndo/OR4M/I2+vb30NjnoHewf9o4OD3onR/v77g7X2frXo7y/hjX1o/GK
flpl8YWaFcXyYm/v4eGh7/y+9w/4YM/f+m/76mXobPy30X2cIELIU9r08ywe
5XmaeLs9OlSvwmk6VTdh9s7Z6OWoSN1NvrxUcJgH+5s2eX561js7OuodD/xN
vsMV9f/aX4R9ZDe/nuLjPiB1BYdvIuAiepmCxMBMvMe0n1fR6rYIM287g7P9
fXULGBJlcHjwV1xE6vh039kZsK8R0LZ7gJfq/Oi4aW8aD9Okv5Q1/DqJgKuE
WX8Y/1hZ/3/PfCT8Dijm/QrI8LsoyaPE+Z12cZcm07/GTch4hPt5FqZfwvff
PqxdesNhZmHs7ONgH7ZfordnszgJvX3Icvo/4gC/Lmh6xKv+KAkC4N5FFg9X
RYW7/LGvXsTuofwxDlNcxUNifmDmsgofotjbxQH8h6QDc/8Nv3oz3rSR/cHB
cdNGNLKdnfQGx4eDk7PBweGxxzPe93NcVx+YlYNoQZIC7ykAzri169vX8C0M
cUFfauEGj5U8B0wZgzSapJkqZpHKomUWwQEWIQk34JYIhxz/4EWi6EJZBi/H
GbLscXwf5/Burno9pK9C0aC0Idpp3qG5LTfH/3oCX1rKDsnUhKYM5+p1Ng2T
+EdeAS7sFiUT8Dd5ttuRQeTQPmGMMQhTPAkii+veVd9qCauEJFlvmaXLvJdE
D7j0N18/OxgMzuXPk9PzQ/nz9ODsWP95ZJ4CXp/YP8/0nwfHeoQzEB36z7Nz
GCFOJt75eUtahsWsdw8sm+EIHx2fmLlOTvdP9QrOTwf2Txg16MHZhEMUaaMi
CH7xf+Cft+/ipZpF4RiYCKBQBMf3qyC4AxxoUn3yJt1nksFZknIE/BgmVbiW
YBxNYFjAFpVHBSIQQBI1iHkOegO8aYdClYQehqNZHN1HarGaF/ESpNc0Ded5
F6Aymq/GqANF72Fp9BdjK3yBQ4dqCktNcKC+umQVp6SRWV0s+I9wsfyqTRuj
xU3CUaR2QP3aVXGuEpDOoDM4i8QF0PoCWgDO2afd41ErvXt8C1U4GDlMCpBN
RD0AivsYSCOYruD/zOlNgKd+WUOqq4BJ0dPoPZyceU4LSguF8puwtK/uZnGO
Ku+KNmBhD4jLCs+I8L73IlzDgd+BSjyJR+r1sogXmkx2UA/chZVm9/Eo6oKm
OZ/DllkN9QF0y+90urC4sDDbgb2peAEHt3A5iOyqG0zS+Tx90IfnbJ2XO9bo
gwDsM5p+IkI+FQm7dVgY0CkDrwNcC/MtUJAGgR9yhg78GeBpjVJYPOxyuBao
AbOMR6t5mDHevgYiRAUYGH9S8Csu4gVlxMNZ6WwA8iOQZwxAeuJQJKMgPg0a
KUJtTxEBUUQNooPcGMHb8zXNZ9EdFoko/ZmwPnqPqAxibB3AJnIYhqcbpcuI
cQ2gpsmAqULVU0XwUVShXKII6oniKTShDE0E29AE8Whk5ot4PAbMbGPlXyB1
ZOl4xaTx4YsY//nIPJ7PeV0hAsN5R0JzY01ziaY5pLF8N5gBeqORo4ZRAkst
gHYsm4a/EP9h+YT04TTqAuQEu9ZdxIYgg5HlAR7U08k8sFj+4YNIwMdHc8qT
dJVZvEV6Dyr0fqF2BruGQMoiI7jWX3fVzoHz3suoCEF1CJX7wqHzwot0Oi0N
gASwc+S8g9vNAKvNO8DyLhcp8xUwPEvr7zYu044QGKQD215NVgmBCz6FszKy
AjHKgddF0LlrGtjKwSgJh3MinTKM9Cw4LKD62yXqw+FC80F4GU6y8pnyPguu
0ofE/26MVsgCkTlmaim9AnSNK1I7iEoPMZnsu8y9R9GS2QfgbjQFDW9sUEtW
0VfXwJbnObyN1EcssmYNIzmhB6TnfJau5sC8keUXqyxhZQCneQu8QV1OYXxA
MBEK4zgTXAXtOQf8Z64fqZWGTxNA+p3gEhanZvF0pubA7+fdMovbhAZd5CVZ
BJokkh1sIgQ9WQEtAcHiCsP8nWC+hjIdNg89hrGDnbEHDNKABMgOjEMHwppf
iF+tGxC+A9EYWIjALL2IEo+2n6ULGHCFoN/RQApobgEzKuIA6IgMi2WKYiul
fyIfE8Dj4oGMnqUZWDEgSJEZzdcMwEZw4eaGWRqOQXahNQPiFjlFShDTxxKy
WCwxjDYJGrTrlA5/J2pEBv/4aOHWeMxvHORyBn1jxwz0mKj9Pz6WxeAE/siN
6A0mcQaju/tcM4NVJOmD4JY5B0o+AKVxSgrpDNNihoQferuV4xxrbSjgg12u
8tkuscJQOIN77vgifwIvzucgdFOWpUQ4iJfvEpzyYRYhgqsYsAdm1hgGHzsq
1QqpUiNZIQMJflwSf7S6FsCLQIfgNfuLc/swHf4VJsi1piW4DAqtHD9r9SNX
fyKVkOZTt6g56iFAGwTQAXaP1w4OBLdyosf4oYMQffVt+gBcIOuCxu+pQvpj
3FsWJoDuGbmZg9USzVrWV/WsQxClEWinAmk+AYHGXSpjiYrrKGKFhzhahJBO
Q2pwbtWZJ+pTjJ9gNYPENrsaroNYdBYEsVgv6LauU78abBLY0fc/7HwxnPJE
4zgHdM/FFNPKCh659aqjfAwdKOoFuUZIhnhEW3VBAn+n7GqAVYW5qHN5X9ES
whH53pPxrtV9EwCP8dEo+wqSI9GSJTB4iKvjwTBqMRnFu0pDiHcULFJY1zDM
Ac7actsGSmTpABbOYeVmysCCxJtUdL9FuEQeAzoKehIKUgeQkASoCB07wAWt
rqRnTvEzu8OHGPZLByAzgIBa5kIw+n1EGgs9QAh4mCCJy7ja+lGWGnnxk3he
oMFVA7mg87X8qFpgRAwJz9NhUNOocCaiHQRs+HnUDwK3ABJHkMAXRvhNgK0h
JoFqh+f0MItho8jDYPmwoynogLhy8T2xxCvWBPfJKiOmB3rIAxJgSv9qBr1W
8QOjhJlliyilhTpEIKJUz4pnYakcVKaEcD94CFGBZ4Dg0qPJBHnXPZp+k6ig
Dfl80IEXkB1vOkbaYYUcCAs9GNeXry4J5/NotKLDBVUBLTzGAeacmppJbiKo
4jAJSaIQ4PSnqHZQcIOWJXZTq610R3pQOk+na1rEbyxhfnAIWcwnxHqMneWq
8/Lt7R1QE/1f9eo1/f3m+e/eXr95foV/3357+eKF+UO/cfvt67cv4PdA/rJf
Pnv98uXzV1f8MTxVpUcvL//UYWui8/rm7vr1q8sXHVZ/XAcQwgoOHtCKQAzG
ecEMyvMV/ObZjRocMS9Gv+bjI0uewenR42MAYjbhmdIEzpb/CZgFAFouozAj
1R3wGY47LtBPR2YGoGeiUP3sM6hgwniaGF8Fkr1ltB4LzlcLFi0A5yijcCTJ
3gnxxaDqRWM+9S0G8SqiqgBNgMkTxYjHc7PoPgb7H73CODCs8wv//D98gVqx
HLUZcqVlCO0D38grShybVF0jwE9AuiFuegL9EgwPVkmrYxMo6scWYcnDbfBV
V5U+M4N1OHCcOWbqQiexMI/tBDm+fvsK3l4VaZIu0lWubtdAyQv1arUYRhn8
DoC6aLTq+fdrCpSXDXz4bUwf+zYZPAYkuDCI1N3g6MVg9zYurZ66fnN1AYsQ
3zsInDfCo9UVqZZpRiYGBcp76uYa3r5hkZT19Dldj5GBwjlkzqsr2oZrFBO2
3ZbdY/7SgONMzSuAhw76eI5lQw6BQ15d63pCd1II1IG6BRmxLfkIiyhkY5x9
hWSmvS+Y/q3ix9bt31YAFVyp8d/V0LZRotC5w47YmBm5b/LAjpYR6z8O2fTV
byKUvHFept+A6Rchh2w4i+ZkgJJFmJe0Z1q9N+rXQPVg9YbxnOwke+L4puUR
ubZ58Leu9vSOWf6iHwDMa/gHm6Z5hKZiALPkwEz+U73UTrRivWQJuMDgE2JR
D6jVeANdwbgT96N+V8XL+6NRPM7orxP+K8yTbqDYwuC4GobVdlkeVq1I2uYl
iBh2eF/fAFuAt95HeQflNeVdkEuA1U1SSa5vwH4bg8xELiFLCdXe4QHFzq5v
7o/Q1oYng4Mz/eiExa7Cj/UMwnABmtkwBlRAS51+UvMomQKvRVzI0LWeiwNm
iFbHkhAGxoXRjAfSrklR0JgcWbw0WhDCA5eBfkdtuRiA9t1jIMQL5/Y4PAWl
AYyIPcahCetCu9/wsBtjIaGpfjkCgsgJud1fDnc9W/0lHFoXXYAwmEd5GoMB
mVznobgMj3db34bBtDeSgLum/QiJjq2IzjluS6jsuIZIvyLNAEFfj6UetPDw
cURrJnu+7RwB73OZRmAX6ZTteH4rwRiJr7BgUlHC7AEmmIu3gCMu+CVYCp5v
wj87MTdyixWaitwVGYxdAsOSWE6n+oY7BmqsWcy+VdDFhmsMSyCiovTxlV/k
p+i1sro3mmoEJX/pGq6bOAUjcddlHUzUADlki6zljdhEo58nxPHIT4frE5dI
br0tIMPZ6+LByRNIRTSf58YNQ3/MQROQMy9PEfp+F8xgYkfI18Q5LLeAfzap
D8CGQL3Id7uitOjtozIZcvTOWQ6GynDVwpw1YhufICxphOokOUZImxVvp8Nk
xLUqS8djFn1CNIFJiDBAZBBno3A2CixmqAx1fatDab86LsyVJ6iWUfxW3C4z
sjDZiqQNGed3zmJbLxFk65Ty1ZCMSFY7Di9YANADnAr8Q2PUyM3DMFabQAnh
wNKgBVgAp1hCl7n4b3lIH1waWJT0h+Cyu//4vTPqtE9opruKwQ7NIk0hnt0p
u9QUIQb3KF0MfUYESJWEWQZLMrAQSIzWWvbwolw4bo9t9WtHmAFscvasAQ/A
V6ub8LYgKOhRKTKVbwiQHHZmjwKhCKmZ2+aiLkJEixkaeaQRUhgkHBUrEKHh
NItY8+tW47zVlNeyqPO5CulQzIiS/CHKjJfE5AkQuABrLogOYDSKCANA4SkA
CmPjudi5ZuixDrVoEfV/ie+gRyYkS5H9o0RGwxQjzdEC9A/Y3AS0wlXGYNdQ
C90DYLwBUwqUJuUqj0XKKHYP8hcsKm96486yrz8Q3oiartejyJ9vXoIBl6jp
AmeE/RLcx+5pWJ8u8SLiA/GSGTCGNslhw04i8lSgCulp6qRZo9YvQt046/W6
RjNiN3sWXhlw+GzMLH7invMe8hr3oIUlK4wSV7cBk6CvEnkYnoLZk7bXVyQt
xLCnNzOFoQPCXIotk8IxR4RIgLfhijA8hacDJiRG3IBhFNFolsSIQmzik23t
+HXIzaP9wR/EYQzW1sc7sk2CgVUnAmbDiBm4Su3nnNO4O0W6JJfDbgmbVIcy
ATrCNYRPyMGADQKydqQdo7hdimDEOWc1ogpgtyBngbg7mqUp2CohBpmDHIMK
4dzhVHqeXGMA0yZoYhnlnWg2rd/rq7f5irUXEL6ITuTCGQv7SaznPtIgyP19
SmwH1+QsOBBdEHAzB3JE4ToL79H3h4cASv1afhJ+sQBw3MOq6SQwIw4MoCB4
ncWgRfPyaCEPmLCQgmwm9Rl4RMqnSUpbluZ57/r2Bu1XOuopIEam37w5uAk8
kLpT2QANTYOA1pbNCrkRIgAocghSCRuVxQBn7TDFWoHeVdWYEGb2PT4GNgtG
ISHQkmwcw56oCayg+52WIOkyBn+QwwUky1Yg96YksDL4/wg7ceBZbowpHTjV
InwnnqoQvgMtEAPxNbOSWoguDzsfsgPhrMSIyqAgEyX2wEAUBEB1U4Qu0Mx2
6FQRnfZg3QCOSEoamMOZ1eSOvi1eSc6rUgY2zhkLhWp02KGIWeVn67LKhaxA
cKa59YtwVmpU7CIaMVnRNsfjWDJVS4TvEYJqIhFUiuZj0qPgTOL52lKpJQhx
AcLYo5nRplBkauhjAAKtcVELH8KEzYJmcOBr5SMborbAjlx3LzvCRIiAWLjs
+tHc6ibSIfolYDiSWw8gzI0UMLQ1i+ZLJx7DqMXnjIYWCTGYkaLaJEM1zPGX
/MuSOQoKNpg2HLmzvpg8iryYm/Z0wKoSZ8QRn/TEEk/OWrleBC8aA3QU1wp6
SNIUoLgg9TgWl6HAWAv0FeXDIsbRmgmPKYkszUCFYQvUuODsak3wY7fPM+Ok
WmkRdMdBZwhRzePJxJ6x4sxkTxTDSN1XN3NM41I4heZGg+P+oH9gWRKLPnbe
aM+aM4biWOE0jsjqffP89g61JyZABgMt1tApqgwUAZimSaQDUOK2z7X/EDSa
CCd01JWwNLajrZDdMkfe0BNxRE6GUBaoM6PQil7rXBPxXV5TjHcyj97HyOUQ
frIk/GeUpKvpDFcButIYH7wHKSyMDLEvRd83+p4mqwJlGWWNMZFYDz9MytnD
1yyn9Y4kXSaHISM2Yhr3sAADjxkuq3xmHcRlnSw4OqbKskyYzyT3s48IcytW
I14JYEKWaLRXOnpCtI+aAqErpishGaKtOS9mDBztlEJCF7vFSWaKkc3ZjM1L
R0E1yS1DSiVMRaNg7ZmwNi447iMnTxiIZ+8hrkvJiILPgVizHh0YVepVUdA4
0C32Rd5Hsg+Y72GWzq1hh0DgzKM8MrrZjks9Z/3jEuns6k3DaE/cdtPyYCST
G1kBRTksTq7ScKmj3gwPz67TqpwTpBeexAm6JGF0CYnIGDJWPMkm5pFrORjJ
0GVLwFV+4knFqUuJWhGXAZC/jWnHeLiRMZLJ0nT8Th4D+Sl1DkBl+5p9KgYW
2eqSgcLHUEoLgJk5xk7WPkJiSfFHB3gwGjvAAGbo1uvaeJ8+ERN6J1/s0kl6
SSQB0xF8PJ8TySdjVStXVpqhjYQqTEwe1ApkalINyDlJLKbHnnPUgrmyU6sf
JTtMm7AX6g8zMUjtoRHHIVZWmx4lZqaOOqwSOFuglWis3b3Ej4GliGMNviSb
EeGwq63DxoXyaRngaROXUVNGMY4AwjexehU77hFiz1z/DnrSRW3qqfGKouzi
N4AHSy4NFVeVAwObW6lrN3TCHXn6jWtJic+JqjtwaxKuIb9WKiskKSB+adbJ
aXu/S2/76g8xst2iAhckSxcyXauGLeLprBCPygoVTRh0hBNqeufIE2sx5kzE
qdutCgxOxnP9zGbvJvfD3WIfhnL8lnTeYI7FkjpE9lMV1/yjNShu/DAc92S4
h7g0sZQARXZgxJwn3MVMgWKVm2MXBWBs6FqDiR2aSfSAfN4mNbCNyxGs3PVV
RLUUAgNykOLsHDMzgdJ0fDy8ByzS6VLAMcmMMK55PiPU0BGewv4EWZyUUxRL
lDyAQS6g51AcRtYtuhP1p/0uOYRH+Z5WRbqKvRSFzt0Myl8bl4BWLp9zttCN
zhYCHrpNXkITRZJNiejtB2UZKPOIoxX6HOIKYZv80RGJXMkQDWT8WZhXORA7
vdilgbDhGkcvOTkak8qqcwFqjwghBzIXM6rvKkwu4Z8E6sTW38eL1QJEezJ+
iMfFbJcgH5KFJmcTcsWEmqfheFdOvtbtiGKeNrHi6E2mXRoRWw7Wzu+XXKDx
RH+FpB6j9wTLTjlLwYkSSRCBgSLOOY0ZFOAtcLDCOmIxQZdjBmhY5LD9d1wS
RA5p7VHHoPME2Q3xM3RbJVOiAcfzRqnvvqljQtNi02hJwfr3vVHHrc7swJlC
ZMSi4sJwKZvQwFUBifh95gQiMd/Ex4/KCyGo8jQbdPc2EYTagiAQK2BFHj4v
cJl5upyhEj8isWYdtf7J2hxKpksY7SaEJ7+nrBX13GTplpfiFJNitDR3XSKi
3sh4Wt4YpcPdvq6KQ7zHUme0ukxMUJMX194hulJybHsmXnNCpvqgFTnJzfK1
diwowozGpfhe6Fc3qUcPY+uGSB4Fgi+cqaGTBkT5yjFfa+4lIXMUu2P8G8Us
I7QLYaDFAiev5MB0pQyEFMkiW43I6iJjUvzXIkfxSzbpAjLpOq6l0K8xVbzg
mnFAm9JFnfqgl95VzGMMfFydXuubnryXh+QMbCym8+CzXf5xIMmv4hf+7vb1
KxGNB8fngJE6cx3PBKg1ZB7dcVjEnunm8l9/BR2oQ+DJo4CGctPtyQ3rpcn/
BrQ4b12v6XUnz98k5nupe3cN+fAYxfQmIEaxaRYdKfJPlAjaPG4rNDThXpyb
7X4PT8tJkXJkgRncJWTt1TetANpOz011D4JXaRFZ156JyMDJNUEgi0w+Imhk
QUP6ja9ZklNdJhW2jfQWYb4EcRxMdurh4Qc72u1KaKVjNEfortdJ13Fuk2RA
53NPmYJFLwnn7hDnDNchPEQ0FPbj4KVbl3VZCnIKXOM8aMNe68ejlOZdXsa3
d3c3mOAzS8fuOvDfGKnaMKHVY8RBi2ukIb95fqd4GImNcUXXdbIE2+EmRAaJ
XUDsnDH+wvvGsyB3jpbXKLK8AZZmAB7diwGbIUFktAzoKlI8ytvc/RoRSM6h
g393wIyOQITqPGydpLxK5qgRbjidgLOMSGVzKKmOQDBO03TagQH+jHKtJXPJ
fqtTCeWt6ytC2xjM9JqXeS+UEoV5aEQgYk25Wy4X/5MPQrNn9KFad191EkPu
NXzGBvpuG/0okvuDbl/KQsUscfYyM0tEgzIG1epr8X/KIjEssZZS+o2wpNgL
aSR8NDWgYgx5o11vBks0M9KYAlgZakwxbRuqOMGjEPgF9gz1+yKcdgL+3GFa
xjW+3z8seffkcPgT41fEwSSp0ea1cABnbB2gBv5BcL1prU/AXwrXVvdmoNrD
XWrkQn6JQeP7cL6KxOsXZlkoJT1jUk8Ddz/4sd2URmWUwTreRAl8Lptya5MD
QW0mi01J2TvXb652uSZU1xugh92W9jkeuDbwoVMGWNY46FB3OC9PpePIjFA5
2gXtErk/juwNfAWLuAiCf/zjH9wyiF//IH1ral9X1Ym/ovcfCQZ675Vv1YVB
e7ZAUOZ+FdTN2ySNXVbbQ/WjZ92Hv9jv9//zV3oltSv/ivZZKhMNG3YpS6qA
khNGGB+BkSALI9alrSk6HT8xs7zUTiOuBi2qiChjFHwx9NmW/+lmfxL3076H
MexfiKlsfYvA4IXpsIfZm/jSF8tizeslm5otPo4BOeXMxohG/5mJfSXroCFz
lLC+6vhInHqwXEgnXydF+F5qsBz/fxPoUGhT+LTKCoPj/qBSyXq54RDM+Vv7
xfq33fYStpVED+nP7S3RIxizNWU3KJzHK9j10741Cz/qH+D/c9d+QjrhHeeq
R/NJT/LnkaENTZECHCCokzC7YxmMdL+PRlPAK8fSenkvL9ZzipdJKN0PIB0E
1QBSrhNBMMY7TO8lvNBQ0NC2orhcn9Fv5GNIv7fkvCmfyFfOG78npC+fkH7D
pgs28ZyGhdazOGdJZrzKiiov0Ip+MXBnNesS7kaRG5RbDctxTGr2l2jtQZLZ
3YgMa6a4BONtKOIFpyNwpqgusYuk9i5NUAu7LpdShm2nmGBhB66a+Ar8gQzD
TF2/3sCW3lmDrlTYykZl08Tkh8PwQGc6T4fhvON0gLFRjnqO5ga+F5pNVbKl
jE6EZucFKJZcF5u6uXl1TMuY3ehAd2pWdSJEJZ+2UiniCwKvDAABLo7R+Trg
8MU8qgb8uFRIP8qFf1AhjqljNoDXcNGJf/5q/vx9B3tn7g36A6wLxb9z+sef
fzBKfQ5S06uL1rlqtNt5SC0kUc6iErZArw0Vr6Hilcc/RkL6z/94+fLmxXPF
7Qc1qbEufaE+9Pt98mLSwxr16cJ8ojYI8Av1vXlTOV/5XzKLgZc7mF2ra3J0
4U2n2/gZkbm3HHlHNznqme5gpaXIewbepZ9+8P79WFpB4wbxv19YBij4+Svv
DXdob+APwc8SPPn/JnyC8lN+AsafRuGDf6OwPqPuzw+/G8+PDYwYQ7rc1sRh
9rlJLjIOPc3+uC1G7BcXS/ZjzjxQ60WSxwdjLyKMBcf5ggduaDPn+FUrrnES
2bIYp6xbgsNOyhr+pD30gAg9vZiAlPabcI0hQHJCVsvBtY+UJ2hR/oOSJ013
NMEyzBCbd2ivinHN2A6HjZp/Mg6cHNaKjeGUIm4BP3WXBroIFEV/12TLmSWN
dMcZ9hbVRT3GlS4I0vfhiy/Ucy1vrWNInjzi719gATj8Bv9bnsNjU39Mebzw
O/mL8phlubzHMTI+2b5kTnEKgDYlSbZjJleLR0ZHfsWvFmDiJrdJcnxBXPbZ
+n2LEw0r6WzrFi7hQJcw7sWUSmI46j7O0kTQ2jfpNRzQ9Fxh43SVUH+22hXZ
AAF1FkClx+3x0oVnqHe0+a8fJJVFO6ZG622+4rcp/pBQcMpMqr+etLR+McNw
UZGDWXWpc3pEr2WKNVNZkrh0QYET1K5KvVYqS3vKiNgKZBmPG8Ym0xnplQ9B
N4fifgQ6UkRtsHkF6NDAd0zyaD2AqJ6o5hN34blYjhhs2Bsbnx0GIFDKBKCN
5sUFZoqmfaEnbpbOwYQLVQmXmEEoZtKt/E5pkPQbaEd6Huy0rV7/NtCpNr0X
VIt+oQ6PDwf2KbLZjVPCsCR6jeYQaPE7CcGW49C64FwPQIAifrHu6Z/dXwIj
SjsGqM6IDV85or+zymIcn0T6xd5eGY571k1vhX2HglZG/ahs137DYanAE/m4
qmiFLz11LYt1tJLPPuNaNISEIJ+0Iv3N1suxsbrqQmQwVgeBGH2V8MlH9glr
s5+QHx00stKpaeXKXb7mO58CyD09yKetmntL5o3v8yy156APQfOgJxMMfgjf
7GFPjKfjh3zdegwuwsJJ2Lc8nu7p9x0Yc4kXkpTV/g42C6kduV8jJn7olr89
+dhvnS4kVY3/I8YL82T7pdgvjbnwWMKDMjZ/OkLM0/TdarlnxoufgOQNaNGG
5/IJhdHz7fGp2yg1/pmYVrUrK3jhLK1PmssnIOdnmO7njs+ss/VEzPSeyp8l
9XgjQ8N+T3vRPVUYkXq4JbbK+PRJO8q6qFaPqF3/FSu1uvXfVvbUIM9Kv7eJ
a/3mdiTj5Hj3OIe8Z6FaJqRmpc6DKkIP8zNHsxIgK1B54ocVdcn93R1oEWWw
ETtS9ymzVJWJn2SaVpXrs8z4JNKklN6PoktrqH0UadYQV63cc0mgXUL+lBRQ
L5I/P4Js0AF+avwI+H+J5xI9TBT8jkfaFaU+fIFapu+NehRPIvsttYup1HGX
PVBttrnOVxmn1G9Ye1BsbpCTymbT74pZFkVNHj8T+POzsjiiJY7dcm01jKkd
yvYaCZMRHfz5e/1rVxmv9J9/qHmV88n0Kyp02q3Z4fyGrxKyJs+DwNjxOzQ6
Hpo9D8ZU2eB0qHodKm6HwRFdo7fB72AmxEGZhEpOB0lH82IT+nR6oOZcbJCU
Hf66Mw5PjqNReBANT8PB/ig6G+4fn58e7Q/3hwfR4eQsGg7GR6dnxxrfxSnP
A7VHS7aPlfhM4iPiJJujJNvFSBqCII1xuLbwRyVK4+ck4L50w8eKHtsppSew
Rjk4P+jv9+F/9g6OOu1xme0mP3nC5Hhj3cV4eHZxsXd4UJnd+Zf9xVnTz+uE
62NgP/fDP+sfw+L29+vP/3OcgNPL8mMPweHP257DzxHaB/uHQGqDweFTgB24
T/BfjgZw7ZSDvpVy0OCyvoW7GyVs88JzfCqUghP7WLcqo2nG7sB1pbRuSarp
uxtwfT8pG1y/hwUY3H6+sFcp4LpnIfU2olAXJXWSGqVIVSLhTVUZ/E/MvsGk
bNP3DO/jKLhfS9fk6kpOkiki1ivFWEOtVNPqiBuQk5t6eLkduc2nh2q5xKZs
rzjqglsfPqPUWlKUEs5up5IUzmCV2nV9+0yF+/AvADvNVwIqylikmOe9Q6XU
TWoQlvRgHNk829Xl5niJD2gOUuBMUWyjZ43mq7yg/hvlsHMW6ZZWDA+s2tqU
dE91zLkFUBYt5+FIWoKm5QyyvnoRcj5Rt3IScjF0Xv6GoVMSawjasV/uQA4o
m76p0/6k8agPdUdVhNPNncv65LgY/8YB/ErYahCzvCFRI29e34IaWXKjPCGM
VbHeWnXITYphg7ulGt46PzLRKgCnH1rSVpFYk67ZulmFLNs49aE2SbfAW5Gj
ZS/EQyrvrQIYGIr+uWHbQsqyb8z4hw14BH6hH282v3nIfO8Q9PLj84OT48Pj
s/POY8tSrC1QgaRZjer3+01cxUaZ8aVPnUn/4dkH+pFnJNiHrvKfjye+2j8e
5xN4avT+w9PBScf9+tH+A+Wzmb7JFHAWs9kecBdZWvPT9MbmLx29xX+pRYMs
v1hSX8o//1B+9FhdUdvOafeblJiaNW2ryZQ/fSw/Kr1TXj7jN3sTCMHDmlRb
QW/nQ2dU87wB/0vOlmYCcCAHEEvJKSqCygdSB0ve8dc9pJM9pIs9pAL/JQ23
TqstHI7GRwcHh4PhJOrUU4NZC/LehnVUCWavjUACtbe/Z//p/oOPe6/XtBlP
wNYcwg+iprZV3ztKpNzhwT0OqlWBlFTlvWSzAEWqAXdbxuO6Mn5bWD7CtPdl
ocvJ227c2Lm5vsKbAgNzgTk2H8jS1ZLvQOALDPC6AOeiA+/6JcK9aGzSprGe
JpwyBJYpoKU09IaJdGnRXG4cv4/sHYWRWR1B0pYNSfuV9mseKpc8cOHJPJKW
IJQ3J2BpqO6WgvxSL2YqZGY4Bh0Bfsd0W2uQTggZ6zqs6QLma4tY6mnGdisV
qPnXglvWYIJSaW2S51ibb1YzHpfc6dLD3KlTcIsKHF3RloOpecyXuMEhvgql
4qL+np1+QM0EnDepuRG1GB9x/6obrN6NS0lmTtEsda7U96k0gJhpqhZqTkWn
NwMVFQTSG63VC+yVGsdjXVJpy2fdo6ypNa5UGpuizDdXXHNpza5K+aiUvErT
GAM5phS619rCrG5unMeUZ2IFFBk62iCVhDzLcgzgdOW8TvksN7E1pReIrqZG
AnfEvUpkZJsKyuN9UWV8aHxU4Y85pnZZ5XRSeys0zos7ceHA5YvukQGg/Iif
1BNLCz4DVr/puY8QW8Cs72bq2VStT0nVKyVvfXKu3tHRRsuoNGVTrp4oxMZ/
9KHO5qmPPIvSfBhFB6PhaXQ2Pjkcn0/C4elgeD48PBoNJ6cnR0eHJ4eD4+Oj
g8j4tcQvRG4hyfmrTerrwDJQ5Gdo3HeUa5bZFAxPlnfLbsFjL9nDZlLUO29N
IHMaZXibd6d+ygZfWF2YC6kEZeTXlpPpW+lb6MSgog6BaaSV6w7bc3XpatcG
dhl4JZY+ATgUbtHfT8H7FBLYNma0EflPD082Ir8bL2pIUfUZtEsBDor/L5BC
Wwhp6wjSh48KKtSZhd+7pp2X29PigK411rRYLzmc6600n/Q9b7PjbDbPrWe8
eecbnPk/o81r9tN9OhxcfAo2+tvlFtOaLqzikKT6Z30rKV24IZ0h00mwKe2E
+6I2qVhlSR7oxqLknnxI9Uxy5RFdyy21mYX+0VUQpceGOa6gEjl3qq6tppZH
YECMnZHZH81Fuz7wkY+bHqwtM9eG5G3dkY3Hb/Kkbg7MP9GX+tHO1GrU/uzY
icR7DlX/YGt8qu1cVYfVu85oMlSzm7ZuyC2y2nRBHRVFNiQr1Dput/DcfoTr
tsl3+ynO2/N9ct42rqasmNacnV2YdeO6mj/2pHO+Mm7cVj8unIyZsPZ462bd
xnm8pfesfc7vzV/1brTt/Gi1vqftXcyeI63Rk1Zdiv/s6W617fxqtZvTgstd
vPn7h3+B03mCm3PD8bAc+alOaNB+QoOmExC/Ztt97+yEoR9KnepKBX9Abd/f
6vteDp1rBUi4fn9U3yHNNHZo9q0GnitS96usdDfGy+e3b02EgnvMFwuZK4py
qqEO5w/hOjc307cEvyWdwI7F+pFpt112QsbIxvHKCO2HlArDQPo3tR2DaQ1q
O9CGJkycSm3kVv40/VnPbT9bV6Wsu7oEkXvFYEujMMpQ4JfpwjEK0Q8jyTSQ
NqOgSGllUm5PpH5BAJICb9EQtU4mkzd5pfWF1AEV/+KhzuKluSUm3K6QlZrn
tcIMe3/YPqLsNGydLxDs3jNNYnmS8uNyJ03MdtlqzaY5KPnmnDab2ler75po
bX+ZuC0LTe/O3fZCtErbza0X3dZuk/Te7fptllgO9d3UjS7jUndNabK8HR5k
fNPyXNrscatWqhQepmOD+7RS0xC7qd9toRcTOIsRV69zxY3x0hv3pD3Lhmao
bnnfhrZ7wZvob5qfVJrNSccv24Sv1Chqi+ZVm7pXcTs8IzHW3JGqPI//jqqU
ADnNrh5V246+4q0EzPPRuY6l9aW1XwRyfwsSTshtmkoYwQndX+blbdd1Qzsm
o6zUx82blMDxkbNyYKameZxSNe3jYNoy7HDeSxPUqXa6q99R+Y54JCJuBK5c
I5dy4lOXuUsfP2prn5OngHprOdlOSmdblZp/gRCgq/nctvptaWfKCSOZCGn9
0CiMKN3eNBXTLbpokaaTntq6x1g5cwzLCNwre7Eplwcp5kI++LmHIa01Xej7
iuyv7jUiJseu0iv4qd2Bg+AWMbCmR+42DZopyOSIDPxcR5N0i03qxFrYOwNY
HQJEjscm3uY1j2X+R1oDuiW6ThQ9MG4a+kmZy6XcdqgtF0dVAqabJEF5xYAI
dJGi15qy4kvUveS+anuTzYknvgq6qL2pgdhaZXLYI10pFDYCvEIaTK0A8aDz
/C/Xr35/+eL66i9fXz9/cfUX+Pvt846Au4Y5AIwrN9sZx1kgNpOPUDwWd/eP
1O23r9++uLLHTlhfIoy+k/RQylPdUpQzvREMAkdUR1rq8rXFW+oshcO3w2Cj
02Gn1ApaN1je7e/a1kJWHW4bik5LdGO+jHxTw3yOj5bg6bSUpb2s8LIovnBC
1OymDxIJPaDB7RW49VU5EwHTn4OGcS5rpgakcZKjqt/8JtDtXc39nugBrn87
N10V+aScF0hwY3cX0wDKvRIMvdf2XUONl35n67pPg4ZPf2M6wyJkpMGSd+Jb
4Z139HLl+cbT50vS19VbwtGfHbPL8k53Mq+CHFZPDTxNksGGZrS0Rp4kIO+8
vX6dWhrdUVJ5taLbYw+ssZu+thUpKZOBFPyjzqJvPmbMnsFLRC/ljvimM4+L
vHp4pEW7xKEav687+D+WDj64rb9OUIdUhUlhrhKghkncEObn9AqvJpxQfN4H
oy9VbaIPZny16FEOy0R1g80JDq40ImngMkd9x4tYQlGSrzKdcmT7Z42A2BME
jL8vbnoOlGSiQfM1s4a1c68gN752bUe8FTEp5aF/VEKLjqGHeUtWS7UstfZA
y3F5fsupDWg3xUmvqha87nKGPvXJpo5d87WJLNXXjbpRJfVavy8xrfbiVVPE
YPqLzeeB67sZRqPQAFGiZFWzBQ/LrM+rTK0G4HJrwpYFhA2eVb4qhcvK/XU+
UyFra3CsZIrXxcNOT5x4WJUP2hBxXevMrSP0m+rNGhK2/Si2eV8HkPn//tAa
BvN2e3y6vzmY+LlKdlu6V/y7ZvffFZ1PLzLcmPRAjHcUomzjq1DxBV1zB8wK
L2mqzfB3C7Dq0g78Gxn09Q7OeaFkXdGVJJiYzfnB83gRF6aRd7n9eId0Kl9B
CDy35ROzDeAhki+/93NLOzg8OmlNOzC8Yvs0gTb2wrCt6dnRxNwbKOPjOh1v
wxHorScx/SotbaKsf2dJ+JVnNUhWTlbYxup7YsJC26xeQNwPLv88g+M/x9yF
UlFQW/j8d3Txp1OzYQ1GpyzIu/vUXtpZvWOc8uFzcxWWc8crMnS5Csu7o4PE
EAdJXXh0taNF373pDmUu54mdy0urUQIzsHchjpucR34DW1AS5hIFJgGHfkvP
ftbNeivNt9FDm4RgbIBsfuAbtMSnweLZXTsvWVsj2l1sewKXC1c23jMrJmwu
IRadlMB3Vzq6AIjfNH0Hwt/dFN/BPY7BGF7B4t0bJb6mwv0gtnfZmOswbS1W
uXCbwhAEQHOniC0Do00GVOlCRffbDu13H9J9kAPft1GZSEpq4oRdfbFzC5Sx
rPV97mA+lk5Bcirr+zZLT3OTXFJG3DH6LuLa28111EF2iUNY4nttYehR3HMN
UDDi9ctFqsFM90VWKujpauyH1Dnsi9LNOf5VSsxU+uoyKD3y7oZLnZtqWPmj
sjX0T5PPI612cQ/CPE9HdFe9vQIVLxPOGbKl+q8dR9V2G9lw98Vu4DV1ZB++
yUje7asKdRNOCEl7t79uvtGc+mLUwVEPl2LHBg5Z4zr436bZv4pNGSMyCPIx
TmcFwOohzMYoJLM05P4ETnFjUGZH7gZ0Xq9+O6YgnX+oDg8LnBV2TQ5zuYCO
ApjNaweMfY7LjN7jpdUu6+YDk9wmsyi8qMrlo84a4IfANo//T1TC02wsiLPN
ldpSusKnTiUwHM19SEGywfz6gKtT511Vm4plYWnxjihYOcjnSiuvHZmyN+RS
j5Tq8ngJKM5xYu2Zx6ArNwEBAIfZaEZORlvAOlxJVxaHN5tf+zDYnb49FzHL
WTl2UalZtiW8eYqZ6MgLAVTv6RIixVOVzpCdldX5BbZ99QdpmVJz3bzHLGnq
un1QiWWiYaZXrkFGHJuXR7cvzznsFi3oUnLvmqnN+88NAGA4HwR9wEPuso98
DgERtmPSJkRCzKkp+3Rxxc5ndGhLed6MdIWGcvlDUjd612G7a04VqLkAWkxq
VQYfjeVvVBducvebupoH2vcQEwY2hd9Z7LJLHMseq8vHMzCZjElqWU0NC0Gw
O0SLQoHpzZULXhoDwrBOr+jJxeO1I5TyH+kMWGTlcufFg78644qnW54Jt+Ue
FS0V04RwHo3+LbS6IPhWdyOy7ZpIh3ZUh7Aq9zEob+nBiIRAvNNCba0qmtIq
mp3MOG0QgZrmPHHmtLmH4rXZ2PSi1pO2oSbyqPND8Kh6vV/xUBflt+Wh/wmb
Ppfo4K+FsE8dWwA42IpvetxOMLpVQTZ8z7lM2D03Ge3EjlaGOe/f1ngCCDoE
rQ/BZidn7XF4Y2G9KcDfqRG9faWuaC2SCgH/lrUZJTC3aCb6I7Hmy1WRJuki
XeXqdg1kttCoGVzLle8c1/qCleG1zCPpp3c259HlFQI0ZxnEf5Dgd+Af2Cgs
G4W5jpl9IYP2dJKAnsv2o0AVHL7v8WS9ePzoTW61JrmfWD/nLgt2HZq/Sscq
1sFyyloMJHeG4mYT3d4qC0fEe2D15cVXep7BPAElupycnh/yVVIhXWK7AHRM
VoshLE/fwTOPQkLzH6MszTUYvhWtZE188ToBOokLrBzTeVuYDpQa5YUuoYzt
W2RVOtZZ2QCA9UmQ8tnrt6/u3vzp2eur5x7iuM+3RCBm3jpr7KPwpGZWxBdX
LHwK3jjjfAz+NCzPxaBEXd++Dg4HJye9Aegyy1nYO1DUkg8kzu1r/gEQwt3D
P+nMZfMBrqbOCK4WadQawWvXQQUgNU5lUCnMD4/le9v8DiqRf0WTViuoFU2N
SxxM4iRwk7rcC01DX9c1Oo9cuCANCs2YMmRQuwQn27KtHt51ZGA9RcJsXlvL
2lImVdhDXV+xZAK8QsjgQmuvY7cZ/rQ4cxzcdKYMKQ+T/a3VXm9FdiCfDa6g
ogmXoERFE2R0NOrMLv45t0AjAtaDvGZdXdF5ZVW1ijQ8CsLaTZnhNYNvP1Cd
hoKKdCnnkVUAp0RCmNTGlYGu17oyTllg6xGs8LZgN8cd8XI+WOKte3P4RlS4
bAcP3wHsuzVsTq2kQVX8rDo/x9fQtgBwbgpL3Ft+PaWN46hi23Lo0st0rT3v
oOa8qaCBvGV9xY4TubORmHgbVEyrHoCMWxZBV+7pBNBS2YHJba4tL9ndZTRq
30X5WOoZSrfETpC/GFNODtJLP9Tpf6UVb5/1l1+oncGupLRnUeBQi08KLRjw
FYmznYNdcTuaM6+1YhwkkPvS2ZFbfzf0p6ZvcXACNlOfweVKv4bmKZT3VLpS
UNwTxlJATuhWPyTjQP/2pccV6mSf2z+l7hKtT+mi4t6f9KmNVAbHBwcbO6m4
E5pmKvVXSJXTe1q7rDR0Gmq5ysbm+5yeD47Ho/2D8/3Rwen+8dHZYHR0PggP
hkeTyTAaHZ0dDA9Hk5ODjglslxv8OER5sfIvKqkuouamovJGPirCv0V4vyG2
b/N4fnh8LO+tatT/v7g93z3xL7nD3L2tvnW7pY5TP9VuN7W732rDjQ3vN23z
5MLvyvUveaZN+wNl4CLMT46Ozk/+NTfWiqyBKrcbMqXtLQLZFDY3BIwlZUJK
/eVWX5DELdqYDs+jt9mR3zU8kUeqQTuTMCcZc823HrrJc825x1sKWD/x7TMo
AKqua8+AqnK1vNYqjYtgdT5h97cyuPg33RqrY8+hU3fpXz1+b39rob20kFFu
m3Zx55vbxf10So768FQl5yO0nO6W89VdgfwxUx42K1afXfn4fKnUW7Htbt1a
S8h3QbxoUL5w9/OLsJ/t3g8rtx587j5z7hUnxSxy+Hst+7fXvqNBuiXzd42A
SdZpyJR2JMu/RGu2w8Pz5hxpfffflp3Z2u8N3JQp/TllwSa89G+d9SRbq0ir
zlFDxv8fJUUPjgZHB4PD45ODw9PDbZOiq1gVNCREewpeWwZ05erJtjmcbN06
qe1k+zrC27v/o16G+5dAbO2vqFyjIdL1YBhF4egsig4OR4fj8SA6PwtPDyfj
w/3x5Gw/GkXnkxAAf9p5rI7SOnlJrjfN/yTp7g7yg/fv0uoaRb4H4CdIv8rG
nyIFK3tvsHpqbgvZJCK7bkWFGD/eNTA1KePbJvi3YPfHd7srIfXefmt2/8lg
eHA4ODsOj/fHo9Ph4eHR8enp8f5pdDbZ359MzkaHw6P98+hom9Z3LYvzn+25
5LrnC+S9Zm7ftAf47bgtdx9bMqjbd/FSzaJwHGVqji1cqGwfNJfLV5cmFZY7
fqkPlJnUGBvVSU024pS3N9TCiy2qPbhxDnppV+fmNhef0hDKHSLwhuBXd/vq
WrIha27CQOyQxlRuVmqwY0by01x2YV16q15qsJMq6nwscXrJjtUD6K5o/hBe
aLE6Bv4sI3DgoBm2buD1g4UHnN2HC5wWj/qXnSIDTHkM6C3swodNk5wxg+B2
NSy8H0vhvTdcljB2Go/ha6/2LoPg9RLHAMW35rfn0hqEOidYDMPfG36iIAQn
N2CiKyXEYfmgbYij43OqevF5x8HJvsL2BNzk6eD4nHvlRCNQEbAFV2U5DT9x
HzzT1E/JBXoxXYYyppdXi6XOu5IGUJo3654wEmOO89Eqz/12M4Oajj6UxoQI
YhqGVVZLwL1ZDedxPoMBvSx6/P17tzElTADD083NwaWFmMRIOeYEdG5BRz21
bHyZIkF+fYizYBXF1OUkLwjX59RwJaMdRwug1bGE1WO5eRrgE1YWYYKvRKlk
FE3CkVhCK2o6iVWm1MkyCL7OwinHSW0STAOMLiWzElDJiYLjzy/DaTySHKed
fBdZtHyj0I+H7SpAY8VWDuVfX4YjvJUwxxZseDEmxbWBe/vv3QDg4ID/A7TO
rwASYWzz++gyHLAVpXh2ssoIgqUFIvpergD7s/xLdWlSoaV6R/CE4u0rRDL8
5Nnrly9fv0JydZqAwiLMCwwTGnSrKZ5xx3HRr+cRfaXT7ICEp8BeuILiLszf
YS9N7A+Emy3SC1Bupr/G1NV+mk3bOJnD6Bv4Gb/x2bia29bg37ztX5C3lVIY
fgY8DkDjcrlP43HII2EiKR6rtA/rDcPctFkCNPs3S/xXZol0uC+1clq6r+0N
lRJka80MfRW1oqJrB6IptGgYN7cDj8Du4sSmQBPuqdMB72x//wQrRy9JiS3f
wJab9pi6SK9LPSetil4M5xclvRq2/ffyPv+urki5Z3aj//u7bcLmPXf/+3vw
917pv8qDlqeld2Blkqlk13Dp3hlHwiSHp9/Xd/q2jAhWBtKqBgAKlPw5yK+2
A0In1J+/h5HUc6BWQE11g22jI33/spnElGstDcfEryR3m+UJMEWNIf0//8DN
h5HTVfOeK/hWtWpacW7jsBbbTKfXwUCj2zYFzHUFNWyLSbfWoAkdlUZHb0+M
jc41knTksgWhfyvPaxHQSYhm1uakRNPvjk4D+zSJtCZ5lt7RacApA1FPTV8R
lisPU1Xp3+3/bXp7m9E2vkOLDPPEg43uEeeVQnhk4r79CiVr43+bfud3JuE8
bxsEFum4XLxF1ubdlxb7T1qkZh0esmrO4YjwBorL/5kMxE/xbWAhxqmxNQNp
GLaehRxuzUIum1P7SZ5tZiBmKz39Xh0X4YOuSYqux4hNTKJGzvW2E2pbvkiE
UfZOa0FXWz3hS7s2L1UJqasA3IDZHir8tKhtraWKVzSXX7CNgpQCij6sU+6H
1PXcu8vY6yPs35QxiakvoTSwpOLuAjB6lUXeeKYnoOJKRBQrTYuUukvvO2zY
22CR7VJeMLUBn2OjrsiErPXGAD5uMrXuMiCVBxLkZnUYPjKtdkuN+P20bQ1H
lcWgIeejKAmzOM2DfJau5tiD0Zgu0Ziq//GOjhCUcrKc8UNqUAAzTmkYsU5d
a4Eu6QgLMCjewVEvwjWaqNMVLAjMEQB7NJ+4TROkXofratAEUztRf9rvUm/K
IsykhBYouIdq0CzqLeLxmFqq8yTi6tXFPsze/W4kbgsNrsfhenhzT0Sg6tLT
JSEMTH687pcHdgs6cG9YmufcEbMz2A2U9NTkElMqg4B/jOUN2i+axZnumJZ3
0frE7PccIwVsjwLPm6Yp2rY2055qpI3ZRj1r4BS7hG2CZti/As5Gik8t8vVZ
08M4vWNb+5dv9+W4lynGi2NshwLsM48z6vkOJzjmGjJs5mpQguRBDQrQfgNV
qsMiMBFvoC5z8GnloPIFFnm52fyjVO7fzrHK3lw4TQDF4cP7FGwGqsOdRBm3
dc1CvCNHsIpn1e1n10qQHds644Cp+VaK0PEGHRe+kg+yEcYH/YNAlchcw9iS
lQYzdmRhl0E414QFG74PRw1kZSHiJKcoIUancLNcJZ4Tokbvl+jw0t0B5qkY
dtZrgYMJ7V3fOB0g0CkAhlZviu2XMcPy+irfbcJFJqYqtLhshbiO3MU+4Hub
dg53ywEmF6aHjVhbhWh4D6a+qWCZWP4CRJxX2RIS1mpkyByWADsch3IHBr+q
G2zpUdy2T75EATQCPkek4s1LBT0wngCe4mQ4u+6ob6gNpMA8zKZRd2NHXzwo
pkKfh1LtEpNFigWbq3SVUwP1VDyKkUi2ZPwQjwFV3AFJfAFpedVtslaK63ED
r9bUWZb7AfW2XhtKrm1dVVkV3lG/KvxKuZwPv1p0lyrgHvFUuo2g/gGIlbdT
Kgzk4FX1qoEKNwwu51h+PZ01DNmMteWRmeEEdnCSQUI8Idb44fnCt+h01RLa
5Qe+P7FLHdHJOxtiu08k0iTiUd173KkkTTfy6alL0+NszI2fxeVUupGlG+jk
rUuuW5JeylzXiok8jO8E92Y5K4PU9S1lf8Gb5797e/3m+RWuWksIq1hwdx8a
wYoaOgBBtX4H1+m02DFdbnYIV56RLxmlsSnY82SWeN7H9otbwq5d1vXqf9Oj
iXuYr5e6iqlTzaW/TgTGy8s/Me3o9+9e3KrFqgBSCMob4xrA0mb50iq+7Mw5
4SSapgXXbWN7ACKSIfnHE7q0nh+CepdKUbDHqiigLz2xTX8rrJZVfA6ofJLS
BYMBIYdTUZLwuLHnDnGrHFvhv05sGzFPMwKt6B1KbOL35lY6W8JpuOaIJHGS
IrrgEYnQ0dWDGKExBAfsKMFoEEBnBZyyizfpCL/L4ynGeKZZxLebS0jA3L8j
SpXup4DcKc7TuQhWXhKOI9rqaI6iEpTqLCQBazfG3XiNuqfvmYBntDqiESTI
rn2Nmf04zvimAa30iUIiugj2muJrJuiAidE54JLp8AICRHpHSYlE7gog9BUo
tDnumbfX1m5fObyWugnHE9CDyDXAdxde6zPSLMjEqgAp3r65JvlmvkLBtGFK
Z0LY3izMZ1QnjZcmgATAk7m+6pLExBV86T5GvH2IgBTCXEo+7Ymjc8GFACuF
pPRguw5Fha5PWBtdikLGIC7t+s0VRr8DdLUNQS0I2jJ7LkfvkvRhHo2njIu/
9P9DUxwU6Vma/bIDQ3XEKI7Gv+yQidGRbhMhh0IQpxK8+LYo1LNwNafGy111
FSYAk8t59F69APpNc3UDY/yIP2TrObw+D7mM9DZM/goY+BKM8CzUUc44o/uo
5oiZ93H0kItZh4lNfMNTuhCw/iae8hK48VagvaR/+EY9m4UxLHDndwCsP6xo
iN/HONk3qwzYkc4u0pXiTAIpkrNMizonNbJ4fvuNfaR2XpLZp65W74CQnmfx
O/VbBG9XyQ+/j6dwTNHqPTxZYRF38Fuw0AArH0DbeZMC00L4rOfxQ1f9dzgD
WvnxxxCf3obZO2xfBWOO1O/XyeidtNz7mu7czkdhcBPO08UwptU70IKjIFVA
4NXVcVeSx9Y4IgtmFi1hMei1BkmNHMHE1BbIYCOfBwJefYdLA/aeZhNqZTjE
Gx+J05FaKNLD1lR/A1ifXD97hfyaqqJ39JOL4NL1ZVBk1Q2HAj7Tq14riWcR
NmUZ6UuW8T4hpEAswkbPiJnFruOvaUz3ach6nq9QGYRNPAO0iQkoZDtmRDyn
oBJ+jTF8MjxushTU7IXaoTAeRh2TtK9O9s+OB2e7pqXnq1BcUddJXsTFqkBS
DNxF45s43Soxm7uLRrMknadgbOy8un52Rw2+vgMNJSnNNjg53e3zVSgG+fGu
lPmKzlPfjRNx8ylUqzG+QQkD4h3SxMnnTdodsvBhZO+GYwUsiUYYrc9iojWn
lwo1G6OLXDHHIZ3jja5oawVRAnjA/AgwS8LfwMhEMKaERqhEdvViyujQ9Q4l
sIdCjgaETL/sCEaskwaDeGVrGeGepdQCkiF/K8rMJXuAyZ2LbVm+vLUdVw1G
PH+PVgJ2icGd88WgcwrZ6hO+xch+mKHxROPhsPemfxYs9ku106GX5rDwaNVB
z1nidBhoxj40Rr9Ns/hHeHKwf7CvkW8RsXrwDVA97EMLEcKN07P9o8Nz6cig
sSP4VOxQjB3Bp2KH8rAj2AY7asADx/8/wcv5FKQRAQA= [rfced] Terminology:

a) The following terms were used inconsistently. We selected the latter form. Please let us know if any updates are necessary.

   ALTO protocol / ALTO Protocol - RFC 7285 capitalizes

   advertisement / Advertisement (when talking about messages)

   Advertisement service / Advertisement Service

   BaseAdvertisement objects / BaseAdvertisementObjects

   Capabilities / capabilities (when not used with "Advertisement")

   Footprint / footprint (when not used with "Advertisement")

   resource id / resource ID

   Footprint types (RFC 8006 uses quotes):
     asn / "asn"
     countrycode / "countrycode"
     ipv4cidr / "ipv4cidr"
     ipv6cidr / "ipv6cidr"

   Information Service / information service - RFC 7285 uses lc for general services

b) The following terms are used inconsistently. Instances of each are in parentheses. Please let us know how to make them consistent.

   Footprint & Capabilities Advertisement (3 instances) / Footprint and Capabilities Advertisement (3 instances)

   footprint type (7) / Footprint Type (8)
   payload type (0) / Payload Type (1)

   footprint value (3) / footprint-value (16)

   request routing (8) / Request Routing (12) - RFCs 6707 and 8008 capitalize

   Properties: RFC 7285 doesn't put properties in quotes but RFC9240 does.
      "capabilities-with-footprints" (1)
      "capability-type" (1) / capability-type (2) / capability type (1)
      "capability-value" (2) / capability-value (2) / capability value (2)
      "cdni-capabilities" (11) / cdni-capabilities (0)
      "footprint-type"  (0) / footprint-type (3)
      "footprint-value" (0) / footprint-value (2)
      "footprints" (0) / footprints (6)
      "pid" (6) / pid (0)

   delivery protocols and acquisition protocols:
      "delivery-protocols" (0) / delivery-protocols (2) / delivery-protocol (1)
      "http/1.1" (1) / http/1.1 (7)
      "https/1.1" (2) / https/1.1 (9)

   Services:
      CDNI Advertisement Service (1) / "CDNI Advertisement Service" (6)
         Should it be in quotes consistently or only for the first use?
      map service (5) / Map Service (2) - RFC 7285 capitalizes

c) The following terms were used consistently; however, normatively referenced RFCs format the terms differently. Please let us know if any updates are necessary:

   content request / Content Request - RFC 6707 caps

   Entity Property Map - if RFC 9240 goes lc, would need updating
-->

<!-- [rfced] Please review the "Inclusive Language" portion of the online Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let us know if any changes are needed.

For example, please consider whether "man-in-the-middle"  should be updated to "on-path".
-->
  </back>
</rfc>