<?xml version='1.0' encoding='utf-8'?>

<!-- [rfced] v23 was approved. Authors submitted v24 before we even added the doc to our queue.
Please start with v24 but note the diffs in URL https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-24 and ask the ADs for approval as needed. -->

<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.13 -->
<!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-unified-props-new-24" category="std" number="9240" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" tocDepth="3" sortRefs="true" symRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.40.0 -->

  <front>
    <title abbrev="Entity Property Maps">An ALTO Extension: Extension for Application-Layer Traffic Optimization (ALTO): Entity Property Maps</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-alto-unified-props-new-24"/> name="RFC" value="9240"/>
    <author initials="W." surname="Roome" fullname="Wendy Roome">
      <organization abbrev="Nokia Bell Labs">Nokia Bell Labs (Retired)</organization>
      <address>
        <postal>
          <street>124 Burlington Rd</street>
          <city>Murray Hill</city>
          <region>NJ</region>
          <code>07974</code>
          <country>USA</country>
          <country>United States of America</country>
        </postal>
        <phone>+1-908-464-6975</phone>
        <email>wendy@wdroome.com</email>
      </address>
    </author>
    <author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy">
      <organization>Nokia Bell Labs</organization>
      <address>
        <postal>
          <street>Route de Villejust</street>
          <city>NOZAY</city>
          <code>91460</code>
          <country>FRANCE</country>
          <country>France</country>
        </postal>
        <email>Sabine.Randriamasy@nokia-bell-labs.com</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>
          <country>USA</country>
          <region>CT</region>
          <code>06511</code>
          <country>United States of America</country>
        </postal>
        <phone>+1-203-432-6400</phone>
        <email>yry@cs.yale.edu</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.n.zhang@gmail.com</email>
      </address>
    </author>
    <author initials="K." surname="Gao" fullname="Kai Gao">
      <organization>Sichuan University</organization>
      <address>
        <postal>
          <street>No.24 South Section 1, Yihuan Road</street>
          <city>Chengdu</city>
          <code>610000</code>
          <country>China</country>
        </postal>
        <email>kaigao@scu.edu.cn</email>
      </address>
    </author>
    <date year="2022" month="February" day="28"/>
    <area>Networks</area>
    <workgroup>ALTO WG</workgroup> month="July"/>
    <area>tsv</area>
    <workgroup>alto</workgroup>
    <keyword>ALTO</keyword>
    <abstract>
      <t>This document specifies an extension to the base
      Application-Layer Traffic Optimization (ALTO)
	protocol
	Protocol that generalizes the concept of "endpoint properties",
	which were so far have been tied to IP addresses, addresses so far,
	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. Protocol.
	While supporting the endpoints and related endpoint property service Endpoint Property Service defined in RFC7285, RFC 7285,
	the ALTO protocol 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 for specific endpoints to entire entity property maps. These
	extensions introduce additional features allowing that allow 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>
  <middle>

    <section anchor="introduction" numbered="true" toc="default">
      <name>Introduction</name>
	 <t>The ALTO protocol Protocol <xref target="RFC7285" format="default"/> introduces
	 the concept of "properties" attached to "endpoint addresses".
	 It also defines the Endpoint Property Service (EPS) to
	allow ALTO clients to retrieve those properties. While useful, the EPS, EPS as
	defined in <xref target="RFC7285" format="default"/>, format="default"/> has at least three limitations
	that limitations,
	which are further elaborated hereafter.</t> here.</t>
      <t>First, the EPS allows properties to be associated with only with endpoints that
	are identified by individual communication addresses like IPv4 and IPv6
	addresses. It is reasonable to think that collections of endpoints
	<!--, as defined
        identified by CIDRs <xref target="RFC4632" format="default"/> -->
	or Provider-Defined Identifiers (PIDs), (PIDs) may also have properties.
	<!--
	Furthermore, recent ALTO use cases show that properties
   	of entities such as network flows
	<xref target="RFC7011" format="default"/>
	and routing elements <xref target="RFC7921" format="default"/> are also useful.
	Such cases are documented, for example, in <xref target="I-D.gao-alto-fcs" format="default"/>. -->
	Furthermore, recent ALTO use cases show that properties
   	of entities such as abstracted network elements Abstract Network Elements as defined in
   	<xref target="I-D.ietf-alto-path-vector" format="default"/>
     are also useful.
	However, the current EPS is restricted to
	individual endpoints and cannot be applied to those entities.</t>

      <t>Second, the EPS only allows endpoints identified by global communication
addresses. However, an endpoint address may be a local IP address or an
anycast IP address that may not be globally unique. Additionally, an entity
such as a PID may have an identifier that is not globally unique. That is, a the
same PID may be used in multiple network maps, while in each
network map, this PID points to a different set of addresses.
<!--
For
example, PID "mypid10" may be defined in "netmap1" and "netmap2" while in
each network map, "mypid10" covers a different set of addresses.-->
</t>

      <t>Third, in section 11.4 of <xref target="RFC7285" section="11.4" sectionFormat="of" format="default"/>,
      the EPS is only defined as a POST-mode service. ALTO clients must request
the properties for an explicit set of endpoint addresses. By contrast,
<xref target="RFC7285" format="default"/>, in section 11.2.3, section="11.2.3" sectionFormat="of" format="default"/>
defines a GET-mode cost map resource which that returns all available
costs, so an ALTO Client can retrieve a full set of costs once, once and then process cost
lookups without querying the ALTO server.
<xref target="RFC7285" format="default"/> does not define a
similar service for endpoint properties. At first, a map of endpoint
properties might seem impractical, impractical because it could require enumerating the
property value for every possible endpoint.
In particular, the number of endpoint addresses involved by
an ALTO server can be quite large. To avoid enumerating a large number
of endpoint addresses inefficiently, the ALTO server might define
properties for a sufficiently large subset of endpoints and uses then use an aggregation
representation to reference endpoints in order to allow efficient enumeration.
This is particularly true if blocks of
endpoint addresses with a common prefix have the same value
for a property. Entities in other domains may very well allow aggregated
representation and hence be enumerable as well.</t>

<t>To address these three limitations, this document specifies an
      ALTO protocol Protocol extension for defining and retrieving ALTO properties:</t>
      <ul spacing="normal">

        <li>The first limitation is addressed by introducing a generic
concept called ALTO Entity, entity, which generalizes an endpoint and may represent
a PID, a network element, a cell in a cellular network, an abstracted
network element Abstract
Network Element <xref target="I-D.ietf-alto-path-vector" format="default"/>,
or other physical or logical objects involved in a network topology. Each entity is
included in a collection called an ALTO entity domain. Since each ALTO
entity domain includes only one type of entities, entity, each entity domain can be
classified by the type of enclosed entities.</li>
        <li>The second limitation is addressed by using resource-specific
entity domains. A resource-specific entity domain contains entities that
are defined and identified with respect to a given ALTO information
resource, which provides scoping. For example, an entity domain containing
PIDs is identified with respect to the network map in which these PIDs are
defined. Likewise, an entity domain containing local IP addresses may be
defined with respect to a local network map.</li>
        <li>The third limitation is addressed by defining two new types of ALTO
	information resources: Property Map property map (<xref target="prop-map" format="default"/>)
	and Filtered Property Map filtered property map (<xref target="filter-prop-map" format="default"/>).
	The former is a resource that is requested using the HTTP GET method,
	returns the property values for all entities in one or more
	entity domains, and is analogous to a network map or a cost map in
	Section 11.2 of
	<xref target="RFC7285" section="11.2" sectionFormat="of" format="default"/>.
	The latter is a resource that that is requested using the HTTP POST method,
	returns the values for
	sets of properties and entities requested by the client, and is analogous
	to a filtered network map or a filtered cost map.</li>
      </ul>

      <t>The Entity Property Maps entity property maps extension described in this document introduces a
number of features that are summarized in
<xref target="features-introduced-with-epm-extension" format="default"/>,
where <xref target="TableUPFeatures" format="default"/> lists
the features and references the sections in this document that give
their high-level and their normative description.</t> descriptions.</t>

      <t>The protocol extension defined in this document is augmentable. can be augmented. New entity
domain types can be defined without revising the present specification.
Similarly, new cost metrics and new endpoint properties can be
defined in other documents without revising the protocol specification
defined in <xref target="RFC7285" format="default"/>.</t>

      <section anchor="terminology" numbered="true" toc="default">
        <name>Terminology and notation</name> Notation</name>
        <t>This document uses the following terms and abbreviations, abbreviations that will be
further defined in the document. While this document introduces the feature
"entity property map", it will use both the term "property map" and "entity
property map" to refer to this feature.</t>
        <ul
        <dl spacing="normal">
          <li>Transaction: A
          <dt>Transaction:</dt>
          <dd>A request/response exchange between an ALTO client and an ALTO server.</li>
          <li>Client: When server.</dd>

          <dt>Client:</dt>
          <dd>When used with a capital "C", this term refers to an ALTO client.
          Note that expressions "ALTO client", "ALTO Client" Client", and "Client" are equivalent. </li>
          <li>Server: When </dd>

          <dt>Server:</dt>
          <dd>When used with a capital "S", this term refers to an ALTO server.
          Note that expressions "ALTO server", "ALTO Server" Server", and "Server" are equivalent.</li>
          <li>EPS: An equivalent.</dd>

          <dt>EPS:</dt>
          <dd>An abbreviation for Endpoint Property Service.</li>
        </ul> Service.</dd>
        </dl>
      <t>This document uses the semi-formal notation defined in Section 8.2
      of
      <xref target="RFC7285" section="8.2" sectionFormat="of" format="default"/>.</t>
      </section>
    </section>

    <section anchor="requirements-language" numbered="true" toc="default">
      <name>Requirements Language</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"/>
when, and only when, they appear in all capitals, as shown here. When the
words appear in lower case, they are to be interpreted with their natural
language meanings.</t> here.</t>
    </section>

    <section anchor="basic-features-of-the-unified-property-extension" numbered="true" toc="default">
      <name>Basic Features of the Entity Property Map Extension</name>
      <t>This section gives a high-level overview of the basic features involved in
ALTO Entity Property Maps. entity property maps. It assumes the reader is familiar with the ALTO
protocol
Protocol <xref target="RFC7285" format="default"/>. The purpose of this extension is to convey
properties on for objects that extend ALTO Endpoints endpoints and are called ALTO
Entities, or entities for short.</t>
      <t>The features introduced in this section can be used as standalone. However,
in some cases, these features may depend on particular information resources
and need to be defined with respect to them. To this end,
<xref target="advanced-features-of-the-unified-property-extension" format="default"/> introduces
additional features that extend the ones presented in the present this section.
</t>

      <section anchor="con-entity" numbered="true" toc="default">
        <name>Entity</name>
        <t>The concept of an ALTO Entity entity generalizes the concept of an ALTO Endpoint endpoint
defined in Section 2.1 of <xref target="RFC7285" section="2.1" sectionFormat="of" format="default"/>.
An entity is an object that can be an
endpoint defined by its network address, but it can also be an object
that has a defined mapping to a set of one or more network addresses or an
object that is not even related to any network address. Thus, whereas all
endpoints are entities, not all entities are endpoints.</t>
        <!-- Examples of entities -->

<t>Examples of entities are:</t>
        <ul spacing="normal">
          <li>an ALTO endpoint
          that represents an application or a host identified by a communication address
          (e.g., an IPv4 or IPv6 address) in a network,</li>
          <li>a PID, defined in <xref target="RFC7285" format="default"/>, that has a provider defined provider-defined, human-readable
		identifier specified by an ALTO network map, which maps a PID to a set of
		IPv4 and IPv6 addresses,
		</li>
          <li>an Autonomous System (AS), (AS) that has an AS number (ASN) as its identifier
		and maps to a set of IPv4 and IPv6 addresses,
		that
		which is defined in <xref target="I-D.ietf-alto-cdni-request-routing-alto" target="RFC9241" format="default"/>,
		</li>
          <li>a country with a code specified in <xref target="ISO3166-1" format="default"/>, format="default"/>
          to which applications such as CDN content delivery network (CDN) providers associate properties and capabilities,
          that
          which is defined in <xref target="I-D.ietf-alto-cdni-request-routing-alto" target="RFC9241" format="default"/>,
          </li>
          <li>a TCP/UDP TCP or UDP network flow, flow that is identified by a TCP/UDP 5-tuple
          specifying its source and destination addresses and port numbers,
          and the IP protocol, protocol (TCP or UDP),
		</li>
          <li>a routing element, that is as specified in <xref target="RFC7921" format="default"/> and format="default"/>, that is associated with
routing capabilities information,</li> information, or</li>
          <li>an abstract network element,
          that is Abstract Network Element,
          as specified in <xref target="I-D.ietf-alto-path-vector" format="default"/>
          and format="default"/>,
          that represents an abstraction of a network
		part such as a router, one or more links, a network domain domain, or their
		aggregation.</li>
        </ul>
<t>Some of the example entities listed above have already been documented as ALTO entities.
The other examples are provided for illustration as potential entities. </t>
      </section>

      <section anchor="con-entity-domain" numbered="true" toc="default">
        <name>Entity Domain</name>
        <t>An entity domain defines a set of entities of the same semantic type. An
entity domain is characterized by a type and identified by a name.</t>
        <t>In this document, an entity is owned by exactly one entity domain name.
An entity identifier points to exactly one entity. If two entities in two
different entity domains refer to the same physical or logical object, they
are treated as different entities. For example, if an end host has both an IPv4
and an IPv6 address, these two addresses will be treated as two entities,
defined respectively in the "ipv4" and "ipv6" entity domains.</t>

        <section anchor="con-entity-domain-type" numbered="true" toc="default">
          <name>Entity Domain Type</name>
          <t>The type of an entity domain type defines the semantics of a the type of entity.
   entity found in an entity domain.
	Entity domain types can be defined in different documents. For example: the
	present document defines entity domain types "ipv4", "ipv6" "ipv4" and "pid" "ipv6" in <xref target="inet-addr-domain" format="default"/>
        and "pid"
	in <xref target="pid-domain" format="default"/>.
        The entity domain type
        "ane", that which defines Abstract Network Elements (ANEs), is introduced in
        <xref target="I-D.ietf-alto-path-vector" format="default"/>.
	The "countrycode" entity domain type that defines country
	codes is introduced in <xref target="I-D.ietf-alto-cdni-request-routing-alto" target="RFC9241" format="default"/>. An entity
	domain type MUST <bcp14>MUST</bcp14> be registered at the with IANA, as specified in
	<xref target="dom-reg-process" format="default"/>.</t>
        </section>

        <section anchor="con-entity-domain-name" numbered="true" toc="default">
          <name>Entity Domain Name</name>
          <t>
		In this document, the identifier of an entity domain is mostly called "entity domain name".
		The identifier of an entity domain is defined in the scope of scoped to an ALTO server.
		An entity domain identifier can sometimes be identical to the identifier
		of its relevant entity domain type.
                This is the case when the entities of a domain have an
                identifier that points to the same object throughout all the
                information resources of the Server that provide are providing entity properties
                for this domain.  For
		example, a domain of type "ipv4" containing entities that are identified by a public
		IPv4 address can be named "ipv4" because its entities are uniquely identified
		by all the Server resources.</t>

          <t>In some cases, the name of an entity domain cannot be
           simply its entity domain type.
		Indeed, for some domain types, entities are defined relative to a given
		information resource. This is the case for entities of domain type "pid". A
		PID is defined relative to a network map. For example, an entity "mypid10" of
		domain type "pid" may be defined in a given network map and be undefined in
		other network maps. Or The entity "mypid10" may even be defined in two different network
		maps
		maps, and map, it may map in each of these network maps, maps to a different set of endpoint
		addresses. In this case, naming an entity domain only by its type "pid" does
		not guarantee that its set of entities is owned by exactly one entity domain.</t>
          <t><xref
          <t>Sections <xref target="rsed-name" format="default"/> format="counter"/> and
          <xref target="domain-names" format="default"/> format="counter"/>
          describe how a domain is uniquely identified, identified across the ALTO
		server,
		server by a name that associates the domain type and the related information
		resource.</t>
        </section>
      </section>

      <section anchor="con-property" numbered="true" toc="default">
        <name>Entity Property Type</name>
        <t>An entity property defines a property of an entity. This is similar to the
endpoint property defined in Section 7.1 of <xref target="RFC7285" section="7.1" sectionFormat="of" format="default"/>. An entity property
can convey either network-aware or network-agnostic information. Similar to
an entity domain, an entity property is characterized by a type and
identified by a name. An entity property type MUST <bcp14>MUST</bcp14> be registered at the with
IANA, as specified in <xref target="IANAEntityProp" format="default"/>.</t>
        <t>Below are listed some examples with real and fictitious entity domain and property
names:</t>
        <ul spacing="normal">
          <li>an entity in the "ipv4" domain type may have a property whose value is an
Autonomous System (AS) number indicating the AS to which this IPv4 address
belongs and another property named "countrycode" indicating a country code mapping
to this address,</li>
          <li>an entity identified by its country code in the entity domain type
"countrycode", defined in <xref target="I-D.ietf-alto-cdni-request-routing-alto" format="default"/> target="RFC9241" format="default"/>, may
have a property indicating what delivery protocol is used by a CDN,</li> CDN, or</li>
          <li>an entity in the "netmap1.pid" domain may have a property that indicates
the central geographical location of the endpoints it includes.</li>
        </ul>
        <t>It should be noted that some identifiers may be used for both an entity
domain type and a property type. For example:</t>
        <ul spacing="normal">
          <li>the identifier "countrycode" may point to both the entity domain type
"countrycode" and the fictitious property type "countrycode".</li>
          <li>the identifier "pid" may point to both the entity domain type "pid" and the
property type "pid".</li>
        </ul>
        <t>Likewise, the same identifier may point to both a domain name and a property
name. For example: the identifier "netmap10.pid" may point to either the
domain defined by the PIDs of network map "netmap10" or to a property that
returns, for an entity defined by its IPv4 address, the PID of netmap10 "netmap10" that
contains this entity. Such cases will be are further explained in
<xref target="advanced-features-of-the-unified-property-extension" format="default"/>.</t>
      </section>

      <section anchor="con-propmap" numbered="true" toc="default">
        <name>New Information Resource and Media Type: ALTO Property Map</name>
        <t>This document introduces a new ALTO information resource named Property Map. property map.
An ALTO property map provides a set of properties on for one or more sets of
entities. A property may apply to different entity domain types and names.
For example, an ALTO property map may define the "ASN" property for both
"ipv4" and "ipv6" entity domains.</t>
        <t>The present extension also introduces a new media type.</t>
        <t>This document uses the same definition of an information resource as Section
9.1 of
<xref target="RFC7285" section="9.1" sectionFormat="of" format="default"/>. ALTO uses media types to uniquely indicate the data
format used to encode the content to be transmitted between an ALTO server
and an ALTO client in the HTTP entity body. In the present case, an ALTO
property map resource is
<!-- represented by a JSON object of type InfoResourcePropertyMap and -->
defined by the media type "application/alto-propmap+json".</t>
        <t>A Property Map property map can be queried as a GET-mode resource, thus conveying all
properties on for all entities indicated in its capabilities. It can also be
queried as a POST-mode resource, thus conveying a selection of properties on for
a selection of entities.</t>
      </section>
    </section>

    <section anchor="advanced-features-of-the-unified-property-extension" numbered="true" toc="default">
      <name>Advanced Features of the Entity Property Map Extension</name>
      <t>This section gives a high-level overview of the advanced features
   involved in ALTO Entity Property Maps. entity property maps. Most of these features are
defined to
extend the ones features defined in
<xref target="basic-features-of-the-unified-property-extension" format="default"/>.</t>

      <section anchor="entity-identifier-and-entity-domain" numbered="true" toc="default">
        <name>Entity Identifier and Entity Domain Name</name>
        <t>In <xref target="RFC7285" format="default"/>, an endpoint has an identifier that is explicitly associated
with the "ipv4" or "ipv6" address domain. Examples are "ipv4:192.0.2.14" and
"ipv6:2001:db8::12".</t>
	<t>In this document, example IPv4 and IPv6 addresses and prefixes are taken
	from the address ranges reserved for documentation by
	<xref target="RFC5737" format="default"/> and
	<xref target="RFC3849" format="default"/>.
	</t>
        <t>In this document, an entity must be owned by exactly one entity
   domain name name, and an entity identifier must point to exactly one
   entity.  To ensure this, an entity identifier is explicitly attached
   to the name of its entity domain domain, and an entity domain type
   characterizes the semantics and identifier format of its entities.
</t>
        <t>The encoding format of an entity identifier is further specified in
<xref target="entity-addrs" format="default"/> of this document.</t>
        <t>For instance:</t>
        <ul spacing="normal">
          <li>if an entity is an endpoint with IPv4 address
"192.0.2.14", its identifier is associated with entity domain name "ipv4" and is
"ipv4:192.0.2.14",</li>
"ipv4:192.0.2.14";</li>
          <li>if an entity is a PID named "mypid10" in network map resource "netmap2",
its identifier is associated with entity domain name "netmap2.pid" and is
"netmap2.pid:mypid10".</li>
        </ul>
      </section>

      <section anchor="rsed-name" numbered="true" toc="default">
        <name>Resource-Specific Entity Domain Name</name>
        <t>Some entities are defined and identified uniquely and globally
        in the context of an ALTO server. This is the
case
case, for instance instance, when entities are endpoints that are identified by a
reachable IPv4 or IPv6 address. The entity domain for such entities can be
globally defined and named "ipv4" or "ipv6". Those entity domains are called
resource-agnostic entity domains in this document, as they are not associated
with any specific ALTO information resources.</t>
        <t>Some other entities and entity types are only defined relative to a given
information resource. This is the case for entities of domain type "pid",
that
which can only be understood with respect to the network map where they are
defined. For example, a PID named "mypid10" may be defined to represent a set
S1 of IP addresses in a network map resource named "netmap1". Another network
map "netmap2" may use the same name "mypid10" and define it to represent
another set S2 of IP addresses. The identifier "pid:mypid10" may thus point
to different objects because the information on the originating information
resource is lost.</t>
        <t>To solve this ambiguity, the present extension introduces the concept of
resources-specific
resource-specific entity domain. This concept applies to domain types where
entities are defined relative to a given information resource. It can also
apply to entity domains that are defined locally, such as local networks of
objects identified with a local IPv4 address.</t>
        <t>In such cases, an entity domain type is explicitly associated with an
identifier of the information resource where these entities are defined. Such
an information resource is referred to as the "specific information
resource". Using a resource-aware entity domain name, an ALTO property map
can unambiguously identify distinct entity domains of the same type, on which
entity properties may be queried. Examples of resource-specific entity domain
names may look like: like "netmap1.pid" or "netmap2.pid". Thus, a name association
such as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" allows to distinguish distinguishes
the two abovementioned PIDs that are both named "mypid10" but in two
different resources, "netmap1" and "netmap2".</t>
        <t>An information resource is defined in the scope of an ALTO Server and so is
an entity domain name. The format of a resource-specific entity domain name
is further specified in <xref target="domain-names" format="default"/>.</t>
      </section>

      <section anchor="rsep" numbered="true" toc="default">
        <name>Resource-Specific Entity Property Value</name>
        <t>Like entity domains, some types of properties are defined relative to an
information resource. That is, an entity may have a property of a given type, type
whose values are associated to with different information resources.</t>

        <t>For example, suppose entity "192.0.2.34" defined in the "ipv4" domain has a
property of type "pid", "pid" whose value is the PID to which address "192.0.2.34"
is attached in a network map. The mapping of network addresses to PIDs is
specific to a network map and probably different from one network map
resource to another one. Thus, if a property "pid" is defined for entity
"192.0.2.34" in two different network maps "netmap1" and "netmap2", the value
for this property can be a different value in "netmap1" and
"netmap2".</t>

        <t>To support information resource dependent information-resource-dependent property values, this document uses
the same approach as in Section 10.8.1 of <xref target="RFC7285" format="default"/> entitled section="10.8.1" sectionFormat="bare">
"Resource-Specific Endpoint Properties". Properties"</xref> of <xref target="RFC7285" format="default"/>. When a property value depends on a
given information resource, the name of this property MUST <bcp14>MUST</bcp14> be explicitly
associated with the information resource that defines it.</t>
        <t>For example, the property "pid" queried on entity "ipv4:192.0.2.34" and
defined in both "netmap1" and "netmap2", "netmap2" can be named "netmap1.pid" and
"netmap2.pid". This allows a Client to get a property of the same type but
defined in different information resources with a single query.
Specifications on for the property name format are provided in <xref target="def-property" format="default"/>.</t>
      </section>

 	<section anchor="con-hni" numbered="true" toc="default">
        <name>Entity Hierarchy and Property Inheritance</name>
        <t>For some domain types, there is an underlying structure that allows entities to
	efficiently
	be efficiently grouped into a set and be defined by the identifier of this set.
	This is the case for domain types "ipv4" and "ipv6",
	where individual Internet addresses can be grouped in blocks. When the same
	property value applies to a whole set, a Server can define a property for the
	identifier of this set instead of enumerating all the entities and their
	properties. This allows a substantial reduction of transmission payload both
	for the Server and the Client. For example, all the entities included in the
	set defined by the address block "ipv6:2001:db8::1/64" share the same
	properties and values defined for this block.</t>
        <t>Additionally, entity sets sometimes are related by inclusion, hierarchy hierarchy, or
	other relations. This allows defining inheritance rules for entity properties
	that propagate properties among related entity sets. The Server and the
	Client can use these inheritance rules for further payload savings. Entity
	hierarchy and property inheritance rules are specified in the documents that
	define the applicable domain types. The present document defines these rules
	for the "ipv4" and "ipv6" domain types.</t>
        <t>This document introduces, for
        <t>For applicable domain types, "Entity Property
	Inheritance rules", this document introduces entity property
	inheritance rules with the following concepts: Entity Hierarchy, Property
	Inheritance entity hierarchy, property
	inheritance, and Property Value Unicity. property value unicity. A detailed specification of entity
	hierarchy and property inheritance rules is provided in
	<xref target="def-hierarchy-and-inheritance" format="default"/>.</t>

        <section anchor="entity-hierarchy" numbered="true" toc="default">
          <name>Entity Hierarchy</name>
          <t>An entity domain may allow using the use of a single identifier to identify a set of
		related individual entities. For example, a CIDR Classless Inter-Domain Routing
                (CIDR) block can be used to identify a set
		of IPv4 or IPv6 entities. A CIDR block is called a hierarchical entity
		identifier, as it can reflect inclusion relations among entity sets.
		That is, in an entity hierarchy, "supersets" are defined at upper levels
		and include "subsets" defined at lower levels." levels.
		For example, the CIDR "ipv4:192.0.1.0/24" includes all the individual IPv4
		entities identified by the CIDR "ipv4:192.0.1.0/26".
		This document will sometimes use the term "hierarchical address"
		to refer to a hierarchical entity identifier. </t>
        </section>

	<section anchor="property-inheritance" numbered="true" toc="default">
	<name>Property Inheritance</name>

     <t>A property may be defined for a hierarchical entity identifier, while it may
	be undefined for individual entities covered by this identifier. In this
	case, these individual entities inherit the property value defined for the
	identifier that covers them. For example, suppose a property map defines a
	property P for which it assigns value V1 only for the hierarchical entity
	identifier "ipv4:192.0.1.0/24" but not for individual entities in this block.
	Suppose also that inheritance rules are specified for CIDR blocks in the
	"ipv4" domain type. When receiving this property map, a Client can infer that
	entity "ipv4:192.0.1.1" inherits the property value V1 of block
	"ipv4:192.0.1.0/24" because the address "ipv4:192.0.1.1" is included in the
	CIDR block "ipv4:192.0.1.0/24".</t>
	          <t>Property value inheritance rules also apply among entity sets. A property map
	may define values for an entity set belonging to a hierarchy but not for
	"subsets" that are covered by this set identifier. In this case, inheritance
	rules must specify how entities in "subsets" inherit property values from
	their "superset".
	For instance, suppose a property P is defined only for the entity set defined
	by address block "ipv4:192.0.1.0/24". We know that entity set "ipv4:192.0.1.0/30"
	is included in "ipv4:192.0.1.0/24". Therefore, the entities of "ipv4:192.0.1.0/30"
	may inherit the value of property P from set "ipv4:192.0.1.0/24", "ipv4:192.0.1.0/24"
	if an inheritance rule from "ipv4" CIDR blocks to included "ipv4" CIDR blocks, blocks is specified.</t>
   </section>

        <section anchor="property-value-unicity" numbered="true" toc="default">
          <name>Property Value Unicity</name>
          <t>The inheritance rules must ensure that an entity belonging to a hierarchical
	set of entities inherits no more than one property value, for the sake of
	consistency. Indeed, a property map may define a property on for a hierarchy of
	entity sets that inherit inherits property values from one or more supersets (located at upper
	levels). On the other hand, a property value, value defined on for a subset (located at a lower
	level) may be different from the value defined on for a superset. In such a case,
	subsets may potentially end up with different property values. This may be
	the case for address blocs blocks with increasing prefix length, on which a property
	value gets becomes increasingly accurate and thus may differ. For example, a
	fictitious property such as "geo-location" or "average transfer volume" may
	be defined at a progressively finer grain for lower level lower-level subsets of entities, entities defined with
	progressively longer CIDR prefixes. It seems more interesting to have
	property values of progressively higher accuracy. A unicity rule, rule applied to
	the entity domain type must specify an arbitration rule among the different
	property values for an entity. An example illustrating the need for such
	rules is provided in <xref target="inet-inheritance" format="default"/>.</t>
        </section>
      </section>

      <section anchor="applicable-entity-domains-and-properties-in-the-property-map-capabilities" numbered="true" toc="default">
        <name>Supported Properties on for Entity Domains in Property Map Capabilities</name>
        <t>A property type is not necessarily applicable to any domain type, or an ALTO
	Server may choose not to provide a property on for all applicable domains. For
	instance, a property type reflecting link bandwidth is likely not defined on for
	entities of a domain of type "countrycode". Therefore, an ALTO server
	providing Property Maps property maps needs to specify the properties that can be queried
	on the different entity domains it supports.</t>
        <t>This document explains how the Information Resources Resource Directory (IRD)
	capabilities of a Property Map property map resource unambiguously expose what which properties
	a Client can query on a given entity domain:</t>
        <ul spacing="normal">
          <li>a field named "mappings" lists the names of the entity domains supported by
	the Property Map,</li> property map, and</li>
          <li>for each listed entity domain, a list of the names of the applicable
	properties is provided.</li>
        </ul>
        <t>An example is provided in <xref target="ird-example" format="default"/>.
        The "mappings" field associates
	entity domains and properties that can be resource-agnostic or
	resource-specific. This allows a Client to formulate compact and unambiguous
	entity property queries, possibly relating to one or more information
	resources. In particular:</t>
        <ul spacing="normal">
          <li>it prevents a Client from querying a property on for entity domains on for which it is not
		defined,</li>
		defined;</li>
          <li>it allows a Client to query, for an entity E, values for a property P that
		are defined in several information resources,</li> resources; and</li>
          <li>it allows a Client to query a property P on entities that are defined in
		several information resources.</li>
        </ul>
        <t>Further details are provided in <xref target="FullPropMapCapabilities" format="default"/>.</t>
      </section>

      <section anchor="def-ir" numbered="true" toc="default">
        <name>Defining Information Resource for Resource-Specific Entity Domains</name>
        <t>A Client willing to query entity properties on entities belonging to a domain needs
