rfc9240.original.xml		rfc9240.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
			<!DOCTYPE rfc>
			<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
			-ietf-alto-unified-props-new-24" number="9240" obsoletes="" updates="" submissio
			nType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" toc
			Depth="3" sortRefs="true" symRefs="true" version="3">
	<!-- [rfced] v23 was approved. Authors submitted v24 before we even added the do
	c 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 neede
	d. -->
	<?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"?>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
	-ietf-alto-unified-props-new-24" category="std" obsoletes="" updates="" submissi
	onType="IETF" xml:lang="en" tocInclude="true" tocDepth="3" sortRefs="true" symRe
	fs="true" version="3">
	<!-- xml2rfc v2v3 conversion 2.40.0 -->		<!-- xml2rfc v2v3 conversion 2.40.0 -->
	<front>		<front>
			<!-- [rfced] May we update the title to expand the acronym ALTO as follows?
			Current:
			An ALTO Extension: Entity Property Maps
			Perhaps:
			An Extension for Application-Layer Traffic Optimization (ALTO): Entity Proper
			ty Maps
			-->
	<title abbrev="Entity Property Maps">An ALTO Extension: Entity Property Maps </title>		<title abbrev="Entity Property Maps">An ALTO Extension: Entity Property Maps </title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-alto-unified-props-new-2 4"/>		<seriesInfo name="RFC" value="9240"/>
	<author initials="W." surname="Roome" fullname="Wendy Roome">		<author initials="W." surname="Roome" fullname="Wendy Roome">
	<organization abbrev="Nokia Bell Labs">Nokia Bell Labs (Retired)</organiza tion>		<organization abbrev="Nokia Bell Labs">Nokia Bell Labs (Retired)</organiza tion>
	<address>		<address>
	<postal>		<postal>
	<street>124 Burlington Rd</street>		<street>124 Burlington Rd</street>
	<city>Murray Hill</city>		<city>Murray Hill</city>
	<region>NJ</region>		<region>NJ</region>
	<code>07974</code>		<code>07974</code>
	<country>USA</country>		<country>United States of America</country>
	</postal>		</postal>
	<phone>+1-908-464-6975</phone>		<phone>+1-908-464-6975</phone>
	<email>wendy@wdroome.com</email>		<email>wendy@wdroome.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy">		<author initials="S." surname="Randriamasy" fullname="Sabine Randriamasy">
	<organization>Nokia Bell Labs</organization>		<organization>Nokia Bell Labs</organization>
	<address>		<address>
	<postal>		<postal>
	<street>Route de Villejust</street>		<street>Route de Villejust</street>
	<city>NOZAY</city>		<city>NOZAY</city>
	<code>91460</code>		<code>91460</code>
	<country>FRANCE</country>		<country>France</country>
	</postal>		</postal>
	<email>Sabine.Randriamasy@nokia-bell-labs.com</email>		<email>Sabine.Randriamasy@nokia-bell-labs.com</email>
	</address>		</address>
	</author>		</author>
	<author initials="Y." surname="Yang" fullname="Y. Richard Yang">		<author initials="Y." surname="Yang" fullname="Y. Richard Yang">
	<organization>Yale University</organization>		<organization>Yale University</organization>
	<address>		<address>
	<postal>		<postal>
	<street>51 Prospect Street</street>		<street>51 Prospect Street</street>
	<city>New Haven</city>		<city>New Haven</city>
	<code>CT 06511</code>		<region>CT</region>
	<country>USA</country>		<code>06511</code>
			<country>United States of America</country>
	</postal>		</postal>
	<phone>+1-203-432-6400</phone>		<phone>+1-203-432-6400</phone>
	<email>yry@cs.yale.edu</email>		<email>yry@cs.yale.edu</email>
	</address>		</address>
	</author>		</author>
	<author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang">		<author initials="J." surname="Zhang" fullname="Jingxuan Jensen Zhang">
	<organization>Tongji University</organization>		<organization>Tongji University</organization>
	<address>		<address>
	<postal>		<postal>
	<street>4800 Cao'An Hwy</street>		<street>4800 Cao'An Hwy</street>
	skipping to change at line 86 ¶		skipping to change at line 81 ¶
	<address>		<address>
	<postal>		<postal>
	<street>No.24 South Section 1, Yihuan Road</street>		<street>No.24 South Section 1, Yihuan Road</street>
	<city>Chengdu</city>		<city>Chengdu</city>
	<code>610000</code>		<code>610000</code>
	<country>China</country>		<country>China</country>
	</postal>		</postal>
	<email>kaigao@scu.edu.cn</email>		<email>kaigao@scu.edu.cn</email>
	</address>		</address>
	</author>		</author>
	<date year="2022" month="February" day="28"/>		<date year="2022" month="May"/>
	<area>Networks</area>		<area>tsv</area>
	<workgroup>ALTO WG</workgroup>		<workgroup>alto</workgroup>
	<keyword>ALTO</keyword>		<keyword>ALTO</keyword>
	<abstract>		<abstract>
	<t>This document specifies an extension to the base		<t>This document specifies an extension to the base
	Application-Layer Traffic Optimization (ALTO)		Application-Layer Traffic Optimization (ALTO)
	protocol that generalizes the concept of "endpoint properties",		Protocol that generalizes the concept of "endpoint properties",
	which were so far tied to IP addresses,		which have been tied to IP addresses so far,
	to entities defined by a wide set of objects.		to entities defined by a wide set of objects.
	Further, these properties are presented as maps, similar to the		Further, these properties are presented as maps, similar to the
	network and cost maps in the base ALTO protocol.		network and cost maps in the base ALTO Protocol.
	While supporting the endpoints and related endpoint property service defi		While supporting the endpoints and related Endpoint Property Service defi
	ned in RFC7285,		ned in RFC 7285,
	the ALTO protocol is extended in two major directions.		the ALTO Protocol is extended in two major directions.
	First, from endpoints restricted to IP addresses to		First, from endpoints restricted to IP addresses to
	entities covering a wider and extensible set of objects; second, from		entities covering a wider and extensible set of objects; second, from
	properties on specific endpoints to entire entity property maps. These		properties for specific endpoints to entire entity property maps. These
	extensions introduce additional features allowing entities and property		extensions introduce additional features that allow entities and property
	values to be specific to a given information resource. This is made possi ble		values to be specific to a given information resource. This is made possi ble
	by a generic and flexible design of entity and property types.</t>		by a generic and flexible design of entity and property types.</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="introduction" numbered="true" toc="default">		<section anchor="introduction" numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>The ALTO protocol <xref target="RFC7285" format="default"/> introduce s		<t>The ALTO Protocol <xref target="RFC7285" format="default"/> introduce s
	the concept of "properties" attached to "endpoint addresses".		the concept of "properties" attached to "endpoint addresses".
	It also defines the Endpoint Property Service (EPS) to		It also defines the Endpoint Property Service (EPS) to
	allow ALTO clients to retrieve those properties. While useful, the EPS, a		allow ALTO clients to retrieve those properties. While useful, the EPS as
	s		defined in <xref target="RFC7285" format="default"/> has at least three l
	defined in <xref target="RFC7285" format="default"/>, has at least three		imitations,
	limitations		which are elaborated here.</t>
	that are further elaborated hereafter.</t>		<!-- [rfced] FYI: There are multiple XML comments left by the authors. We have
			marked these with [auth]. Please review and let us know if any updates
			are necessary. Note that these comments will be removed before the
			document is published.
			-->
			<!-- [rfced] Section 1: It is unclear in the following sentence whether both
			collections and PIDs are being discussed.
	<t>First, the EPS allows properties to be associated with only endpoints t		Original:
	hat		It is reasonable to think that collections of endpoints
			or Provider-Defined Identifiers (PIDs),
			may also have properties.
			Perhaps (a collection can be identified by a PID):
			It is reasonable to think that collections of endpoints,
			which are identified by Provider-Defined Identifiers (PIDs),
			may also have properties.
			-->
			<t>First, the EPS allows properties to be associated only with endpoints t
			hat
	are identified by individual communication addresses like IPv4 and IPv6		are identified by individual communication addresses like IPv4 and IPv6
	addresses. It is reasonable to think that collections of endpoints		addresses. It is reasonable to think that collections of endpoints
	<!--, as defined by CIDRs <xref target="RFC4632" format="default"/> -->		<!-- [auth], as defined by CIDRs <xref target="RFC4632" format="default"/ > -->
	or Provider-Defined Identifiers (PIDs), may also have properties.		or Provider-Defined Identifiers (PIDs), may also have properties.
	<!-- Furthermore,		<!-- [auth] Furthermore,
	recent ALTO use cases show that properties of entities such as network fl ows		recent ALTO use cases show that properties of entities such as network fl ows
	<xref target="RFC7011" format="default"/>		<xref target="RFC7011" format="default"/>
	and routing elements <xref target="RFC7921" format="default"/> are also u seful.		and routing elements <xref target="RFC7921" format="default"/> are also u seful.
	Such cases are documented, for example, in <xref target="I-D.gao-alto-fcs " format="default"/>. -->		Such cases are documented, for example, in <xref target="I-D.gao-alto-fcs " format="default"/>. -->
	Furthermore, recent ALTO use cases show that properties		Furthermore, recent ALTO use cases show that properties
	of entities such as abstracted network elements as defined in		of entities such as Abstract Network Elements as defined in
	<xref target="I-D.ietf-alto-path-vector" format="default"/>		<xref target="I-D.ietf-alto-path-vector" format="default"/>
	are also useful.		are also useful.
	However, the current EPS is restricted to		However, the current EPS is restricted to
	individual endpoints and cannot be applied to those entities.</t>		individual endpoints and cannot be applied to those entities.</t>
	<t>Second, the EPS only allows endpoints identified by global communicatio n		<t>Second, the EPS only allows endpoints identified by global communicatio n
	addresses. However, an endpoint address may be a local IP address or an		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		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		such as a PID may have an identifier that is not globally unique. That is, the
	same PID may be used in multiple network maps, while in each		same PID may be used in multiple network maps, while in each
	network map, this PID points to a different set of addresses.		network map, this PID points to a different set of addresses.
	<!--		<!-- [auth]
	For		For
	example, PID "mypid10" may be defined in "netmap1" and "netmap2" while in		example, PID "mypid10" may be defined in "netmap1" and "netmap2" while in
	each network map, "mypid10" covers a different set of addresses.-->		each network map, "mypid10" covers a different set of addresses.-->
	</t>		</t>
	<t>Third, in section 11.4 of <xref target="RFC7285" format="default"/>,		<!-- [rfced] Section 1: Does the following suggestion improve the
			readability of the sentence?
			Original:
			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 an aggregation
			representation to reference endpoints to allow efficient
			enumeration.
			Perhaps (change "and uses" to "and then use", "to allow" to "in order to allow")
			:
			To avoid enumerating a large number of endpoint addresses
			inefficiently, the ALTO server might define properties for a
			sufficiently large subset of endpoints and then use an aggregation
			representation to reference endpoints in order to allow efficient
			enumeration.
			-->
			<t>Third, in <xref target="RFC7285" section="11.4" sectionFormat="of" form
			at="default"/>,
	the EPS is only defined as a POST-mode service. ALTO clients must request		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,		the properties for an explicit set of endpoint addresses. By contrast,
	<xref target="RFC7285" format="default"/>, in section 11.2.3,		<xref target="RFC7285" section="11.2.3" sectionFormat="of" format="default"/>
	defines a GET-mode cost map resource which returns all available		defines a GET-mode cost map resource that returns all available
	costs, so an ALTO Client can retrieve a full set of costs once, and then process		costs, so an ALTO Client can retrieve a full set of costs once and then process
	cost		cost
	lookups without querying the ALTO server.		lookups without querying the ALTO server.
	<xref target="RFC7285" format="default"/> does not define a		<xref target="RFC7285" format="default"/> does not define a
	similar service for endpoint properties. At first, a map of endpoint		similar service for endpoint properties. At first, a map of endpoint
	properties might seem impractical, because it could require enumerating the		properties might seem impractical because it could require enumerating the
	property value for every possible endpoint.		property value for every possible endpoint.
	In particular, the number of endpoint addresses involved by		In particular, the number of endpoint addresses involved by
	an ALTO server can be quite large. To avoid enumerating a large number		an ALTO server can be quite large. To avoid enumerating a large number
	of endpoint addresses inefficiently, the ALTO server might define		of endpoint addresses inefficiently, the ALTO server might define
	properties for a sufficiently large subset of endpoints and uses an aggregation		properties for a sufficiently large subset of endpoints and uses an aggregation
	representation to reference endpoints to allow efficient enumeration.		representation to reference endpoints to allow efficient enumeration.
	This is particularly true if blocks of		This is particularly true if blocks of
	endpoint addresses with a common prefix have the same value		endpoint addresses with a common prefix have the same value
	for a property. Entities in other domains may very well allow aggregated		for a property. Entities in other domains may very well allow aggregated
	representation and hence be enumerable as well.</t>		representation and hence be enumerable as well.</t>
	<t>To address these three limitations, this document specifies an		<t>To address these three limitations, this document specifies an
	ALTO protocol extension for defining and retrieving ALTO properties:</t>		ALTO Protocol extension for defining and retrieving ALTO properties:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The first limitation is addressed by introducing a generic		<li>The first limitation is addressed by introducing a generic
	concept called ALTO Entity, which generalizes an endpoint and may represent		concept called ALTO Entity, which generalizes an endpoint and may represent
	a PID, a network element, a cell in a cellular network, an abstracted		a PID, a network element, a cell in a cellular network, an Abstract
	network element <xref target="I-D.ietf-alto-path-vector" format="default"/>,		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		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		included in a collection called an ALTO entity domain. Since each ALTO
	entity domain includes only one type of entities, each entity domain can be		entity domain includes only one type of entity, each entity domain can be
	classified by the type of enclosed entities.</li>		classified by the type of enclosed entities.</li>
	<li>The second limitation is addressed by using resource-specific		<li>The second limitation is addressed by using resource-specific
	entity domains. A resource-specific entity domain contains entities that		entity domains. A resource-specific entity domain contains entities that
	are defined and identified with respect to a given ALTO information		are defined and identified with respect to a given ALTO information
	resource, which provides scoping. For example, an entity domain containing		resource, which provides scoping. For example, an entity domain containing
	PIDs is identified with respect to the network map in which these PIDs are		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. Likewise, an entity domain containing local IP addresses may be
	defined with respect to a local network map.</li>		defined with respect to a local network map.</li>
	<li>The third limitation is addressed by defining two new types of ALTO		<li>The third limitation is addressed by defining two new types of ALTO
	information resources: Property Map (<xref target="prop-map" format="defa ult"/>)		information resources: Property Map (<xref target="prop-map" format="defa ult"/>)
	and Filtered Property Map (<xref target="filter-prop-map" format="default "/>).		and Filtered Property Map (<xref target="filter-prop-map" format="default "/>).
	The former is a resource that is requested using the HTTP GET method,		The former is a resource that is requested using the HTTP GET method,
	returns the property values for all entities in one or more		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		entity domains, and is analogous to a network map or a cost map in
	Section 11.2 of <xref target="RFC7285" format="default"/>.		<xref target="RFC7285" section="11.2" sectionFormat="of" format="default"
	The latter is a resource that that is requested using the HTTP POST metho		/>.
	d,		The latter is a resource that is requested using the HTTP POST method,
	returns the values for		returns the values for
	sets of properties and entities requested by the client, and is analogous		sets of properties and entities requested by the client, and is analogous
	to a filtered network map or a filtered cost map.</li>		to a filtered network map or a filtered cost map.</li>
	</ul>		</ul>
	<t>The Entity Property Maps extension described in this document introduce s a		<t>The Entity Property Maps extension described in this document introduce s a
	number of features that are summarized in		number of features that are summarized in
	<xref target="features-introduced-with-epm-extension" format="default"/>,		<xref target="features-introduced-with-epm-extension" format="default"/>,
	where <xref target="TableUPFeatures" format="default"/> lists		where <xref target="TableUPFeatures" format="default"/> lists
	the features and references the sections in this document that give		the features and references the sections in this document that give
	their high-level and their normative description.</t>		their high-level and their normative descriptions.</t>
	<t>The protocol extension defined in this document is augmentable. New ent ity		<t>The protocol extension defined in this document can be augmented. New e ntity
	domain types can be defined without revising the present specification.		domain types can be defined without revising the present specification.
	Similarly, new cost metrics and new endpoint properties can be		Similarly, new cost metrics and new endpoint properties can be
	defined in other documents without revising the protocol specification		defined in other documents without revising the protocol specification
	defined in <xref target="RFC7285" format="default"/>.</t>		defined in <xref target="RFC7285" format="default"/>.</t>
	<section anchor="terminology" numbered="true" toc="default">		<section anchor="terminology" numbered="true" toc="default">
	<name>Terminology and notation</name>		<name>Terminology and Notation</name>
	<t>This document uses the following terms and abbreviations, that will b		<t>This document uses the following terms and abbreviations that will be
	e
	further defined in the document. While this document introduces the feature		further defined in the document. While this document introduces the feature
	"entity property map", it will use both the term "property map" and "entity		"entity property map", it will use both the term "property map" and "entity
	property map" to refer to this feature.</t>		property map" to refer to this feature.</t>
	<ul spacing="normal">		<dl spacing="normal">
	<li>Transaction: A request/response exchange between an ALTO client an		<dt>Transaction:</dt>
	d an ALTO server.</li>		<dd>A request/response exchange between an ALTO client and an ALTO ser
	<li>Client: When used with a capital "C", this term refers to an ALTO		ver.</dd>
	client.
	Note that expressions "ALTO client", "ALTO Client" and "Client" are eq		<!-- [rfced] Section 1.1: We note that RFC 7285 mainly uses lowercase for
	uivalent. </li>		"ALTO client" and "ALTO server" and that this document does not seem to
	<li>Server: When used with a capital "S", this term refers to an ALTO		use lowercase "client" and "server" for applications. May we update the
	server.		document and the following descriptions to do the same?
	Note that expressions "ALTO server", "ALTO Server" and "Server" are eq
	uivalent.</li>		Current:
	<li>EPS: An abbreviation for Endpoint Property Service.</li>
	</ul>		Client: When used with a capital "C", this term refers to an ALTO
	<t>This document uses the semi-formal notation defined in Section 8.2		client. Note that expressions "ALTO client", "ALTO Client", and
	of <xref target="RFC7285" format="default"/>.</t>		"Client" are equivalent.
			Server: When used with a capital "S", this term refers to an ALTO
			server. Note that expressions "ALTO server", "ALTO Server", and
			"Server" are equivalent.
			Perhaps:
			Client: "ALTO client" and "client" are equivalent.
			Server: "ALTO server" and "server" are equivalent.
			-->
			<dt>Client:</dt>
			<dd>When used with a capital "C", this term refers to an ALTO client.
			Note that expressions "ALTO client", "ALTO Client", and "Client" are e
			quivalent. </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", and "Server" are e
			quivalent.</dd>
			<dt>EPS:</dt>
			<dd>An abbreviation for Endpoint Property Service.</dd>
			</dl>
			<!-- [rfced] Section 1.1: FYI, we have removed the term "semi-formal" from the
			following sentence because in American English the term refers to
			clothing or occasions. Please let us know if any changes are needed:
			Original:
			This document uses the semi-formal notation defined in Section 8.2 of
			[RFC7285].
			Current:
			This document uses the notation defined in Section 8.2 of [RFC7285].
			-->
			<t>This document uses the notation defined in
			<xref target="RFC7285" section="8.2" sectionFormat="of" format="default"/>
			.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="requirements-language" numbered="true" toc="default">		<section anchor="requirements-language" numbered="true" toc="default">
	<name>Requirements Language</name>		<name>Requirements Language</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH		<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
	OULD",		>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this		SHOULD</bcp14>",
	document are to be interpreted as described in BCP 14 <xref target="RFC2119" for		"<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMEND
	mat="default"/> <xref target="RFC8174" format="default"/>		ED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this
	when, and only when, they appear in all capitals, as shown here. When the		document are to be interpreted as described in BCP 14 <xref target="RFC2119" for
	words appear in lower case, they are to be interpreted with their natural		mat="default"/> <xref target="RFC8174" format="default"/>
	language meanings.</t>		when, and only when, they appear in all capitals, as shown here.</t>
	</section>		</section>
	<section anchor="basic-features-of-the-unified-property-extension" numbered= "true" toc="default">		<section anchor="basic-features-of-the-unified-property-extension" numbered= "true" toc="default">
	<name>Basic Features of the Entity Property Map Extension</name>		<name>Basic Features of the Entity Property Map Extension</name>
	<t>This section gives a high-level overview of the basic features involved in		<t>This section gives a high-level overview of the basic features involved in
	ALTO Entity Property Maps. It assumes the reader is familiar with the ALTO		ALTO Entity Property Maps. It assumes the reader is familiar with the ALTO
	protocol <xref target="RFC7285" format="default"/>. The purpose of this extensio		Protocol <xref target="RFC7285" format="default"/>. The purpose of this extensio
	n is to convey		n is to convey
	properties on objects that extend ALTO Endpoints and are called ALTO		properties for objects that extend ALTO endpoints and are called ALTO
	Entities, or entities for short.</t>		Entities, or entities for short.</t>
	<t>The features introduced in this section can be used as standalone. Howe ver,		<t>The features introduced in this section can be used standalone. However ,
	in some cases, these features may depend on particular information resources		in some cases, these features may depend on particular information resources
	and need to be defined with respect to them. To this end,		and need to be defined with respect to them. To this end,
	<xref target="advanced-features-of-the-unified-property-extension" format="defau lt"/> introduces		<xref target="advanced-features-of-the-unified-property-extension" format="defau lt"/> introduces
	additional features that extend the ones presented in the present section.		additional features that extend the ones presented in this section.
	</t>		</t>
	<section anchor="con-entity" numbered="true" toc="default">		<section anchor="con-entity" numbered="true" toc="default">
	<name>Entity</name>		<name>Entity</name>
	<t>The concept of an ALTO Entity generalizes the concept of an ALTO Endp		<t>The concept of an ALTO Entity generalizes the concept of an ALTO endp
	oint		oint
	defined in Section 2.1 of <xref target="RFC7285" format="default"/>.		defined in <xref target="RFC7285" section="2.1" sectionFormat="of" format="defau
			lt"/>.
	An entity is an object that can be an		An entity is an object that can be an
	endpoint defined by its network address, but can also be an object		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		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		object that is not even related to any network address. Thus, whereas all
	endpoints are entities, not all entities are endpoints.</t>		endpoints are entities, not all entities are endpoints.</t>
	<!-- Examples of entities -->
	<t>Examples of entities are:</t>		<t>Examples of entities are:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>an ALTO endpoint		<li>an ALTO endpoint
	that represents an application or a host identified by a communication address		that represents an application or a host identified by a communication address
	(e.g., an IPv4 or IPv6 address) in a network,</li>		(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 human-readable		<li>a PID, defined in <xref target="RFC7285" format="default"/>, that has a provider-defined, human-readable
	identifier specified by an ALTO network map, which maps a PID to a set of		identifier specified by an ALTO network map, which maps a PID to a set of
	IPv4 and IPv6 addresses,		IPv4 and IPv6 addresses,
	</li>		</li>
	<li>an Autonomous System (AS), that has an AS number (ASN) as its iden tifier		<li>an Autonomous System (AS) that has an AS number (ASN) as its ident ifier
	and maps to a set of IPv4 and IPv6 addresses,		and maps to a set of IPv4 and IPv6 addresses,
	that is defined in <xref target="I-D.ietf-alto-cdni-request-routi ng-alto" format="default"/>,		which is defined in <xref target="RFC9241" format="default"/>,
	</li>		</li>
	<li>a country with a code specified in <xref target="ISO3166-1" format		<li>a country with a code specified in <xref target="ISO3166-1" format
	="default"/>,		="default"/>
	to which applications such as CDN providers associate properties and c		to which applications such as content delivery network (CDN) providers
	apabilities,		associate properties and capabilities,
	that is defined in <xref target="I-D.ietf-alto-cdni-request-routing-al		which is defined in <xref target="RFC9241" format="default"/>,
	to" format="default"/>,
	</li>		</li>
	<li>a TCP/UDP network flow, that is identified by a TCP/UDP 5-tuple sp		<!-- [rfced] Section 3.1: Does clarifying that a network flow can be either
	ecifying		TCP or UDP improve the readability of the sentence?:
			Current:
			* a TCP/UDP network flow that is identified by a TCP/UDP 5-tuple
			specifying its source and destination addresses and port numbers,
			and the IP protocol,
			Perhaps:
			* a TCP or UDP network flow that is identified by a 5-tuple
			specifying its source and destination addresses and port numbers,
			and the IP protocol (TCP or UDP),
			-->
			<li>a TCP/UDP network flow that is identified by a TCP/UDP 5-tuple spe
			cifying
	its source and destination addresses and port numbers, and the IP protocol,		its source and destination addresses and port numbers, and the IP protocol,
	</li>		</li>
	<li>a routing element, that is specified in <xref target="RFC7921" for		<li>a routing element, as specified in <xref target="RFC7921" format="
	mat="default"/> and is associated with		default"/>, that is associated with
	routing capabilities information,</li>		routing capabilities information, or</li>
	<li>an abstract network element,		<li>an Abstract Network Element,
	that is specified in <xref target="I-D.ietf-alto-path-vector" format="		as specified in <xref target="I-D.ietf-alto-path-vector" format="defau
	default"/>		lt"/>,
	and that represents an abstraction of a network		that represents an abstraction of a network
	part such as a router, one or more links, a network domain or the		part such as a router, one or more links, a network domain, or th
	ir		eir
	aggregation.</li>		aggregation.</li>
	</ul>		</ul>
	<t>Some of the example entities listed above have already been documented as ALT O entities.		<t>Some of the example entities listed above have already been documented as ALT O entities.
	The other examples are provided for illustration as potential entities. </t>		The other examples are provided for illustration as potential entities. </t>
	</section>		</section>
	<section anchor="con-entity-domain" numbered="true" toc="default">		<section anchor="con-entity-domain" numbered="true" toc="default">
	<name>Entity Domain</name>		<name>Entity Domain</name>
	<t>An entity domain defines a set of entities of the same semantic type. An		<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>		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 nam e.		<t>In this document, an entity is owned by exactly one entity domain nam e.
	An entity identifier points to exactly one entity. If two entities in two		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		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		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,		and an IPv6 address, these two addresses will be treated as two entities,
	defined respectively in the "ipv4" and "ipv6" entity domains.</t>		defined respectively in the "ipv4" and "ipv6" entity domains.</t>
	<section anchor="con-entity-domain-type" numbered="true" toc="default">		<section anchor="con-entity-domain-type" numbered="true" toc="default">
	<name>Entity Domain Type</name>		<name>Entity Domain Type</name>
			<!-- [rfced] Section 3.2.1: The following sentence is hard to parse because of
			the repetition of the term "type":
			Current:
			The type of an entity domain type defines the semantics of a type of
			entity.
			Perhaps:
			The entity domain type defines the semantics of the type of
			entity found in an entity domain.
			-->
			<!-- [rfced] Section 3.2.1: Does adding the "countrycode" identifier to the
			following improve the readability of the following?
			Current:
			The entity domain type that defines
			country codes is introduced in [RFC9241].
			Perhaps:
			The "countrycode" entity domain type that defines
			country codes is introduced in [RFC9241].
			-->
	<t>The type of an entity domain type defines the semantics of a type o f entity.		<t>The type of an entity domain type defines the semantics of a type o f entity.
	Entity domain types can be defined in different documents. For example: t he		Entity domain types can be defined in different documents. For example: t he
	present document defines entity domain types "ipv4", "ipv6" and "pid" in		present document defines entity domain types "ipv4" and "ipv6" in <xref t
	<xref target="inet-addr-domain" format="default"/> and <xref target="pid-		arget="inet-addr-domain" format="default"/>
	domain" format="default"/>.		and "pid"
			in <xref target="pid-domain" format="default"/>.
	The entity domain type		The entity domain type
	"ane", that defines Abstract Network Elements (ANEs), is introduced in		"ane", which defines Abstract Network Elements (ANEs), is introduced in
	<xref target="I-D.ietf-alto-path-vector" format="default"/>.		<xref target="I-D.ietf-alto-path-vector" format="default"/>.
	The entity domain type that defines country		The entity domain type that defines country
	codes is introduced in <xref target="I-D.ietf-alto-cdni-request-routing-a		codes is introduced in <xref target="RFC9241" format="default"/>. An enti
	lto" format="default"/>. An entity		ty
	domain type MUST be registered at the IANA, as specified in		domain type <bcp14>MUST</bcp14> be registered with IANA, as specified in
	<xref target="dom-reg-process" format="default"/>.</t>		<xref target="dom-reg-process" format="default"/>.</t>
	</section>		</section>
	<section anchor="con-entity-domain-name" numbered="true" toc="default">		<section anchor="con-entity-domain-name" numbered="true" toc="default">
	<name>Entity Domain Name</name>		<name>Entity Domain Name</name>
			<!-- [rfced] Section 3.2.2: Does changing "is defined in the scope of" to
			"is scoped to" improve readability?
			Current:
			The identifier of an entity domain is defined
			in the scope of an ALTO server.
			Perhaps:
			The identifier of an entity domain is
			scoped to an ALTO server.
			-->
			<!-- [rfced] Section 3.2.2: We are having difficulty determining what provides
			entity properties in the following. Is it the server or the information
			resources?
			Current:
			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 entity properties
			for this domain.
			Possibly (the server provides the properties):
			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, which provides entity properties
			for this domain.
			-->
	<t>		<t>
	In this document, the identifier of an entity domain is mostly ca lled "entity domain name".		In this document, the identifier of an entity domain is mostly ca lled "entity domain name".
	The identifier of an entity domain is defined in the scope of an ALTO server.		The identifier of an entity domain is defined in the scope of an ALTO server.
	An entity domain identifier can sometimes be identical to the ide ntifier		An entity domain identifier can sometimes be identical to the ide ntifier
	of its relevant entity domain type.		of its relevant entity domain type.
	This is the case when the entities of a domain have an		This is the case when the entities of a domain have an
	identifier that points to the same object throughout all the info rmation		identifier that points to the same object throughout all the info rmation
	resources of the Server that provide entity properties for this d omain. For		resources of the Server that provide entity properties for this d omain. For
	example, a domain of type "ipv4" containing entities that are ide ntified by a public		example, a domain of type "ipv4" containing entities that are ide ntified by a public
	IPv4 address can be named "ipv4" because its entities are uniquel y identified		IPv4 address can be named "ipv4" because its entities are uniquel y identified
	by all the Server resources.</t>		by all the Server resources.</t>
	<t>In some cases, the name of an entity domain cannot be		<t>In some cases, the name of an entity domain cannot be
	simply its entity domain type.		simply its entity domain type.
	Indeed, for some domain types, entities are defined relative to a given		Indeed, for some domain types, entities are defined relative to a given
	information resource. This is the case for entities of domain typ e "pid". A		information resource. This is the case for entities of domain typ e "pid". A
	PID is defined relative to a network map. For example, an entity "mypid10" of		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 un defined in		domain type "pid" may be defined in a given network map and be un defined in
	other network maps. Or "mypid10" may even be defined in two diffe		other network maps. The entity "mypid10" may even be defined in t
	rent network		wo different network
	maps and map, in each of these network maps, to a different set o		maps, and it may map in each of these network maps to a different
	f endpoint		set of endpoint
	addresses. In this case, naming an entity domain only by its type "pid" does		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 en tity domain.</t>		not guarantee that its set of entities is owned by exactly one en tity domain.</t>
	<t><xref target="rsed-name" format="default"/> and		<t>Sections <xref target="rsed-name" format="counter"/> and
	<xref target="domain-names" format="default"/>		<xref target="domain-names" format="counter"/>
	describe how a domain is uniquely identified, across the ALTO		describe how a domain is uniquely identified across the ALTO
	server, by a name that associates the domain type and the related		server by a name that associates the domain type and the related
	information		information
	resource.</t>		resource.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="con-property" numbered="true" toc="default">		<section anchor="con-property" numbered="true" toc="default">
	<name>Entity Property Type</name>		<name>Entity Property Type</name>
	<t>An entity property defines a property of an entity. This is similar t o the		<t>An entity property defines a property of an entity. This is similar t o the
	endpoint property defined in Section 7.1 of <xref target="RFC7285" format="defau lt"/>. An entity property		endpoint property defined in <xref target="RFC7285" section="7.1" sectionFormat= "of" format="default"/>. An entity property
	can convey either network-aware or network-agnostic information. Similar to		can convey either network-aware or network-agnostic information. Similar to
	an entity domain, an entity property is characterized by a type and		an entity domain, an entity property is characterized by a type and
	identified by a name. An entity property type MUST be registered at the		identified by a name. An entity property type <bcp14>MUST</bcp14> be registered with
	IANA, as specified in <xref target="IANAEntityProp" format="default"/>.</t>		IANA, as specified in <xref target="IANAEntityProp" format="default"/>.</t>
	<t>Below are listed some examples with real and fictitious entity domain and property		<t>Below are listed some examples with real and fictitious entity domain and property
	names:</t>		names:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>an entity in the "ipv4" domain type may have a property whose valu e is an		<li>an entity in the "ipv4" domain type may have a property whose valu e is an
	Autonomous System (AS) number indicating the AS to which this IPv4 address		Autonomous System (AS) number indicating the AS to which this IPv4 address
	belongs and another property named "countrycode" indicating a country code mappi ng		belongs and another property named "countrycode" indicating a country code mappi ng
	to this address,</li>		to this address,</li>
	<li>an entity identified by its country code in the entity domain type		<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"		"countrycode", defined in <xref target="RFC9241" format="default"/>, may
	format="default"/> may		have a property indicating what delivery protocol is used by a CDN, or</li>
	have a property indicating what delivery protocol is used by a CDN,</li>
	<li>an entity in the "netmap1.pid" domain may have a property that ind icates		<li>an entity in the "netmap1.pid" domain may have a property that ind icates
	the central geographical location of the endpoints it includes.</li>		the central geographical location of the endpoints it includes.</li>
	</ul>		</ul>
	<t>It should be noted that some identifiers may be used for both an enti ty		<t>It should be noted that some identifiers may be used for both an enti ty
	domain type and a property type. For example:</t>		domain type and a property type. For example:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>the identifier "countrycode" may point to both the entity domain t ype		<li>the identifier "countrycode" may point to both the entity domain t ype
	"countrycode" and the fictitious property type "countrycode".</li>		"countrycode" and the fictitious property type "countrycode".</li>
	<li>the identifier "pid" may point to both the entity domain type "pid " and the		<li>the identifier "pid" may point to both the entity domain type "pid " and the
	property type "pid".</li>		property type "pid".</li>
	</ul>		</ul>
	<t>Likewise, the same identifier may point to both a domain name and a p roperty		<t>Likewise, the same identifier may point to both a domain name and a p roperty
	name. For example: the identifier "netmap10.pid" may point to either the		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		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 that		returns, for an entity defined by its IPv4 address, the PID of "netmap10" that
	contains this entity. Such cases will be further explained in		contains this entity. Such cases are further explained in
	<xref target="advanced-features-of-the-unified-property-extension" format="defau lt"/>.</t>		<xref target="advanced-features-of-the-unified-property-extension" format="defau lt"/>.</t>
	</section>		</section>
	<section anchor="con-propmap" numbered="true" toc="default">		<section anchor="con-propmap" numbered="true" toc="default">
	<name>New Information Resource and Media Type: ALTO Property Map</name>		<name>New Information Resource and Media Type: ALTO Property Map</name>
	<t>This document introduces a new ALTO information resource named Proper ty Map.		<t>This document introduces a new ALTO information resource named Proper ty Map.
	An ALTO property map provides a set of properties on one or more sets of		An ALTO property map provides a set of properties for one or more sets of
	entities. A property may apply to different entity domain types and names.		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		For example, an ALTO property map may define the "ASN" property for both
	"ipv4" and "ipv6" entity domains.</t>		"ipv4" and "ipv6" entity domains.</t>
	<t>The present extension also introduces a new media type.</t>		<t>The present extension also introduces a new media type.</t>
	<t>This document uses the same definition of an information resource as		<t>This document uses the same definition of an information resource as
	Section		<xref target="RFC7285" section="9.1" sectionFormat="of" format="default"/>. ALTO
	9.1 of <xref target="RFC7285" format="default"/>. ALTO uses media types to uniqu		uses media types to uniquely indicate the data
	ely indicate the data
	format used to encode the content to be transmitted between an ALTO server		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		and an ALTO client in the HTTP entity body. In the present case, an ALTO
	property map resource is		property map resource is
	<!-- represented by a JSON object of type InfoResourcePropertyMap and -->		<!-- [auth] represented by a JSON object of type InfoResourcePropertyMap and -->
	defined by the media type "application/alto-propmap+json".</t>		defined by the media type "application/alto-propmap+json".</t>
	<t>A Property Map can be queried as a GET-mode resource, thus conveying all		<t>A Property Map can be queried as a GET-mode resource, thus conveying all
	properties on all entities indicated in its capabilities. It can also be		properties for all entities indicated in its capabilities. It can also be
	queried as a POST-mode resource, thus conveying a selection of properties on		queried as a POST-mode resource, thus conveying a selection of properties for
	a selection of entities.</t>		a selection of entities.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="advanced-features-of-the-unified-property-extension" number ed="true" toc="default">		<section anchor="advanced-features-of-the-unified-property-extension" number ed="true" toc="default">
	<name>Advanced Features of the Entity Property Map Extension</name>		<name>Advanced Features of the Entity Property Map Extension</name>
	<t>This section gives a high-level overview of the advanced features		<t>This section gives a high-level overview of the advanced features
	involved in ALTO Entity Property Maps. Most of these features are		involved in ALTO Entity Property Maps. Most of these features
	defined to extend the ones defined in		extend the features defined in
	<xref target="basic-features-of-the-unified-property-extension" format="default" />.</t>		<xref target="basic-features-of-the-unified-property-extension" format="default" />.</t>
	<section anchor="entity-identifier-and-entity-domain" numbered="true" toc= "default">		<section anchor="entity-identifier-and-entity-domain" numbered="true" toc= "default">
	<name>Entity Identifier and Entity Domain Name</name>		<name>Entity Identifier and Entity Domain Name</name>
	<t>In <xref target="RFC7285" format="default"/>, an endpoint has an iden tifier that is explicitly associated		<t>In <xref target="RFC7285" format="default"/>, an endpoint has an iden tifier that is explicitly associated
	with the "ipv4" or "ipv6" address domain. Examples are "ipv4:192.0.2.14" and		with the "ipv4" or "ipv6" address domain. Examples are "ipv4:192.0.2.14" and
	"ipv6:2001:db8::12".</t>		"ipv6:2001:db8::12".</t>
	<t>In this document, example IPv4 and IPv6 addresses and prefixes are tak en		<t>In this document, example IPv4 and IPv6 addresses and prefixes are tak en
	from the address ranges reserved for documentation by		from the address ranges reserved for documentation by
	<xref target="RFC5737" format="default"/> and		<xref target="RFC5737" format="default"/> and
	<xref target="RFC3849" format="default"/>.		<xref target="RFC3849" format="default"/>.
	</t>		</t>
	<t>In this document, an entity must be owned by exactly one entity		<t>In this document, an entity must be owned by exactly one entity
	domain name and an entity identifier must point to exactly one		domain name, and an entity identifier must point to exactly one
	entity. To ensure this, an entity identifier is explicitly attached		entity. To ensure this, an entity identifier is explicitly attached
	to the name of its entity domain and an entity domain type		to the name of its entity domain, and an entity domain type
	characterizes the semantics and identifier format of its entities.		characterizes the semantics and identifier format of its entities.
	</t>		</t>
	<t>The encoding format of an entity identifier is further specified in		<t>The encoding format of an entity identifier is further specified in
	<xref target="entity-addrs" format="default"/> of this document.</t>		<xref target="entity-addrs" format="default"/> of this document.</t>
	<t>For instance:</t>		<t>For instance:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>if an entity is an endpoint with IPv4 address		<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		"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 "net map2",		<li>if an entity is a PID named "mypid10" in network map resource "net map2",
	its identifier is associated with entity domain name "netmap2.pid" and is		its identifier is associated with entity domain name "netmap2.pid" and is
	"netmap2.pid:mypid10".</li>		"netmap2.pid:mypid10".</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="rsed-name" numbered="true" toc="default">		<section anchor="rsed-name" numbered="true" toc="default">
	<name>Resource-Specific Entity Domain Name</name>		<name>Resource-Specific Entity Domain Name</name>
	<t>Some entities are defined and identified uniquely and globally		<t>Some entities are defined and identified uniquely and globally
	in the context of an ALTO server. This is the		in the context of an ALTO server. This is the
	case for instance when entities are endpoints that are identified by a		case, for instance, when entities are endpoints that are identified by a
	reachable IPv4 or IPv6 address. The entity domain for such entities can be		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		globally defined and named "ipv4" or "ipv6". Those entity domains are called
	resource-agnostic entity domains in this document, as they are not associated		resource-agnostic entity domains in this document, as they are not associated
	with any specific ALTO information resources.</t>		with any specific ALTO information resources.</t>
	<t>Some other entities and entity types are only defined relative to a g iven		<t>Some other entities and entity types are only defined relative to a g iven
	information resource. This is the case for entities of domain type "pid",		information resource. This is the case for entities of domain type "pid",
	that can only be understood with respect to the network map where they are		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		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		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		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		another set S2 of IP addresses. The identifier "pid:mypid10" may thus point
	to different objects because the information on the originating information		to different objects because the information on the originating information
	resource is lost.</t>		resource is lost.</t>
	<t>To solve this ambiguity, the present extension introduces the concept of		<t>To solve this ambiguity, the present extension introduces the concept of
	resources-specific entity domain. This concept applies to domain types where		resource-specific entity domain. This concept applies to domain types where
	entities are defined relative to a given information resource. It can also		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		apply to entity domains that are defined locally, such as local networks of
	objects identified with a local IPv4 address.</t>		objects identified with a local IPv4 address.</t>
	<t>In such cases, an entity domain type is explicitly associated with an		<t>In such cases, an entity domain type is explicitly associated with an
	identifier of the information resource where these entities are defined. Such		identifier of the information resource where these entities are defined. Such
	an information resource is referred to as the "specific information		an information resource is referred to as the "specific information
	resource". Using a resource-aware entity domain name, an ALTO property map		resource". Using a resource-aware entity domain name, an ALTO property map
	can unambiguously identify distinct entity domains of the same type, on which		can unambiguously identify distinct entity domains of the same type, on which
	entity properties may be queried. Examples of resource-specific entity domain		entity properties may be queried. Examples of resource-specific entity domain
	names may look like: "netmap1.pid" or "netmap2.pid". Thus, a name association		names may look like "netmap1.pid" or "netmap2.pid". Thus, a name association
	such as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" allows to distinguish		such as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" distinguishes
	the two abovementioned PIDs that are both named "mypid10" but in two		the two abovementioned PIDs that are both named "mypid10" but in two
	different resources, "netmap1" and "netmap2".</t>		different resources, "netmap1" and "netmap2".</t>
	<t>An information resource is defined in the scope of an ALTO Server and so is		<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		an entity domain name. The format of a resource-specific entity domain name
	is further specified in <xref target="domain-names" format="default"/>.</t>		is further specified in <xref target="domain-names" format="default"/>.</t>
	</section>		</section>
	<section anchor="rsep" numbered="true" toc="default">		<section anchor="rsep" numbered="true" toc="default">
	<name>Resource-Specific Entity Property Value</name>		<name>Resource-Specific Entity Property Value</name>
	<t>Like entity domains, some types of properties are defined relative to an		<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,		information resource. That is, an entity may have a property of a given type
	whose values are associated to different information resources.</t>		whose values are associated with different information resources.</t>
	<t>For example, suppose entity "192.0.2.34" defined in the "ipv4" domain has a		<t>For example, suppose entity "192.0.2.34" defined in the "ipv4" domain has a
	property of type "pid", whose value is the PID to which address "192.0.2.34"		property of type "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		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		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		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		"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		for this property can be a different value in "netmap1" and
	"netmap2".</t>		"netmap2".</t>
	<t>To support information resource dependent property values, this docum		<t>To support information-resource-dependent property values, this docum
	ent uses		ent uses
	the same approach as in Section 10.8.1 of <xref target="RFC7285" format="default		the same approach as in Section <xref target="RFC7285" section="10.8.1" sectionF
	"/> entitled		ormat="bare">
	"Resource-Specific Endpoint Properties". When a property value depends on a		"Resource-Specific Endpoint Properties"</xref> of <xref target="RFC7285" format=
	given information resource, the name of this property MUST be explicitly		"default"/>. When a property value depends on a
			given information resource, the name of this property <bcp14>MUST</bcp14> be exp
			licitly
	associated with the information resource that defines it.</t>		associated with the information resource that defines it.</t>
	<t>For example, the property "pid" queried on entity "ipv4:192.0.2.34" a nd		<t>For example, the property "pid" queried on entity "ipv4:192.0.2.34" a nd
	defined in both "netmap1" and "netmap2", can be named "netmap1.pid" and		defined in both "netmap1" and "netmap2" can be named "netmap1.pid" and
	"netmap2.pid". This allows a Client to get a property of the same type but		"netmap2.pid". This allows a Client to get a property of the same type but
	defined in different information resources with a single query.		defined in different information resources with a single query.
	Specifications on the property name format are provided in <xref target="def-pro perty" format="default"/>.</t>		Specifications for the property name format are provided in <xref target="def-pr operty" format="default"/>.</t>
	</section>		</section>
	<section anchor="con-hni" numbered="true" toc="default">		<section anchor="con-hni" numbered="true" toc="default">
	<name>Entity Hierarchy and Property Inheritance</name>		<name>Entity Hierarchy and Property Inheritance</name>
	<t>For some domain types, there is an underlying structure that allows e ntities to		<t>For some domain types, there is an underlying structure that allows e ntities to
	efficiently be grouped into a set and be defined by the identifier of thi s set.		be efficiently grouped into a set and be defined by the identifier of thi s set.
	This is the case for domain types "ipv4" and "ipv6",		This is the case for domain types "ipv4" and "ipv6",
	where individual Internet addresses can be grouped in blocks. When the sa me		where individual Internet addresses can be grouped in blocks. When the sa me
	property value applies to a whole set, a Server can define a property for the		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		identifier of this set instead of enumerating all the entities and their
	properties. This allows a substantial reduction of transmission payload b oth		properties. This allows a substantial reduction of transmission payload b oth
	for the Server and the Client. For example, all the entities included in the		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		set defined by the address block "ipv6:2001:db8::1/64" share the same
	properties and values defined for this block.</t>		properties and values defined for this block.</t>
	<t>Additionally, entity sets sometimes are related by inclusion, hierarc hy or		<t>Additionally, entity sets sometimes are related by inclusion, hierarc hy, or
	other relations. This allows defining inheritance rules for entity proper ties		other relations. This allows defining inheritance rules for entity proper ties
	that propagate properties among related entity sets. The Server and the		that propagate properties among related entity sets. The Server and the
	Client can use these inheritance rules for further payload savings. Entit y		Client can use these inheritance rules for further payload savings. Entit y
	hierarchy and property inheritance rules are specified in the documents t hat		hierarchy and property inheritance rules are specified in the documents t hat
	define the applicable domain types. The present document defines these ru les		define the applicable domain types. The present document defines these ru les
	for the "ipv4" and "ipv6" domain types.</t>		for the "ipv4" and "ipv6" domain types.</t>
	<t>This document introduces, for applicable domain types, "Entity Proper		<!-- [rfced] Section 4.4: Is the use of quotations marks and capitalization here
	ty		required?
	Inheritance rules", with the following concepts: Entity Hierarchy, Proper
	ty		Current:
	Inheritance and Property Value Unicity. A detailed specification of entit		For applicable domain types, this document introduces "Entity
	y		Property Inheritance rules" with the following concepts: Entity
			Hierarchy, Property Inheritance, and Property Value Unicity.
			Perhaps:
			For applicable domain types, this document introduces entity
			property inheritance rules with the following concepts: entity
			hierarchy, property inheritance, and property value unicity.
			-->
			<t>For applicable domain types, this document introduces "Entity Propert
			y
			Inheritance rules" with the following concepts: Entity Hierarchy, Propert
			y
			Inheritance, and Property Value Unicity. A detailed specification of enti
			ty
	hierarchy and property inheritance rules is provided in		hierarchy and property inheritance rules is provided in
	<xref target="def-hierarchy-and-inheritance" format="default"/>.</t>		<xref target="def-hierarchy-and-inheritance" format="default"/>.</t>
	<section anchor="entity-hierarchy" numbered="true" toc="default">		<section anchor="entity-hierarchy" numbered="true" toc="default">
	<name>Entity Hierarchy</name>		<name>Entity Hierarchy</name>
	<t>An entity domain may allow using a single identifier to identify a		<t>An entity domain may allow the use of a single identifier to identi
	set of		fy a set of
	related individual entities. For example, a CIDR block can be use		related individual entities. For example, a Classless Inter-Domai
	d to identify a set		n Routing
			(CIDR) block can be used to identify a set
	of IPv4 or IPv6 entities. A CIDR block is called a hierarchical e ntity		of IPv4 or IPv6 entities. A CIDR block is called a hierarchical e ntity
	identifier, as it can reflect inclusion relations among entity se ts.		identifier, as it can reflect inclusion relations among entity se ts.
	That is, in an entity hierarchy, "supersets" are defined at upper levels		That is, in an entity hierarchy, "supersets" are defined at upper levels
	and include "subsets" defined at lower levels."		and include "subsets" defined at lower levels.
	For example, the CIDR "ipv4:192.0.1.0/24" includes all the indivi dual IPv4		For example, the CIDR "ipv4:192.0.1.0/24" includes all the indivi dual IPv4
	entities identified by the CIDR "ipv4:192.0.1.0/26".		entities identified by the CIDR "ipv4:192.0.1.0/26".
	This document will sometimes use the term "hierarchical address"		This document will sometimes use the term "hierarchical address"
	to refer to a hierarchical entity identifier. </t>		to refer to a hierarchical entity identifier. </t>
	</section>		</section>
	<section anchor="property-inheritance" numbered="true" toc="default">		<section anchor="property-inheritance" numbered="true" toc="default">
	<name>Property Inheritance</name>		<name>Property Inheritance</name>
	<t>A property may be defined for a hierarchical entity identifier, while it may		<t>A property may be defined for a hierarchical entity identifier, while it may
	skipping to change at line 578 ¶		skipping to change at line 719 ¶
	"ipv4:192.0.1.0/24" because the address "ipv4:192.0.1.1" is included in t he		"ipv4:192.0.1.0/24" because the address "ipv4:192.0.1.1" is included in t he
	CIDR block "ipv4:192.0.1.0/24".</t>		CIDR block "ipv4:192.0.1.0/24".</t>
	<t>Property value inheritance rules also apply among entity set s. A property map		<t>Property value inheritance rules also apply among entity set s. A property map
	may define values for an entity set belonging to a hierarchy but not for		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, inherita nce		"subsets" that are covered by this set identifier. In this case, inherita nce
	rules must specify how entities in "subsets" inherit property values from		rules must specify how entities in "subsets" inherit property values from
	their "superset".		their "superset".
	For instance, suppose a property P is defined only for the entity set def ined		For instance, suppose a property P is defined only for the entity set def ined
	by address block "ipv4:192.0.1.0/24". We know that entity set "ipv4:192.0 .1.0/30"		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"		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",		may inherit the value of property P from set "ipv4:192.0.1.0/24"
	if an inheritance rule from "ipv4" CIDR blocks to included "ipv4" CIDR bl		if an inheritance rule from "ipv4" CIDR blocks to included "ipv4" CIDR bl
	ocks, is specified.</t>		ocks is specified.</t>
	</section>		</section>
	<section anchor="property-value-unicity" numbered="true" toc="default">		<section anchor="property-value-unicity" numbered="true" toc="default">
	<name>Property Value Unicity</name>		<name>Property Value Unicity</name>
	<t>The inheritance rules must ensure that an entity belonging to a hie rarchical		<t>The inheritance rules must ensure that an entity belonging to a hie rarchical
	set of entities inherits no more than one property value, for the sake of		set of entities inherits no more than one property value, for the sake of
	consistency. Indeed, a property map may define a property on a hierarchy		consistency. Indeed, a property map may define a property for a hierarchy
	of		of
	entity sets that inherit property values from one or more supersets (loca		entity sets that inherits property values from one or more supersets (loc
	ted at upper		ated at upper
	levels). On the other hand, a property value, defined on a subset (locate		levels). On the other hand, a property value defined for a subset (locate
	d at a lower		d at a lower
	level) may be different from the value defined on a superset. In such a c		level) may be different from the value defined for a superset. In such a
	ase,		case,
	subsets may potentially end up with different property values. This may b e		subsets may potentially end up with different property values. This may b e
	the case for address blocs with increasing prefix length, on which a prop		the case for address blocks with increasing prefix length, on which a pro
	erty		perty
	value gets increasingly accurate and thus may differ. For example, a		value becomes increasingly accurate and thus may differ. For example, a
	fictitious property such as "geo-location" or "average transfer volume" m ay		fictitious property such as "geo-location" or "average transfer volume" m ay
	be defined at a progressively finer grain for lower level subsets of enti ties, defined with		be defined at a progressively finer grain for lower-level subsets of enti ties defined with
	progressively longer CIDR prefixes. It seems more interesting to have		progressively longer CIDR prefixes. It seems more interesting to have
	property values of progressively higher accuracy. A unicity rule, applied to		property values of progressively higher accuracy. A unicity rule applied to
	the entity domain type must specify an arbitration rule among the differe nt		the entity domain type must specify an arbitration rule among the differe nt
	property values for an entity. An example illustrating the need for such		property values for an entity. An example illustrating the need for such
	rules is provided in <xref target="inet-inheritance" format="default"/>.< /t>		rules is provided in <xref target="inet-inheritance" format="default"/>.< /t>
	</section>		</section>
	</section>		</section>
	<section anchor="applicable-entity-domains-and-properties-in-the-property- map-capabilities" numbered="true" toc="default">		<section anchor="applicable-entity-domains-and-properties-in-the-property- map-capabilities" numbered="true" toc="default">
	<name>Supported Properties on Entity Domains in Property Map Capabilitie s</name>		<name>Supported Properties for Entity Domains in Property Map Capabiliti es</name>
	<t>A property type is not necessarily applicable to any domain type, or an ALTO		<t>A property type is not necessarily applicable to any domain type, or an ALTO
	Server may choose not to provide a property on all applicable domains. Fo		Server may choose not to provide a property for all applicable domains. F
	r		or
	instance, a property type reflecting link bandwidth is likely not defined		instance, a property type reflecting link bandwidth is likely not defined
	on		for
	entities of a domain of type "countrycode". Therefore, an ALTO server		entities of a domain of type "countrycode". Therefore, an ALTO server
	providing Property Maps needs to specify the properties that can be queri ed		providing Property Maps needs to specify the properties that can be queri ed
	on the different entity domains it supports.</t>		on the different entity domains it supports.</t>
	<t>This document explains how the Information Resources Directory (IRD)		<t>This document explains how the Information Resource Directory (IRD)
	capabilities of a Property Map resource unambiguously expose what propert		capabilities of a Property Map resource unambiguously expose which proper
	ies		ties
	a Client can query on a given entity domain:</t>		a Client can query on a given entity domain:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>a field named "mappings" lists the names of the entity domains sup ported by		<li>a field named "mappings" lists the names of the entity domains sup ported by
	the Property Map,</li>		the Property Map, and</li>
	<li>for each listed entity domain, a list of the names of the applicab le		<li>for each listed entity domain, a list of the names of the applicab le
	properties is provided.</li>		properties is provided.</li>
	</ul>		</ul>
	<t>An example is provided in <xref target="ird-example" format="default" />.		<t>An example is provided in <xref target="ird-example" format="default" />.
	The "mappings" field associates		The "mappings" field associates
	entity domains and properties that can be resource-agnostic or		entity domains and properties that can be resource-agnostic or
	resource-specific. This allows a Client to formulate compact and unambigu ous		resource-specific. This allows a Client to formulate compact and unambigu ous
	entity property queries, possibly relating to one or more information		entity property queries, possibly relating to one or more information
	resources. In particular:</t>		resources. In particular:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>it prevents a Client from querying a property on entity domains on		<li>it prevents a Client from querying a property for entity domains f
	which it is not		or which it is not
	defined,</li>		defined;</li>
	<li>it allows a Client to query, for an entity E, values for a propert y P that		<li>it allows a Client to query, for an entity E, values for a propert y P that
	are defined in several information resources,</li>		are defined in several information resources; and</li>
	<li>it allows a Client to query a property P on entities that are defi ned in		<li>it allows a Client to query a property P on entities that are defi ned in
	several information resources.</li>		several information resources.</li>
	</ul>		</ul>
	<t>Further details are provided in <xref target="FullPropMapCapabilities " format="default"/>.</t>		<t>Further details are provided in <xref target="FullPropMapCapabilities " format="default"/>.</t>
	</section>		</section>
	<section anchor="def-ir" numbered="true" toc="default">		<section anchor="def-ir" numbered="true" toc="default">
	<name>Defining Information Resource for Resource-Specific Entity Domains </name>		<name>Defining Information Resource for Resource-Specific Entity Domains </name>
	<t>A Client willing to query properties on entities belonging to a domai n needs		<t>A Client willing to query entity properties belonging to a domain nee ds
	to know how to retrieve these entities. To this end, the Client can look up		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, see		the "mappings" field exposed in IRD capabilities of a property map; see
	<xref target="applicable-entity-domains-and-properties-in-the-property-map-capab ilities" format="default"/>.		<xref target="applicable-entity-domains-and-properties-in-the-property-map-capab ilities" format="default"/>.
	This field, in its keys, exposes all the entity domains supported by the		This field, in its keys, exposes all the entity domains supported by the
	property map. The syntax of the entity domain identifier specified in		property map. The syntax of the entity domain identifier specified in
	<xref target="domain-names" format="default"/> allows the client to infer whethe r the entity domain is		<xref target="domain-names" format="default"/> allows the client to infer whethe r the entity domain is
	resource-specific or not. The Client can extract, if applicable, the		resource-specific or not. The Client can extract, if applicable, the
	identifier of the specific resource, query the resource and retrieve the		identifier of the specific resource, query the resource, and retrieve the
	entities. For example:		entities. For example:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>an entity domain named "netmap1.ipv4" includes the IPv4 addresses that		<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		appear in the "ipv4" field of the endpoint address group of each PID in the
	network map "netmap1", and that have no meaning outside "netmap1"		network map "netmap1" and that have no meaning outside "netmap1"
	because, for instance, these are local addresses not reachable outside some priv		because, for instance, these are local addresses not reachable outside some priv
	ate network,</li>		ate network;</li>
	<li>an entity domain named "netmap1.pid" includes the PIDs listed in n etwork		<li>an entity domain named "netmap1.pid" includes the PIDs listed in n etwork
	map "netmap1".</li>		map "netmap1"; and</li>
	<li>an entity domain named "ipv4" is resource-agnostic and covers all the		<li>an entity domain named "ipv4" is resource-agnostic and covers all the
	reachable IPv4 addresses.</li>		reachable IPv4 addresses.</li>
	</ul>		</ul>
	<t>Besides, it is not possible to prevent a Server from mistakenly expos ing		<t>Besides, it is not possible to prevent a Server from mistakenly expos ing
	inappropriate associations of information resources and entity domain ty pes.		inappropriate associations of information resources and entity domain ty pes.
	To prevent failures due to invalid queries, it is necessary to inform th e Client		To prevent failures due to invalid queries, it is necessary to inform th e Client
	about which associations are allowed.		which associations are allowed.
	An informed Client will just ignore inappropriate associations ex posed by a		An informed Client will just ignore inappropriate associations ex posed by a
	Server and avoid error-prone transactions with the Server.		Server and avoid error-prone transactions with the Server.
	</t>		</t>
	<t>For example, the association "costmap3.pid" is not allowed for the fo llowing		<t>For example, the association "costmap3.pid" is not allowed for the fo llowing
	reason: although a cost map exposes PID identifiers, it does not define the		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		set of addresses included in this PID. Neither does a cost map list all the
	PIDs on which properties can be queried, because a cost map only exposes PID		PIDs on which properties can be queried because a cost map only exposes PID
	pairs on which a queried cost type is defined. Therefore, the resource		pairs on which a queried cost type is defined. Therefore, the resource
	"costmap3" does not enable a Client to extract information on the existing		"costmap3" does not enable a Client to extract information on the existing
	PID entities or on the addresses they contain.</t>		PID entities or on the addresses they contain.</t>
	<t>Instead, the cost map uses a network map, where all the PIDs used in a cost		<t>Instead, the cost map uses a network map where all the PIDs used in a cost
	map are defined together with the addresses contained by the PIDs. This		map are defined together with the addresses contained by the PIDs. This
	network map is qualified in this document as the Defining Information		network map is qualified in this document as the Defining Information
	Resource for the entity domain of type "pid" and this concept is explained in		Resource for the entity domain of type "pid", and this concept is explained in
	<xref target="defining-information-resource-and-media-type" format="default"/>.< /t>		<xref target="defining-information-resource-and-media-type" format="default"/>.< /t>
	<section anchor="defining-information-resource-and-media-type" numbered=" true" toc="default">		<section anchor="defining-information-resource-and-media-type" numbered=" true" toc="default">
	<name>Defining Information Resource and its Media Type</name>		<name>Defining Information Resource and Its Media Type</name>
	<t>For the reasons explained in <xref target="def-ir" format="default"/>,		<t>For the reasons explained in <xref target="def-ir" format="default"/>,
	this document introduces the concept of "Defining Information Resource		this document introduces the concept of "Defining Information Resource
	and its Media Type".</t>		and its Media Type".</t>
	<t>A defining information resource for an entity domain D is the informatio n		<t>A defining information resource for an entity domain D is the informatio n
	resource where entities of D are defined. That is, all the information on the		resource where entities of D are defined. That is, all the information on the
	entities of D can be retrieved in this resource.		entities of D can be retrieved in this resource.
	A defining information resource is defined for resource-specific entity d omains.		A defining information resource is defined for resource-specific entity d omains.
	It does not exist for entity domains that are not resource-specific such as		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 cover ing		"ipv4" or "ipv6". Neither does it exist for entity domains that are cover ing
	entity identifiers already defined in other standardization documents,		entity identifiers already defined in other standardization documents,
	at it is the case for country code identifiers standardized in [ISO3166-1		as is the case for country code identifiers standardized in <xref target=
	]		"ISO3166-1" format="default"/>
	or AS numbers allocated by the IANA.		or AS numbers allocated by IANA.
	This is useful for entity domain types that are by		This is useful for entity domain types that are by
	essence domain-specific, such as the "pid" domain type. It is also		essence domain-specific, such as the "pid" domain type. It is also
	useful for resource-specific entity domains constructed from		useful for resource-specific entity domains constructed from
	resource-agnostic domain types, such as network map specific domains of l ocal		resource-agnostic domain types, such as network-map-specific domains of l ocal
	IPv4 addresses.</t>		IPv4 addresses.</t>
	<t>The defining information resource of a resource-specific entity domain D ,		<t>The defining information resource of a resource-specific entity domain D ,
	when it exists, is unique and has the following specificities:</t>		when it exists, is unique and has the following characteristics:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>it has an entry in the IRD,</li>		<li>it has an entry in the IRD;</li>
	<li>it defines the entities of D,</li>		<li>it defines the entities of D;</li>
	<li>it does not use another information resource that defines these		<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 persisten		<li>it defines and exposes entity identifiers that are all persisten
	t,</li>		t; and</li>
	<li>its media type is equal to the one that is specified for the		<li>its media type is equal to the one that is specified for the
	defining information resource of an entity domain type.</ li>		defining information resource of an entity domain type.</ li>
	</ul>		</ul>
			<!-- [rfced] Section 4.6.1: We are having difficulty with the phrase "and
			related information". Does this refer to the "Media Types" IANA registry?
			Current:
			When an entity domain type allows associations with defining
			information resources, the media type of the potential defining
			information resource MUST be specified:
			* in the document that defines this entity domain type, and
			* in the "ALTO Entity Domain Types" IANA registry and related
			information.
			Perhaps:
			...
			* in the "ALTO Entity Domain Types" IANA registry, and
			* in the "Media Types" IANA registry.
			-->
	<t>A fundamental characteristic of a defining information resource is its media type.		<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		There is a unique association between an entity domain type and the media
	type of its defining information resource. When an entity domain type all ows associations		type of its defining information resource. When an entity domain type all ows associations
	with defining information resources, the media type of the potential defi ning information		with defining information resources, the media type of the potential defi ning information
	resource MUST be specified:</t>		resource <bcp14>MUST</bcp14> be specified:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>in the document that defines this entity domain type,</li>		<li>in the document that defines this entity domain type, and</li>
	<li>in the IANA ALTO Entity Domain Type Registry and related information		<li>in the "ALTO Entity Domain Types" IANA registry and related informat
	.</li>		ion.</li>
	</ul>		</ul>
	<!-- commented text		<!-- [auth] commented text
	If an entity domain type can be		If an entity domain type can be
	resource-specific, the document that defines this entity domain type must		resource-specific, the document that defines this entity domain type must
	specify the association between the entity domain type and the media type of		specify the association between the entity domain type and the media type of
	the potential defining information resource in the "ALTO Entity Domain Type		the potential defining information resource in the "ALTO Entity Domain Type
	Registry" (<xref target="IANADomain" format="default"/>) and request the additio n to the IANA.		Registry" (<xref target="IANADomain" format="default"/>) and request the additio n to the IANA.
	-->		-->
	<t>When the Client wants to use a resource-specific entity domain, it needs to		<t>When the Client wants to use a resource-specific entity domain, it needs to
	be cognizant of the media-type of its defining information resource. If the		be cognizant of the media type of its defining information resource. If the
	Server exposes a resource-specific entity domain with a		Server exposes a resource-specific entity domain with a
	non-compliant media type for the defining resource, the Client MUST ignore the		noncompliant media type for the defining resource, the Client <bcp14>MUST</bcp14 > ignore the
	entities from that entity domain to avoid errors.</t>		entities from that entity domain to avoid errors.</t>
	<!--		<!-- [auth]
	The same holds for property types whose values are defined relative to an		The same holds for property types whose values are defined relative to an
	information resource. Similarly to resource specific entity domains, the		information resource. Similarly to resource specific entity domains, the
	Client needs to be cognizant of appropriate associations of information		Client needs to be cognizant of appropriate associations of information
	resource and property types. Therefore, when specifying and registering a		resource and property types. Therefore, when specifying and registering a
	property type whose values are resource-specific, it is necessary to specify		property type whose values are resource-specific, it is necessary to specify
	the media type of its defining information resource. For example: the		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 "pid" is a network map; the
	defining information resource for property type "cdnifci-capability", defined in		defining information resource for property type "cdnifci-capability", defined in
	{{I-D.ietf-alto-cdni-request-routing-alto}} is a "cdnifci-map" information		{{I-D.ietf-alto-cdni-request-routing-alto}} is a "cdnifci-map" information
	resource, defined in that same document.		resource, defined in that same document.
	-->		-->
	</section>		</section>
	<!-- Examples of Defining Information Resources and Their Media Types -->
	<section anchor="example-specific-ir-mediatype" numbered="true" toc="defa ult">		<section anchor="example-specific-ir-mediatype" numbered="true" toc="defa ult">
	<name>Examples of Defining Information Resources and Their Media Type< /name>		<name>Examples of Defining Information Resources and Their Media Types </name>
	<t>Here are examples of defining information resource types and their media		<t>Here are examples of defining information resource types and their media
	types associated to different entity domain types:</t>		types associated with different entity domain types:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>For entity domain type "pid": the media type of the specific res		<li>For entity domain type "pid", the media type of the specific res
	ource is		ource is
	"application/alto-networkmap+json", because PIDs are defined in network map		"application/alto-networkmap+json" because PIDs are defined in network map
	resources.</li>		resources.</li>
	<li>For entity domain types "ipv4" and "ipv6": the media type of the		<li>For entity domain types "ipv4" and "ipv6", the media type of the
	specific		specific
	resource is "application/alto-networkmap+json", because IPv4 and IPv6		resource is "application/alto-networkmap+json" because IPv4 and IPv6
	addresses covered by the Server are defined in network map resources.</li>		addresses covered by the Server are defined in network map resources.</li>
	<li>For entities of domain type "ane": <xref target="I-D.ietf-alto-p		<li>For entities of domain type "ane"; <xref target="I-D.ietf-alto-p
	ath-vector" format="default"/> defines		ath-vector" format="default"/> defines
	entities named "ANE", where ANE stands for Abstracted Network Element, and		entities named "ANE", where ANE stands for Abstract Network Element, and
	the entity domain type "ane". An ANE may have a persistent identifier, say,		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		"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		"persistent-entity-id" property of this ANE. Further properties may then be
	queried on an ANE by using its persistent entity ID. These properties are		queried on an ANE by using its persistent entity ID. These properties are
	available from a persistent property map, that defines properties on a		available from a persistent property map that defines properties for a
	specific "ane" domain. Together with the persistent identifier, the Server		specific "ane" domain. Together with the persistent identifier, the Server
	also provides the property map resource identifier where the "ane" domain		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 defined. The definition of the "ane" entity domain
	containing "entity-4" is thus specific to the property map. Therefore, for		containing "entity-4" is thus specific to the property map. Therefore, for
	entities of domain type "ane" that have a persistent identifier, the media		entities of domain type "ane" that have a persistent identifier, the media
	type of the defining information resource is		type of the defining information resource is
	"application/alto-propmap+json".</li>		"application/alto-propmap+json".</li>
	<li>Last, the entity domain types "asn" and "countrycode" defined in		<li>Last, the entity domain types "asn" and "countrycode" defined in
	<xref target="I-D.ietf-alto-cdni-request-routing-alto" format="default"/> do not have a defining		<xref target="RFC9241" format="default"/> do not have a defining
	information resource. Indeed, the entity identifiers in these two entity		information resource. Indeed, the entity identifiers in these two entity
	domain types are already standardized in documents that the Client can use.</li>		domain types are already standardized in documents that the Client can use.</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="def-ir-for-irsp" numbered="true" toc="default">		<section anchor="def-ir-for-irsp" numbered="true" toc="default">
	<name>Defining Information Resource for Resource-Specific Property Value s</name>		<name>Defining Information Resources for Resource-Specific Property Valu es</name>
	<t>As explained in <xref target="rsep" format="default"/>, a property ty pe may		<t>As explained in <xref target="rsep" format="default"/>, a property ty pe may
	take values that are resource-specific. This is the case for property type		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		"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 netw ork		map. That is, the PID value returned for an IPv4 address is specific to the netw ork
	map defining this PID and may differ from one network map to another one.</t>		map defining this PID and may differ from one network map to another one.</t>
	<!--		<!-- [auth]
	Property values may be specific to different types of information resources.		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		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		value for property type "cdnifci-capab" is specific to the information
	resource "cdnifci-map", defined in		resource "cdnifci-map", defined in
	{{I-D.ietf-alto-cdni-request-routing-alto}}, while network maps do not define		{{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		property "fci-capability" for IPv4 addresses and a cdnifci-map does not
	define "pid" values for IPv4 addresses.		define "pid" values for IPv4 addresses.
	-->		-->
	<t>Another example is provided in		<t>Another example is provided in
	<xref target="I-D.ietf-alto-cdni-request-routing-alto" format="default"/>		<xref target="RFC9241" format="default"/>,
	that defines property type "cdni-capabilities". The value of this property is		which defines property type "cdni-capabilities". The value of this property is
	specific to a CDNI advertisement resource, that provides a list of CDNI		specific to a Content Delivery Network Interconnection (CDNI) Advertisement reso
			urce, which provides a list of CDNI
	capabilities. The property is provided for entity domain types "ipv4",		capabilities. The property is provided for entity domain types "ipv4",
	"ipv6", "asn" and "countrycode". A CDNI Advertisement resource does however		"ipv6", "asn", and "countrycode". However, a CDNI Advertisement resource does
	not define PID values for IPv4 addresses while a network map does not define		not define PID values for IPv4 addresses, while a network map does not define
	CDNI capabilities for IPv4 addresses.</t>		CDNI capabilities for IPv4 addresses.</t>
	<!--		<!-- [auth]
	Thus, similarly to resource specific entity domains, the Client needs to be		Thus, similarly to resource specific entity domains, the Client needs to be
	cognizant of appropriate associations of information resource and property		cognizant of appropriate associations of information resource and property
	types.		types.
	-->		-->
	<t>Similar to resource-specific entity domains, the Client needs to be		<t>Similar to resource-specific entity domains, the Client needs to be
	cognizant of appropriate associations of information resource and property		cognizant of appropriate associations of information resource and property
	types. Therefore, when specifying and registering a property type whose		types. Therefore, when specifying and registering a property type whose
	values are resource-specific, the media type of its defining information		values are resource-specific, the media type of its defining information
	resource needs to be specified. For example:</t>		resource needs to be specified. For example:</t>
	<!--		<!-- [auth]
	### Examples of defining resources media-types for properties {#example-specific -ir-mediatype-prop}		### Examples of defining resources media-types for properties {#example-specific -ir-mediatype-prop}
	-->		-->
	<!--		<!-- [auth]
	Here are some examples of specific information resources types associated to		Here are some examples of specific information resources types associated to
	entity property types and their media type.		entity property types and their media type.
	-->		-->
	<ul spacing="normal">		<ul spacing="normal">
	<li>The media type of the defining information resource for property t ype "pid"		<li>The media type of the defining information resource for property t ype "pid"
	is "application/alto-networkmap+json".</li>		is "application/alto-networkmap+json".</li>
	<li>The media type of the defining information resource for property t ype		<li>The media type of the defining information resource for property t ype
	"cdni-capabilities" defined in <xref target="I-D.ietf-alto-cdni-request-routing- alto" format="default"/>		"cdni-capabilities" defined in <xref target="RFC9241" format="default"/>
	is "application/alto-cdni+json".</li>		is "application/alto-cdni+json".</li>
	</ul>		</ul>
	</section>		</section>
	</section>		</section>
	<section anchor="protocol-specification-basic-data-types" numbered="true" to c="default">		<section anchor="protocol-specification-basic-data-types" numbered="true" to c="default">
	<name>Protocol Specification: Basic Data Types</name>		<name>Protocol Specification: Basic Data Types</name>
	<section anchor="def-domain" numbered="true" toc="default">		<section anchor="def-domain" numbered="true" toc="default">
	<name>Entity Domain</name>		<name>Entity Domain</name>
	<section anchor="domain-types" numbered="true" toc="default">		<section anchor="domain-types" numbered="true" toc="default">
	<name>Entity Domain Type</name>		<name>Entity Domain Type</name>
			<!-- [rfced] Section 5.1.1: In the following sentence, does the "MUST NOT"
			apply to the type or to the string?
			Current:
			An entity domain has a type, which is uniquely identified by a string
			that MUST be no more than 64 characters, and MUST NOT contain
			characters other than US-ASCII alphanumeric characters
			(U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
			U+002D), the colon (':', U+003A), or the low line ('_', U+005F).
			Perhaps (also changing "US-ASCII" to "ASCII"):
			An entity domain has a type that is uniquely identified by a string
			that MUST be no more than 64 characters and MUST NOT contain
			characters other than ASCII alphanumeric characters
			(U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-',
			U+002D), the colon (':', U+003A), or the low line ('_', U+005F).
			-->
	<t>An entity domain has a type, which is uniquely identified by a string th at		<t>An entity domain has a type, which is uniquely identified by a string th at
	MUST be no more than 64 characters, and MUST NOT contain characters other		<bcp14>MUST</bcp14> be no more than 64 characters, and <bcp14>MUST NOT</b cp14> contain characters other
	than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and		than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and
	U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A),		U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A),
	or the low line ('_', U+005F).</t>		or the low line ('_', U+005F).</t>
	<t>The usage of colon (':', U+003A) MUST obey the rules below:</t>		<t>The usage of colon (':', U+003A) <bcp14>MUST</bcp14> obey the rules be low:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The colon (':', U+003A) character MUST NOT appear more than once,</l		<li>The colon (':', U+003A) character <bcp14>MUST NOT</bcp14> appear mor
	i>		e than once;</li>
	<li>The colon character MUST NOT be used unless within the string "priv:		<li>The colon character <bcp14>MUST NOT</bcp14> be used unless within th
	",</li>		e string "priv:";</li>
	<li>The string "priv:" MUST NOT be used unless it starts the string that		<li>The string "priv:" <bcp14>MUST NOT</bcp14> be used unless it starts
	identifies an entity domain type,</li>		the string that identifies an entity domain type; and</li>
	<li>For an entity domain type identifier with the "priv:" prefix ,		<li>For an entity domain type identifier with the "priv:" prefix,
	an additional string (e.g., company identifier or random string)		an additional string (e.g., company identifier or random string)
	MUST follow "priv:",		<bcp14>MUST</bcp14> follow "priv:"
	to reduce potential collisions.</li>		to reduce potential collisions.</li>
	</ul>		</ul>
	<t>For example, the strings "ipv4", "ipv6", "pid" and "priv:example-test-ed		<t>For example, the strings "ipv4", "ipv6", "pid", and "priv:example-test-e
	t",		dt",
	are valid entity domain types. "ipv4.anycast", "pid.local" and "priv:" are		are valid entity domain types. "ipv4.anycast", "pid.local", and "priv:" are
	invalid.</t>		invalid.</t>
	<t>Although “_”, “-“, “__--" are valid entity domain types,		<t>Although "_", "-", "__--" are valid entity domain types,
	it is desirable to add characters such as alphanumeric ones,		it is desirable to add characters, such as alphanumeric ones,
	for better intelligibility. </t>		for better intelligibility. </t>
	<t>The type EntityDomainType is used in this document to denote a JSON stri ng		<t>The type EntityDomainType is used in this document to denote a JSON stri ng
	meeting the preceding requirements.</t>		meeting the preceding requirements.</t>
	<t>An entity domain type defines the semantics of a type of entity,		<t>An entity domain type defines the semantics of a type of entity,
	independently of any specifying resource. All entity		independently of any specifying resource. All entity
	domain types that are not prefixed with "priv:" MUST be registered with the I		domain types that are not prefixed with "priv:" <bcp14>MUST</bcp14> be regist
	ANA,		ered with IANA
	in the "ALTO Entity Domain Type Registry", defined in <xref target="IANADomai		in the "ALTO Entity Domain Types" registry, defined in <xref target="IANADoma
	n" format="default"/>,		in" format="default"/>,
	following the procedure specified in <xref target="dom-reg-process" format="d efault"/>		following the procedure specified in <xref target="dom-reg-process" format="d efault"/>
	of this document.		of this document.
	The format of the entity identifiers (see <xref target="entity-addrs" format= "default"/>)		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		in that entity domain type, as well as any hierarchical or inheritance rules
	(see <xref target="def-hierarchy-and-inheritance" format="default"/>) for		(see <xref target="def-hierarchy-and-inheritance" format="default"/>) for
	those entities, MUST be specified in the IANA registration.</t>		those entities, <bcp14>MUST</bcp14> be specified in the IANA registration.</t >
	<t>Entity domain type identifiers prefixed with "priv:" are reserved for Priv ate Use		<t>Entity domain type identifiers prefixed with "priv:" are reserved for Priv ate Use
	(see <xref target="RFC8126" format="default"/>) without a need to register wi th IANA.		(see <xref target="RFC8126" format="default"/>) without a need to register wi th IANA.
	The definition of a private use entity domain type MUST apply the same way in all		The definition of a private-use entity domain type <bcp14>MUST</bcp14> apply the same way in all
	property maps of an IRD where it is present.		property maps of an IRD where it is present.
	</t>		</t>
	</section>		</section>
	<section anchor="domain-names" numbered="true" toc="default">		<section anchor="domain-names" numbered="true" toc="default">
	<name>Entity Domain Name</name>		<name>Entity Domain Name</name>
	<t>As discussed in <xref target="con-entity-domain" format="default"/> ,		<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>		an entity domain is characterized by a type and identified by a name.< /t>
	<t>This document distinguishes three categories of entity domains:		<t>This document distinguishes three categories of entity domains:
	resource-specific entity domains, resource-agnostic entity domain s and		resource-specific entity domains, resource-agnostic entity domain s, and
	self-defined entity domains. Their entity domain names are constr ucted as		self-defined entity domains. Their entity domain names are constr ucted as
	specified in the following sub-sections.</t>		specified in the following subsections.</t>
			<!--[rfced] FYI, [RFC5511] has been moved from Informative to Normative Referenc
			es
			because it's the definition of formal language used in this document.
			-->
	<t>Each entity domain is identified by a unique entity domain name.		<t>Each entity domain is identified by a unique entity domain name.
	Borrowing the symbol "::=" from the Backus-Naur Form notation		Borrowing the symbol "::=" from the Backus-Naur Form notation
	<xref target="RFC5511" format="default"/>,		<xref target="RFC5511" format="default"/>,
	the format of an entity domain name is defined as follows:</t>		the format of an entity domain name is defined as follows:</t>
			<!-- [rfced] Should the following artwork be labeled with <sourcecode type="rbnf
			">
			instead of <artwork>?:
			Current (Section 5.1.2):
			EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType
			...
			"[ [ ResourceID ] '.' ]"
			Current (Section 5.1.2.3):
			EntityDomainName ::= '.' EntityDomainType
			Current (Section 5.1.3):
			EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID
			Current (Section 5.2.2):
			EntityPropertyName ::= [ [ ResourceID ] '.' ] EntityPropertyType
			-->
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType		EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType
	]]></artwork>		]]></artwork>
	<t>The presence and construction of the component</t>		<t>The presence and construction of the component</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	"[ [ ResourceID ] '.' ]"		"[ [ ResourceID ] '.' ]"
	]]></artwork>		]]></artwork>
	<t>depends on the category of entity domain.</t>		<t>depends on the category of entity domain.</t>
	<!-- commented text <t>The component</t> -->		<!-- [auth] commented text <t>The component</t> -->
	<!-- commented text <artwork name="" type="" align="left" alt="">		<!-- [auth] commented text <artwork name="" type="" align="left"
	<![CDATA[		alt=""><![CDATA[
	"['priv:']"		"['priv:']"
	]]></artwork> -->		]]></artwork> -->
	<!-- commented text <t>is present when the entity domain type is defi ned for Private Use.		<!-- [auth] commented text <t>is present when the entity domain type is defined for Private Use.
	</t> -->		</t> -->
	<t>Note that the '.' separator is not allowed in EntityDomainType and hence		<t>Note that the '.' separator is not allowed in EntityDomainType, and hence
	there is no ambiguity on whether an entity domain name refers to a		there is no ambiguity on whether an entity domain name refers to a
	resource-agnostic entity domain or a resource-specific entity dom ain.</t>		resource-agnostic entity domain or a resource-specific entity dom ain.</t>
	<t>Note also that Section 10.1 of <xref target="RFC7285" format="defau lt"/>		<t>Note also that <xref target="RFC7285" section="10.1" sectionFormat= "of" format="default"/>
	specifies the format of the PID		specifies the format of the PID
	name which is the format of the resource ID including the followi		name, which is the format of the resource ID including the follow
	ng		ing
	specification: "the '.' separator is reserved for future use and		specification:</t>
	MUST NOT be		<blockquote>The '.' separator is reserved for future use and <bcp14>MU
			ST NOT</bcp14> be
	used unless specifically indicated in this document, or an extens ion		used unless specifically indicated in this document, or an extens ion
	document". The present extension keeps the format specification o		document.</blockquote>
	f		<t>The present extension keeps the format specification of
	<xref target="RFC7285" format="default"/>, hence the '.' separato		<xref target="RFC7285" format="default"/>, hence the '.' separato
	r MUST NOT		r <bcp14>MUST NOT</bcp14>
	be used in an information resource ID.</t>		be used in an information resource ID.</t>
	<section anchor="resource-specific-ED" numbered="true" toc="default">		<section anchor="resource-specific-ED" numbered="true" toc="default">
	<name>Resource-specific Entity Domain</name>		<name>Resource-Specific Entity Domain</name>
	<t>A resource-specific entity domain is identified by an entity doma in name		<t>A resource-specific entity domain is identified by an entity doma in name
	constructed as follows. It MUST start with a resource ID using the ResourceID		constructed as follows. It <bcp14>MUST</bcp14> start with a resource ID using th
	type defined in Section 10.2 of <xref target="RFC7285" format="default"/>, follo		e ResourceID
	wed by the '.' separator		type defined in <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		(U+002E), followed by a string of the type EntityDomainType specified in
	<xref target="domain-types" format="default"/>.</t>		<xref target="domain-types" format="default"/>.</t>
	<t>For example, if an ALTO server provides two network maps "netmap- 1" and		<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		"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>		type "pid", respectively identified by "netmap-1.pid" and "netmap-2.pid".</t>
	</section>		</section>
	<section anchor="resource-agnostic-ED" numbered="true" toc="default">		<section anchor="resource-agnostic-ED" numbered="true" toc="default">
	<name>Resource-agnostic Entity Domain</name>		<name>Resource-Agnostic Entity Domain</name>
	<t>A resource-agnostic entity domain contains entities that are iden tified		<t>A resource-agnostic entity domain contains entities that are iden tified
	independently of any information resource. The identifier of a		independently of any information resource. The identifier of a
	resource-agnostic entity domain is simply the identifier of its entity domain		resource-agnostic entity domain is simply the identifier of its entity domain
	type. For example, "ipv4" and "ipv6" identify the two resource-agnostic		type. For example, "ipv4" and "ipv6" identify the two resource-agnostic
	Internet address entity domains defined in <xref target="inet-addr-domain" forma t="default"/>.</t>		Internet address entity domains defined in <xref target="inet-addr-domain" forma t="default"/>.</t>
	</section>		</section>
	<section anchor="self-defined-ED" numbered="true" toc="default">		<section anchor="self-defined-ED" numbered="true" toc="default">
	<name>Self-defined Entity Domain</name>		<name>Self-Defined Entity Domain</name>
	<t>A property map can define properties on entities that are specifi		<t>A property map can define properties for entities that are specif
	c to a		ic to a
	unique information resource, which is the property map itself. This may be		unique information resource, which is the property map itself. This may be
	the case when an ALTO Server provides properties on a set of entities that		the case when an ALTO Server provides properties for a set of entities that
	are defined only in this property map, are not relevant to another one and do		are defined only in this property map, are not relevant to another one, and do
	not depend on another specific resource.</t>		not depend on another specific resource.</t>
	<t>For example: a specialised property map may define a domain of ty pe "ane",		<t>For example: a specialized property map may define a domain of ty pe "ane",
	defined in <xref target="I-D.ietf-alto-path-vector" format="default"/>, that con tains a set of ANEs		defined in <xref target="I-D.ietf-alto-path-vector" format="default"/>, that con tains a set of ANEs
	representing data centers, that each have a persistent identifier and are		representing data centers that each have a persistent identifier and are
	relevant only to this property map.</t>		relevant only to this property map.</t>
	<t>In this case, the entity domain is qualified as "self-defined". T he		<t>In this case, the entity domain is qualified as "self-defined". T he
	identifier of a self-defined entity domain can be of the format:</t>		identifier of a self-defined entity domain can be of the format:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	EntityDomainName ::= '.' EntityDomainType		EntityDomainName ::= '.' EntityDomainType
	]]></artwork>		]]></artwork>
	<t>where '.' indicates that the entity domain only exists within the property		<t>where '.' indicates that the entity domain only exists within the property
	map resource using it.</t>		map resource using it.</t>
	<t>A self-defined entity domain can be viewed as a particular case o f		<t>A self-defined entity domain can be viewed as a particular case o f
	resource-specific entity domain, where the specific resource is the current		resource-specific entity domain, where the specific resource is the current
	resource that uses this entity domain. In that case, for the sake of		resource that uses this entity domain. In that case, for the sake of
	simplification, the component "ResourceID" MUST be omitted in its entity		simplification, the component "ResourceID" <bcp14>MUST</bcp14> be omitted in its entity
	domain name.</t>		domain name.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="entity-addrs" numbered="true" toc="default">		<section anchor="entity-addrs" numbered="true" toc="default">
	<name>Entity Identifier</name>		<name>Entity Identifier</name>
	<!-- FIXME: The entity identifier is not global unique. -->		<!-- [auth] FIXME: The entity identifier is not global unique. -->
	<t>Entities in an entity domain are identified by entity identifiers (Ent ityID) of		<t>Entities in an entity domain are identified by entity identifiers (Ent ityID) of
	the following format:		the following format:
	</t>		</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID		EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID
	]]></artwork>		]]></artwork>
	<t>Examples from the Internet address entity domains include individual IP		<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		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		as address blocks such as "net1.ipv4:192.0.2.0/26" and
	"net1.ipv6:2001:db8::/48".</t>		"net1.ipv6:2001:db8::/48".</t>
	<t>The format of the second part of an entity identifier,		<t>The format of the second part of an entity identifier,
	DomainTypeSpecificEntityID, depends on the entity domain type, and MUST b		DomainTypeSpecificEntityID, depends on the entity domain type and <bcp14>
	e		MUST</bcp14> be
	specified when defining a new entity domain type and registering it with		specified when defining a new entity domain type and registering it with
	the
	IANA.		IANA.
	Identifiers MAY be hierarchical, and properties		Identifiers <bcp14>MAY</bcp14> be hierarchical, and properties
	MAY be inherited based on that hierarchy. The rules defining any hierarch		<bcp14>MAY</bcp14> be inherited based on that hierarchy. The rules defini
	y or		ng any hierarchy or
	inheritance MUST be defined when the entity domain type is registered.		inheritance <bcp14>MUST</bcp14> be defined when the entity domain type is
			registered.
	</t>		</t>
	<t>The type EntityID is used in this document to denote a JSON string		<t>The type EntityID is used in this document to denote a JSON string
	representing an entity identifier in this format.</t>		representing an entity identifier in this format.</t>
	<t>Note that two entity identifiers with different valid textual repre sentations		<t>Note that two entity identifiers with different, valid textual repr esentations
	may refer to the same entity, for a given entity domain. For example, the		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		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		the same entity in the "ipv6" entity domain. Such equivalences should be
	established by the object represented by DomainTypeSpecificEntityID, for		established by the object represented by DomainTypeSpecificEntityID. For
	example, <xref target="RFC5952" format="default"/> establishes equivalence for I Pv6 addresses, while		example, <xref target="RFC5952" format="default"/> establishes equivalence for I Pv6 addresses, while
	<xref target="RFC4632" format="default"/> does so for IPv4 addresses.</t>		<xref target="RFC4632" format="default"/> does so for IPv4 addresses.</t>
	</section>		</section>
	<section anchor="def-hierarchy-and-inheritance" numbered="true" toc="def ault">		<section anchor="def-hierarchy-and-inheritance" numbered="true" toc="def ault">
	<name>Hierarchy and Inheritance</name>		<name>Hierarchy and Inheritance</name>
	<t>To simplify the representation, some types of entity domains allow the ALTO		<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		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 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		a CIDR "net1.ipv4:192.0.2.0/26" covers 64 individual IPv4 entities. In this
	case, the corresponding property inheritance rule MUST be defined for the		case, the corresponding property inheritance rule <bcp14>MUST</bcp14> be defined
	entity domain type. The hierarchy and inheritance rule MUST have no		for the
			entity domain type. The hierarchy and inheritance rule <bcp14>MUST</bcp14> have
			no
	ambiguity.</t>		ambiguity.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="def-property" numbered="true" toc="default">		<section anchor="def-property" numbered="true" toc="default">
	<name>Entity Property</name>		<name>Entity Property</name>
	<t>Each entity property has a type to indicate the encoding and the sema ntics of		<t>Each entity property has a type to indicate the encoding and the sema ntics of
	the value of this entity property, and has a name to identify it.</t>		the value of this entity property, and has a name to identify it.</t>
	<section anchor="def-property-type" numbered="true" toc="default">		<section anchor="def-property-type" numbered="true" toc="default">
	<name>Entity Property Type</name>		<name>Entity Property Type</name>
	<t>The type EntityPropertyType is used in this document to indicate a strin g		<t>The type EntityPropertyType is used in this document to indicate a strin g
	denoting an entity property type. The string MUST be no more than 32		denoting an entity property type. The string <bcp14>MUST</bcp14> be no mo
	characters, and it MUST NOT contain characters other than US-ASCII		re than 32
			characters, and it <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) ,		alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A) ,
	the hyphen ('-', U+002D), the colon (':', U+003A), or the low line ('_',		the hyphen ('-', U+002D), the colon (':', U+003A), or the low line ('_',
	U+005F). Note that the '.' separator is not allowed because it is reserve d to		U+005F). Note that the '.' separator is not allowed because it is reserve d to
	separate an entity property type and an information resource identifier w hen		separate an entity property type and an information resource identifier w hen
	an entity property is resource-specific.</t>		an entity property is resource-specific.</t>
	<t>While, in <xref target="domain-types" format="default"/>,		<t>While <xref target="domain-types" format="default"/> allows the use of
	character ":" is allowed with restrictions on entity domain identifiers,		the
			character ":" with restrictions on entity domain identifiers,
	it can be used without restrictions on entity property type identifiers.		it can be used without restrictions on entity property type identifiers.
	This relates to <xref target="RFC7285" format="default"/>, where a Server		This relates to <xref target="RFC7285" format="default"/>, where a Server
	can define properties on endpoints "ipv4" and "ipv6". In the present exte		can define properties for endpoints "ipv4" and "ipv6". In the present ext
	nsion,		ension,
	there is a mapping of ALTO entity domain types "ipv4" and "ipv6", to ALTO		there is a mapping of ALTO entity domain types "ipv4" and "ipv6" to ALTO
	address types "ipv4" and "ipv6". Properties defined on "ipv4" and "ipv6"		address types "ipv4" and "ipv6". Properties defined for "ipv4" and "ipv6"
	endpoints should be re-usable on "ipv4" and "ipv6" entities. Forbidding t		endpoints should be reusable on "ipv4" and "ipv6" entities. Forbidding th
	he		e
	usage of ":" in a non-private entity property type identifier would not		usage of ":" in a non-private entity property type identifier would not
	allow to use properties previously defined on "ipv4" and "ipv6" endpoint s		allow the use of properties previously defined for "ipv4" and "ipv6" endp oints
	because their identifiers would be invalid.</t>		because their identifiers would be invalid.</t>
	<t>Although “:” or “_::-“ are valid entity domain types,		<t>Although ":" or "_::-" are valid entity domain types,
	it is desirable to add characters such as alphanumeric ones,		it is desirable to add characters, such as alphanumeric ones,
	for better intelligibility. </t>		for better intelligibility. </t>
	<t>Identifiers prefixed with "priv:" are reserved for Private Use		<t>Identifiers prefixed with "priv:" are reserved for Private Use
	<xref target="RFC8126" format="default"/>		<xref target="RFC8126" format="default"/>
	without a need to register with IANA. All other identifiers for entity		without a need to register with IANA. All other identifiers for entity
	property types MUST be registered in the "ALTO Entity		property types <bcp14>MUST</bcp14> be registered in the "ALTO Entity
	Property Type Registry", defined in <xref target="IANAEntityProp" format=		Property Types" registry, which is defined in <xref target="IANAEntityPro
	"default"/>.		p" format="default"/>.
	The intended semantics of the entity property type MUST be specified in t		The intended semantics of the entity property type <bcp14>MUST</bcp14> be
	he IANA registration.		specified in the IANA registration.
	</t>		</t>
	<t>For an entity		<t>For an entity
	property identifier with the "priv:" prefix, an additional string (e.g.,		property identifier with the "priv:" prefix, an additional string (e.g.,
	company identifier or random string) MUST follow the prefix to reduce		company identifier or random string) <bcp14>MUST</bcp14> follow the prefi x to reduce
	potential collisions, that is, the string "priv:" alone is not a valid		potential collisions, that is, the string "priv:" alone is not a valid
	entity property identifier.		entity property identifier.
	The definition of a private use entity property type must apply		The definition of a private-use entity property type must apply
	the same way in all property maps of an IRD where it is present.		the same way in all property maps of an IRD where it is present.
	</t>		</t>
	<t>To distinguish from the endpoint property type, the entity property type has		<t>To distinguish from the endpoint property type, the entity property type has
	the following characteristics:</t>		the following characteristics:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Some entity property types are applicable to entities in particu		<li>Some entity property types are applicable only to entities in pa
	lar entity		rticular entity
	domain types only. For example, the property type "pid" is applicable to		domain types. For example, the property type "pid" is applicable to
	entities in the entity domain types "ipv4" or "ipv6" while is not		entities in the entity domain types "ipv4" or "ipv6", while it is not
	applicable to entities in an entity domain of type "pid".</li>		applicable to entities in an entity domain of type "pid".</li>
	<li>The intended semantics of the value of an entity property may al so depend		<li>The intended semantics of the value of an entity property may al so depend
	on the entity domain type. For example, suppose that a property n amed		on the entity domain type. For example, suppose that a property n amed
	"geo-location" is defined as the coordinates of a point, encoded as:		"geo-location" is defined as the coordinates of a point and is en coded as:
	"latitude longitude [altitude]." When applied to an entity that r epresents		"latitude longitude [altitude]." When applied to an entity that r epresents
	a specific host computer, identified by an address in an entity d omain of		a specific host computer and identified by an address in an entit y domain of
	type "ipv4" or "ipv6", the "geo-location" property would define t he host's		type "ipv4" or "ipv6", the "geo-location" property would define t he host's
	location. However, when applied to an entity in a "pid" domain ty pe, the		location. However, when applied to an entity in a "pid" domain ty pe, the
	property would indicate a location representative of all hosts in this		property would indicate a location representative of all hosts in this
	"pid" entity.</li>		"pid" entity.</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="entity-property-name" numbered="true" toc="default">		<section anchor="entity-property-name" numbered="true" toc="default">
	<name>Entity Property Name</name>		<name>Entity Property Name</name>
	<t>Each entity property is identified by an entity property name, whic h is a		<t>Each entity property is identified by an entity property name, whic h is a
	string of the following format:</t>		string of the following format:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	EntityPropertyName ::= [ [ ResourceID ] '.' ] EntityPropertyType		EntityPropertyName ::= [ [ ResourceID ] '.' ] EntityPropertyType
	]]></artwork>		]]></artwork>
	<t>Similar to the endpoint property type defined in Section 10.8 of <x ref target="RFC7285" format="default"/>,		<t>Similar to the endpoint property type defined in <xref target="RFC7 285" section="10.8" sectionFormat="of" format="default"/>,
	each entity property may be defined by either the property map itself		each entity property may be defined by either the property map itself
	(self-defined) or some other specific information resource		(self-defined) or some other specific information resource
	(resource-specific).</t>		(resource-specific).</t>
	<t>The entity property name of a resource-specific entity property sta rts with a		<t>The entity property name of a resource-specific entity property sta rts with a
	string of the type ResourceID defined in <xref target="RFC7285" format="default" />, followed by the '.'		string of the type ResourceID defined in <xref target="RFC7285" format="default" />, followed by the '.'
	separator (U+002E) and a EntityDomainType typed string. For example, the		separator (U+002E) and an EntityDomainType typed string. For example, the
	"pid" properties of an "ipv4" entity defined by two different maps		"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-1" and "net-map-2" are identified by "net-map-1.pid" and
	"net-map-2.pid" respectively.</t>		"net-map-2.pid" respectively.</t>
	<t>The specific information resource of an entity property may be the current		<t>The specific information resource of an entity property may be the current
	information resource itself, that is, the property map defining the property.		information resource itself, that is, the property map defining the property.
	In that case, the ResourceID in the property name SHOULD be omitted. For		In that case, the ResourceID in the property name <bcp14>SHOULD</bcp14> be omitt ed. For
	example, the property name ".asn" applied to an entity identified by its		example, the property name ".asn" applied to an entity identified by its
	IPv4 address, indicates the AS number of the AS that "owns" the entity, where		IPv4 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>		the returned AS number is defined by the property map itself.</t>
	</section>		</section>
	<section anchor="format-entity-property-value" numbered="true" toc="defa ult">		<section anchor="format-entity-property-value" numbered="true" toc="defa ult">
	<name>Format for Entity Property Value</name>		<name>Format for Entity Property Value</name>
	<t>Section 11.4.1.6 of <xref target="RFC7285" format="default"/> speci		<t><xref target="RFC7285" section="11.4.1.6" sectionFormat="of" format
	fies that an implementation of the		="default"/> specifies that an implementation of the
	Endpoint Property Service specified in <xref target="RFC7285" format="default"/>		Endpoint Property Service specified in <xref target="RFC7285" format="default"/>
	SHOULD assume that the		<bcp14>SHOULD</bcp14> assume that the
	property value is a JSONString and fail to parse if it is not. This document		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		extends the format of a property value by allowing it to be a JSONValue
	instead of just a JSONString.</t>		instead of just a JSONString.</t>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="entity-domain-types" numbered="true" toc="default">		<section anchor="entity-domain-types" numbered="true" toc="default">
	<name>Entity Domain Types Defined in this Document</name>		<name>Entity Domain Types Defined in This Document</name>
	<t>The definition of each entity domain type MUST include		<!-- [rfced] Section 6: The following sentence contains both numbers and two
			different normative keywords. Does the following suggestion improve readability?
			Current:
			The definition of each entity domain type MUST include (1) the entity
			domain type name and (2) domain-specific entity identifiers, and MAY
			include (3) hierarchy and inheritance semantics optionally.
			Perhaps (splitting into two sentences and removing the numbers):
			The definition of each entity domain type MUST include the entity
			domain type name and the domain-specific entity identifiers.
			The definition of an entity domain type MAY include hierarchy
			and inheritance semantics.
			-->
			<t>The definition of each entity domain type <bcp14>MUST</bcp14> include
	(1) the entity domain type name and (2) domain-specific entity identifiers,		(1) the entity domain type name and (2) domain-specific entity identifiers,
	and MAY include (3) hierarchy and inheritance semantics optionally. This		and <bcp14>MAY</bcp14> include (3) hierarchy and inheritance semantics optionall y. This
	document defines three initial entity domain types as follows.</t>		document defines three initial entity domain types as follows.</t>
	<section anchor="inet-addr-domain" numbered="true" toc="default">		<section anchor="inet-addr-domain" numbered="true" toc="default">
	<name>Internet Address Domain Types</name>		<name>Internet Address Domain Types</name>
	<t>The document defines two entity domain types (IPv4 and IPv6) for Inte rnet		<t>The document defines two entity domain types (IPv4 and IPv6) for Inte rnet
	addresses. Both types are resource-agnostic entity domain types and hence		addresses. Both types are resource-agnostic entity domain types and hence
	define corresponding resource-agnostic entity domains as well. Since the two		define corresponding resource-agnostic entity domains as well. Since the two
	domains use the same hierarchy and inheritance semantics, we define the		domains use the same hierarchy and inheritance semantics, we define the
	semantics together, instead of repeating for each.</t>		semantics together, instead of repeating for each.</t>
	<section anchor="ipv4-domain" numbered="true" toc="default">		<section anchor="ipv4-domain" numbered="true" toc="default">
	<name>Entity Domain Type: IPv4</name>		<name>Entity Domain Type: IPv4</name>
	<section anchor="ipv4-edt" numbered="true" toc="default">		<section anchor="ipv4-edt" numbered="true" toc="default">
	<name>Entity Domain Type Identifier</name>		<name>Entity Domain Type Identifier</name>
	<t>The identifier for this Entity Domain Type is "ipv4".</t>		<t>The identifier for this Entity Domain Type is "ipv4".</t>
	</section>		</section>
	<section anchor="ipv4-dsei" numbered="true" toc="default">		<section anchor="ipv4-dsei" numbered="true" toc="default">
	<name>Domain-Specific Entity Identifiers</name>		<name>Domain-Specific Entity Identifiers</name>
			<!-- [rfced] Section 6.1.1.2: The following sentence seems to have redundant
			phrasing ("to define properties" is used twice):
			Current:
			To define properties, an individual Internet address and the
			corresponding full-length prefix are considered aliases for the same
			entity on which to define properties.
			Perhaps:
			To define properties, an individual Internet address and the
			corresponding full-length prefix are considered aliases for the same
			entity.
			-->
	<t>Individual addresses are strings as specified by the IPv4address rule in		<t>Individual addresses are strings as specified by the IPv4address rule in
	Section 3.2.2 of <xref target="RFC3986" format="default"/>;		<xref target="RFC3986" section="3.2.2" sectionFormat="of" format=
	Hierarchical addresses are strings as specified by the prefix not		"default"/>;
	ation in Section 3.1		hierarchical addresses are strings as specified by the prefix not
	of <xref target="RFC4632" format="default"/>.		ation in
			<xref target="RFC4632" section="3.1" sectionFormat="of" format="d
			efault"/>.
	To define properties, an		To define properties, an
	individual Internet address and the corresponding full-length pre fix are		individual Internet address and the corresponding full-length pre fix are
	considered aliases for the same entity on which to define propert ies.		considered aliases for the same entity on which to define propert ies.
	Thus, "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are equivalent.</t >		Thus, "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are equivalent.</t >
	</section>		</section>
	</section>		</section>
	<section anchor="ipv6-domain" numbered="true" toc="default">		<section anchor="ipv6-domain" numbered="true" toc="default">
	<name>Entity Domain Type: IPv6</name>		<name>Entity Domain Type: IPv6</name>
	<section anchor="ipv6-edt" numbered="true" toc="default">		<section anchor="ipv6-edt" numbered="true" toc="default">
	<name>Entity Domain Type Identifier</name>		<name>Entity Domain Type Identifier</name>
	<t>The identifier for this Entity Domain Type is "ipv6".</t>		<t>The identifier for this Entity Domain Type is "ipv6".</t>
	</section>		</section>
	<section anchor="ipv6-dsei" numbered="true" toc="default">		<section anchor="ipv6-dsei" numbered="true" toc="default">
	<name>Domain-Specific Entity Identifiers</name>		<name>Domain-Specific Entity Identifiers</name>
	<t>Individual addresses are strings as specified by		<t>Individual addresses are strings as specified by
	Section 4 of <xref target="RFC5952" format="default"/>;		<xref target="RFC5952" section="4" sectionFormat="of" format="de
	Hierarchical addresses are strings as specified by		fault"/>;
	IPv6 address prefixes notation in Section 2.3 of		hierarchical addresses are strings as specified by
	<xref target="RFC4291" format="default"/>.		IPv6 address prefixes notation in
			<xref target="RFC4291" section="2.3" sectionFormat="of" format="d
			efault"/>.
	To define properties, an individual Internet address and the		To define properties, an individual Internet address and the
	corresponding 128-bit prefix are considered aliases for the same entity. That		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, and have		is, "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent and have
	the same set of properties.</t>		the same set of properties.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="inet-inheritance" numbered="true" toc="default">		<section anchor="inet-inheritance" numbered="true" toc="default">
	<name>Hierarchy and Inheritance of Internet Address Domains</name>		<name>Hierarchy and Inheritance of Internet Address Domains</name>
			<!-- [rfced] Section 6.1.3: Would the following sentence be easier to read as a
			list?
			Current:
			Hierarchical addresses can also inherit properties: if a property P
			is not defined for the hierarchical address C, but is defined for a
			set of hierarchical addresses, where each address C' in the set
			contains all IP addresses in C, and C' has a shorter prefix length
			than C, then C MUST inherit the property P from the C' having the
			longest prefix length.
			Perhaps:
			Hierarchical addresses can also inherit properties. For instance,
			if a property P:
			* is not defined for the hierarchical address C,
			* but is defined for a set of hierarchical addresses where:
			* each address C' in the set contains all IP addresses in C, and
			* C' has a shorter prefix length than C,
			Then C MUST inherit the property P from the C' having the longest
			prefix length.
			-->
	<t>Both Internet address domains allow property values to be inherited .		<t>Both Internet address domains allow property values to be inherited .
	Specifically, if a property P is not defined for a specific Inter net address		Specifically, if a property P is not defined for a specific Inter net address
	I, but P is defined for a hierarchical Internet address C which		I, but P is defined for a hierarchical Internet address C that
	represents a set of addresses containing I, then the address I in herits		represents a set of addresses containing I, then the address I in herits
	the value of P defined for the hierarchical address C.		the value of P defined for the hierarchical address C.
	If more than one such hierarchical addresses define a		If more than one such hierarchical addresses define a
	value for P, I inherits the value of P in the hierarchical addres s with the		value for P, I inherits the value of P in the hierarchical addres s with the
	longest prefix. Note that this longest prefix rule ensures no mul tiple value		longest prefix. Note that this longest prefix rule ensures no mul tiple value
	inheritances, and hence no ambiguity.</t>		inheritances, and hence no ambiguity.</t>
	<t>Hierarchical addresses can also inherit properties: if a property P is not		<t>Hierarchical addresses can also inherit properties: if a property P is not
	defined for the hierarchical address C, but is defined for		defined for the hierarchical address C, but is defined for
	a set of hierarchical addresses, where each address C' in the set		a set of hierarchical addresses, where each address C' in the set
	contains all IP addresses in C, and C' has a shorter prefix lengt h than C,		contains all IP addresses in C, and C' has a shorter prefix lengt h than C,
	then C MUST inherit the property P from the C' having the longest prefix length.		then C <bcp14>MUST</bcp14> inherit the property P from the C' hav ing the longest prefix length.
	</t>		</t>
	<t>As an example, suppose that a server defines a property P for the f ollowing		<t>As an example, suppose that a server defines a property P for the f ollowing
	entities:</t>		entities:</t>
	<figure anchor="fig_def-prop-val">		<figure anchor="fig_def-prop-val">
	<name>Defined Property Values.</name>		<name>Defined Property Values</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[
			<!-- [rfced] Figures 1-7: Please let us know if the <artwork> in the
			figures showing network maps and property values should be marked as
			<sourcecode> or constructed as tables instead.
			-->
			<artwork name="" type="" align="left" alt=""><![CDATA[
	ipv4:192.0.2.0/26: P=v1		ipv4:192.0.2.0/26: P=v1
	ipv4:192.0.2.0/28: P=v2		ipv4:192.0.2.0/28: P=v2
	ipv4:192.0.2.0/30: P=v3		ipv4:192.0.2.0/30: P=v3
	ipv4:192.0.2.0: P=v4		ipv4:192.0.2.0: P=v4
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>Then the following entities have the indicated values:</t>		<t>Then the following entities have the indicated values:</t>
	<figure anchor="fig_inh-prop-val">		<figure anchor="fig_inh-prop-val">
	<name>Inherited Property Values.</name>		<name>Inherited Property Values</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	ipv4:192.0.2.0: P=v4		ipv4:192.0.2.0: P=v4
	ipv4:192.0.2.1: P=v3		ipv4:192.0.2.1: P=v3
	ipv4:192.0.2.16: P=v1		ipv4:192.0.2.16: P=v1
	ipv4:192.0.2.32: P=v1		ipv4:192.0.2.32: P=v1
	ipv4:192.0.2.64: (not defined)		ipv4:192.0.2.64: (not defined)
	ipv4:192.0.2.0/32: P=v4		ipv4:192.0.2.0/32: P=v4
	ipv4:192.0.2.0/31: P=v3		ipv4:192.0.2.0/31: P=v3
	ipv4:192.0.2.0/29: P=v2		ipv4:192.0.2.0/29: P=v2
	ipv4:192.0.2.0/27: P=v1		ipv4:192.0.2.0/27: P=v1
	ipv4:192.0.2.0/25: (not defined)		ipv4:192.0.2.0/25: (not defined)
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<!-- Improve words of this paragraph. (Done, waiting for review) -->		<!-- [auth] Improve words of this paragraph. (Done, waiting for review ) -->
	<t>An ALTO server MAY explicitly indicate a property as not having a value for		<t>An ALTO server <bcp14>MAY</bcp14> explicitly indicate a property as not havin
	a particular entity. That is, a server MAY say that property P of entity X is		g a value for
	"defined to have no value", instead of "undefined". To indicate "no value",		a particular entity. That is, a server <bcp14>MAY</bcp14> say that property P of
	a server MAY perform different behaviors:</t>		entity X is
			"defined to have no value" instead of "undefined". To indicate "no value",
			a server <bcp14>MAY</bcp14> perform different behaviors:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	If entity X would inherit a value for property P, and if the ALTO server decides to		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		say that "X has no value for P", then the
	ALTO server MUST return a "null" value for that property on X. In this		ALTO server <bcp14>MUST</bcp14> return a "null" value for that property o
	case, the ALTO client MUST recognize the JSON "null" value as "no value"		n X. In this
			case, the ALTO client <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".		and interpret it as "do not apply the inheritance rules for this property on X".
	</li>		</li>
	<li>If the entity would not inherit a value, then the ALTO server MA Y return		<li>If the entity would not inherit a value, then the ALTO server <b cp14>MAY</bcp14> return
	"null" or just omit the property. In this case, the ALTO client c annot infer		"null" or just omit the property. In this case, the ALTO client c annot infer
	the value for this property of this entity from the Inheritance r		the value for this property of this entity from the Inheritance r
	ules. So, the		ules. Thus, the
	client MUST interpret that this property has no value.</li>		client <bcp14>MUST</bcp14> interpret that this property has no va
			lue.</li>
	</ul>		</ul>
	<t>If the ALTO server does not define any properties for an entity, th en the		<t>If the ALTO server does not define any properties for an entity, th en the
	server MAY omit that entity from the response.</t>		server <bcp14>MAY</bcp14> omit that entity from the response.</t>
	</section>		</section>
	<section anchor="defining-IR-media-type-ipv4-ipv6" numbered="true" toc=" default">		<section anchor="defining-IR-media-type-ipv4-ipv6" numbered="true" toc=" default">
	<name>Defining Information Resource Media Type for domain types IPv4 a		<name>Defining Information Resource Media Type for Domain Types IPv4 a
	nd IPv6</name>		nd IPv6</name>
	<t>Entity domain types "ipv4" and "ipv6" both allow to define resource		<t>Entity domain types "ipv4" and "ipv6" both allow the definition of
	specific		resource-specific
	entity domains. When resource specific domains are defined with entities of		entity domains. When resource-specific domains are defined with entities of
	domain type "ipv4" or "ipv6", the defining information resource for an entity		domain type "ipv4" or "ipv6", the defining information resource for an entity
	domain of type "ipv4" or "ipv6" MUST be a Network Map. The media type of a		domain of type "ipv4" or "ipv6" <bcp14>MUST</bcp14> be a Network Map. The media type of a
	defining information resource is therefore:</t>		defining information resource is therefore:</t>
	<t>application/alto-networkmap+json</t>		<t>application/alto-networkmap+json</t>
	</section>		</section>
	</section>		</section>
	<section anchor="pid-domain" numbered="true" toc="default">		<section anchor="pid-domain" numbered="true" toc="default">
	<name>Entity Domain Type: PID</name>		<name>Entity Domain Type: PID</name>
	<t>The PID entity domain associates property values with the PIDs in a n etwork map.		<t>The PID entity domain associates property values with the PIDs in a n etwork map.
	Accordingly, this entity domain always depends on a network map.</t>		Accordingly, this entity domain always depends on a network map.</t>
	<section anchor="entity-domain-type-identifier" numbered="true" toc="def ault">		<section anchor="entity-domain-type-identifier" numbered="true" toc="def ault">
	<name>Entity Domain Type Identifier</name>		<name>Entity Domain Type Identifier</name>
	<t>The identifier for this Entity Domain Type is "pid"</t>		<t>The identifier for this Entity Domain Type is "pid".</t>
	</section>		</section>
	<section anchor="domain-specific-entity-identifiers" numbered="true" toc ="default">		<section anchor="domain-specific-entity-identifiers" numbered="true" toc ="default">
	<name>Domain-Specific Entity Identifiers</name>		<name>Domain-Specific Entity Identifiers</name>
	<t>The entity identifiers are the PID names of the associated network map.</t>		<t>The entity identifiers are the PID names of the associated network map.</t>
	</section>		</section>
	<section anchor="hierarchy-and-inheritance" numbered="true" toc="default ">		<section anchor="hierarchy-and-inheritance" numbered="true" toc="default ">
	<name>Hierarchy and Inheritance</name>		<name>Hierarchy and Inheritance</name>
	<t>There are no hierarchy or inheritance for properties associated wit h PIDs.</t>		<t>There is no hierarchy or inheritance for properties associated with PIDs.</t>
	</section>		</section>
	<section anchor="defining-IR-media-type-pid" numbered="true" toc="defaul t">		<section anchor="defining-IR-media-type-pid" numbered="true" toc="defaul t">
	<name>Defining Information Resource Media Type for Domain Type PID</na me>		<name>Defining Information Resource Media Type for Domain Type PID</na me>
	<t>The entity domain type "pid" allows to define resource specific ent		<t>The entity domain type "pid" allows the definition of resource-spec
	ity		ific entity
	domains. When resource specific domains are defined with entities of domain		domains. When resource-specific domains are defined with entities of domain
	type "pid", the defining information resource for entity domain type "pid"		type "pid", the defining information resource for entity domain type "pid"
	MUST be a Network Map. The media type of a defining information resource is		<bcp14>MUST</bcp14> be a Network Map. The media type of a defining information r esource is
	therefore:</t>		therefore:</t>
	<t>application/alto-networkmap+json</t>		<t>application/alto-networkmap+json</t>
	</section>		</section>
	<section anchor="relationship-to-internet-addresses-domains" numbered="t rue" toc="default">		<section anchor="relationship-to-internet-addresses-domains" numbered="t rue" toc="default">
	<name>Relationship To Internet Addresses Domains</name>		<name>Relationship To Internet Addresses Domains</name>
	<t>The PID domain and the Internet address domains are completely inde pendent;		<t>The PID domain and the Internet address domains are completely inde pendent;
	the properties associated with a PID have no relation to the properties		the properties associated with a PID have no relation to the properties
	associated with the prefixes or endpoint addresses in that PID. An ALTO		associated with the prefixes or endpoint addresses in that PID. An ALTO
	server MAY choose to assign all the properties of a PID to the prefixes in		server <bcp14>MAY</bcp14> choose to assign all the properties of a PID to the pr efixes in
	that PID or only some of these properties.</t>		that PID or only some of these properties.</t>
	<t>For example, suppose "PID1" consists of the prefix "ipv4:192.0.2.0/		<t>For example, suppose "PID1" consists of the prefix "ipv4:192.0.2.0/
	24", and		24" and
	has the property "P" with value "v1". The Internet address entities		has the property P with value v1. The Internet address entities
	"ipv4:192.0.2.0" and "ipv4:192.0.2.0/24" in the IPv4 domain MAY have a value		"ipv4:192.0.2.0" and "ipv4:192.0.2.0/24" in the IPv4 domain <bcp14>MAY</bcp14> h
	for the property "P", and if they do, it is not necessarily "v1".</t>		ave a value
			for the property P, and if they do, it is not necessarily v1.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="internet-address-properties-vs-pid-properties" numbered=" true" toc="default">		<section anchor="internet-address-properties-vs-pid-properties" numbered=" true" toc="default">
	<name>Internet Address Properties vs. PID Properties</name>		<name>Internet Address Properties vs. PID Properties</name>
	<t>Because the Internet address and PID domains relate to completely dis tinct domain types, the		<t>Because the Internet address and PID domains relate to completely dis tinct domain types, the
	question may arise as to which entity domain type is the best for a property. In general, 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 for properties that are closely re		Internet address domain types are <bcp14>RECOMMENDED</bcp14> for properties that
	lated		are closely related
	to the Internet address, or are associated with, and inherited through, hierarch		to the Internet address or are associated with, and inherited through, hierarchi
	ical addresses.</t>		cal addresses.</t>
	<t>The PID domain type is RECOMMENDED for properties that arise from the		<t>The PID domain type is <bcp14>RECOMMENDED</bcp14> for properties that
	definition of		arise from the definition of
	the PID, rather than from the Internet address prefixes in that PID.</t>		the PID, rather than from the Internet address prefixes in that PID.</t>
	<t>For example, because Internet addresses are allocated to service prov iders by		<t>For example, because Internet addresses are allocated to service prov iders by
	blocks of prefixes, an "ISP" property would be best associated with Internet		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		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		was formed, or how it relates to a provider's network, would best be
	associated with the PID domain type.</t>		associated with the PID domain type.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="prop-map" numbered="true" toc="default">		<section anchor="prop-map" numbered="true" toc="default">
	skipping to change at line 1359 ¶		skipping to change at line 1620 ¶
	</section>		</section>
	<section anchor="accept-input-parameters" numbered="true" toc="default">		<section anchor="accept-input-parameters" numbered="true" toc="default">
	<name>Accept Input Parameters</name>		<name>Accept Input Parameters</name>
	<t>A Property Map has no Accept Input parameters.</t>		<t>A Property Map has no Accept Input parameters.</t>
	</section>		</section>
	<section anchor="FullPropMapCapabilities" numbered="true" toc="default">		<section anchor="FullPropMapCapabilities" numbered="true" toc="default">
	<name>Capabilities</name>		<name>Capabilities</name>
	<t>The capabilities are defined by an object of type PropertyMapCapabili ties:</t>		<t>The capabilities are defined by an object of type PropertyMapCapabili ties:</t>
			<!-- [rfced] Should the following artwork be labeled <sourcecode type="json">
			instead of <artwork>?
			Current (Section 7.4):
			object {
			EntityPropertyMapping mappings;
			} PropertyMapCapabilities;
			object-map {
			EntityDomainName -> EntityPropertyName<1..*>;
			} EntityPropertyMapping
			Current (Section 7.6):
			object {
			PropertyMapData property-map;
			} InfoResourceProperties : ResponseEntityBase;
			object-map {
			EntityID -> EntityProps;
			} PropertyMapData;
			object {
			EntityPropertyName -> JSONValue;
			} EntityProps;
			Current (Section 8.3):
			object {
			EntityID entities<0..*>;
			[EntityPropertyName properties<0..*>;]
			} ReqFilteredPropertyMap;
			-->
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	object {		object {
	EntityPropertyMapping mappings;		EntityPropertyMapping mappings;
	} PropertyMapCapabilities;		} PropertyMapCapabilities;
	object-map {		object-map {
	EntityDomainName -> EntityPropertyName<1..*>;		EntityDomainName -> EntityPropertyName<1..*>;
	} EntityPropertyMapping		} EntityPropertyMapping
	]]></artwork>		]]></artwork>
	<t>with fields:</t>		<t>with fields:</t>
	skipping to change at line 1389 ¶		skipping to change at line 1681 ¶
	<t> The "uses" field of a property map resource in an IRD entry specifie s		<t> The "uses" field of a property map resource in an IRD entry specifie s
	the resources in this same IRD on which this property map directly dep ends. It is an array of		the resources in this same IRD on which this property map directly dep ends. It is an array of
	resource ID(s). This array identifies the defining information resourc es associated with		resource ID(s). This array identifies the defining information resourc es associated with
	the resource-specific entity domains and properties that are indicated in this resource.		the resource-specific entity domains and properties that are indicated in this resource.
	</t>		</t>
	</section>		</section>
	<section anchor="FullPropMapResponse" numbered="true" toc="default">		<section anchor="FullPropMapResponse" numbered="true" toc="default">
	<name>Response</name>		<name>Response</name>
	<t>If the entity domains in this property map depend on other resources, the		<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 be an array		"dependent-vtags" field in the "meta" field of the response <bcp14>MUST</bcp14>
	that includes the version tags of those resources, and the order MUST be		be an array
			that includes the version tags of those resources, and the order <bcp14>MUST</bc
			p14> be
	consistent with the "uses" field of this property map resource. The data		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		component of a property map response is named "property-map", which is a JSON
	object of type PropertyMapData, where:</t>		object of type PropertyMapData, where:</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	object {		object {
	PropertyMapData property-map;		PropertyMapData property-map;
	} InfoResourceProperties : ResponseEntityBase;		} InfoResourceProperties : ResponseEntityBase;
	object-map {		object-map {
	EntityID -> EntityProps;		EntityID -> EntityProps;
	} PropertyMapData;		} PropertyMapData;
	object {		object {
	EntityPropertyName -> JSONValue;		EntityPropertyName -> JSONValue;
	} EntityProps;		} EntityProps;
	]]></artwork>		]]></artwork>
	<t>The ResponseEntityBase type is defined in Section 8.4		<t>The ResponseEntityBase type is defined in
	of <xref target="RFC7285" format="default"/>.		<xref target="RFC7285" section="8.4" sectionFormat="of" format="default"
			/>.
	</t>		</t>
	<t>Specifically, a PropertyMapData object has one member for each entity in the		<t>Specifically, a PropertyMapData object has one member for each entity in the
	property map. The entity's properties are encoded in the correspo nding		property map. The entity's properties are encoded in the correspo nding
	EntityProps object. EntityProps encodes one name/value pair for e ach property,		EntityProps object. EntityProps encodes one name/value pair for e ach property,
	where the property names are encoded as strings of type PropertyN ame.		where the property names are encoded as strings of type PropertyN ame.
	A protocol implementation SHOULD assume that the property value i s either		A protocol implementation <bcp14>SHOULD</bcp14> assume that the p roperty value is either
	a JSONString or a JSON "null" value, and fail to parse if it is n ot, unless the		a JSONString or a JSON "null" value, and fail to parse if it is n ot, unless the
	implementation is using an extension to this document that indica tes when and		implementation is using an extension to this document that indica tes when and
	how property values of other data types are signaled.</t>		how property values of other data types are signaled.</t>
	<t>For each entity in the property map:</t>		<t>For each entity in the property map:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>If the entity is in a resource-specific entity domain, the ALTO se		<!-- [rfced] Section 7.6: We are having difficulty parsing the following
	rver MUST		sentence. Are defining information resources always found in an IRD as
	only return self-defined properties and resource-specific propert		are the capabilities of the property map resource? Is there a way to
	ies which		shorten the sentence while keeping the meaning intact?
	depend on the same resource as the entity does. The ALTO client M
	UST ignore		Current:
			* If the entity identifier is resource-agnostic, the ALTO server
			SHOULD return the self-defined properties and all the resource-
			specific properties that are defined in the property defining
			information resources indicated, in the IRD, in the "mappings"
			capability of the property map resource, unless property values
			can be omitted upon some inheritance rules.
			-->
			<li>If the entity is in a resource-specific entity domain, the ALTO se
			rver <bcp14>MUST</bcp14>
			only return self-defined properties and resource-specific propert
			ies that
			depend on the same resource as the entity does. The ALTO client <
			bcp14>MUST</bcp14> ignore
	any resource-specific property for this entity if the mapping bet ween		any resource-specific property for this entity if the mapping bet ween
	this resource-specific property and this entity is not indicated, in the		this resource-specific property and this entity is not indicated, in the
	IRD, in the "mappings" capability of the property map resource.		IRD, in the "mappings" capability of the property map resource.
	</li>		</li>
	<li>		<li>
	If the entity identifier is resource-agnostic, the ALTO server SH OULD		If the entity identifier is resource-agnostic, the ALTO server <b cp14>SHOULD</bcp14>
	return the self-defined properties and all the resource-specific		return the self-defined properties and all the resource-specific
	properties that are defined in the property defining information resources		properties that are defined in the property defining information resources
	indicated, in the IRD, in the “mappings” capability of the proper ty map resource,		indicated, in the IRD, in the "mappings" capability of the proper ty map resource,
	unless property values can be omitted upon some inheritance rules .		unless property values can be omitted upon some inheritance rules .
	</li>		</li>
	</ul>		</ul>
	<!--		<!-- [auth]
	For each entity in the Property Map, the ALTO server returns the value defined		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.		for each of the properties specified in this resource's `capabilities` list.
	-->		-->
	<t>		<t>
	The ALTO server MAY omit property values that are inherited rather than		The ALTO server <bcp14>MAY</bcp14> omit property values that are inherited rathe
	explicitly defined, in order to achieve more compact encoding. As a consequence,		r than
	the ALTO Client MUST NOT assume inherited property values will all be present.		explicitly defined in order to achieve more compact encoding. As a consequence,
	If the Client needs inherited values, it MUST use the entity domain's		the ALTO Client <bcp14>MUST NOT</bcp14> assume inherited property values will al
			l be present.
			If the Client needs inherited values, it <bcp14>MUST</bcp14> use the entity doma
			in's
	inheritance rules to deduce those values.		inheritance rules to deduce those values.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<section anchor="filter-prop-map" numbered="true" toc="default">		<section anchor="filter-prop-map" numbered="true" toc="default">
	<name>Filtered Property Map</name>		<name>Filtered Property Map</name>
	<t>A filtered property map returns the values of a set of properties for a set of		<t>A filtered property map returns the values of a set of properties for a set of
	entities selected by the client.		entities selected by the client.
	</t>		</t>
	<t><xref target="filt-prop-map-example-1" format="default"/>,		<t>Sections <xref target="filt-prop-map-example-1" format="counter"/>,
	<xref target="filt-prop-map-example-2" format="default"/>,		<xref target="filt-prop-map-example-2" format="counter"/>,
	<xref target="filt-prop-map-example-3" format="default"/>		<xref target="filt-prop-map-example-3" format="counter"/>,
	and <xref target="filt-prop-map-example-4" format="default"/> giv		and <xref target="filt-prop-map-example-4" format="counter"/> giv
	e examples of		e examples of
	filtered property map requests and responses.		filtered property map requests and responses.
	</t>		</t>
			<!-- [rfced] Section 8: Do the following updates improve the readability of thes
			e sentences?
			Current:
			A client, sometimes, may only want to know what entity
			IDs it can provide as input to a filtered property map request but
			wants to avoid the burden of downloading the full property map. Or
			it may want to check whether some given entity IDs are eligible for a
			query. To support such a case, the filtered property map supports a
			lightweight response with empty property values.
			Perhaps (reordering the subject, changing "may only want" to "only wants", short
			ening "wants to avoid the burden of downloading" to "does not want to download",
			and changing "such as case" to "these cases"):
			Sometimes a client only wants to know what entity
			IDs it can provide as input to a filtered property map request but
			does not want to download the full property map, or
			it may want to check whether some given entity IDs are eligible for a
			query. To support these cases, the filtered property map supports a
			lightweight response with empty property values.
			-->
	<t>		<t>
	While the IRD lists all the names of the supported properties,		While the IRD lists all the names of the supported properties,
	it only lists the names of the supported entity domains and not t he entity IDs.		it only lists the names of the supported entity domains and not t he entity IDs.
	A client, sometimes, may only want to know what entity IDs it can provide as input to a		Sometimes a client may only want to know what entity IDs it can p rovide as input to a
	filtered property map request but wants to avoid the burden of do wnloading the full property		filtered property map request but wants to avoid the burden of do wnloading the full property
	map. Or it may want to check whether some given entity IDs are el igible for a query.		map. Or it may want to check whether some given entity IDs are el igible for a query.
	To support such a case, the filtered property map supports a ligh t weight response,		To support such a case, the filtered property map supports a ligh tweight response
	with empty property values.		with empty property values.
	</t>		</t>
	<section anchor="FilterPropMapMediaType" numbered="true" toc="default">		<section anchor="FilterPropMapMediaType" numbered="true" toc="default">
	<name>Media Type</name>		<name>Media Type</name>
	<t>The media type of a property map resource is		<t>The media type of a property map resource is
	"application/alto-propmap+json".</t>		"application/alto-propmap+json".</t>
	</section>		</section>
	<section anchor="http-method-1" numbered="true" toc="default">		<section anchor="http-method-1" numbered="true" toc="default">
	skipping to change at line 1492 ¶		skipping to change at line 1817 ¶
	<section anchor="filter-prop-map-params" numbered="true" toc="default">		<section anchor="filter-prop-map-params" numbered="true" toc="default">
	<name>Accept Input Parameters</name>		<name>Accept Input Parameters</name>
	<t>The input parameters for a filtered property map request are supplied in the		<t>The input parameters for a filtered property map request are supplied in the
	entity body of the POST request. This document specifies the inpu t parameters		entity body of the POST request. This document specifies the inpu t parameters
	with a data format indicated by the media type		with a data format indicated by the media type
	"application/alto-propmapparams+json", which is a JSON object of type		"application/alto-propmapparams+json", which is a JSON object of type
	ReqFilteredPropertyMap. ReqFilteredPropertyMap is designed to sup port the		ReqFilteredPropertyMap. ReqFilteredPropertyMap is designed to sup port the
	following cases of client requests:		following cases of client requests:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The client wants the value of a selected set of properties o		<li>The client wants the value of a selected set of properties f
	n a selected set of entities,</li>		or a selected set of entities;</li>
	<li>The client wants all properties values on all the entities,		<li>The client wants all property values on all the entities; </
	</li>		li>
	<li>The client wants all entities on which a property is defined		<li>The client wants all entities for which a property is define
	but is not interested in their property values,</li>		d
	<li>The Client wants to cross-check whether some entity IDs are		but is not interested in their property values; or</li>
	present in		<li>The client wants to cross-check whether some entity IDs are
			present in
	the Filtered Property Map but is not interested in their propert y values.</li>		the Filtered Property Map but is not interested in their propert y values.</li>
	</ul>		</ul>
	<t>The third case is equivalent to querying the whole unfiltered property map, which		<t>The third case is equivalent to querying the whole unfiltered property map, which
	can also be achieved with a GET request.		can also be achieved with a GET request.
	Some Clients however, may prefer to systematically make filtered property map queries,		Some Clients, however, may prefer to systematically make filtered property map queries,
	where filtering parameters may sometimes be empty.</t>		where filtering parameters may sometimes be empty.</t>
	<t>The JSON object ReqFilteredPropertyMap is specified as follows :</t>		<t>The JSON object ReqFilteredPropertyMap is specified as follows :</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	object {		object {
	EntityID entities<0..*>;		EntityID entities<0..*>;
	[EntityPropertyName properties<0..*>;]		[EntityPropertyName properties<0..*>;]
	} ReqFilteredPropertyMap;		} ReqFilteredPropertyMap;
	]]></artwork>		]]></artwork>
	<t>with fields:</t>		<t>with fields:</t>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>entities:</dt>		<dt>entities:</dt>
	<dd>		<dd>
	List of entity identifiers for which the specified properties are to be		A list of entity identifiers for which the specified properties a re to be
	returned.		returned.
	If the list is empty, the ALTO Server MUST interpret the list as if it		If the list is empty, the ALTO Server <bcp14>MUST</bcp14> interpr et the list as if it
	contained a list of all entities currently defined in the filtere d property map.		contained a list of all entities currently defined in the filtere d property map.
	The domain of each entity MUST be included in the list of entity domains in		The domain of each entity <bcp14>MUST</bcp14> be included in the list of entity domains in
	this resource's "capabilities" field (see		this resource's "capabilities" field (see
	<xref target="FilteredPropMapCapabilities" format="default"/>).		<xref target="FilteredPropMapCapabilities" format="default"/>).
	The ALTO server MUST interpret entries appearing multiple times		The ALTO server <bcp14>MUST</bcp14> interpret entries appearing m ultiple times
	as if they appeared only once.		as if they appeared only once.
	</dd>		</dd>
	<dt>properties:</dt>		<dt>properties:</dt>
	<dd>		<dd>
	List of properties to be returned for each entity.		A list of properties to be returned for each entity.
	If the list is empty, the ALTO Sever MUST interpret the list as i f it		If the list is empty, the ALTO Sever <bcp14>MUST</bcp14> interpre t the list as if it
	contained a list of all properties currently defined in the filte red property map.		contained a list of all properties currently defined in the filte red property map.
	Each specified property MUST be included in the list of propertie s in this resource's		Each specified property <bcp14>MUST</bcp14> be included in the li st of properties in this resource's
	"capabilities" field (see <xref target="FilteredPropMapCapabiliti es" format="default"/>).		"capabilities" field (see <xref target="FilteredPropMapCapabiliti es" format="default"/>).
	The ALTO server MUST interpret entries appearing multiple times a s if		The ALTO server <bcp14>MUST</bcp14> interpret entries appearing m ultiple times as if
	they appeared only once.		they appeared only once.
	This field is optional. If it is absent, the Server returns		This field is optional. If it is absent, the Server returns
	a property value equal to the literal string "{}"		a property value equal to the literal string "{}"
	for all the entity IDs of the "entities" field on which at least one property is		for all the entity IDs of the "entities" field for which at least one property is
	defined.		defined.
	</dd>		</dd>
	</dl>		</dl>
	<t>Note that the field "properties" is optional. When in addition,		<t>Note that the field "properties" is optional. In addition, when
	the "entities" field is an empty list, it corresponds to a		the "entities" field is an empty list, it corresponds to a
	query for all applicable entity IDs of the filtered property map, with no		query for all applicable entity IDs of the filtered property map, with no
	current interest on any particular property. When		current interest on any particular property. When
	the "entities" field is not empty, it allows the Client		the "entities" field is not empty, it allows the Client
	to check whether the listed entity IDs can be used as input to a filtered property		to check whether the listed entity IDs can be used as input to a filtered property
	map query.</t>		map query.</t>
	</section>		</section>
	<section anchor="FilteredPropMapCapabilities" numbered="true" toc="default ">		<section anchor="FilteredPropMapCapabilities" numbered="true" toc="default ">
	<name>Capabilities</name>		<name>Capabilities</name>
	<t>The capabilities are defined by an object of type PropertyMapCapabili ties, as		<t>The capabilities are defined by an object of type PropertyMapCapabili ties, as
	defined in <xref target="FullPropMapCapabilities" format="default "/>.</t>		defined in <xref target="FullPropMapCapabilities" format="default "/>.</t>
	</section>		</section>
	<section anchor="uses" numbered="true" toc="default">		<section anchor="uses" numbered="true" toc="default">
	<name>Uses</name>		<name>Uses</name>
	<t>Same to the "uses" field of the Property Map resource (see		<t>This is the same as the "uses" field of the Property Map resource (se e
	<xref target="FullPropMapUses" format="default"/>).		<xref target="FullPropMapUses" format="default"/>).
	</t>		</t>
	<!--		<!-- [auth]
	The `uses` field of a filtered property map is an array with the resource ID(s)		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		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`		provide the properties specified in the `properties` capability. The same `uses`
	rule as defined by the property map resource applies (see [](#FullPropMapUses)).		rule as defined by the property map resource applies (see [](#FullPropMapUses)).
	-->		-->
	<!-- YRY: say refer to the same consistency of uses in Section 4.5. -->		<!-- [auth] YRY: say refer to the same consistency of uses in Section 4.5. -->
	</section>		</section>
	<!-- Filtered Property Map Response -->
	<section anchor="FilteredPropMapResponse" numbered="true" toc="default">		<section anchor="FilteredPropMapResponse" numbered="true" toc="default">
	<name>Filtered Property Map Response</name>		<name>Filtered Property Map Response</name>
	<t>The response MUST indicate an error, using ALTO protocol error handli		<t>The response <bcp14>MUST</bcp14> indicate an error, using ALTO Protoc
	ng, as		ol error handling, as
	defined in Section 8.5 of <xref target="RFC7285" format="default"		defined in <xref target="RFC7285" section="8.5" sectionFormat="of
	/>, if the request is invalid.		" format="default"/>, if the request is invalid.
	</t>		</t>
	<t>Specifically, a filtered property map request can be invalid in the f ollowing cases:		<t>Specifically, a filtered property map request can be invalid in the f ollowing cases:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>The input field "entities" is absent from the Client request.		<li>The input field "entities" is absent from the Client request.
	In this case, the Server MUST return an "E_MISSING_FIELD" error		In this case, the Server <bcp14>MUST</bcp14> return an "E_MISSING
	as defined in Section 8.5.2 of <xref target="RFC7285" format="de		_FIELD" error
	fault"/>.		as defined in <xref target="RFC7285" section="8.5.2" sectionForma
			t="of" format="default"/>.
	</li>		</li>
	<li>		<li>
	<t>An entity identifier in the "entities" field of the request is inva lid.		<t>An entity identifier in the "entities" field of the request is inva lid.
	This occurs when:		This occurs when:
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
			<!-- [rfced] Section 8.6: We could not find "entity-domains" mentioned
			elsewhere in this document. Please review. Perhaps a citation is needed?
			Current:
			- The domain of this entity is not defined in the "entity-
			domains" capability of this resource in the IRD, or
			-->
	<li>The domain of this entity is not defined in the "entity-domain s"		<li>The domain of this entity is not defined in the "entity-domain s"
	capability of this resource in the IRD,</li>		capability of this resource in the IRD, or</li>
	<li>The entity identifier is not valid for the entity domain.</li>		<li>The entity identifier is not valid for the entity domain.</li>
	</ul>		</ul>
	<t> A valid entity identifier does never generate an error, even if t he filtered property		<t> A valid entity identifier never generates an error, even if the f iltered property
	map resource does not define any properties for it.		map resource does not define any properties for it.
	</t>		</t>
	<t>		<t>
	If an entity identifier in the "entities" field of the re quest is invalid, the ALTO		If an entity identifier in the "entities" field of the re quest is invalid, the ALTO
	server MUST return an "E_INVALID_FIELD_VALUE" error defin		server <bcp14>MUST</bcp14> return an "E_INVALID_FIELD_VAL
	ed in Section		UE" error defined in
	8.5.2 of <xref target="RFC7285" format="default"/>, and t		<xref target="RFC7285" section="8.5.2" sectionFormat="of"
	he "value" field of the error message SHOULD		format="default"/>, and the "value" field of the error message <bcp14>SHOULD</b
			cp14>
	indicate the provided invalid entity identifier.		indicate the provided invalid entity identifier.
	</t>		</t>
	</li>		</li>
	<li>		<li>
	<t>A property name in the "properties" field of the request is invalid . This		<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" capa bility of this		occurs when this property name is not defined in the "properties" capa bility of this
	resource in the IRD.		resource in the IRD.
	</t>		</t>
	<t> When a filtered property map resource does not define a value for a		<t> When a filtered property map resource does not define a value for a
	property requested on a particular entity, it is not an error. In		property requested for a particular entity, it is not an error. I
	this		n this
	case, the ALTO server MUST omit that property from the response f		case, the ALTO server <bcp14>MUST</bcp14> omit that property from
	or that		the response for that
	endpoint. </t>		endpoint. </t>
	<t> If a property name in "properties" in the request is invalid, the		<t> If a property name in the "properties" field in the request is inv
	ALTO		alid, the ALTO
	server MUST return an "E_INVALID_FIELD_VALUE" error defined in Se		server <bcp14>MUST</bcp14> return an "E_INVALID_FIELD_VALUE" erro
	ction		r defined in
	8.5.2 of <xref target="RFC7285" format="default"/>. The "value" f		<xref target="RFC7285" section="8.5.2" sectionFormat="of" format=
	ield of the error message SHOULD		"default"/>. The "value" field of the error message <bcp14>SHOULD</bcp14>
	indicate the property name.		indicate the property name.
	</t>		</t>
	</li>		</li>
	</ul>		</ul>
	<t>Some identifiers can be interpreted as both an entity name and a property name,		<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 erroneously used alone		as is the case for "pid" if it were erroneously used alone.
	.		In such a case, the Server <bcp14>SHOULD</bcp14> follow
	In such a case, the Server SHOULD follow Section 8.5.2 of		<xref target="RFC7285" section="8.5.2" sectionFormat="of" format=
	<xref target="RFC7285" format="default"/>, that says:		"default"/>, which says:</t>
	"For an E_INVALID_FIELD_VALUE error, the server may include an op		<blockquote>
	tional field		For an E_INVALID_FIELD_VALUE error, the server may include an opt
			ional field
	named "field" in the "meta" field of the response, to indicate th e field that contains the		named "field" in the "meta" field of the response, to indicate th e field that contains the
	wrong value."		wrong value.
	</t>		</blockquote>
	<t>The response to a valid request is the same as for the Property Map		<t>The response to a valid request is the same as for the Property Map
	(see <xref target="FullPropMapResponse" format="default"/>), exce pt that:</t>		(see <xref target="FullPropMapResponse" format="default"/>) excep t that:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li> If the requested entities include entities with a resource-agnost ic identifier,		<li> If the requested entities include entities with a resource-agnost ic identifier,
	the "dependent-vtags" field in its "meta" field MUST include version t ags of all		the "dependent-vtags" field in its "meta" field <bcp14>MUST</bcp14> in clude version tags of all
	dependent resources appearing in the "uses" field.		dependent resources appearing in the "uses" field.
	</li>		</li>
	<li>If the requested entities only include entities in resource-specif ic entity		<li>If the requested entities only include entities in resource-specif ic entity
	domains, the "dependent-vtags" field in its "meta" field MUST inc lude the version		domains, the "dependent-vtags" field in its "meta" field <bcp14>M UST</bcp14> include the version
	tags of the resources on which the requested resource-specific en tity domains and		tags of the resources on which the requested resource-specific en tity domains and
	the requested resource-specific properties are dependent on.		the requested resource-specific properties are dependent.
	</li>		</li>
	<li>The response only includes the entities and properties requested b y the		<li>The response only includes the entities and properties requested b y the
	client. If an entity in the request is identified by a hierarchic al identifier		client. If an entity in the request is identified by a hierarchic al identifier
	(e.g., a "ipv4" or "ipv6" prefix), the response MUST return all p		(e.g., a "ipv4" or "ipv6" prefix), the response <bcp14>MUST</bcp1
	roperties that		4> return all properties that
	are present on any address covered by the prefix, even though som		are present for any address covered by the prefix, even though so
	e of those		me of those
	properties may not be present on all addresses covered by the pre		properties may not be present for all addresses covered by the pr
	fix.		efix.
	</li>		</li>
	<li>When the input member "properties" is absent from the client request,		<li>When the input member "properties" is absent from the client request,
	the Server returns a property map containing all the requested en tity identifiers		the Server returns a property map containing all the requested en tity identifiers
	on which one or more properties are defined. For all the entities		for which one or more properties are defined. For all the entitie
	of the returned map,		s of the returned map,
	the returned property value is equal to '{}'.		the returned property value is equal to "{}".
	</li>		</li>
	</ul>		</ul>
	<t>The filtered property map response MUST include all the inherited pro		<t>The filtered property map response <bcp14>MUST</bcp14> include all th
	perty		e inherited property
	values for the requested entities and all the entities which are		values for the requested entities and all the entities that are a
	able to		ble to
	inherit property values from the requested entities. To achieve t his goal,		inherit property values from the requested entities. To achieve t his goal,
	the ALTO server MAY follow two rules:</t>		the ALTO server <bcp14>MAY</bcp14> follow two rules:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>If a property for a requested entity is inherited from another ent ity not		<li>If a property for a requested entity is inherited from another ent ity not
	included in the request, the response MUST include this property		included in the request, the response <bcp14>MUST</bcp14> include
	for the		this property for the
	requested entity. For example, A full property map may skip a pro		requested entity. For example, a full property map may skip a pro
	perty P for		perty P for
	an entity A (e.g., ipv4:192.0.2.0/31) if P can be derived using i		an entity A (e.g., "ipv4:192.0.2.0/31") if P can be derived using
	nheritance		inheritance
	from another entity B (e.g., ipv4:192.0.2.0/30). A filtered prope		from another entity B (e.g., "ipv4:192.0.2.0/30"). A filtered pro
	rty map		perty map
	request may include only A but not B. In such a case, the propert		request may include only A but not B. In such a case, the propert
	y P MUST be		y P <bcp14>MUST</bcp14> be
	included in the response for A.</li>		included in the response for A.</li>
	<li>If there are entities covered by a requested entity but having dif		<li>If there are entities covered by a requested entity but they have
	ferent		different
	values for the requested properties, the response MUST include al		values for the requested properties, the response <bcp14>MUST</bc
	l those		p14> include all those
	entities and the different property values for them. For example,		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), i		a request for property P of entity A (e.g., "ipv4:192.0.2.0/31"):
	f P has value		if P has value
	v1 for A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then		v1 for "A1=ipv4:192.0.2.0/32" and v2 for "A2=ipv4:192.0.2.1/32",
	, the		then the
	response SHOULD include A1 and A2.</li>		response <bcp14>SHOULD</bcp14> include A1 and A2.</li>
	</ul>		</ul>
	<t>For the sake of response compactness, the ALTO server SHOULD obey the following rule:</t>		<t>For the sake of response compactness, the ALTO server <bcp14>SHOULD</b cp14> obey the following rule:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>If an entity identifier in the response is already covered by othe r		<li>If an entity identifier in the response is already covered by othe r
	entities identifiers in the same response, it SHOULD be removed f rom the		entities identifiers in the same response, it <bcp14>SHOULD</bcp1 4> be removed from the
	response. In the previous example, the entity		response. In the previous example, the entity
	A = ipv4:192.0.2.0/31 SHOULD be removed because A1 and A2 cover a ll the		"A=ipv4:192.0.2.0/31" <bcp14>SHOULD</bcp14> be removed because A1 and A2 cover all the
	addresses in A.</li>		addresses in A.</li>
	</ul>		</ul>
	<t>An ALTO client should be aware that the entities in the response may be		<t>An ALTO client should be aware that the entities in the response may be
	different from the entities in its request.</t>		different from the entities in its request.</t>
	</section>		</section>
	<section anchor="prop-type-pid" numbered="true" toc="default">		<section anchor="prop-type-pid" numbered="true" toc="default">
	<name>Entity Property Type Defined in This Document</name>		<name>Entity Property Type Defined in This Document</name>
	<t>This document defines the entity property type "pid". This property t ype		<t>This document defines the entity property type "pid". This property t ype
	extends the ALTO Endpoint Property Type "pid" defined in section 7.1.1 of		extends the ALTO endpoint property type "pid" defined in
	<xref target="RFC7285" format="default"/> as follows: the property has the same		<xref target="RFC7285" section="7.1.1" sectionFormat="of" format="default"/> as
	semantics and applies to		follows: the property has the same semantics and applies to
	IPv4 and IPv6 addresses; the difference is that the IPv4 and IPv6 addresses		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>		have evolved from the status of endpoints to the status of entities.</t>
	<t>The defining information resource for property type MUST be a network		<!-- [rfced] Section 8.7: May this sentence be removed? It seems out of place.
	map.
	This document requests a IANA registration for this property		Current:
			This document requests an IANA registration for this property.
			-->
			<t>The defining information resource for property type <bcp14>MUST</bcp1
			4> be a network map.
			This document requests an IANA registration for this property.
	</t>		</t>
	<section anchor="entity-property-type-pid" numbered="true" toc="default" >		<section anchor="entity-property-type-pid" numbered="true" toc="default" >
	<name>Entity Property Type: pid</name>		<name>Entity Property Type: pid</name>
	<ol spacing="normal" type="1">		<dl spacing="normal">
	<li>Identifier: pid</li>		<dt>Identifier:</dt>
	<li>Semantics: the intended semantics are the same as in <xref targe		<dd>pid</dd>
	t="RFC7285" format="default"/> for the
	ALTO Endpoint Property Type "pid"</li>		<dt>Semantics:</dt>
	<li>Media type of defining information resource: application/alto-ne		<dd>the intended semantics are the same as in <xref target="RFC7285"
	tworkmap+json</li>		format="default"/> for the
	<li>Security considerations: for entity property type "pid" are the		ALTO endpoint property type "pid".</dd>
	same as
	documented in <xref target="RFC7285" format="default"/> for the ALTO Endpoint Pr		<dt>Media type of defining information resource:</dt>
	operty Type "pid".</li>		<dd>application/alto-networkmap+json</dd>
	</ol>
			<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 pr
			operty type "pid".</dd>
			</dl>
	</section>		</section>
	</section>		</section>
	</section>		</section>
	<section anchor="legacy" numbered="true" toc="default">		<section anchor="legacy" numbered="true" toc="default">
	<name>Impact on Legacy ALTO Servers and ALTO Clients</name>		<name>Impact on Legacy ALTO Servers and ALTO Clients</name>
	<section anchor="impact-on-endpoint-property-service" numbered="true" toc= "default">		<section anchor="impact-on-endpoint-property-service" numbered="true" toc= "default">
	<name>Impact on Endpoint Property Service</name>		<name>Impact on Endpoint Property Service</name>
	<t>Since the Property Map and the Filtered Property Map defined in this document		<t>Since the Property Map and the Filtered Property Map defined in this document
	provide a functionality that covers the EPS		provide a functionality that covers the EPS
	defined in Section 11.4 of <xref target="RFC7285" format="default"/>, ALTO serve rs may prefer to provide		defined in <xref target="RFC7285" section="11.4" sectionFormat="of" format="defa ult"/>, ALTO servers may prefer to provide
	Property Map and Filtered Property Map in place of EPS. However, for the		Property Map and Filtered Property Map in place of EPS. However, for the
	legacy endpoint properties, it is recommended that ALTO servers also provide		legacy endpoint properties, it is recommended that ALTO servers also provide
	EPS so that legacy clients can still be supported.</t>		EPS so that legacy clients can still be supported.</t>
	</section>		</section>
	<section anchor="impact-on-resource-specific-properties" numbered="true" t oc="default">		<section anchor="impact-on-resource-specific-properties" numbered="true" t oc="default">
	<name>Impact on Resource-Specific Properties</name>		<name>Impact on Resource-Specific Properties</name>
	<t>Section 10.8 of <xref target="RFC7285" format="default"/> defines		<t><xref target="RFC7285" section="10.8" sectionFormat="of" format="defa ult"/> defines
	two categories of endpoint properties: "resource-specific" and "global".		two categories of endpoint properties: "resource-specific" and "global".
	Resource-specific property names are		Resource-specific property names are
	prefixed with the ID of the resource they depend on, while global property		prefixed with the ID of the resource they depend on, while global property
	names have no such prefix. The property map and the filtered property map		names have no such prefix. The property map and the filtered property map
	defined in this document define similar categories of entity properties. The		specified in this document define similar categories of entity properties. The
	difference is that entity property maps do not define "global" entity		difference is that entity property maps do not define "global" entity
	properties. Instead, they define "self-defined" entity properties as a		properties. Instead, they define "self-defined" entity properties as a
	special case of "resource-specific" entity properties, where the specific		special case of "resource-specific" entity properties, where the specific
	resource is the property map itself. This means that "self-defined"		resource is the property map itself. This means that "self-defined"
	properties are defined within the scope of the property map.</t>		properties are defined within the scope of the property map.</t>
	</section>		</section>
	<section anchor="impact-on-other-properties" numbered="true" toc="default" >		<section anchor="impact-on-other-properties" numbered="true" toc="default" >
	<name>Impact on Other Properties</name>		<name>Impact on Other Properties</name>
	<t>In the present extension, properties can be defined on sets of entity		<t>In the present extension, properties can be defined for sets of entit y
	addresses, rather than just individual endpoint addresses as initially defined		addresses, rather than just individual endpoint addresses as initially defined
	in <xref target="RFC7285" format="default"/>.		in <xref target="RFC7285" format="default"/>.
	This might change the semantics of a property. These sets can be		This might change the semantics of a property. These sets can be,
	for example hierarchical IP address blocks. For instance, a property such as		for example, hierarchical IP address blocks. For instance, a property such as th
	fictitious "geo-location", defined on a set of IP addresses would have a		e
			fictitious "geo-location" defined for a set of IP addresses would have a
	value corresponding to a location representative of all the addresses in this se t.		value corresponding to a location representative of all the addresses in this se t.
	</t>		</t>
	</section>		</section>
	</section>		</section>
	<!-- Examples -->
	<section anchor="examples" numbered="true" toc="default">		<section anchor="examples" numbered="true" toc="default">
	<name>Examples</name>		<name>Examples</name>
	<t>In this document, the HTTP message bodies of all the		<t>In this document, the HTTP message bodies of all the
	examples use Unix-style line-ending character (%x0A) as the line separato r.</t>		examples use Unix-style line-ending character (%x0A) as the line separato r.</t>
	<section anchor="net-map-example" numbered="true" toc="default">		<section anchor="net-map-example" numbered="true" toc="default">
	<name>Network Map</name>		<name>Network Map</name>
	<t>The examples in this section use a very simple default network map:</t>		<t>The examples in this section use a very simple default network map:</t>
	<figure anchor="net-map-values-ex">		<figure anchor="net-map-values-ex">
	<name>Example Default Network Map</name>		<name>Example Default Network Map</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	defaultpid: ipv4:0.0.0.0/0 ipv6:::/0		defaultpid: ipv4:0.0.0.0/0 ipv6:::/0
	pid1: ipv4:192.0.2.0/25		pid1: ipv4:192.0.2.0/25
	pid2: ipv4:192.0.2.0/27		pid2: ipv4:192.0.2.0/27
	pid3: ipv4:192.0.3.0/28		pid3: ipv4:192.0.3.0/28
	pid4: ipv4:192.0.3.16/28		pid4: ipv4:192.0.3.16/28
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>And another simple alternative network map:</t>		<t>And another simple alternative network map:</t>
	<figure anchor="alt-net-map-values-ex">		<figure anchor="alt-net-map-values-ex">
	<name>Example Alternative Network Map</name>		<name>Example Alternative Network Map</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	defaultpid: ipv4:0.0.0.0/0 ipv6:::/0		defaultpid: ipv4:0.0.0.0/0 ipv6:::/0
	pid1: ipv4:192.0.2.0/27		pid1: ipv4:192.0.2.0/27
	pid2: ipv4:192.0.3.0/27		pid2: ipv4:192.0.3.0/27
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	</section>		</section>
	<section anchor="inet-prop-example" numbered="true" toc="default">		<section anchor="inet-prop-example" numbered="true" toc="default">
	<name>Property Definitions</name>		<name>Property Definitions</name>
	<t>Beyond "pid", the examples in this section use four additional fictitious property types		<t>Beyond "pid", the examples in this section use four additional , fictitious property types
	for entities of domain type "ipv4": "countrycode", "ASN", "ISP", and "state".		for entities of domain type "ipv4": "countrycode", "ASN", "ISP", and "state".
	These properties are assumed to be resource-agnostic so their nam e is identical		These properties are assumed to be resource-agnostic so their nam e is identical
	to their type. The entities have the following values:		to their type. The entities have the following values:
	</t>		</t>
	<figure anchor="prop-map-values-ip-ex">		<figure anchor="prop-map-values-ip-ex">
	<name>Example Property Values for Internet Address Domains</name>		<name>Example Property Values for Internet Address Domains</name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	ISP ASN countrycode state		ISP ASN countrycode state
	ipv4:192.0.2.0/23: BitsRus - us -		ipv4:192.0.2.0/23: BitsRus - us -
	ipv4:192.0.2.0/28: - 65543 - NJ		ipv4:192.0.2.0/28: - 65543 - NJ
	ipv4:192.0.2.16/28: - 65543 - CT		ipv4:192.0.2.16/28: - 65543 - CT
	ipv4:192.0.2.1: - - - PA		ipv4:192.0.2.1: - - - PA
	ipv4:192.0.3.0/28: - 65544 - TX		ipv4:192.0.3.0/28: - 65544 - TX
	ipv4:192.0.3.16/28: - 65544 - MN		ipv4:192.0.3.16/28: - 65544 - MN
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>And the examples in this section use the property "region" for the PI D domain of		<t>The examples in this section use the property "region" for the PID do main of
	the default network map with the following values:</t>		the default network map with the following values:</t>
	<figure anchor="prop-map-values-pid-ex">		<figure anchor="prop-map-values-pid-ex">
	<name>Example Property Values for Default Network Map's PID Domain</na me>		<name>Example Property Values for Default Network Map's PID Domain</na me>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	region		region
	pid:defaultpid: -		pid:defaultpid: -
	pid:pid1: us-west		pid:pid1: us-west
	pid:pid2: us-east		pid:pid2: us-east
	pid:pid3: us-south		pid:pid3: us-south
	pid:pid4: us-north		pid:pid4: us-north
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	<t>Note that "-" means the value of the property for the entity is "unde fined". So		<t>Note that "-" means the value of the property for the entity is "unde fined". So
	the entity would inherit a value for this property by the inherit ance rule if		the entity would inherit a value for this property by the inherit ance rule if
	possible. For example, the value of the "ISP" property for "ipv4: 192.0.2.1" is		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" proper ty for		"BitsRus" because of "ipv4:192.0.2.0/24". But the "region" proper ty for
	"pid:defaultpid" has no value because no entity from which it can inherit.</t>		"pid:defaultpid" has no value because there is no entity from whi ch it can inherit.</t>
	<t>Similar to the PID domain of the default network map, the examples in this		<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 alternat ive network map		section use the property "ASN" for the PID domain of the alternat ive network map
	with the following values:</t>		with the following values:</t>
	<figure anchor="alt-prop-map-values-pid-ex">		<figure anchor="alt-prop-map-values-pid-ex">
	<name>Example Property Values for Alternative Network Map's PID Domain </name>		<name>Example Property Values for Alternative Network Map's PID Domain </name>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	ASN		ASN
	pid:defaultpid: -		pid:defaultpid: -
	pid:pid1: 65543		pid:pid1: 65543
	pid:pid2: 65544		pid:pid2: 65544
	]]></artwork>		]]></artwork>
	</figure>		</figure>
	</section>		</section>
	<section anchor="ird-example" numbered="true" toc="default">		<section anchor="ird-example" numbered="true" toc="default">
	<name>Information Resource Directory (IRD)</name>		<name>Information Resource Directory (IRD)</name>
	<t>The following IRD defines ALTO Server information resources that are relevant		<t>The following IRD defines ALTO Server information resources that are relevant
	to the Entity Property Service. It provides a property map for th e		to the Entity Property Service. It provides a property map for th e
	"ISP" and "ASN" properties.		"ISP" and "ASN" properties.
	The server could have provided a single property map for all four		The server could have provided a single property map for all four
	properties, but does not, presumably because the organization tha t runs the		properties, but it does not, presumably because the organization that runs the
	ALTO server believes that a client is not necessarily interested in getting		ALTO server believes that a client is not necessarily interested in getting
	all four properties.</t>		all four properties.</t>
	<t>The server provides several filtered property maps. The first returns all		<t>The server provides several filtered property maps. The first returns all
	four properties, and the second returns only the "pid" property f or the		four properties, and the second returns only the "pid" property f or the
	default network map and the "alt-network-map".</t>		default network map and the "alt-network-map".</t>
	<t>The filtered property maps for the "ISP", "ASN", "countrycode" and "s tate"		<t>The filtered property maps for the "ISP", "ASN", "countrycode", and " state"
	properties do not depend on the default network map (it does not have a		properties do not depend on the default network map (it does not have a
	"uses" capability), because the definitions of those properties d o not depend		"uses" capability) because the definitions of those properties do not depend
	on the default network map. The Filtered Property Map providing t he "pid"		on the default network map. The Filtered Property Map providing t he "pid"
	property does have a "uses" capability for the default network ma p because		property does have a "uses" capability for the default network ma p because
	the default network map defines the values of the "pid" property. </t>		the default network map defines the values of the "pid" property. </t>
	<t>Note that for legacy clients, the ALTO server provides an Endpoint Pr operty		<t>Note that for legacy clients, the ALTO server provides an Endpoint Pr operty
	Service for the "pid" property defined on the endpoints of the de fault		Service for the "pid" property defined for the endpoints of the d efault
	network map and the "alt-network-map".</t>		network map and the "alt-network-map".</t>
	<t>The server provides another filtered Property map resource, named		<t>The server provides another filtered Property map resource, named
	"ane-dc-property-map", that returns fictitious properties named		"ane-dc-property-map", that returns fictitious properties named
	"storage-capacity", "ram" and "cpu" for ANEs that have a persiste nt		"storage-capacity", "ram", and "cpu" for ANEs that have a persist ent
	identifier. The entity domain to which the ANEs belong is "self-d efined" and		identifier. The entity domain to which the ANEs belong is "self-d efined" and
	valid only within the property map.</t>		valid only within the property map.</t>
	<t>The other property maps in the returned IRD are here for purposes o f illustration.</t>		<t>The other property maps in the returned IRD are shown here for purp oses of illustration.</t>
	<figure anchor="example-ird">		<figure anchor="example-ird">
	<name>Example IRD</name>		<name>Example IRD</name>
			<!-- [rfced] Sections 10.3-10.9: Please let us know if the <artwork> in these
			sections should be labeled <sourcecode type="http"> instead.
			-->
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	GET /directory HTTP/1.1		GET /directory HTTP/1.1
	Host: alto.example.com		Host: alto.example.com
	Accept: application/alto-directory+json,application/alto-error+json		Accept: application/alto-directory+json,application/alto-error+json
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Length: 2713		Content-Length: 2713
	Content-Type: application/alto-directory+json		Content-Type: application/alto-directory+json
	{		{
	skipping to change at line 1975 ¶		skipping to change at line 2321 ¶
	<section anchor="prop-map-example" numbered="true" toc="default">		<section anchor="prop-map-example" numbered="true" toc="default">
	<name>Full Property Map Example</name>		<name>Full Property Map Example</name>
	<t>The following example uses the properties and IRD defined in		<t>The following example uses the properties and IRD defined in
	<xref target="ird-example" format="default"/> to retrieve a Prope rty Map for		<xref target="ird-example" format="default"/> to retrieve a Prope rty Map for
	entities with the "ISP" and "ASN" properties.</t>		entities with the "ISP" and "ASN" properties.</t>
	<t>Note that, to be compact, the response does not include the entity		<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		"ipv4:192.0.2.1" because values of all those properties for this entity are
	inherited from other entities.</t>		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		<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", because they have the same value of the		merged into "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		"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		"ipv4:192.0.3.16/28". Both "ipv4:192.0.2.0/27" and "ipv4:192.0.3.
	.3.0/27" omit		0/27" omit
	the value for the "ISP" property, because it is inherited from		the value for the "ISP" property because it is inherited from
	"ipv4:192.0.2.0/23".</t>		"ipv4:192.0.2.0/23".</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	GET /propmap/full/inet-ia HTTP/1.1		GET /propmap/full/inet-ia HTTP/1.1
	Host: alto.example.com		Host: alto.example.com
	Accept: application/alto-propmap+json,application/alto-error+json		Accept: application/alto-propmap+json,application/alto-error+json
	]]></artwork>		]]></artwork>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Content-Length: 418		Content-Length: 418
	skipping to change at line 2012 ¶		skipping to change at line 2358 ¶
	"ipv4:192.0.2.0/27": {".ASN": "65543"},		"ipv4:192.0.2.0/27": {".ASN": "65543"},
	"ipv4:192.0.3.0/27": {".ASN": "65544"}		"ipv4:192.0.3.0/27": {".ASN": "65544"}
	}		}
	}		}
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="filt-prop-map-example-1" numbered="true" toc="default">		<section anchor="filt-prop-map-example-1" numbered="true" toc="default">
	<name>Filtered Property Map Example #1</name>		<name>Filtered Property Map Example #1</name>
	<t>The following example uses the filtered property map resource to requ est the		<t>The following example uses the filtered property map resource to requ est the
	"ISP", "ASN" and "state" properties for several IPv4 addresses.</ t>		"ISP", "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 expli citly		<t>Note that the value of "state" for "ipv4:192.0.2.1" is the only expli citly
	defined property; the other values are all derived by the inherit ance rules		defined property; the other values are all derived from the inher itance rules
	for Internet address entities.</t>		for Internet address entities.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	POST /propmap/lookup/inet-iacs HTTP/1.1		POST /propmap/lookup/inet-iacs HTTP/1.1
	Host: alto.example.com		Host: alto.example.com
	Accept: application/alto-propmap+json,application/alto-error+json		Accept: application/alto-propmap+json,application/alto-error+json
	Content-Length: 158		Content-Length: 158
	Content-Type: application/alto-propmapparams+json		Content-Type: application/alto-propmapparams+json
	{		{
	skipping to change at line 2060 ¶		skipping to change at line 2406 ¶
	"ipv4:192.0.2.17":		"ipv4:192.0.2.17":
	{".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"}		{".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"}
	}		}
	}		}
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="filt-prop-map-example-2" numbered="true" toc="default">		<section anchor="filt-prop-map-example-2" numbered="true" toc="default">
	<name>Filtered Property Map Example #2</name>		<name>Filtered Property Map Example #2</name>
	<t>The following example uses the filtered property map resource to requ est the		<t>The following example uses the filtered property map resource to requ est the
	"ASN", "countrycode" and "state" properties for several IPv4 pref ixes.</t>		"ASN", "countrycode", and "state" properties for several IPv4 pre fixes.</t>
	<t>Note that the property values for both entities "ipv4:192.0.2.0/26" a nd		<t>Note that the property values for both entities "ipv4:192.0.2.0/26" a nd
	"ipv4:192.0.3.0/26" are not explicitly defined. They are inherite d from the		"ipv4:192.0.3.0/26" are not explicitly defined. They are inherite d from the
	entity "ipv4:192.0.2.0/23".</t>		entity "ipv4:192.0.2.0/23".</t>
	<t>Also note that some entities like "ipv4:192.0.2.0/28" and		<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		"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		request. The response includes them because they are refinements of the
	requested entities and have different values for the requested pr operties.</t>		requested entities and have different values for the requested pr operties.</t>
	<t>The entity "ipv4:192.0.4.0/26" is not included in the response, becau		<t>The entity "ipv4:192.0.4.0/26" is not included in the response becaus
	se there		e there
	are neither entities which it is inherited from, nor entities inh		are neither entities from which it is inherited, nor entities inh
	erited from		erited from
	it.</t>		it.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	POST /propmap/lookup/inet-iacs HTTP/1.1		POST /propmap/lookup/inet-iacs HTTP/1.1
	Host: alto.example.com		Host: alto.example.com
	Accept: application/alto-propmap+json,application/alto-error+json		Accept: application/alto-propmap+json,application/alto-error+json
	Content-Length: 174		Content-Length: 174
	Content-Type: application/alto-propmapparams+json		Content-Type: application/alto-propmapparams+json
	{		{
	skipping to change at line 2121 ¶		skipping to change at line 2467 ¶
	".state": "MN"}		".state": "MN"}
	}		}
	}		}
	]]></artwork>		]]></artwork>
	</section>		</section>
	<section anchor="filt-prop-map-example-3" numbered="true" toc="default">		<section anchor="filt-prop-map-example-3" numbered="true" toc="default">
	<name>Filtered Property Map Example #3</name>		<name>Filtered Property Map Example #3</name>
	<t>The following example uses the filtered property map resource to requ est the		<t>The following example uses the filtered property map resource to requ est the
	"default-network-map.pid" property and the "alt-network-map.pid" property for		"default-network-map.pid" property and the "alt-network-map.pid" property for
	a set of IPv4 addresses and prefixes.</t>		a set of IPv4 addresses and prefixes.</t>
	<t>Note that the entity "ipv4:192.0.3.0/27" is decomposed into two entit ies		<t>Note that the entity "ipv4:192.0.3.0/27" is decomposed into two entit ies:
	"ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28", as they have different		"ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28", as they have different
	"default-network-map.pid" property values.</t>		"default-network-map.pid" property values.</t>
	<artwork name="" type="" align="left" alt=""><![CDATA[		<artwork name="" type="" align="left" alt=""><![CDATA[
	POST /propmap/lookup/pid HTTP/1.1		POST /propmap/lookup/pid HTTP/1.1
	Host: alto.example.com		Host: alto.example.com
	Accept: application/alto-propmap+json,application/alto-error+json		Accept: application/alto-propmap+json,application/alto-error+json
	Content-Length: 222		Content-Length: 222
	Content-Type: application/alto-propmapparams+json		Content-Type: application/alto-propmapparams+json
	{		{
	skipping to change at line 2253 ¶		skipping to change at line 2599 ¶
	}		}
	}		}
	]]></artwork>		]]></artwork>
	</section>		</section>
	</section>		</section>
	<section anchor="SecSC" numbered="true" toc="default">		<section anchor="SecSC" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>Both Property Map and Filtered Property Map defined in this document fi t into		<t>Both Property Map and Filtered Property Map defined in this document fi t into
	the architecture of the ALTO base protocol, and hence the Security		the architecture of the ALTO base protocol, and hence the Security
	Considerations (Section 15 of <xref target="RFC7285" format="default"/>) of the base protocol fully apply:		Considerations (<xref target="RFC7285" section="15" sectionFormat="of" format="d efault"/>) of the base protocol fully apply:
	authenticity and integrity of ALTO information (i.e., authenticity and		authenticity and integrity of ALTO information (i.e., authenticity and
	integrity of Property Maps), potential undesirable guidance from		integrity of Property Maps), potential undesirable guidance from
	authenticated ALTO information (e.g., potentially imprecise or even wrong		authenticated ALTO information (e.g., potentially imprecise or even wrong
	value of a property such as geo-location), confidentiality of ALTO		value of a property such as geo-location), confidentiality of ALTO
	information (e.g., exposure of a potentially sensitive entity property such		information (e.g., exposure of a potentially sensitive entity property such
	as geo-location), privacy for ALTO users, and availability of ALTO services		as geo-location), privacy for ALTO users, and availability of ALTO services
	should all be considered.</t>		should all be considered.</t>
	<t>ALTO clients using this extension should in addition be aware that the entity		<t>ALTO clients using this extension should in addition be aware that the entity
	properties they require may convey more details than the endpoint propert ies		properties they require may convey more details than the endpoint propert ies
	conveyed by using <xref target="RFC7285" format="default"/>.		conveyed by using <xref target="RFC7285" format="default"/>.
	Client requests may reveal details on their		Client requests may reveal details of their
	activity or plans thereof, that a malicious Server, that is in a position		activity or plans thereof such that a malicious Server, which is in a pos
	to do so,		ition to do so,
	may monetize or use for		may monetize or use for
	attacks or undesired surveillance. Likewise, ALTO Servers expose entities and		attacks or undesired surveillance. Likewise, ALTO Servers expose entities and
	properties related to specific parts of the infrastructure that reveal		properties related to specific parts of the infrastructure that reveal
	details on capabilities, locations, or resource availability. These detai ls		details of capabilities, locations, or resource availability. These detai ls
	may be maliciously used for competition purposes, or to cause resource		may be maliciously used for competition purposes, or to cause resource
	shortage or undesired publication.</t>		shortage or undesired publication.</t>
	<t>To address these concerns, the Property Maps provided by this extension		<t>To address these concerns, the Property Maps provided by this extension
	require additional attention on two security considerations discussed in		require additional attention to two security considerations discussed in:
	<xref target="RFC7285" format="default"/>: "potential undesirable guidance from		Section <xref target="RFC7285" section="15.2" sectionFormat="bare">"Potential Un
	authenticated ALTO		desirable Guidance from Authenticated ALTO Information"</xref> of <xref target="
	information" (Section 15.2 of <xref target="RFC7285" format="default"/>) and "co		RFC7285" format="default"/>
	nfidentiality of ALTO		and Section <xref target="RFC7285" section="15.3" sectionFormat="bare">"Confiden
	information" (Section 15.3 of <xref target="RFC7285" format="default"/>). Threat		tiality of ALTO
	s to the availability of		Information"</xref> of <xref target="RFC7285" format="default"/>. Threats to the
	the ALTO Service caused by highly demanding queries should be addressed as		availability of
	specified in Section 15.5 of <xref target="RFC7285" format="default"/>.</t>		the ALTO service caused by highly demanding queries should be addressed as
			specified in <xref target="RFC7285" section="15.5" sectionFormat="of" format="de
			fault"/>.</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Potential undesirable guidance from authenticated ALTO information: it can		<t>Potential undesirable guidance from authenticated ALTO information: this can
	be caused by Property values that change over time and thus lead to		be caused by Property values that change over time and thus lead to
	performance degradation or system rejection of application requests. </t>		performance degradation or system rejection of application requests. </t>
	<t>		<t>
	To avoid these consequences, a more robust ALTO client should adopt and		To avoid these consequences, a more robust ALTO client should adopt and
	extend protection strategies specified in Section 15.2 of <xref target="RFC728 5" format="default"/>.		extend protection strategies specified in <xref target="RFC7285" section="15.2 " sectionFormat="of" format="default"/>.
	For example, to be notified immediately when a particular ALTO value that		For example, to be notified immediately when a particular ALTO value that
	the Client depends on changes, it is RECOMMENDED that both the ALTO		the Client depends on changes, it is <bcp14>RECOMMENDED</bcp14> that both the
	Client and ALTO Server using this extension implement "Application-Layer		ALTO
	Traffic Optimization (ALTO) Incremental Updates Using Server-Sent Events		Client and ALTO Server using this extension implement
	(SSE)" <xref target="RFC8895" format="default"/>.</t>		"<xref target="RFC8895" format="title"/>" <xref target="RFC8895" format="defau
			lt"/>.</t>
	</li>		</li>
	<li>		<li>
	<t>Confidentiality of ALTO information: as discussed in Section 15 of		<t>Confidentiality of ALTO information: as discussed in
	<xref target="RFC7285" format="default"/>, properties may have sensitive custome		<xref target="RFC7285" section="15" sectionFormat="of" format="default"/>, prope
	r-specific information.		rties may have sensitive customer-specific information.
	If this is the case, an ALTO Server may limit access to those properties by		If this is the case, an ALTO Server may limit access to those properties by
	providing several different property maps. For non-sensitive properties,		providing several different property maps. For a nonsensitive properties,
	the ALTO Server would provide a URI which accepts requests from any client.		the ALTO Server would provide a URI that accepts requests from any client.
	Sensitive properties, on the other hand, would only be available via a		Sensitive properties, on the other hand, would only be available via a
	secure URI which would require client authentication. Another way is to		secure URI that would require client authentication. Another way is to
	expose highly abstracted coarse-grained property values to all Clients while		expose highly abstracted, coarse-grained property values to all Clients while
	restricting access to URIs exposing more fine-grained values to authorized		restricting access to URIs that expose more fine-grained values to authorized
	Clients. Restricted access URIs may be gathered in delegate IRDs as		Clients. Restricted access URIs may be gathered in delegate IRDs as
	specified in Section 9.2.4 of <xref target="RFC7285" format="default"/>. </t>		specified in <xref target="RFC7285" section="9.2.4" sectionFormat="of" format="d efault"/>. </t>
	<t>		<t>
	Also, while technically this document does not introduce any security		Also, while technically this document does not introduce any security
	risks not inherent in the Endpoint Property Service defined by <xref target="R FC7285" format="default"/>,		risks not inherent in the Endpoint Property Service defined by <xref target="R FC7285" format="default"/>,
	the GET-mode property map resource defined in this document does make it		the GET-mode property map resource defined in this document does make it
	easier for a client to download large numbers of property values.		easier for a client to download large numbers of property values.
	Accordingly, an ALTO Server should limit GET-mode property maps to		Accordingly, an ALTO Server should limit GET-mode property maps to
	properties that do not contain sensitive data. </t>		properties that do not contain sensitive data. </t>
	<t>		<t>
	Section 12 of this document specifies that the ALTO service		<xref target="iana-considerations"/> of this document specifies that the ALTO
	provider MUST be aware of the potential sensitivity of exposed entity		service
	domains and properties. Section 12.2.2. (ALTO Entity Domain Type		provider <bcp14>MUST</bcp14> be aware of the potential sensitivity of exposed
	Registration Process) of this document specifies that when the		entity
	registration of an entity domain type is requested at the IANA, the		domains and properties. <xref target="dom-reg-process"/> (<xref target="dom-re
	request MUST include security considerations that show awareness of how		g-process" format="title"/>)
			of this document specifies that when the
			registration of an entity domain type is requested of IANA, the
			request <bcp14>MUST</bcp14> include security considerations that show awarenes
			s of how
	the exposed entity addresses may be related to private information about		the exposed entity addresses may be related to private information about
	an ALTO client or an infrastructure service provider. Likewise, Section		an ALTO client or an infrastructure service provider. Likewise,
	12.3. (ALTO Entity Property Type Registry) of this document specifies		<xref target="IANAEntityProp"/> (<xref target="IANAEntityProp" format="title"/
	that when the registration of a property type is requested at the IANA,		>) of this document specifies
	the request MUST include security considerations that explain why this		that when the registration of a property type is requested of IANA,
			the request <bcp14>MUST</bcp14> include security considerations that explain w
			hy this
	property type is required for ALTO-based operations. </t>		property type is required for ALTO-based operations. </t>
	<t>		<t>
	The risk of ALTO information being leaked to malicious Clients or third		The risk of ALTO information being leaked to malicious Clients or third
	parties is addressed similarly to Section 7 of <xref target="RFC8896" format="		parties is addressed similarly to <xref target="RFC8896" section="7" sectionFo
	default"/>. ALTO		rmat="of" format="default"/>. ALTO
	clients and servers SHOULD support TLS 1.3 <xref target="RFC8446" format="defa		clients and servers <bcp14>SHOULD</bcp14> support TLS 1.3 <xref target="RFC844
	ult"/>.		6" format="default"/>.
	</t>		</t>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<!-- IANA Considerations -->
	<section anchor="iana-considerations" numbered="true" toc="default">		<section anchor="iana-considerations" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This document defines additional application/alto-* media types, that a re		<t>This document defines additional application/alto-* media types, which are
	listed in <xref target="TableMediaTypes" format="default"/>.		listed in <xref target="TableMediaTypes" format="default"/>.
	It defines		It defines
	an ALTO Entity Domain Type Registry that extends the ALTO Address Type		the "ALTO Entity Domain Types" registry that extends the "ALTO Address Ty
	Registry defined in <xref target="RFC7285" format="default"/>.		pes"
	It also defines an ALTO Entity Property Type		registry defined in <xref target="RFC7285" format="default"/>.
	Registry that extends the ALTO endpoint property registry defined in		It also defines the "ALTO Entity Property Types"
			registry that extends the "ALTO Endpoint Property Types" registry defined
			in
	<xref target="RFC7285" format="default"/>.</t>		<xref target="RFC7285" format="default"/>.</t>
	<table anchor="TableMediaTypes" align="center">		<table anchor="TableMediaTypes" align="center">
	<name>Additional ALTO Media Types.</name>		<name>Additional ALTO Media Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Type</th>		<th align="left">Type</th>
	<th align="left">Subtype</th>		<th align="left">Subtype</th>
	<th align="left">Specification</th>		<th align="left">Specification</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">application</td>		<td align="left">application</td>
	<td align="left">alto-propmap+json</td>		<td align="left">alto-propmap+json</td>
	<td align="left">		<td align="left">
	<xref target="FullPropMapMediaType" format="default"/></td>		<xref target="FullPropMapMediaType" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">application</td>		<td align="left">application</td>
	<td align="left">alto-propmapparams+json</td>		<td align="left">alto-propmapparams+json</td>
	<td align="left">		<td align="left">
	<xref target="filter-prop-map-params" format="default"/></td>		<xref target="FilterPropMapMediaType" format="default"/></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<section anchor="application-alto-propmap-media-type" numbered="true" toc= "default">		<section anchor="application-alto-propmap-media-type" numbered="true" toc= "default">
	<name>application/alto-propmap+json Media Type</name>		<name>application/alto-propmap+json Media Type</name>
	<dl newline="true" spacing="normal">		<dl newline="true" spacing="normal">
	<dt>Type name:</dt>		<dt>Type name:</dt>
	<dd>application</dd>		<dd>application</dd>
	skipping to change at line 2394 ¶		skipping to change at line 2738 ¶
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>Encoding considerations are identical to those specified for the		<dd>Encoding considerations are identical to those specified for the
	"application/json" media type. See <xref target="RFC8259" format= "default"/>.</dd>		"application/json" media type. See <xref target="RFC8259" format= "default"/>.</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>Security considerations related to the generation and consumption of ALTO		<dd>Security considerations related to the generation and consumption of ALTO
	Protocol messages are discussed in Section 15 of		Protocol messages are discussed in
	<xref target="RFC7285" format="default"/>		<xref target="RFC7285" section="15" sectionFormat="of" format="de
			fault"/>
	and <xref target="SecSC" format="default"/> of this document.</dd >		and <xref target="SecSC" format="default"/> of this document.</dd >
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	This document is the specification for this media type.		This document is the specification for this media type.
	See <xref target="FullPropMapMediaType" format="default"/>.</dd>		See <xref target="FullPropMapMediaType" format="default"/>.</dd>
	skipping to change at line 2407 ¶		skipping to change at line 2751 ¶
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	This document is the specification for this media type.		This document is the specification for this media type.
	See <xref target="FullPropMapMediaType" format="default"/>.</dd>		See <xref target="FullPropMapMediaType" format="default"/>.</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>ALTO servers and ALTO clients <xref target="RFC7285" format="defau lt"/>,		<dd>ALTO servers and ALTO clients <xref target="RFC7285" format="defau lt"/>,
	either stand alone or embedded within other applications,		either standalone or embedded within other applications,
	when the queried resource is a property map, whether filtered or not. </dd>		when the queried resource is a property map, whether filtered or not. </dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	<dt>Additional information:</dt>		<dt>Additional information:</dt>
	<dd>		<dd>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Magic number(s):</dt>		<dt>Magic number(s):</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	skipping to change at line 2465 ¶		skipping to change at line 2810 ¶
	<dt>Optional parameters:</dt>		<dt>Optional parameters:</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	<dt>Encoding considerations:</dt>		<dt>Encoding considerations:</dt>
	<dd>Encoding considerations are identical to those specified for the		<dd>Encoding considerations are identical to those specified for the
	"application/json" media type. See <xref target="RFC8259" format= "default"/>.</dd>		"application/json" media type. See <xref target="RFC8259" format= "default"/>.</dd>
	<dt>Security considerations:</dt>		<dt>Security considerations:</dt>
	<dd>Security considerations related to the generation and consumption of ALTO		<dd>Security considerations related to the generation and consumption of ALTO
	Protocol messages are discussed in Section 15 of		Protocol messages are discussed in
	<xref target="RFC7285" format="default"/>		<xref target="RFC7285" section="15" sectionFormat="of" format="de
			fault"/>
	and <xref target="SecSC" format="default"/> of this document.</dd >		and <xref target="SecSC" format="default"/> of this document.</dd >
	<dt>Interoperability considerations:</dt>		<dt>Interoperability considerations:</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	<dt>Published specification:</dt>		<dt>Published specification:</dt>
	<dd>		<dd>
	This document is the specification for this media type.		This document is the specification for this media type.
	See <xref target="filter-prop-map-params" format="default"/>.</dd>		See <xref target="FilterPropMapMediaType" format="default"/>.</dd>
	<dt>Applications that use this media type:</dt>		<dt>Applications that use this media type:</dt>
	<dd>ALTO servers and ALTO clients <xref target="RFC7285" format="defau lt"/>,		<dd>ALTO servers and ALTO clients <xref target="RFC7285" format="defau lt"/>,
	either stand alone or embedded within other applications,		either standalone or embedded within other applications,
	when the queried resource is a filtered property map.		when the queried resource is a filtered property map.
	This media-type indicates the data format used by the ALTO client to s upply the property map		This media type indicates the data format used by the ALTO client to s upply the property map
	filtering parameters.		filtering parameters.
	</dd>		</dd>
	<dt>Fragment identifier considerations:</dt>		<dt>Fragment identifier considerations:</dt>
	<dd>n/a</dd>		<dd>n/a</dd>
	<dt>Additional information:</dt>		<dt>Additional information:</dt>
	<dd>		<dd>
	<dl newline="false" spacing="normal">		<dl newline="false" spacing="normal">
	<dt>Magic number(s):</dt>		<dt>Magic number(s):</dt>
	skipping to change at line 2519 ¶		skipping to change at line 2864 ¶
	<dt>Author:</dt>		<dt>Author:</dt>
	<dd>See Authors' Addresses section.</dd>		<dd>See Authors' Addresses section.</dd>
	<dt>Change controller:</dt>		<dt>Change controller:</dt>
	<dd>Internet Engineering Task Force (mailto:iesg@ietf.org).</dd>		<dd>Internet Engineering Task Force (mailto:iesg@ietf.org).</dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="IANADomain" numbered="true" toc="default">		<section anchor="IANADomain" numbered="true" toc="default">
	<name>ALTO Entity Domain Type Registry</name>		<name>ALTO Entity Domain Types Registry</name>
	<t>This document requests IANA to create and maintain the "ALTO Entity D		<t>IANA has created and will maintain the "ALTO Entity Domain Types"
	omain Type		registry listed in <xref target="TableEntityDomainNames" format="
	Registry", listed in <xref target="TableEntityDomainNames" format		default"/>.
	="default"/>.		The first row lists information items that must be provided with
	The first line lists information items that must be provided with		each
	each
	registered entity domain type.		registered entity domain type.
	<xref target="dom-reg-process" format="default"/> specifies how t o document		<xref target="dom-reg-process" format="default"/> specifies how t o document
	these items and provides guidance on the security considerations		these items and in addition provides guidance on the security con
	item that must		siderations item that must
	be documented in addition.		be documented.
	</t>		</t>
	<table anchor="TableEntityDomainNames" align="center">		<table anchor="TableEntityDomainNames" align="center">
	<name>ALTO Entity Domain Types</name>		<name>ALTO Entity Domain Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Identifier</th>		<th align="left">Identifier</th>
	<th align="left">Entity Identifier Encoding</th>		<th align="left">Entity Identifier Encoding</th>
	<th align="left">Hierarchy &amp; Inheritance</th>		<th align="left">Hierarchy and Inheritance</th>
	<th align="left">Media Type of Defining Resource</th>		<th align="left">Media Type of Defining Resource</th>
	<th align="left">Mapping to ALTO Address Type</th>		<th align="left">Mapping to ALTO Address Type</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">ipv4</td>		<td align="left">ipv4</td>
	<td align="left">See <xref target="ipv4-domain" format="default"/> </td>		<td align="left">See <xref target="ipv4-domain" format="default"/> </td>
	<td align="left">See <xref target="inet-inheritance" format="defau lt"/></td>		<td align="left">See <xref target="inet-inheritance" format="defau lt"/></td>
	<td align="left">application/alto-networkmap+json</td>		<td align="left">application/alto-networkmap+json</td>
	skipping to change at line 2572 ¶		skipping to change at line 2917 ¶
	</tbody>		</tbody>
	</table>		</table>
	<t>This registry serves two purposes. First, it ensures uniqueness of		<t>This registry serves two purposes. First, it ensures uniqueness of
	identifiers referring to ALTO entity domain types. Second, it states the		identifiers referring to ALTO entity domain types. Second, it states the
	requirements for allocated entity domain types.</t>		requirements for allocated entity domain types.</t>
	<t>		<t>
	As specified in <xref target="domain-types" format="default"/>, identifiers pref ixed		As specified in <xref target="domain-types" format="default"/>, identifiers pref ixed
	with "priv:" are reserved for Private Use without a need to register with IANA		with "priv:" are reserved for Private Use without a need to register with IANA
	</t>		</t>
	<section anchor="consistency-procedure" numbered="true" toc="default">		<section anchor="consistency-procedure" numbered="true" toc="default">
	<name>Consistency Procedure between ALTO Address Type Registry and ALT		<name>Consistency Procedure between ALTO Address Types Registry and AL
	O Entity Domain Type Registry</name>		TO Entity Domain Types Registry</name>
	<t>One potential issue of introducing the "ALTO Entity Domain Type Reg		<t>One potential issue of introducing the "ALTO Entity Domain Types" r
	istry" is		egistry is
	its relationship with the "ALTO Address Types Registry" already defined in		its relationship with the "ALTO Address Types" registry already defined in
	Section 14.4 of <xref target="RFC7285" format="default"/>. In particular, the en		<xref target="RFC7285" section="14.4" sectionFormat="of" format="default"/>. In
	tity identifier of a type		particular, the entity identifier of a type
	of an entity domain registered in the "ALTO Entity Domain Type Registry" MAY		of an entity domain registered in the "ALTO Entity Domain Types" registry <bcp14
	match an address type defined in "ALTO Address Type Registry". It is		>MAY</bcp14>
			match an address type defined in "ALTO Address Types" registry. It is
	necessary to precisely define and guarantee the consistency between "ALTO		necessary to precisely define and guarantee the consistency between "ALTO
	Address Type Registry" and "ALTO Entity Domain Registry".</t>		Address Types" registry and "ALTO Entity Domain Types" registry.</t>
	<t>We define that the ALTO Entity Domain Type Registry is consistent w		<t>We define that the "ALTO Entity Domain Types" registry is consisten
	ith ALTO		t with "ALTO
	Address Type Registry if two conditions are satisfied:</t>		Address Types" registry if two conditions are satisfied:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>When an address type is already or able to be registered in the		<li>When an address type is already registered or is able to be regi
	ALTO Address		stered in the "ALTO Address
	Type Registry <xref target="RFC7285" format="default"/>, the same identifier MUS		Types" registry <xref target="RFC7285" format="default"/>, the same identifier <
	T be used when a		bcp14>MUST</bcp14> be used when a
	corresponding entity domain type is registered in the ALTO Entity Domain Type		corresponding entity domain type is registered in the "ALTO Entity Domain Types"
	Registry.</li>		registry.</li>
			<!-- [rfced] Section 12.3.1: FYI, we have updated "their addresses encoding" to
			"their address encodings" in the following statement. Please let us know if any
			changes are necessary:
			Original:
			* If an ALTO entity domain type has the same identifier as an ALTO
			address type, their addresses encoding MUST be compatible.
			Current:
			* If an ALTO entity domain type has the same identifier as an ALTO
			address type, their address encodings MUST be compatible.
			-->
	<li>If an ALTO entity domain type has the same identifier as an ALTO address type,		<li>If an ALTO entity domain type has the same identifier as an ALTO address type,
	their addresses encoding MUST be compatible.</li>		their address encodings <bcp14>MUST</bcp14> be compatible.</li>
	</ul>		</ul>
	<t>To achieve this consistency, the following items MUST be checked be fore		<t>To achieve this consistency, the following items <bcp14>MUST</bcp14 > be checked before
	registering a new ALTO entity domain type in a future document:</t>		registering a new ALTO entity domain type in a future document:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>Whether the ALTO Address Type Registry contains an address type that can be		<li>Whether the "ALTO Address Types" registry contains an address ty pe that can be
	used as an identifier for the candidate entity domain type identifier. This has been		used as an identifier for the candidate entity domain type identifier. This has been
	done for the identifiers "ipv4" and "ipv6" of <xref target="TableEntityDomainNam es" format="default"/>.</li>		done for the identifiers "ipv4" and "ipv6" of <xref target="TableEntityDomainNam es" format="default"/>.</li>
	<li>Whether the candidate entity domain type identifier can potentia lly be an		<li>Whether the candidate entity domain type identifier can potentia lly be an
	endpoint address type, as defined in Sections 2.1 and 2.2 of <xref target="RFC72		endpoint address type, as defined in Sections <xref target="RFC7285" section="2.
	85" format="default"/>.</li>		1" sectionFormat="bare" format="default"/>
			and <xref target="RFC7285" section="2.2" sectionFormat="bare" format="default"/>
			of <xref target="RFC7285" format="default"/>.</li>
	</ul>		</ul>
	<t>When a new ALTO entity domain type is registered, the consistency w		<t>When a new ALTO entity domain type is registered, the consistency w
	ith the ALTO		ith the "ALTO
	Address Type Registry MUST be ensured by the following procedure:</t>		Address Types" registry <bcp14>MUST</bcp14> be ensured by the following procedur
			e:</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Test: Do corresponding entity domain type identifiers match a k nown "network" address type?		<t>Test: Do corresponding entity domain type identifiers match a k nown "network" address type?
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>If yes (e.g., cell, MAC or socket addresses):		<t>If yes (e.g., cell, MAC, or socket addresses):
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>		<li>
	<t>Test: Is such an address type present in the ALTO Addre		<t>Test: Is such an address type present in the "ALTO Addr
	ss Type		ess Types"
	Registry?		registry?
	</t>		</t>
	<ul spacing="normal">		<ul spacing="normal">
	<li>If yes: Set the new ALTO entity domain type identifi er to be the		<li>If yes: Set the new ALTO entity domain type identifi er to be the
	found ALTO address type identifier.</li>		found ALTO address type identifier.</li>
	<li>If no: Define a new ALTO entity domain type identifi er and use it to		<li>If no: Define a new ALTO entity domain type identifi er and use it to
	register a new address type in the ALTO Address Type Registry		register a new address type in the "ALTO Address Types" registry
	following Section 14.4 of <xref target="RFC7285" format="default"/>.</li>		following <xref target="RFC7285" section="14.4" sectionFormat="of" format="defau
			lt"/>.</li>
	</ul>		</ul>
	</li>		</li>
	<li>Use the new ALTO entity domain type identifier to regist er a new ALTO		<li>Use the new ALTO entity domain type identifier to regist er a new ALTO
	entity domain type in the ALTO Entity Domain Type Registry following		entity domain type in the "ALTO Entity Domain Types" registry following
	<xref target="dom-reg-process" format="default"/> of this document.</li>		<xref target="dom-reg-process" format="default"/> of this document.</li>
	</ul>		</ul>
	</li>		</li>
	<li>If no (e.g., pid name, ane name or country code): Proceed wi		<!-- [rfced] Section 12.3.1: Should the following names be in quotes?
	th the ALTO
			Current:
			- If no (e.g., pid name, ane name, or country code): Proceed with
			the ALTO Entity Domain Type registration as described in
			Section 12.3.2.
			Perhaps:
			- If no (e.g., "pid" name, "ane" name, or "countrycode"): Proceed with
			the ALTO Entity Domain Type registration as described in
			Section 12.3.2.
			-->
			<li>If no (e.g., pid name, ane name, or country code): Proceed w
			ith the ALTO
	Entity Domain Type registration as described in <xref target="dom-reg-process" f ormat="default"/>.</li>		Entity Domain Type registration as described in <xref target="dom-reg-process" f ormat="default"/>.</li>
	</ul>		</ul>
	</li>		</li>
	</ul>		</ul>
	</section>		</section>
	<section anchor="dom-reg-process" numbered="true" toc="default">		<section anchor="dom-reg-process" numbered="true" toc="default">
	<name>ALTO Entity Domain Type Registration Process</name>		<name>ALTO Entity Domain Type Registration Process</name>
			<!-- [rfced] Section 12.3.2: Does the following update improve the readability o
			f the sentence?
			Current:
			RFCs defining new entity domain types MUST indicate how an entity in
			a registered type of domain is encoded as an EntityID and, if
			applicable, the rules defining the entity hierarchy and property
			inheritance.
			Perhaps (changing "the rules defining" to "provide the rules for defining"):
			RFCs defining new entity domain types MUST indicate how an entity in
			a registered type of domain is encoded as an EntityID, and, if
			applicable, provide the rules for defining the entity hierarchy and
			property inheritance.
			-->
	<t>New ALTO entity domain types are assigned after IETF Review <xref t arget="RFC8126" format="default"/> to		<t>New ALTO entity domain types are assigned after IETF Review <xref t arget="RFC8126" format="default"/> to
	ensure that proper documentation regarding the new ALTO entity do main types		ensure that proper documentation regarding the new ALTO entity do main types
	and their security considerations has been provided. RFCs definin g new entity		and their security considerations has been provided. RFCs definin g new entity
	domain types MUST indicate how an entity in a registered type of		domain types <bcp14>MUST</bcp14> indicate how an entity in a regi
	domain is		stered type of domain is
	encoded as an EntityID, and, if applicable, the rules defining th		encoded as an EntityID and, if applicable, the rules defining the
	e entity		entity
	hierarchy and property inheritance. Updates and deletions of ALTO entity		hierarchy and property inheritance. Updates and deletions of ALTO entity
	domains types follow the same procedure.		domains types follow the same procedure.
	</t>		</t>
	<t>Registered ALTO entity domain type identifiers MUST conform to the		<t>Registered ALTO entity domain type identifiers <bcp14>MUST</bcp14> conform to the
	syntactical requirements specified in <xref target="domain-names" format="default"/>.		syntactical requirements specified in <xref target="domain-names" format="default"/>.
	Identifiers are to be recorded and displayed as strings.		Identifiers are to be recorded and displayed as strings.
	</t>		</t>
	<t>Requests to the IANA to add a new value to the Entity Domain Type r		<t>Requests to IANA to add a new value to the "ALTO Entity Domain Type
	egistry		s" registry
	MUST include the following information:</t>		<bcp14>MUST</bcp14> include the following information:</t>
	<ul spacing="normal">		<dl spacing="normal">
	<li>Identifier: The name of the desired ALTO entity domain type.</li		<dt>Identifier:</dt>
	>		<dd>The name of the desired ALTO entity domain type.</dd>
	<li>Entity Identifier Encoding: The procedure for encoding the ident
	ifier of an		<dt>Entity Identifier Encoding:</dt>
			<dd>The procedure for encoding the identifier of an
	entity of the registered domain type as an EntityID (see		entity of the registered domain type as an EntityID (see
	<xref target="entity-addrs" format="default"/>). If corre sponding entity identifiers of an entity domain		<xref target="entity-addrs" format="default"/>). If corre sponding entity identifiers of an entity domain
	type match a known "network" address type, the Entity Ide ntifier Encoding		type match a known "network" address type, the Entity Ide ntifier Encoding
	of this domain identifier MUST include both Address Encod		of this domain identifier <bcp14>MUST</bcp14> include bot
	ing and Prefix		h Address Encoding and Prefix
	Encoding of the same identifier registered in the ALTO Ad		Encoding of the same identifier registered in the "ALTO A
	dress Type		ddress Types"
	Registry <xref target="RFC7285" format="default"/>. To de		registry <xref target="RFC7285" format="default"/>. To de
	fine properties, an individual entity identifier		fine properties, an individual entity identifier
	and the corresponding full-length prefix MUST be consider		and the corresponding full-length prefix <bcp14>MUST</bcp
	ed aliases for the		14> be considered aliases for the
	same entity.</li>		same entity.</dd>
	<li>Hierarchy: If the entities form a hierarchy, the procedure for d
	etermining		<dt>Hierarchy:</dt>
	that hierarchy.</li>		<dd>If the entities form a hierarchy, the procedure for determining
	<li>Inheritance: If entities can inherit property values from other		that hierarchy.</dd>
	entities, the
	procedure for determining that inheritance.</li>		<dt>Inheritance:</dt>
	<li>		<dd>If entities can inherit property values from other entities, the
	<t>Media type of defining information resource: Some entity domain		procedure for determining that inheritance.</dd>
	types allow
			<dt>Media type of defining information resource:</dt>
			<dd>Some entity domain types allow
	an entity domain name to be combined with an information resource name to		an entity domain name to be combined with an information resource name to
	define a resource-specific entity domain. Such an informa tion resource is		define a resource-specific entity domain. Such an informa tion resource is
	called "defining information resource",		called a "defining information resource" and is
	defined in <xref target="def-ir" format="default"/>.		defined in <xref target="def-ir" format="default"/>.
	For each entity domain type, the potential defining infor mation resources		For each entity domain type, the potential defining infor mation resources
	have one common media type. This unique common media type is specific to		have one common media type. This unique common media type is specific to
	the entity domain type and MUST be specified.		the entity domain type and <bcp14>MUST</bcp14> be specifi
	</t>		ed. </dd>
	</li>
	<li>Mapping to ALTO Address Type: A boolean value to indicate if the		<dt>Mapping to ALTO Address Type:</dt>
	entity domain		<dd>A boolean value to indicate if the entity domain
	type can be mapped to the ALTO address type with the same		type can be mapped to the ALTO address type with the same
	identifier.</li>		identifier.</dd>
	<li>Security Considerations: In some usage scenarios, entity identif
	iers carried in		<dt>Security Considerations:</dt>
			<dd>In some usage scenarios, entity identifiers carried in
	ALTO Protocol messages may reveal information about an AL TO client or an ALTO		ALTO Protocol messages may reveal information about an AL TO client or an ALTO
	service provider. Applications and ALTO service providers using addresses of		service provider. Applications and ALTO service providers using addresses of
	the registered type should be cognizant of how (or if) th e addressing scheme		the registered type should be cognizant of how (or if) th e addressing scheme
	relates to private information and network proximity.</li		relates to private information and network proximity.</dd
	>		>
	</ul>		</dl>
	<t>This specification requests registration of the identifiers "ipv4",		<t>IANA has registered the identifiers "ipv4", "ipv6", and
	"ipv6" and
	"pid", as shown in <xref target="TableEntityDomainNames" format=" default"/>.</t>		"pid", as shown in <xref target="TableEntityDomainNames" format=" default"/>.</t>
	</section>		</section>
	</section>		</section>
	<section anchor="IANAEntityProp" numbered="true" toc="default">		<section anchor="IANAEntityProp" numbered="true" toc="default">
	<name>ALTO Entity Property Type Registry</name>		<name>ALTO Entity Property Types Registry</name>
	<t>This document requests IANA to create and maintain the "ALTO Entity P		<t>IANA has created and will maintain the "ALTO Entity Property
	roperty		Types" registry, which is listed in <xref target="TablePropertyTy
	Type Registry", listed in <xref target="TablePropertyTypes" forma		pes" format="default"/>.
	t="default"/>.
	</t>		</t>
	<t>This registry extends the "ALTO Endpoint Property Type Registry", def		<t>This registry extends the "ALTO Endpoint Property Types" registry, de
	ined in		fined in
	<xref target="RFC7285" format="default"/>, in that a property typ		<xref target="RFC7285" format="default"/>, in that a property typ
	e is defined on		e is defined for
	one or more entity domains, rather than just on IPv4 and IPv6 Int		one or more entity domains, rather than just for IPv4 and IPv6 In
	ernet address domains.		ternet address domains.
	An entry in this registry is an ALTO entity property type defined in		An entry in this registry is an ALTO entity property type defined in
	<xref target="def-property-type" format="default"/>.		<xref target="def-property-type" format="default"/>.
	Thus, a registered ALTO entity property type identifier MUST conf orm to		Thus, a registered ALTO entity property type identifier <bcp14>MU ST</bcp14> conform to
	the syntactical requirements specified in that section.		the syntactical requirements specified in that section.
	</t>		</t>
	<t>As specified in <xref target="def-property-type" format="defau lt"/>,		<t>As specified in <xref target="def-property-type" format="defau lt"/>,
	identifiers prefixed with "priv:" are		identifiers prefixed with "priv:" are
	reserved for Private Use without a need to register with IANA.		reserved for Private Use without a need to register with IANA.
	</t>		</t>
	<t>The first line of <xref target="TablePropertyTypes" format="de fault"/> lists		<t>The first row of <xref target="TablePropertyTypes" format="def ault"/> lists
	information items that must be provided with each registered entity pr operty type.		information items that must be provided with each registered entity pr operty type.
	</t>		</t>
	<table anchor="TablePropertyTypes" align="center">		<table anchor="TablePropertyTypes" align="center">
	<name>ALTO Entity Property Types.</name>		<name>ALTO Entity Property Types</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Identifier</th>		<th align="left">Identifier</th>
	<th align="left">Intended Semantics</th>		<th align="left">Intended Semantics</th>
	<th align="left">Media Type of Defining Resource</th>		<th align="left">Media Type of Defining Resource</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">pid</td>		<td align="left">pid</td>
	<td align="left">See Section 7.1.1 of <xref target="RFC7285" forma t="default"/></td>		<td align="left">See <xref target="RFC7285" section="7.1.1" sectio nFormat="of" format="default"/></td>
	<td align="left">application/alto-networkmap+json</td>		<td align="left">application/alto-networkmap+json</td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	<t>New ALTO entity property types are assigned after		<t>New ALTO entity property types are assigned after
	IETF Review <xref target="RFC8126" format="default"/>		IETF Review <xref target="RFC8126" format="default"/>
	to ensure that proper documentation regarding the new ALTO entity		to ensure that proper documentation regarding the new ALTO entity
	property types and their security considerations has been provide d.		property types and their security considerations has been provide d.
	RFCs defining new entity property types SHOULD indicate how a pro perty		RFCs defining new entity property types <bcp14>SHOULD</bcp14> ind icate how a property
	of a registered type is encoded as a property name.		of a registered type is encoded as a property name.
	Updates and deletions of ALTO entity property types follow the sa me procedure.		Updates and deletions of ALTO entity property types follow the sa me procedure.
	</t>		</t>
	<t>Requests to the IANA to add a new value to the registry MUST include the		<t>Requests to IANA to add a new value to the registry <bcp14>MUST</bcp1 4> include the
	following information:</t>		following information:</t>
	<ul spacing="normal">		<dl spacing="normal">
	<li>Identifier: The identifier for the desired ALTO entity property ty		<dt>Identifier:</dt>
	pe. The		<dd>The identifier for the desired ALTO entity property type. The
	format MUST be as defined in <xref target="def-property-type" format="default"/>		format <bcp14>MUST</bcp14> be as defined in <xref target="def-property-type" for
	of this document.		mat="default"/> of this document.
	</li>		</dd>
	<li>Intended Semantics: ALTO entity properties carry with them semanti
	cs to guide		<dt>Intended Semantics:</dt>
	their usage by ALTO clients. Hence, a document defining a new type SHOULD		<dd>ALTO entity properties carry with them semantics to guide
			their usage by ALTO clients. Hence, a document defining a new type <bcp14>SHOULD
			</bcp14>
	provide guidance to both ALTO service providers and applications utilizing		provide guidance to both ALTO service providers and applications utilizing
	ALTO clients as to how values of the registered ALTO entity property should		ALTO clients as to how values of the registered ALTO entity property should
	be interpreted.</li>		be interpreted.</dd>
	<li>Media type of defining information resource: when the property typ		<dt>Media type of defining information resource:</dt>
	e allows		<dd>when the property type allows
	values to be defined relative to a given information resource, th e latter		values to be defined relative to a given information resource, th e latter
	is referred to as the "defining information resource", see descri ption		is referred to as the "defining information resource"; see the de scription
	in <xref target="def-ir-for-irsp" format="default"/>.		in <xref target="def-ir-for-irsp" format="default"/>.
	For each property type, the potential defining information resour ces have		For each property type, the potential defining information resour ces have
	one common media type. This unique common media type is specific to the		one common media type. This unique common media type is specific to the
	property type and MUST be specified.		property type and <bcp14>MUST</bcp14> be specified.
	</li>		</dd>
	<li>Security Considerations: ALTO entity properties expose information		<dt>Security Considerations:</dt>
	to ALTO		<dd>ALTO entity properties expose information to ALTO
	clients. ALTO service providers should be cognizant of the security		clients. ALTO service providers should be cognizant of the security
	ramifications related to the exposure of an entity property.</li>		ramifications related to the exposure of an entity property.</dd>
	</ul>		</dl>
	<t>In security considerations, the request should also discuss the sensi tivity		<t>In security considerations, the request should also discuss the sensi tivity
	of the information, and why it is required for ALTO-based operations.		of the information and why it is required for ALTO-based operations.
	Regarding this discussion, the request SHOULD follow the recommendations of		Regarding this discussion, the request <bcp14>SHOULD</bcp14> follow the recommen
	Section 14.3. ALTO Endpoint Property Type Registry in <xref target="RFC7285" for		dations of
	mat="default"/>.</t>		the "ALTO Endpoint Property Types" registry in <xref target="RFC7285" section="1
	<t>This document requests registration of the identifier "pid", listed i		4.3" sectionFormat="of" format="default"/>.</t>
	n		<t>IANA has registered the identifier "pid", which is listed in
	<xref target="TablePropertyTypes" format="default"/>. Semantics for this propert y are documented in		<xref target="TablePropertyTypes" format="default"/>. Semantics for this propert y are documented in
	Section 7.1.1 of <xref target="RFC7285" format="default"/>. No security issues r elated to the exposure of a		<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		"pid" identifier are considered, as it is exposed with the Network Map
	Service defined and mandated in <xref target="RFC7285" format="default"/>.</t>		Service defined and mandated in <xref target="RFC7285" format="default"/>.</t>
	</section>		</section>
	</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 docume
	nt,
	to Vijay Gurbani, ALTO WG Chair and Martin Duke, Transport Area Director,
	for their thorough review, discussions, guidance and shepherding, that further h
	elped to
	enrich this document.</t>
	</section>
	</middle>		</middle>
	<back>		<back>
			<displayreference target="I-D.ietf-alto-path-vector" to="PATH-VECTOR"/>
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
			<!-- [ISO3166-1] URL https://www.iso.org/standard/72482.html -->
	<reference anchor="ISO3166-1">		<reference anchor="ISO3166-1">
	<front>		<front>
	<title>ISO 3166-1: Codes for the representation of names of countrie		<title>Codes for the representation of names of countries and their
	s and their subdivisions -- Part 1: Country codes</title>		subdivisions -- Part 1: Country codes</title>
	<author initials="." surname="ISO (International Organization for St		<author>
	andardization)" fullname="ISO (International Organization for Standardization)">		<organization>International Organization for Standardization</orga
	<organization/>		nization>
	</author>
	<date year="2020"/>
	</front>
	</reference>
	<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
	119">
	<front>
	<title>Key words for use in RFCs to Indicate Requirement Levels</tit
	le>
	<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>		</author>
	<date year="1997" month="March"/>		<date month="August" year="2020"/>
	<abstract>
	<t>In many standards track documents several words are used to sig
	nify the requirements in the specification. These words are often capitalized.
	This document defines these words as they should be interpreted in IETF document
	s. This document specifies an Internet Best Current Practices for the Internet
	Community, and requests discussion and suggestions for improvements.</t>
	</abstract>
	</front>		</front>
			<seriesInfo name="ISO" value="3166-1:2020"/>
	</reference>		</reference>
	<reference anchor="RFC4291">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<front>		FC.2119.xml"/>
	<title>IP Version 6 Addressing Architecture</title>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="R. Hinden" initials="R." surname="Hin		FC.4291.xml"/>
	den"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="S. Deering" initials="S." surname="De		FC.3986.xml"/>
	ering"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<date month="February" year="2006"/>		FC.4632.xml"/>
	</front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	</reference>		FC.5952.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.7285.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8126.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8174.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8259.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8446.xml"/>
			<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
			FC.8895.xml"/>
	<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
	986">
	<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 ch
	aracters that identifies an abstract or physical resource. This specification d
	efines the generic URI syntax and a process for resolving URI references that mi
	ght be in relative form, along with guidelines and security considerations for t
	he use of URIs on the Internet. The URI syntax defines a grammar that is a supe
	rset of all valid URIs, allowing an implementation to parse the common component
	s of a URI reference without knowing the scheme-specific requirements of every p
	ossible identifier. This specification does not define a generative grammar for
	URIs; that task is performed by the individual specifications of each URI schem
	e. [STANDARDS-TRACK]</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC4632" target="https://www.rfc-editor.org/info/rfc4
	632">
	<front>
	<title>Classless Inter-domain Routing (CIDR): The Internet Address A
	ssignment 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 spa
	ce and limiting the growth rate of global routing state. This document obsoletes
	the original Classless Inter-domain Routing (CIDR) spec in RFC 1519, with chang
	es made both to clarify the concepts it introduced and, after more than twelve y
	ears, to update the Internet community on the results of deploying the technolog
	y 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/rfc5
	952">
	<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 o
	f an IPv6 address, this flexibility has been causing problems for operators, sys
	tem engineers, and users. This document defines a canonical textual representat
	ion 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 foll
	owed by humans and systems when representing IPv6 addresses as text, but all imp
	lementations 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/rfc7
	285">
	<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="edit
	or">
	<organization/>
	</author>
	<author initials="R." surname="Penno" fullname="R. Penno" role="edit
	or">
	<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 top
	ology information of Internet Service Provider (ISP) networks. For example, vie
	ws 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 wa
	y to distribute it.</t>
	<t>The Application-Layer Traffic Optimization (ALTO) services defi
	ned in this document provide network information (e.g., basic network location s
	tructure and preferences of network paths) with the goal of modifying network re
	source consumption patterns while maintaining or improving application performan
	ce. The basic information of ALTO is based on abstract maps of a network. Thes
	e maps provide a simplified view, yet enough information about a network for app
	lications to effectively utilize them. Additional services are built on top of
	the maps.</t>
	<t>This document describes a protocol implementing the ALTO servic
	es. Although the ALTO services would primarily be provided by ISPs, other entiti
	es, such as content service providers, could also provide ALTO services. Applic
	ations that could use the ALTO services are those that have a choice to which en
	d points to connect. Examples of such applications are peer-to-peer (P2P) and c
	ontent delivery networks.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8126" target="https://www.rfc-editor.org/info/rfc8
	126">
	<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 con
	stants to identify various protocol parameters. To ensure that the values in th
	ese fields do not have conflicting uses and to promote interoperability, their a
	llocations 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 des
	cribing the conditions under which new values should be assigned, as well as whe
	n and how modifications to existing values can be made, is needed. This documen
	t defines a framework for the documentation of these guidelines by specification
	authors, in order to assure that the provided guidance for the IANA Considerati
	ons is clear and addresses the various issues that are likely in the operation o
	f a registry.</t>
	<t>This is the third edition of this document; it obsoletes RFC 52
	26.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
	174">
	<front>
	<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
	tle>
	<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 protoco
	l specifications. This document aims to reduce the ambiguity by clarifying tha
	t 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/rfc8
	259">
	<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 ECMAScri
	pt 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 interoperabi
	lity guidance.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8446" target="https://www.rfc-editor.org/info/rfc8
	446">
	<front>
	<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
	e>
	<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 Secu
	rity (TLS) protocol.
	TLS allows client/server applications to communicate over the Inte
	rnet in a way that
	is designed to prevent eavesdropping, tampering, and message forge
	ry.</t>
	<t>This document updates RFCs 5705 and 6066, and obsoletes RFCs 50
	77, 5246, and 6961.
	This document also specifies new requirements for TLS 1.2 implemen
	tations.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8895" target="https://www.rfc-editor.org/info/rfc8
	895">
	<front>
	<title>Application-Layer Traffic Optimization (ALTO) Incremental Upd
	ates 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 th
	at clients can make
	informed decisions in utilizing network resources. This document p
	resents a mechanism to
	allow an ALTO server to push updates to ALTO clients to achieve tw
	o 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 ch
	anges and
	(2) updates can be immediate, in that the ALTO server can send upd
	ates
	as soon as they are available.</t>
	</abstract>
	</front>
	</reference>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<reference anchor="RFC3849">		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<front>		FC.3849.xml"/>
	<title>IPv6 Address Prefix Reserved for Documentation</title>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="G. Huston" initials="G." surname="Huston"/>		FC.5737.xml"/>
	<author fullname="A. Lord" initials="A." surname="Lord"/>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<author fullname="P. Smith" initials="P." surname="Smith"/>		FC.5511.xml"/>
	<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">		<!-- [auth] commented text <reference anchor="RFC7011" target="https://w ww.rfc-editor.org/info/rfc7011">
	<front>		<front>
	<title>Specification of the IP Flow Information Export (IPFIX) Proto col for the Exchange of Flow Information</title>		<title>Specification of the IP Flow Information Export (IPFIX) Proto col for the Exchange of Flow Information</title>
	<seriesInfo name="DOI" value="10.17487/RFC7011"/>		<seriesInfo name="DOI" value="10.17487/RFC7011"/>
	<seriesInfo name="RFC" value="7011"/>		<seriesInfo name="RFC" value="7011"/>
	<seriesInfo name="STD" value="77"/>		<seriesInfo name="STD" value="77"/>
	<author initials="B." surname="Claise" fullname="B. Claise" role="ed itor">		<author initials="B." surname="Claise" fullname="B. Claise" role="ed itor">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="B." surname="Trammell" fullname="B. Trammell" role ="editor">		<author initials="B." surname="Trammell" fullname="B. Trammell" role ="editor">
	<organization/>		<organization/>
	skipping to change at line 3069 ¶		skipping to change at line 3239 ¶
	<author initials="P." surname="Aitken" fullname="P. Aitken">		<author initials="P." surname="Aitken" fullname="P. Aitken">
	<organization/>		<organization/>
	</author>		</author>
	<date year="2013" month="September"/>		<date year="2013" month="September"/>
	<abstract>		<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 P rocess to a Collecting Process, a common representation of flow data and a stand ard means of communicating them are required. This document describes how the I PFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document o bsoletes RFC 5101.</t>		<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 P rocess to a Collecting Process, a common representation of flow data and a stand ard means of communicating them are required. This document describes how the I PFIX Data and Template Records are carried over a number of transport protocols from an IPFIX Exporting Process to an IPFIX Collecting Process. This document o bsoletes RFC 5101.</t>
	</abstract>		</abstract>
	</front>		</front>
	</reference> -->		</reference> -->
	<reference anchor="RFC7921" target="https://www.rfc-editor.org/info/rfc7		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	921">		FC.7921.xml"/>
	<front>		<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
	<title>An Architecture for the Interface to the Routing System</titl		FC.8896.xml"/>
	e>
	<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, p
	rogrammatic interface for state transfer in and out of the Internet routing syst
	em. It describes the high-level architecture, the building blocks of this high-
	level architecture, and their interfaces, with particular focus on those to be s
	tandardized as part of the Interface to the Routing System (I2RS).</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="RFC8896" target="https://www.rfc-editor.org/info/rfc8		<!-- [auth] commented text
	896">
	<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 Tra
	ffic 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 lik
	e to schedule these transfers during an off-peak hour, for example. This extens
	ion introduces the ALTO Cost Calendar with which an ALTO Server exposes ALTO cos
	t 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 I
	nformation Resources Directory and ALTO Server responses.</t>
	</abstract>
	</front>
	</reference>
	<!-- commented text
	<reference anchor="I-D.gao-alto-fcs" target="http://www.ietf.org/interne t-drafts/draft-gao-alto-fcs-07.txt">		<reference anchor="I-D.gao-alto-fcs" target="http://www.ietf.org/interne t-drafts/draft-gao-alto-fcs-07.txt">
	<front>		<front>
	<title>ALTO Extension: Flow-based Cost Query</title>		<title>ALTO Extension: Flow-based Cost Query</title>
	<seriesInfo name="Internet-Draft" value="draft-gao-alto-fcs-07"/>		<seriesInfo name="Internet-Draft" value="draft-gao-alto-fcs-07"/>
	<author initials="J" surname="Zhang" fullname="J. Zhang">		<author initials="J" surname="Zhang" fullname="J. Zhang">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="K" surname="Gao" fullname="Kai Gao">		<author initials="K" surname="Gao" fullname="Kai Gao">
	<organization/>		<organization/>
	</author>		</author>
	skipping to change at line 3146 ¶		skipping to change at line 3266 ¶
	<author initials="Y" surname="Yang" fullname="Y. Yang">		<author initials="Y" surname="Yang" fullname="Y. Yang">
	<organization/>		<organization/>
	</author>		</author>
	<date month="March" day="16" year="2020"/>		<date month="March" day="16" year="2020"/>
	<abstract>		<abstract>
	<t>ALTO cost maps and endpoint cost services map a source-destinat ion pair into a cost value. However, current filter specifications, which defin e 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 suf ficient to uniquely identify a flow in networks with fine-grained routing, such as the emerging Software Defined Networks; 2) The base ALTO protocol only define s filters enumerating all sources and all destinations, leading to redundant inf ormation in the response; 3) Cannot distinguish transmission types of flows in t he query, which makes the server hard to respond the accurate resource consumpti on. 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 t he concerned source-destination pairs and announce the flow-specific information like data transmission type, and a more expressive address space which allows A LTO clients to make queries beyond the limited IP addresses.</t>		<t>ALTO cost maps and endpoint cost services map a source-destinat ion pair into a cost value. However, current filter specifications, which defin e 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 suf ficient to uniquely identify a flow in networks with fine-grained routing, such as the emerging Software Defined Networks; 2) The base ALTO protocol only define s filters enumerating all sources and all destinations, leading to redundant inf ormation in the response; 3) Cannot distinguish transmission types of flows in t he query, which makes the server hard to respond the accurate resource consumpti on. 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 t he concerned source-destination pairs and announce the flow-specific information like data transmission type, and a more expressive address space which allows A LTO clients to make queries beyond the limited IP addresses.</t>
	</abstract>		</abstract>
	</front>		</front>
	</reference> -->		</reference> -->
	<reference anchor="I-D.ietf-alto-cdni-request-routing-alto" target="http		<!-- [I-D.ietf-alto-cdni-request-routing-alto] in EDIT state as of 04/14/22; com
	://www.ietf.org/internet-drafts/draft-ietf-alto-cdni-request-routing-alto-16.txt		panion document RFC 9241 -->
	">		<reference anchor="RFC9241" target="https://www.rfc-editor.org/info/rfc9
			241">
	<front>		<front>
	<title>Content Delivery Network Interconnection (CDNI) Request Routi ng: CDNI Footprint and Capabilities Advertisement using ALTO</title>		<title>Content Delivery Network Interconnection (CDNI) Request Routi ng: CDNI Footprint and Capabilities Advertisement using ALTO</title>
	<seriesInfo name="Internet-Draft" value="draft-ietf-alto-cdni-reques t-routing-alto-16"/>
	<author initials="J" surname="Seedorf" fullname="Jan Seedorf">		<author initials="J" surname="Seedorf" fullname="Jan Seedorf">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="Y" surname="Yang" fullname="Y. Yang">		<author initials="Y" surname="Yang" fullname="Y. Yang">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="K" surname="Ma" fullname="Kevin Ma">		<author initials="K" surname="Ma" fullname="Kevin Ma">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="J" surname="Peterson" fullname="Jon Peterson">		<author initials="J" surname="Peterson" fullname="Jon Peterson">
	<organization/>		<organization/>
	</author>		</author>
	<author initials="J" surname="Zhang" fullname="Jingxuan Zhang">		<author initials="J" surname="Zhang" fullname="Jingxuan Zhang">
	<organization/>		<organization/>
	</author>		</author>
	<date month="January" day="12" year="2021"/>		<date year="2022" month="May"/>
	<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 part
	icular CDN. One component that is needed to achieve the goal of CDNI described
	in CDNI framework is the CDNI Request Routing Footprint &amp; Capabilities Adver
	tisement interface (FCI). RFC 8008 defines precisely the semantics of FCI and p
	rovides guidelines on the FCI protocol, but the exact protocol is explicitly out
	side the scope of that document. This document defines an FCI protocol using th
	e Application-Layer Traffic Optimization (ALTO) protocol, following the guidelin
	es defined in RFC 8008.</t>
	</abstract>
	</front>
	</reference>
	<reference anchor="I-D.ietf-alto-path-vector" target="http://www.ietf.or
	g/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 Randriam
	asy">
	<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 Tra
	ffic Optimization (ALTO) protocol. It extends the ALTO Cost Map service and ALT
	O Property Map service so that the application can decide which endpoint(s) to c
	onnect based on not only numerical/ordinal cost values but also details of the p
	aths. This is useful for applications whose performance is impacted by specifie
	d components of a network on the end-to-end paths, e.g., they may infer that sev
	eral paths share common links and prevent traffic bottlenecks by avoiding such p
	aths. This extension introduces a new abstraction called Abstract Network Eleme
	nt (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 representatio
	n of the underlying network(s) for informed traffic optimization among endpoints
	.</t>
	</abstract>
	</front>		</front>
			<seriesInfo name="RFC" value="9241"/>
			<seriesInfo name="DOI" value="10.17487/RFC9241"/>
	</reference>		</reference>
			<!-- [I-D.ietf-alto-path-vector] MISSREF as of 2022 Apr 14 -->
			<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D
			.ietf-alto-path-vector.xml"/>
	</references>		</references>
	</references>		</references>
	<section anchor="features-introduced-with-epm-extension" numbered="true" toc ="default">		<section anchor="features-introduced-with-epm-extension" numbered="true" toc ="default">
	<name>Features introduced with the Entity Property Maps extension</name>		<name>Features Introduced with the Entity Property Maps Extension</name>
	<t>The Entity Property Maps extension described in this document introduce s a		<t>The Entity Property Maps extension described in this document introduce s a
	number of features that are summarized in table below. The first column		number of features that are summarized in table below. The first column
	provides the name of the feature. The second column provides the section		provides the name of the feature. The second column provides the section
	number of this document that gives a high level description of the feature.		number of this document that gives a high-level description of the feature.
	The third column provides the section number of this document that gives a		The third column provides the section number of this document that gives a
	normative description relating to the feature, when applicable.</t>		normative description relating to the feature, when applicable.</t>
	<table anchor="TableUPFeatures" align="center">		<table anchor="TableUPFeatures" align="center">
	<name>Features introduced with ALTO Entity Property Maps</name>		<name>Features Introduced with ALTO Entity Property Maps</name>
	<thead>		<thead>
	<tr>		<tr>
	<th align="left">Feature</th>		<th align="left">Feature</th>
	<th align="left">High-level description</th>		<th align="left">High-Level Description</th>
	<th align="left">Related normative description</th>		<th align="left">Related Normative Description</th>
	</tr>		</tr>
	</thead>		</thead>
	<tbody>		<tbody>
	<tr>		<tr>
	<td align="left">Entity</td>		<td align="left">Entity</td>
	<td align="left">		<td align="left">
	<xref target="con-entity" format="default"/></td>		<xref target="con-entity" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="entity-addrs" format="default"/></td>		<xref target="entity-addrs" format="default"/></td>
	</tr>		</tr>
			<!-- [rfced] Appendix A: We note that two acronyms are provided in this
			appendix but are not otherwise used in the document. Would you like to
			define these acronyms earlier and use them throughout the document or
			should we remove them from the appendix?
			Current:
			| Entity domain (ED) | Section 3.2 | |
			...
			| Entity property (EP) | Section 3.3 | Sections 5.2, 5.2.1, |
			| type | | 5.2.2, and 5.2.3 |
			Would you like to provide a link to the Related Normative Description of
			"Entity domain (ED)"?
			-->
	<tr>		<tr>
	<td align="left">Entity domain (ED)</td>		<td align="left">Entity domain (ED)</td>
	<td align="left">		<td align="left">
	<xref target="con-entity-domain" format="default"/></td>		<xref target="con-entity-domain" format="default"/></td>
	<td align="left">&nbsp;</td>		<td align="left"> </td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Entity domain type</td>		<td align="left">Entity domain type</td>
	<td align="left">		<td align="left">
	<xref target="con-entity-domain-type" format="default"/></td>		<xref target="con-entity-domain-type" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="domain-types" format="default"/></td>		<xref target="domain-types" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Entity domain name</td>		<td align="left">Entity domain name</td>
	<td align="left">		<td align="left">
	<xref target="con-entity-domain-name" format="default"/></td>		<xref target="con-entity-domain-name" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="domain-names" format="default"/></td>		<xref target="domain-names" format="default"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Entity property (EP) type</td>		<td align="left">Entity property (EP) type</td>
	<td align="left">		<td align="left">
	<xref target="con-property" format="default"/></td>		<xref target="con-property" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="def-property" format="default"/>, <xref target="def- property-type" format="default"/>, <xref target="entity-property-name" format="d efault"/>, <xref target="format-entity-property-value" format="default"/></td>		Sections <xref target="def-property" format="counter"/>, <xref tar get="def-property-type" format="counter"/>, <xref target="entity-property-name" format="counter"/>, and <xref target="format-entity-property-value" format="coun ter"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Entity property map</td>		<td align="left">Entity property map</td>
	<td align="left">		<td align="left">
	<xref target="con-propmap" format="default"/></td>		<xref target="con-propmap" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="prop-map" format="default"/>, <xref target="filter-p rop-map" format="default"/></td>		Sections <xref target="prop-map" format="counter"/> and <xref targ et="filter-prop-map" format="counter"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Resource-specific ED name</td>		<td align="left">Resource-specific ED name</td>
	<td align="left">		<td align="left">
	<xref target="rsed-name" format="default"/></td>		<xref target="rsed-name" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="domain-names" format="default"/>, <xref target="reso urce-specific-ED" format="default"/></td>		Sections <xref target="domain-names" format="counter"/> and <xref target="resource-specific-ED" format="counter"/></td>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Resource-specific EP value</td>		<td align="left">Resource-specific EP value</td>
	<td align="left">		<td align="left">
	<xref target="rsep" format="default"/></td>		<xref target="rsep" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="format-entity-property-value" format="default"/></td >		<xref target="format-entity-property-value" format="default"/></td >
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Entity Hierarchy and property inheritance</td>		<td align="left">Entity Hierarchy and property inheritance</td>
	<td align="left">		<td align="left">
	<xref target="con-hni" format="default"/></td>		<xref target="con-hni" format="default"/></td>
	<td align="left">		<td align="left">
	<xref target="def-hierarchy-and-inheritance" format="default"/></t d>		<xref target="def-hierarchy-and-inheritance" format="default"/></t d>
	</tr>		</tr>
	<tr>		<tr>
	<td align="left">Defining information resource</td>		<td align="left">Defining information resource</td>
	<td align="left">		<td align="left">
	<xref target="def-ir" format="default"/>, <xref target="def-ir-for -irsp" format="default"/></td>		Sections <xref target="def-ir" format="counter"/> and <xref target ="def-ir-for-irsp" format="counter"/></td>
	<td align="left">		<td align="left">
	<xref target="dom-reg-process" format="default"/>, <xref target="I ANAEntityProp" format="default"/></td>		Sections <xref target="dom-reg-process" format="counter"/> and <xr ef target="IANAEntityProp" format="counter"/></td>
	</tr>		</tr>
	</tbody>		</tbody>
	</table>		</table>
	</section>		</section>
	</back>		<section anchor="ack" numbered="false" toc="default">
	<!-- ##markdown-source:		<name>Acknowledgments</name>
	H4sIAJOmdWAAA+29aXcbR5Yg+j1/RT74nGexGoC5iZLoqZmiJbnMalnSiHQt		<!-- [rfced] Acknowledgments: We notice that Vijay Gurbani is listed twice.
	092nnQCSZJZAJDoTII2y1b/93TXiRmQkQKr8uuZDq7otCMiM5caNuy+j0Sib		Please let us know how this may be updated.
	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=
			Current:
			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 for improving this
			document, to Vijay Gurbani, ALTO WG Chair,...
	-->		-->
			<t>The authors would like to thank <contact fullname="Dawn Chen"/> and <co
			ntact fullname="Shenshen Chen"/> for their contributions to earlier drafts.
			Thank you also to <contact fullname="Qiao Xiang"/>, <contact fullname="Shawn Lin
			"/>, <contact fullname="Xin Wang"/>, and
			<contact fullname="Vijay Gurbani"/> for fruitful discussions. Last, big thanks t
			o <contact fullname="Danny Perez"/> and <contact fullname="Luis Contreras"/> for
			their
			substantial working group review feedback and suggestions for improving this doc
			ument,
			to <contact fullname="Vijay Gurbani"/>, ALTO WG Chair, and <contact fullname="Ma
			rtin Duke"/>, Transport Area Director,
			for their thorough review, discussions, guidance, and shepherding, which further
			helped to
			enrich this document.</t>
			</section>
			<!-- [rfced] Terminology:
			a) The following terms were used inconsistently. We have chosen the latter form.
			Please let us know if any updates are needed:
			'{}' / "{}"
			abstract network element / Abstract Network Element
			Abstracted Network Element / abstracted network elements / Abstract Network E
			lement
			(based on use of term in draft-ietf-alto-path-vector)
			ALTO Endpoint / ALTO endpoint (RFC 7285 uses lowercase)
			ALTO protocol / ALTO Protocol (RFC 7285 capitalizes)
			ALTO Service / ALTO service (lowercase in the text of RFC 7285)
			CDNI advertisement resource / CDNI Advertisement resource
			(capped in draft-ietf-alto-cdni-request-routing-alto)
			Endpoint Property Type / endpoint property type (when not used as IANA regis
			try name or
			in Endpoint Property Service per usage in RFC 7285)
			endpoint property service / Endpoint Property Service (RFC 7285 capitalizes)
			property "P" / property P
			value "v1" / value v1
			b) Please let us know how to make the following terms consistent
			(the number of instances is in parentheses):
			".asn" (1) / ".ASN" (16) property
			"asn" domain type (2) / "ASN" property (10)
			ALTO Entity (31) / ALTO entity (25)
			Defining Information Resource (14) / defining information resource (29)
			(we note that RFC 7285 mostly uses lowercase for "information resource")
			Entity Domain Type (38) / entity domain type (80) - when not used as an IANA
			registry name
			"pid" domain or "pid" domain type (3) / PID domain or PID domain type (9)
			self-defined (6) / "self-defined" (4)
			Terms related to identifiers:
			EntityID (10) / Entity ID (2) / entity ID (8) / entity identifier (34)
			ResourceID (3) / "ResourceID" (1) / resource ID (4) / resource identifier (
			2)
			Terms related to maps:
			Entity Property Map (12) / entity property map (4)
			Filtered Property Map (21) / filtered Property map (1) / filtered property
			map (27)
			Network Map (9) / network map (49) (we note that RFC 7285 uses lowercase)
			Property Map (56) / property map (89)
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed.
			-->
			</back>
	</rfc>		</rfc>
End of changes. 383 change blocks.
	1914 lines changed or deleted		1396 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/

mirror server hosted at Truenetwork, Russian Federation.