rfc9240.original   rfc9240.txt 
ALTO WG W. Roome Internet Engineering Task Force (IETF) W. Roome
Internet-Draft S. Randriamasy Request for Comments: 9240 S. Randriamasy
Intended status: Standards Track Nokia Bell Labs Category: Standards Track Nokia Bell Labs
Expires: 1 September 2022 Y. Yang ISSN: 2070-1721 Y. Yang
Yale University Yale University
J. Zhang J. Zhang
Tongji University Tongji University
K. Gao K. Gao
Sichuan University Sichuan University
28 February 2022 May 2022
An ALTO Extension: Entity Property Maps An ALTO Extension: Entity Property Maps
draft-ietf-alto-unified-props-new-24
Abstract Abstract
This document specifies an extension to the base Application-Layer This document specifies an extension to the base Application-Layer
Traffic Optimization (ALTO) protocol that generalizes the concept of Traffic Optimization (ALTO) Protocol that generalizes the concept of
"endpoint properties", which were so far tied to IP addresses, to "endpoint properties", which have been tied to IP addresses so far,
entities defined by a wide set of objects. Further, these properties to entities defined by a wide set of objects. Further, these
are presented as maps, similar to the network and cost maps in the properties are presented as maps, similar to the network and cost
base ALTO protocol. While supporting the endpoints and related maps in the base ALTO Protocol. While supporting the endpoints and
endpoint property service defined in RFC7285, the ALTO protocol is related Endpoint Property Service defined in RFC 7285, the ALTO
extended in two major directions. First, from endpoints restricted Protocol is extended in two major directions. First, from endpoints
to IP addresses to entities covering a wider and extensible set of restricted to IP addresses to entities covering a wider and
objects; second, from properties on specific endpoints to entire extensible set of objects; second, from properties for specific
entity property maps. These extensions introduce additional features endpoints to entire entity property maps. These extensions introduce
allowing entities and property values to be specific to a given additional features that allow entities and property values to be
information resource. This is made possible by a generic and specific to a given information resource. This is made possible by a
flexible design of entity and property types. generic and flexible design of entity and property types.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 1 September 2022. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9240.
Copyright Notice Copyright Notice
Copyright (c) 2022 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction
1.1. Terminology and notation . . . . . . . . . . . . . . . . 6 1.1. Terminology and Notation
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 6 2. Requirements Language
3. Basic Features of the Entity Property Map Extension . . . . . 7 3. Basic Features of the Entity Property Map Extension
3.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. Entity
3.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Entity Domain
3.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 8 3.2.1. Entity Domain Type
3.2.2. Entity Domain Name . . . . . . . . . . . . . . . . . 8 3.2.2. Entity Domain Name
3.3. Entity Property Type . . . . . . . . . . . . . . . . . . 9 3.3. Entity Property Type
3.4. New Information Resource and Media Type: ALTO Property 3.4. New Information Resource and Media Type: ALTO Property Map
Map . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Advanced Features of the Entity Property Map Extension
4. Advanced Features of the Entity Property Map Extension . . . 10 4.1. Entity Identifier and Entity Domain Name
4.1. Entity Identifier and Entity Domain Name . . . . . . . . 10 4.2. Resource-Specific Entity Domain Name
4.2. Resource-Specific Entity Domain Name . . . . . . . . . . 11 4.3. Resource-Specific Entity Property Value
4.3. Resource-Specific Entity Property Value . . . . . . . . . 12 4.4. Entity Hierarchy and Property Inheritance
4.4. Entity Hierarchy and Property Inheritance . . . . . . . . 13 4.4.1. Entity Hierarchy
4.4.1. Entity Hierarchy . . . . . . . . . . . . . . . . . . 13 4.4.2. Property Inheritance
4.4.2. Property Inheritance . . . . . . . . . . . . . . . . 14 4.4.3. Property Value Unicity
4.4.3. Property Value Unicity . . . . . . . . . . . . . . . 14 4.5. Supported Properties for Entity Domains in Property Map
4.5. Supported Properties on Entity Domains in Property Map Capabilities
Capabilities . . . . . . . . . . . . . . . . . . . . . . 15
4.6. Defining Information Resource for Resource-Specific Entity 4.6. Defining Information Resource for Resource-Specific Entity
Domains . . . . . . . . . . . . . . . . . . . . . . . . . 15 Domains
4.6.1. Defining Information Resource and its Media Type . . 16 4.6.1. Defining Information Resource and Its Media Type
4.6.2. Examples of Defining Information Resources and Their 4.6.2. Examples of Defining Information Resources and Their
Media Type . . . . . . . . . . . . . . . . . . . . . 17 Media Types
4.7. Defining Information Resource for Resource-Specific 4.7. Defining Information Resources for Resource-Specific
Property Values . . . . . . . . . . . . . . . . . . . . . 18 Property Values
5. Protocol Specification: Basic Data Types . . . . . . . . . . 19 5. Protocol Specification: Basic Data Types
5.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 19 5.1. Entity Domain
5.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 19 5.1.1. Entity Domain Type
5.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 20 5.1.2. Entity Domain Name
5.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 22 5.1.3. Entity Identifier
5.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 23 5.1.4. Hierarchy and Inheritance
5.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 23 5.2. Entity Property
5.2.1. Entity Property Type . . . . . . . . . . . . . . . . 23 5.2.1. Entity Property Type
5.2.2. Entity Property Name . . . . . . . . . . . . . . . . 24 5.2.2. Entity Property Name
5.2.3. Format for Entity Property Value . . . . . . . . . . 25 5.2.3. Format for Entity Property Value
6. Entity Domain Types Defined in this Document . . . . . . . . 25 6. Entity Domain Types Defined in This Document
6.1. Internet Address Domain Types . . . . . . . . . . . . . . 25 6.1. Internet Address Domain Types
6.1.1. Entity Domain Type: IPv4 . . . . . . . . . . . . . . 25 6.1.1. Entity Domain Type: IPv4
6.1.2. Entity Domain Type: IPv6 . . . . . . . . . . . . . . 26 6.1.2. Entity Domain Type: IPv6
6.1.3. Hierarchy and Inheritance of Internet Address 6.1.3. Hierarchy and Inheritance of Internet Address Domains
Domains . . . . . . . . . . . . . . . . . . . . . . . 26 6.1.4. Defining Information Resource Media Type for Domain
6.1.4. Defining Information Resource Media Type for domain Types IPv4 and IPv6
types IPv4 and IPv6 . . . . . . . . . . . . . . . . . 28 6.2. Entity Domain Type: PID
6.2. Entity Domain Type: PID . . . . . . . . . . . . . . . . . 28 6.2.1. Entity Domain Type Identifier
6.2.1. Entity Domain Type Identifier . . . . . . . . . . . . 28 6.2.2. Domain-Specific Entity Identifiers
6.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 28 6.2.3. Hierarchy and Inheritance
6.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 28
6.2.4. Defining Information Resource Media Type for Domain 6.2.4. Defining Information Resource Media Type for Domain
Type PID . . . . . . . . . . . . . . . . . . . . . . 28 Type PID
6.2.5. Relationship To Internet Addresses Domains . . . . . 29 6.2.5. Relationship To Internet Addresses Domains
6.3. Internet Address Properties vs. PID Properties . . . . . 29 6.3. Internet Address Properties vs. PID Properties
7. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 29 7. Property Map
7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 30 7.1. Media Type
7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 30 7.2. HTTP Method
7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 30 7.3. Accept Input Parameters
7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 30 7.4. Capabilities
7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.5. Uses
7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 30 7.6. Response
8. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 32 8. Filtered Property Map
8.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 32 8.1. Media Type
8.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 32 8.2. HTTP Method
8.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 32 8.3. Accept Input Parameters
8.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 34 8.4. Capabilities
8.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 34 8.5. Uses
8.6. Filtered Property Map Response . . . . . . . . . . . . . 34 8.6. Filtered Property Map Response
8.7. Entity Property Type Defined in This Document . . . . . . 36 8.7. Entity Property Type Defined in This Document
8.7.1. Entity Property Type: pid . . . . . . . . . . . . . . 36 8.7.1. Entity Property Type: pid
9. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 37 9. Impact on Legacy ALTO Servers and ALTO Clients
9.1. Impact on Endpoint Property Service . . . . . . . . . . . 37 9.1. Impact on Endpoint Property Service
9.2. Impact on Resource-Specific Properties . . . . . . . . . 37 9.2. Impact on Resource-Specific Properties
9.3. Impact on Other Properties . . . . . . . . . . . . . . . 37 9.3. Impact on Other Properties
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. Examples
10.1. Network Map . . . . . . . . . . . . . . . . . . . . . . 38 10.1. Network Map
10.2. Property Definitions . . . . . . . . . . . . . . . . . . 38 10.2. Property Definitions
10.3. Information Resource Directory (IRD) . . . . . . . . . . 39 10.3. Information Resource Directory (IRD)
10.4. Full Property Map Example . . . . . . . . . . . . . . . 42 10.4. Full Property Map Example
10.5. Filtered Property Map Example #1 . . . . . . . . . . . . 43 10.5. Filtered Property Map Example #1
10.6. Filtered Property Map Example #2 . . . . . . . . . . . . 44 10.6. Filtered Property Map Example #2
10.7. Filtered Property Map Example #3 . . . . . . . . . . . . 45 10.7. Filtered Property Map Example #3
10.8. Filtered Property Map Example #4 . . . . . . . . . . . . 47 10.8. Filtered Property Map Example #4
10.9. Filtered Property Map for ANEs Example #5 . . . . . . . 47 10.9. Filtered Property Map for ANEs Example #5
11. Security Considerations . . . . . . . . . . . . . . . . . . . 48 11. Security Considerations
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 50 12. IANA Considerations
12.1. application/alto-propmap+json Media Type . . . . . . . . 51 12.1. application/alto-propmap+json Media Type
12.2. alto-propmapparams+json Media Type . . . . . . . . . . . 52 12.2. alto-propmapparams+json Media Type
12.3. ALTO Entity Domain Type Registry . . . . . . . . . . . . 53 12.3. ALTO Entity Domain Types Registry
12.3.1. Consistency Procedure between ALTO Address Type 12.3.1. Consistency Procedure between ALTO Address Types
Registry and ALTO Entity Domain Type Registry . . . . 54 Registry and ALTO Entity Domain Types Registry
12.3.2. ALTO Entity Domain Type Registration Process . . . . 56 12.3.2. ALTO Entity Domain Type Registration Process
12.4. ALTO Entity Property Type Registry . . . . . . . . . . . 57 12.4. ALTO Entity Property Types Registry
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 58 13. References
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 59 13.1. Normative References
14.1. Normative References . . . . . . . . . . . . . . . . . . 59 13.2. Informative References
14.2. Informative References . . . . . . . . . . . . . . . . . 60 Appendix A. Features Introduced with the Entity Property Maps
Appendix A. Features introduced with the Entity Property Maps Extension
extension . . . . . . . . . . . . . . . . . . . . . . . . 61 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 62 Authors' Addresses
1. Introduction 1. Introduction
The ALTO protocol [RFC7285] introduces the concept of "properties" The ALTO Protocol [RFC7285] introduces the concept of "properties"
attached to "endpoint addresses". It also defines the Endpoint attached to "endpoint addresses". It also defines the Endpoint
Property Service (EPS) to allow ALTO clients to retrieve those Property Service (EPS) to allow ALTO clients to retrieve those
properties. While useful, the EPS, as defined in [RFC7285], has at properties. While useful, the EPS as defined in [RFC7285] has at
least three limitations that are further elaborated hereafter. least three limitations, which are elaborated here.
First, the EPS allows properties to be associated with only endpoints First, the EPS allows properties to be associated only with endpoints
that are identified by individual communication addresses like IPv4 that are identified by individual communication addresses like IPv4
and IPv6 addresses. It is reasonable to think that collections of and IPv6 addresses. It is reasonable to think that collections of
endpoints or Provider-Defined Identifiers (PIDs), may also have endpoints or Provider-Defined Identifiers (PIDs), may also have
properties. Furthermore, recent ALTO use cases show that properties 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
[I-D.ietf-alto-path-vector] are also useful. However, the current [PATH-VECTOR] are also useful. However, the current EPS is
EPS is restricted to individual endpoints and cannot be applied to restricted to individual endpoints and cannot be applied to those
those entities. entities.
Second, the EPS only allows endpoints identified by global Second, the EPS only allows endpoints identified by global
communication addresses. However, an endpoint address may be a local communication addresses. However, an endpoint address may be a local
IP address or an anycast IP address that may not be globally unique. IP address or an anycast IP address that may not be globally unique.
Additionally, an entity such as a PID may have an identifier that is Additionally, an entity such as a PID may have an identifier that is
not globally unique. That is, a same PID may be used in multiple not globally unique. That is, the same PID may be used in multiple
network maps, while in each network map, this PID points to a network maps, while in each network map, this PID points to a
different set of addresses. different set of addresses.
Third, in section 11.4 of [RFC7285], the EPS is only defined as a Third, in Section 11.4 of [RFC7285], the EPS is only defined as a
POST-mode service. ALTO clients must request the properties for an POST-mode service. ALTO clients must request the properties for an
explicit set of endpoint addresses. By contrast, [RFC7285], in explicit set of endpoint addresses. By contrast, Section 11.2.3 of
section 11.2.3, defines a GET-mode cost map resource which returns [RFC7285] defines a GET-mode cost map resource that returns all
all available costs, so an ALTO Client can retrieve a full set of available costs, so an ALTO Client can retrieve a full set of costs
costs once, and then process cost lookups without querying the ALTO once and then process cost lookups without querying the ALTO server.
server. [RFC7285] does not define a similar service for endpoint [RFC7285] does not define a similar service for endpoint properties.
properties. At first, a map of endpoint properties might seem At first, a map of endpoint properties might seem impractical because
impractical, because it could require enumerating the property value it could require enumerating the property value for every possible
for every possible endpoint. In particular, the number of endpoint endpoint. In particular, the number of endpoint addresses involved
addresses involved by an ALTO server can be quite large. To avoid by an ALTO server can be quite large. To avoid enumerating a large
enumerating a large number of endpoint addresses inefficiently, the number of endpoint addresses inefficiently, the ALTO server might
ALTO server might define properties for a sufficiently large subset define properties for a sufficiently large subset of endpoints and
of endpoints and uses an aggregation representation to reference uses an aggregation representation to reference endpoints to allow
endpoints to allow efficient enumeration. This is particularly true efficient enumeration. This is particularly true if blocks of
if blocks of endpoint addresses with a common prefix have the same endpoint addresses with a common prefix have the same value for a
value for a property. Entities in other domains may very well allow property. Entities in other domains may very well allow aggregated
aggregated representation and hence be enumerable as well. representation and hence be enumerable as well.
To address these three limitations, this document specifies an ALTO To address these three limitations, this document specifies an ALTO
protocol extension for defining and retrieving ALTO properties: Protocol extension for defining and retrieving ALTO properties:
* The first limitation is addressed by introducing a generic concept * The first limitation is addressed by introducing a generic concept
called ALTO Entity, which generalizes an endpoint and may called ALTO Entity, which generalizes an endpoint and may
represent a PID, a network element, a cell in a cellular network, represent a PID, a network element, a cell in a cellular network,
an abstracted network element [I-D.ietf-alto-path-vector], or an Abstract Network Element [PATH-VECTOR], or other physical or
other physical or logical objects involved in a network topology. logical objects involved in a network topology. Each entity is
Each entity is included in a collection called an ALTO entity included in a collection called an ALTO entity domain. Since each
domain. Since each ALTO entity domain includes only one type of ALTO entity domain includes only one type of entity, each entity
entities, each entity domain can be classified by the type of domain can be classified by the type of enclosed entities.
enclosed entities.
* The second limitation is addressed by using resource-specific * The second limitation is addressed by using resource-specific
entity domains. A resource-specific entity domain contains entity domains. A resource-specific entity domain contains
entities that are defined and identified with respect to a given entities that are defined and identified with respect to a given
ALTO information resource, which provides scoping. For example, ALTO information resource, which provides scoping. For example,
an entity domain containing PIDs is identified with respect to the an entity domain containing PIDs is identified with respect to the
network map in which these PIDs are defined. Likewise, an entity network map in which these PIDs are defined. Likewise, an entity
domain containing local IP addresses may be defined with respect domain containing local IP addresses may be defined with respect
to a local network map. to a local network map.
* The third limitation is addressed by defining two new types of * The third limitation is addressed by defining two new types of
ALTO information resources: Property Map (Section 7) and Filtered ALTO information resources: Property Map (Section 7) and Filtered
Property Map (Section 8). The former is a resource that is Property Map (Section 8). The former is a resource that is
requested using the HTTP GET method, returns the property values requested using the HTTP GET method, returns the property values
for all entities in one or more entity domains, and is analogous for all entities in one or more entity domains, and is analogous
to a network map or a cost map in Section 11.2 of [RFC7285]. The to a network map or a cost map in Section 11.2 of [RFC7285]. The
latter is a resource that that is requested using the HTTP POST latter is a resource that is requested using the HTTP POST method,
method, returns the values for sets of properties and entities returns the values for sets of properties and entities requested
requested by the client, and is analogous to a filtered network by the client, and is analogous to a filtered network map or a
map or a filtered cost map. filtered cost map.
The Entity Property Maps extension described in this document The Entity Property Maps extension described in this document
introduces a number of features that are summarized in Appendix A, introduces a number of features that are summarized in Appendix A,
where Table 4 lists the features and references the sections in this where Table 4 lists the features and references the sections in this
document that give their high-level and their normative description. document that give their high-level and their normative descriptions.
The protocol extension defined in this document is augmentable. New The protocol extension defined in this document can be augmented.
entity domain types can be defined without revising the present New entity domain types can be defined without revising the present
specification. Similarly, new cost metrics and new endpoint specification. Similarly, new cost metrics and new endpoint
properties can be defined in other documents without revising the properties can be defined in other documents without revising the
protocol specification defined in [RFC7285]. protocol specification defined in [RFC7285].
1.1. Terminology and notation 1.1. Terminology and Notation
This document uses the following terms and abbreviations, that will This document uses the following terms and abbreviations that will be
be further defined in the document. While this document introduces further defined in the document. While this document introduces the
the feature "entity property map", it will use both the term feature "entity property map", it will use both the term "property
"property map" and "entity property map" to refer to this feature. map" and "entity property map" to refer to this feature.
* Transaction: A request/response exchange between an ALTO client Transaction: A request/response exchange between an ALTO client and
and an ALTO server. an ALTO server.
* Client: When used with a capital "C", this term refers to an ALTO Client: When used with a capital "C", this term refers to an ALTO
client. Note that expressions "ALTO client", "ALTO Client" and client. Note that expressions "ALTO client", "ALTO Client", and
"Client" are equivalent. "Client" are equivalent.
* Server: When used with a capital "S", this term refers to an ALTO Server: When used with a capital "S", this term refers to an ALTO
server. Note that expressions "ALTO server", "ALTO Server" and server. Note that expressions "ALTO server", "ALTO Server", and
"Server" are equivalent. "Server" are equivalent.
* EPS: An abbreviation for Endpoint Property Service. EPS: An abbreviation for Endpoint Property Service.
This document uses the semi-formal notation defined in Section 8.2 of This document uses the notation defined in Section 8.2 of [RFC7285].
[RFC7285].
2. Requirements Language 2. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. When the words appear in lower case, they capitals, as shown here.
are to be interpreted with their natural language meanings.
3. Basic Features of the Entity Property Map Extension 3. Basic Features of the Entity Property Map Extension
This section gives a high-level overview of the basic features This section gives a high-level overview of the basic features
involved in ALTO Entity Property Maps. It assumes the reader is involved in ALTO Entity Property Maps. It assumes the reader is
familiar with the ALTO protocol [RFC7285]. The purpose of this familiar with the ALTO Protocol [RFC7285]. The purpose of this
extension is to convey properties on objects that extend ALTO extension is to convey properties for objects that extend ALTO
Endpoints and are called ALTO Entities, or entities for short. endpoints and are called ALTO Entities, or entities for short.
The features introduced in this section can be used as standalone. The features introduced in this section can be used standalone.
However, in some cases, these features may depend on particular However, in some cases, these features may depend on particular
information resources and need to be defined with respect to them. information resources and need to be defined with respect to them.
To this end, Section 4 introduces additional features that extend the To this end, Section 4 introduces additional features that extend the
ones presented in the present section. ones presented in this section.
3.1. Entity 3.1. Entity
The concept of an ALTO Entity generalizes the concept of an ALTO The concept of an ALTO Entity generalizes the concept of an ALTO
Endpoint defined in Section 2.1 of [RFC7285]. An entity is an object endpoint defined in Section 2.1 of [RFC7285]. An entity is an object
that can be an endpoint defined by its network address, but can also that can be an endpoint defined by its network address, but it can
be an object that has a defined mapping to a set of one or more also be an object that has a defined mapping to a set of one or more
network addresses or an object that is not even related to any network addresses or an object that is not even related to any
network address. Thus, whereas all endpoints are entities, not all network address. Thus, whereas all endpoints are entities, not all
entities are endpoints. entities are endpoints.
Examples of entities are: Examples of entities are:
* an ALTO endpoint that represents an application or a host * an ALTO endpoint that represents an application or a host
identified by a communication address (e.g., an IPv4 or IPv6 identified by a communication address (e.g., an IPv4 or IPv6
address) in a network, address) in a network,
* a PID, defined in [RFC7285], that has a provider defined human- * a PID, defined in [RFC7285], that has a provider-defined, human-
readable identifier specified by an ALTO network map, which maps a readable identifier specified by an ALTO network map, which maps a
PID to a set of IPv4 and IPv6 addresses, PID to a set of IPv4 and IPv6 addresses,
* an Autonomous System (AS), that has an AS number (ASN) as its * an Autonomous System (AS) that has an AS number (ASN) as its
identifier and maps to a set of IPv4 and IPv6 addresses, that is identifier and maps to a set of IPv4 and IPv6 addresses, which is
defined in [I-D.ietf-alto-cdni-request-routing-alto], defined in [RFC9241],
* a country with a code specified in [ISO3166-1], to which * a country with a code specified in [ISO3166-1] to which
applications such as CDN providers associate properties and applications such as content delivery network (CDN) providers
capabilities, that is defined in associate properties and capabilities, which is defined in
[I-D.ietf-alto-cdni-request-routing-alto], [RFC9241],
* a TCP/UDP network flow, that is identified by a TCP/UDP 5-tuple * a TCP/UDP network flow that is identified by a TCP/UDP 5-tuple
specifying its source and destination addresses and port numbers, specifying its source and destination addresses and port numbers,
and the IP protocol, and the IP protocol,
* a routing element, that is specified in [RFC7921] and is * a routing element, as specified in [RFC7921], that is associated
associated with routing capabilities information, with routing capabilities information, or
* an abstract network element, that is specified in * an Abstract Network Element, as specified in [PATH-VECTOR], that
[I-D.ietf-alto-path-vector] and that represents an abstraction of represents an abstraction of a network part such as a router, one
a network part such as a router, one or more links, a network or more links, a network domain, or their aggregation.
domain or their aggregation.
Some of the example entities listed above have already been Some of the example entities listed above have already been
documented as ALTO entities. The other examples are provided for documented as ALTO entities. The other examples are provided for
illustration as potential entities. illustration as potential entities.
3.2. Entity Domain 3.2. Entity Domain
An entity domain defines a set of entities of the same semantic type. 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. An entity domain is characterized by a type and identified by a name.
skipping to change at page 8, line 34 skipping to change at line 355
entities in two different entity domains refer to the same physical entities in two different entity domains refer to the same physical
or logical object, they are treated as different entities. For or logical object, they are treated as different entities. For
example, if an end host has both an IPv4 and an IPv6 address, these example, if an end host has both an IPv4 and an IPv6 address, these
two addresses will be treated as two entities, defined respectively two addresses will be treated as two entities, defined respectively
in the "ipv4" and "ipv6" entity domains. in the "ipv4" and "ipv6" entity domains.
3.2.1. Entity Domain Type 3.2.1. Entity Domain Type
The type of an entity domain type defines the semantics of a type of The type of an entity domain type defines the semantics of a type of
entity. Entity domain types can be defined in different documents. entity. Entity domain types can be defined in different documents.
For example: the present document defines entity domain types "ipv4", For example: the present document defines entity domain types "ipv4"
"ipv6" and "pid" in Section 6.1 and Section 6.2. The entity domain and "ipv6" in Section 6.1 and "pid" in Section 6.2. The entity
type "ane", that defines Abstract Network Elements (ANEs), is domain type "ane", which defines Abstract Network Elements (ANEs), is
introduced in [I-D.ietf-alto-path-vector]. The entity domain type introduced in [PATH-VECTOR]. The entity domain type that defines
that defines country codes is introduced in country codes is introduced in [RFC9241]. An entity domain type MUST
[I-D.ietf-alto-cdni-request-routing-alto]. An entity domain type be registered with IANA, as specified in Section 12.3.2.
MUST be registered at the IANA, as specified in Section 12.3.2.
3.2.2. Entity Domain Name 3.2.2. Entity Domain Name
In this document, the identifier of an entity domain is mostly called In this document, the identifier of an entity domain is mostly called
"entity domain name". The identifier of an entity domain is defined "entity domain name". The identifier of an entity domain is defined
in the scope of an ALTO server. An entity domain identifier can in the scope of an ALTO server. An entity domain identifier can
sometimes be identical to the identifier of its relevant entity sometimes be identical to the identifier of its relevant entity
domain type. This is the case when the entities of a domain have an domain type. This is the case when the entities of a domain have an
identifier that points to the same object throughout all the identifier that points to the same object throughout all the
information resources of the Server that provide entity properties information resources of the Server that provide entity properties
skipping to change at page 9, line 13 skipping to change at line 382
entities that are identified by a public IPv4 address can be named entities that are identified by a public IPv4 address can be named
"ipv4" because its entities are uniquely identified by all the Server "ipv4" because its entities are uniquely identified by all the Server
resources. resources.
In some cases, the name of an entity domain cannot be simply its In some cases, the name of an entity domain cannot be simply its
entity domain type. Indeed, for some domain types, entities are entity domain type. Indeed, for some domain types, entities are
defined relative to a given information resource. This is the case defined relative to a given information resource. This is the case
for entities of domain type "pid". A PID is defined relative to a for entities of domain type "pid". A PID is defined relative to a
network map. For example, an entity "mypid10" of domain type "pid" network map. For example, an entity "mypid10" of domain type "pid"
may be defined in a given network map and be undefined in other may be defined in a given network map and be undefined in other
network maps. Or "mypid10" may even be defined in two different network maps. The entity "mypid10" may even be defined in two
network maps and map, in each of these network maps, to a different different network maps, and it may map in each of these network maps
set of endpoint addresses. In this case, naming an entity domain to a different set of endpoint addresses. In this case, naming an
only by its type "pid" does not guarantee that its set of entities is entity domain only by its type "pid" does not guarantee that its set
owned by exactly one entity domain. of entities is owned by exactly one entity domain.
Section 4.2 and Section 5.1.2 describe how a domain is uniquely Sections 4.2 and 5.1.2 describe how a domain is uniquely identified
identified, across the ALTO server, by a name that associates the across the ALTO server by a name that associates the domain type and
domain type and the related information resource. the related information resource.
3.3. Entity Property Type 3.3. Entity Property Type
An entity property defines a property of an entity. This is similar An entity property defines a property of an entity. This is similar
to the endpoint property defined in Section 7.1 of [RFC7285]. An to the endpoint property defined in Section 7.1 of [RFC7285]. An
entity property can convey either network-aware or network-agnostic entity property can convey either network-aware or network-agnostic
information. Similar to an entity domain, an entity property is information. Similar to an entity domain, an entity property is
characterized by a type and identified by a name. An entity property characterized by a type and identified by a name. An entity property
type MUST be registered at the IANA, as specified in Section 12.4. type MUST be registered with IANA, as specified in Section 12.4.
Below are listed some examples with real and fictitious entity domain Below are listed some examples with real and fictitious entity domain
and property names: and property names:
* an entity in the "ipv4" domain type may have a property whose * an entity in the "ipv4" domain type may have a property whose
value is an Autonomous System (AS) number indicating the AS to value is an Autonomous System (AS) number indicating the AS to
which this IPv4 address belongs and another property named which this IPv4 address belongs and another property named
"countrycode" indicating a country code mapping to this address, "countrycode" indicating a country code mapping to this address,
* an entity identified by its country code in the entity domain type * an entity identified by its country code in the entity domain type
"countrycode", defined in "countrycode", defined in [RFC9241], may have a property
[I-D.ietf-alto-cdni-request-routing-alto] may have a property indicating what delivery protocol is used by a CDN, or
indicating what delivery protocol is used by a CDN,
* an entity in the "netmap1.pid" domain may have a property that * an entity in the "netmap1.pid" domain may have a property that
indicates the central geographical location of the endpoints it indicates the central geographical location of the endpoints it
includes. includes.
It should be noted that some identifiers may be used for both an It should be noted that some identifiers may be used for both an
entity domain type and a property type. For example: entity domain type and a property type. For example:
* the identifier "countrycode" may point to both the entity domain * the identifier "countrycode" may point to both the entity domain
type "countrycode" and the fictitious property type "countrycode". type "countrycode" and the fictitious property type "countrycode".
* the identifier "pid" may point to both the entity domain type * the identifier "pid" may point to both the entity domain type
"pid" and the property type "pid". "pid" and the property type "pid".
Likewise, the same identifier may point to both a domain name and a Likewise, the same identifier may point to both a domain name and a
property name. For example: the identifier "netmap10.pid" may point property name. For example: the identifier "netmap10.pid" may point
to either the domain defined by the PIDs of network map "netmap10" or to either the domain defined by the PIDs of network map "netmap10" or
to a property that returns, for an entity defined by its IPv4 to a property that returns, for an entity defined by its IPv4
address, the PID of netmap10 that contains this entity. Such cases address, the PID of "netmap10" that contains this entity. Such cases
will be further explained in Section 4. are further explained in Section 4.
3.4. New Information Resource and Media Type: ALTO Property Map 3.4. New Information Resource and Media Type: ALTO Property Map
This document introduces a new ALTO information resource named This document introduces a new ALTO information resource named
Property Map. An ALTO property map provides a set of properties on Property Map. An ALTO property map provides a set of properties for
one or more sets of entities. A property may apply to different one or more sets of entities. A property may apply to different
entity domain types and names. For example, an ALTO property map may entity domain types and names. For example, an ALTO property map may
define the "ASN" property for both "ipv4" and "ipv6" entity domains. define the "ASN" property for both "ipv4" and "ipv6" entity domains.
The present extension also introduces a new media type. The present extension also introduces a new media type.
This document uses the same definition of an information resource as This document uses the same definition of an information resource as
Section 9.1 of [RFC7285]. ALTO uses media types to uniquely indicate Section 9.1 of [RFC7285]. ALTO uses media types to uniquely indicate
the data format used to encode the content to be transmitted between the data format used to encode the content to be transmitted between
an ALTO server and an ALTO client in the HTTP entity body. In the an ALTO server and an ALTO client in the HTTP entity body. In the
present case, an ALTO property map resource is defined by the media present case, an ALTO property map resource is defined by the media
type "application/alto-propmap+json". type "application/alto-propmap+json".
A Property Map can be queried as a GET-mode resource, thus conveying A Property Map can be queried as a GET-mode resource, thus conveying
all properties on all entities indicated in its capabilities. It can all properties for all entities indicated in its capabilities. It
also be queried as a POST-mode resource, thus conveying a selection can also be queried as a POST-mode resource, thus conveying a
of properties on a selection of entities. selection of properties for a selection of entities.
4. Advanced Features of the Entity Property Map Extension 4. Advanced Features of the Entity Property Map Extension
This section gives a high-level overview of the advanced features 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 extend
defined to extend the ones defined in Section 3. the features defined in Section 3.
4.1. Entity Identifier and Entity Domain Name 4.1. Entity Identifier and Entity Domain Name
In [RFC7285], an endpoint has an identifier that is explicitly In [RFC7285], an endpoint has an identifier that is explicitly
associated with the "ipv4" or "ipv6" address domain. Examples are associated with the "ipv4" or "ipv6" address domain. Examples are
"ipv4:192.0.2.14" and "ipv6:2001:db8::12". "ipv4:192.0.2.14" and "ipv6:2001:db8::12".
In this document, example IPv4 and IPv6 addresses and prefixes are In this document, example IPv4 and IPv6 addresses and prefixes are
taken from the address ranges reserved for documentation by [RFC5737] taken from the address ranges reserved for documentation by [RFC5737]
and [RFC3849]. and [RFC3849].
In this document, an entity must be owned by exactly one entity 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.
The encoding format of an entity identifier is further specified in The encoding format of an entity identifier is further specified in
Section 5.1.3 of this document. Section 5.1.3 of this document.
For instance: For instance:
* if an entity is an endpoint with IPv4 address "192.0.2.14", its * if an entity is an endpoint with IPv4 address "192.0.2.14", its
identifier is associated with entity domain name "ipv4" and is identifier is associated with entity domain name "ipv4" and is
"ipv4:192.0.2.14", "ipv4:192.0.2.14";
* if an entity is a PID named "mypid10" in network map resource * if an entity is a PID named "mypid10" in network map resource
"netmap2", its identifier is associated with entity domain name "netmap2", its identifier is associated with entity domain name
"netmap2.pid" and is "netmap2.pid:mypid10". "netmap2.pid" and is "netmap2.pid:mypid10".
4.2. Resource-Specific Entity Domain Name 4.2. Resource-Specific Entity Domain Name
Some entities are defined and identified uniquely and globally in the Some entities are defined and identified uniquely and globally in the
context of an ALTO server. This is the case for instance when context of an ALTO server. This is the case, for instance, when
entities are endpoints that are identified by a reachable IPv4 or entities are endpoints that are identified by a reachable IPv4 or
IPv6 address. The entity domain for such entities can be globally IPv6 address. The entity domain for such entities can be globally
defined and named "ipv4" or "ipv6". Those entity domains are called defined and named "ipv4" or "ipv6". Those entity domains are called
resource-agnostic entity domains in this document, as they are not resource-agnostic entity domains in this document, as they are not
associated with any specific ALTO information resources. associated with any specific ALTO information resources.
Some other entities and entity types are only defined relative to a Some other entities and entity types are only defined relative to a
given information resource. This is the case for entities of domain given information resource. This is the case for entities of domain
type "pid", that can only be understood with respect to the network type "pid", which can only be understood with respect to the network
map where they are defined. For example, a PID named "mypid10" may map where they are defined. For example, a PID named "mypid10" may
be defined to represent a set S1 of IP addresses in a network map be defined to represent a set S1 of IP addresses in a network map
resource named "netmap1". Another network map "netmap2" may use the resource named "netmap1". Another network map "netmap2" may use the
same name "mypid10" and define it to represent another set S2 of IP same name "mypid10" and define it to represent another set S2 of IP
addresses. The identifier "pid:mypid10" may thus point to different addresses. The identifier "pid:mypid10" may thus point to different
objects because the information on the originating information objects because the information on the originating information
resource is lost. resource is lost.
To solve this ambiguity, the present extension introduces the concept To solve this ambiguity, the present extension introduces the concept
of resources-specific entity domain. This concept applies to domain of resource-specific entity domain. This concept applies to domain
types where entities are defined relative to a given information types where entities are defined relative to a given information
resource. It can also apply to entity domains that are defined resource. It can also apply to entity domains that are defined
locally, such as local networks of objects identified with a local locally, such as local networks of objects identified with a local
IPv4 address. IPv4 address.
In such cases, an entity domain type is explicitly associated with an In such cases, an entity domain type is explicitly associated with an
identifier of the information resource where these entities are identifier of the information resource where these entities are
defined. Such an information resource is referred to as the defined. Such an information resource is referred to as the
"specific information resource". Using a resource-aware entity "specific information resource". Using a resource-aware entity
domain name, an ALTO property map can unambiguously identify distinct domain name, an ALTO property map can unambiguously identify distinct
entity domains of the same type, on which entity properties may be entity domains of the same type, on which entity properties may be
queried. Examples of resource-specific entity domain names may look queried. Examples of resource-specific entity domain names may look
like: "netmap1.pid" or "netmap2.pid". Thus, a name association such like "netmap1.pid" or "netmap2.pid". Thus, a name association such
as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" allows to as "netmap1.pid:mypid10" and "netmap2.pid:mypid10" distinguishes the
distinguish the two abovementioned PIDs that are both named "mypid10" two abovementioned PIDs that are both named "mypid10" but in two
but in two different resources, "netmap1" and "netmap2". different resources, "netmap1" and "netmap2".
An information resource is defined in the scope of an ALTO Server and 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 so is an entity domain name. The format of a resource-specific
entity domain name is further specified in Section 5.1.2. entity domain name is further specified in Section 5.1.2.
4.3. Resource-Specific Entity Property Value 4.3. Resource-Specific Entity Property Value
Like entity domains, some types of properties are defined relative to Like entity domains, some types of properties are defined relative to
an information resource. That is, an entity may have a property of a an information resource. That is, an entity may have a property of a
given type, whose values are associated to different information given type whose values are associated with different information
resources. resources.
For example, suppose entity "192.0.2.34" defined in the "ipv4" domain 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 has a 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 "192.0.2.34" is attached in a network map. The mapping of network
addresses to PIDs is specific to a network map and probably different addresses to PIDs is specific to a network map and probably different
from one network map resource to another one. Thus, if a property from one network map resource to another one. Thus, if a property
"pid" is defined for entity "192.0.2.34" in two different network "pid" is defined for entity "192.0.2.34" in two different network
maps "netmap1" and "netmap2", the value for this property can be a maps "netmap1" and "netmap2", the value for this property can be a
different value in "netmap1" and "netmap2". different value in "netmap1" and "netmap2".
To support information resource dependent property values, this To support information-resource-dependent property values, this
document uses the same approach as in Section 10.8.1 of [RFC7285] document uses the same approach as in Section 10.8.1
entitled "Resource-Specific Endpoint Properties". When a property ("Resource-Specific Endpoint Properties") of [RFC7285]. When a
value depends on a given information resource, the name of this property value depends on a given information resource, the name of
property MUST be explicitly associated with the information resource this property MUST be explicitly associated with the information
that defines it. resource that defines it.
For example, the property "pid" queried on entity "ipv4:192.0.2.34" For example, the property "pid" queried on entity "ipv4:192.0.2.34"
and defined in both "netmap1" and "netmap2", can be named and defined in both "netmap1" and "netmap2" can be named
"netmap1.pid" and "netmap2.pid". This allows a Client to get a "netmap1.pid" and "netmap2.pid". This allows a Client to get a
property of the same type but defined in different information property of the same type but defined in different information
resources with a single query. Specifications on the property name resources with a single query. Specifications for the property name
format are provided in Section 5.2. format are provided in Section 5.2.
4.4. Entity Hierarchy and Property Inheritance 4.4. Entity Hierarchy and Property Inheritance
For some domain types, there is an underlying structure that allows For some domain types, there is an underlying structure that allows
entities to efficiently be grouped into a set and be defined by the entities to be efficiently grouped into a set and be defined by the
identifier of this set. This is the case for domain types "ipv4" and identifier of this set. This is the case for domain types "ipv4" and
"ipv6", where individual Internet addresses can be grouped in blocks. "ipv6", where individual Internet addresses can be grouped in blocks.
When the same property value applies to a whole set, a Server can When the same property value applies to a whole set, a Server can
define a property for the identifier of this set instead of define a property for the identifier of this set instead of
enumerating all the entities and their properties. This allows a enumerating all the entities and their properties. This allows a
substantial reduction of transmission payload both for the Server and substantial reduction of transmission payload both for the Server and
the Client. For example, all the entities included in the set the Client. For example, all the entities included in the set
defined by the address block "ipv6:2001:db8::1/64" share the same defined by the address block "ipv6:2001:db8::1/64" share the same
properties and values defined for this block. properties and values defined for this block.
Additionally, entity sets sometimes are related by inclusion, Additionally, entity sets sometimes are related by inclusion,
hierarchy or other relations. This allows defining inheritance rules hierarchy, or other relations. This allows defining inheritance
for entity properties that propagate properties among related entity rules for entity properties that propagate properties among related
sets. The Server and the Client can use these inheritance rules for entity sets. The Server and the Client can use these inheritance
further payload savings. Entity hierarchy and property inheritance rules for further payload savings. Entity hierarchy and property
rules are specified in the documents that define the applicable inheritance rules are specified in the documents that define the
domain types. The present document defines these rules for the applicable domain types. The present document defines these rules
"ipv4" and "ipv6" domain types. for the "ipv4" and "ipv6" domain types.
This document introduces, for applicable domain types, "Entity For applicable domain types, this document introduces "Entity
Property Inheritance rules", with the following concepts: Entity Property Inheritance rules" with the following concepts: Entity
Hierarchy, Property Inheritance and Property Value Unicity. A Hierarchy, Property Inheritance, and Property Value Unicity. A
detailed specification of entity hierarchy and property inheritance detailed specification of entity hierarchy and property inheritance
rules is provided in Section 5.1.4. rules is provided in Section 5.1.4.
4.4.1. Entity Hierarchy 4.4.1. Entity Hierarchy
An entity domain may allow using a single identifier to identify a An entity domain may allow the use of a single identifier to identify
set of related individual entities. For example, a CIDR block can be a set of related individual entities. For example, a Classless
used to identify a set of IPv4 or IPv6 entities. A CIDR block is Inter-Domain Routing (CIDR) block can be used to identify a set of
called a hierarchical entity identifier, as it can reflect inclusion IPv4 or IPv6 entities. A CIDR block is called a hierarchical entity
relations among entity sets. That is, in an entity hierarchy, identifier, as it can reflect inclusion relations among entity sets.
"supersets" are defined at upper levels and include "subsets" defined That is, in an entity hierarchy, "supersets" are defined at upper
at lower levels." For example, the CIDR "ipv4:192.0.1.0/24" includes levels and include "subsets" defined at lower levels. For example,
all the individual IPv4 entities identified by the CIDR the CIDR "ipv4:192.0.1.0/24" includes all the individual IPv4
"ipv4:192.0.1.0/26". This document will sometimes use the term entities identified by the CIDR "ipv4:192.0.1.0/26". This document
"hierarchical address" to refer to a hierarchical entity identifier. will sometimes use the term "hierarchical address" to refer to a
hierarchical entity identifier.
4.4.2. Property Inheritance 4.4.2. Property Inheritance
A property may be defined for a hierarchical entity identifier, while A property may be defined for a hierarchical entity identifier, while
it may be undefined for individual entities covered by this it may be undefined for individual entities covered by this
identifier. In this case, these individual entities inherit the identifier. In this case, these individual entities inherit the
property value defined for the identifier that covers them. For property value defined for the identifier that covers them. For
example, suppose a property map defines a property P for which it example, suppose a property map defines a property P for which it
assigns value V1 only for the hierarchical entity identifier assigns value V1 only for the hierarchical entity identifier
"ipv4:192.0.1.0/24" but not for individual entities in this block. "ipv4:192.0.1.0/24" but not for individual entities in this block.
skipping to change at page 14, line 29 skipping to change at line 631
Property value inheritance rules also apply among entity sets. A Property value inheritance rules also apply among entity sets. A
property map may define values for an entity set belonging to a property map may define values for an entity set belonging to a
hierarchy but not for "subsets" that are covered by this set hierarchy but not for "subsets" that are covered by this set
identifier. In this case, inheritance rules must specify how identifier. In this case, inheritance rules must specify how
entities in "subsets" inherit property values from their "superset". entities in "subsets" inherit property values from their "superset".
For instance, suppose a property P is defined only for the entity set For instance, suppose a property P is defined only for the entity set
defined by address block "ipv4:192.0.1.0/24". We know that entity defined by address block "ipv4:192.0.1.0/24". We know that entity
set "ipv4:192.0.1.0/30" is included in "ipv4:192.0.1.0/24". set "ipv4:192.0.1.0/30" is included in "ipv4:192.0.1.0/24".
Therefore, the entities of "ipv4:192.0.1.0/30" may inherit the value 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", if an inheritance rule of property P from set "ipv4:192.0.1.0/24" if an inheritance rule
from "ipv4" CIDR blocks to included "ipv4" CIDR blocks, is specified. from "ipv4" CIDR blocks to included "ipv4" CIDR blocks is specified.
4.4.3. Property Value Unicity 4.4.3. Property Value Unicity
The inheritance rules must ensure that an entity belonging to a The inheritance rules must ensure that an entity belonging to a
hierarchical set of entities inherits no more than one property hierarchical set of entities inherits no more than one property
value, for the sake of consistency. Indeed, a property map may value, for the sake of consistency. Indeed, a property map may
define a property on a hierarchy of entity sets that inherit property define a property for a hierarchy of entity sets that inherits
values from one or more supersets (located at upper levels). On the property values from one or more supersets (located at upper levels).
other hand, a property value, defined on a subset (located at a lower On the other hand, a property value defined for a subset (located at
level) may be different from the value defined on a superset. In a lower level) may be different from the value defined for a
such a case, subsets may potentially end up with different property superset. In such a case, subsets may potentially end up with
values. This may be the case for address blocs with increasing different property values. This may be the case for address blocks
prefix length, on which a property value gets increasingly accurate with increasing prefix length, on which a property value becomes
and thus may differ. For example, a fictitious property such as increasingly accurate and thus may differ. For example, a fictitious
"geo-location" or "average transfer volume" may be defined at a property such as "geo-location" or "average transfer volume" may be
progressively finer grain for lower level subsets of entities, defined at a progressively finer grain for lower-level subsets of
defined with progressively longer CIDR prefixes. It seems more entities defined with progressively longer CIDR prefixes. It seems
interesting to have property values of progressively higher accuracy. more interesting to have property values of progressively higher
A unicity rule, applied to the entity domain type must specify an accuracy. A unicity rule applied to the entity domain type must
arbitration rule among the different property values for an entity. specify an arbitration rule among the different property values for
An example illustrating the need for such rules is provided in an entity. An example illustrating the need for such rules is
Section 6.1.3. provided in Section 6.1.3.
4.5. Supported Properties on Entity Domains in Property Map 4.5. Supported Properties for Entity Domains in Property Map
Capabilities Capabilities
A property type is not necessarily applicable to any domain type, or 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 an ALTO Server may choose not to provide a property for all
domains. For instance, a property type reflecting link bandwidth is applicable domains. For instance, a property type reflecting link
likely not defined on entities of a domain of type "countrycode". bandwidth is likely not defined for entities of a domain of type
Therefore, an ALTO server providing Property Maps needs to specify "countrycode". Therefore, an ALTO server providing Property Maps
the properties that can be queried on the different entity domains it needs to specify the properties that can be queried on the different
supports. entity domains it supports.
This document explains how the Information Resources Directory (IRD) This document explains how the Information Resource Directory (IRD)
capabilities of a Property Map resource unambiguously expose what capabilities of a Property Map resource unambiguously expose which
properties a Client can query on a given entity domain: properties a Client can query on a given entity domain:
* a field named "mappings" lists the names of the entity domains * a field named "mappings" lists the names of the entity domains
supported by the Property Map, supported by the Property Map, and
* for each listed entity domain, a list of the names of the * for each listed entity domain, a list of the names of the
applicable properties is provided. applicable properties is provided.
An example is provided in Section 10.3. The "mappings" field An example is provided in Section 10.3. The "mappings" field
associates entity domains and properties that can be resource- associates entity domains and properties that can be resource-
agnostic or resource-specific. This allows a Client to formulate agnostic or resource-specific. This allows a Client to formulate
compact and unambiguous entity property queries, possibly relating to compact and unambiguous entity property queries, possibly relating to
one or more information resources. In particular: one or more information resources. In particular:
* it prevents a Client from querying a property on entity domains on * it prevents a Client from querying a property for entity domains
which it is not defined, for which it is not defined;
* it allows a Client to query, for an entity E, values for a * it allows a Client to query, for an entity E, values for a
property P that are defined in several information resources, property P that are defined in several information resources; and
* it allows a Client to query a property P on entities that are * it allows a Client to query a property P on entities that are
defined in several information resources. defined in several information resources.
Further details are provided in Section 7.4. Further details are provided in Section 7.4.
4.6. Defining Information Resource for Resource-Specific Entity Domains 4.6. Defining Information Resource for Resource-Specific Entity Domains
A Client willing to query properties on entities belonging to a A Client willing to query entity properties belonging to a domain
domain needs to know how to retrieve these entities. To this end, needs to know how to retrieve these entities. To this end, the
the Client can look up the "mappings" field exposed in IRD Client can look up the "mappings" field exposed in IRD capabilities
capabilities of a property map, see Section 4.5. This field, in its of a property map; see Section 4.5. This field, in its keys, exposes
keys, exposes all the entity domains supported by the property map. all the entity domains supported by the property map. The syntax of
The syntax of the entity domain identifier specified in Section 5.1.2 the entity domain identifier specified in Section 5.1.2 allows the
allows the client to infer whether the entity domain is resource- client to infer whether the entity domain is resource-specific or
specific or not. The Client can extract, if applicable, the not. The Client can extract, if applicable, the identifier of the
identifier of the specific resource, query the resource and retrieve specific resource, query the resource, and retrieve the entities.
the entities. For example: For example:
* an entity domain named "netmap1.ipv4" includes the IPv4 addresses * an entity domain named "netmap1.ipv4" includes the IPv4 addresses
that appear in the "ipv4" field of the endpoint address group of that appear in the "ipv4" field of the endpoint address group of
each PID in the network map "netmap1", and that have no meaning each PID in the network map "netmap1" and that have no meaning
outside "netmap1" because, for instance, these are local addresses outside "netmap1" because, for instance, these are local addresses
not reachable outside some private network, not reachable outside some private network;
* an entity domain named "netmap1.pid" includes the PIDs listed in * an entity domain named "netmap1.pid" includes the PIDs listed in
network map "netmap1". network map "netmap1"; and
* an entity domain named "ipv4" is resource-agnostic and covers all * an entity domain named "ipv4" is resource-agnostic and covers all
the reachable IPv4 addresses. the reachable IPv4 addresses.
Besides, it is not possible to prevent a Server from mistakenly Besides, it is not possible to prevent a Server from mistakenly
exposing inappropriate associations of information resources and exposing inappropriate associations of information resources and
entity domain types. To prevent failures due to invalid queries, it entity domain types. To prevent failures due to invalid queries, it
is necessary to inform the Client about which associations are is necessary to inform the Client which associations are allowed. An
allowed. An informed Client will just ignore inappropriate informed Client will just ignore inappropriate associations exposed
associations exposed by a Server and avoid error-prone transactions by a Server and avoid error-prone transactions with the Server.
with the Server.
For example, the association "costmap3.pid" is not allowed for the For example, the association "costmap3.pid" is not allowed for the
following reason: although a cost map exposes PID identifiers, it following reason: although a cost map exposes PID identifiers, it
does not define the set of addresses included in this PID. Neither does not define the set of addresses included in this PID. Neither
does a cost map list all the PIDs on which properties can be queried, does a cost map list all the PIDs on which properties can be queried
because a cost map only exposes PID pairs on which a queried cost because a cost map only exposes PID pairs on which a queried cost
type is defined. Therefore, the resource "costmap3" does not enable type is defined. Therefore, the resource "costmap3" does not enable
a Client to extract information on the existing PID entities or on a Client to extract information on the existing PID entities or on
the addresses they contain. the addresses they contain.
Instead, the cost map uses a network map, where all the PIDs used in Instead, the cost map uses a network map where all the PIDs used in a
a cost map are defined together with the addresses contained by the cost map are defined together with the addresses contained by the
PIDs. This network map is qualified in this document as the Defining PIDs. This network map is qualified in this document as the Defining
Information Resource for the entity domain of type "pid" and this Information Resource for the entity domain of type "pid", and this
concept is explained in Section 4.6.1. concept is explained in Section 4.6.1.
4.6.1. Defining Information Resource and its Media Type 4.6.1. Defining Information Resource and Its Media Type
For the reasons explained in Section 4.6, this document introduces For the reasons explained in Section 4.6, this document introduces
the concept of "Defining Information Resource and its Media Type". the concept of "Defining Information Resource and its Media Type".
A defining information resource for an entity domain D is the A defining information resource for an entity domain D is the
information resource where entities of D are defined. That is, all information resource where entities of D are defined. That is, all
the information on the entities of D can be retrieved in this the information on the entities of D can be retrieved in this
resource. A defining information resource is defined for resource- resource. A defining information resource is defined for resource-
specific entity domains. It does not exist for entity domains that specific entity domains. It does not exist for entity domains that
are not resource-specific such as "ipv4" or "ipv6". Neither does it are not resource-specific such as "ipv4" or "ipv6". Neither does it
exist for entity domains that are covering entity identifiers already exist for entity domains that are covering entity identifiers already
defined in other standardization documents, at it is the case for defined in other standardization documents, as is the case for
country code identifiers standardized in [ISO3166-1] or AS numbers country code identifiers standardized in [ISO3166-1] or AS numbers
allocated by the IANA. This is useful for entity domain types that allocated by IANA. This is useful for entity domain types that are
are by essence domain-specific, such as the "pid" domain type. It is by essence domain-specific, such as the "pid" domain type. It is
also useful for resource-specific entity domains constructed from also useful for resource-specific entity domains constructed from
resource-agnostic domain types, such as network map specific domains resource-agnostic domain types, such as network-map-specific domains
of local IPv4 addresses. of local IPv4 addresses.
The defining information resource of a resource-specific entity The defining information resource of a resource-specific entity
domain D, when it exists, is unique and has the following domain D, when it exists, is unique and has the following
specificities: characteristics:
* it has an entry in the IRD, * it has an entry in the IRD;
* it defines the entities of D, * it defines the entities of D;
* it does not use another information resource that defines these * it does not use another information resource that defines these
entities, entities;
* it defines and exposes entity identifiers that are all persistent, * it defines and exposes entity identifiers that are all persistent;
and
* its media type is equal to the one that is specified for the * its media type is equal to the one that is specified for the
defining information resource of an entity domain type. defining information resource of an entity domain type.
A fundamental characteristic of a defining information resource is A fundamental characteristic of a defining information resource is
its media type. There is a unique association between an entity its media type. There is a unique association between an entity
domain type and the media type of its defining information resource. domain type and the media type of its defining information resource.
When an entity domain type allows associations with defining When an entity domain type allows associations with defining
information resources, the media type of the potential defining information resources, the media type of the potential defining
information resource MUST be specified: information resource MUST be specified:
* in the document that defines this entity domain type, * in the document that defines this entity domain type, and
* in the IANA ALTO Entity Domain Type Registry and related * in the "ALTO Entity Domain Types" IANA registry and related
information. information.
When the Client wants to use a resource-specific entity domain, it When the Client wants to use a resource-specific entity domain, it
needs to be cognizant of the media-type of its defining information needs to be cognizant of the media type of its defining information
resource. If the Server exposes a resource-specific entity domain resource. If the Server exposes a resource-specific entity domain
with a non-compliant media type for the defining resource, the Client with a noncompliant media type for the defining resource, the Client
MUST ignore the entities from that entity domain to avoid errors. MUST ignore the entities from that entity domain to avoid errors.
4.6.2. Examples of Defining Information Resources and Their Media Type 4.6.2. Examples of Defining Information Resources and Their Media Types
Here are examples of defining information resource types and their Here are examples of defining information resource types and their
media types associated to different entity domain types: media types associated with different entity domain types:
* For entity domain type "pid": the media type of the specific * For entity domain type "pid", the media type of the specific
resource is "application/alto-networkmap+json", because PIDs are resource is "application/alto-networkmap+json" because PIDs are
defined in network map resources. defined in network map resources.
* For entity domain types "ipv4" and "ipv6": the media type of the * For entity domain types "ipv4" and "ipv6", the media type of the
specific resource is "application/alto-networkmap+json", because specific resource is "application/alto-networkmap+json" because
IPv4 and IPv6 addresses covered by the Server are defined in IPv4 and IPv6 addresses covered by the Server are defined in
network map resources. network map resources.
* For entities of domain type "ane": [I-D.ietf-alto-path-vector] * For entities of domain type "ane"; [PATH-VECTOR] defines entities
defines entities named "ANE", where ANE stands for Abstracted named "ANE", where ANE stands for Abstract Network Element, and
Network Element, and the entity domain type "ane". An ANE may the entity domain type "ane". An ANE may have a persistent
have a persistent identifier, say, "entity-4", that is provided by identifier, say, "entity-4", that is provided by the Server as a
the Server as a value of the "persistent-entity-id" property of value of the "persistent-entity-id" property of this ANE. Further
this ANE. Further properties may then be queried on an ANE by properties may then be queried on an ANE by using its persistent
using its persistent entity ID. These properties are available entity ID. These properties are available from a persistent
from a persistent property map, that defines properties on a property map that defines properties for a specific "ane" domain.
specific "ane" domain. Together with the persistent identifier, Together with the persistent identifier, the Server also provides
the Server also provides the property map resource identifier the property map resource identifier where the "ane" domain
where the "ane" domain containing "entity-4" is defined. The containing "entity-4" is defined. The definition of the "ane"
definition of the "ane" entity domain containing "entity-4" is entity domain containing "entity-4" is thus specific to the
thus specific to the property map. Therefore, for entities of property map. Therefore, for entities of domain type "ane" that
domain type "ane" that have a persistent identifier, the media have a persistent identifier, the media type of the defining
type of the defining information resource is "application/alto- information resource is "application/alto-propmap+json".
propmap+json".
* Last, the entity domain types "asn" and "countrycode" defined in * Last, the entity domain types "asn" and "countrycode" defined in
[I-D.ietf-alto-cdni-request-routing-alto] do not have a defining [RFC9241] do not have a defining information resource. Indeed,
information resource. Indeed, the entity identifiers in these two the entity identifiers in these two entity domain types are
entity domain types are already standardized in documents that the already standardized in documents that the Client can use.
Client can use.
4.7. Defining Information Resource for Resource-Specific Property 4.7. Defining Information Resources for Resource-Specific Property
Values Values
As explained in Section 4.3, a property type may take values that are As explained in Section 4.3, a property type may take values that are
resource-specific. This is the case for property type "pid", whose resource-specific. This is the case for property type "pid", whose
values are by essence defined relative to a specific network map. values are by essence defined relative to a specific network map.
That is, the PID value returned for an IPv4 address is specific to That is, the PID value returned for an IPv4 address is specific to
the network map defining this PID and may differ from one network map the network map defining this PID and may differ from one network map
to another one. to another one.
Another example is provided in Another example is provided in [RFC9241], which defines property type
[I-D.ietf-alto-cdni-request-routing-alto] that defines property type
"cdni-capabilities". The value of this property is specific to a "cdni-capabilities". The value of this property is specific to a
CDNI advertisement resource, that provides a list of CDNI Content Delivery Network Interconnection (CDNI) Advertisement
capabilities. The property is provided for entity domain types resource, which provides a list of CDNI capabilities. The property
"ipv4", "ipv6", "asn" and "countrycode". A CDNI Advertisement is provided for entity domain types "ipv4", "ipv6", "asn", and
resource does however not define PID values for IPv4 addresses while "countrycode". However, a CDNI Advertisement resource does not
a network map does not define CDNI capabilities for IPv4 addresses. define PID values for IPv4 addresses, while a network map does not
define CDNI capabilities for IPv4 addresses.
Similar to resource-specific entity domains, the Client needs to be Similar to resource-specific entity domains, the Client needs to be
cognizant of appropriate associations of information resource and cognizant of appropriate associations of information resource and
property types. Therefore, when specifying and registering a property types. Therefore, when specifying and registering a
property type whose values are resource-specific, the media type of property type whose values are resource-specific, the media type of
its defining information resource needs to be specified. For its defining information resource needs to be specified. For
example: example:
* The media type of the defining information resource for property * The media type of the defining information resource for property
type "pid" is "application/alto-networkmap+json". type "pid" is "application/alto-networkmap+json".
* The media type of the defining information resource for property * The media type of the defining information resource for property
type "cdni-capabilities" defined in type "cdni-capabilities" defined in [RFC9241] is "application/
[I-D.ietf-alto-cdni-request-routing-alto] is "application/alto- alto-cdni+json".
cdni+json".
5. Protocol Specification: Basic Data Types 5. Protocol Specification: Basic Data Types
5.1. Entity Domain 5.1. Entity Domain
5.1.1. Entity Domain Type 5.1.1. Entity Domain Type
An entity domain has a type, which is uniquely identified by a string 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 that MUST be no more than 64 characters, and MUST NOT contain
characters other than US-ASCII alphanumeric characters characters other than US-ASCII alphanumeric characters
(U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', (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). U+002D), the colon (':', U+003A), or the low line ('_', U+005F).
The usage of colon (':', U+003A) MUST obey the rules below: The usage of colon (':', U+003A) MUST obey the rules below:
* The colon (':', U+003A) character MUST NOT appear more than once, * The colon (':', U+003A) character MUST NOT appear more than once;
* The colon character MUST NOT be used unless within the string * The colon character MUST NOT be used unless within the string
"priv:", "priv:";
* The string "priv:" MUST NOT be used unless it starts the string * The string "priv:" MUST NOT be used unless it starts the string
that identifies an entity domain type, that identifies an entity domain type; and
* For an entity domain type identifier with the "priv:" prefix , an * For an entity domain type identifier with the "priv:" prefix, an
additional string (e.g., company identifier or random string) MUST additional string (e.g., company identifier or random string) MUST
follow "priv:", to reduce potential collisions. follow "priv:" to reduce potential collisions.
For example, the strings "ipv4", "ipv6", "pid" and "priv:example- For example, the strings "ipv4", "ipv6", "pid", and "priv:example-
test-edt", are valid entity domain types. "ipv4.anycast", "pid.local" test-edt", are valid entity domain types. "ipv4.anycast",
and "priv:" are invalid. "pid.local", and "priv:" are invalid.
Although "_", "-", "__--" are valid entity domain types, it is Although "_", "-", "__--" are valid entity domain types, it is
desirable to add characters such as alphanumeric ones, for better desirable to add characters, such as alphanumeric ones, for better
intelligibility. intelligibility.
The type EntityDomainType is used in this document to denote a JSON The type EntityDomainType is used in this document to denote a JSON
string meeting the preceding requirements. string meeting the preceding requirements.
An entity domain type defines the semantics of a type of entity, An entity domain type defines the semantics of a type of entity,
independently of any specifying resource. All entity domain types independently of any specifying resource. All entity domain types
that are not prefixed with "priv:" MUST be registered with the IANA, that are not prefixed with "priv:" MUST be registered with IANA in
in the "ALTO Entity Domain Type Registry", defined in Section 12.3, the "ALTO Entity Domain Types" registry, defined in Section 12.3,
following the procedure specified in Section 12.3.2 of this document. following the procedure specified in Section 12.3.2 of this document.
The format of the entity identifiers (see Section 5.1.3) in that The format of the entity identifiers (see Section 5.1.3) in that
entity domain type, as well as any hierarchical or inheritance rules entity domain type, as well as any hierarchical or inheritance rules
(see Section 5.1.4) for those entities, MUST be specified in the IANA (see Section 5.1.4) for those entities, MUST be specified in the IANA
registration. registration.
Entity domain type identifiers prefixed with "priv:" are reserved for Entity domain type identifiers prefixed with "priv:" are reserved for
Private Use (see [RFC8126]) without a need to register with IANA. Private Use (see [RFC8126]) without a need to register with IANA.
The definition of a private use entity domain type MUST apply the The definition of a private-use entity domain type MUST apply the
same way in all property maps of an IRD where it is present. same way in all property maps of an IRD where it is present.
5.1.2. Entity Domain Name 5.1.2. Entity Domain Name
As discussed in Section 3.2, an entity domain is characterized by a As discussed in Section 3.2, an entity domain is characterized by a
type and identified by a name. type and identified by a name.
This document distinguishes three categories of entity domains: This document distinguishes three categories of entity domains:
resource-specific entity domains, resource-agnostic entity domains resource-specific entity domains, resource-agnostic entity domains,
and self-defined entity domains. Their entity domain names are and self-defined entity domains. Their entity domain names are
constructed as specified in the following sub-sections. constructed as specified in the following subsections.
Each entity domain is identified by a unique entity domain name. 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
[RFC5511], the format of an entity domain name is defined as follows: [RFC5511], the format of an entity domain name is defined as follows:
EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType
The presence and construction of the component The presence and construction of the component
"[ [ ResourceID ] '.' ]" "[ [ ResourceID ] '.' ]"
depends on the category of entity domain. depends on the category of entity domain.
Note that the '.' separator is not allowed in EntityDomainType and Note that the '.' separator is not allowed in EntityDomainType, and
hence there is no ambiguity on whether an entity domain name refers hence there is no ambiguity on whether an entity domain name refers
to a resource-agnostic entity domain or a resource-specific entity to a resource-agnostic entity domain or a resource-specific entity
domain. domain.
Note also that Section 10.1 of [RFC7285] specifies the format of the Note also that Section 10.1 of [RFC7285] specifies the format of the
PID name which is the format of the resource ID including the PID name, which is the format of the resource ID including the
following specification: "the '.' separator is reserved for future following specification:
use and MUST NOT be used unless specifically indicated in this
document, or an extension document". The present extension keeps the
format specification of [RFC7285], hence the '.' separator MUST NOT
be used in an information resource ID.
5.1.2.1. Resource-specific Entity Domain | The '.' separator is reserved for future use and MUST NOT be used
| unless specifically indicated in this document, or an extension
| document.
The present extension keeps the format specification of [RFC7285],
hence the '.' separator MUST NOT be used in an information resource
ID.
5.1.2.1. Resource-Specific Entity Domain
A resource-specific entity domain is identified by an entity domain A resource-specific entity domain is identified by an entity domain
name constructed as follows. It MUST start with a resource ID using name constructed as follows. It MUST start with a resource ID using
the ResourceID type defined in Section 10.2 of [RFC7285], followed by the ResourceID type defined in Section 10.2 of [RFC7285], followed by
the '.' separator (U+002E), followed by a string of the type the '.' separator (U+002E), followed by a string of the type
EntityDomainType specified in Section 5.1.1. EntityDomainType specified in Section 5.1.1.
For example, if an ALTO server provides two network maps "netmap-1" For example, if an ALTO server provides two network maps "netmap-1"
and "netmap-2", these network maps can define two resource-specific and "netmap-2", these network maps can define two resource-specific
domains of type "pid", respectively identified by "netmap-1.pid" and domains of type "pid", respectively identified by "netmap-1.pid" and
"netmap-2.pid". "netmap-2.pid".
5.1.2.2. Resource-agnostic Entity Domain 5.1.2.2. Resource-Agnostic Entity Domain
A resource-agnostic entity domain contains entities that are A resource-agnostic entity domain contains entities that are
identified independently of any information resource. The identifier identified independently of any information resource. The identifier
of a resource-agnostic entity domain is simply the identifier of its of a resource-agnostic entity domain is simply the identifier of its
entity domain type. For example, "ipv4" and "ipv6" identify the two entity domain type. For example, "ipv4" and "ipv6" identify the two
resource-agnostic Internet address entity domains defined in resource-agnostic Internet address entity domains defined in
Section 6.1. Section 6.1.
5.1.2.3. Self-defined Entity Domain 5.1.2.3. Self-Defined Entity Domain
A property map can define properties on entities that are specific to A property map can define properties for entities that are specific
a unique information resource, which is the property map itself. to a unique information resource, which is the property map itself.
This may be the case when an ALTO Server provides properties on a set This may be the case when an ALTO Server provides properties for a
of entities that are defined only in this property map, are not set of entities that are defined only in this property map, are not
relevant to another one and do not depend on another specific relevant to another one, and do not depend on another specific
resource. resource.
For example: a specialised property map may define a domain of type For example: a specialized property map may define a domain of type
"ane", defined in [I-D.ietf-alto-path-vector], that contains a set of "ane", defined in [PATH-VECTOR], that contains a set of ANEs
ANEs representing data centers, that each have a persistent representing data centers that each have a persistent identifier and
identifier and are relevant only to this property map. are relevant only to this property map.
In this case, the entity domain is qualified as "self-defined". The In this case, the entity domain is qualified as "self-defined". The
identifier of a self-defined entity domain can be of the format: identifier of a self-defined entity domain can be of the format:
EntityDomainName ::= '.' EntityDomainType EntityDomainName ::= '.' EntityDomainType
where '.' indicates that the entity domain only exists within the where '.' indicates that the entity domain only exists within the
property map resource using it. property map resource using it.
A self-defined entity domain can be viewed as a particular case of A self-defined entity domain can be viewed as a particular case of
skipping to change at page 22, line 37 skipping to change at line 1018
(EntityID) of the following format: (EntityID) of the following format:
EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID
Examples from the Internet address entity domains include individual Examples from the Internet address entity domains include individual
IP addresses such as "net1.ipv4:192.0.2.14" and IP addresses such as "net1.ipv4:192.0.2.14" and
"net1.ipv6:2001:db8::12", as well as address blocks such as "net1.ipv6:2001:db8::12", as well as address blocks such as
"net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::/48". "net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::/48".
The format of the second part of an entity identifier, The format of the second part of an entity identifier,
DomainTypeSpecificEntityID, depends on the entity domain type, and DomainTypeSpecificEntityID, depends on the entity domain type and
MUST be specified when defining a new entity domain type and MUST be specified when defining a new entity domain type and
registering it with the IANA. Identifiers MAY be hierarchical, and registering it with IANA. Identifiers MAY be hierarchical, and
properties MAY be inherited based on that hierarchy. The rules properties MAY be inherited based on that hierarchy. The rules
defining any hierarchy or inheritance MUST be defined when the entity defining any hierarchy or inheritance MUST be defined when the entity
domain type is registered. domain type is registered.
The type EntityID is used in this document to denote a JSON string The type EntityID is used in this document to denote a JSON string
representing an entity identifier in this format. representing an entity identifier in this format.
Note that two entity identifiers with different valid textual Note that two entity identifiers with different, valid textual
representations may refer to the same entity, for a given entity representations may refer to the same entity, for a given entity
domain. For example, the strings "net1.ipv6:2001:db8::1" and domain. For example, the strings "net1.ipv6:2001:db8::1" and
"net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the "net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the
"ipv6" entity domain. Such equivalences should be established by the "ipv6" entity domain. Such equivalences should be established by the
object represented by DomainTypeSpecificEntityID, for example, object represented by DomainTypeSpecificEntityID. For example,
[RFC5952] establishes equivalence for IPv6 addresses, while [RFC4632] [RFC5952] establishes equivalence for IPv6 addresses, while [RFC4632]
does so for IPv4 addresses. does so for IPv4 addresses.
5.1.4. Hierarchy and Inheritance 5.1.4. Hierarchy and Inheritance
To simplify the representation, some types of entity domains allow To simplify the representation, some types of entity domains allow
the ALTO Client and Server to use a hierarchical entity identifier the ALTO Client and Server to use a hierarchical entity identifier
format to represent a block of individual entities. For instance, in format to represent a block of individual entities. For instance, in
an IPv4 domain "net1.ipv4", a CIDR "net1.ipv4:192.0.2.0/26" covers 64 an IPv4 domain "net1.ipv4", a CIDR "net1.ipv4:192.0.2.0/26" covers 64
individual IPv4 entities. In this case, the corresponding property individual IPv4 entities. In this case, the corresponding property
skipping to change at page 23, line 42 skipping to change at line 1065
The type EntityPropertyType is used in this document to indicate a The type EntityPropertyType is used in this document to indicate a
string denoting an entity property type. The string MUST be no more string denoting an entity property type. The string MUST be no more
than 32 characters, and it MUST NOT contain characters other than US- than 32 characters, and it MUST NOT contain characters other than US-
ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 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 U+0061-U+007A), the hyphen ('-', U+002D), the colon (':', U+003A), or
the low line ('_', U+005F). Note that the '.' separator is not the low line ('_', U+005F). Note that the '.' separator is not
allowed because it is reserved to separate an entity property type allowed because it is reserved to separate an entity property type
and an information resource identifier when an entity property is and an information resource identifier when an entity property is
resource-specific. resource-specific.
While, in Section 5.1.1, character ":" is allowed with restrictions While Section 5.1.1 allows the use of the character ":" with
on entity domain identifiers, it can be used without restrictions on restrictions on entity domain identifiers, it can be used without
entity property type identifiers. This relates to [RFC7285], where a restrictions on entity property type identifiers. This relates to
Server can define properties on endpoints "ipv4" and "ipv6". In the [RFC7285], where a Server can define properties for endpoints "ipv4"
present extension, there is a mapping of ALTO entity domain types and "ipv6". In the present extension, there is a mapping of ALTO
"ipv4" and "ipv6", to ALTO address types "ipv4" and "ipv6". entity domain types "ipv4" and "ipv6" to ALTO address types "ipv4"
Properties defined on "ipv4" and "ipv6" endpoints should be re-usable and "ipv6". Properties defined for "ipv4" and "ipv6" endpoints
on "ipv4" and "ipv6" entities. Forbidding the usage of ":" in a non- should be reusable on "ipv4" and "ipv6" entities. Forbidding the
private entity property type identifier would not allow to use usage of ":" in a non-private entity property type identifier would
properties previously defined on "ipv4" and "ipv6" endpoints because not allow the use of properties previously defined for "ipv4" and
their identifiers would be invalid. "ipv6" endpoints because their identifiers would be invalid.
Although ":" or "_::-" are valid entity domain types, it is desirable Although ":" or "_::-" are valid entity domain types, it is desirable
to add characters such as alphanumeric ones, for better to add characters, such as alphanumeric ones, for better
intelligibility. intelligibility.
Identifiers prefixed with "priv:" are reserved for Private Use Identifiers prefixed with "priv:" are reserved for Private Use
[RFC8126] without a need to register with IANA. All other [RFC8126] without a need to register with IANA. All other
identifiers for entity property types MUST be registered in the "ALTO identifiers for entity property types MUST be registered in the "ALTO
Entity Property Type Registry", defined in Section 12.4. The Entity Property Types" registry, which is defined in Section 12.4.
intended semantics of the entity property type MUST be specified in The intended semantics of the entity property type MUST be specified
the IANA registration. in the IANA registration.
For an entity property identifier with the "priv:" prefix, an For an entity property identifier with the "priv:" prefix, an
additional string (e.g., company identifier or random string) MUST additional string (e.g., company identifier or random string) MUST
follow the prefix to reduce potential collisions, that is, the string follow the prefix to reduce potential collisions, that is, the string
"priv:" alone is not a valid entity property identifier. The "priv:" alone is not a valid entity property identifier. The
definition of a private use entity property type must apply the same definition of a private-use entity property type must apply the same
way in all property maps of an IRD where it is present. way in all property maps of an IRD where it is present.
To distinguish from the endpoint property type, the entity property To distinguish from the endpoint property type, the entity property
type has the following characteristics: type has the following characteristics:
* Some entity property types are applicable to entities in * Some entity property types are applicable only to entities in
particular entity domain types only. For example, the property particular entity domain types. For example, the property type
type "pid" is applicable to entities in the entity domain types "pid" is applicable to entities in the entity domain types "ipv4"
"ipv4" or "ipv6" while is not applicable to entities in an entity or "ipv6", while it is not applicable to entities in an entity
domain of type "pid". domain of type "pid".
* The intended semantics of the value of an entity property may also * The intended semantics of the value of an entity property may also
depend on the entity domain type. For example, suppose that a depend on the entity domain type. For example, suppose that a
property named "geo-location" is defined as the coordinates of a property named "geo-location" is defined as the coordinates of a
point, encoded as: "latitude longitude [altitude]." When applied point and is encoded as: "latitude longitude [altitude]." When
to an entity that represents a specific host computer, identified applied to an entity that represents a specific host computer and
by an address in an entity domain of type "ipv4" or "ipv6", the identified by an address in an entity domain of type "ipv4" or
"geo-location" property would define the host's location. "ipv6", the "geo-location" property would define the host's
However, when applied to an entity in a "pid" domain type, the location. However, when applied to an entity in a "pid" domain
property would indicate a location representative of all hosts in type, the property would indicate a location representative of all
this "pid" entity. hosts in this "pid" entity.
5.2.2. Entity Property Name 5.2.2. Entity Property Name
Each entity property is identified by an entity property name, which Each entity property is identified by an entity property name, which
is a string of the following format: is a string of the following format:
EntityPropertyName ::= [ [ ResourceID ] '.' ] EntityPropertyType EntityPropertyName ::= [ [ ResourceID ] '.' ] EntityPropertyType
Similar to the endpoint property type defined in Section 10.8 of Similar to the endpoint property type defined in Section 10.8 of
[RFC7285], each entity property may be defined by either the property [RFC7285], each entity property may be defined by either the property
map itself (self-defined) or some other specific information resource map itself (self-defined) or some other specific information resource
(resource-specific). (resource-specific).
The entity property name of a resource-specific entity property The entity property name of a resource-specific entity property
starts with a string of the type ResourceID defined in [RFC7285], starts with a string of the type ResourceID defined in [RFC7285],
followed by the '.' separator (U+002E) and a EntityDomainType typed followed by the '.' separator (U+002E) and an EntityDomainType typed
string. For example, the "pid" properties of an "ipv4" entity string. For example, the "pid" properties of an "ipv4" entity
defined by two different maps "net-map-1" and "net-map-2" are defined by two different maps "net-map-1" and "net-map-2" are
identified by "net-map-1.pid" and "net-map-2.pid" respectively. identified by "net-map-1.pid" and "net-map-2.pid" respectively.
The specific information resource of an entity property may be the The specific information resource of an entity property may be the
current information resource itself, that is, the property map current information resource itself, that is, the property map
defining the property. In that case, the ResourceID in the property defining the property. In that case, the ResourceID in the property
name SHOULD be omitted. For example, the property name ".asn" name SHOULD be omitted. For example, the property name ".asn"
applied to an entity identified by its IPv4 address, indicates the AS applied to an entity identified by its IPv4 address indicates the AS
number of the AS that "owns" the entity, where the returned AS number number of the AS that "owns" the entity, where the returned AS number
is defined by the property map itself. is defined by the property map itself.
5.2.3. Format for Entity Property Value 5.2.3. Format for Entity Property Value
Section 11.4.1.6 of [RFC7285] specifies that an implementation of the Section 11.4.1.6 of [RFC7285] specifies that an implementation of the
Endpoint Property Service specified in [RFC7285] SHOULD assume that Endpoint Property Service specified in [RFC7285] SHOULD assume that
the property value is a JSONString and fail to parse if it is not. the property value is a JSONString and fail to parse if it is not.
This document extends the format of a property value by allowing it This document extends the format of a property value by allowing it
to be a JSONValue instead of just a JSONString. to be a JSONValue instead of just a JSONString.
6. Entity Domain Types Defined in this Document 6. Entity Domain Types Defined in This Document
The definition of each entity domain type MUST include (1) the entity The definition of each entity domain type MUST include (1) the entity
domain type name and (2) domain-specific entity identifiers, and MAY domain type name and (2) domain-specific entity identifiers, and MAY
include (3) hierarchy and inheritance semantics optionally. This include (3) hierarchy and inheritance semantics optionally. This
document defines three initial entity domain types as follows. document defines three initial entity domain types as follows.
6.1. Internet Address Domain Types 6.1. Internet Address Domain Types
The document defines two entity domain types (IPv4 and IPv6) for The document defines two entity domain types (IPv4 and IPv6) for
Internet addresses. Both types are resource-agnostic entity domain Internet addresses. Both types are resource-agnostic entity domain
skipping to change at page 26, line 4 skipping to change at line 1167
6.1. Internet Address Domain Types 6.1. Internet Address Domain Types
The document defines two entity domain types (IPv4 and IPv6) for The document defines two entity domain types (IPv4 and IPv6) for
Internet addresses. Both types are resource-agnostic entity domain Internet addresses. Both types are resource-agnostic entity domain
types and hence define corresponding resource-agnostic entity domains types and hence define corresponding resource-agnostic entity domains
as well. Since the two domains use the same hierarchy and as well. Since the two domains use the same hierarchy and
inheritance semantics, we define the semantics together, instead of inheritance semantics, we define the semantics together, instead of
repeating for each. repeating for each.
6.1.1. Entity Domain Type: IPv4 6.1.1. Entity Domain Type: IPv4
6.1.1.1. Entity Domain Type Identifier 6.1.1.1. Entity Domain Type Identifier
The identifier for this Entity Domain Type is "ipv4". The identifier for this Entity Domain Type is "ipv4".
6.1.1.2. Domain-Specific Entity Identifiers 6.1.1.2. Domain-Specific Entity Identifiers
Individual addresses are strings as specified by the IPv4address rule Individual addresses are strings as specified by the IPv4address rule
in Section 3.2.2 of [RFC3986]; Hierarchical addresses are strings as in Section 3.2.2 of [RFC3986]; hierarchical addresses are strings as
specified by the prefix notation in Section 3.1 of [RFC4632]. To specified by the prefix notation in Section 3.1 of [RFC4632]. To
define properties, an individual Internet address and the define properties, an individual Internet address and the
corresponding full-length prefix are considered aliases for the same corresponding full-length prefix are considered aliases for the same
entity on which to define properties. Thus, "ipv4:192.0.2.0" and entity on which to define properties. Thus, "ipv4:192.0.2.0" and
"ipv4:192.0.2.0/32" are equivalent. "ipv4:192.0.2.0/32" are equivalent.
6.1.2. Entity Domain Type: IPv6 6.1.2. Entity Domain Type: IPv6
6.1.2.1. Entity Domain Type Identifier 6.1.2.1. Entity Domain Type Identifier
The identifier for this Entity Domain Type is "ipv6". The identifier for this Entity Domain Type is "ipv6".
6.1.2.2. Domain-Specific Entity Identifiers 6.1.2.2. Domain-Specific Entity Identifiers
Individual addresses are strings as specified by Section 4 of Individual addresses are strings as specified by Section 4 of
[RFC5952]; Hierarchical addresses are strings as specified by IPv6 [RFC5952]; hierarchical addresses are strings as specified by IPv6
address prefixes notation in Section 2.3 of [RFC4291]. To define address prefixes notation in Section 2.3 of [RFC4291]. To define
properties, an individual Internet address and the corresponding properties, an individual Internet address and the corresponding
128-bit prefix are considered aliases for the same entity. That is, 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 "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent and have
have the same set of properties. the same set of properties.
6.1.3. Hierarchy and Inheritance of Internet Address Domains 6.1.3. Hierarchy and Inheritance of Internet Address Domains
Both Internet address domains allow property values to be inherited. Both Internet address domains allow property values to be inherited.
Specifically, if a property P is not defined for a specific Internet Specifically, if a property P is not defined for a specific Internet
address I, but P is defined for a hierarchical Internet address C address I, but P is defined for a hierarchical Internet address C
which represents a set of addresses containing I, then the address I that represents a set of addresses containing I, then the address I
inherits the value of P defined for the hierarchical address C. If inherits the value of P defined for the hierarchical address C. If
more than one such hierarchical addresses define a value for P, I more than one such hierarchical addresses define a value for P, I
inherits the value of P in the hierarchical address with the longest inherits the value of P in the hierarchical address with the longest
prefix. Note that this longest prefix rule ensures no multiple value prefix. Note that this longest prefix rule ensures no multiple value
inheritances, and hence no ambiguity. inheritances, and hence no ambiguity.
Hierarchical addresses can also inherit properties: if a property P Hierarchical addresses can also inherit properties: if a property P
is not defined for the hierarchical address C, but is defined for a is not defined for the hierarchical address C, but is defined for a
set of hierarchical addresses, where each address C' in the set set of hierarchical addresses, where each address C' in the set
contains all IP addresses in C, and C' has a shorter prefix length contains all IP addresses in C, and C' has a shorter prefix length
skipping to change at page 27, line 13 skipping to change at line 1225
longest prefix length. longest prefix length.
As an example, suppose that a server defines a property P for the As an example, suppose that a server defines a property P for the
following entities: following entities:
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
Figure 1: Defined Property Values. Figure 1: Defined Property Values
Then the following entities have the indicated values: Then the following entities have the indicated values:
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)
Figure 2: Inherited Property Values. Figure 2: Inherited Property Values
An ALTO server MAY explicitly indicate a property as not having a An ALTO server MAY explicitly indicate a property as not having a
value for a particular entity. That is, a server MAY say that value for a particular entity. That is, a server MAY say that
property P of entity X is "defined to have no value", instead of property P of entity X is "defined to have no value" instead of
"undefined". To indicate "no value", a server MAY perform different "undefined". To indicate "no value", a server MAY perform different
behaviors: behaviors:
* If entity X would inherit a value for property P, and if the ALTO * If entity X would inherit a value for property P, and if the ALTO
server decides to say that "X has no value for P", then the ALTO server decides to say that "X has no value for P", then the ALTO
server MUST return a "null" value for that property on X. In this server MUST return a "null" value for that property on X. In this
case, the ALTO client MUST recognize the JSON "null" value as "no case, the ALTO client MUST recognize the JSON "null" value as "no
value" and interpret it as "do not apply the inheritance rules for value" and interpret it as "do not apply the inheritance rules for
this property on X". this property on X".
* If the entity would not inherit a value, then the ALTO server MAY * If the entity would not inherit a value, then the ALTO server MAY
return "null" or just omit the property. In this case, the ALTO return "null" or just omit the property. In this case, the ALTO
client cannot infer the value for this property of this entity client cannot infer the value for this property of this entity
from the Inheritance rules. So, the client MUST interpret that from the Inheritance rules. Thus, the client MUST interpret that
this property has no value. this property has no value.
If the ALTO server does not define any properties for an entity, then If the ALTO server does not define any properties for an entity, then
the server MAY omit that entity from the response. the server MAY omit that entity from the response.
6.1.4. Defining Information Resource Media Type for domain types IPv4 6.1.4. Defining Information Resource Media Type for Domain Types IPv4
and IPv6 and IPv6
Entity domain types "ipv4" and "ipv6" both allow to define resource Entity domain types "ipv4" and "ipv6" both allow the definition of
specific entity domains. When resource specific domains are defined resource-specific entity domains. When resource-specific domains are
with entities of domain type "ipv4" or "ipv6", the defining defined with entities of domain type "ipv4" or "ipv6", the defining
information resource for an entity domain of type "ipv4" or "ipv6" information resource for an entity domain of type "ipv4" or "ipv6"
MUST be a Network Map. The media type of a defining information MUST be a Network Map. The media type of a defining information
resource is therefore: resource is therefore:
application/alto-networkmap+json application/alto-networkmap+json
6.2. Entity Domain Type: PID 6.2. Entity Domain Type: PID
The PID entity domain associates property values with the PIDs in a The PID entity domain associates property values with the PIDs in a
network map. Accordingly, this entity domain always depends on a network map. Accordingly, this entity domain always depends on a
network map. network map.
6.2.1. Entity Domain Type Identifier 6.2.1. Entity Domain Type Identifier
The identifier for this Entity Domain Type is "pid" The identifier for this Entity Domain Type is "pid".
6.2.2. Domain-Specific Entity Identifiers 6.2.2. Domain-Specific Entity Identifiers
The entity identifiers are the PID names of the associated network The entity identifiers are the PID names of the associated network
map. map.
6.2.3. Hierarchy and Inheritance 6.2.3. Hierarchy and Inheritance
There are no hierarchy or inheritance for properties associated with There is no hierarchy or inheritance for properties associated with
PIDs. PIDs.
6.2.4. Defining Information Resource Media Type for Domain Type PID 6.2.4. Defining Information Resource Media Type for Domain Type PID
The entity domain type "pid" allows to define resource specific The entity domain type "pid" allows the definition of resource-
entity domains. When resource specific domains are defined with specific entity domains. When resource-specific domains are defined
entities of domain type "pid", the defining information resource for with entities of domain type "pid", the defining information resource
entity domain type "pid" MUST be a Network Map. The media type of a for entity domain type "pid" MUST be a Network Map. The media type of
defining information resource is therefore: a defining information resource is therefore:
application/alto-networkmap+json application/alto-networkmap+json
6.2.5. Relationship To Internet Addresses Domains 6.2.5. Relationship To Internet Addresses Domains
The PID domain and the Internet address domains are completely The PID domain and the Internet address domains are completely
independent; the properties associated with a PID have no relation to independent; the properties associated with a PID have no relation to
the properties associated with the prefixes or endpoint addresses in the properties associated with the prefixes or endpoint addresses in
that PID. An ALTO server MAY choose to assign all the properties of that PID. An ALTO server MAY choose to assign all the properties of
a PID to the prefixes in that PID or only some of these properties. a PID to the prefixes in that PID or only some of these properties.
For example, suppose "PID1" consists of the prefix For example, suppose "PID1" consists of the prefix
"ipv4:192.0.2.0/24", and has the property "P" with value "v1". The "ipv4:192.0.2.0/24" and has the property P with value v1. The
Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24" in Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24" in
the IPv4 domain MAY have a value for the property "P", and if they the IPv4 domain MAY have a value for the property P, and if they do,
do, it is not necessarily "v1". it is not necessarily v1.
6.3. Internet Address Properties vs. PID Properties 6.3. Internet Address Properties vs. PID Properties
Because the Internet address and PID domains relate to completely Because the Internet address and PID domains relate to completely
distinct domain types, the question may arise as to which entity distinct domain types, the question may arise as to which entity
domain type is the best for a property. In general, the Internet domain type is the best for a property. In general, the Internet
address domain types are RECOMMENDED for properties that are closely address domain types are RECOMMENDED for properties that are closely
related to the Internet address, or are associated with, and related to the Internet address or are associated with, and inherited
inherited through, hierarchical addresses. through, hierarchical addresses.
The PID domain type is RECOMMENDED for properties that arise from the The PID domain type is RECOMMENDED for properties that arise from the
definition of the PID, rather than from the Internet address prefixes definition of the PID, rather than from the Internet address prefixes
in that PID. in that PID.
For example, because Internet addresses are allocated to service For example, because Internet addresses are allocated to service
providers by blocks of prefixes, an "ISP" property would be best providers by blocks of prefixes, an "ISP" property would be best
associated with Internet address domain types. On the other hand, a associated with Internet address domain types. On the other hand, a
property that explains why a PID was formed, or how it relates to a property that explains why a PID was formed, or how it relates to a
provider's network, would best be associated with the PID domain provider's network, would best be associated with the PID domain
skipping to change at page 31, line 34 skipping to change at line 1433
strings of type PropertyName. A protocol implementation SHOULD strings of type PropertyName. A protocol implementation SHOULD
assume that the property value is either a JSONString or a JSON assume that the property value is either a JSONString or a JSON
"null" value, and fail to parse if it is not, unless the "null" value, and fail to parse if it is not, unless the
implementation is using an extension to this document that indicates implementation is using an extension to this document that indicates
when and how property values of other data types are signaled. when and how property values of other data types are signaled.
For each entity in the property map: For each entity in the property map:
* If the entity is in a resource-specific entity domain, the ALTO * If the entity is in a resource-specific entity domain, the ALTO
server MUST only return self-defined properties and resource- server MUST only return self-defined properties and resource-
specific properties which depend on the same resource as the specific properties that depend on the same resource as the entity
entity does. The ALTO client MUST ignore any resource-specific does. The ALTO client MUST ignore any resource-specific property
property for this entity if the mapping between this resource- for this entity if the mapping between this resource-specific
specific property and this entity is not indicated, in the IRD, in property and this entity is not indicated, in the IRD, in the
the "mappings" capability of the property map resource. "mappings" capability of the property map resource.
* If the entity identifier is resource-agnostic, the ALTO server * If the entity identifier is resource-agnostic, the ALTO server
SHOULD return the self-defined properties and all the resource- SHOULD return the self-defined properties and all the resource-
specific properties that are defined in the property defining specific properties that are defined in the property defining
information resources indicated, in the IRD, in the "mappings" information resources indicated, in the IRD, in the "mappings"
capability of the property map resource, unless property values capability of the property map resource, unless property values
can be omitted upon some inheritance rules. can be omitted upon some inheritance rules.
The ALTO server MAY omit property values that are inherited rather The ALTO server MAY omit property values that are inherited rather
than explicitly defined, in order to achieve more compact encoding. than explicitly defined in order to achieve more compact encoding.
As a consequence, the ALTO Client MUST NOT assume inherited property As a consequence, the ALTO Client MUST NOT assume inherited property
values will all be present. If the Client needs inherited values, it values will all be present. If the Client needs inherited values, it
MUST use the entity domain's inheritance rules to deduce those MUST use the entity domain's inheritance rules to deduce those
values. values.
8. Filtered Property Map 8. Filtered Property Map
A filtered property map returns the values of a set of properties for A filtered property map returns the values of a set of properties for
a set of entities selected by the client. a set of entities selected by the client.
Section 10.5, Section 10.6, Section 10.7 and Section 10.8 give Sections 10.5, 10.6, 10.7, and 10.8 give examples of filtered
examples of filtered property map requests and responses. property map requests and responses.
While the IRD lists all the names of the supported properties, it While the IRD lists all the names of the supported properties, it
only lists the names of the supported entity domains and not the only lists the names of the supported entity domains and not the
entity IDs. A client, sometimes, may only want to know what entity entity IDs. Sometimes a client may only want to know what entity IDs
IDs it can provide as input to a filtered property map request but it can provide as input to a filtered property map request but wants
wants to avoid the burden of downloading the full property map. Or to avoid the burden of downloading the full property map. Or it may
it may want to check whether some given entity IDs are eligible for a want to check whether some given entity IDs are eligible for a query.
query. To support such a case, the filtered property map supports a To support such a case, the filtered property map supports a
light weight response, with empty property values. lightweight response with empty property values.
8.1. Media Type 8.1. Media Type
The media type of a property map resource is "application/alto- The media type of a property map resource is "application/alto-
propmap+json". propmap+json".
8.2. HTTP Method 8.2. HTTP Method
The filtered property map is requested using the HTTP POST method. The filtered property map is requested using the HTTP POST method.
8.3. Accept Input Parameters 8.3. Accept Input Parameters
The input parameters for a filtered property map request are supplied The input parameters for a filtered property map request are supplied
in the entity body of the POST request. This document specifies the in the entity body of the POST request. This document specifies the
input parameters with a data format indicated by the media type input parameters 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 ReqFilteredPropertyMap. ReqFilteredPropertyMap is designed to
support the following cases of client requests: support the following cases of client requests:
* The client wants the value of a selected set of properties on a * The client wants the value of a selected set of properties for a
selected set of entities, selected set of entities;
* The client wants all properties values on all the entities, * The client wants all property values on all the entities;
* The client wants all entities on which a property is defined but
is not interested in their property values,
* The Client wants to cross-check whether some entity IDs are * The client wants all entities for which a property is defined but
is not interested in their property values; or
* The client wants to cross-check whether some entity IDs are
present in the Filtered Property Map but is not interested in present in the Filtered Property Map but is not interested in
their property values. their property values.
The third case is equivalent to querying the whole unfiltered The third case is equivalent to querying the whole unfiltered
property map, which can also be achieved with a GET request. Some property map, which can also be achieved with a GET request. Some
Clients however, may prefer to systematically make filtered property Clients, however, may prefer to systematically make filtered property
map queries, where filtering parameters may sometimes be empty. map queries, where filtering parameters may sometimes be empty.
The JSON object ReqFilteredPropertyMap is specified as follows: The JSON object ReqFilteredPropertyMap is specified as follows:
object { object {
EntityID entities<0..*>; EntityID entities<0..*>;
[EntityPropertyName properties<0..*>;] [EntityPropertyName properties<0..*>;]
} ReqFilteredPropertyMap; } ReqFilteredPropertyMap;
with fields: with fields:
entities: List of entity identifiers for which the specified entities: A list of entity identifiers for which the specified
properties are to be returned. If the list is empty, the ALTO properties are to be returned. If the list is empty, the ALTO
Server MUST interpret the list as if it contained a list of all Server MUST interpret the list as if it contained a list of all
entities currently defined in the filtered property map. The entities currently defined in the filtered property map. The
domain of each entity MUST be included in the list of entity domain of each entity MUST be included in the list of entity
domains in this resource's "capabilities" field (see Section 8.4). domains in this resource's "capabilities" field (see Section 8.4).
The ALTO server MUST interpret entries appearing multiple times as The ALTO server MUST interpret entries appearing multiple times as
if they appeared only once. if they appeared only once.
properties: List of properties to be returned for each entity. If properties: A list of properties to be returned for each entity. If
the list is empty, the ALTO Sever MUST interpret the list as if it the list is empty, the ALTO Sever MUST interpret the list as if it
contained a list of all properties currently defined in the contained a list of all properties currently defined in the
filtered property map. Each specified property MUST be included filtered property map. Each specified property MUST be included
in the list of properties in this resource's "capabilities" field in the list of properties in this resource's "capabilities" field
(see Section 8.4). The ALTO server MUST interpret entries (see Section 8.4). The ALTO server MUST interpret entries
appearing multiple times as if they appeared only once. This appearing multiple times as if they appeared only once. This
field is optional. If it is absent, the Server returns a property field is optional. If it is absent, the Server returns a property
value equal to the literal string "{}" for all the entity IDs of value equal to the literal string "{}" for all the entity IDs of
the "entities" field on which at least one property is defined. the "entities" field for which at least one property is defined.
Note that the field "properties" is optional. When in addition, the Note that the field "properties" is optional. In addition, when the
"entities" field is an empty list, it corresponds to a query for all "entities" field is an empty list, it corresponds to a query for all
applicable entity IDs of the filtered property map, with no current applicable entity IDs of the filtered property map, with no current
interest on any particular property. When the "entities" field is interest on any particular property. When the "entities" field is
not empty, it allows the Client to check whether the listed entity not empty, it allows the Client to check whether the listed entity
IDs can be used as input to a filtered property map query. IDs can be used as input to a filtered property map query.
8.4. Capabilities 8.4. Capabilities
The capabilities are defined by an object of type The capabilities are defined by an object of type
PropertyMapCapabilities, as defined in Section 7.4. PropertyMapCapabilities, as defined in Section 7.4.
8.5. Uses 8.5. Uses
Same to the "uses" field of the Property Map resource (see This is the same as the "uses" field of the Property Map resource
Section 7.5). (see Section 7.5).
8.6. Filtered Property Map Response 8.6. Filtered Property Map Response
The response MUST indicate an error, using ALTO protocol error The response MUST indicate an error, using ALTO Protocol error
handling, as defined in Section 8.5 of [RFC7285], if the request is handling, as defined in Section 8.5 of [RFC7285], if the request is
invalid. invalid.
Specifically, a filtered property map request can be invalid in the Specifically, a filtered property map request can be invalid in the
following cases: following cases:
* The input field "entities" is absent from the Client request. In * The input field "entities" is absent from the Client request. In
this case, the Server MUST return an "E_MISSING_FIELD" error as this case, the Server MUST return an "E_MISSING_FIELD" error as
defined in Section 8.5.2 of [RFC7285]. defined in Section 8.5.2 of [RFC7285].
* An entity identifier in the "entities" field of the request is * An entity identifier in the "entities" field of the request is
invalid. This occurs when: invalid. This occurs when:
- The domain of this entity is not defined in the "entity- - The domain of this entity is not defined in the "entity-
domains" capability of this resource in the IRD, domains" capability of this resource in the IRD, or
- The entity identifier is not valid for the entity domain. - The entity identifier is not valid for the entity domain.
A valid entity identifier does never generate an error, even if A valid entity identifier never generates an error, even if the
the filtered property map resource does not define any properties filtered property map resource does not define any properties for
for it. it.
If an entity identifier in the "entities" field of the request is If an entity identifier in the "entities" field of the request is
invalid, the ALTO server MUST return an "E_INVALID_FIELD_VALUE" invalid, the ALTO server MUST return an "E_INVALID_FIELD_VALUE"
error defined in Section 8.5.2 of [RFC7285], and the "value" field error defined in Section 8.5.2 of [RFC7285], and the "value" field
of the error message SHOULD indicate the provided invalid entity of the error message SHOULD indicate the provided invalid entity
identifier. identifier.
* A property name in the "properties" field of the request is * A property name in the "properties" field of the request is
invalid. This occurs when this property name is not defined in invalid. This occurs when this property name is not defined in
the "properties" capability of this resource in the IRD. the "properties" capability of this resource in the IRD.
When a filtered property map resource does not define a value for When a filtered property map resource does not define a value for
a property requested on a particular entity, it is not an error. a property requested for a particular entity, it is not an error.
In this case, the ALTO server MUST omit that property from the In this case, the ALTO server MUST omit that property from the
response for that endpoint. response for that endpoint.
If a property name in "properties" in the request is invalid, the If a property name in the "properties" field in the request is
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined invalid, the ALTO server MUST return an "E_INVALID_FIELD_VALUE"
in Section 8.5.2 of [RFC7285]. The "value" field of the error error defined in Section 8.5.2 of [RFC7285]. The "value" field of
message SHOULD indicate the property name. the error message SHOULD indicate the property name.
Some identifiers can be interpreted as both an entity name and a 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 property name, as is the case for "pid" if it were erroneously used
used alone. In such a case, the Server SHOULD follow Section 8.5.2 alone. In such a case, the Server SHOULD follow Section 8.5.2 of
of [RFC7285], that says: "For an E_INVALID_FIELD_VALUE error, the [RFC7285], which says:
server may include an optional field named "field" in the "meta"
field of the response, to indicate the field that contains the wrong | For an E_INVALID_FIELD_VALUE error, the server may include an
value." | optional field named "field" in the "meta" field of the response,
| to indicate the field that contains the wrong value.
The response to a valid request is the same as for the Property Map The response to a valid request is the same as for the Property Map
(see Section 7.6), except that: (see Section 7.6) except that:
* If the requested entities include entities with a resource- * If the requested entities include entities with a resource-
agnostic identifier, the "dependent-vtags" field in its "meta" agnostic identifier, the "dependent-vtags" field in its "meta"
field MUST include version tags of all dependent resources field MUST include version tags of all dependent resources
appearing in the "uses" field. appearing in the "uses" field.
* If the requested entities only include entities in resource- * If the requested entities only include entities in resource-
specific entity domains, the "dependent-vtags" field in its "meta" specific entity domains, the "dependent-vtags" field in its "meta"
field MUST include the version tags of the resources on which the field MUST include the version tags of the resources on which the
requested resource-specific entity domains and the requested requested resource-specific entity domains and the requested
resource-specific properties are dependent on. resource-specific properties are dependent.
* The response only includes the entities and properties requested * The response only includes the entities and properties requested
by the client. If an entity in the request is identified by a by the client. If an entity in the request is identified by a
hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the hierarchical identifier (e.g., a "ipv4" or "ipv6" prefix), the
response MUST return all properties that are present on any response MUST return all properties that are present for any
address covered by the prefix, even though some of those address covered by the prefix, even though some of those
properties may not be present on all addresses covered by the properties may not be present for all addresses covered by the
prefix. prefix.
* When the input member "properties" is absent from the client * When the input member "properties" is absent from the client
request, the Server returns a property map containing all the request, the Server returns a property map containing all the
requested entity identifiers on which one or more properties are requested entity identifiers for which one or more properties are
defined. For all the entities of the returned map, the returned defined. For all the entities of the returned map, the returned
property value is equal to '{}'. property value is equal to "{}".
The filtered property map response MUST include all the inherited The filtered property map response MUST include all the inherited
property values for the requested entities and all the entities which property values for the requested entities and all the entities that
are able to inherit property values from the requested entities. To are able to inherit property values from the requested entities. To
achieve this goal, the ALTO server MAY follow two rules: achieve this goal, the ALTO server MAY follow two rules:
* If a property for a requested entity is inherited from another * If a property for a requested entity is inherited from another
entity not included in the request, the response MUST include this entity not included in the request, the response MUST include this
property for the requested entity. For example, A full property property for the requested entity. For example, a full property
map may skip a property P for an entity A (e.g., map may skip a property P for an entity A (e.g.,
ipv4:192.0.2.0/31) if P can be derived using inheritance from "ipv4:192.0.2.0/31") if P can be derived using inheritance from
another entity B (e.g., ipv4:192.0.2.0/30). A filtered property another entity B (e.g., "ipv4:192.0.2.0/30"). A filtered property
map request may include only A but not B. In such a case, the map request may include only A but not B. In such a case, the
property P MUST be included in the response for A. property P MUST be included in the response for A.
* If there are entities covered by a requested entity but having * If there are entities covered by a requested entity but they have
different values for the requested properties, the response MUST different values for the requested properties, the response MUST
include all those entities and the different property values for include all those entities and the different property values for
them. For example, considering a request for property P of entity them. For example, consider a request for property P of entity A
A (e.g., ipv4:192.0.2.0/31), if P has value v1 for (e.g., "ipv4:192.0.2.0/31"): if P has value v1 for
A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the "A1=ipv4:192.0.2.0/32" and v2 for "A2=ipv4:192.0.2.1/32", then the
response SHOULD include A1 and A2. response SHOULD include A1 and A2.
For the sake of response compactness, the ALTO server SHOULD obey the For the sake of response compactness, the ALTO server SHOULD obey the
following rule: following rule:
* If an entity identifier in the response is already covered by * If an entity identifier in the response is already covered by
other entities identifiers in the same response, it SHOULD be other entities identifiers in the same response, it SHOULD be
removed from the response. In the previous example, the entity A removed from the response. In the previous example, the entity
= ipv4:192.0.2.0/31 SHOULD be removed because A1 and A2 cover all "A=ipv4:192.0.2.0/31" SHOULD be removed because A1 and A2 cover
the addresses in A. all the addresses in A.
An ALTO client should be aware that the entities in the response may An ALTO client should be aware that the entities in the response may
be different from the entities in its request. be different from the entities in its request.
8.7. Entity Property Type Defined in This Document 8.7. Entity Property Type Defined in This Document
This document defines the entity property type "pid". This property This document defines the entity property type "pid". This property
type extends the ALTO Endpoint Property Type "pid" defined in section type extends the ALTO endpoint property type "pid" defined in
7.1.1 of [RFC7285] as follows: the property has the same semantics Section 7.1.1 of [RFC7285] as follows: the property has the same
and applies to IPv4 and IPv6 addresses; the difference is that the semantics and applies to IPv4 and IPv6 addresses; the difference is
IPv4 and IPv6 addresses have evolved from the status of endpoints to that the IPv4 and IPv6 addresses have evolved from the status of
the status of entities. endpoints to the status of entities.
The defining information resource for property type MUST be a network The defining information resource for property type MUST be a network
map. This document requests a IANA registration for this property map. This document requests an IANA registration for this property.
8.7.1. Entity Property Type: pid 8.7.1. Entity Property Type: pid
1. Identifier: pid
2. Semantics: the intended semantics are the same as in [RFC7285] Identifier: pid
for the ALTO Endpoint Property Type "pid"
3. Media type of defining information resource: application/alto- Semantics: the intended semantics are the same as in [RFC7285] for
networkmap+json the ALTO endpoint property type "pid".
4. Security considerations: for entity property type "pid" are the Media type of defining information resource: application/alto-
same as documented in [RFC7285] for the ALTO Endpoint Property networkmap+json
Type "pid".
Security considerations: for entity property type "pid" are the same
as documented in [RFC7285] for the ALTO endpoint property type
"pid".
9. Impact on Legacy ALTO Servers and ALTO Clients 9. Impact on Legacy ALTO Servers and ALTO Clients
9.1. Impact on Endpoint Property Service 9.1. Impact on Endpoint Property Service
Since the Property Map and the Filtered Property Map defined in this Since the Property Map and the Filtered Property Map defined in this
document provide a functionality that covers the EPS defined in document provide a functionality that covers the EPS defined in
Section 11.4 of [RFC7285], ALTO servers may prefer to provide Section 11.4 of [RFC7285], ALTO servers may prefer to provide
Property Map and Filtered Property Map in place of EPS. However, for Property Map and Filtered Property Map in place of EPS. However, for
the legacy endpoint properties, it is recommended that ALTO servers the legacy endpoint properties, it is recommended that ALTO servers
also provide EPS so that legacy clients can still be supported. also provide EPS so that legacy clients can still be supported.
9.2. Impact on Resource-Specific Properties 9.2. Impact on Resource-Specific Properties
Section 10.8 of [RFC7285] defines two categories of endpoint Section 10.8 of [RFC7285] defines two categories of endpoint
properties: "resource-specific" and "global". Resource-specific properties: "resource-specific" and "global". Resource-specific
property names are prefixed with the ID of the resource they depend property names are prefixed with the ID of the resource they depend
on, while global property names have no such prefix. The property on, while global property names have no such prefix. The property
map and the filtered property map defined in this document define map and the filtered property map specified in this document define
similar categories of entity properties. The difference is that similar categories of entity properties. The difference is that
entity property maps do not define "global" entity properties. entity property maps do not define "global" entity properties.
Instead, they define "self-defined" entity properties as a special Instead, they define "self-defined" entity properties as a special
case of "resource-specific" entity properties, where the specific 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. properties are defined within the scope of the property map.
9.3. Impact on Other Properties 9.3. Impact on Other Properties
In the present extension, properties can be defined on sets of entity In the present extension, properties can be defined for sets of
addresses, rather than just individual endpoint addresses as entity addresses, rather than just individual endpoint addresses as
initially defined in [RFC7285]. This might change the semantics of a initially defined in [RFC7285]. This might change the semantics of a
property. These sets can be for example hierarchical IP address property. These sets can be, for example, hierarchical IP address
blocks. For instance, a property such as fictitious "geo-location", blocks. For instance, a property such as the fictitious "geo-
defined on a set of IP addresses would have a value corresponding to location" defined for a set of IP addresses would have a value
a location representative of all the addresses in this set. corresponding to a location representative of all the addresses in
this set.
10. Examples 10. Examples
In this document, the HTTP message bodies of all the examples use In this document, the HTTP message bodies of all the examples use
Unix-style line-ending character (%x0A) as the line separator. Unix-style line-ending character (%x0A) as the line separator.
10.1. Network Map 10.1. Network Map
The examples in this section use a very simple default network map: The examples in this section use a very simple default network map:
skipping to change at page 38, line 32 skipping to change at line 1756
And another simple alternative network map: And another simple alternative network map:
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
Figure 4: Example Alternative Network Map Figure 4: Example Alternative Network Map
10.2. Property Definitions 10.2. Property Definitions
Beyond "pid", the examples in this section use four additional Beyond "pid", the examples in this section use four additional,
fictitious property types for entities of domain type "ipv4": fictitious property types for entities of domain type "ipv4":
"countrycode", "ASN", "ISP", and "state". These properties are "countrycode", "ASN", "ISP", and "state". These properties are
assumed to be resource-agnostic so their name is identical to their assumed to be resource-agnostic so their name is identical to their
type. The entities have the following values: type. The entities have the following values:
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
Figure 5: Example Property Values for Internet Address Domains Figure 5: Example Property Values for Internet Address Domains
And the examples in this section use the property "region" for the The examples in this section use the property "region" for the PID
PID domain of the default network map with the following values: domain of the default network map with the following values:
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
Figure 6: Example Property Values for Default Network Map's PID Figure 6: Example Property Values for Default Network Map's PID
Domain Domain
Note that "-" means the value of the property for the entity is Note that "-" means the value of the property for the entity is
"undefined". So the entity would inherit a value for this property "undefined". So the entity would inherit a value for this property
by the inheritance rule if possible. For example, the value of the by the inheritance rule if possible. For example, the value of the
"ISP" property for "ipv4:192.0.2.1" is "BitsRus" because of "ISP" property for "ipv4:192.0.2.1" is "BitsRus" because of
"ipv4:192.0.2.0/24". But the "region" property for "pid:defaultpid" "ipv4:192.0.2.0/24". But the "region" property for "pid:defaultpid"
has no value because no entity from which it can inherit. has no value because there is no entity from which it can inherit.
Similar to the PID domain of the default network map, the examples in 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 this section use the property "ASN" for the PID domain of the
alternative network map with the following values: alternative network map with the following values:
ASN ASN
pid:defaultpid: - pid:defaultpid: -
pid:pid1: 65543 pid:pid1: 65543
pid:pid2: 65544 pid:pid2: 65544
Figure 7: Example Property Values for Alternative Network Map's Figure 7: Example Property Values for Alternative Network Map's
PID Domain PID Domain
10.3. Information Resource Directory (IRD) 10.3. Information Resource Directory (IRD)
The following IRD defines ALTO Server information resources that are The following IRD defines ALTO Server information resources that are
relevant to the Entity Property Service. It provides a property map relevant to the Entity Property Service. It provides a property map
for the "ISP" and "ASN" properties. The server could have provided a for the "ISP" and "ASN" properties. The server could have provided a
single property map for all four properties, but does not, presumably single property map for all four properties, but it does not,
because the organization that runs the ALTO server believes that a presumably because the organization that runs the ALTO server
client is not necessarily interested in getting all four properties. believes that a client is not necessarily interested in getting all
four properties.
The server provides several filtered property maps. The first The server provides several filtered property maps. The first
returns all four properties, and the second returns only the "pid" returns all four properties, and the second returns only the "pid"
property for the default network map and the "alt-network-map". property for the default network map and the "alt-network-map".
The filtered property maps for the "ISP", "ASN", "countrycode" and The filtered property maps for the "ISP", "ASN", "countrycode", and
"state" properties do not depend on the default network map (it does "state" properties do not depend on the default network map (it does
not have a "uses" capability), because the definitions of those not have a "uses" capability) because the definitions of those
properties do not depend on the default network map. The Filtered properties do not depend on the default network map. The Filtered
Property Map providing the "pid" property does have a "uses" Property Map providing the "pid" property does have a "uses"
capability for the default network map because the default network capability for the default network map because the default network
map defines the values of the "pid" property. map defines the values of the "pid" property.
Note that for legacy clients, the ALTO server provides an Endpoint Note that for legacy clients, the ALTO server provides an Endpoint
Property Service for the "pid" property defined on the endpoints of Property Service for the "pid" property defined for the endpoints of
the default network map and the "alt-network-map". the default network map and the "alt-network-map".
The server provides another filtered Property map resource, named 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 persistent "storage-capacity", "ram", and "cpu" for ANEs that have a persistent
identifier. The entity domain to which the ANEs belong is "self- identifier. The entity domain to which the ANEs belong is "self-
defined" and valid only within the property map. defined" and valid only within the property map.
The other property maps in the returned IRD are here for purposes of The other property maps in the returned IRD are shown here for
illustration. purposes of illustration.
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 page 42, line 33 skipping to change at line 1942
The following example uses the properties and IRD defined in The following example uses the properties and IRD defined in
Section 10.3 to retrieve a Property Map for entities with the "ISP" Section 10.3 to retrieve a Property Map for entities with the "ISP"
and "ASN" properties. and "ASN" properties.
Note that, to be compact, the response does not include the entity 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 "ipv4:192.0.2.1" because values of all those properties for this
entity are inherited from other entities. entity are inherited from other entities.
Also note that the entities "ipv4:192.0.2.0/28" and 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 "ipv4:192.0.2.16/28" are merged into "ipv4:192.0.2.0/27" because they
they have the same value of the "ASN" property. The same rule have the same value of the "ASN" property. The same rule applies to
applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28". the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28". Both
Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value for the
for the "ISP" property, because it is inherited from "ISP" property because it is inherited from "ipv4:192.0.2.0/23".
"ipv4:192.0.2.0/23".
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
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 418 Content-Length: 418
Content-Type: application/alto-propmap+json Content-Type: application/alto-propmap+json
{ {
"meta": { "meta": {
"dependent-vtags": [ "dependent-vtags": [
{"resource-id": "default-network-map", {"resource-id": "default-network-map",
"tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"},
{"resource-id": "alt-network-map", {"resource-id": "alt-network-map",
skipping to change at page 43, line 27 skipping to change at line 1975
"property-map": { "property-map": {
"ipv4:192.0.2.0/23": {".ISP": "BitsRus"}, "ipv4:192.0.2.0/23": {".ISP": "BitsRus"},
"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"}
} }
} }
10.5. Filtered Property Map Example #1 10.5. Filtered Property Map Example #1
The following example uses the filtered property map resource to The following example uses the filtered property map resource to
request the "ISP", "ASN" and "state" properties for several IPv4 request the "ISP", "ASN", and "state" properties for several IPv4
addresses. addresses.
Note that the value of "state" for "ipv4:192.0.2.1" is the only Note that the value of "state" for "ipv4:192.0.2.1" is the only
explicitly defined property; the other values are all derived by the explicitly defined property; the other values are all derived from
inheritance rules for Internet address entities. the inheritance rules for Internet address entities.
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
{ {
"entities" : [ "ipv4:192.0.2.0", "entities" : [ "ipv4:192.0.2.0",
"ipv4:192.0.2.1", "ipv4:192.0.2.1",
skipping to change at page 44, line 30 skipping to change at line 2021
"ipv4:192.0.2.1": "ipv4:192.0.2.1":
{".ISP": "BitsRus", ".ASN": "65543", ".state": "PA"}, {".ISP": "BitsRus", ".ASN": "65543", ".state": "PA"},
"ipv4:192.0.2.17": "ipv4:192.0.2.17":
{".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"} {".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"}
} }
} }
10.6. Filtered Property Map Example #2 10.6. Filtered Property Map Example #2
The following example uses the filtered property map resource to The following example uses the filtered property map resource to
request the "ASN", "countrycode" and "state" properties for several request the "ASN", "countrycode", and "state" properties for several
IPv4 prefixes. IPv4 prefixes.
Note that the property values for both entities "ipv4:192.0.2.0/26" Note that the property values for both entities "ipv4:192.0.2.0/26"
and "ipv4:192.0.3.0/26" are not explicitly defined. They are and "ipv4:192.0.3.0/26" are not explicitly defined. They are
inherited from the entity "ipv4:192.0.2.0/23". inherited from the entity "ipv4:192.0.2.0/23".
Also note that some entities like "ipv4:192.0.2.0/28" and 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 request. The response includes them because they are refinements of
the requested entities and have different values for the requested the requested entities and have different values for the requested
properties. properties.
The entity "ipv4:192.0.4.0/26" is not included in the response, The entity "ipv4:192.0.4.0/26" is not included in the response
because there are neither entities which it is inherited from, nor because there are neither entities from which it is inherited, nor
entities inherited from it. entities inherited from it.
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
{ {
"entities" : [ "ipv4:192.0.2.0/26", "entities" : [ "ipv4:192.0.2.0/26",
skipping to change at page 46, line 6 skipping to change at line 2086
} }
} }
10.7. Filtered Property Map Example #3 10.7. Filtered Property Map Example #3
The following example uses the filtered property map resource to The following example uses the filtered property map resource to
request the "default-network-map.pid" property and the "alt-network- request the "default-network-map.pid" property and the "alt-network-
map.pid" property for a set of IPv4 addresses and prefixes. map.pid" property for a set of IPv4 addresses and prefixes.
Note that the entity "ipv4:192.0.3.0/27" is decomposed into two Note that the entity "ipv4:192.0.3.0/27" is decomposed into two
entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28", as they have entities: "ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28", as they have
different "default-network-map.pid" property values. different "default-network-map.pid" property values.
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
{ {
"entities" : [ "entities" : [
skipping to change at page 48, line 52 skipping to change at line 2222
undesirable guidance from authenticated ALTO information (e.g., undesirable guidance from authenticated ALTO information (e.g.,
potentially imprecise or even wrong value of a property such as geo- potentially imprecise or even wrong value of a property such as geo-
location), confidentiality of ALTO information (e.g., exposure of a location), confidentiality of ALTO information (e.g., exposure of a
potentially sensitive entity property such as geo-location), privacy potentially sensitive entity property such as geo-location), privacy
for ALTO users, and availability of ALTO services should all be for ALTO users, and availability of ALTO services should all be
considered. considered.
ALTO clients using this extension should in addition be aware that ALTO clients using this extension should in addition be aware that
the entity properties they require may convey more details than the the entity properties they require may convey more details than the
endpoint properties conveyed by using [RFC7285]. Client requests may endpoint properties conveyed by using [RFC7285]. Client requests may
reveal details on their activity or plans thereof, that a malicious reveal details of their activity or plans thereof such that a
Server, that is in a position to do so, may monetize or use for malicious Server, which is in a position to do so, may monetize or
attacks or undesired surveillance. Likewise, ALTO Servers expose use for attacks or undesired surveillance. Likewise, ALTO Servers
entities and properties related to specific parts of the expose entities and properties related to specific parts of the
infrastructure that reveal details on capabilities, locations, or infrastructure that reveal details of capabilities, locations, or
resource availability. These details may be maliciously used for resource availability. These details may be maliciously used for
competition purposes, or to cause resource shortage or undesired competition purposes, or to cause resource shortage or undesired
publication. publication.
To address these concerns, the Property Maps provided by this To address these concerns, the Property Maps provided by this
extension require additional attention on two security considerations extension require additional attention to two security considerations
discussed in [RFC7285]: "potential undesirable guidance from discussed in: Section 15.2 ("Potential Undesirable Guidance from
authenticated ALTO information" (Section 15.2 of [RFC7285]) and Authenticated ALTO Information") of [RFC7285] and Section 15.3
"confidentiality of ALTO information" (Section 15.3 of [RFC7285]). ("Confidentiality of ALTO Information") of [RFC7285]. Threats to the
Threats to the availability of the ALTO Service caused by highly availability of the ALTO service caused by highly demanding queries
demanding queries should be addressed as specified in Section 15.5 of should be addressed as specified in Section 15.5 of [RFC7285].
[RFC7285].
* Potential undesirable guidance from authenticated ALTO * Potential undesirable guidance from authenticated ALTO
information: it can be caused by Property values that change over information: this can be caused by Property values that change
time and thus lead to performance degradation or system rejection over time and thus lead to performance degradation or system
of application requests. rejection of application requests.
To avoid these consequences, a more robust ALTO client should To avoid these consequences, a more robust ALTO client should
adopt and extend protection strategies specified in Section 15.2 adopt and extend protection strategies specified in Section 15.2
of [RFC7285]. For example, to be notified immediately when a of [RFC7285]. For example, to be notified immediately when a
particular ALTO value that the Client depends on changes, it is particular ALTO value that the Client depends on changes, it is
RECOMMENDED that both the ALTO Client and ALTO Server using this RECOMMENDED that both the ALTO Client and ALTO Server using this
extension implement "Application-Layer Traffic Optimization (ALTO) extension implement "Application-Layer Traffic Optimization (ALTO)
Incremental Updates Using Server-Sent Events (SSE)" [RFC8895]. Incremental Updates Using Server-Sent Events (SSE)" [RFC8895].
* Confidentiality of ALTO information: as discussed in Section 15 of * Confidentiality of ALTO information: as discussed in Section 15 of
[RFC7285], properties may have sensitive customer-specific [RFC7285], properties may have sensitive customer-specific
information. If this is the case, an ALTO Server may limit access information. If this is the case, an ALTO Server may limit access
to those properties by providing several different property maps. to those properties by providing several different property maps.
For non-sensitive properties, the ALTO Server would provide a URI For a nonsensitive properties, the ALTO Server would provide a URI
which accepts requests from any client. Sensitive properties, on that accepts requests from any client. Sensitive properties, on
the other hand, would only be available via a secure URI which the other hand, would only be available via a secure URI that
would require client authentication. Another way is to expose would require client authentication. Another way is to expose
highly abstracted coarse-grained property values to all Clients highly abstracted, coarse-grained property values to all Clients
while restricting access to URIs exposing more fine-grained values while restricting access to URIs that expose more fine-grained
to authorized Clients. Restricted access URIs may be gathered in values to authorized Clients. Restricted access URIs may be
delegate IRDs as specified in Section 9.2.4 of [RFC7285]. gathered in delegate IRDs as specified in Section 9.2.4 of
[RFC7285].
Also, while technically this document does not introduce any Also, while technically this document does not introduce any
security risks not inherent in the Endpoint Property Service security risks not inherent in the Endpoint Property Service
defined by [RFC7285], the GET-mode property map resource defined defined by [RFC7285], the GET-mode property map resource defined
in this document does make it easier for a client to download in this document does make it easier for a client to download
large numbers of property values. Accordingly, an ALTO Server large numbers of property values. Accordingly, an ALTO Server
should limit GET-mode property maps to properties that do not should limit GET-mode property maps to properties that do not
contain sensitive data. contain sensitive data.
Section 12 of this document specifies that the ALTO service Section 12 of this document specifies that the ALTO service
provider MUST be aware of the potential sensitivity of exposed provider MUST be aware of the potential sensitivity of exposed
entity domains and properties. Section 12.2.2. (ALTO Entity entity domains and properties. Section 12.3.2 (ALTO Entity Domain
Domain Type Registration Process) of this document specifies that Type Registration Process) of this document specifies that when
when the registration of an entity domain type is requested at the the registration of an entity domain type is requested of IANA,
IANA, the request MUST include security considerations that show the request MUST include security considerations that show
awareness of how the exposed entity addresses may be related to awareness of how the exposed entity addresses may be related to
private information about an ALTO client or an infrastructure private information about an ALTO client or an infrastructure
service provider. Likewise, Section 12.3. (ALTO Entity Property service provider. Likewise, Section 12.4 (ALTO Entity Property
Type Registry) of this document specifies that when the Types Registry) of this document specifies that when the
registration of a property type is requested at the IANA, the registration of a property type is requested of IANA, the request
request MUST include security considerations that explain why this MUST include security considerations that explain why this
property type is required for ALTO-based operations. property type is required for ALTO-based operations.
The risk of ALTO information being leaked to malicious Clients or The risk of ALTO information being leaked to malicious Clients or
third parties is addressed similarly to Section 7 of [RFC8896]. third parties is addressed similarly to Section 7 of [RFC8896].
ALTO clients and servers SHOULD support TLS 1.3 [RFC8446]. ALTO clients and servers SHOULD support TLS 1.3 [RFC8446].
12. IANA Considerations 12. IANA Considerations
This document defines additional application/alto-* media types, that This document defines additional application/alto-* media types,
are listed in Table 1. It defines an ALTO Entity Domain Type which are listed in Table 1. It defines the "ALTO Entity Domain
Registry that extends the ALTO Address Type Registry defined in Types" registry that extends the "ALTO Address Types" registry
[RFC7285]. It also defines an ALTO Entity Property Type Registry defined in [RFC7285]. It also defines the "ALTO Entity Property
that extends the ALTO endpoint property registry defined in Types" registry that extends the "ALTO Endpoint Property Types"
[RFC7285]. registry defined in [RFC7285].
+=============+=========================+===============+ +=============+=========================+===============+
| Type | Subtype | Specification | | Type | Subtype | Specification |
+=============+=========================+===============+ +=============+=========================+===============+
| application | alto-propmap+json | Section 7.1 | | application | alto-propmap+json | Section 7.1 |
+-------------+-------------------------+---------------+ +-------------+-------------------------+---------------+
| application | alto-propmapparams+json | Section 8.3 | | application | alto-propmapparams+json | Section 8.1 |
+-------------+-------------------------+---------------+ +-------------+-------------------------+---------------+
Table 1: Additional ALTO Media Types. Table 1: Additional ALTO Media Types
12.1. application/alto-propmap+json Media Type 12.1. application/alto-propmap+json Media Type
Type name: Type name:
application application
Subtype name: Subtype name:
alto-propmap+json alto-propmap+json
Required parameters: Required parameters:
skipping to change at page 51, line 36 skipping to change at line 2342
and Section 11 of this document. and Section 11 of this document.
Interoperability considerations: Interoperability considerations:
n/a n/a
Published specification: Published specification:
This document is the specification for this media type. See This document is the specification for this media type. See
Section 7.1. Section 7.1.
Applications that use this media type: Applications that use this media type:
ALTO servers and ALTO clients [RFC7285], either stand alone or ALTO servers and ALTO clients [RFC7285], either standalone or
embedded within other applications, when the queried resource is a embedded within other applications, when the queried resource is a
property map, whether filtered or not. property map, whether filtered or not.
Fragment identifier considerations: Fragment identifier considerations:
n/a n/a
Additional information: Additional information:
Magic number(s): n/a Magic number(s): n/a
File extension(s): n/a File extension(s): n/a
skipping to change at page 52, line 45 skipping to change at line 2399
Security considerations: Security considerations:
Security considerations related to the generation and consumption Security considerations related to the generation and consumption
of ALTO Protocol messages are discussed in Section 15 of [RFC7285] of ALTO Protocol messages are discussed in Section 15 of [RFC7285]
and Section 11 of this document. and Section 11 of this document.
Interoperability considerations: Interoperability considerations:
n/a n/a
Published specification: Published specification:
This document is the specification for this media type. See This document is the specification for this media type. See
Section 8.3. Section 8.1.
Applications that use this media type: Applications that use this media type:
ALTO servers and ALTO clients [RFC7285], either stand alone or ALTO servers and ALTO clients [RFC7285], either standalone or
embedded within other applications, when the queried resource is a embedded within other applications, when the queried resource is a
filtered property map. This media-type indicates the data format filtered property map. This media type indicates the data format
used by the ALTO client to supply the property map filtering used by the ALTO client to supply the property map filtering
parameters. parameters.
Fragment identifier considerations: Fragment identifier considerations:
n/a n/a
Additional information: Additional information:
Magic number(s): n/a Magic number(s): n/a
File extension(s): n/a File extension(s): n/a
skipping to change at page 53, line 30 skipping to change at line 2433
Restrictions on usage: Restrictions on usage:
n/a n/a
Author: Author:
See Authors' Addresses section. See Authors' Addresses section.
Change controller: Change controller:
Internet Engineering Task Force (mailto:iesg@ietf.org). Internet Engineering Task Force (mailto:iesg@ietf.org).
12.3. ALTO Entity Domain Type Registry 12.3. ALTO Entity Domain Types Registry
This document requests IANA to create and maintain the "ALTO Entity IANA has created and will maintain the "ALTO Entity Domain Types"
Domain Type Registry", listed in Table 2. The first line lists registry listed in Table 2. The first row lists information items
information items that must be provided with each registered entity that must be provided with each registered entity domain type.
domain type. Section 12.3.2 specifies how to document these items Section 12.3.2 specifies how to document these items and in addition
and provides guidance on the security considerations item that must provides guidance on the security considerations item that must be
be documented in addition. documented.
+==========+===========+=============+======================+=======+ +==========+===========+=============+======================+=======+
|Identifier|Entity |Hierarchy & |Media Type of Defining|Mapping| |Identifier|Entity |Hierarchy and|Media Type of Defining|Mapping|
| |Identifier |Inheritance |Resource |to ALTO| | |Identifier |Inheritance |Resource |to ALTO|
| |Encoding | | |Address| | |Encoding | | |Address|
| | | | |Type | | | | | |Type |
+==========+===========+=============+======================+=======+ +==========+===========+=============+======================+=======+
|ipv4 |See Section|See |application/alto- |true | |ipv4 |See Section|See |application/alto- |true |
| |6.1.1 |Section 6.1.3|networkmap+json | | | |6.1.1 |Section 6.1.3|networkmap+json | |
+----------+-----------+-------------+----------------------+-------+ +----------+-----------+-------------+----------------------+-------+
|ipv6 |See Section|See |application/alto- |true | |ipv6 |See Section|See |application/alto- |true |
| |6.1.2 |Section 6.1.3|networkmap+json | | | |6.1.2 |Section 6.1.3|networkmap+json | |
+----------+-----------+-------------+----------------------+-------+ +----------+-----------+-------------+----------------------+-------+
skipping to change at page 54, line 30 skipping to change at line 2467
Table 2: ALTO Entity Domain Types Table 2: ALTO Entity Domain Types
This registry serves two purposes. First, it ensures uniqueness of This registry serves two purposes. First, it ensures uniqueness of
identifiers referring to ALTO entity domain types. Second, it states identifiers referring to ALTO entity domain types. Second, it states
the requirements for allocated entity domain types. the requirements for allocated entity domain types.
As specified in Section 5.1.1, identifiers prefixed with "priv:" are As specified in Section 5.1.1, 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
12.3.1. Consistency Procedure between ALTO Address Type Registry and 12.3.1. Consistency Procedure between ALTO Address Types Registry and
ALTO Entity Domain Type Registry ALTO Entity Domain Types Registry
One potential issue of introducing the "ALTO Entity Domain Type One potential issue of introducing the "ALTO Entity Domain Types"
Registry" is its relationship with the "ALTO Address Types Registry" registry is its relationship with the "ALTO Address Types" registry
already defined in Section 14.4 of [RFC7285]. In particular, the already defined in Section 14.4 of [RFC7285]. In particular, the
entity identifier of a type of an entity domain registered in the entity identifier of a type of an entity domain registered in the
"ALTO Entity Domain Type Registry" MAY match an address type defined "ALTO Entity Domain Types" registry MAY match an address type defined
in "ALTO Address Type Registry". It is necessary to precisely define in "ALTO Address Types" registry. It is necessary to precisely
and guarantee the consistency between "ALTO Address Type Registry" define and guarantee the consistency between "ALTO Address Types"
and "ALTO Entity Domain Registry". registry and "ALTO Entity Domain Types" registry.
We define that the ALTO Entity Domain Type Registry is consistent We define that the "ALTO Entity Domain Types" registry is consistent
with ALTO Address Type Registry if two conditions are satisfied: with "ALTO Address Types" registry if two conditions are satisfied:
* When an address type is already or able to be registered in the * When an address type is already registered or is able to be
ALTO Address Type Registry [RFC7285], the same identifier MUST be registered in the "ALTO Address Types" registry [RFC7285], the
used when a corresponding entity domain type is registered in the same identifier MUST be used when a corresponding entity domain
ALTO Entity Domain Type Registry. type is registered in the "ALTO Entity Domain Types" registry.
* If an ALTO entity domain type has the same identifier as an ALTO * If an ALTO entity domain type has the same identifier as an ALTO
address type, their addresses encoding MUST be compatible. address type, their address encodings MUST be compatible.
To achieve this consistency, the following items MUST be checked To achieve this consistency, the following items MUST be checked
before registering a new ALTO entity domain type in a future before registering a new ALTO entity domain type in a future
document: document:
* Whether the ALTO Address Type Registry contains an address type * Whether the "ALTO Address Types" registry contains an address type
that can be used as an identifier for the candidate entity domain that can be used as an identifier for the candidate entity domain
type identifier. This has been done for the identifiers "ipv4" type identifier. This has been done for the identifiers "ipv4"
and "ipv6" of Table 2. and "ipv6" of Table 2.
* Whether the candidate entity domain type identifier can * Whether the candidate entity domain type identifier can
potentially be an endpoint address type, as defined in Sections potentially be an endpoint address type, as defined in Sections
2.1 and 2.2 of [RFC7285]. 2.1 and 2.2 of [RFC7285].
When a new ALTO entity domain type is registered, the consistency When a new ALTO entity domain type is registered, the consistency
with the ALTO Address Type Registry MUST be ensured by the following with the "ALTO Address Types" registry MUST be ensured by the
procedure: following procedure:
* Test: Do corresponding entity domain type identifiers match a * Test: Do corresponding entity domain type identifiers match a
known "network" address type? known "network" address type?
- If yes (e.g., cell, MAC or socket addresses): - If yes (e.g., cell, MAC, or socket addresses):
o Test: Is such an address type present in the ALTO Address o Test: Is such an address type present in the "ALTO Address
Type Registry? Types" registry?
+ If yes: Set the new ALTO entity domain type identifier to + If yes: Set the new ALTO entity domain type identifier to
be the found ALTO address type identifier. be the found ALTO address type identifier.
+ If no: Define a new ALTO entity domain type identifier + If no: Define a new ALTO entity domain type identifier
and use it to register a new address type in the ALTO and use it to register a new address type in the "ALTO
Address Type Registry following Section 14.4 of Address Types" registry following Section 14.4 of
[RFC7285]. [RFC7285].
o Use the new ALTO entity domain type identifier to register a o Use the new ALTO entity domain type identifier to register a
new ALTO entity domain type in the ALTO Entity Domain Type new ALTO entity domain type in the "ALTO Entity Domain
Registry following Section 12.3.2 of this document. Types" registry following Section 12.3.2 of this document.
- If no (e.g., pid name, ane name or country code): Proceed with - If no (e.g., pid name, ane name, or country code): Proceed with
the ALTO Entity Domain Type registration as described in the ALTO Entity Domain Type registration as described in
Section 12.3.2. Section 12.3.2.
12.3.2. ALTO Entity Domain Type Registration Process 12.3.2. ALTO Entity Domain Type Registration Process
New ALTO entity domain types are assigned after IETF Review [RFC8126] New ALTO entity domain types are assigned after IETF Review [RFC8126]
to ensure that proper documentation regarding the new ALTO entity to ensure that proper documentation regarding the new ALTO entity
domain types and their security considerations has been provided. domain types and their security considerations has been provided.
RFCs defining new entity domain types MUST indicate how an entity in RFCs defining new entity domain types MUST indicate how an entity in
a registered type of domain is encoded as an EntityID, and, if a registered type of domain is encoded as an EntityID and, if
applicable, the rules defining the entity hierarchy and property applicable, the rules defining the entity hierarchy and property
inheritance. Updates and deletions of ALTO entity domains types inheritance. Updates and deletions of ALTO entity domains types
follow the same procedure. follow the same procedure.
Registered ALTO entity domain type identifiers MUST conform to the Registered ALTO entity domain type identifiers MUST conform to the
syntactical requirements specified in Section 5.1.2. Identifiers are syntactical requirements specified in Section 5.1.2. Identifiers are
to be recorded and displayed as strings. to be recorded and displayed as strings.
Requests to the IANA to add a new value to the Entity Domain Type Requests to IANA to add a new value to the "ALTO Entity Domain Types"
registry MUST include the following information: registry MUST include the following information:
* Identifier: The name of the desired ALTO entity domain type. Identifier: The name of the desired ALTO entity domain type.
* Entity Identifier Encoding: The procedure for encoding the Entity Identifier Encoding: The procedure for encoding the
identifier of an entity of the registered domain type as an identifier of an entity of the registered domain type as an
EntityID (see Section 5.1.3). If corresponding entity identifiers EntityID (see Section 5.1.3). If corresponding entity identifiers
of an entity domain type match a known "network" address type, the of an entity domain type match a known "network" address type, the
Entity Identifier Encoding of this domain identifier MUST include Entity Identifier Encoding of this domain identifier MUST include
both Address Encoding and Prefix Encoding of the same identifier both Address Encoding and Prefix Encoding of the same identifier
registered in the ALTO Address Type Registry [RFC7285]. To define registered in the "ALTO Address Types" registry [RFC7285]. To
properties, an individual entity identifier and the corresponding define properties, an individual entity identifier and the
full-length prefix MUST be considered aliases for the same entity. corresponding full-length prefix MUST be considered aliases for
the same entity.
* Hierarchy: If the entities form a hierarchy, the procedure for Hierarchy: If the entities form a hierarchy, the procedure for
determining that hierarchy. determining that hierarchy.
* Inheritance: If entities can inherit property values from other Inheritance: If entities can inherit property values from other
entities, the procedure for determining that inheritance. entities, the procedure for determining that inheritance.
* Media type of defining information resource: Some entity domain Media type of defining information resource: Some entity domain
types allow an entity domain name to be combined with an types allow an entity domain name to be combined with an
information resource name to define a resource-specific entity information resource name to define a resource-specific entity
domain. Such an information resource is called "defining domain. Such an information resource is called a "defining
information resource", defined in Section 4.6. For each entity information resource" and is defined in Section 4.6. For each
domain type, the potential defining information resources have one entity domain type, the potential defining information resources
common media type. This unique common media type is specific to have one common media type. This unique common media type is
the entity domain type and MUST be specified. specific to the entity domain type and MUST be specified.
* Mapping to ALTO Address Type: A boolean value to indicate if the Mapping to ALTO Address Type: A boolean value to indicate if the
entity domain type can be mapped to the ALTO address type with the entity domain type can be mapped to the ALTO address type with the
same identifier. same identifier.
* Security Considerations: In some usage scenarios, entity Security Considerations: In some usage scenarios, entity identifiers
identifiers carried in ALTO Protocol messages may reveal carried in ALTO Protocol messages may reveal information about an
information about an ALTO client or an ALTO service provider. ALTO client or an ALTO service provider. Applications and ALTO
Applications and ALTO service providers using addresses of the service providers using addresses of the registered type should be
registered type should be cognizant of how (or if) the addressing cognizant of how (or if) the addressing scheme relates to private
scheme relates to private information and network proximity. information and network proximity.
This specification requests registration of the identifiers "ipv4", IANA has registered the identifiers "ipv4", "ipv6", and "pid", as
"ipv6" and "pid", as shown in Table 2. shown in Table 2.
12.4. ALTO Entity Property Type Registry 12.4. ALTO Entity Property Types Registry
This document requests IANA to create and maintain the "ALTO Entity IANA has created and will maintain the "ALTO Entity Property Types"
Property Type Registry", listed in Table 3. registry, which is listed in Table 3.
This registry extends the "ALTO Endpoint Property Type Registry", This registry extends the "ALTO Endpoint Property Types" registry,
defined in [RFC7285], in that a property type is defined on one or defined in [RFC7285], in that a property type is defined for one or
more entity domains, rather than just on IPv4 and IPv6 Internet more entity domains, rather than just for IPv4 and IPv6 Internet
address domains. An entry in this registry is an ALTO entity address domains. An entry in this registry is an ALTO entity
property type defined in Section 5.2.1. Thus, a registered ALTO property type defined in Section 5.2.1. Thus, a registered ALTO
entity property type identifier MUST conform to the syntactical entity property type identifier MUST conform to the syntactical
requirements specified in that section. requirements specified in that section.
As specified in Section 5.2.1, identifiers prefixed with "priv:" are As specified in Section 5.2.1, 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.
The first line of Table 3 lists information items that must be The first row of Table 3 lists information items that must be
provided with each registered entity property type. provided with each registered entity property type.
+============+====================+=================================+ +============+====================+=================================+
| Identifier | Intended Semantics | Media Type of | | Identifier | Intended Semantics | Media Type of |
| | | Defining Resource | | | | Defining Resource |
+============+====================+=================================+ +============+====================+=================================+
| pid | See Section 7.1.1 | application/alto- | | pid | See Section 7.1.1 | application/alto- |
| | of [RFC7285] | networkmap+json | | | of [RFC7285] | networkmap+json |
+------------+--------------------+---------------------------------+ +------------+--------------------+---------------------------------+
Table 3: ALTO Entity Property Types. Table 3: ALTO Entity Property Types
New ALTO entity property types are assigned after IETF Review New ALTO entity property types are assigned after IETF Review
[RFC8126] to ensure that proper documentation regarding the new ALTO [RFC8126] to ensure that proper documentation regarding the new ALTO
entity property types and their security considerations has been entity property types and their security considerations has been
provided. RFCs defining new entity property types SHOULD indicate provided. RFCs defining new entity property types SHOULD indicate
how a property of a registered type is encoded as a property name. how a property of a registered type is encoded as a property name.
Updates and deletions of ALTO entity property types follow the same Updates and deletions of ALTO entity property types follow the same
procedure. procedure.
Requests to the IANA to add a new value to the registry MUST include Requests to IANA to add a new value to the registry MUST include the
the following information: following information:
* Identifier: The identifier for the desired ALTO entity property Identifier: The identifier for the desired ALTO entity property
type. The format MUST be as defined in Section 5.2.1 of this type. The format MUST be as defined in Section 5.2.1 of this
document. document.
* Intended Semantics: ALTO entity properties carry with them Intended Semantics: ALTO entity properties carry with them semantics
semantics to guide their usage by ALTO clients. Hence, a document to guide their usage by ALTO clients. Hence, a document defining
defining a new type SHOULD provide guidance to both ALTO service a new type SHOULD provide guidance to both ALTO service providers
providers and applications utilizing ALTO clients as to how values and applications utilizing ALTO clients as to how values of the
of the registered ALTO entity property should be interpreted. registered ALTO entity property should be interpreted.
* Media type of defining information resource: when the property Media type of defining information resource: when the property type
type allows values to be defined relative to a given information allows values to be defined relative to a given information
resource, the latter is referred to as the "defining information resource, the latter is referred to as the "defining information
resource", see description in Section 4.7. For each property resource"; see the description in Section 4.7. For each property
type, the potential defining information resources have one common type, the potential defining information resources have one common
media type. This unique common media type is specific to the media type. This unique common media type is specific to the
property type and MUST be specified. property type and MUST be specified.
* Security Considerations: ALTO entity properties expose information Security Considerations: ALTO entity properties expose information
to ALTO clients. ALTO service providers should be cognizant of to ALTO clients. ALTO service providers should be cognizant of
the security ramifications related to the exposure of an entity the security ramifications related to the exposure of an entity
property. property.
In security considerations, the request should also discuss the In security considerations, the request should also discuss the
sensitivity of the information, and why it is required for ALTO-based sensitivity of the information and why it is required for ALTO-based
operations. Regarding this discussion, the request SHOULD follow the operations. Regarding this discussion, the request SHOULD follow the
recommendations of Section 14.3. ALTO Endpoint Property Type recommendations of the "ALTO Endpoint Property Types" registry in
Registry in [RFC7285]. Section 14.3 of [RFC7285].
This document requests registration of the identifier "pid", listed
in Table 3. Semantics for this property are documented in
Section 7.1.1 of [RFC7285]. No security issues related to the
exposure of a "pid" identifier are considered, as it is exposed with
the Network Map Service defined and mandated in [RFC7285].
13. Acknowledgments
The authors would like to thank Dawn Chen, and Shenshen Chen for IANA has registered the identifier "pid", which is listed in Table 3.
their contributions to earlier drafts. Thank you also to Qiao Xiang, Semantics for this property are documented in Section 7.1.1 of
Shawn Lin, Xin Wang and Vijay Gurbani for fruitful discussions. [RFC7285]. No security issues related to the exposure of a "pid"
Last, big thanks to Danny Perez and Luis Contreras for their identifier are considered, as it is exposed with the Network Map
substantial Working Group review feedback and suggestions to improve Service defined and mandated in [RFC7285].
this document, to Vijay Gurbani, ALTO WG Chair and Martin Duke,
Transport Area Director, for their thorough review, discussions,
guidance and shepherding, that further helped to enrich this
document.
14. References 13. References
14.1. Normative References 13.1. Normative References
[ISO3166-1] [ISO3166-1]
ISO (International Organization for Standardization), ., International Organization for Standardization, "Codes for
"ISO 3166-1: Codes for the representation of names of the representation of names of countries and their
countries and their subdivisions -- Part 1: Country subdivisions -- Part 1: Country codes", ISO 3166-1:2020,
codes", 2020. August 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", February 2006. Architecture", RFC 4291, DOI 10.17487/RFC4291, February
2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation (CIDR): The Internet Address Assignment and Aggregation
Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August
2006, <https://www.rfc-editor.org/info/rfc4632>. 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, Address Text Representation", RFC 5952,
DOI 10.17487/RFC5952, August 2010, DOI 10.17487/RFC5952, August 2010,
<https://www.rfc-editor.org/info/rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
skipping to change at page 60, line 23 skipping to change at line 2729
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic [RFC8895] Roome, W. and Y. Yang, "Application-Layer Traffic
Optimization (ALTO) Incremental Updates Using Server-Sent Optimization (ALTO) Incremental Updates Using Server-Sent
Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November Events (SSE)", RFC 8895, DOI 10.17487/RFC8895, November
2020, <https://www.rfc-editor.org/info/rfc8895>. 2020, <https://www.rfc-editor.org/info/rfc8895>.
14.2. Informative References 13.2. Informative References
[I-D.ietf-alto-cdni-request-routing-alto]
Seedorf, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang,
"Content Delivery Network Interconnection (CDNI) Request
Routing: CDNI Footprint and Capabilities Advertisement
using ALTO", Work in Progress, Internet-Draft, draft-ietf-
alto-cdni-request-routing-alto-16, 12 January 2021,
<http://www.ietf.org/internet-drafts/draft-ietf-alto-cdni-
request-routing-alto-16.txt>.
[I-D.ietf-alto-path-vector] [PATH-VECTOR]
Gao, K., Lee, Y., Randriamasy, S., Yang, Y., and J. Zhang, Gao, K., Lee, Y., Randriamasy, S., Yang, Y. R., and J. J.
"ALTO Extension: Path Vector", Work in Progress, Internet- Zhang, "An ALTO Extension: Path Vector", Work in Progress,
Draft, draft-ietf-alto-path-vector-13, 20 November 2020, Internet-Draft, draft-ietf-alto-path-vector-25, 20 March
<http://www.ietf.org/internet-drafts/draft-ietf-alto-path- 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-
vector-13.txt>. alto-path-vector-25>.
[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix
Reserved for Documentation", July 2004. Reserved for Documentation", RFC 3849,
DOI 10.17487/RFC3849, July 2004,
<https://www.rfc-editor.org/info/rfc3849>.
[RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax [RFC5511] Farrel, A., "Routing Backus-Naur Form (RBNF): A Syntax
Used to Form Encoding Rules in Various Routing Protocol Used to Form Encoding Rules in Various Routing Protocol
Specifications", April 2009. Specifications", RFC 5511, DOI 10.17487/RFC5511, April
2009, <https://www.rfc-editor.org/info/rfc5511>.
[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks
Reserved for Documentation", January 2010. Reserved for Documentation", RFC 5737,
DOI 10.17487/RFC5737, January 2010,
<https://www.rfc-editor.org/info/rfc5737>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing Nadeau, "An Architecture for the Interface to the Routing
System", RFC 7921, DOI 10.17487/RFC7921, June 2016, System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<https://www.rfc-editor.org/info/rfc7921>. <https://www.rfc-editor.org/info/rfc7921>.
[RFC8896] Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N. [RFC8896] Randriamasy, S., Yang, R., Wu, Q., Deng, L., and N.
Schwan, "Application-Layer Traffic Optimization (ALTO) Schwan, "Application-Layer Traffic Optimization (ALTO)
Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, November Cost Calendar", RFC 8896, DOI 10.17487/RFC8896, November
2020, <https://www.rfc-editor.org/info/rfc8896>. 2020, <https://www.rfc-editor.org/info/rfc8896>.
Appendix A. Features introduced with the Entity Property Maps extension [RFC9241] Seedorf, J., Yang, Y., Ma, K., Peterson, J., and J. Zhang,
"Content Delivery Network Interconnection (CDNI) Request
Routing: CDNI Footprint and Capabilities Advertisement
using ALTO", RFC 9241, DOI 10.17487/RFC9241, May 2022,
<https://www.rfc-editor.org/info/rfc9241>.
Appendix A. Features Introduced with the Entity Property Maps Extension
The Entity Property Maps extension described in this document The Entity Property Maps extension described in this document
introduces a number of features that are summarized in table below. introduces a number of features that are summarized in table below.
The first column provides the name of the feature. The second column The first column provides the name of the feature. The second column
provides the section number of this document that gives a high level provides the section number of this document that gives a high-level
description of the feature. The third column provides the section description of the feature. The third column provides the section
number of this document that gives a normative description relating number of this document that gives a normative description relating
to the feature, when applicable. to the feature, when applicable.
+======================+=============+==============================+ +======================+=============+======================+
| Feature | High-level | Related normative | | Feature | High-Level | Related Normative |
| | description | description | | | Description | Description |
+======================+=============+==============================+ +======================+=============+======================+
| Entity | Section 3.1 | Section 5.1.3 | | Entity | Section 3.1 | Section 5.1.3 |
+----------------------+-------------+------------------------------+ +----------------------+-------------+----------------------+
| Entity domain | Section 3.2 | | | Entity domain (ED) | Section 3.2 | |
| (ED) | | | +----------------------+-------------+----------------------+
+----------------------+-------------+------------------------------+ | Entity domain type | Section | Section 5.1.1 |
| Entity domain | Section | Section 5.1.1 | | | 3.2.1 | |
| type | 3.2.1 | | +----------------------+-------------+----------------------+
+----------------------+-------------+------------------------------+ | Entity domain name | Section | Section 5.1.2 |
| Entity domain | Section | Section 5.1.2 | | | 3.2.2 | |
| name | 3.2.2 | | +----------------------+-------------+----------------------+
+----------------------+-------------+------------------------------+ | Entity property (EP) | Section 3.3 | Sections 5.2, 5.2.1, |
| Entity property | Section 3.3 | Section 5.2, Section 5.2.1, | | type | | 5.2.2, and 5.2.3 |
| (EP) type | | Section 5.2.2, Section 5.2.3 | +----------------------+-------------+----------------------+
+----------------------+-------------+------------------------------+ | Entity property map | Section 3.4 | Sections 7 and 8 |
| Entity property | Section 3.4 | Section 7, Section 8 | +----------------------+-------------+----------------------+
| map | | | | Resource-specific ED | Section 4.2 | Sections 5.1.2 and |
+----------------------+-------------+------------------------------+ | name | | 5.1.2.1 |
| Resource-specific | Section 4.2 | Section 5.1.2, | +----------------------+-------------+----------------------+
| ED name | | Section 5.1.2.1 | | Resource-specific EP | Section 4.3 | Section 5.2.3 |
+----------------------+-------------+------------------------------+ | value | | |
| Resource-specific | Section 4.3 | Section 5.2.3 | +----------------------+-------------+----------------------+
| EP value | | | | Entity Hierarchy and | Section 4.4 | Section 5.1.4 |
+----------------------+-------------+------------------------------+ | property inheritance | | |
| Entity Hierarchy | Section 4.4 | Section 5.1.4 | +----------------------+-------------+----------------------+
| and property | | | | Defining information | Sections | Sections 12.3.2 and |
| inheritance | | | | resource | 4.6 and 4.7 | 12.4 |
+----------------------+-------------+------------------------------+ +----------------------+-------------+----------------------+
| Defining | Section | Section 12.3.2, Section 12.4 |
| information | 4.6, | |
| resource | Section 4.7 | |
+----------------------+-------------+------------------------------+
Table 4: Features introduced with ALTO Entity Property Maps Table 4: Features Introduced with ALTO Entity Property Maps
Acknowledgments
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 for improving this
document, to Vijay Gurbani, ALTO WG Chair, and Martin Duke, Transport
Area Director, for their thorough review, discussions, guidance, and
shepherding, which further helped to enrich this document.
Authors' Addresses Authors' Addresses
Wendy Roome Wendy Roome
Nokia Bell Labs (Retired) Nokia Bell Labs (Retired)
124 Burlington Rd 124 Burlington Rd
Murray Hill, NJ 07974 Murray Hill, NJ 07974
United States of America United States of America
Phone: +1-908-464-6975 Phone: +1-908-464-6975
Email: wendy@wdroome.com Email: wendy@wdroome.com
skipping to change at page 63, line 4 skipping to change at line 2833
Authors' Addresses Authors' Addresses
Wendy Roome Wendy Roome
Nokia Bell Labs (Retired) Nokia Bell Labs (Retired)
124 Burlington Rd 124 Burlington Rd
Murray Hill, NJ 07974 Murray Hill, NJ 07974
United States of America United States of America
Phone: +1-908-464-6975 Phone: +1-908-464-6975
Email: wendy@wdroome.com Email: wendy@wdroome.com
Sabine Randriamasy Sabine Randriamasy
Nokia Bell Labs Nokia Bell Labs
Route de Villejust Route de Villejust
91460 NOZAY 91460 NOZAY
France France
Email: Sabine.Randriamasy@nokia-bell-labs.com Email: Sabine.Randriamasy@nokia-bell-labs.com
Y. Richard Yang Y. Richard Yang
Yale University Yale University
51 Prospect Street 51 Prospect Street
New Haven, CT 06511 New Haven, CT 06511
United States of America United States of America
Phone: +1-203-432-6400 Phone: +1-203-432-6400
Email: yry@cs.yale.edu Email: yry@cs.yale.edu
Jingxuan Jensen Zhang Jingxuan Jensen Zhang
Tongji University Tongji University
4800 Cao'An Hwy 4800 Cao'An Hwy
Shanghai Shanghai
201804 201804
China China
 End of changes. 283 change blocks. 
791 lines changed or deleted 790 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.