to know how to retrieve these entities. To this end, the Client can look up
the "mappings" field exposed in IRD capabilities of a property map, map; see
<xref target="applicable-entity-domains-and-properties-in-the-property-map-capabilities" format="default"/>.
This field, in its keys, exposes all the entity domains supported by the
property map. The syntax of the entity domain identifier specified in
<xref target="domain-names" format="default"/> allows the client to infer whether the entity domain is
resource-specific or not. The Client can extract, if applicable, the
identifier of the specific resource, query the resource resource, and retrieve the
entities. For example:
</t>
        <ul spacing="normal">
          <li>an entity domain named "netmap1.ipv4" includes the IPv4 addresses that
appear in the "ipv4" field of the endpoint address group of each PID in the
network map "netmap1", "netmap1" and that have no meaning outside "netmap1"
because, for instance, these are local addresses not reachable outside some private network,</li> network;</li>
          <li>an entity domain named "netmap1.pid" includes the PIDs listed in network
map "netmap1".</li> "netmap1"; and</li>
          <li>an entity domain named "ipv4" is resource-agnostic and covers all the
reachable IPv4 addresses.</li>
        </ul>

        <t>Besides, it is not possible to prevent a Server from mistakenly exposing
        inappropriate associations of information resources and entity domain types.
        To prevent failures due to invalid queries, it is necessary to inform the Client
        about
        which associations are allowed.
		An informed Client will just ignore inappropriate associations exposed by a
		Server and avoid error-prone transactions with the Server.
		</t>
        <t>For example, the association "costmap3.pid" is not allowed for the following
reason: although a cost map exposes PID identifiers, it does not define the
set of addresses included in this PID. Neither does a cost map list all the
PIDs on which properties can be queried, queried because a cost map only exposes PID
pairs on which a queried cost type is defined. Therefore, the resource
"costmap3" does not enable a Client to extract information on the existing
PID entities or on the addresses they contain.</t>
        <t>Instead, the cost map uses a network map, map where all the PIDs used in a cost
map are defined together with the addresses contained by the PIDs. This
network map is qualified in this document as the Defining Information
Resource defining information
resource for the entity domain of type "pid" "pid", and this concept is explained in
<xref target="defining-information-resource-and-media-type" format="default"/>.</t>

	<section anchor="defining-information-resource-and-media-type" numbered="true" toc="default">
     <name>Defining Information Resource and its Its Media Type</name>
     <t>For the reasons explained in <xref target="def-ir" format="default"/>,
     this document introduces the concept of "Defining Information Resource
     and its Media Type".</t>

     <t>A defining information resource for an entity domain D is the information
	resource where entities of D are defined. That is, all the information on the
	entities of D can be retrieved in this resource.

	A defining information resource is defined for resource-specific entity domains.
	It does not exist for entity domains that are not resource-specific such as
	"ipv4" or "ipv6". Neither does it exist for entity domains that are covering
	entity identifiers already defined in other standardization documents,
	at it
	as is the case for country code identifiers standardized in [ISO3166-1] <xref target="ISO3166-1" format="default"/>
	or AS numbers allocated by the IANA.

	This is useful for entity domain types that are by
	essence domain-specific, such as the "pid" domain type. type "pid". It is also
	useful for resource-specific entity domains constructed from
	resource-agnostic domain types, such as network map specific network-map-specific domains of local
	IPv4 addresses.</t>

     <t>The defining information resource of a resource-specific entity domain D,
     when it exists, is unique and has the following specificities:</t> characteristics:</t>

          <ul spacing="normal">
            <li>it has an entry in the IRD,</li> IRD;</li>
            <li>it defines the entities of D,</li> D;</li>
            <li>it does not use another information resource that defines these entities,</li> entities;</li>
            <li>it defines and exposes entity identifiers that are all persistent,</li> persistent; and</li>
            <li>its media type is equal to the one that is specified for the
			defining information resource of an entity domain type.</li>
          </ul>
          <t>A fundamental characteristic of a defining information resource is its media type.
	There is a unique association between an entity domain type and the media
	type of its defining information resource. When an entity domain type allows associations
	with defining information resources, the media type of the potential defining information
	resource MUST <bcp14>MUST</bcp14> be specified:</t>
	<ul spacing="normal">
	 <li>in the document that defines this entity domain type,</li> type, and</li>
	 <li>in the IANA ALTO Entity Domain Type Registry and related information.</li>
	</ul>
<!-- commented text
If an entity domain type can be
resource-specific, the document that defines this entity domain type must
specify the association between the entity domain type and the media type of
the potential defining information resource in the "ALTO Entity Domain Type
Registry" (<xref target="IANADomain" format="default"/>) and request the addition to the IANA.
--> Types" IANA registry.</li>
	</ul>
          <t>When the Client wants to use a resource-specific entity domain, it needs to
be cognizant of the media-type media type of its defining information resource. If the
Server exposes a resource-specific entity domain with a
non-compliant
noncompliant media type for the defining resource, the Client MUST <bcp14>MUST</bcp14> ignore the
entities from that entity domain to avoid errors.</t>
          <!--
The same holds for property types whose values are defined relative to an
information resource. Similarly to resource specific entity domains, the
Client needs to be cognizant of appropriate associations of information
resource and property types. Therefore, when specifying and registering a
property type whose values are resource-specific, it is necessary to specify
the media type of its defining information resource. For example: the
defining information resource for property type "pid" is a network map; the
defining information resource for property type "cdnifci-capability", defined in
{{I-D.ietf-alto-cdni-request-routing-alto}} is a "cdnifci-map" information
resource, defined in that same document.
-->
</section>

	<!-- Examples of Defining Information Resources and Their Media Types -->

	<section anchor="example-specific-ir-mediatype" numbered="true" toc="default">
          <name>Examples of Defining Information Resources and Their Media Type</name> Types</name>
          <t>Here are examples of defining information resource types and their media
types associated to with different entity domain types:</t>

          <ul spacing="normal">
            <li>For entity domain type "pid": "pid", the media type of the specific resource is
"application/alto-networkmap+json",
"application/alto-networkmap+json" because PIDs are defined in network map
resources.</li>

            <li>For entity domain types "ipv4" and "ipv6": "ipv6", the media type of the specific
resource is "application/alto-networkmap+json", "application/alto-networkmap+json" because IPv4 and IPv6
addresses covered by the Server are defined in network map resources.</li>

            <li>For entities of domain type "ane": "ane"; <xref target="I-D.ietf-alto-path-vector" format="default"/> defines
entities named "ANE", where ANE stands for Abstracted Abstract Network Element, and
the entity domain type "ane". An ANE may have a persistent identifier, say,
"entity-4", that is provided by the Server as a value of the
"persistent-entity-id" property of this ANE. Further properties may then be
queried on an ANE by using its persistent entity ID. identifier. These properties are
available from a persistent property map, map that defines properties on for a
specific "ane" domain. Together with the persistent identifier, the Server
also provides the property map resource identifier where the "ane" domain
containing "entity-4" is defined. The definition of the "ane" entity domain
containing "entity-4" is thus specific to the property map. Therefore, for
entities of domain type "ane" that have a persistent identifier, the media
type of the defining information resource is
"application/alto-propmap+json".</li>

            <li>Last, the entity domain types "asn" and "countrycode" defined in
<xref target="I-D.ietf-alto-cdni-request-routing-alto" target="RFC9241" format="default"/> do not have a defining
information resource. Indeed, the entity identifiers in these two entity
domain types are already standardized in documents that the Client can use.</li>
          </ul>
        </section>
      </section>

      <section anchor="def-ir-for-irsp" numbered="true" toc="default">
        <name>Defining Information Resource Resources for Resource-Specific Property Values</name>
        <t>As explained in <xref target="rsep" format="default"/>, a property type may
take values that are resource-specific. This is the case for property type
"pid", whose values are by essence defined relative to a specific network
map. That is, the PID value returned for an IPv4 address is specific to the network
map defining this PID and may differ from one network map to another one.</t>
        <!--
Property values may be specific to different types of information resources.
For example: the value for property "pid" is specific to a network map. The
value for property type "cdnifci-capab" is specific to the information
resource "cdnifci-map", defined in
{{I-D.ietf-alto-cdni-request-routing-alto}}, while network maps do not define
property "fci-capability" for IPv4 addresses and a cdnifci-map does not
define "pid" values for IPv4 addresses.
-->
<t>Another example is provided in
<xref target="I-D.ietf-alto-cdni-request-routing-alto" format="default"/>
that target="RFC9241" format="default"/>,
which defines property type "cdni-capabilities". The value of this property is
specific to a CDNI advertisement Content Delivery Network Interconnection (CDNI) Advertisement resource, that which provides a list of CDNI
capabilities. The property is provided for entity domain types "ipv4",
"ipv6", "asn" "asn", and "countrycode". A However, a CDNI Advertisement resource does however
not define PID values for IPv4 addresses addresses, while a network map does not define
CDNI capabilities for IPv4 addresses.</t>
        <!--
Thus, similarly to resource specific entity domains, the Client needs to be
cognizant of appropriate associations of information resource and property
types.
-->
<t>Similar to resource-specific entity domains, the Client needs to be
cognizant of appropriate associations of information resource and property
types. Therefore, when specifying and registering a property type whose
values are resource-specific, the media type of its defining information
resource needs to be specified. For example:</t>
        <!--
### Examples of defining resources media-types for properties {#example-specific-ir-mediatype-prop}
-->

<!--
Here are some examples of specific information resources types associated to
entity property types and their media type.
-->

<ul spacing="normal">
          <li>The media type of the defining information resource for property type "pid"
is "application/alto-networkmap+json".</li>
          <li>The media type of the defining information resource for property type
"cdni-capabilities" defined in <xref target="I-D.ietf-alto-cdni-request-routing-alto" target="RFC9241" format="default"/>
is "application/alto-cdni+json".</li>
        </ul>
      </section>
    </section>

    <section anchor="protocol-specification-basic-data-types" numbered="true" toc="default">
      <name>Protocol Specification: Basic Data Types</name>

      <section anchor="def-domain" numbered="true" toc="default">
        <name>Entity Domain</name>

	<section anchor="domain-types" numbered="true" toc="default">
     <name>Entity Domain Type</name>
     <t>An entity domain has a type, which is uniquely identified by a string that
	MUST
	<bcp14>MUST</bcp14> be no more than 64 characters, and MUST NOT <bcp14>MUST NOT</bcp14> contain characters other
	than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and
	U+0061-U+007A), the hyphen hyphen-minus ('-', U+002D), the colon (':', U+003A),
	or the low line ('_', U+005F).</t>

	<t>The usage of colon (':', U+003A) MUST <bcp14>MUST</bcp14> obey the rules below:</t>
	 <ul spacing="normal">
	 <li>The colon (':', U+003A) character MUST NOT <bcp14>MUST NOT</bcp14> appear more than once,</li> once;</li>
	 <li>The colon character MUST NOT <bcp14>MUST NOT</bcp14> be used unless within the string "priv:",</li> "priv:";</li>
	 <li>The string "priv:" MUST NOT <bcp14>MUST NOT</bcp14> be used unless it starts the string that identifies an entity domain type,</li> type; and</li>
	 <li>For an entity domain type identifier with the "priv:" prefix , prefix,
	 	an additional string (e.g., company identifier or random string) MUST <bcp14>MUST</bcp14> follow "priv:", "priv:"
	 	to reduce potential collisions.</li>
	 </ul>

     <t>For example, the strings "ipv4", "ipv6", "pid" "pid", and "priv:example-test-edt",
     are valid entity domain types. "ipv4.anycast", "pid.local" "pid.local", and "priv:" are invalid.</t>

     <t>Although “_”, “-“, “__--" "_", "-", "__--" are valid entity domain types,
	it is desirable to add characters characters, such as alphanumeric ones,
	for better intelligibility. </t>

     <t>The type EntityDomainType is used in this document to denote a JSON string
meeting the preceding requirements.</t>

	<t>An entity domain type defines the semantics of a type of entity,
   independently of any specifying resource. All entity
   domain types that are not prefixed with "priv:" MUST <bcp14>MUST</bcp14> be registered with the IANA, IANA
   in the "ALTO Entity Domain Type Registry", Types" registry, defined in <xref target="IANADomain" format="default"/>,
   following the procedure specified in <xref target="dom-reg-process" format="default"/>
   of this document.
   The format of the entity identifiers (see <xref target="entity-addrs" format="default"/>)
   in that entity domain type, as well as any hierarchical or inheritance rules
   (see <xref target="def-hierarchy-and-inheritance" format="default"/>) for
   those entities, MUST <bcp14>MUST</bcp14> be specified in the IANA registration.</t>

   <t>Entity domain type identifiers prefixed with "priv:" are reserved for Private Use
   (see <xref target="RFC8126" format="default"/>) without a need to register with IANA.
   The definition of a private use private-use entity domain type MUST <bcp14>MUST</bcp14> apply the same way in all
   property maps of an IRD where it is present.
   </t>

     </section>

        <section anchor="domain-names" numbered="true" toc="default">
          <name>Entity Domain Name</name>
          <t>As discussed in <xref target="con-entity-domain" format="default"/>,
          an entity domain is characterized by a type and identified by a name.</t>

          <t>This document distinguishes three categories of entity domains:
		resource-specific entity domains, resource-agnostic entity domains domains, and
		self-defined entity domains. Their entity domain names are constructed as
		specified in the following sub-sections.</t> subsections.</t>
          <t>Each entity domain is identified by a unique entity domain name.
          Borrowing the symbol "::=" from the Backus-Naur Form notation
          <xref target="RFC5511" format="default"/>,
          the format of an entity domain name is defined as follows:</t>

          <artwork name="" type="" align="left" alt=""><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType
		]]></artwork>
]]></sourcecode>

          <t>The presence and construction of the component</t>
           <artwork name="" type="" align="left" alt=""><![CDATA[
           <sourcecode type="rbnf"><![CDATA[
                "[ [ ResourceID ] '.' ]"
		]]></artwork>
]]></sourcecode>
          <t>depends on the category of entity domain.</t>

		<!-- commented text <t>The component</t> -->
 		<!-- commented text <artwork name="" type="" align="left" alt=""><![CDATA[
    		"['priv:']"
		]]></artwork> -->
          <!-- commented text  <t>is present when the entity domain type is defined for Private Use.
          </t> -->

          <t>Note that the '.' separator is not allowed in EntityDomainType EntityDomainType, and hence
		there is no ambiguity on whether an entity domain name refers to a
		resource-agnostic entity domain or a resource-specific entity domain.</t>
          <t>Note also that Section 10.1 of <xref target="RFC7285" section="10.1" sectionFormat="of" format="default"/>
          specifies the format of the PID
		name
		name, which is the format of the resource ID identifier including the following
		specification: "the
		specification:</t>
          <blockquote>The '.' separator is reserved for future use and MUST NOT <bcp14>MUST NOT</bcp14> be
		used unless specifically indicated in this document, or an extension
		document". The
		document.</blockquote>
          <t>The present extension keeps the format specification of
		<xref target="RFC7285" format="default"/>, hence the '.' separator MUST NOT <bcp14>MUST NOT</bcp14>
		be used in an information resource ID.</t> identifier.</t>

     <section anchor="resource-specific-ED" numbered="true" toc="default">
            <name>Resource-specific
            <name>Resource-Specific Entity Domain</name>
            <t>A resource-specific entity domain is identified by an entity domain name
constructed as follows. It MUST <bcp14>MUST</bcp14> start with a resource ID identifier using the ResourceID
type defined in Section 10.2 of <xref target="RFC7285" section="10.2" sectionFormat="of" format="default"/>, followed by the '.' separator
(U+002E), followed by a string of the type EntityDomainType specified in
<xref target="domain-types" format="default"/>.</t>
            <t>For example, if an ALTO server provides two network maps "netmap-1" and
"netmap-2", these network maps can define two resource-specific domains of
type "pid", respectively identified by "netmap-1.pid" and "netmap-2.pid".</t>
          </section>
          <section anchor="resource-agnostic-ED" numbered="true" toc="default">
            <name>Resource-agnostic
            <name>Resource-Agnostic Entity Domain</name>
            <t>A resource-agnostic entity domain contains entities that are identified
independently of any information resource. The identifier of a
resource-agnostic entity domain is simply the identifier of its entity domain
type. For example, "ipv4" and "ipv6" identify the two resource-agnostic
Internet address entity domains defined in <xref target="inet-addr-domain" format="default"/>.</t>
          </section>

          <section anchor="self-defined-ED" numbered="true" toc="default">
            <name>Self-defined
            <name>Self-Defined Entity Domain</name>
            <t>A property map can define properties on for entities that are specific to a
unique information resource, which is the property map itself. This may be
the case when an ALTO Server provides properties on for a set of entities that
are defined only in this property map, are not relevant to another one one, and do
not depend on another specific resource.</t>
            <t>For example: a specialised specialized property map may define a domain of type "ane",
defined in <xref target="I-D.ietf-alto-path-vector" format="default"/>, that contains a set of ANEs
representing data centers, centers that each have a persistent identifier and are
relevant only to this property map.</t>
            <t>In this case, the entity domain is qualified as "self-defined". The
identifier of a self-defined entity domain can be of the format:</t>
            <artwork name="" type="" align="left" alt=""><![CDATA[
            <sourcecode type="rbnf"><![CDATA[
    EntityDomainName ::= '.' EntityDomainType
]]></artwork>
]]></sourcecode>
            <t>where '.' indicates that the entity domain only exists within the property
map resource using it.</t>
            <t>A self-defined entity domain can be viewed as a particular case of
resource-specific entity domain, where the specific resource is the current
resource that uses this entity domain. In that case, for the sake of
simplification, the component "ResourceID" MUST ResourceID <bcp14>MUST</bcp14> be omitted in its entity
domain name.</t>
          </section>
        </section>
   <section anchor="entity-addrs" numbered="true" toc="default">
     <name>Entity Identifier</name>
          <!-- FIXME: The entity identifier is not global unique. -->

	<t>Entities in an entity domain are identified by entity identifiers (EntityID) of
	the following format:
	</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          <sourcecode type="rbnf"><![CDATA[
EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID
]]></artwork>
]]></sourcecode>
     <t>Examples from the Internet address entity domains include individual IP
	addresses such as "net1.ipv4:192.0.2.14" and "net1.ipv6:2001:db8::12", as well
	as address blocks such as "net1.ipv4:192.0.2.0/26" and
	"net1.ipv6:2001:db8::/48".</t>

     <t>The format of the second part of an entity identifier,
   	DomainTypeSpecificEntityID, depends on the entity domain type, type and MUST <bcp14>MUST</bcp14> be
   	specified when defining a new entity domain type and registering it with the
   	IANA.
	Identifiers MAY <bcp14>MAY</bcp14> be hierarchical, and properties
	MAY
	<bcp14>MAY</bcp14> be inherited based on that hierarchy. The rules defining any hierarchy or
	inheritance MUST <bcp14>MUST</bcp14> be defined when the entity domain type is registered.
	</t>
          <t>The type EntityID is used in this document to denote a JSON string
representing an entity identifier in this format.</t>
          <t>Note that two entity identifiers with different different, valid textual representations
may refer to the same entity, for a given entity domain. For example, the
strings "net1.ipv6:2001:db8::1" and "net1.ipv6:2001:db8:0:0:0:0:0:1" refer to
the same entity in the "ipv6" entity domain. Such equivalences should be
established by the object represented by DomainTypeSpecificEntityID, for DomainTypeSpecificEntityID. For
example, <xref target="RFC5952" format="default"/> establishes equivalence for IPv6 addresses, while
<xref target="RFC4632" format="default"/> does so for IPv4 addresses.</t>
        </section>
        <section anchor="def-hierarchy-and-inheritance" numbered="true" toc="default">
          <name>Hierarchy and Inheritance</name>
          <t>To simplify the representation, some types of entity domains allow the ALTO
Client and Server to use a hierarchical entity identifier format to represent
a block of individual entities. For instance, in an IPv4 domain "net1.ipv4",
a CIDR "net1.ipv4:192.0.2.0/26" covers 64 individual IPv4 entities. In this
case, the corresponding property inheritance rule MUST <bcp14>MUST</bcp14> be defined for the
entity domain type. The hierarchy and inheritance rule MUST <bcp14>MUST</bcp14> have no
ambiguity.</t>
        </section>
      </section>
      <section anchor="def-property" numbered="true" toc="default">
        <name>Entity Property</name>
        <t>Each entity property has a type to indicate the encoding and the semantics of
the value of this entity property, and has a name to identify it.</t>

   	<section anchor="def-property-type" numbered="true" toc="default">
          <name>Entity Property Type</name>
     <t>The type EntityPropertyType is used in this document to indicate a string
	denoting an entity property type. The string MUST <bcp14>MUST</bcp14> be no more than 32
	characters, and it MUST NOT <bcp14>MUST NOT</bcp14> contain characters other than US-ASCII
	alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A),
	the hyphen hyphen-minus ('-', U+002D), the colon (':', U+003A), or the low line ('_',
	U+005F). Note that the '.' separator is not allowed because it is reserved to
	separate an entity property type and an information resource identifier when
	an entity property is resource-specific.</t>

	<t>While, in

	<t>While <xref target="domain-types" format="default"/>, format="default"/> allows the use of the
	character ":" is allowed with restrictions on entity domain identifiers,
	it can be used without restrictions on entity property type identifiers.
	This relates to <xref target="RFC7285" format="default"/>, where a Server
	can define properties on for endpoints "ipv4" and "ipv6". In the present extension,
	there is a mapping of ALTO entity domain types "ipv4" and "ipv6", "ipv6" to ALTO
	address types "ipv4" and "ipv6". Properties defined on for "ipv4" and "ipv6"
	endpoints should be re-usable reusable on "ipv4" and "ipv6" entities. Forbidding the
	usage of ":" in a non-private entity property type identifier would not
	allow to the use of properties previously defined on for "ipv4" and "ipv6" endpoints
	because their identifiers would be invalid.</t>

	<t>Although “:” ":" or “_::-“ "_::-" are valid entity domain types,
	it is desirable to add characters characters, such as alphanumeric ones,
	for better intelligibility. </t>

     <t>Identifiers prefixed with "priv:" are reserved for Private Use
     <xref target="RFC8126" format="default"/>
	without a need to register with IANA. All other identifiers for entity
	property types MUST <bcp14>MUST</bcp14> be registered in the "ALTO Entity
	Property Type Registry", Types" registry, which is defined in <xref target="IANAEntityProp" format="default"/>.
	The intended semantics of the entity property type MUST <bcp14>MUST</bcp14> be specified in the IANA registration.
	</t>
	<t>For an entity
	property identifier with the "priv:" prefix, an additional string (e.g.,
	company identifier or random string) MUST <bcp14>MUST</bcp14> follow the prefix to reduce
	potential collisions, that is, the string "priv:" alone is not a valid
	entity property identifier.
	 The definition of a private use private-use entity property type must apply
	 the same way in all property maps of an IRD where it is present.
	</t>

          <t>To distinguish from the endpoint property type, the entity property type has
the following characteristics:</t>
          <ul spacing="normal">
            <li>Some entity property types are applicable only to entities in particular entity
domain types only. types. For example, the property type "pid" is applicable to
entities in the entity domain types "ipv4" or "ipv6" "ipv6", while it is not
applicable to entities in an entity domain of type "pid".</li>
            <li>The intended semantics of the value of an entity property may also depend
		on the entity domain type. For example, suppose that a property named
		"geo-location" is defined as the coordinates of a point, point and is encoded as:
		"latitude longitude [altitude]." When applied to an entity that represents
		a specific host computer, computer and identified by an address in an entity domain of
		type "ipv4" or "ipv6", the "geo-location" property would define the host's
		location. However, when applied to an entity in a "pid" domain type, of type "pid", the
		property would indicate a location representative of all hosts in this
		"pid" entity.</li>
          </ul>
        </section>

        <section anchor="entity-property-name" numbered="true" toc="default">
          <name>Entity Property Name</name>
          <t>Each entity property is identified by an entity property name, which is a
string of the following format:</t>
          <artwork name="" type="" align="left" alt=""><![CDATA[
          <sourcecode type=""><![CDATA[
EntityPropertyName ::= [ [ ResourceID ] '.' ] EntityPropertyType
]]></artwork>
]]></sourcecode>
          <t>Similar to the endpoint property type defined in Section 10.8 of <xref target="RFC7285" section="10.8" sectionFormat="of" format="default"/>,
each entity property may be defined by either the property map itself
(self-defined) or some other specific information resource
(resource-specific).</t>
          <t>The entity property name of a resource-specific entity property starts with a
string of the type ResourceID defined in <xref target="RFC7285" format="default"/>, followed by the '.'
separator (U+002E) and a an EntityDomainType typed string. For example, the
"pid" properties of an "ipv4" entity defined by two different maps
"net-map-1" and "net-map-2" are identified by "net-map-1.pid" and
"net-map-2.pid" respectively.</t>
          <t>The specific information resource of an entity property may be the current
information resource itself, that is, the property map defining the property.
In that case, the ResourceID in the property name SHOULD <bcp14>SHOULD</bcp14> be omitted. For
example, the property name ".asn" ".ASN" applied to an entity identified by its
IPv4 address, address indicates the AS number of the AS that "owns" the entity, where
the returned AS number is defined by the property map itself.</t>
        </section>

        <section anchor="format-entity-property-value" numbered="true" toc="default">
          <name>Format for Entity Property Value</name>
          <t>Section 11.4.1.6 of <xref
          <t><xref target="RFC7285" section="11.4.1.6" sectionFormat="of" format="default"/> specifies that an implementation of the
Endpoint Property Service specified in <xref target="RFC7285" format="default"/> SHOULD <bcp14>SHOULD</bcp14> assume that the
property value is a JSONString and fail to parse if it is not. This document
extends the format of a property value by allowing it to be a JSONValue
instead of just a JSONString.</t>
        </section>
      </section>
    </section>

    <section anchor="entity-domain-types" numbered="true" toc="default">
      <name>Entity Domain Types Defined in this This Document</name>
      <t>The definition of each entity domain type MUST <bcp14>MUST</bcp14> include
(1)
the entity domain type name and (2) the domain-specific entity identifiers,
and MAY identifiers.
The definition of an entity domain type
<bcp14>MAY</bcp14> include (3) hierarchy and inheritance semantics optionally. semantics. This
document defines three initial entity domain types as follows.</t>
      <section anchor="inet-addr-domain" numbered="true" toc="default">
        <name>Internet Address Domain Types</name>
        <t>The document defines two entity domain types (IPv4 and IPv6) for Internet
addresses. Both types are resource-agnostic entity domain types and hence
define corresponding resource-agnostic entity domains as well. Since the two
domains use the same hierarchy and inheritance semantics, we define the
semantics together, instead of repeating for each.</t>

        <section anchor="ipv4-domain" numbered="true" toc="default">
          <name>Entity Domain Type: IPv4</name>
          <section anchor="ipv4-edt" numbered="true" toc="default">
            <name>Entity Domain Type Identifier</name>
            <t>The identifier for this Entity Domain Type entity domain type is "ipv4".</t>
          </section>
          <section anchor="ipv4-dsei" numbered="true" toc="default">
            <name>Domain-Specific Entity Identifiers</name>
            <t>Individual addresses are strings as specified by the IPv4address rule in
		Section 3.2.2 of
		<xref target="RFC3986" section="3.2.2" sectionFormat="of" format="default"/>;
		Hierarchical
		hierarchical addresses are strings as specified by the prefix notation in Section 3.1
		of
		<xref target="RFC4632" section="3.1" sectionFormat="of" format="default"/>.
		To define properties, an
		An
		individual Internet address and the corresponding full-length prefix are
		considered aliases for the same entity on which to define properties.
		Thus, "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are equivalent.</t>
          </section>
        </section>

        <section anchor="ipv6-domain" numbered="true" toc="default">
          <name>Entity Domain Type: IPv6</name>
          <section anchor="ipv6-edt" numbered="true" toc="default">
            <name>Entity Domain Type Identifier</name>
            <t>The identifier for this Entity Domain Type is "ipv6".</t>
          </section>

          <section anchor="ipv6-dsei" numbered="true" toc="default">
            <name>Domain-Specific Entity Identifiers</name>

            <t>Individual addresses are strings as specified by
   		 Section 4 of
   		 <xref target="RFC5952" section="4" sectionFormat="of" format="default"/>;
		Hierarchical
		hierarchical addresses are strings as specified by
		 IPv6 address prefixes notation in Section 2.3 of
		<xref target="RFC4291" section="2.3" sectionFormat="of" format="default"/>.

		To define properties, an individual Internet address and the
		corresponding 128-bit prefix are considered aliases for the same entity. That
		is, "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, equivalent and have
		the same set of properties.</t>
          </section>
        </section>

        <section anchor="inet-inheritance" numbered="true" toc="default">
          <name>Hierarchy and Inheritance of Internet Address Domains</name>
          <t>Both Internet address domains allow property values to be inherited.
		Specifically, if a property P is not defined for a specific Internet address
		I, but P is defined for a hierarchical Internet address C which that
		represents a set of addresses containing I, then the address I inherits
		the value of P defined for the hierarchical address C.
		If more than one such hierarchical addresses define a
		value for P, I inherits the value of P in the hierarchical address with the
		longest prefix. Note that this longest prefix rule ensures no multiple value
		inheritances, and hence no ambiguity.</t>
          <t>Hierarchical addresses can also inherit properties: properties. For instance, if a property P is P:</t>
            <ul>
              <li>is not
		  defined for the hierarchical address C, but C,</li>
              <li>
                <t>but is defined for
		   a set of hierarchical addresses, where each addresses where:</t>
                <ul>
                  <li>each address C' in the set
		      contains all IP addresses in C, and C' and</li>
                  <li>C' has a shorter prefix length than C,
		then C,</li>
                </ul>
              </li>
             </ul>
	  <t>then C MUST <bcp14>MUST</bcp14> inherit the property P from the C' having the longest prefix length.
		</t>
          <t>As an example, suppose that a server defines a property P for the following
entities:</t>
          <figure
          <table anchor="fig_def-prop-val">
            <name>Defined Property Values.</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                          ipv4:192.0.2.0/26: P=v1
                          ipv4:192.0.2.0/28: P=v2
                          ipv4:192.0.2.0/30: P=v3
                          ipv4:192.0.2.0:    P=v4
]]></artwork>
          </figure> Values</name>
            <tbody>
              <tr>
                <td>ipv4:192.0.2.0/26:</td>
                <td>P=v1</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/28:</td>
                <td>P=v2</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/30:</td>
                <td>P=v3</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0:</td>
                <td>P=v4</td>
              </tr>
            </tbody>
          </table>
          <t>Then the following entities have the indicated values:</t>
          <figure
          <table anchor="fig_inh-prop-val">
            <name>Inherited Property Values.</name>
            <artwork name="" type="" align="left" alt=""><![CDATA[
                      ipv4:192.0.2.0:    P=v4
                      ipv4:192.0.2.1:    P=v3
                      ipv4:192.0.2.16:   P=v1
                      ipv4:192.0.2.32:   P=v1
                      ipv4:192.0.2.64:   (not defined)
                      ipv4:192.0.2.0/32: P=v4
                      ipv4:192.0.2.0/31: P=v3
                      ipv4:192.0.2.0/29: P=v2
                      ipv4:192.0.2.0/27: P=v1
                      ipv4:192.0.2.0/25: (not defined)
]]></artwork>
          </figure>
          <!-- Improve words of this paragraph. (Done, waiting for review) --> Values</name>
            <tbody>
              <tr>
                <td>ipv4:192.0.2.0:</td>
                <td>P=v4</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.1:</td>
                <td>P=v3</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.16:</td>
                <td>P=v1</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.32:</td>
                <td>P=v1</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.64:</td>
                <td>(not defined)</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/32:</td>
                <td>P=v4</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/31:</td>
                <td>P=v3</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/29:</td>
                <td>P=v2</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/27:</td>
                <td>P=v1</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/25:</td>
                <td>(not defined)</td>
              </tr>
            </tbody>
          </table>

<t>An ALTO server MAY <bcp14>MAY</bcp14> explicitly indicate a property as not having a value for
a particular entity. That is, a server MAY <bcp14>MAY</bcp14> say that property P of entity X is
"defined to have no value", value" instead of "undefined". To indicate "no value",
a server MAY <bcp14>MAY</bcp14> perform different behaviors:</t>
          <ul spacing="normal">
            <li>
		If entity X would inherit a value for property P, and if the ALTO server decides to
		say that "X has no value for P", then the
      	ALTO server MUST <bcp14>MUST</bcp14> return a "null" value for that property on X. In this
      	case, the ALTO client MUST <bcp14>MUST</bcp14> recognize the JSON "null" value as "no value"
      	and interpret it as "do not apply the inheritance rules for this property on X".
		</li>
            <li>If the entity would not inherit a value, then the ALTO server MAY <bcp14>MAY</bcp14> return
		"null" or just omit the property. In this case, the ALTO client cannot infer
		the value for this property of this entity from the Inheritance rules. So, Thus, the
		client MUST <bcp14>MUST</bcp14> interpret that this property has no value.</li>
          </ul>
          <t>If the ALTO server does not define any properties for an entity, then the
server MAY <bcp14>MAY</bcp14> omit that entity from the response.</t>
        </section>

        <section anchor="defining-IR-media-type-ipv4-ipv6" numbered="true" toc="default">
          <name>Defining Information Resource Media Type for domain types Domain Types IPv4 and IPv6</name>
          <t>Entity domain types "ipv4" and "ipv6" both allow to define resource specific the definition of resource-specific
entity domains. When resource specific resource-specific domains are defined with entities of
domain type "ipv4" or "ipv6", the defining information resource for an entity
domain of type "ipv4" or "ipv6" MUST <bcp14>MUST</bcp14> be a Network Map. network map. The media type of a
defining information resource is therefore:</t>
          <t>application/alto-networkmap+json</t>
        </section>
      </section>

      <section anchor="pid-domain" numbered="true" toc="default">
        <name>Entity Domain Type: PID</name>
        <t>The PID entity domain associates property values with the PIDs in a network map.
Accordingly, this entity domain always depends on a network map.</t>
        <section anchor="entity-domain-type-identifier" numbered="true" toc="default">
          <name>Entity Domain Type Identifier</name>
          <t>The identifier for this Entity Domain Type is "pid"</t> "pid".</t>
        </section>

        <section anchor="domain-specific-entity-identifiers" numbered="true" toc="default">
          <name>Domain-Specific Entity Identifiers</name>
          <t>The entity identifiers are the PID names of the associated network map.</t>
        </section>
        <section anchor="hierarchy-and-inheritance" numbered="true" toc="default">
          <name>Hierarchy and Inheritance</name>
          <t>There are is no hierarchy or inheritance for properties associated with PIDs.</t>
        </section>

        <section anchor="defining-IR-media-type-pid" numbered="true" toc="default">
          <name>Defining Information Resource Media Type for Domain Type PID</name>
          <t>The entity domain type "pid" allows to define resource specific the definition of resource-specific entity
domains. When resource specific resource-specific domains are defined with entities of domain
type "pid", the defining information resource for entity domain type "pid"
MUST
<bcp14>MUST</bcp14> be a Network Map. network map. The media type of a defining information resource is
therefore:</t>
          <t>application/alto-networkmap+json</t>
        </section>

        <section anchor="relationship-to-internet-addresses-domains" numbered="true" toc="default">
          <name>Relationship To Internet Addresses Domains</name>
          <t>The PID domain and the Internet address domains are completely independent;
the properties associated with a PID have no relation to the properties
associated with the prefixes or endpoint addresses in that PID. An ALTO
server MAY <bcp14>MAY</bcp14> choose to assign all the properties of a PID to the prefixes in
that PID or only some of these properties.</t>
          <t>For example, suppose "PID1" consists of the prefix "ipv4:192.0.2.0/24", "ipv4:192.0.2.0/24" and
has the property "P" P with value "v1". v1. The Internet address entities
"ipv4:192.0.2.0" and "ipv4:192.0.2.0/24" in the IPv4 domain MAY <bcp14>MAY</bcp14> have a value
for the property "P", P, and if they do, it is not necessarily "v1".</t> v1.</t>
        </section>
      </section>

      <section anchor="internet-address-properties-vs-pid-properties" numbered="true" toc="default">
        <name>Internet Address Properties vs. PID Properties</name>
        <t>Because the Internet address and PID domains relate to completely distinct domain types, the
question may arise as to which entity domain type is the best for a property. In general, the
Internet address domain types are RECOMMENDED <bcp14>RECOMMENDED</bcp14> for properties that are closely related
to the Internet address, address or are associated with, and inherited through, hierarchical addresses.</t>
        <t>The PID domain type is RECOMMENDED <bcp14>RECOMMENDED</bcp14> for properties that arise from the definition of
the PID, rather than from the Internet address prefixes in that PID.</t>
        <t>For example, because Internet addresses are allocated to service providers by
blocks of prefixes, an "ISP" property would be best associated with Internet
address domain types. On the other hand, a property that explains why a PID
was formed, or how it relates to a provider's network, would best be
associated with the PID domain type.</t>
      </section>
    </section>

    <section anchor="prop-map" numbered="true" toc="default">
      <name>Property Map</name>
      <t>A property map returns the properties defined for all entities in one or more
	domains, e.g., the "location" property of entities in "pid" domain, a domain of type "pid", and the
	"ASN" property of entities in domains of types "ipv4" and "ipv6" domains. "ipv6".
	<xref target="prop-map-example" format="default"/> gives an example of a
	property map request and its response.
	</t>
	<t>Downloading the whole property map is a way for the Client to obtain the Entity IDs entity identifiers
	that can be used as input for a Filtered Property Map filtered property map request.
	However, a whole property map may be too voluminous for a Client that
	only wants the list of applicable Entity IDs. entity identifiers. How to obtain the list of entities
	of a filtered property map in a simplified response is specified in
	<xref target="filter-prop-map" format="default"/>.
	</t>

      <section anchor="FullPropMapMediaType" numbered="true" toc="default">
        <name>Media Type</name>
        <t>The media type of a property map is "application/alto-propmap+json".</t>
      </section>

      <section anchor="http-method" numbered="true" toc="default">
        <name>HTTP Method</name>
        <t>The property map is requested using the HTTP GET method.</t>
      </section>

      <section anchor="accept-input-parameters" numbered="true" toc="default">
        <name>Accept Input Parameters</name>
        <t>A Property Map property map has no Accept Input parameters.</t>
      </section>

      <section anchor="FullPropMapCapabilities" numbered="true" toc="default">
        <name>Capabilities</name>
        <t>The capabilities are defined by an object of type PropertyMapCapabilities:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    object {
      EntityPropertyMapping mappings;
    } PropertyMapCapabilities;

    object-map {
      EntityDomainName -> EntityPropertyName<1..*>;
    } EntityPropertyMapping
]]></artwork>
        <t>with fields:</t>
        <dl newline="false" spacing="normal">
          <dt>mappings:</dt>
          <dd>
  A JSON object whose keys are names of entity domains and values are the
supported entity properties of the corresponding entity domains.</dd>
        </dl>
      </section>

      <section anchor="FullPropMapUses" numbered="true" toc="default">
        <name>Uses</name>
        <t> The "uses" field of a property map resource in an IRD entry specifies
	   the resources in this same IRD on which this property map directly depends. It is an array of
	   resource ID(s). identifier(s). This array identifies the defining information resources associated with
	   the resource-specific entity domains and properties that are indicated in this resource.
	</t>
      </section>

      <section anchor="FullPropMapResponse" numbered="true" toc="default">
        <name>Response</name>
        <t>If the entity domains in this property map depend on other resources, the
"dependent-vtags" field in the "meta" field of the response MUST <bcp14>MUST</bcp14> be an array
that includes the version tags of those resources, and the order MUST <bcp14>MUST</bcp14> be
consistent with the "uses" field of this property map resource. The data
component of a property map response is named "property-map", which is a JSON
object of type PropertyMapData, where:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
    object {
      PropertyMapData property-map;
    } InfoResourceProperties : ResponseEntityBase;

    object-map {
      EntityID -> EntityProps;
    } PropertyMapData;

    object {
      EntityPropertyName -> JSONValue;
    } EntityProps;
]]></artwork>
        <t>The ResponseEntityBase type is defined in Section 8.4
        of
        <xref target="RFC7285" section="8.4" sectionFormat="of" format="default"/>.
        </t>
        <t>Specifically, a PropertyMapData object has one member for each entity in the
		property map. The entity's properties are encoded in the corresponding
		EntityProps object. EntityProps encodes one name/value pair for each property,
		where the property names are encoded as strings of type PropertyName.
		A protocol implementation SHOULD <bcp14>SHOULD</bcp14> assume that the property value is either
		a JSONString or a JSON "null" value, and fail to parse if it is not, unless the
		implementation is using an extension to this document that indicates when and
		how property values of other data types are signaled.</t>

        <t>For each entity in the property map:</t>
        <ul spacing="normal">
          <li>If the entity is in a resource-specific entity domain, the ALTO server MUST <bcp14>MUST</bcp14>
		only return self-defined properties and resource-specific properties which that
		depend on the same resource as the entity does. The ALTO client MUST <bcp14>MUST</bcp14> ignore
		any resource-specific property for this entity if the mapping between
		this resource-specific property and this entity is not indicated, in the
      	IRD, in the "mappings" capability of the property map resource.
		</li>
          <li>
                If the entity identifier is resource-agnostic, the ALTO server SHOULD <bcp14>SHOULD</bcp14>
                return the self-defined properties and all the resource-specific
                properties that are defined in the property defining property-defining information resources that are
                indicated, in the IRD, in the “mappings” "mappings" capability of the property map resource,
                unless property values can be omitted upon some inheritance rules.
		</li>
        </ul>
        <!--
For each entity in the Property Map, the ALTO server returns the value defined
for each of the properties specified in this resource's `capabilities` list.
-->
<t>
The ALTO server MAY <bcp14>MAY</bcp14> omit property values that are inherited rather than
explicitly defined, defined in order to achieve more compact encoding. As a consequence,
the ALTO Client MUST NOT <bcp14>MUST NOT</bcp14> assume inherited property values will all be present.
If the Client needs inherited values, it MUST <bcp14>MUST</bcp14> use the entity domain's
inheritance rules to deduce those values.
</t>
      </section>
    </section>

    <section anchor="filter-prop-map" numbered="true" toc="default">
      <name>Filtered Property Map</name>
      <t>A filtered property map returns the values of a set of properties for a set of
		entities selected by the client.
		</t>
	<t><xref
	<t>Sections <xref target="filt-prop-map-example-1" format="default"/>, format="counter"/>,
	<xref target="filt-prop-map-example-2" format="default"/>, format="counter"/>,
		<xref target="filt-prop-map-example-3" format="default"/> format="counter"/>,
		and <xref target="filt-prop-map-example-4" format="default"/> format="counter"/> give examples of
		filtered property map requests and responses.
		</t>
		<t>
		While the IRD lists all the names of the supported properties,
		it only lists the names of the supported entity domains and not the entity IDs.
		A client, sometimes, may identifiers.
                Sometimes a client only want wants to know what entity IDs identifiers it can provide as input to a
                filtered property map request but wants does not want to avoid the burden of downloading download the full property
		map. Or
                map, or it may want to check whether some given entity IDs identifiers are eligible for a query.
                To support such a case, these cases, the filtered property map supports a light weight response, lightweight response
                with empty property values.
		</t>

      <section anchor="FilterPropMapMediaType" numbered="true" toc="default">
        <name>Media Type</name>
        <t>The media type of a property map resource is
		"application/alto-propmap+json".</t>
      </section>

      <section anchor="http-method-1" numbered="true" toc="default">
        <name>HTTP Method</name>
        <t>The filtered property map is requested using the HTTP POST method.</t>
      </section>

      <section anchor="filter-prop-map-params" numbered="true" toc="default">
        <name>Accept Input Parameters</name>
        <t>The input parameters for a filtered property map request 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-propmapparams+json", which is a JSON object of type
		ReqFilteredPropertyMap. ReqFilteredPropertyMap is designed to support the
		following cases of client requests:
		</t>
		 <ul spacing="normal">
		 <li>The client wants the value of a selected set of properties on for a selected set of entities,</li> entities;</li>
		 <li>The client wants all properties property values on all the entities, entities; </li>
		 <li>The client wants all entities on for which a property is defined
		 	but is not interested in their property values,</li> values; or</li>
		 <li>The Client client wants to cross-check whether some entity IDs identifiers are present in
		 the Filtered Property Map filtered property map but is not interested in their property values.</li>
		 </ul>
		<t>The third case is equivalent to querying the whole unfiltered property map, which
		can also be achieved with a GET request.
		Some Clients Clients, however, may prefer to systematically make filtered property map queries,
		where filtering parameters may sometimes be empty.</t>
		<t>The JSON object ReqFilteredPropertyMap is specified as follows:</t>
		<artwork name="" type="" align="left" alt=""><![CDATA[
		  object {
		    EntityID             entities<0..*>;
		    [EntityPropertyName   properties<0..*>;]
		  } ReqFilteredPropertyMap;
]]></artwork>

        <t>with fields:</t>
        <dl newline="false" spacing="normal">
          <dt>entities:</dt>
          <dd>
		List
		A list of entity identifiers for which the specified properties are to be
		returned.
		If the list is empty, the ALTO Server MUST <bcp14>MUST</bcp14> interpret the list as if it
		contained a list of all entities currently defined in the filtered property map.
		The domain of each entity MUST <bcp14>MUST</bcp14> be included in the list of entity domains in
		this resource's "capabilities" field (see
		<xref target="FilteredPropMapCapabilities" format="default"/>).
		The ALTO server MUST <bcp14>MUST</bcp14> interpret entries appearing multiple times
		as if they appeared only once.
		</dd>

          <dt>properties:</dt>
          <dd>
		List
		A list of properties to be returned for each entity.

		If the list is empty, the ALTO Sever MUST <bcp14>MUST</bcp14> interpret the list as if it
		contained a list of all properties currently defined in the filtered property map.
		Each specified property MUST <bcp14>MUST</bcp14> be included in the list of properties in this resource's
		"capabilities" field (see <xref target="FilteredPropMapCapabilities" format="default"/>).
		The ALTO server MUST <bcp14>MUST</bcp14> interpret entries appearing multiple times as if
		they appeared only once.

		This field is optional. If it is absent, the Server returns
		a property value equal to the literal string "{}"
		for all the entity IDs identifiers of the "entities" field on for which at least one property is
		defined.
		</dd>
        </dl>
        <t>Note that the field "properties" is optional. When in In addition, when
        	the "entities" field is an empty list, it corresponds to a
		query for all applicable entity IDs identifiers of the filtered property map, with no
		current interest on any particular property. When
        	the "entities" field is not empty, it allows the Client
        	to check whether the listed entity IDs identifiers can be used as input to a filtered property
        	map query.</t>
      </section>

      <section anchor="FilteredPropMapCapabilities" numbered="true" toc="default">
        <name>Capabilities</name>
        <t>The capabilities are defined by an object of type PropertyMapCapabilities, as
		defined in <xref target="FullPropMapCapabilities" format="default"/>.</t>
      </section>

      <section anchor="uses" numbered="true" toc="default">
        <name>Uses</name>
        <t>Same to
        <t>This is the same as the "uses" field of the Property Map property map resource (see
		<xref target="FullPropMapUses" format="default"/>).
		</t>
        <!--
The `uses` field of a filtered property map is an array with the resource ID(s)
of resource(s) that each domain in `entity-domains` depends on, in order to
provide the properties specified in the `properties` capability. The same `uses`
rule as defined by the property map resource applies (see [](#FullPropMapUses)).
-->

<!-- YRY: say refer to the same consistency of uses in Section 4.5. -->
	</section>

	<!-- Filtered Property Map Response -->

	<section anchor="FilteredPropMapResponse" numbered="true" toc="default">
        <name>Filtered Property Map Response</name>
        <t>The response MUST <bcp14>MUST</bcp14> indicate an error, using ALTO protocol Protocol error handling, as
		defined in Section 8.5 of <xref target="RFC7285" section="8.5" sectionFormat="of" format="default"/>, if the request is invalid.
		</t>
        <t>Specifically, a filtered property map request can be invalid in the following cases:
        </t>
        <ul spacing="normal">
		<li>The input field "entities" is absent from the Client request.
        	In this case, the Server MUST <bcp14>MUST</bcp14> return an "E_MISSING_FIELD" error
		as defined in Section 8.5.2 of <xref target="RFC7285" section="8.5.2" sectionFormat="of" format="default"/>.
		</li>
          <li>
          <t>An entity identifier in the "entities" field of the request is invalid.
            This occurs when:
            </t>
            <ul spacing="normal">
              <li>The domain of this entity is not defined in the "entity-domains" "mappings"
			capability of this resource in the IRD,</li> IRD, or</li>
              <li>The entity identifier is not valid for the entity domain.</li>
            </ul>
           <t> A valid entity identifier does never generate generates an error, even if the filtered property
	  		map resource does not define any properties for it.
	  		</t>
            <t>
			If an entity identifier in the "entities" field of the 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 the provided invalid entity identifier.
			</t>
          </li>
          <li>
          <t>A property name in the "properties" field of the request is invalid. This
          occurs when this property name is not defined in the "properties" capability of this
		resource in the IRD.
		</t>
		<t> When a filtered property map resource does not define a value for a
		property requested on for a particular entity, it is not an error. In this
		case, the ALTO server MUST <bcp14>MUST</bcp14> omit that property from the response for that
		endpoint.  </t>
          <t> If a property name in the "properties" field in the 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"/>. The "value" field of the error message SHOULD <bcp14>SHOULD</bcp14>
		indicate the property name.
		</t>
          </li>
        </ul>
		<t>Some identifiers can be interpreted as both an entity name and a property name,
		as it is the case for "pid" if it would be were erroneously used alone.
		In such a case, the Server SHOULD <bcp14>SHOULD</bcp14> follow Section 8.5.2 of
		<xref target="RFC7285" section="8.5.2" sectionFormat="of" format="default"/>, that says:
		"For which says:</t>
                <blockquote>
		For an E_INVALID_FIELD_VALUE error, the server may include an optional field
		named "field" in the "meta" field of the response, to indicate the field that contains the
   		wrong value."
		</t> value.
		</blockquote>

        <t>The response to a valid request is the same as for the Property Map property map
		(see <xref target="FullPropMapResponse" format="default"/>), format="default"/>) except that:</t>
        <ul spacing="normal">
          <li> If the requested entities include entities with a resource-agnostic identifier,
          the "dependent-vtags" field in its "meta" field MUST <bcp14>MUST</bcp14> include version tags of all
		dependent resources appearing in the "uses" field.
		</li>
          <li>If the requested entities only include entities in resource-specific entity
		domains, the "dependent-vtags" field in its "meta" field MUST <bcp14>MUST</bcp14> include the version
		tags of the resources on which the requested resource-specific entity domains and
		the requested resource-specific properties are dependent on. dependent.
		</li>
          <li>The response only includes the entities and properties requested by the
		client. If an entity in the request is identified by a hierarchical identifier
		(e.g., a "ipv4" or "ipv6" prefix), the response MUST <bcp14>MUST</bcp14> return all properties that
		are present on for any address covered by the prefix, even though some of those
		properties may not be present on for all addresses covered by the prefix.
		</li>
		<li>When the input member "properties" is absent from the client request,
		the Server returns a property map containing all the requested entity identifiers
		on
		for which one or more properties are defined. For all the entities of the returned map,
		the returned property value is equal to '{}'. "{}".
		</li>
        </ul>

        <t>The filtered property map response MUST <bcp14>MUST</bcp14> include all the inherited property
		values for the requested entities and all the entities which that are able to
		inherit property values from the requested entities. To achieve this goal,
		the ALTO server MAY <bcp14>MAY</bcp14> follow two rules:</t>
        <ul spacing="normal">
          <li>If a property for a requested entity is inherited from another entity not
		included in the request, the response MUST <bcp14>MUST</bcp14> include this property for the
		requested entity. For example, A a full property map may skip a property P for
		an entity A (e.g., ipv4:192.0.2.0/31) "ipv4:192.0.2.0/31") if P can be derived using inheritance
		from another entity B (e.g., ipv4:192.0.2.0/30). "ipv4:192.0.2.0/30"). A filtered property map
		request may include only A but not B. In such a case, the property P MUST <bcp14>MUST</bcp14> be
		included in the response for A.</li>

          <li>If there are entities covered by a requested entity but having they have different
		values for the requested properties, the response MUST <bcp14>MUST</bcp14> include all those
		entities and the different property values for them. For example, considering consider
		a request for property P of entity A (e.g., ipv4:192.0.2.0/31), "ipv4:192.0.2.0/31"): if P has value
		v1 for A1=ipv4:192.0.2.0/32 "A1=ipv4:192.0.2.0/32" and v2 for A2=ipv4:192.0.2.1/32, then, "A2=ipv4:192.0.2.1/32", then the
		response SHOULD <bcp14>SHOULD</bcp14> include A1 and A2.</li>
		</ul>

	<t>For the sake of response compactness, the ALTO server SHOULD <bcp14>SHOULD</bcp14> obey the following rule:</t>
	<ul spacing="normal">
          <li>If an entity identifier in the response is already covered by other
		entities identifiers in the same response, it SHOULD <bcp14>SHOULD</bcp14> be removed from the
		response. In the previous example, the entity
		A = ipv4:192.0.2.0/31 SHOULD
		"A=ipv4:192.0.2.0/31" <bcp14>SHOULD</bcp14> be removed because A1 and A2 cover all the
		addresses in A.</li>
	</ul>

        <t>An ALTO client should be aware that the entities in the response may be
		different from the entities in its request.</t>
      </section>

      <section anchor="prop-type-pid" numbered="true" toc="default">
        <name>Entity Property Type Defined in This Document</name>
        <t>This document defines the entity property type "pid". This property type
extends the ALTO Endpoint Property Type endpoint property type "pid" defined in section 7.1.1 of
<xref target="RFC7285" section="7.1.1" sectionFormat="of" format="default"/> as follows: the property has the same semantics and applies to
IPv4 and IPv6 addresses; the difference is that the IPv4 and IPv6 addresses
have evolved from the status of endpoints to the status of entities.</t>
        <t>The defining information resource for property type MUST <bcp14>MUST</bcp14> be a network map.
This document requests a IANA registration for this property
</t>
        <section anchor="entity-property-type-pid" numbered="true" toc="default">
          <name>Entity Property Type: pid</name>
          <ol spacing="normal" type="1">
            <li>Identifier: pid</li>
            <li>Semantics: the
          <dl spacing="normal">
            <dt>Identifier:</dt>
            <dd>pid</dd>

            <dt>Semantics:</dt>
            <dd>the intended semantics are the same as in <xref target="RFC7285" format="default"/> for the
ALTO Endpoint Property Type "pid"</li>
            <li>Media endpoint property type "pid".</dd>

            <dt>Media type of defining information resource: application/alto-networkmap+json</li>
            <li>Security considerations: for resource:</dt>
            <dd>application/alto-networkmap+json</dd>

            <dt>Security considerations:</dt>
            <dd>for entity property type "pid" are the same as
documented in <xref target="RFC7285" format="default"/> for the ALTO Endpoint Property Type "pid".</li>
          </ol> endpoint property type "pid".</dd>
          </dl>
        </section>
      </section>
    </section>

    <section anchor="legacy" numbered="true" toc="default">
      <name>Impact on Legacy ALTO Servers and ALTO Clients</name>

      <section anchor="impact-on-endpoint-property-service" numbered="true" toc="default">
        <name>Impact on Endpoint Property Service</name>
        <t>Since the Property Map property map and the Filtered Property Map filtered property map defined in this document
provide a functionality that covers the EPS
defined in Section 11.4 of <xref target="RFC7285" section="11.4" sectionFormat="of" format="default"/>, ALTO servers may prefer to provide
Property Map
property map and Filtered Property Map filtered property map in place of EPS. However, for the
legacy endpoint properties, it is recommended that ALTO servers also provide
EPS so that legacy clients can still be supported.</t>
      </section>

      <section anchor="impact-on-resource-specific-properties" numbered="true" toc="default">
        <name>Impact on Resource-Specific Properties</name>
        <t>Section 10.8 of <xref
        <t><xref target="RFC7285" section="10.8" sectionFormat="of" format="default"/> defines
        two categories of endpoint properties: "resource-specific" and "global".
Resource-specific property names are
prefixed with the ID identifier of the resource they depend on, while global property
names have no such prefix. The property map and the filtered property map
defined
specified in this document define similar categories of entity properties. The
difference is that entity property maps do not define "global" entity
properties. Instead, they define "self-defined" self-defined entity properties as a
special case of "resource-specific" entity properties, where the specific
resource is the property map itself. This means that "self-defined" self-defined
properties are defined within the scope of the property map.</t>
      </section>

      <section anchor="impact-on-other-properties" numbered="true" toc="default">
        <name>Impact on Other Properties</name>
        <t>In the present extension, properties can be defined on for sets of entity
addresses, rather than just individual endpoint addresses as initially defined
in <xref target="RFC7285" format="default"/>.
This might change the semantics of a property. These sets can be be,
for example example, hierarchical IP address blocks. For instance, a property such as the
fictitious "geo-location", "geo-location" defined on for a set of IP addresses would have a
value corresponding to a location representative of all the addresses in this set.
</t>
      </section>
    </section>

<!-- Examples -->

<section anchor="examples" numbered="true" toc="default">
 <name>Examples</name>
	<t>In this document, the HTTP message bodies of all the
	examples use Unix-style line-ending character (%x0A) as the line separator.</t>

	<section anchor="net-map-example" numbered="true" toc="default">
     <name>Network Map</name>

     <t>The examples in this section use a very simple default network map:</t>
        <figure
          <table anchor="net-map-values-ex">
            <name>Example Default Network Map</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
               defaultpid:  ipv4:0.0.0.0/0  ipv6:::/0
               pid1:        ipv4:192.0.2.0/25
               pid2:        ipv4:192.0.2.0/27
               pid3:        ipv4:192.0.3.0/28
               pid4:        ipv4:192.0.3.16/28
		]]></artwork>
        </figure>
            <tbody>
              <tr>
                <td>defaultpid:</td>
                <td>ipv4:0.0.0.0/0  ipv6:::/0</td>
              </tr>
              <tr>
                <td>pid1:</td>
                <td>ipv4:192.0.2.0/25</td>
              </tr>
              <tr>
                <td>pid2:</td>
                <td>ipv4:192.0.2.0/27</td>
              </tr>
              <tr>
                <td>pid3:</td>
                <td>ipv4:192.0.3.0/28</td>
              </tr>
              <tr>
                <td>pid4:</td>
                <td>ipv4:192.0.3.16/28</td>
              </tr>
            </tbody>
          </table>

      <t>And another simple alternative network map:</t>
        <figure
          <table anchor="alt-net-map-values-ex">
            <name>Example Alternative Network Map</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
               defaultpid:  ipv4:0.0.0.0/0  ipv6:::/0
               pid1:        ipv4:192.0.2.0/27
               pid2:        ipv4:192.0.3.0/27
		]]></artwork>
        </figure>
            <tbody>
              <tr>
                <td>defaultpid:</td>
                <td>ipv4:0.0.0.0/0  ipv6:::/0</td>
              </tr>
              <tr>
                <td>pid1:</td>
                <td>ipv4:192.0.2.0/27</td>
              </tr>
              <tr>
                <td>pid2:</td>
                <td>ipv4:192.0.3.0/27</td>
              </tr>
            </tbody>
          </table>
      </section>

      <section anchor="inet-prop-example" numbered="true" toc="default">
        <name>Property Definitions</name>
		<t>Beyond "pid", the examples in this section use four additional additional, fictitious property types
		for entities of domain type "ipv4": "countrycode", "ASN",  "ISP", and "state".
		These properties are assumed to be resource-agnostic so their name is identical
		to their type.  The entities have the following values:
		</t>

        <figure
          <table anchor="prop-map-values-ip-ex">
            <name>Example Property Values for Internet Address Domains</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                                ISP    ASN   countrycode   state
        ipv4:192.0.2.0/23:    BitsRus   -      	us          -
        ipv4:192.0.2.0/28:       -    65543    	-           NJ
        ipv4:192.0.2.16/28:      -    65543    	-           CT
        ipv4:192.0.2.1:          -      -      	-           PA
        ipv4:192.0.3.0/28:       -    65544    	-           TX
        ipv4:192.0.3.16/28:      -    65544    	-           MN
		]]></artwork>
        </figure>

        <t>And the
            <thead>
              <tr>
                <th>&nbsp;</th>
                <th align="center">ISP</th>
                <th align="center">ASN</th>
                <th align="center">countrycode</th>
                <th align="center">state</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>ipv4:192.0.2.0/23:</td>
                <td align="center">BitsRus</td>
                <td align="center">-</td>
                <td align="center">us</td>
                <td align="center">-</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.0/28:</td>
                <td align="center">-</td>
                <td align="center">65543</td>
                <td align="center">-</td>
                <td align="center">NJ</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.16/28:</td>
                <td align="center">-</td>
                <td align="center">65543</td>
                <td align="center">-</td>
                <td align="center">CT</td>
              </tr>
              <tr>
                <td>ipv4:192.0.2.1:</td>
                <td align="center">-</td>
                <td align="center">-</td>
                <td align="center">-</td>
                <td align="center">PA</td>
              </tr>
              <tr>
                <td>ipv4:192.0.3.0/28:</td>
                <td align="center">-</td>
                <td align="center">65544</td>
                <td align="center">-</td>
                <td align="center">TX</td>
              </tr>
              <tr>
                <td>ipv4:192.0.3.16/28:</td>
                <td align="center">-</td>
                <td align="center">65544</td>
                <td align="center">-</td>
                <td align="center">MN</td>
              </tr>
            </tbody>
          </table>

        <t>The examples in this section use the property "region" for the PID domain of
		the default network map with the following values:</t>
        <figure
          <table anchor="prop-map-values-pid-ex">
            <name>Example Property Values for Default Network Map's PID Domain</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                                      region
                   pid:defaultpid:     -
                   pid:pid1:           us-west
                   pid:pid2:           us-east
                   pid:pid3:           us-south
                   pid:pid4:           us-north
]]></artwork>
        </figure>
            <thead>
              <tr>
                <th>&nbsp;</th>
                <th>region</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>pid:defaultpid:</td>
                <td>-</td>
              </tr>
              <tr>
                <td>pid:pid1:</td>
                <td>us-west</td>
              </tr>
              <tr>
                <td>pid:pid2:</td>
                <td>us-east</td>
              </tr>
              <tr>
                <td>pid:pid3:</td>
                <td>us-south</td>
              </tr>
              <tr>
                <td>pid:pid4:</td>
                <td>us-north</td>
              </tr>
            </tbody>
          </table>
        <t>Note that "-" means the value of the property for the entity is "undefined". So
		the entity would inherit a value for this property by the inheritance rule if
		possible. For example, the value of the "ISP" property for "ipv4:192.0.2.1" is
		"BitsRus" because of "ipv4:192.0.2.0/24". But the "region" property for
		"pid:defaultpid" has no value because there is no entity from which it can inherit.</t>
        <t>Similar to the PID domain of the default network map, the examples in this
		section use the property "ASN" for the PID domain of the alternative network map
		with the following values:</t>
        <figure
          <table anchor="alt-prop-map-values-pid-ex">
            <name>Example Property Values for Alternative Network Map's PID Domain</name>
          <artwork name="" type="" align="left" alt=""><![CDATA[
                                          ASN
                       pid:defaultpid:     -
                       pid:pid1:         65543
                       pid:pid2:         65544
		]]></artwork>
        </figure>
            <thead>
              <tr>
                <th>&nbsp;</th>
                <th>ASN</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>pid:defaultpid:</td>
                <td>-</td>
              </tr>
              <tr>
                <td>pid:pid1:</td>
                <td>65543</td>
              </tr>
              <tr>
                <td>pid:pid2:</td>
                <td>65544</td>
              </tr>
            </tbody>
          </table>
      </section>

      <section anchor="ird-example" numbered="true" toc="default">
        <name>Information Resource Directory (IRD)</name>
        <t>The following IRD defines ALTO Server information resources that are relevant
		to the Entity Property Service. It provides a property map for the
		"ISP" and "ASN" properties.
		The server could have provided a single property map for all four
		properties, but it does not, presumably because the organization that runs the
		ALTO server believes that a client is not necessarily interested in getting
		all four properties.</t>

        <t>The server provides several filtered property maps. The first returns all
		four properties, and the second returns only the "pid" property for the
		default network map and the "alt-network-map".</t>
        <t>The filtered property maps for the "ISP", "ASN", "countrycode" "countrycode", and "state"
		properties do not depend on the default network map (it does not have a
		"uses" capability), capability) because the definitions of those properties do not depend
		on the default network map. The Filtered Property Map filtered property map providing the "pid"
		property does have a "uses" capability for the default network map because
		the default network map defines the values of the "pid" property.</t>
        <t>Note that for legacy clients, the ALTO server provides an Endpoint Property
		Service for the "pid" property defined on for the endpoints of the default
		network map and the "alt-network-map".</t>
        <t>The server provides another filtered Property map resource, named
		"ane-dc-property-map", that returns fictitious properties named
		"storage-capacity", "ram" "ram", and "cpu" for ANEs that have a persistent
		identifier. The entity domain to which the ANEs belong is "self-defined" self-defined and
		valid only within the property map.</t>
	   <t>The other property maps in the returned IRD are shown here for purposes of illustration.</t>

        <figure anchor="example-ird">

          <name>Example IRD</name>
          <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: 2713
 Content-Type: application/alto-directory+json

 {
   "meta" : {
     "default-alto-network-map" : "default-network-map"
   },
   "resources" : {
     "default-network-map" : {
       "uri" : "http://alto.example.com/networkmap/default",
       "media-type" : "application/alto-networkmap+json"
     },
     "alt-network-map" : {
       "uri" : "http://alto.example.com/networkmap/alt",
       "media-type" : "application/alto-networkmap+json"
     },
     "ia-property-map" : {
       "uri" : "http://alto.example.com/propmap/full/inet-ia",
       "media-type" : "application/alto-propmap+json",
       "capabilities" : {
         "mappings": {
           "ipv4": [ ".ISP", ".ASN" ],
           "ipv6": [ ".ISP", ".ASN" ]
         }
       }
     },
     "iacs-property-map" : {
       "uri" : "http://alto.example.com/propmap/lookup/inet-iacs",
       "media-type" : "application/alto-propmap+json",
       "accepts": "application/alto-propmapparams+json",
       "capabilities" : {
         "mappings": {
           "ipv4": [ ".ISP", ".ASN", ".countrycode", ".state" ],
           "ipv6": [ ".ISP", ".ASN", ".countrycode", ".state" ]
         }
       }
     },
     "region-property-map": {
       "uri": "http://alto.example.com/propmap/lookup/region",
       "media-type": "application/alto-propmap+json",
       "accepts": "application/alto-propmapparams+json",
       "uses" : [ "default-network-map", "alt-network-map" ],
       "capabilities": {
         "mappings": {
           "default-network-map.pid": [ ".region" ],
           "alt-network-map.pid": [ ".ASN" ]
         }
       }
     },
     "ip-pid-property-map" : {
       "uri" : "http://alto.example.com/propmap/lookup/pid",
       "media-type" : "application/alto-propmap+json",
       "accepts" : "application/alto-propmapparams+json",
       "uses" : [ "default-network-map", "alt-network-map" ],
       "capabilities" : {
         "mappings": {
           "ipv4": [ "default-network-map.pid",
                     "alt-network-map.pid" ],
           "ipv6": [ "default-network-map.pid",
                     "alt-network-map.pid" ]
         }
       }
     },
     "legacy-endpoint-property" : {
       "uri" : "http://alto.example.com/legacy/eps-pid",
       "media-type" : "application/alto-endpointprop+json",
       "accepts" : "application/alto-endpointpropparams+json",
       "capabilities" : {
         "properties" : [ "default-network-map.pid",
                          "alt-network-map.pid" ]
       }
     },
     "ane-dc-property-map": {
       "uri" : "http://alto.example.com/propmap/lookup/ane-dc",
       "media-type" : "application/alto-propmap+json",
       "accepts": "application/alto-propmapparams+json",
       "capabilities": {
         "mappings": {
           ".ane" : [ "storage-capacity", "ram", "cpu" ]
         }
       }
     }
   }
 }
]]></artwork>
        </figure>
      </section>

      <section anchor="prop-map-example" numbered="true" toc="default">
        <name>Full Property Map Example</name>
        <t>The following example uses the properties and IRD defined in
		<xref target="ird-example" format="default"/> to retrieve a Property Map property map for
		entities with the "ISP" and "ASN" properties.</t>
        <t>Note that, to be compact, the response does not include the entity
		"ipv4:192.0.2.1" because values of all those properties for this entity are
		inherited from other entities.</t>
        <t>Also note that the entities "ipv4:192.0.2.0/28" and "ipv4:192.0.2.16/28" are
		merged into "ipv4:192.0.2.0/27", "ipv4:192.0.2.0/27" because they have the same value of the
		"ASN" property. The same rule applies to the entities "ipv4:192.0.3.0/28" and
		"ipv4:192.0.3.16/28". Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit
		the value for the "ISP" property, property because it is inherited from
		"ipv4:192.0.2.0/23".</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[
GET /propmap/full/inet-ia HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Length: 418
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {"resource-id": "default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"},
      {"resource-id": "alt-network-map",
       "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"}
    ]
  },
  "property-map": {
    "ipv4:192.0.2.0/23":   {".ISP": "BitsRus"},
    "ipv4:192.0.2.0/27":   {".ASN": "65543"},
    "ipv4:192.0.3.0/27":   {".ASN": "65544"}
  }
}
]]></artwork>
      </section>

      <section anchor="filt-prop-map-example-1" numbered="true" toc="default">
        <name>Filtered Property Map Example #1</name>
        <t>The following example uses the filtered property map resource to request the
		"ISP", "ASN" "ASN", and "state" properties for several IPv4 addresses.</t>
        <t>Note that the value of "state" for "ipv4:192.0.2.1" is the only explicitly
		defined property; the other values are all derived by from the inheritance rules
		for Internet address entities.</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[
POST /propmap/lookup/inet-iacs HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: 158
Content-Type: application/alto-propmapparams+json

{
  "entities" : [ "ipv4:192.0.2.0",
                 "ipv4:192.0.2.1",
                 "ipv4:192.0.2.17" ],
  "properties" : [ ".ISP", ".ASN", ".state" ]
}
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Length: 540
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {"resource-id": "default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"},
      {"resource-id": "alt-network-map",
       "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"}
    ]
  },
  "property-map": {
    "ipv4:192.0.2.0":
           {".ISP": "BitsRus", ".ASN": "65543", ".state": "NJ"},
    "ipv4:192.0.2.1":
           {".ISP": "BitsRus", ".ASN": "65543", ".state": "PA"},
    "ipv4:192.0.2.17":
           {".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"}
  }
}
]]></artwork>
      </section>

      <section anchor="filt-prop-map-example-2" numbered="true" toc="default">
        <name>Filtered Property Map Example #2</name>
        <t>The following example uses the filtered property map resource to request the
		"ASN", "countrycode" "countrycode", and "state" properties for several IPv4 prefixes.</t>
        <t>Note that the property values for both entities "ipv4:192.0.2.0/26" and
		"ipv4:192.0.3.0/26" are not explicitly defined. They are inherited from the
		entity "ipv4:192.0.2.0/23".</t>
        <t>Also note that some entities like "ipv4:192.0.2.0/28" and
		"ipv4:192.0.2.16/28" in the response are not explicitly listed in the
		request. The response includes them because they are refinements of the
		requested entities and have different values for the requested properties.</t>
        <t>The entity "ipv4:192.0.4.0/26" is not included in the response, response because there
		are neither entities from which it is inherited from, inherited, nor entities inherited from
		it.</t>

        <artwork name="" type="" align="left" alt=""><![CDATA[
POST /propmap/lookup/inet-iacs HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: 174
Content-Type: application/alto-propmapparams+json

{
  "entities" : [ "ipv4:192.0.2.0/26",
                 "ipv4:192.0.3.0/26",
                 "ipv4:192.0.4.0/26" ],
  "properties" : [ ".ASN", ".countrycode", ".state" ]
}
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Length: 774
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {"resource-id": "default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"},
      {"resource-id": "alt-network-map",
       "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"}
    ]
  },
  "property-map": {
    "ipv4:192.0.2.0/26":  {".countrycode": "us"},
    "ipv4:192.0.2.0/28":  {".ASN": "65543",
                           ".state": "NJ"},
    "ipv4:192.0.2.16/28": {".ASN": "65543",
                           ".state": "CT"},
    "ipv4:192.0.2.1":     {".state": "PA"},
    "ipv4:192.0.3.0/26":  {".countrycode": "us"},
    "ipv4:192.0.3.0/28":  {".ASN": "65544",
                           ".state": "TX"},
    "ipv4:192.0.3.16/28": {".ASN": "65544",
                           ".state": "MN"}
  }
}
]]></artwork>
      </section>
      <section anchor="filt-prop-map-example-3" numbered="true" toc="default">
        <name>Filtered Property Map Example #3</name>
        <t>The following example uses the filtered property map resource to request the
"default-network-map.pid" property and the "alt-network-map.pid" property for
a set of IPv4 addresses and prefixes.</t>
        <t>Note that the entity "ipv4:192.0.3.0/27" is decomposed into two entities entities:
"ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28", as they have different
"default-network-map.pid" property values.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
POST /propmap/lookup/pid HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: 222
Content-Type: application/alto-propmapparams+json

{
  "entities" : [
                "ipv4:192.0.2.128",
                "ipv4:192.0.2.0/27",
                "ipv4:192.0.3.0/27" ],
  "properties" : [ "default-network-map.pid",
                   "alt-network-map.pid" ]
}
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Length: 774
Content-Type: application/alto-propmap+json

{
  "meta": {
    "dependent-vtags": [
      {"resource-id": "default-network-map",
       "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"},
      {"resource-id": "alt-network-map",
       "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"}
    ]
  },
  "property-map": {
    "ipv4:192.0.2.128":   {"default-network-map.pid": "defaultpid",
                           "alt-network-map.pid": "defaultpid"},
    "ipv4:192.0.2.0/27":  {"default-network-map.pid": "pid2",
                           "alt-network-map.pid": "pid1"},
    "ipv4:192.0.3.0/28":  {"default-network-map.pid": "pid3",
                           "alt-network-map.pid": "pid2"},
    "ipv4:192.0.3.16/28": {"default-network-map.pid": "pid4",
                           "alt-network-map.pid": "pid2"}
  }
}
]]></artwork>
      </section>
      <section anchor="filt-prop-map-example-4" numbered="true" toc="default">
        <name>Filtered Property Map Example #4</name>
        <t>Here is an example of using the filtered property map to query the regions
for several PIDs in "default-network-map". The "region" property is specified
as a "self-defined" self-defined property, i.e., the values of this property are defined
by this property map resource.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
POST /propmap/lookup/region HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: 132
Content-Type: application/alto-propmapparams+json

{
  "entities" : ["default-network-map.pid:pid1",
                "default-network-map.pid:pid2"],
  "properties" : [ ".region" ]
}
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Length: 326
Content-Type: application/alto-propmap+json

{
  "meta" : {
    "dependent-vtags" : [
       {"resource-id": "default-network-map",
        "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}
    ]
  },
  "property-map": {
    "default-network-map.pid:pid1": {
      ".region": "us-west"
    },
    "default-network-map.pid:pid2": {
      ".region": "us-east"
    }
  }
}
]]></artwork>
      </section>
      <section anchor="ane-example" numbered="true" toc="default">
        <name>Filtered Property Map for ANEs Example #5</name>
        <t>The following example uses the filtered property map resource
"ane-dc-property-map" to request properties "storage-capacity" and "cpu" on
several ANEs defined in this property map.</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
POST /propmap/lookup/ane-dc HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: 155
Content-Type: application/alto-propmapparams+json

{
  "entities" : [".ane:dc21",
                ".ane:dc45.srv9",
                ".ane:dc6.srv-cluster8"],
                ".ane:dc45-srv9",
                ".ane:dc6-srvcluster8"],
  "properties" : [ "storage-capacity", "cpu"]
}
]]></artwork>
        <artwork name="" type="" align="left" alt=""><![CDATA[
HTTP/1.1 200 OK
Content-Length: 295
Content-Type: application/alto-propmap+json

{
  "meta" : {
  },
  "property-map": {
    ".ane:dc21":
      {"storage-capacity" : 40000, "cpu" : 500},
    ".ane:dc45.srv9":
    ".ane:dc45-srv9":
      {"storage-capacity" : 100, "cpu" : 20},
    ".ane:dc6.srv-cluster8":
    ".ane:dc6-srvcluster8":
      {"storage-capacity" : 6000, "cpu" : 100}
  }
}
]]></artwork>
      </section>
    </section>

    <section anchor="SecSC" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>Both Property Map property map and Filtered Property Map filtered property map defined in this document fit into
the architecture of the ALTO base protocol, and hence the Security
Considerations (Section 15 of <xref (<xref target="RFC7285" section="15" sectionFormat="of" format="default"/>) of the base protocol fully apply:
authenticity and integrity of ALTO information (i.e., authenticity and
integrity of Property Maps), property maps), potential undesirable guidance from
authenticated ALTO information (e.g., potentially imprecise or even wrong
value of a property such as geo-location), confidentiality of ALTO
information (e.g., exposure of a potentially sensitive entity property such
as geo-location), privacy for ALTO users, and availability of ALTO services
should all be considered.</t>

      <t>ALTO clients using this extension should in addition be aware that the entity
	properties they require may convey more details than the endpoint properties
	conveyed by using <xref target="RFC7285" format="default"/>.
	Client requests may reveal details on of their
	activity or plans thereof, thereof such that a malicious Server, that which is in a position to do so,
	may monetize or use for
	attacks or undesired surveillance. Likewise, ALTO Servers expose entities and
	properties related to specific parts of the infrastructure that reveal
	details on of capabilities, locations, or resource availability. These details
	may be maliciously used for competition purposes, or to cause resource
	shortage or undesired publication.</t>

      <t>To address these concerns, the Property Maps property maps provided by this extension
require additional attention on to two security considerations discussed in in:
Section <xref target="RFC7285" format="default"/>: "potential undesirable guidance section="15.2" sectionFormat="bare">"Potential Undesirable Guidance from authenticated Authenticated ALTO
information" (Section 15.2 Information"</xref> of <xref target="RFC7285" format="default"/>) format="default"/>
and "confidentiality Section <xref target="RFC7285" section="15.3" sectionFormat="bare">"Confidentiality of ALTO
information" (Section 15.3
Information"</xref> of <xref target="RFC7285" format="default"/>). format="default"/>. Threats to the availability of
the ALTO Service service caused by highly demanding queries should be addressed as
specified in Section 15.5 of <xref target="RFC7285" section="15.5" sectionFormat="of" format="default"/>.</t>
      <ul spacing="normal">
        <li>
          <t>Potential undesirable guidance from authenticated ALTO information: it this can
be caused by Property values that change over time and thus lead to
performance degradation or system rejection of application requests.  </t>
          <t>
To avoid these consequences, a more robust ALTO client should adopt and
  extend protection strategies specified in Section 15.2 of <xref target="RFC7285" section="15.2" sectionFormat="of" format="default"/>.
  For example, to be notified immediately when a particular ALTO value that
  the Client depends on changes, it is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that both the ALTO
  Client and ALTO Server using this extension implement "Application-Layer
  Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events
  (SSE)"
  "<xref target="RFC8895" format="title"/>" <xref target="RFC8895" format="default"/>.</t>
        </li>
        <li>
          <t>Confidentiality of ALTO information: as discussed in Section 15 of
<xref target="RFC7285" section="15" sectionFormat="of" format="default"/>, properties may have sensitive customer-specific information.
If this is the case, an ALTO Server may limit access to those properties by
providing several different property maps. For non-sensitive a nonsensitive properties,
the ALTO Server would provide a URI which that accepts requests from any client.
Sensitive properties, on the other hand, would only be available via a
secure URI which that would require client authentication. Another way is to
expose highly abstracted abstracted, coarse-grained property values to all Clients while
restricting access to URIs exposing that expose more fine-grained values to authorized
Clients. Restricted access URIs may be gathered in delegate IRDs as
specified in Section 9.2.4 of <xref target="RFC7285" section="9.2.4" sectionFormat="of" format="default"/>.  </t>
          <t>
Also, while technically this document does not introduce any security
  risks not inherent in the Endpoint Property Service defined by <xref target="RFC7285" format="default"/>,
  the GET-mode property map resource defined in this document does make it
  easier for a client to download large numbers of property values.
  Accordingly, an ALTO Server should limit GET-mode property maps to
  properties that do not contain sensitive data.  </t>
          <t>
  Section 12
  <xref target="iana-considerations"/> of this document specifies that the ALTO service
  provider MUST <bcp14>MUST</bcp14> be aware of the potential sensitivity of exposed entity
  domains and properties. Section 12.2.2. (ALTO Entity Domain Type
  Registration Process) <xref target="dom-reg-process"/> (<xref target="dom-reg-process" format="title"/>)
  of this document specifies that when the
  registration of an entity domain type is requested at the of IANA, the
  request MUST <bcp14>MUST</bcp14> include security considerations that show awareness of how
  the exposed entity addresses may be related to private information about
  an ALTO client or an infrastructure service provider. Likewise, Section
  12.3. (ALTO Entity Property Type Registry)
  <xref target="IANAEntityProp"/> (<xref target="IANAEntityProp" format="title"/>) of this document specifies
  that when the registration of a property type is requested at the of IANA,
  the request MUST <bcp14>MUST</bcp14> include security considerations that explain why this
  property type is required for ALTO-based operations.  </t>
          <t>
The risk of ALTO information being leaked to malicious Clients or third
  parties is addressed similarly to Section 7 of <xref target="RFC8896" section="7" sectionFormat="of" format="default"/>. ALTO
  clients and servers SHOULD <bcp14>SHOULD</bcp14> support TLS 1.3 <xref target="RFC8446" format="default"/>.
  </t>
        </li>
      </ul>
    </section>

<!-- IANA Considerations -->

    <section anchor="iana-considerations" numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document defines additional application/alto-* media types, that which are
       listed in <xref target="TableMediaTypes" format="default"/>.
      It defines
	an ALTO
	the "ALTO Entity Domain Type Registry Types" registry that extends the ALTO "ALTO Address Type
	Registry Types"
	registry defined in <xref target="RFC7285" format="default"/>.
	It also defines an ALTO the "ALTO Entity Property Type
	Registry Types"
	registry that extends the ALTO endpoint property "ALTO Endpoint Property Types" registry defined in
	<xref target="RFC7285" format="default"/>.</t>
	<table anchor="TableMediaTypes" align="center">
          <name>Additional ALTO Media Types.</name> Types</name>
          <thead>
            <tr>
              <th align="left">Type</th>
              <th align="left">Subtype</th>
              <th align="left">Specification</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="left">application</td>
              <td align="left">alto-propmap+json</td>
              <td align="left">
                <xref target="FullPropMapMediaType" format="default"/></td>
            </tr>
            <tr>
              <td align="left">application</td>
              <td align="left">alto-propmapparams+json</td>
              <td align="left">
                <xref target="filter-prop-map-params" format="default"/></td>
            </tr>
          </tbody>
        </table>

      <section anchor="application-alto-propmap-media-type" numbered="true" toc="default">
        <name>application/alto-propmap+json Media Type</name>

        <dl newline="true" spacing="normal">
          <dt>Type name:</dt>
          <dd>application</dd>

          <dt>Subtype name:</dt>
          <dd>alto-propmap+json</dd>

          <dt>Required parameters:</dt>
          <dd>n/a</dd>

          <dt>Optional parameters:</dt>
          <dd>n/a</dd>

          <dt>Encoding considerations:</dt>
          <dd>Encoding considerations are identical to those specified for the
		"application/json" media type. See <xref target="RFC8259" format="default"/>.</dd>

          <dt>Security considerations:</dt>
          <dd>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"/>
		and <xref target="SecSC" format="default"/> of this document.</dd>

          <dt>Interoperability considerations:</dt>
          <dd>n/a</dd>

          <dt>Published specification:</dt>
          <dd>
          This document is the specification for this media type.
          See <xref target="FullPropMapMediaType" format="default"/>.</dd>

          <dt>Applications that use this media type:</dt>

          <dd>ALTO servers and ALTO clients <xref target="RFC7285" format="default"/>,
          either stand alone standalone or embedded within other applications,
          when the queried resource is a property map, whether filtered or not. </dd>

		<dt>Fragment identifier considerations:</dt>
		<dd>n/a</dd>

          <dt>Additional information:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>Magic number(s):</dt>
              <dd>n/a</dd>
              <dt>File extension(s):</dt>
              <dd>n/a</dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>n/a</dd>
            </dl>
          </dd>

          <dt>Person &amp; email address to contact for further information:</dt>
          <dd>See Authors' Addresses section.</dd>

          <dt>Intended usage:</dt>
          <dd>COMMON</dd>

          <dt>Restrictions on usage:</dt>
          <dd>n/a</dd>

          <dt>Author:</dt>
          <dd>See Authors' Addresses section.</dd>

         <dt>Change controller:</dt>
          <dd>Internet Engineering Task Force (mailto:iesg@ietf.org).</dd> (iesg@ietf.org).</dd>
        </dl>
      </section>

	<section anchor="application-alto-propmapparams-media-type" numbered="true" toc="default">
	<name>alto-propmapparams+json Media Type</name>

        <dl newline="true" spacing="normal">
          <dt>Type name:</dt>
          <dd>application</dd>

          <dt>Subtype name:</dt>
          <dd>alto-propmapparams+json</dd>

          <dt>Required parameters:</dt>
          <dd>n/a</dd>

          <dt>Optional parameters:</dt>
          <dd>n/a</dd>

          <dt>Encoding considerations:</dt>
          <dd>Encoding considerations are identical to those specified for the
		"application/json" media type. See <xref target="RFC8259" format="default"/>.</dd>

          <dt>Security considerations:</dt>
          <dd>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"/>
		and <xref target="SecSC" format="default"/> of this document.</dd>

          <dt>Interoperability considerations:</dt>
          <dd>n/a</dd>

          <dt>Published specification:</dt>
          <dd>
          This document is the specification for this media type.
          See <xref target="filter-prop-map-params" format="default"/>.</dd>

          <dt>Applications that use this media type:</dt>
          <dd>ALTO servers and ALTO clients <xref target="RFC7285" format="default"/>,
          either stand alone standalone or embedded within other applications,
          when the queried resource is a filtered property map.
          This media-type media type indicates the data format used by the ALTO client to supply the property map
          filtering parameters.
          </dd>

		<dt>Fragment identifier considerations:</dt>
		<dd>n/a</dd>

          <dt>Additional information:</dt>
          <dd>
            <dl newline="false" spacing="normal">
              <dt>Magic number(s):</dt>
              <dd>n/a</dd>
              <dt>File extension(s):</dt>
              <dd>n/a</dd>
              <dt>Macintosh file type code(s):</dt>
              <dd>n/a</dd>
            </dl>
          </dd>

          <dt>Person &amp; email address to contact for further information:</dt>
          <dd>See Authors' Addresses section.</dd>

          <dt>Intended usage:</dt>
          <dd>COMMON</dd>

          <dt>Restrictions on usage:</dt>
          <dd>n/a</dd>

          <dt>Author:</dt>
          <dd>See Authors' Addresses section.</dd>

         <dt>Change controller:</dt>
          <dd>Internet Engineering Task Force (mailto:iesg@ietf.org).</dd> (iesg@ietf.org).</dd>
        </dl>

	</section>

      <section anchor="IANADomain" numbered="true" toc="default">
        <name>ALTO Entity Domain Type Types Registry</name>
        <t>This document requests IANA to create
        <t>IANA has created and will maintain the "ALTO Entity Domain Type
		Registry", Types"
		registry listed in <xref target="TableEntityDomainNames" format="default"/>.
		The first line row lists information items that must be provided with each
		registered entity domain type.
		<xref target="dom-reg-process" format="default"/> specifies how to document
		these items and in addition provides guidance on the security considerations item that must
		be documented in addition. documented.
		</t>

        <table anchor="TableEntityDomainNames" align="center">
          <name>ALTO Entity Domain Types</name>
          <thead>
            <tr>
              <th align="left">Identifier</th>
              <th align="left">Entity 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">ipv4</td>
              <td align="left">See <xref target="ipv4-domain" format="default"/></td>
              <td align="left">See <xref target="inet-inheritance" format="default"/></td>
              <td align="left">application/alto-networkmap+json</td>
              <td align="left">true</td>
            </tr>
            <tr>
              <td align="left">ipv6</td>
              <td align="left">See <xref target="ipv6-domain" format="default"/></td>
              <td align="left">See <xref target="inet-inheritance" format="default"/></td>
              <td align="left">application/alto-networkmap+json</td>
              <td align="left">true</td>
            </tr>
            <tr>
              <td align="left">pid</td>
              <td align="left">See <xref target="pid-domain" format="default"/></td>
              <td align="left">None</td>
              <td align="left">application/alto-networkmap+json</td>
              <td align="left">false</td>
            </tr>
          </tbody>
        </table>
        <t>This registry serves two purposes. First, it ensures uniqueness of
identifiers referring to ALTO entity domain types. Second, it states the
requirements for allocated entity domain types.</t>
<t>
As specified in <xref target="domain-types" format="default"/>, identifiers prefixed
with "priv:" are reserved for Private Use without a need to register with IANA
</t>
        <section anchor="consistency-procedure" numbered="true" toc="default">
          <name>Consistency Procedure between ALTO Address Type Types Registry and ALTO Entity Domain Type Types Registry</name>
          <t>One potential issue of introducing the "ALTO Entity Domain Type Registry" Types" registry is
its relationship with the "ALTO Address Types Registry" Types" registry already defined in
Section 14.4 of
<xref target="RFC7285" section="14.4" sectionFormat="of" format="default"/>. In particular, the entity identifier of a type
of an entity domain registered in the "ALTO Entity Domain Type Registry" MAY Types" registry <bcp14>MAY</bcp14>
match an address type defined in "ALTO Address Type Registry". Types" registry. It is
necessary to precisely define and guarantee the consistency between "ALTO
Address Type Registry" Types" registry and "ALTO Entity Domain Registry".</t> Types" registry.</t>
          <t>We define that the ALTO "ALTO Entity Domain Type Registry Types" registry is consistent with ALTO "ALTO
Address Type Registry Types" registry if two conditions are satisfied:</t>
          <ul spacing="normal">
            <li>When an address type is already registered or is able to be registered in the ALTO "ALTO Address
Type Registry
Types" registry <xref target="RFC7285" format="default"/>, the same identifier MUST <bcp14>MUST</bcp14> be used when a
corresponding entity domain type is registered in the ALTO "ALTO Entity Domain Type
Registry.</li> Types"
registry.</li>
            <li>If an ALTO entity domain type has the same identifier as an ALTO address type,
their addresses encoding MUST address encodings <bcp14>MUST</bcp14> be compatible.</li>
          </ul>
          <t>To achieve this consistency, the following items MUST <bcp14>MUST</bcp14> be checked before
registering a new ALTO entity domain type in a future document:</t>
          <ul spacing="normal">
            <li>Whether the ALTO "ALTO Address Type Registry Types" registry contains an address type that can be
used as an identifier for the candidate entity domain type identifier. This has been
done for the identifiers "ipv4" and "ipv6" of <xref target="TableEntityDomainNames" format="default"/>.</li>
            <li>Whether the candidate entity domain type identifier can potentially be an
endpoint address type, as defined in Sections 2.1 <xref target="RFC7285" section="2.1" sectionFormat="bare" format="default"/>
and 2.2 <xref target="RFC7285" section="2.2" sectionFormat="bare" format="default"/> of <xref target="RFC7285" format="default"/>.</li>
          </ul>
          <t>When a new ALTO entity domain type is registered, the consistency with the ALTO "ALTO
Address Type Registry MUST Types" registry <bcp14>MUST</bcp14> be ensured by the following procedure:</t>
          <ul spacing="normal">
            <li>
              <t>Test: Do corresponding entity domain type identifiers match a known "network" address type?
              </t>
              <ul spacing="normal">
                <li>
                  <t>If yes (e.g., cell, MAC MAC, or socket addresses):
                  </t>
                  <ul spacing="normal">
                    <li>
                      <t>Test: Is such an address type present in the ALTO "ALTO Address Type
Registry? Types"
registry?
                      </t>
                      <ul spacing="normal">
                        <li>If yes: Set the new ALTO entity domain type identifier to be the
found ALTO address type identifier.</li>
                        <li>If no: Define a new ALTO entity domain type identifier and use it to
register a new address type in the ALTO "ALTO Address Type Registry Types" registry
following Section 14.4 of <xref target="RFC7285" section="14.4" sectionFormat="of" format="default"/>.</li>
                      </ul>
                    </li>
                    <li>Use the new ALTO entity domain type identifier to register a new ALTO
entity domain type in the ALTO "ALTO Entity Domain Type Registry Types" registry following
<xref target="dom-reg-process" format="default"/> of this document.</li>
                  </ul>
                </li>
                <li>If no (e.g., pid PID name, ANE name, ane name or country code): "countrycode"): Proceed with the ALTO
Entity Domain Type registration as described in <xref target="dom-reg-process" format="default"/>.</li>
              </ul>
            </li>
          </ul>
        </section>

        <section anchor="dom-reg-process" numbered="true" toc="default">
          <name>ALTO Entity Domain Type Registration Process</name>
          <t>New ALTO entity domain types are assigned after IETF Review <xref target="RFC8126" format="default"/> to
		ensure that proper documentation regarding the new ALTO entity domain types
		and their security considerations has been provided. RFCs defining new entity
		domain types MUST <bcp14>MUST</bcp14> indicate how an entity in a registered type of domain is
		encoded as an EntityID, EntityID and, if applicable, provide the rules for defining the entity
		hierarchy and property inheritance. Updates and deletions of ALTO entity
		domains types follow the same procedure.
		</t>
          <t>Registered ALTO entity domain type identifiers MUST <bcp14>MUST</bcp14> conform to the
		syntactical requirements specified in <xref target="domain-names" format="default"/>.
		Identifiers are to be recorded and displayed as strings.
		</t>
          <t>Requests to the IANA to add a new value to the "ALTO Entity Domain Type Types" registry
		MUST
		<bcp14>MUST</bcp14> include the following information:</t>
          <ul
          <dl spacing="normal">
            <li>Identifier: The
            <dt>Identifier:</dt>
            <dd>The name of the desired ALTO entity domain type.</li>
            <li>Entity type.</dd>

            <dt>Entity Identifier Encoding: The Encoding:</dt>
            <dd>The procedure for encoding the identifier of an
			entity of the registered domain type as an EntityID (see
			<xref target="entity-addrs" format="default"/>). If corresponding entity identifiers of an entity domain
			type match a known "network" address type, the Entity Identifier Encoding
			of this domain identifier MUST <bcp14>MUST</bcp14> include both Address Encoding and Prefix
			Encoding of the same identifier registered in the ALTO "ALTO Address Type
			Registry Types"
			registry <xref target="RFC7285" format="default"/>. To define properties, an individual entity identifier
			and the corresponding full-length prefix MUST <bcp14>MUST</bcp14> be considered aliases for the
			same entity.</li>
            <li>Hierarchy: If entity.</dd>

            <dt>Hierarchy:</dt>
            <dd>If the entities form a hierarchy, the procedure for determining
			that hierarchy.</li>
            <li>Inheritance: If hierarchy.</dd>

            <dt>Inheritance:</dt>
            <dd>If entities can inherit property values from other entities, the
			procedure for determining that inheritance.</li>
            <li>
              <t>Media inheritance.</dd>

            <dt>Media type of defining information resource: Some resource:</dt>
            <dd>Some entity domain types allow
			an entity domain name to be combined with an information resource name to
			define a resource-specific entity domain. Such an information resource is
			called a "defining information resource", resource" and is
			defined in <xref target="def-ir" format="default"/>.
			For each entity domain type, the potential defining information resources
			have one common media type. This unique common media type is specific to
			the entity domain type and MUST <bcp14>MUST</bcp14> be specified.
              </t>
            </li>
            <li>Mapping </dd>

            <dt>Mapping to ALTO Address Type: A Type:</dt>
            <dd>A boolean value to indicate if the entity domain
			type can be mapped to the ALTO address type with the same identifier.</li>
            <li>Security Considerations: In identifier.</dd>

            <dt>Security Considerations:</dt>
            <dd>In some usage scenarios, entity identifiers carried in
			ALTO Protocol messages may reveal information about an ALTO client or an ALTO
			service provider. Applications and ALTO service providers using addresses of
			the registered type should be cognizant of how (or if) the addressing scheme
			relates to private information and network proximity.</li>
          </ul>
          <t>This specification requests registration of proximity.</dd>
          </dl>
          <t>IANA has registered the identifiers "ipv4", "ipv6" "ipv6", and
		"pid", as shown in <xref target="TableEntityDomainNames" format="default"/>.</t>
        </section>
      </section>

      <section anchor="IANAEntityProp" numbered="true" toc="default">
        <name>ALTO Entity Property Type Types Registry</name>
        <t>This document requests IANA to create
        <t>IANA has created and will maintain the "ALTO Entity Property
		Type Registry",
		Types" registry, which is listed in <xref target="TablePropertyTypes" format="default"/>.
		</t>
        <t>This registry extends the "ALTO Endpoint Property Type Registry", Types" registry, defined in
		<xref target="RFC7285" format="default"/>, in that a property type is defined on for
		one or more entity domains, rather than just on for IPv4 and IPv6 Internet address domains.
		An entry in this registry is an ALTO entity property type defined in
		<xref target="def-property-type" format="default"/>.
		Thus, a registered ALTO entity property type identifier MUST <bcp14>MUST</bcp14> conform to
		the syntactical requirements specified in that section.
		</t>
		<t>As specified in <xref target="def-property-type" format="default"/>,
		identifiers prefixed with "priv:" are
		reserved for Private Use without a need to register with IANA.
		</t>
		<t>The first line row of <xref target="TablePropertyTypes" format="default"/> lists
	   information items that must be provided with each registered entity property type.
		</t>
        <table anchor="TablePropertyTypes" align="center">
          <name>ALTO Entity Property Types.</name> Types</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">pid</td>
              <td align="left">See Section 7.1.1 of <xref target="RFC7285" section="7.1.1" sectionFormat="of" format="default"/></td>
              <td align="left">application/alto-networkmap+json</td>
            </tr>
          </tbody>
        </table>
        <t>New ALTO entity property types are assigned after
		IETF Review <xref target="RFC8126" format="default"/>
		to ensure that proper documentation regarding the new ALTO entity
		property types and their security considerations has been provided.
		RFCs defining new entity property types SHOULD <bcp14>SHOULD</bcp14> indicate how a property
		of a registered type is encoded as a property name.
		Updates and deletions of ALTO entity property types follow the same procedure.
        </t>
        <t>Requests to the IANA to add a new value to the registry MUST <bcp14>MUST</bcp14> include the
following information:</t>
        <ul
        <dl spacing="normal">
          <li>Identifier: The
          <dt>Identifier:</dt>
          <dd>The identifier for the desired ALTO entity property type. The
format MUST <bcp14>MUST</bcp14> be as defined in <xref target="def-property-type" format="default"/> of this document.
</li>
          <li>Intended Semantics: ALTO
</dd>

          <dt>Intended Semantics:</dt>
          <dd>ALTO entity properties carry with them semantics to guide
their usage by ALTO clients. Hence, a document defining a new type SHOULD <bcp14>SHOULD</bcp14>
provide guidance to both ALTO service providers and applications utilizing
ALTO clients as to how values of the registered ALTO entity property should
be interpreted.</li>

          <li>Media interpreted.</dd>

          <dt>Media type of defining information resource: when resource:</dt>
          <dd>when the property type allows
		values to be defined relative to a given information resource, the latter
		is referred to as the "defining information resource", resource"; see the description
		in <xref target="def-ir-for-irsp" format="default"/>.
		For each property type, the potential defining information resources have
		one common media type. This unique common media type is specific to the
		property type and MUST <bcp14>MUST</bcp14> be specified.
		</li>

          <li>Security Considerations: ALTO
		</dd>

          <dt>Security Considerations:</dt>
          <dd>ALTO entity properties expose information to ALTO
clients. ALTO service providers should be cognizant of the security
ramifications related to the exposure of an entity property.</li>
        </ul> property.</dd>
        </dl>
        <t>In security considerations, the request should also discuss the sensitivity
of the information, information and why it is required for ALTO-based operations.
Regarding this discussion, the request SHOULD <bcp14>SHOULD</bcp14> follow the recommendations of
Section 14.3. ALTO
the "ALTO Endpoint Property Type Registry Types" registry in <xref target="RFC7285" section="14.3" sectionFormat="of" format="default"/>.</t>
        <t>This document requests registration of
        <t>IANA has registered the identifier "pid", which is listed in
<xref target="TablePropertyTypes" format="default"/>. Semantics for this property are documented in
Section 7.1.1 of
<xref target="RFC7285" section="7.1.1" sectionFormat="of" format="default"/>. No security issues related to the exposure of a
"pid" identifier are considered, as it is exposed with the Network Map
Service defined and mandated in <xref target="RFC7285" format="default"/>.</t>
      </section>
    </section>
    <section anchor="ack" numbered="true" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank Dawn Chen, and Shenshen
Chen for their contributions to earlier drafts.
Thank you also to Qiao Xiang, Shawn Lin, Xin Wang and Vijay
Gurbani for fruitful discussions. Last, big thanks to Danny
Perez and Luis Contreras for their
substantial Working Group review feedback and suggestions to improve this document,
to Vijay Gurbani, ALTO WG Chair and Martin Duke, Transport Area Director,
for their thorough review, discussions, guidance and shepherding, that further helped to
enrich this document.</t>
    </section>
  </middle>
  <back>

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

    <references>
      <name>References</name>

      <references>
        <name>Normative References</name>

        <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
            <author>
              <organization>International Organization for Standardization)" fullname="ISO (International Organization for Standardization)">
              <organization/> Standardization</organization>
            </author>
            <date month="August" year="2020"/>
          </front>
        </reference>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <seriesInfo name="DOI" value="10.17487/RFC2119"/>
            <seriesInfo name="RFC" value="2119"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization/>
            </author>
            <date year="1997" month="March"/>
            <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>
        </reference>

		<reference anchor="RFC4291">
		        <front>
		          <title>IP Version 6 Addressing Architecture</title>
		          <author fullname="R. Hinden" initials="R." surname="Hinden"/>
		          <author fullname="S. Deering" initials="S." surname="Deering"/>
		          <date month="February" year="2006"/>
		        </front>
		</reference>

        <reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3986">
          <front>
            <title>Uniform Resource Identifier (URI): Generic Syntax</title>
            <seriesInfo name="DOI" value="10.17487/RFC3986"/>
            <seriesInfo name="RFC" value="3986"/>
            <seriesInfo name="STD" value="66"/>
            <author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee">
              <organization/>
            </author>
            <author initials="R." surname="Fielding" fullname="R. Fielding">
              <organization/>
            </author>
            <author initials="L." surname="Masinter" fullname="L. Masinter">
              <organization/>
            </author>
            <date year="2005" month="January"/>
            <abstract>
              <t>A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource.  This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet.  The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier.  This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC4632" target="https://www.rfc-editor.org/info/rfc4632">
          <front>
            <title>Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan</title>
            <seriesInfo name="DOI" value="10.17487/RFC4632"/>
            <seriesInfo name="RFC" value="4632"/>
          <seriesInfo name="BCP" value="122"/>
            <author initials="V." surname="Fuller" fullname="V. Fuller">
              <organization/>
            </author>
            <author initials="T." surname="Li" fullname="T. Li">
              <organization/>
            </author>
            <date year="2006" month="August"/>
            <abstract>
              <t>This memo discusses the strategy for address assignment of the existing 32-bit IPv4 address space with a view toward conserving the address space and limiting the growth rate of global routing state. This document obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with changes made both to clarify the concepts it introduced and, after more than twelve years, to update the Internet community on the results of deploying the technology described.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC5952" target="https://www.rfc-editor.org/info/rfc5952">
          <front>
            <title>A Recommendation for IPv6 Address Text Representation</title>
            <seriesInfo name="DOI" value="10.17487/RFC5952"/>
            <seriesInfo name="RFC" value="5952"/>
            <author initials="S." surname="Kawamura" fullname="S. Kawamura">
              <organization/>
            </author>
            <author initials="M." surname="Kawashima" fullname="M. Kawashima">
              <organization/>
            </author>
            <date year="2010" month="August"/>
            <abstract>
              <t>As IPv6 deployment increases, there will be a dramatic increase in the need to use IPv6 addresses in text.  While the IPv6 address architecture in Section 2.2 of RFC 4291 describes a flexible model for text representation of an IPv6 address, this flexibility has been causing problems for operators, system engineers, and users.  This document defines a canonical textual representation format.  It does not define a format for internal storage, such as within an application or database.  It is expected that the canonical format will be followed by humans and systems when representing IPv6 addresses as text, but all implementations must accept and be able to handle any legitimate RFC 4291 format.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC7285" target="https://www.rfc-editor.org/info/rfc7285">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Protocol</title>
            <seriesInfo name="DOI" value="10.17487/RFC7285"/>
            <seriesInfo name="RFC" value="7285"/>
            <author initials="R." surname="Alimi" fullname="R. Alimi" role="editor">
              <organization/>
            </author>
            <author initials="R." surname="Penno" fullname="R. Penno" role="editor">
              <organization/>
            </author>
            <author initials="Y." surname="Yang" fullname="Y. Yang" role="editor">
              <organization/>
            </author>
            <author initials="S." surname="Kiesel" fullname="S. Kiesel">
              <organization/>
            </author>
            <author initials="S." surname="Previdi" fullname="S. Previdi">
              <organization/>
            </author>
            <author initials="W." surname="Roome" fullname="W. Roome">
              <organization/>
            </author>
            <author initials="S." surname="Shalunov" fullname="S. Shalunov">
              <organization/>
            </author>
            <author initials="R." surname="Woundy" fullname="R. Woundy">
              <organization/>
            </author>
            <date year="2014" month="September"/>
            <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>
        </reference>
        <reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8126">
          <front>
            <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
            <seriesInfo name="DOI" value="10.17487/RFC8126"/>
            <seriesInfo name="RFC" value="8126"/>
            <seriesInfo name="BCP" value="26"/>
            <author initials="M." surname="Cotton" fullname="M. Cotton">
              <organization/>
            </author>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <author initials="T." surname="Narten" fullname="T. Narten">
              <organization/>
            </author>
            <date year="2017" month="June"/>
            <abstract>
              <t>Many protocols make use of points of extensibility that use constants to identify various protocol parameters.  To ensure that the values in these fields do not have conflicting uses and to promote interoperability, their allocations are often coordinated by a central record keeper.  For IETF protocols, that role is filled by the Internet Assigned Numbers Authority (IANA).</t>
              <t>To make assignments in a given registry prudently, guidance describing the conditions under which new values should be assigned, as well as when and how modifications to existing values can be made, is needed.  This document defines a framework for the documentation of these guidelines by specification authors, in order to assure that the provided guidance for the IANA Considerations is clear and addresses the various issues that are likely in the operation of a registry.</t>
              <t>This is the third edition of this document; it obsoletes RFC 5226.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <seriesInfo name="DOI" value="10.17487/RFC8174"/>
            <seriesInfo name="RFC" value="8174"/>
            <seriesInfo name="BCP" value="14"/>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization/>
            </author>
            <date year="2017" month="May"/>
            <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>
        </reference>
        <reference anchor="RFC8259" target="https://www.rfc-editor.org/info/rfc8259">
          <front>
            <title>The JavaScript Object Notation (JSON) Data Interchange Format</title>
            <seriesInfo name="DOI" value="10.17487/RFC8259"/>
            <seriesInfo name="RFC" value="8259"/>
            <seriesInfo name="STD" value="90"/>
            <author initials="T." surname="Bray" fullname="T. Bray" role="editor">
              <organization/>
            </author>
            <date year="2017" month="December"/>
            <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>
        </reference>
        <reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8446">
          <front>
            <title>The Transport Layer Security (TLS) Protocol Version 1.3</title>
            <seriesInfo name="DOI" value="10.17487/RFC8446"/>
            <seriesInfo name="RFC" value="8446"/>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization/>
            </author>
            <date year="2018" month="August"/>
            <abstract>
              <t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.
              TLS allows client/server applications to communicate over the Internet in a way that
              is designed to prevent eavesdropping, tampering, and message forgery.</t>
              <t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 5077, 5246, and 6961.
              This document also specifies new requirements for TLS 1.2 implementations.</t>
            </abstract>
          </front>
        </reference>
        <reference anchor="RFC8895" target="https://www.rfc-editor.org/info/rfc8895">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events (SSE)</title>
            <seriesInfo name="DOI" value="10.17487/RFC8895"/>
            <seriesInfo name="RFC" value="8895"/>
            <author initials="W." surname="Roome" fullname="W. Roome">
              <organization/>
            </author>
            <author initials="Y." surname="Yang" fullname="Y. Yang">
              <organization/>
            </author>
            <date year="2020" month="November"/>
            <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> name="ISO" value="3166-1:2020"/>
        </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.4291.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4632.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5952.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.8126.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.8259.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8895.xml"/>

      </references>

      <references>
        <name>Informative References</name>

        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3849.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5737.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5511.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7921.xml"/>
        <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8896.xml"/>

        <reference anchor="RFC3849">
	        <front>
	          <title>IPv6 Address Prefix Reserved for Documentation</title>
	          <author fullname="G. Huston" initials="G." surname="Huston"/>
	          <author fullname="A. Lord" initials="A." surname="Lord"/>
	          <author fullname="P. Smith" initials="P." surname="Smith"/>
	          <date month="July" year="2004"/>
	        </front>
	   </reference>

        <reference anchor="RFC5737">
	        <front>
	          <title>IPv4 Address Blocks Reserved for Documentation</title>
	          <author fullname="J. Arkko" initials="J." surname="Arkko"/>
	          <author fullname="M. Cotton" initials="M." surname="Cotton"/>
	          <author fullname="L. Vegoda" initials="L." surname="Vegoda"/>
	          <date month="January" year="2010"/>
	        </front>
	  </reference>

	  <reference anchor="RFC5511">
        <front>
          <title>Routing Backus-Naur Form (RBNF): A Syntax Used to Form
		Encoding Rules in Various Routing Protocol Specifications</title>
          <author fullname="A. Farrel" initials="A." surname="Farrel"/>
          <date month="April" year="2009"/>
        </front>
	  </reference>

        <!-- commented text <reference anchor="RFC7011" target="https://www.rfc-editor.org/info/rfc7011">
          <front>
            <title>Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of Flow Information</title>
            <seriesInfo name="DOI" value="10.17487/RFC7011"/>
            <seriesInfo name="RFC" value="7011"/>
            <seriesInfo name="STD" value="77"/>
            <author initials="B." surname="Claise" fullname="B. Claise" role="editor">
              <organization/>
            </author>
            <author initials="B." surname="Trammell" fullname="B. Trammell" role="editor">
              <organization/>
            </author>
            <author initials="P." surname="Aitken" fullname="P. Aitken">
              <organization/>
            </author>
            <date year="2013" month="September"/>
            <abstract>
              <t>This document specifies the IP Flow Information Export (IPFIX) protocol, which serves as a means for transmitting Traffic Flow information over the network.  In order to transmit Traffic Flow information from an Exporting Process to a Collecting Process, a common representation of flow data and a standard means of communicating them are required.  This document describes how the IPFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process.  This document obsoletes RFC 5101.</t>
            </abstract>
          </front>
        </reference> -->

        <reference anchor="RFC7921" target="https://www.rfc-editor.org/info/rfc7921">
          <front>
            <title>An Architecture for the Interface to the Routing System</title>
            <seriesInfo name="DOI" value="10.17487/RFC7921"/>
            <seriesInfo name="RFC" value="7921"/>
            <author initials="A." surname="Atlas" fullname="A. Atlas">
              <organization/>
            </author>
            <author initials="J." surname="Halpern" fullname="J. Halpern">
              <organization/>
            </author>
            <author initials="S." surname="Hares" fullname="S. Hares">
              <organization/>
            </author>
            <author initials="D." surname="Ward" fullname="D. Ward">
              <organization/>
            </author>
            <author initials="T." surname="Nadeau" fullname="T. Nadeau">
              <organization/>
            </author>
            <date year="2016" month="June"/>
            <abstract>
              <t>This document describes the IETF architecture for a standard, programmatic interface for state transfer in and out of the Internet routing system.  It describes the high-level architecture, the building blocks of this high-level architecture, and their interfaces, with particular focus on those to be standardized as part of the Interface to the Routing System (I2RS).</t>
            </abstract>
          </front>
        </reference>

        <reference anchor="RFC8896" target="https://www.rfc-editor.org/info/rfc8896">
          <front>
            <title>Application-Layer Traffic Optimization (ALTO) Cost Calendar</title>
            <seriesInfo name="DOI" value="10.17487/RFC8896"/>
            <seriesInfo name="RFC" value="8896"/>
            <author initials="S." surname="Randriamasy" fullname="S. Randriamasy">
              <organization/>
            </author>
            <author initials="R." surname="Yang" fullname="R. Yang">
              <organization/>
            </author>
            <author initials="Q." surname="Wu" fullname="Q. Wu">
              <organization/>
            </author>
            <author initials="L." surname="Deng" fullname="L. Deng">
              <organization/>
            </author>
            <author initials="N." surname="Schwan" fullname="N. Schwan">
              <organization/>
            </author>
            <date year="2020" month="November"/>
            <abstract>
              <t>This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol.  It extends the ALTO cost information service so that applications decide not only 'where' to connect but also 'when'.  This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example.  This extension introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval.  The time intervals, as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.</t>
            </abstract>
          </front>
        </reference>
        <!-- commented text
        <reference anchor="I-D.gao-alto-fcs" target="http://www.ietf.org/internet-drafts/draft-gao-alto-fcs-07.txt">
          <front>
            <title>ALTO Extension: Flow-based Cost Query</title>
            <seriesInfo name="Internet-Draft" value="draft-gao-alto-fcs-07"/>
            <author initials="J" surname="Zhang" fullname="J. Zhang">
              <organization/>
            </author>
            <author initials="K" surname="Gao" fullname="Kai Gao">
              <organization/>
            </author>
            <author initials="J" surname="Wang" fullname="Junzhuo Wang">
              <organization/>
            </author>
            <author initials="Y" surname="Yang" fullname="Y. Yang">
              <organization/>
            </author>
            <date month="March" day="16" year="2020"/>
            <abstract>
              <t>ALTO cost maps and endpoint cost services map a source-destination pair into a cost value.  However, current filter specifications, which define the set of source-destination pairs in an ALTO query, have two limitations: 1) Only very limited address types are supported (IPv4 and IPv6), which is not sufficient to uniquely identify a flow in networks with fine-grained routing, such as the emerging Software Defined Networks; 2) The base ALTO protocol only defines filters enumerating all sources and all destinations, leading to redundant information in the response; 3) Cannot distinguish transmission types of flows in the query, which makes the server hard to respond the accurate resource consumption.  To address these three issues, this document extends the base ALTO protocol with a more fine-grained filter type which allows ALTO clients to select only the concerned source-destination pairs and announce the flow-specific information like data transmission type, and a more expressive address space which allows ALTO clients to make queries beyond the limited IP addresses.</t>
            </abstract>
          </front>
        </reference> -->

        <reference anchor="I-D.ietf-alto-cdni-request-routing-alto" target="http://www.ietf.org/internet-drafts/draft-ietf-alto-cdni-request-routing-alto-16.txt"> anchor="RFC9241" target="https://www.rfc-editor.org/info/rfc9241">
          <front>
            <title>Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO</title>
            <seriesInfo name="Internet-Draft" value="draft-ietf-alto-cdni-request-routing-alto-16"/> Using Application-Layer Traffic Optimization (ALTO)</title>
            <author initials="J" surname="Seedorf" fullname="Jan Seedorf">
              <organization/>
            </author>
            <author initials="Y" surname="Yang" fullname="Y. Yang">
              <organization/>
            </author>
            <author initials="K" surname="Ma" fullname="Kevin Ma">
              <organization/>
            </author>
            <author initials="J" surname="Peterson" fullname="Jon Peterson">
              <organization/>
            </author>
            <author initials="J" surname="Zhang" fullname="Jingxuan Zhang">
              <organization/>
            </author>
            <date month="January" day="12" year="2021"/>
            <abstract>
              <t>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 an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol, following the guidelines defined in RFC 8008.</t>
            </abstract> year="2022" month="July"/>
          </front>
        </reference>
        <reference anchor="I-D.ietf-alto-path-vector" target="http://www.ietf.org/internet-drafts/draft-ietf-alto-path-vector-13.txt">
          <front>
            <title>ALTO Extension: Path Vector</title>
          <seriesInfo name="Internet-Draft" value="draft-ietf-alto-path-vector-13"/>
            <author initials="K" surname="Gao" fullname="Kai Gao">
              <organization/>
            </author>
            <author initials="Y" surname="Lee" fullname="Young Lee">
              <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="J. Zhang">
              <organization/>
            </author>
            <date month="November" day="20" year="2020"/>
            <abstract>
              <t>This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol.  It extends the ALTO Cost Map service and ALTO Property Map service so that the 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> name="RFC" value="9241"/>
          <seriesInfo name="DOI" value="10.17487/RFC9241"/>
        </reference>

        <xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-alto-path-vector.xml"/>

      </references>
    </references>

    <section anchor="features-introduced-with-epm-extension" numbered="true" toc="default">
      <name>Features introduced Introduced with the Entity Property Maps extension</name> Extension</name>
      <t>The Entity Property Maps entity property maps extension described in this document introduces a
number of features that are summarized in table below. The first column
provides the name of the feature. The second column provides the section
number of this document that gives a high level high-level description of the feature.
The third column provides the section number of this document that gives a
normative description relating to the feature, when applicable.</t>
      <table anchor="TableUPFeatures" align="center">
        <name>Features introduced Introduced with ALTO Entity Property Maps</name>
        <thead>
          <tr>
            <th align="left">Feature</th>
            <th align="left">High-level description</th> align="left">High-Level Description</th>
            <th align="left">Related normative description</th> Normative Description</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left">Entity</td>
            <td align="left">
              <xref target="con-entity" format="default"/></td>
            <td align="left">
              <xref target="entity-addrs" format="default"/></td>
          </tr>
          <tr>
            <td align="left">Entity domain (ED)</td> domain</td>
            <td align="left">
              <xref target="con-entity-domain" format="default"/></td>
            <td align="left">&nbsp;</td> align="left"></td>
          </tr>
          <tr>
            <td align="left">Entity domain type</td>
            <td align="left">
              <xref target="con-entity-domain-type" format="default"/></td>
            <td align="left">
              <xref target="domain-types" format="default"/></td>
          </tr>
          <tr>
            <td align="left">Entity domain name</td>
            <td align="left">
              <xref target="con-entity-domain-name" format="default"/></td>
            <td align="left">
              <xref target="domain-names" format="default"/></td>
          </tr>
          <tr>
            <td align="left">Entity property (EP) type</td>
            <td align="left">
              <xref target="con-property" format="default"/></td>
            <td align="left">
              Sections <xref target="def-property" format="default"/>, format="counter"/>, <xref target="def-property-type" format="default"/>, format="counter"/>, <xref target="entity-property-name" format="default"/>, format="counter"/>, and <xref target="format-entity-property-value" format="default"/></td> format="counter"/></td>
          </tr>
          <tr>
            <td align="left">Entity property map</td>
            <td align="left">
              <xref target="con-propmap" format="default"/></td>
            <td align="left">
              Sections <xref target="prop-map" format="default"/>, format="counter"/> and <xref target="filter-prop-map" format="default"/></td> format="counter"/></td>
          </tr>
          <tr>
            <td align="left">Resource-specific ED entity domain name</td>
            <td align="left">
              <xref target="rsed-name" format="default"/></td>
            <td align="left">
              Sections <xref target="domain-names" format="default"/>, format="counter"/> and <xref target="resource-specific-ED" format="default"/></td> format="counter"/></td>
          </tr>
          <tr>
            <td align="left">Resource-specific EP entity property value</td>
            <td align="left">
              <xref target="rsep" format="default"/></td>
            <td align="left">
              <xref target="format-entity-property-value" format="default"/></td>
          </tr>
          <tr>
            <td align="left">Entity Hierarchy and property inheritance</td>
            <td align="left">
              <xref target="con-hni" format="default"/></td>
            <td align="left">
              <xref target="def-hierarchy-and-inheritance" format="default"/></td>
          </tr>
          <tr>
            <td align="left">Defining information resource</td>
            <td align="left">
              Sections <xref target="def-ir" format="default"/>, format="counter"/> and <xref target="def-ir-for-irsp" format="default"/></td> format="counter"/></td>
            <td align="left">
              Sections <xref target="dom-reg-process" format="default"/>, format="counter"/> and <xref target="IANAEntityProp" format="default"/></td> format="counter"/></td>
          </tr>
        </tbody>
      </table>
    </section>
    <section anchor="ack" numbered="false" toc="default">
      <name>Acknowledgments</name>
      <t>The authors would like to thank <contact fullname="Dawn Chen"/> and <contact fullname="Shenshen Chen"/> for their contributions to earlier drafts.
Thank you also to <contact fullname="Qiao Xiang"/>, <contact fullname="Shawn Lin"/>, and <contact fullname="Xin Wang"/>
for fruitful discussions. Last, big thanks to <contact fullname="Danny Perez"/> and <contact fullname="Luis Contreras"/> for their
substantial working group review feedback and suggestions for improving this document,
to <contact fullname="Vijay Gurbani"/>, ALTO WG Chair, and <contact fullname="Martin Duke"/>, Transport Area Director,
for their thorough review, discussions, guidance, and shepherding, which further helped to
enrich this document.</t>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAJOmdWAAA+29aXcbR5Yg+j1/RT74nGexGoC5iZLoqZmiJbnMalnSiHQt
092nnQCSZJZAJDoTII2y1b/93TXiRmQkQKr8uuZDq7otCMiM5caNuy+j0Sib
1dNFcVue5rOmuFqNqnJ1NSrmq3q0XlRXVTkbLZt62Y4W5f3o4Fm2qlZzeHZw
9ubyXf76p1W5aKt6cZq/XsAvm/w9PFs28OH7YtkOsmIyaco7eDz987RYldd1
sznN29Usy6plc5qvmnW7Otzff7F/mBVNWZzmb8vVfd18bDP873VTr5enOU3/
p99nH8sNfDvjL7KsXRWL2b8X83oBa9yUbbasTrM8X9VT/id9rG+XxXRlvpiV
y9XNaX4E/4IlLOoV7fs0X9TwTVs3q6a8avX5dnNr/xmN1q4n7ht4PSvWq5u6
wTWM4P9h/AW8+adx/qGub0v6hmH/p3Ix25hv6+YaNl5/rIr8m3I+z98UkzZ/
8qFcVU0526NHFLbRU/RbC0suYQkHh8f5N+tmXi2uV/Ui/zCjX6dwFKf59+um
KTb5d9V8Tt825TWd5Ns/8EP1DNa1/+zFs2P593qxwqP64eKMvljeEJT/6WD0
Yv/56PjkeHTy4tlT+qm8Lar5aX6Pm/rd/azBbY0BLiEYLgAMcFxNVdwW7cYA
46KYVIuy82MKJsFuP9TrVZnPyvyPsKfyr4BHZrtv3/2fs7+Ynb04OD7ZD3f2
7Yezty9f2x3wSsZmJb9b4AJGE1jAaA4L6G7rL+P8L8Xi2uwHvvlQTW+KZuZ/
oc38pZiX+Q+L6q5sWlhksJmnB3hb2mU5XeUX9J3dTHmff1fclQuzoZeX+f7J
04ODXad1uH80Oj46HJ0c7+/bvW6aze+m7XgDaxqXs3W4qT+M8/9zE+7qD4BU
P62LRf4HoAHlwvxOe7usF9d/rfp2d/x8fz9/WdRfni3y7+43ZmsXOMxNUZmd
He4fPN+PsPDlTbUo7PL/KssZL8Z/wyF+d43fd4/nn8f574va7OOfi8p9Qyu/
gLPCffUs/W09hlt1Abh2k1/A6cClyQ+G+V8qeulDXdhL9vKmXFwTMHUzJwf7
+/v7Ozbzsaiui/p37XSNRzGeLrJsUTe3xQpWhMTk/OLd0cHJyejglN5Sogxf
5/J9/hJma/OruslXNyVc7mVTwimtClpvfUWbb/EDr6KCfwCW48NVg2RsVt1V
SNrbfDTK3xfNKqdBacW0FaDfRIYchcM/IwEqLeXJ+WJVNguaspjn75rrYlH9
jVeAC7tAag23Qr7bG8ggclJ/xxgzYCyIN4cI6A/fvjw8OHhxyh+PXjw/kY/H
J0eH8vHp4bF++/TFU/322eHzp/Lx+cHhifv47Fg/Hj7VcZ8f4wjV4sqeE46x
f3CgH18c6sfnz1889R9p5PPRqzEcOvPeq2mr33mGPJ0tqlFT/se6bFcj4IMr
QHn6pfvosljdjO4AO/FoshEcIdCqVQN8Kcuyy5uqzYHtr28BIfISmfisJTSZ
FG2Zny2X82pK4By9KTZlk1+CZHBVTfN3y1V1q9B/gix3LwMihTx1nk82+XW5
KJtiXv0NFkbjTevFFJgrotkAJlnWFUy4ZCEAMG6QF4B1OF0JmFdn+kiL38/K
K6C9Mxz3/H1ezGaAwC1g6arO/XPmoSK/r2aw2LbE+bJ68lfYfjvOv103sJRm
iAuC3fnZcxAvcrkWMARMeQtSyTBvYY/zosGJ4JVsweIH3Y5p3a7oKcBQAzAU
RpYCh3F+eVO6f+UAaQYwzFAtMhgK3v8rIO4MODkRD1xi1bSrYX7V1Ldmb7Ay
uJfTFcEmhgHACm497mJaA5VCgCsAcKElS2YT4C8Mj1zg8TX8G05lxrNlBhpw
pMhtKjxovwiCNkod9BdIbksV4RAMtNm2zEoVBBEwq6aeraclLreSa3tVFqt1
gyCfz+t7XKxbPq5Wx8zuivmaj3hS+tXAP4v8Gq7UInf3C1YL49XrZlriIgDM
FZ4fMP9l3dLGM8IJQkkYA6e5mpc/EUiAeFXXRAVlU3YR+WqzLNsx35rbajaD
obLsi/xcNoZz4x2Kzj3/+WehGJ8+eSC0nWsQYP9qVUxvylkGO/T3wx3zYEgL
YxznkV7rQ06Sviibuwqg/eT1+4s9RAwCMa9tChdLDrEpkcbflTBKHdyCcf6n
mwpgsm7Lq/V8yLO8v4Cp20xvFyC72d0wv8Fru8rnZQHXYXUDfDGfw6Vh5oKg
E4SWsfjUW3v1+ISLtq2nVYEYfl8BO60X843FvZtihTpADmi9YKEcL3q1QN40
WwNeAXe/BTWFiZW5H/PqYwk35u6YAAgfTjL34zg/XyGygG7RAnIiPtBNrxYf
aUYYFKRHvpqMIrKeACSwjpfnrz60DBjkJHDscK3fn7+CB29BsC7mbQ2QuguB
LdTotm7KYQYUACkwnRXAP58WuPj2Bs6PVmJv55W/Mu16eoPkSinTFUI34xMC
bgMLwV0Lg8jLeXlLWMAPAA/CBwCqtEA+9nF+gWPy/PBbptxBDz9mTp8+MZ2b
ghKBW8BThmUDgjUMW0O6MnNghsIjOS0WoG0RJjgmIAiqmwVkuhCCpdhEWCIo
5ccLceR6Xk9i/LAo8B2vFS9YHl88Oj1cUz6vpzCIp7x4wAWMs9hMEfPND3Rc
+J7sh+eHdcLswK/H+ZkjhvONzIqUJ9OzLBBzaARCGXjAbajh0QGsOHhn5Ev+
EQbNWpC9aBzzrmwGzpmO8nY9X1VLwHlFHuZ590QD4PcSCFJmfkOww8zRoJ45
FMDIrq5KQgLhNAbM39YN8IbiFiYc0hiD282ymh3sD3RdhsQMYFqY8WBAuCH/
Ohy4tWW4tjxYmx+OuGC7fTkk+TQGk6qWkUkXwefw7uJydAsCLgxApHWcvxQ6
egsqZS4CWLa6CYSJK8INYLwoPFVu9i5VH+ffoAANHAJwaJhZtqGUvsh//1rW
oBKH43YIDgAD0PN1syCGmhd3oDQgIcvwaZRg8FyY+OMdAyYI8+dwz+e6LHow
R7Y0VLF/gbuZIjLjj9m8rj+uQdBBwgyUJIdNNxuV64hiIXjKZhwwvlldMpry
VhAnRZoSYBKcEqIg3JBVfsVso6ANG+BZMeW2ur5B6Ja3eXW7RIkWrjfwrUk5
LZCGVkjA1/MZnRPLLUDJmmIla88cnydhg9cD+9g4wcFNa8hEhdChuQBgFd63
7AYWQtcQmQ18iCn2fQXgNhjuJ4pxYpwxR7pFWoCcIe8ZMrozOCITQ1TYRO7t
Ipw7YSdROSXQjL0m0g9M9Pq6Ka+ZYEZaI153Ei4cSOuFF76WoCNW0zWcNa68
AdBWV/kESOjHNr0u5vkFEeka4Qvb+il/Uo6vx4gDyF73mBrS2pG20ZFldNWc
vDZm2yPuAU6pRu4KaAh69IIBRiC/R4MRL143CGJXtD8EE9wDQNKJQxvEByAL
+D7Sj9pQ/LIr+gi1dLqVAJyutAqKXlimA6TDJPEdeTZLafhPFS7lfECL+w1x
XLojZk4EvYJUxCOWPVklEPmXLJUshMJtmcOTbMAlJjQUmuLUN8YEf2KwMoSk
AxeMRvwKj0npsYgZ+NUUgQ1nwZ8QI/Qp4nyqiZZoKIlet4qfEzySai3KoYj/
eN4Z2rc2LRIC/G5eX/NHVnlgoLt6fscj+gWv6mUNTyL+IF8RTaBCk2K1mM7X
M33By4MKO9iEAV/+irANZKgKcYe4FJmj8/ABHVaYTg3kEVUNK9oN+e3wNaTg
EzQLT+cgMDsRhxAweh8XXK3Ggiqs6W3DlXWLWKKsZaT0AeYScMhFAurcfSp8
hlgaXTq3GJLfc5I1HYeF9RhJjSgADExWTqPmEXSNrpflbnpFVrgaIFOiNDyt
l7ALEjZyJ2w4CStaXkU2SpTSERhbloLgNbIGQpYnZjMCjYCScq57G+dvgGrf
V+322TtCpaPrfqgEXPgtsyA95BWKNNvO2BEYtD0synvWbxFrBElTOnV7Gvhq
hjAKrH/OV+Jf/u3JF0iZRrCMPTrSb6v5CoQuvNDbX7uiB0fubdYicH5WHLzk
Y46c+aBKPEbuEh4uwtd8HtwDvF/wNfLTDj4zS8T5QCCvr+u1yLL2wInJOPGr
Qhw0kg4vfA4avC7cy4396/bLRV9RuWojJkymG92DCJr+trNE1107ebFQwJNT
6G7D/aL7GbMFwxkvPE8y1DfkZTjj+ho/IlMckw9ClBhBckYsJlcBKqP82JRo
Txb5MRRE/JRZMCVSVBIeUWVCzOXVI4+cMqwWtIaOMKkk0+xF5QIeuU0vy4Ej
WF+PGQRA+MUX+SXo8tWCGElsWCWJakXorVYvOIRbXjl77yovNgCmiMSYXbGN
IDyK0oCFLTbR8YQmJ7G4ZYOE2W5AIizNhhLzBGDD3ARW5wxU/CSrYnLM4S9k
VLoqxU4KS5EpxySpNMWiLYhpnhLvIFT+Ckka7BeY5E9TdNKgpLW6L8uFY6ms
ajGI5KsL1jNgVP7xFPYPb5BGqyJksQTyN88HLwcigtFeaH18tYPhcSweddtY
FzvG8ut6/f572OUiOFRRdDrAx+e/7Xve3dP4DdBW02/0GgQRPfMPrAMxyr8B
gK+L65Kv/scSpOK6mbX54PsfLi5hr/R3/vYdff7w+n//cP7h9Sv8fPHd2Zs3
7oM+cfHdux/ewO+ZfPJvvnz3/fev377il+HbPPrq+7O/iGlz8O795fm7t2dv
BkpvnOWJxAY2E1boAgLRU6z0wPSnTTXhi/HNy/f5wTHfS/TygA5Kn9FJ8+lT
dg+ny1ORzMX/BFzfoMWpBMEUJTy4B3LoZOMjA9wCNAHAZUYPVBsZVv4tuNGA
+2gx0wGT6yWkYqfaAq9HMc/mcg5AyQpkzC0d1TcFyK/5t2ooB77A9t5O3ISP
ush//mKCb43UvD6qr0bwVhC5ga+NHHn/JESqFYEWxS1kXqjMjuagnoLUfIcI
BIRVlkBTeAu+EaYzKwQHoR1kYwVhdX0r5KgpixkzyqsCSHoFMFTIsBiSMqOL
K2XdLNEiSMtRd0orko5TSUHAuivRPhG5NFQHIALLnhiV3a0lEg/PKEbZayeQ
6y1WGw8gR7MS9mmAIsTX883WqQwLZ39D3CJ/JQaoeOtCBu+09a3Yf9VR5QZH
6XBWLktCYqNmpwW3jPki21IjPhzJt7cAYKHdMPgwQwGtmN0VoMXMHoFTe4b3
ZCmnj4U9HniNNi7veBP2Jl8o4ATEKewKpBVDC3oZYpGBMj8B/AMcCleF5w5Y
els0oPUSTpOUqnv35zpC+I3K5a3ZN6oiQCRIsL1EoeiH93p/90Aib1dttrJY
who+WSeVTbfqaOgsn5aH1xNWb24nna66mGX7S7bO4FrqKxZLBGw/fwH3YsRc
6BMD1PiiIjXWqv+rvifFIGdEE42BOBwf4KPB/T1beL0aB+HbKG4WvhjFwpuG
1M5tnCzVyvs5RK0Z5pM1v04eDBpDRs5oBHJPuUGAgy5J9kIRWZ2hXjeIRy/V
ym/XKrb3EnXTppwX4pMtFpv4daRZ61YwoyD7rHVrN6XR9XHIQGvhn+VhOMj/
8f+MRkDuSaUNXUCj0f/MsuQvMAbZivTIdLxh3ufNEy1F7h8bAX0IQE66CnAI
lL1DJ0uR9r85E96CXXAATvLA5frAXmCIGeJi2Zq0dYV8qqL2e+H4Zn1bLEbI
X8gCnls3hZrfeLUCkMCBwCo9efTZA2OwBIMqrAvRWFQZvsV6VS/qW9Qe2w0o
arf5k7OLPbtcmPIiF9oDv73dQxZQWW8VAZfsa8s2QNFtU2vkkLegzshK6ffL
tjONEiIY1rJZc7YcscgOqJev3jrgtt4zG2unICgVE2DghMG0lsuX7786fx84
I4fu1sQIIw8/HV2u0QnFC96wUQbhIoozu73bVbWIPbvkqQcOLFB1QUv5elUh
6UIThMoSvL7ID+rXFkHLOEdFvw6902iQkKEsECwXVrwQA2fXNpq6avKwWOTd
tcB9YNSVdxDi7OiLsMRrXi0+ttYMK6o4h31VhF3eoB/wBrEuWhYx4reBU5zF
BizvmnKOLSE4IiaSfb4t4TKuMGRjs0Sn5yILRwGoYhwkGn+Z4QqFJztmZBtU
4g/jwrrPI/5obWzoxrsXflH+BIOLdTWcmwcyHCnlzuy+DqLsFZnOrG0J/p15
R2NoW7JasYCl3zjNugMFOayAhqmGEw5diSvVWzerKzHQM1lGWkNavJDcTNRn
SzpUrMStWBcMO6nM5HavQ8foRXIEoWO+UYltUC3vjsVEAB9PBrHVGNEtxrdL
POoE0o0QB0RGUbN2x4xKP9h4GEW4lu9OYA/fjLPXnbc79inEbQduZx8K4H0q
fkOWT52EpuvoLrEV0AwVLgSiZTVDNTdzMh/KjTDCaoTnIWBgeypZWKuZfseK
UHeebFAsyoGQFV3OmVIfiZvPX2sAyJOzt69b4E9VpLBkW90sfZOHswpHyigy
tDNDx5HTG8oYSI3WsJiTdWJSUpx6y1aSYkVIcH729mzY4X8CZhLoYRyY7Xok
Hm4GcqvGRWvUce49JGAp/H2LFzqFv0hfBH/xYxJ/qzY26qH3orQitnrVO7ST
BkXkRVVxVaFmPdHQKCQo6rOQuSuKIASlAe5H1j0977clUR/DGO/F1BGQ9kJf
krCULA5L8bTTkTsnOcPBXpOVFaVc/Nm6dJzGqhyE7WnO6Y2SSGRAUx1cOAF7
3YIYE7dcHBOxRmiU8b94Oh7JJsv1BASjjAUvQQMhFgjUmY7lIw3aUHTniJy5
YS0zCkKUzcv+3L6Zq1nFv4MvdJiVZQgUI+pm1gczPtLzxQwU/yHbKXBcS5OG
4WI9YZ+zLundb9n2KEuHMFfWNgIAt7eVqB1gcUaRQ23PdNafFVJcDwof4wMi
eWeKRByROhGtFwTvO1phFsbXwC4BGwc1zt81UYgSqXzh+Mgg/YGouMY6BEvy
Q42kEtRu43CrdOCUC3exsYoi97ChEfCBQwUiPCHjppWlGDYYjZNR0NgahK7F
qhSiTZJ2JMY9SIgClEVy2rTljOid51aGCAJ5FVtdZngl22kwSNBfUpgzcWfg
HkybWkIsyBrHN2fI15TuBBtvVEBvxT/icUO1AlXWU4QnkIadgcnIJ2rqCuRh
Z5n3ErH7ypJ8f1+iePLYX7XJE8aUZ1uNKS5eGskTWz7zsrLoPCru8ZLX5ovr
BYiKIJobUBgHG0UOR2hlCZJb7C4RPusR4RPL38HXs618nbAOn+ADxPPbgxP9
pqQYHzTrIQEs1UQi5s+CLWhX1RTRHjX38CIF0eiEzGpMUa0hEH0tyvnYTb/B
e4pl5UAzsoCBPnbmrQYX3mqgVgKMlZ26YDU0HxCqw9VsmRBY9iS2g2LBpMxN
K+xKZDIUyQZ2YG8/IMOBGMjYi0xzqMoQ7rxzrsEolZEdQiE1D1cSmXkeLBci
gGGsGMRmX/cskM4rDuczKRjrVpn8y1dvh8kDleDTsRBOWn7qSJmA8qScQIrs
sMRwznl+XdbXTbG8IYEMQzZUrWfQuFjllYsFQiFghU4FDFlESaMm2yJOQgjs
xS0X/kebQd6rKl9CWCa0CC9ayGARq0ki8+JciC84mVhla+8i3n28jvSaOxZe
+ODxcWIdjq8/ZH55XGZl64+djOSQLDOxOSykRiHS4VRFIICFwMyYnMX6YbAD
Qab9cXcrQqdxrYFpxUV5UGQRJugZ8cUNOCDLTh0jZCZBJkMXhixwCg3plnYM
dTKZi4bnwVwkl7iGmJ2ZDAG1GmigAgY9FypWfa4XidkxRpWkxE8WrcpZxUq+
ZIAHflHPtGEvn+JoDOsOoriROMbMT8Xk045NdiMbkUmOeR+D5qxikfPRWOok
2sflbWFInRmMHNKsivYYlsSyQA4gZEzjLA546y6QXYcUiU1E7uzi7cA/oTQk
e4Ah59J46Lz7jRwwHcj6Yxr3xsTQHeTQNGf6TKd3oQAgYlH2IiUWSfZMa+Yl
fdSLlkKtWUosVkXGszAlpQw3YmHi9FqVQgnQLFYs2ttqRUFYUaQKK+pqajP5
VspSvru8fK+AnNSzjQjzHo4s08vLQXSN3zwI0eQFckZjZWR/uHj3VjVtVXbP
AXwf5E1F3+9F+0GPUURpPLzygfEKfMU2IL5H//TXtl4gAT0LL5soxpgVUGnm
hEta8LGaq5t1633z5A0Lr0gUtccHNeM41jYwtFNMgfH6ZcHc3ei77uRwZBrI
G1/VLPrR3VIMzTgTavbo6IzPIIOfrFJy7lkKHmHSECVGKM99RvBox55/HnnU
bHi3eKoS+UaazIIpBs4ZkrnADSEbQEXUzClWEzXNOAclyuP09OnBi8Px/vhw
fMD0hkjPyenh/v7B6Wzy/PT04HCQtPbTLW3Xjap+DzT+Zx0+/lj7v03WMq9E
0JFEzpQRrqtgFLFpj66g1api43bgGmlyIV88QWZwlS21QMwQ3/1TyU1jLI7w
b6tfEf8W9MHz9Nq8D0DMiPUAY1ghepMsWV2FZ2IRjBBGGBV5sSirIlJkBgYz
hpGPNOGNCwQ0w78ofr+DasPUCkn4EVXJ2Xyq0G7k6LBLRxuKp/IRq5NXx05Q
5UWar091fhaClIaPLjTUPnn1nRkGLvgFabspA1/kVnNcEb/XZMLAuJc5456e
MJuGg9HDLN28m6VbZOFJSxSAjZOIxXkyW641F8PE8bqcR7unwCbraBCO6/JH
vU/Ox3c584+3iETPxqE4ZIJwIX4UtBERQ4wDcVkRvXIl5bLiMbG27sGpQd8b
FfHQcmPzEtVoKq6KX9lKO8xcPA7bEdlO2rSrut6dF8EhUAoeFTHibIzkXYtM
txRQrLIRSdTZxQGHQhiPZZDDE1xRGV6zSNHiFJh4M6NJHfLsaMZ30ihfVrc6
n3qP+rpdXKYGFxT6Lw7jJTJqRwrtabBrkkzY1hsI/BqtqC6GyGeSc5gXYHt1
TaERQOVTlk08/zngNmestRivKYad20l1vSautkoK9L2FC7y7pif/RzBP3+CE
buKpgfpC6JIlCVUSy3sqPhhRMHOKU3SPHWHSCSiHBnMJNKYiSKppTdWQTmKQ
zwX3TEv8N04tTvhv6JL1CVIycuBSE8EyqQe5m9amKT2r6FmfGlVJZEIjsWt8
wgN3milEgkv0Q8uysyeb9y6KLfBTpVVQMlGvF4x49br1ln54ucIIn2kngMJG
lCAEMeSFg5dUburmxIoyMA7C5XakrLGBl0bAbGfKuj2NLIF1E/Jvje8TP4Se
JgJNscoOcBqQkyTL11IGRAgQIHBB2xuKHKVYjUl9R/57mAKtEmgdcphNxqqY
rGJ0ZCdGxV3fYV+e/Zi8HH2os8ttLc5N8qvXKOAkfZk+3UsE051ZhfhW1iOq
dh1PO8Qnp6j9kSzyJEGhpQiNg50MMTK/uly5qGxQD83qZ8pao8FBJWVbJogw
2SO8z4z/gOc11CNgHH3yRsCF2/VyaWQjJ3EfoScjPN/Qv0EaYmaXaaSH2Mmh
ZkUfcChaoZ0Pj9QpTTFLZyzRuF1jCg2KQEkOZxaWCYqdvrDoCQihm9iFjgqe
edazTjpGZu8UpM/XHZUHf04SyuNvhc/1yQKo9nmLOdyz5yIyb/ap7sS5vUsJ
ba9SH4CKlPjB5QiiShqZveEoDiAWNGmUkTyD0nonGfvizHY0uGWOSsNRNXXB
5M94MQ/2x887FjsGFErig9RFDdOZsEySJOEU0ZJkrWxFyvqFhWGgkYfAVN+j
589ZzJ972XEQ/lSt4su2smmqjDBqsKp9bEOgqB6JTcTcRSLwvXgSRqcEfMse
vGNcVavMptBEO0B3rg4S3G7LfZGf2CXtIDoqL6HYMGe+vBlnFzahslU5NnBY
KlvgqmxkWPdEvrxytrK9wG//HUhNRTO9YX3WEfjzBVzgipVX9gvcLKpPfETb
ImMEolRlVikTSvkSPxIaUDuCG6X9rHp0sER8oLG4I61H8c7USuLKh6WtmNFd
HhfYcFcETy2ucGJE8QKJNdeEQxFGmDaOqvVaQu9A/ybJNlAWMzaW+gorGuwU
aLccimyLvYS4iNVLVmjqgl2DeLp2Zlixv7ekmyyLzbyGGclloYUtjdyB/5T8
zkj7jNdk6zvgFnE/kW1cmRbBN+9YKb86gdNrb4rG64/WsI3LEa5tWQQBj0ZE
YSuoCCUEgbxEPsAPx9cQFirtAetGWAzzG4f3dSORTCyLUEFBC16X/1+ZO9Gs
5xJL15GoM1d1priOEwBuayoXwQsyS2aOHZ5F9tIXIBJdFoPmkotQ6U6PuC3u
KDFSbnl2E9xy4/uPB6PADysirkzitFSkMA4x8XpQTUBzPbWGY0/AL++EJnR4
2HWhBQP2eyPFZZteyLBTOTs7j/eMEpgyKp9pLnp4e9ohlMP0WAH5ZPn4hwXy
xA16Kl0dh04JofKRJ8TsV6l7ptTdvU/uC/PaXhiF67aRyFHgqnsY/7MWpVWY
kHVt1F7/dIk+QYG6ZMA9lyMSamBTOjvjZZq7owZP6/A1g1BMH1eTcZeZwkY6
voYhJw3RtKDBo5fKUwJ/6+V2BrcyiI0l+ogLsFLHwXj/q0OSVKU2jQ/V9YwI
Uwo88QzMvP2Dngzk5FJMGf2Jgfc7KmuVhEluYSJV4ajqXhaEdrLlunOiXCJO
V21zkxoXZpm5fO62TI4hiBlKLyqOWkJfdgKlpULdivJuk3pZETrvXYChZ+jv
aXRWqyqyQ1fXcPK8gD8esP1WSdJ2rEpiAZoO0MDdB0I1jQsPu9CFo0dWAqO2
U2Qc2F8CLaObdcPpRKLBCpnVHUfDWcGdgmydEDtlm5dAWo1E4QYPBrq4VAkZ
Ap6UK8uSkDEWWafQdiYwooWIiObGJ4aFG/I+XEcCgAhctnEmbvhZaG0zAR+2
NM7CvARbmcMwLiXWU25z+tkAZLIBiyPO2hRfIBIDu5dI4hrMTjLeCZVPlJQ/
CgS2eGUm1EvWqfKDFYtJlsSn4acBi9vWGRmr6u+tmm6vR2YgEnmuOqJfdGpD
G4qGJD98P37jaF/D09Yd0VNLH5FAjpQsSWDea61CtFzggtOoFBDbgIWzZ7iL
W3Qiab96D5YgMck6seN6sRY1BzvBWBz9FB7h0NGmtviI6jiGmrUY9buYbnz6
QkQHDU5bNXUR4K5GVm0Mzm7DozA2i6ontvkToGdlk1Gmfbs3zt+Ju4VkU9hS
uDbZkkcu0mTgNwTPE6oPwkPtOQ4X2qCcmSfMXuDV0HVikzJfqEzHbiWgEOOU
KnKLYiLgeimeZzdHtG3RCqTWWKCaWowXBR7wFPPX8fylMOO8XFyvbrwt3oZE
8i6u+fLqi0iwptN1g0qEw386TFpiLGFlqYBRZ1O/LuuRBtSyVb4AYoRVVEhH
RNp/V89BuB6oQOB8xWLduMYtsqkWf2hAi1ans8UcWy8jC1/DC1EK/2KgSFQS
ViNtGZWo9gtlLtPFQQtvFuMfm5PNwFjfARUngtaUBO41X1y6p0NbI78nCjag
regZaybVqhHbzBqLWBLvIHVIMaSzsIBXcMS+RG1UcxA3V76KKlcYUYd9lhLt
fXpjR5rPL9gG6aMsJRosCHMgthDEVr20edc/f+GVpjDeqSUdwuutI8wuvSl9
tBVQlZENLfsUiKPqtENWuCgxX7BoqvnG6mhS+8EcwJCrRth8FcL16U2NEhKO
BS9pWltEx7A2aawAivTu+VoUzq2qAJUUxNrlE9j0fTXDu9uqgdhX4kX65GV4
m9jnrPkSlj3iuGxUgWEKxOko4pE3gfOGVVkQJcjKpGhoeJiWg4ziBjMxBPbm
UmMhZcaVrg4tUcdtzvXSOfxR7ZEfnD3yFTVaqJtN/uT8w6u9LEjeJ0AEOObs
u6HTEiarKUcyqMibBSIo2TqZD7A5OnSQUyIJ0J5y7oJXxMfRDrhcjLNUOx9o
BI7W3ZvJRlIP7OIxzInoGZricURvpXEZPfS9Dh/M5VHQR9FX4bVmH6EjCon7
3sxG8rNkLZs98tZ91lYW7c5YDmJ86QbtwN3o+A77bdyIGGs0W2nDLprMHHHk
Wd4IhrZDLQu9EU2b6bqVHpJJrcS+fa0mjpGDWe/qahYujbEmpAixQ3zhdT4m
TL5W6FAG7u6ZBo4zAl4PA2JvZcxEuVZKt0I+O08b+3dMHo5fmxCyTmwG1dfc
Ohc6WEInsHoTUh6Db9fzOV4NuBWWawj/eaU20RTJIMjsCMFD9oNmq6oh3iH7
Rt+cIAjvP4x1druPZGt1dSP9xHigjwsgaETUgr4dNu4jrNxlTN90YSiaYb0k
WaFz/5iSEaCAHuZdchgq2SDbcErHr8Vs4QjoltJqhhrp/bHcoB+G1taGFvs0
+SMdzi6VyU27WayKn5LkM10ZqHIVAkz+qoZk3GjRVbLzkYXh/qbUBJ5Ocn+X
IlEGZr3itZkTKn+iGg2srTrIDpMOF9MJx/s0Gb9WN6barCkgXnoNN7ZlRvmM
JszCuBDZHONsgsRcTeRT6Ws7u3qIxgjOeBZlvTklg5xXpD4il6L0cDYC5cmU
p4GWr2dmIP01gKXX1wvKP63XqxZlKvcCDCTWmmEQxap2PSQXEvlVL0YuSjWu
7rQVQFLLw8CHwhGE5/ogYlhLsJnxlrEF6G2C2XHvKe5wwVdDqhF1IqmJTn5T
IkRa6VTAFiSVZDeCykD2PMEuJlilQdQ6H9JEIXEd5AsiVsPcJOoqg5rvLGjI
IDzLNVggSRgz61feCcnNr/D+s6+KQgqWDdWgskuiyhi8fgCaIbw5NnzMKwAZ
8eS+9x39oxhl47Ii1pyXTVNTfeqFaJaFFGtxPhYt+9p195tpUJpu8ciPxhor
ItXeEDjODOL8NRl3IzqFJ7Au8fWNrT2tVDFswsLHGzfcUHembXwSGZ24nQsW
cOZURBrCTEcCoqIZZyMufNH1sMSyCvL+uM1A3M7JLz5bFlXTWgOCRkTQK6p3
uXBGp4EMA0KXOdgO/PZL7uRkRRChsakA2vInjrSj6hReK2r0d0vnyo1WD6GA
T/J6DyU6VjbKvTPiynIl3wZPHbQHD4OIwpGtCLSqr5m1OFQzjn9eQZglyuKu
7daD4PuPdTE37k+rMUnMZ0r6yQLpp8vcgpgvocgm3FdiXIMkUHU8j8wBjDxt
A6mBEtCo8JN6+bYLZpTKAMLC95S4JpUaHjONRIAwNuGFC5ctGmt5R0YoKTQQ
Rz6ZYqdhiHQ+eOzqOa/OOOgTYUZRQi+fxiuNLklGfzPqWWX/VRgn7MMRu3V5
5Apk4etODWPxwuNWlHjQDf9OyEShVOfDZbgXmbXIBdzFR71uMrwVaMYWsU2H
9qHdHk+pRlbk3j93fDEzk+5aKe6uXTVr6mtGzogupw6993GnNryibnAT7kzi
SNbh4yg0bseOVJGpV76uCgHghq995oMDdAmV6yxTuTTAkko6yF0ABUFUPFt0
LUAN/V0JMfEACaDcHTcXajXRXNzIktlHxwNs8AGxGE3j5Eig4u54zUx2awiP
EimkprIQn+8UhFQfUf4Z4Je857P8ar2YFdQvYY6xrk01wfbUbHrbOmrVRhtA
jYmCw5DL6E6MsGFSkxOmYY2NovEyLZFXrdrty6DCh+kRJS2rc1+GQbhNfNJV
qlQeGa4zazFMbazH6B3sTIv/cWM29Y7sArUoLt12PkSggStiUZpmM8ifaL0Z
/nlvT/QtKlWi3LrSPll0eeBhQAStIO9k1UJyTVla2kF0SMhTyyq6NVjvKRbO
hue528OPFXFbRF+9YEa63xmUzyGeGapPaE6bV7gccwgqQgT28chGIYJ6wGrE
K1Z0Kh/UVjrXyshEHilM9aaez9igFZjI27wTP//IuH1bHskjTQ97YO1dtuiM
4fGR9eoleHgpbp7oTWslY0rN9HV0BSu5lBL9OwvdBh2QJG6xqGxWY5QZss51
ewjGdWpp7hZ5ElVcmPwZVvr1542FNYauppU3Sm2CmkSdapjbahLRktyI1Bcl
dYhBzSMu7kP1L1xCNdXzpjA3k760VZxk9nhJ0RBeokS7pEDaneeoalgEFgn4
O1JMGlMcC7NCt0LRlx7h8AvPStrelJSECEcukG+T4h0f8WmXnKcNYJJC3ala
IdjhCld4vVQbdtmTsAkgvt1UO+5dZSJwe9eSbR8rwJbHLDlsYJwH6qCJxPGB
t72769lbKiMYpeXT7Y33lKdrWy0cRmxYZ29fD1T3hc/c7oJJ85lr+xdXpiUL
n7izUpiBSyJvNI5o86aczBdEBrbFBpP0pWvR6FgL5Fp3VQQ4vMUcw8Cnh6/7
0dXgjTQoTJOAIWFNrqtznJe4uimldZ9J/Sh4H677HtJPsxMBABpoLhMN6xEN
tN0r88sADqHtPhDAoror6G7RW2VVJPQsxHaIHkB7COKq0MjoCiIF4UthQRtv
3XYJrcECuFWlVmv1pxibhqLqQX6YAIW2jUYBKTZ9LF51wGivqBHC1nuTS+V/
j51JmDH1zNMUrkcjSFK7qEbPb/I3hbZdT9Kuol0I6QoqtgU+uMdwv1lNKp9s
WFlIT0tBH99l1mf1OZbFpUS5xKvmKQMzNnvYSCedZiaNW6Io/1jcBHr6+a6/
MKjO+/5G8Dj81WIO6VlkSpI6qcu9buQGBiitMABOpDCnyPY5tONUomC4rJuG
2YqZJHdmkp4Ue4d1pkSCMQ+JoVFII9eY0wDtReB2MOqzu0m27IJvQqndxLWp
LAsMyaTMOBdTxP4wYtZlgNvpvRTiEnh7fMqxaGq6QnfTPXtTTYlQZIlXExJn
Z6ReO14gV36uiKqR8kHmqVxcHtErCINILKa9RI4/LoZoVuZMP5pYw+AyUQax
XYuEXS3O0RNM8ogdZik2Z0EfuJ85sslyextX3sknfvnq7TkWAEPO2XKLYptY
6kuVtya0Bl/Kwtpll5a12L32WTulg0Am6YF9xJuySvrXyIdzw43GMuMnctc6
dUSCMmE2deRpymjWIHogddaqqWMSdftobTrvatPZ52jTeVKbzkQpIXxMqvp9
luD/usU9StXPE6p+tl3Vf7g+7+mStW04m2kcZEDnHmu0blxvbfLmq8CCU+1W
ZUn8+cSnR7M5xTYs/QzzbpWu2jyhyHbiwZIqsFhnaQncjrmrCH6WrQNlqIco
i+Nfa1oq49uhlZ9Zqrlv9fiKKyhJuQpcoTnIDj+VVpivipXYNJJdi1ACc+UN
e9vMiH+IDi/V1oibirGBUkLskjXpueYmKLAswxSrTEsHBCkPJ8e+jJ80mdam
qqqGmAekeT29+cPF6Ozi5fk5iLdL+DcmVAMMzLNPfvin/f2j/RH99WKY49/H
B/TPp2esQePnE/7q2dke3+2bzRKpxpMvR1/yO4ev9obSHgp7mGLscAk//+u/
y+9Pv91LxTbw1uPGNtLFlX1tDXHVKgoNUTpGL46LxQak2JXviDMm1xe/XS3o
/bFpAsSHymd6qa6cNuXbRqmvxOrZWhuVV5zdlqULWl9iOtmM6Y9vjDtO4MXj
Gg1hB09XOWMufQA2llR7Jeh1oQXuwskEnzJTBt/p3+RJiErn9ChRTzReTzRd
LuG45+yO4cJ9WDDw/BLD0FtaeZDtQyFUceYQzpPvTt7dE18AMiLn5XNlN7zD
TRQ2LjpR3W5tvWND9VjxaovK6Vydxjx7zDfVbe9awATN4KNyoZ/fpywMUTcF
nQiPmhK1uFV5XTdiQwiXcrrTWz5MRIdFXmokBW05B/IoxLvrb0cG1o1BkzKJ
xsldOHHYZqw5N/J6MtJmVrD1BGZXcbqwc192Z/f0t8iE0Aqa+xkZ/UG6+M//
/E9gMnlAHwg9Tk9/m/8L/E+VeBBz/y3/cvwl/DemJTQIuufECMX5/iKGOSiI
eQn9XKCDLuzkg/REAx7YlKdh5Z2OfdM5dIDc23pVeqsFDtKWS0C/Vd3EkWPV
oksTycmPK0fvTCO5K77WHwdcsUkv3WHI9DbfVR6T0lx2yce6JZ8XbCoCdeoB
KYZJ4/qAwmHU2NsAObrPOKGGQkkx0k3pvQ+va0MJY5CEM55/cyc62dUaKzZL
OINh40CiiQGtF3O0e7iB56bQeJc9aXqQq7ToWuMMwmITvhTjx7JcBtuNSy9k
QUVnQoAE/piF+wC0RVqwP3/FdNeUUHMHHMtfHRQYvX5FsfC7nMddmpDCySwk
Q3KUHLpDW2pX2B1Tig1ZFGCrOgLCX83M8POgzw7g42GEj0OZy3sJAoBmJIgd
vt4Ln3PCoSBlWnrpCzsnGakjd1VxVzhjX7+vk7XERmHNr5FUE4saUNmKPzhS
98h8bFJmS701QRfIMOtZF+DLHLtFjKUJR4hajsD0opY+0UGtHtrkGlc4K32i
OHFaVktbrL8rNW48D6Pyd9NJbvxElUk7b/f1bwtOv1tRxhUaIQSz56ZryOKa
UbFsYK5AsvukHtKFlR/i87HChR5N4Owx6NWTAeObr1trWybCQbqMW8ACgvkA
nrCkngRnkv6iMpXuHkVOsU5XNFL1rF+VYpqVukflKKQ6tHZdjMzXXFC4FiMc
IiB7A6WUcOzhDonBqRrrQUFCIt6fIB/H61KH0GyLHh+4dsWm6S6Sgwi2Ds1c
BWQkdNhIgxofkarLUTsoAW5zzrL1uEEtR2BE8NS+U4HvzXcBcEVZulfMBztj
zKdFTOarUTINdXnoEYw1xtUJnQ8RNZE1pOVKdm7i765ZlBfxIpGK4+QpAxQZ
mgtEFktg4D9VpzGFGO7ezV1V3pfSI8OnI/LNMFWde6PPvI82FYPBku26oWzy
MMJTOr3EQX9SJaTQ7idxQQiimU7K0Th7kb3zgWfpg/ziu3c/vHlFRyYtWiSX
LNTlRDH7ItlW4+dAT/7EhsT82/M/f//61FaoD6v9U0tFqkkv6syY2qtwu2Gp
Z9KRarol8lPqOy/x/NWeRjL2KD/6HGFhBzW/PP0y9wip5jV9hxHU2WVdLYpd
zEPSSMLSUL5ZpYt2/hHG4Bwy04PhR7r77qew58ePzgKRFW1YgGXrsFhmigbO
0gN/dfz8RzEnhToDqK01GttRhuxrkBEpcCFWscnQaQaBMYM4jrO/ck+khMUH
l23N99UqtvicG8z4/uwvOIu1zAyjjOlMnhEDDCJZ0XLQCQcmqJmGVQ425Ph1
GrsPVRW0Rh/dpKuOcdMflUualBqxusY87gf7OCNewHjS3UxkKD7mUKd24QTB
VYuqpbDpcgX615qqUMqE7LGhukrdvu5i/ZNU6lTOfx4bUjNnSE0irBec49/2
3f/gIV1KFi3FJmLGXbykgxsaPmGvKNi2vu9gVraYS4h2Kqf2SHOpqPNUP1nh
EBm3WVKpnr54eoglf93orV2AegxPTPIl+x5Ztz0+OTqkMBNcap32LyJdD4vA
hrVft9onP3FFZOY5mk5rTz4uAx6b2qjaIL5GdT80mxIWoc2sNcx7ezk7pU5h
lwmpQEXewp4Chabs1cLFZMhldFiEbmQpYDhI09CBZpeeHMeF/8yEnSJ58FaD
KiGQUi4U1FP1sUM+ohpcQd03JBdhNcn0cCRnLurM2bnS/Xx/DooHfwrNlG7F
3g/E6bGmYZzrp6TZBtYVkPmQEY0liIYeuhwcbV1sKkaSGPdFfxdiu3RNYIvI
qb6y0zviNqWmioxIbUhRA5+gZNSzXSPp7zo6zGJ/V7Xa7fLKA5dX9vkurzxy
eWX9Li9G13mNP5zKD0dnvb6wTH1h+SOMs2HKszMnAp2WV8o+UOfSmywd/ReE
TC6yxBg2a9wFj/XgunU35dvdTVjNajEr0Z9g3F+G76cH3erXsUKNVNGSuQfL
pro7HWiogrfFvofvEXg/AGyJMTw/ODz59ImaL2HiesHlqIh68nZ4QN7I2Xwu
aGfZv4+7yWIfP9U0YNc5ngn1cdREH04TBIqHlgXp39J1dP9mYD3yCVgn8o6y
8PK7zKNhbLSJm14TI/AuLI8TBm1cyz4BMQOePF+Fq0OtV/1JOb4eDzOqlLMI
xsHdA6ZiFUJ6dI/3xjqKOlGwWBwdBSbJZj4TC24fiAAoTrmAbOtb9sc/R2uJ
Xi0WzBJd003lSeLixtfmVZruaz4ZKYnCQKgjtcs7AtHCxumSvttaN0KkKaNK
Yc6YVNmKQD0RrmgL6EqNvekwdiIbnVz1Sedtp2OaVtLVukL9i++otEFSuIai
KM3IOzTD8ckEAePazW0tWheso+7bQk/1XDYphj0FcJyodKApB1pok6u6mWE7
LVcABzFmyIyfHjvFYTBydoXqL9XuoU//+i9w2+njv/7beCA1+F2pPrNNWpuT
7Khvu7en3GAZAbxs6xVGiHecIy7ENnkCGkceHyvjTbR5B5x7kvtNJXRcxJe4
MH14nH/HUYMSd5bcFxUzGNiW6e562U7cPFsgVcXN0dmQSPAHco2rcdWGKRkD
p+BJeyQmtHv0MLwtHqcAW4aPdkGHIphxQHe8wl1hja0wEnaoamWaXvV4rp7H
nqusTG0/Kq+NhifXgzxlR8+eWLPiXq4tMyJDdUpUyZ50pJA915a0C/AdLaB8
FVD09WlnkSzhaDPgDizd2516mRfk1Kkn4c0dxx3OMhNGlVDqGT+tM4GInNxJ
vbKmw0TQFAhdcuSxG3kPXu7+fThImA7902G7l5H3twXOOjmE7Vkm/ZR5UgaW
3rSUSsgTsfYAvUwSgP9lnIUG4dBx64tyWLTxll/OIp4lKt2HbwzGHD6dJGIz
ZnJXLpgnqMQwDAz4oOlf5KCrTHx1LviC1j+o7xftwDAtsZ5nbFaQ5An/uuFE
k03fZRRq9y3bB1BojQmf9jLjI9HYJ6c1EtMFtdFGXFgycjA+Hh+MT4ZBGAZX
gkazCIXIWUqdxS2aNmTrqKahdzuI8JDzKtp2fet1qbhPDeXSotXvgi843oKr
oqJSDXBPUa+68tWkxNunGm5GgROzOD6k0zRqIi0ixODKQcw8LQEyM31tqKCU
XRJFrYbeUE66fWWze2FVr1Tvdv6FKBA1DBOTaERefJjWVm4LFxSDfPbkYK/P
GOsaXz853IurpSSsokPqZ492ZDX2Pzna22KOMTLeUpvZSFmiRNsUDH+jvXkb
WJje5eM8yJbjHBJnIgIFQP+5474W60h35vs6Od+TIMOWYxV1Tu/XGOffYBcu
L97vcv37UHGOyhIxKzSW7Q7jY4cIFiHQyB5q6Sg/B61rH3BAQIxKI/AZjV7r
Tg1zg/sgrJZc7fRKCsomQzLxJE7ZTgjHAdwuiMlOBmUH3jd6pZyt4Hn8KG/x
453Sm9ZyoLO1ZUXt7Z3N0mQqNT5subDVXYTa4qrP3NNkWARxWgnj0fjQhAYd
vXh+8unT187STGbccCrWfIEBr+DGyrxZMK8hu0cmDI6t3FTRsxM0MeTaFL09
wZxRMkSuq/V8PuKC7aqRo9edqu3PyAABSjX2rDX+V6fRUqr1jjmzh86Z75hT
TcCuKNwqAQXtwhi2y9sXsSeyZh+JwOT8DKvtmHvCuHTyeMw98Zh78kjMPfls
zFUMOnb4wz6Wr7NH4mbeh5vPXGwhj9yPmbuwhAhNiCUHh89HE+rJ8FAMcViJ
aalZJWiQ8pp1vL8wWYwLao6/K73vTEJcDL7tcithj6c0b3JsKfQyEQfpgCh0
I4WSiiZYOWeuaaJIHeMSfU5suXf2STpWH8+dnQ+p30vQH+Wq23mps+aX0onZ
ohQs9pyk7qB6Yn6eBx13nPnnfccPdJNA3fwllSoK+4lQLEDqafVkw+wmD/f9
cMsiRLVIzq0G04x6PrSKr6E3AOvsBz8zE+F+KtwMZT1fVZjdeieypcMJ8ZZw
1K6N1gbc67nI2vA8j/qaYA23HmzIIkCnN/uSUSFGBI5M6zmbL4Vcm6q05++D
kqM4LG4RHuX+we0N1m5uwn4ifLQvBXteiuiZ6IFDJt2XXyJOSJg7XmwH4G2I
gc0Q4NUhDs9iM4+v/YTSULkp7lRXjU6ZVz6m1JNi0WuJlJhdV83OHk+3AKwa
Wk3EWfpPx3l7mr//7d3BI954Tm8cPvyNo3164+jBb5ziV/DGMe3l59P8i6vq
+lS9maiT5ivsAfzbgWpOUYmF8YBl+TjlxJmjyftLkbUu5p7J5lb49a3yAU8f
6NN9UAifPjnlp/vOJWz8e/iYp0+O8eknhtjvPWi7X+E0D90uPH2w9dBjpHqx
Fanip59tRdr46aen0XYtVsFt7mDVuYuASuEVxfid32IQcJnf182s9YUAiqa4
borlzTh/8goYDmhNReXUIKwMW97v5VLAIAjNR8Ll20hbb7u79kWr5VI4Lszx
qazoOoZslVY7R1uIO8F2VnCBKX/GCgYDX1FYoyR4rkGg4g1cy8QBiXhuyQP/
fBbMDfOhacWYLicl7gYUWfaLUWlBX75P7f5Mbs2Gwx0Y0cH2mcmZWrPlDN7+
cQEaxo99g8Tt59xoXMDfjyaF4+MBMX7Y7ZvlSamSwb33mNb4lna5aV8bBC+P
BwqIMoQDjhXBIr1zgjVvG6aRVcI0ZI/CWNfQgLp941o0n7oXSJEtC0Ibdh2F
sJjA0Cj9c5xf1OLkkVmEsQJ/Bya5MhJSEGKjAMYwgKvOtuNa5uh8Njb1oBKy
h1xmgCbA8RjotqBO+wfVmTb1pa/izt2ByciWnz7/YApNj8g6gQrJJwkL3lVH
jlu9S0CZ07c6VTKinjmuTWZcTMOpFiZ3gYRax0FByQsKWCX9h4+oTZ3FTuHY
z6xhEIWr//a9du0IyxcUO2o6ctw5V8UAsrOrSEKifAAr/1gD5ecvltUsNB/i
1xqz7XoVdbQzF1JBhQXJEWoLAmVn0ym5la/nm2GeKH5bzO+LTWuDjKMB+ooa
eFtClsHaBZ932h0CL5wNhNEe5rjtsB+Ur4fRXVivbpz5WsVw221AcWCXjEp9
mLkIsFTe/jOuqgUUH2/P/QTIfQpA0qlF6ZrA9F/GEPP/vstoM8E03e5hN7Bv
A9nDL9zOgtTZYy8c5vlJY+qbaoniRWwwKZ3JpHvtxKjZbzBpOCtkXq5KFrY0
o+/rzPDGFGYVNJGKRdo9O6r+R63dohd9dFNJrSLixjYadQPMh9priHxo2ZM0
A0TvI3VudvX3I88xLdGtSKZE3JDBuVMFbJz98nRdg0qRcSapaqYDePlgkEvX
VXfTRa+NLanU6hZNrFJB3lREez9goLAkMbg7kDTmdAoJgjNlu03NqGYZG8mM
sJO0MjakqPpsFyThp7QjvA1D7ysM2jjSYtPupff+GO7gNiOk/VfYVsf3gE6a
Oz0Kt4xZdNYGUTlGbbqK2gSgFEPhhYiJFAnVVC2JpPA621kSl1zSryZombgK
mrmRSHhdLrCZGo/ec5OMU+vD65fvvv/+9dtXr1/FxNk3gJ4DEmknvHKWaaHz
aHBOdm/K+O4NrXcK1ZObBlvdDHvsNuMOXdBt714rgs/JfoFHNRNeN8ybYuVi
kftzoMz985c7ul6uYG/0sqtYSdFOrJC14iyXFFRgwJNNJplOZITm6ci8Pji/
eN8J2prIkcf0KXZcRi0vtvcyZplZG2reI1un2gv3BafUYNlO2DE2patWcv5c
MMJt5EvX5mLoVtqihpikpNGpaj0oXg324QTBDJV64Cnd/GLWjdqYdAbWy3nY
tt40bFR2PcwpzpXj5BIxcmGH6yDMbei8G4Ozi7db3ulI+SoqZJT+r1t0PTMp
ichaFbst+VwosvSTyQLVJuyNY7og0veXPoUglgDC2JM2/3FrtdkfeTIKjf6+
XN3UMx41HkXWivUyXFkGeun3ry9hCfgijwTiMvaNOV8s0SlRNCCIrkhqfcuV
P+GRqPtvT4dH2V5QmNDKXRz+J7lNqqso5kVjGVuivPCzWKzCcL7vucVirq0W
v6anPvUNyz+bYamMZji0SeYc/c9oOvz2fxyMx7/5nzpRcjmSh4w3jjry4XZ0
hafZaX7GKXayMy4fi20YOZFdNYE4KmExszVm2Qbg+zKGwWOVVyZCL2CkxNLx
/tDGx4rfyHH+iOnEP/rOgp0r4ft5FNzXsqQ+Ni6oKXMSoqn71yn/SaVcpTkQ
Zuw2xSZRZeZJu5dF3z7RzqIfNDkg2Il++8nZPSKwpioKmCoBTLXdwpmn/+i2
NLpbFdcOPCJA/Qg3qPgxbMboUhecaiC7ZNEyaGiIfh2SjGFofh8RxKxBpXRQ
c8vG1S8T2bJcmGzW+PS6W/UlNyiAp1gVmc/6Tp4376PSyvM/uoA3+P1HG8lL
WJ71X3isMyiRev33PXo+t7PpJUT9VPVSI0meOpzgW/pN0ZZfZ9tvPzDH4Nan
KAquIxinhzgpDXEhbl2iAcMTrbjk2MtosXFjPhsr8Hzs4xA42A+uQeinLjrA
k+WiVoFs+bakcEiNMwpTWRMtXvn3L4PiHeTkl3h9wf+A4phI7VbmH1sAyMu8
IMSor1izwY6FfmXOYJ35sghBnGm4EAywkFiLGO/eUlECEmu4BGYUa5mOmIyD
GdGoRKHcWRA4SboA0fYB2o4HamveHlA51JJWCPVoOZRXqJmCrkKVlu0IGz75
aFmpvAL6YyK6ASDCVI3qiHg9BPXiYk6J498mMSKgBN7r4G1bYo3bWdoiNj8z
zCnzhHQccjsEFTYswlHt3XgG8wBHSeSGiLt4E8dKijbkBVoo2prvBRM40Fns
970T+9I0CgwCDZarFRHFpfl0k9FoVmdYi8OML7EZKmada2KaDcBHoKX4vC9m
03dK7U3RxLVL+o7G+0S2nQpK/ltPJlITTIOWCFXcMXpvs7TtSYXRYtFbU+gm
Ln7ii2H3oLXVfroQsCoPX37ZRuaokzPmuJ1GtRtNkihQzx+tiPwj1S6XSsa0
wCvsDwiUbNN7GuRs6QQtuYJbquZnVs82HlJZ/9ccujK1tbS9iYBHlexdduTJ
7GqICTDnyzbvliolAy7mIooIw2OSxvltNecrEKmeV/T9KNBAr/TZXlXUU7ai
G1OmAVn0vW95BphcTn1Hc9mkqIc4pVuE6oijg71h3v/r4d5wy7tHnOHS/8Ax
q6C2enbWt3NS7RwpJKmhTSmh9PrnqKHWAP15+mh66dsU0/fvLh6kmXaxZITB
A7eqsVT0/NI/z+e/FZbMANeSpFKZRqybfFLPHMmlNco7UR5EVE0zXkUmNnBi
upIm4SNoBAf9mfRDnffKsO9I25F6nX0o/0NvmpEFnbQdiK9OALZ/9LpYrTch
5ebmvvlHP+Xp+b9OKcg+DOs0fyPtHBJOMzxMiVe+sYkvkUjKTQFyl/1j2Lu6
BUK/OWqtVZCD7iLcMH2eMkdbZ+Tmp7QqHbbeFf3JeWItn1GdT7uBU58eWv88
3GislPYzDdboqOZ0TkTFgjmyeuyhhmxCFg2Arf22lj7DvtWM2YOUz+7Ae6Ph
HWZ78ebMJN2NYZxF39YesDF3rCSbfM7Bpo5VRVE6WNT0wlIUPyquSmktv0FZ
fWsKpcA787JASCxKto1gurimdXRsa/27/TXta1j1y5YmJECnzXp73kgECqbU
UUnbFkJRyjMRVxo9MjERYrqGol1LUy8PcSYiZ+joGomMgSj3NRK1gOFCDlHz
w2BiHxBANX3YuLKqMzGz7xDxyhANfC8fqeWCgOMdZhSrXGzPQfSaivTz9veh
C0PXiCP/y4e/nFKgWrdkljMPTYmbrcVt6rIaxk+llt4XfdKZtbCFaGqsbJcd
Y5cPyFtwG9mhcH6ixk4Pp5/IPzKHH2ME9WaPp52qwZWa2JiVk4Kj/Qxii8h2
KUBKN8rrerCmIgXmSJDme9ZbCi0gD5ENMF4gLP2UDUm/idhHoEqG+QXBLB5/
xQTlEc8NY2205GnD3uJ+0sQ+eEJeonp8AxY15lWfhX0nbAk/iijDKgbiDg3O
v8R6bXJsnROhkYM78IDwNKrnhC+e99QUfPTZeO2LxrXMRQMjgYi8/vfzt388
e3P+6t+/PX/95tW/w+cfXv8oyNzFXxoKcDhR+1qNuj+SMhMtj8e7RVf6dent
JXlY2mHp23j1nAv1gTU+PUpSTdGv3YibS4WIaKw0rqZJo2Jo0KnV4agcKNf2
6L24fShiQi0LGse95xUQCv3qxP/a8AVFWV+Cje9YEO5pUcPHQbr5OpGQLoQ2
Ywmbo1kM/nbPJwCggOgfjbLM2P4+dPW7HLNrLmAf5OVmfDObdRyt8Olqlk9l
KVapHGoPVPjyJ9Ir8QSsFdPjhXEkcyq29SzT9H22M5Rm+51DmAoVOIdsLnnH
7cMWspT3LKiTFYti4607kira3W31GW1dmSSxBX329oxnC42pzrdlPFsmFzVY
/Q6DMufF5jtfilRED9l6oSWUHOpZOBlbsZo6zVB+RpbjXGT2OOJF3VsbNWgJ
gnE8zYYBuS4YVvyJQ3s5akWq7IVyFyWI2bi63MVndJq/wmp6Zh9vM+fEgh6f
tMbWeWOiY+2m8WEPgqohOQA5IwVF9EjFrSgTz1lBDbGNh6ZUC9ABqpJMyrDl
67qYc+XCOAfA1VXDwglkzFRKYYjzlXRkCSYSA7vunBtFa8dNfoDdALG2LONE
J6lOCHeJrP9WkzjzziKiSjlnlCMenh1Gu7Ufq2UnPQ4tHQ5rzxT3OjlKeygD
vFeRGXSl6s7Z9MJ0jRQMvukbd38PG2sm0c3vkxavMKGrekaJlMiyvyFezaWr
Dac2e3RFbJKnYHj0maelkvXoMNL0gU+gAK5Fko1cxg5M1ov9/pJuP36+GNjS
Kw9vDL7kc4M6l4InvI2wQtO/uXO020bYotDmOG1BhiFjA3qWOVAUdnvAQDz4
bScbjoNZDvn3w/D3A/idc0yGDrnT0Dg7oHHODuWYtsn9Nm5B+1ibM+SEW1vG
r9Me23kQaRwSEn01pKa8re/0uoer7lTap7DUYrpagHgkciUFAmM2VxsWH3Qs
+Cz/bRfoifk1HtKBRriAUFQ8ZhszfTb22XTiB3KFqfPinuOMbOcEIwN52k+1
zzOPfqYGpH8FhQM1nNu8EIdocbm10MEtQYlBBkHQ7810DCxTI3OlRDbZB78E
9YukKmhcZ+nS5yaYFbZatmF8QEVFgkpPvqLOaUh/NKRbCiBoLRjie2LrAf4W
Jju5Q/s6uOmakSMn1PNORmbI8q6eWwzF0m6rtQSa8X5bZy8yPwnvlPo+j+yo
6vMggjyWbg0mdmdR2Vjxjzc8eCdVrr9q82lOSTkHtno/f3c4BmVGAH0qokmn
VKZm46hqEVXS8rx2N5JkR2NxxKl7bSvgTvOdeR3HuIPpusFNK9nmHI9Tm4mS
QPl4X7gBBX23XpiSqp1bJCfuOdExlNrflNfFdGM7/TBG0xdcnB2t23N67BPn
ALiXe+uaYZFGrcAUWCKV5aXtlH1ExFlyCxCHFlOumuWKhEo9BRy2v9Dak9fv
L/ZSdkms5tYx6RipkrsjLZ1ZVpaSdbaV3hIWsJ0XXP8ElmBKhCpeMmg7ZSxJ
pNCq2MB4bhntacfB8qi+ha4Kpsi1gaAMPJVDRHmvXVXATyalDz8dR0eqwSw+
L87H5WXZlkqaQeWwuGFnZ2un2aCj5knQN3eJAYr/oT9kxwWOZWE5bCKmrzrx
p+QiclFF0i9B29E4+sSDapoTyaFawuQytvIrHqfF3V5mKDYu6eqe7mvqgcTt
mBI8IyYa1KBOUq9lCgWjSiJ21HNOaB8qXPiFoBNUIiqZC5JwQy1thpSnTrHz
aqolkm99tLs7WVksZOPhIjO7uihPUEW/ae37ewdxkRHevyMdx+K6l+/CLpND
CxS8VAvQNye23RlGrJgT9WXxwgQayk0P2lR0suOQm7WuaRTAHNTnXK6cQqe6
vllhxe3FtUA4bLusmyZkakteG+t+HAclSRNkRdAKRq4sjTQUijtnGM1TWg1l
cKYocaAkHFZQHlrIuCifoPIN576w01VKEYVBcSLeTIpm46se09WS4YL2Jrnr
0/TzFxqUw6zLJHXCb1r8VZ7R5FZ9WW+vSovclQRo7obbn9CRF+v5yspI6Voq
8iDw31Mp1bE/pv99tU//Pjk9PYXP8WvwPNdQIQtsXOEj8fRh79PPEk8fpZ4+
onI3iaeP008fnODjWl1EQcr6K0BWy4vIkWBqMoHMnMSAuszPfF8/Bm6BlHVR
YDHefwyAUyBLAviIn1YYwMJHO+FwZnYXwQIR1ckQr1winiuTRvqUx9lvyk2t
HeVF+dyGwVdAdW0Dg9Ad15f1iCXkMLMO/sLsLfhrWq8xJEKYNioeWCvFFQHz
rtcH1Bjyf2AO/AvmgP/KFPCJhncvxwfFePwNMI0PQH3yfMSP0Wf8M+p987ke
J71ycHh0/DT3A+T52z+kXyWkP9366svLnlcdBrmHw7/y/P1Z6tWj9IJPglcv
/5x+Nbng8NXv3zoMduF5gr7VMoHBDkX/6G1VfRX+9IrvxM6ATQ9QocT8Qucs
8hmQkpWaoMBeEvxMHOQ/PHfqYSQyAb3JLYpFDwYUJkekHN2Dzrzl8cPocQxB
2vL4UfQ4SFWrmy3PH0fPL0ANuOk9eaz08bCjTxD2L1s6McYBRAEfjDUYDZxc
F3SDsuXrwvgFwJSg/NIFt3KTX7fVTbKGo0mnLBFXIKyusmXdttVkHjfL6Cww
SjG+Ep+OueIDKiklBGngbHsoL3ez98f5N2s2Azl8t2NToXyDb4OgKpAbe+HK
NZOdSKJLOTBGNjvutE4I7lPec5/SPCXrv7WU3pu8svRND1/Pfp1ri39gAX1P
P/jumhtj7i+R+R2PH4aPnwRyweffrx6BoXPHqEhDourLq6qhhsWb/Mn5h1d7
KEw0s0j09ZDHdFBV6G0X6JQVzGQwaI9iLXMQW/vEGkMJo0vbmD1QZU8p4lLt
I3zdSMqwieOV5lPaftGKdUnpJIs0a3UbTr324eJwQE/BOkSRWqpeWJShMrsO
dBtpIMuQVMb1bTGZb9z1xEXVzXWxqP4mxVOovc2aCWBmvZiTco6OToWqmvcT
ZTkoVJb9UBUWr1hh1b1MF2gNCdLKIurk3aIhCkTApBFDYHRVNe3KpWxgZEM0
to9/kgax+iy3qb5Ra2bH95kgNdtc1t779gBB1FoGnF3EJpWl5IYnlT9EVUYl
PsNHPu0NgzOdGfHcJfz2TZ71T87ATpsQ+bw044Lt1A4ytGAp9NJZrANZkqzL
PnrlKOuZ8Xk63RMNOsfijKHhsRtv5RCwSJiQM7XYuuMO0ccYE5j9qwsk5GBZ
F626szPhuOpA3QaoDaUrFnaFH82mvksIPDSQ1i3ueuTGCmKwQEZogfwW1+UI
D2gKx4PY2xS3grnT5ZrZJvaN53E7feFNb3ab2OvKgtQmCoeGAWJScwpjZN/D
wBsO0KJ7muihLpAj1oulJ76aOQ6CWT9fHYwPsvy7ul2dIkuvx8JKxtP6NpMM
oIR/xA1C7pFh53cKQGPXSZ65ifLD/f383T9n+csa/T+r0RuqJ3yaHz5HNV2/
ZWfSjjlxXMqbGWDE0yA/1STwgaDOyDpy6JjhGfej/R7f+0QRuc4O2qYGjMbS
pHOQZ5uKBr9ZrZanX30Vw/Er7036SsYaDN3LvjQbjbHLFTXgFz/JAIPiV1pY
8WsuCt4NLtijFoVv4oowZOYrrihfPGJp8jqvy7+GRHVwmv9L+jiHCUD+m3/Z
5nwEm8H1SGGRQfB1LqFiNONYWN2YJB8/rj52knzMP/UpCz8YOE/bXwHS87r+
uF4qrKft3w/tgggHwqT3FZNH93/jMeHfKpPgZ5ZIHnh4fS8/4EhZeQwPNT7T
hx+pqKLJ8/wvO878VznPBx5nYhpqCseHpKp5dIxF7wsPv4pL0gJ/tctIduBf
6xpue+f/94N7/EXsO8Pg0HYcX/9N/XVGfwBKsAA9UtnW4cbj8IJH+apckpnh
ETih8+K0j0IM+2IaO7adrxeY+/FnG7wfAvQY0imh/u+4ezzcP5ALfg7hG8Oq
BeJ9GspQ1JNtyJvxfz45e5fWR6iaWWzgOv/wSj1dmOoR6rv60M+dWn8dM5U6
rykn0igvGl3rzVizvJhg74JqQfmsxva1x523MdeYtK1gLS5Eq7L1q51JKotN
UlYXHkpmtkSNRgHCztJg0ywkYCAu/OptDqZehkYUxwl1NgERI2SikHYTzM3r
PcP4oUWQJu123DFXP08VoSXnEsWrZbdlc03mKNh65+Vng8B4solqxFgje1Qk
0qTicg6ui7fsX++RX2+W+F5aFKZs8s+6mzyS7zFLLPMegcAk5WtduV1Wq25S
Qaf72uHRQPRsUrNTWozXuHsU7l592xKYrdo2FXbA/8Q6d6xyHx88z3Yo3HbS
LENqw7q2Up5BlIqE7FXIyc8+oohEqbQQ4egdvI0PHZXl4XTyrHw+Ozmavbgq
Js8OJi8mR8fTydWzk+Pjo5Ojg6dPjw/LgRL+7jyxVNKZY7o/LfcPjybPT549
L55NXpTT/f2jw+OTZ0eTF8/Lp8cnT09mB1cnswETRCSVNNsgyVwSSHBKyyJ1
AKZT75GsOIGk8jxeFHieXBOpp4/6nj6hlX7KmGL3Z48rPf7iIIdnfu4rsbOb
OO/IBCUyzIkMzu4vZl5r243pnVqxbQPikBCHLjwdpuu32x9oqBXZxHzhJRfQ
pwvnaG4mpaa0J9JkzafpcTS2WeAnj2t+CyGgajW9WvZ/ATWIL/3B04deeiOX
yNXXvYmMEfO2rjAXe1N3P/JMpPauDNnRrp1G/enhJO/p8f5/k7xfm+QNTu2x
dgmfHpqjbf704Kv3Z2nKePD3Dfv2Dz3DPvv7xn15+Vhie7iN2B7+6sR2izNt
K8HV4usdeuumNals1K+nX7g86RHWTjgXAoXlbjE8Eg03Yf08n80lcnBa5Iok
X+oM4VZHHRB75N8sKf/G6VWJNWNhJV+mzJQjs3luJnf5NpSX2cWO274tvcsr
60nGJenaJ3c9IIdxHLR3sZs8lnOoAp2lk3wZyPegDhAIuN5qnBOcEo2HMHhj
k88CuZkiWP7v5I7PHsofHskdEeY7uN/Rg57S8+vjklttz4/glM9OTv6bU/76
ygEaIJHn6PGcop21VzV4Lk+H7GiL0exBHPCEB/7ccZEDJtc7OFWOuoO5Hz0K
Ekd/NyQu/5we9++FxPdvHysLHG2TBY5+dVmgz+7qX9eQn7S1NQhfNBkfVj+T
Yhw9wkOCA6kFhoqqU6H7Vg1NGECmZDRl6klYc/gMh1JOehPxyoeAwJXE7eVI
8Pw/gBcdHh78Oryog80RPUD47XiGbX5bH9Jj7WFMj3IBpLDxkezr2fF/s69f
mX0dMBWGVfV7WPWnXd6dPoerfX+rwWzrIjB49/OmxyjhXUxo+8RHnz3x4S4u
tX3i479n4sexseNtbOwY2Nh30gUz7OXkq02n+RhwAGBezUY0EfTTs5VNFVVt
N5q8b6x9dUPvK1MoNMPc1ziCzlv7q3E5NnkCiSY5Jjs1I8NgbzOXLfyEl/iP
UG+ODn8dltKHihRln2IUW54/HPTpMi5U4zGU/+jwsxWXvJf0Wzb6OOLvKPOz
FwdPZ9P9wxf708Nn+0+Pnx9Mj18cFIeT46sr0LWPnx9OjqZXJ4cPpMxbD8A7
hh0QSbymjCWO1FNSs/VgesfBVCYZ50GUw0XDOhLylEkI+tkf7BPeLv2mA3ut
TGzMX10HuYndBaxQikOLjqsAJAJrk/ec1/MPMfI//ZXuOYYUnM6mh8lLLT8e
Px23zd2LLU+c4AOj6XyNTVee9933VMwCnsejrv/hi4duve/6b7t1HhxqRP45
gUmn+fE+/Ml/P9msMK+Cseo0fwrfvawBX/XyRQDcPuZBYsTD9IARvLePe5Ja
6oFbanC/fQmcl0EJHLjJ8MvFS8xiRtNwcPn7a6r0lte4QqMiaITkoaeSiKty
ulo3LnWPshAmBQdNUPVqTl+5KbVaja40i1b6xJU+ictY7+ngwbhUt4/q0s83
p1mxhgewKEMlyjOm7lw3UkmXVmUzq56wRBG/lQVvWZC0e8N8WSP2YnEOzJJs
q4YqLl6vqxl3D0cTqhuReld05+UicW4kzDG6BSV9ir1h0TKL1Z/vm3pxnTl3
arcURG7LP+xRtborzlso5mbHWWLm8idQ6+W8imAdLRbfoOS3uPgJzpp1Z102
1R1moRAPwY0CP2g0ZeyuqOamlLFLTqmmZZtJIbWCK+Vo0SYqlRNURVK5FMNt
XIMveRkbNUmOfV9FNluThY0QyHAqeA4LDsG0d/AVNl8FfF/BeluuGmKTXmyN
UH6BHc+8sqDiLy/al+y6pVLzd2Uxd8NzRk3VZAVg+h2BpsHiRZyj1pT11VBz
0m4L9GhglsuaCgXjaLc1CAPV3whRuNAAjLRaFdSlt1GkxMpd6+aurObzgppv
vKk+lvcVug6CGlSECWHtVgsvaadM3YFddaCi8WlAgFwNSBvNmu+/pOngfjOz
32nQWUGxh7sx+0L+Blu0ioqMkeHGJ6WHxxyBL0040EhVrhgHlusG98MjY4Nr
cpK4pBHEuWaFkAwgtVxPlAeha6Z24QIrWsQUu1w0Wt83oAc+k1HVDYeimaKZ
KQIB54SQxraZCzKntemaZdiNe7pu2fJmq+ahRrib/uRd+mOpwMBS2U7V6j0R
tXZTk3Cco3gcPMOmLHzVvIgc+LqymopGp0WgvKmub8j3eFtwZRrUPKmphK++
KCZObGaYBb0mzKJiJgLHO8rffxYELQU/xcTaaYFlCyZ22Q43bMsxqRlEZSax
oYpYdeFSz8sCrxaMAm/R4Dj/DHhPMWN6jdr1BsSEW8Dhv8q2kGZ7ocmRGimP
jth7V1czj7stPrDgvqhM6Jp6gjWRDJVVuBazermSatE54zLJ8yuZm8oOgqoR
t/fYgk9ctzxM9ad4zUUttZ2rWwrfpTb03JjR1pynVTIbdCXhEXNk4b4piQDa
lXOzrdjpIMgtrkhH48gYrhCfZF+nOQ6XcssHZx74ozfFhsqi5tiEEPvS5e+W
cMaaffwER93LzxfThltWzvMfljPqQPkDzcETji5wFa/vkN3RYE8uLl7vDRiK
z5+/UMR9mb6TIWaehdQjDwQqGD0owGdIPZJYMs97EQAGWdW3sD5H+81MeK7n
YoAxlbOoO7wFJo47r7DqP0Zbt0INooDaCdZw9Qm4qt8lKvbeUso0otMC4O/X
6gdDYTsgLbAILluxdOUNf/hwrjWzOQTcc2wpxrxx/e5yGCQxi2bG2rb1PA1F
tU0cvQPaclcV1GSByH1pZucXlFNICrqhPQjn/EwSaO8LMpcRwRC+LXSymODF
pGZ905rapwIJwZKIMT2qSdxSyYrq82VUiXfVYEYttlF1hwSrFPkAv0dVoJFh
zWiw1LoBaQQJhgxLFQVpPKTNPByNJUz8mmqzMXLOSsyeWFGkesvFN5N05cX4
MNXOF+8KRpdoqUEgUzcL7mUTqSwmDHzV1NRyEc9Y+S+N1FTtR33ohtFO4i76
612aFkX2Yjkq9fvXl6PbetbXvKi/gmFNV/IjxjYzLS7aSloRu1oF2D6yvl/M
a2AjQCqBySzW2LC4NU3FvAeNgDWd1g1eMWr2E15UYQF8V5PrFtyzveyYskr6
PTCbVUF1f/W+YDM/7dthSNEhXh6qZRvJPWrRVThESe3VtNT58SK71t4i+Gtl
G8ff3UKwlDRVCvyJ/ZmubnRuWyQENSH9Ysf4P6blWmmD64BQuVca5IMtyQtI
gki/19lN0AGxWDGzW3HN3LCqb22LdWvWufS69hFFWtYYADk047A5Leg40Cdn
ckAWNkEmCCqY4AuHwSHIjGdZrrNREUgXXJWBrltM6jVjcBHW0UZEXsT6gxyy
O2Crt9h2K3AoR9GRuKtJNXi1FfC2Q5AtmoPoHkJUMbgX/A5cjwc/xq3h+d7f
MNGyNyyclpQVVbRHaAcBZrPU0VQAxEUAJUtaPCYl0nKQOz/yiXkFU3kCZ7Y0
LACSGFYSf/fitlRVRRJbWxr9zNFnEFlOUBmO5Cy+Y6p5Sm12FatIOLt8c5Ef
gCbBoxwfn2CdcHiHvz+ksei3p4fuN6yuroPgv6lKU3mPEePcTIUwGkcoQOLG
Kg0cjECDLcprkEIZNku+tmjomGKvX67gjEQqtFH1VVa3el5s1PyN6VzaUlke
eSvTW9ElLL6dtaBJVIVda79dch9TedZwlMAwAVNSBWO32nDe4PZkO2aO7SIb
vTd2+ixk1V98kYKK78bbAat2AefCRQa4tAQDzqEP96Scs0sUuVwzX2rP+Mto
NMp+Yaj+kl+sJyv5pM3viLD8cjri/4NHrYb1S94xTMN3Uf8kN+GeztY/hDHr
y0Dpfr17lN8X7Udz/M4iiBhQjjHpD16FazCH0/jtAOhrCd/R/rFICnY4NcvL
MgWJ/th3FK4zaMsvUJ9ME27bA/8PSrx8u1+cBdAgy1Bh4gqZ3d9eL6Y1KQRR
SXf4vecnDlCesfg897qGlyp9nfqggzC1CzZohQJAKYTo8OkLwuG+CvOwnJ6f
LHfE6yOt/ogxLmb08Pp2qdxG6OV7tW1LfzCputyr1EVCMSW9EFsQU0t3tX19
mZlRtNyDg9gGtYN1y5BwNNc7thCGLHZLmPw9mtLaG2QT9m51J9U+ZfYpPZvW
Nnpuv859E98Yt3zrEAGIjk8eSuxnak40y4zqLsyXY6ip+rU+h2sNK7+reUBL
vEukNVZpRvs1VkRDaQbb34D4PZv52tjaNsVgGuWC+rtrdXeY+PviGtRsFuOf
tHvoG5K7kKOXpvQGCfdrCFfnjr1FUxNdavKx+rL6MW6pNQpVDhgQBXlnukSn
rpmTRIzviyk6f9ob/pGmgLtYhst9D5CD8/h/i9vl1wAW0IS9VbVmTWHKZayu
1g2BM4IEXr8zUi/bL5XXla6KqeA51eon2zi+gvaed2+R3Ig+S8x/4R+glfGg
D5riJZvucLVNPZ+X9JZLKnu9uAbqSu2B8ssCJK5va2rmi5td1adwoa5/V5Wr
q3HdXEuT4J2s/ucvUOLgnzo9XJyNgqQSBCPaV9mgiC+Q8kXxon26is4zGKaI
Nr/Az2PXcss7fcsQYFkysvnOkeNf8u+kT9pGDv/cpOb9YtgUUplX2vZD6yd6
Jsx8GGOtkFFLw0L8pzR03bNfU1KCnwd/29kyRDaGdSfCGU5+5RkwPNKPhEVI
/PhvkXg8YCgnCHTOyMkD6SOnmsCX3OVWcIzomtSDFH/JGIhLg73VKux6gK7B
Nl8vKjQcs0poKqK1TE0aKRgvEmGsqbIGXaNVDMakoOzWZdFUjWTWSKXHms3s
qVG4nc1L05t5AqApy0VXCPa3yFHs7VfNdHwekfQ/g40DuN4trBGhalt2warp
yJUI3DUF1aflvk5zpv03lambPOjsoDWvahMuI1E7rn/cNYahfcVbzW13LNvs
i1RaauqUsjConOcTjh6wRdC/MqDaaEpdeBIf9arqbtWPQLoJAEpLbm6YT5E3
3OWf0ZFer0FEBOrLIQTTBE7QPFl6Hqlt2t2QX0mW/UmX7b3IOxGpav1aVny8
/cugxsD3xAFnlRdZW8CPFuVTaqPILX0jcJrGbHhruM8jW2DiY7PQBpYc4b11
ALiqEAZJ1KhGXi12yGR51CmizzSVXEnSaKbr8b3peihJ2BDMrLPwWqwFlNj/
q8bYqkplT7o3KhayojLU7PG1bS8NZjGEfNRbtSpvWz/KTTn9SF3lgJAhaePt
kx0dta/eLVXUsXlNNi9l73ryK+5cktDy/RmKpbXtIAl7HLntSM4nyGAycFOZ
eYq+VfRGJVcYVMDE9qcFlrksUdyf2RrAljFI91XNAzkZIMHZKl6EO37gimiD
NmoFLcC4sLi1C+MDQqDbkarND8fcBPAw4bPMpKv21kO0CD/s0CRH57cQA0Uk
5rmumoHHN8eWCDsuSwxRfFU/4DKaUxHqnH9c1PdAIkW0GARA+l9kDqObuIH7
InFC03I+HwKFf0mO6Bpw3XTN2fOZ2rqy81aCkyKs1OY+CfLkbej8R0Hzv4Jw
RV0YyuxMlbcejMcUppBq7vN/ruq1ygghkTV9fTsLWNSnLLGWuzDDECkxSWLX
8zpahGKPjBYupAdUDkCdDSnKbJMSzIn9IKWVHw7IaLnOust/0lTuQQzUrd0M
h1QDxhrBpKNln0Nl7LF2UbuwOhC30Y6FDi62aOUUJcRNTlBT3TtlH41tZ2Z2
k1hq4BcgctJOm2ri9ad4qSK37th64C8CgTQaBVs59J+O1EJp2+qa6m5d4dGc
v778Fka/q+A9Nl4dHKKlHHCPaQxzCDbcOjhqJMl10bgC2FvwAq3WM+Gxfa4N
ZRcuQmqMDbVa3+gRxxc3XLAp18N2RsE3OTmnbJPwwooZrn8kDwFiJLF6x/YY
9uevKCCRevCKqjXRnhNULcYvy8QN3jhF1vgGN7bUzNiFc+AT6Mx2bkwDukxd
jLxB1zpbJBpH4slQ6na2+0622sacDCdiYszaDZlWyPwZ6FqBY11wFkYdLZgV
G21een3WGQmX6DFGeOIOq3Y5LzYMXbSxLK5bMe+SXUKsnGqeAIImtELid4Ju
BYn7tckCt1kkeln7EAqNpokpOr34pmt1co7s6wEiyh39NoxT7UPIxyLF6USA
DEUedtRmjvq5jojuGO3RhSiZP/F2TX59hByg3cOzuEqzeHv4CQ0OJV+c6CEc
f2jPIgEFGMuTW75ckYqgx0SuO+VRzhCE+PKeEo+z3H8rAIpF+e0qTKwyhIrv
pTq1om4JYc+/CHxokxVrdghojCcfzSldQfKmjc6gIcqgiFVF66t8YNhKoVVN
SKNxRrBT6Y/uQ2zpsha5oy6u/bpBtxn6QW6JImXio3bPk8LkaRBN4AY3fWi6
pWG6dQk1bKB3dp7bkrzsN49r3evLvcTcCy82nUP0M11kV9Nx4npNSrxAt6+y
vJDlzljgfvOha8Ec4/xC5NTkgOSExzAimHmwdX8DaVCOWiNFv1Ggq4uKYreC
XkvfOqF/QK9csv2Nfdz8VRwdRYMFbuiQgwUkzxkVXOxLQJqoE7fAW1g4wdwN
6xY4FIcJhpDSmpRVz8yVcsYNzs/oXTZKcJe7YCJRTzvO1BeVK+XOoILyG5JE
eNvNRqc///BqSD+a5hsmDF5+05gx6kgpQXjJ9XEQ1LahnNd9JgE1bYqkuwY/
GKXn21GM/T4UK7y7Kgfmq55O2nw/sDneaQeewP3+5wVzXHIjBXd9J/riIQC4
4NTJckTBk+xFcwKdezR9jK2u2kae0XX0OQRjF1GyKNm5ipyOTGs3pUViNtu6
ZXKso5wZof0iZXVmUxtcCJRa0W6PkRNDYdWw/VHVcJS8/lvt+YinGGFNl8JE
yv4GkwWW1mBuOdtpfgY8tJ6XxcILSg5c1VX3pJSgsKEHAbT0PuauUuuUnIjt
4sJ6UsbQzcWkmzNP2mm5KJqqhtufwNtp0TSMb5l0f+/6sE0mTCc+LB0bJipZ
NyYscOM6W3/8nGYOeSsgxT9H8hkByGcVTOtr7B21WEkYXP4EG/Je7TFd55Eo
Qnl6A2I14dOcXRs94W+wOm2RAwv7CYMrN2PxyITOb+fdi4PQ0la2oZrYqFAa
dyUtKEHifrHbqxfppungOfFG8jP4yK/kkdTZstBAn/RJ6rMuliT0ZdnYJJ0j
jtWNZ0nHKA2Z7lDeVSf6znRDEm8/JVKE+l2i7TSGuVI9HiyS/f7upFuRVN7F
KG9mUZnGAjfGvxBZx8P1mf0oQXL5sfgAZeKsKf2jSeuXwXhZLOeHCmb+MAWT
cjW8Jz3lRXYO/AvXSvsR/uHAsepiEMeYfCxGZznaB7lqnX81wLeUbzVAKw61
eqT+2wTWX6PsZg9XdkUMqFw8U1LlDc6V29znEuTjQ6cD43gagbqGt/x8RUzO
11AMyJ72oKT64Uk1XEVFnQgjT4A4sXIT48Vpales7jSNt7TfmqbsAGvM6Cqd
M4j52GQThPKM8+9K6bTeFaT56OiKsVHK5aiYbDHUU2rx+CVYEEUIWXa1XoEM
8zfW64KgooLWjCwnbAK368oy7+JMNBeYhVm0j9TTXAx0SFxYMYDhfdLHxJMc
dmzflRwMXOTXGGufnIA1ozlmQKLyXWkUAcst4uHboWsNMRJMw1jRALsUoc4g
btWM4E34q13ucc2ZrgQrHWglh1TnDIU2Lyj262Oe4m2VpHpwV1J47JwiHaK0
q/jZg1c9EouEwmlOS1PcOvmiE4sYJIEvYryiAKs+6672WOBQd5fIjefCUYqy
EM6+wLX4dGHdLKeIY9A7p+s9JMD9g7FQVy7PjQazCxITsjG0ohXzFm73zOWZ
2GCKo3H+ENEhjqnuFYa2C3DaQj4RtRwJO4YxdjssF8Z1HIaHOCYYmMnemmxj
CmnZjhAsUgaerMaawEjY5JPTDBGnZpi+uVmcKMWSIR5EN0gdA+7PpqjKzcvZ
NQsVP39RTD9K8Rm2q7SSNUeVg2npxeJj/qoAsfcl0rAnl/Xi+q9V/sOiogwA
aiZKmQfwa4tKqX3sq78U89I+qwy1ajjur5qsJV60zsuimSMoZk1xhRm3lzT1
pl4z8sMT/7sq6vzPVQEo+iQeeQgrwFW+qQBf/wx7/1MhdtI/Vn8tNtnv182k
WFT5kz9itCTn/UqI61WzrlaoVHuUB9rwpsCQrUl1zTCgJb4qFosNRl+Wf8uf
+MnxTF8Wt6CDFi3rrm/WcHRYi6WB+9UCOMp5eVVj9pwBQdauJxjmSoFQDbuV
rkDlnsCh0Cjt+hqUOwcgLGNRaxiFt/FkIP3l+A72osm/BRWBIsxcLp7BnVjK
oix7n4X78xdX8vbIvz3Ct0fl8nbkHhSM2TFa4MYLs4Tc6MCZM47HRRjq7N5U
065vbws29uEgFJeD7UDvbWNf0ITXt4ts6XoxR/4KGVb7JVODX34nD94Rgdos
KFw1rQqZcEsW5uubfA4q99yyy3hKghOl/GybMX/IjNmCiftdGUzIQgIbP8zM
Q4ktcv44ryYIhlAw6fXNqLuHX4AoM+1KThloCYIDnGgBkB0xp9uTbwLXiy7g
dSCrPnn9aq/zvg/iTL8kKSbJl0Sq/sW64cgo3rMAQpW+sfDHaCx26UVjOc7x
5PX7vXh5+qMbyOgAQLjSasHQAtD9ROvhn5jZj+InSJTsXR4myIYLg290XZoh
oxOEeTNuzA8dU/HrVwpFerEBhtUPOR68Y28eAR5smeG9qHm/6Axu1Y+Bw3c7
vc4GOjeLyp6Y8xGN4N0gXFknebXVePuLtXAOkzK1B1cQ78APh9Yik770w3tH
9EWl7mUCSV0b6TZo2v8fkozN8RWcAQA=

-->
</rfc>