< draft-ietf-alto-unified-props-new-06.txt   draft-ietf-alto-unified-props-new-07.txt >
ALTO WG W. Roome ALTO WG W. Roome
Internet-Draft Nokia Bell Labs Internet-Draft S. Randriamasy
Intended status: Standards Track S. Chen Intended status: Standards Track Nokia Bell Labs
Expires: July 6, 2019 Tongji University Expires: September 12, 2019 Y. Yang
S. Randriamasy
Nokia Bell Labs
Y. Yang
Yale University Yale University
J. Zhang J. Zhang
Tongji University Tongji University
January 2, 2019 March 11, 2019
Unified Properties for the ALTO Protocol Unified Properties for the ALTO Protocol
draft-ietf-alto-unified-props-new-06 draft-ietf-alto-unified-props-new-07
Abstract Abstract
This document extends the Application-Layer Traffic Optimization This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint
properties" to domains of other entities, and by presenting those properties" to domains of other entities, and by presenting those
properties as maps, similar to the network and cost maps in ALTO. properties as maps, similar to the network and cost maps in ALTO.
Requirements Language Requirements Language
skipping to change at page 1, line 46 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 6, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 27 skipping to change at page 2, line 22
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Concepts . . . . . . . . . . . . . . . . . . 4 2. Definitions and Concepts . . . . . . . . . . . . . . . . . . 4
2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 5 2.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 5
2.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Entity Address . . . . . . . . . . . . . . . . . . . . . 5 2.4. Entity Identifier . . . . . . . . . . . . . . . . . . . . 6
2.5. Property Type and Property Name . . . . . . . . . . . . . 6 2.5. Property Type and Property Name . . . . . . . . . . . . . 6
2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 7 2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 7
2.7. Relationship with Other ALTO Resources . . . . . . . . . 7 2.7. Relationship with Other ALTO Resources . . . . . . . . . 7
3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7 3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 8
3.1. Internet Address Domains . . . . . . . . . . . . . . . . 8 3.1. Internet Address Domains . . . . . . . . . . . . . . . . 9
3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 8 3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 9
3.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 8 3.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 9
3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains . . . 8 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains . . . 9
3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 10 3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10 3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 3.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 11
3.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 10 3.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 11
3.2.4. Relationship To Internet Addresses Domains . . . . . 10 3.2.4. Relationship To Internet Addresses Domains . . . . . 11
3.3. Internet Address Properties vs. PID Properties . . . . . 10 3.3. Internet Address Properties vs. PID Properties . . . . . 11
4. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 11 4. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 11 4.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 12
4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 11 4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 12
4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 13
4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 13
5. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 13 5. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 14
5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 14
5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 13 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 14
5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 15
5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 14 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 15
6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 16 6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 17
6.1. Impact on Endpoint Property Service . . . . . . . . . . . 16 6.1. Impact on Endpoint Property Service . . . . . . . . . . . 17
6.2. Impact on Resource-Specific Properties . . . . . . . . . 16 6.2. Impact on Resource-Specific Properties . . . . . . . . . 17
6.3. Impact on the pid Property . . . . . . . . . . . . . . . 16 6.3. Impact on the pid Property . . . . . . . . . . . . . . . 17
6.4. Impact on Other Properties . . . . . . . . . . . . . . . 17 6.4. Impact on Other Properties . . . . . . . . . . . . . . . 18
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 17 7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 18
7.2. Property Definitions . . . . . . . . . . . . . . . . . . 17 7.2. Property Definitions . . . . . . . . . . . . . . . . . . 18
7.3. Information Resource Directory (IRD) . . . . . . . . . . 18 7.3. Information Resource Directory (IRD) . . . . . . . . . . 19
7.4. Property Map Example . . . . . . . . . . . . . . . . . . 20 7.4. Property Map Example . . . . . . . . . . . . . . . . . . 21
7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 21 7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 22
7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 22 7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 23
7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 23 7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 24
7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 24 7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 25
8. Security Considerations . . . . . . . . . . . . . . . . . . . 25 8. Security Considerations . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
9.1. application/alto-* Media Types . . . . . . . . . . . . . 26 9.1. application/alto-* Media Types . . . . . . . . . . . . . 27
9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 27 9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 28
9.2.1. Consistency Procedure between ALTO Address Type 9.2.1. Consistency Procedure between ALTO Address Type
Registry and ALTO Entity Domain Registry . . . . . . 27 Registry and ALTO Entity Domain Registry . . . . . . 29
9.2.2. ALTO Entity Domain Registration Process . . . . . . . 29 9.2.2. ALTO Entity Domain Registration Process . . . . . . . 30
9.3. ALTO Entity Property Type Registry . . . . . . . . . . . 30 9.3. ALTO Entity Property Type Registry . . . . . . . . . . . 31
10. Normative References . . . . . . . . . . . . . . . . . . . . 31 9.4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 10. Normative References . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 33
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", and defines the Endpoint Property attached to "endpoint addresses", and defines the Endpoint Property
Service (EPS) to allow ALTO clients to retrieve those properties. Service (EPS) to allow ALTO clients to retrieve those properties.
While useful, the EPS, as defined in [RFC7285], has at least two While useful, the EPS, as defined in [RFC7285], has at least two
limitations. limitations.
First, it only allows properties to be associated with a particular First, it only allows properties to be associated with a particular
skipping to change at page 4, line 39 skipping to change at page 4, line 35
consequence, ALTO Entity Domains defined in this document are a consequence, ALTO Entity Domains defined in this document are a
super-set of ALTO Address Types defined in [RFC7285]. Their exact super-set of ALTO Address Types defined in [RFC7285]. Their exact
relationship is specified in Section 9.2.1. relationship is specified in Section 9.2.1.
Entity domains and property names are extensible. New entity domains Entity domains and property names are extensible. New entity domains
can be defined without revising the messages defined in this can be defined without revising the messages defined in this
document, in the same way that new cost metrics and new endpoint document, in the same way that new cost metrics and new endpoint
properties can be defined without revising the messages defined in properties can be defined without revising the messages defined in
[RFC7285]. [RFC7285].
This proposal would subsume the Endpoint Property Service defined in This proposal subsumes the Endpoint Property Service defined in
[RFC7285], although that service may be retained for legacy clients [RFC7285], although that service may be retained for legacy clients
(see Section 6). (see Section 6).
2. Definitions and Concepts 2. Definitions and Concepts
2.1. Entity 2.1. Entity
The entity is a generalized concept of the endpoint defined in The entity generalizes the concept of the endpoint defined in
Section 2.1 of [RFC7285]. An entity is an object with a (possibly Section 2.1 of [RFC7285]. An entity is an object that can be an
empty) set of properties. Each entity MUST be in one and only one endpoint and is identified by its network address, but can also be an
domain, such as the IPv4 domain or the IPv6 domain, and has a unique object that has a defined mapping to a set of one or more network
address. addresses or is even not related to any network address.
Examples of eligible entities are:
o a PID, defined in [RFC7285], that has a provider defined human
readable abstract identifier and maps to a set of ipv4 and ipv6
addresses,
o an ASN number, that has a specified identifier and direct mapping
to network addresses,
o a country code, that specified in ISO 3166 format and that can be
retrieved from an IP of cellular address. As a consequence, all
endpoints are entities while not all entities are endpoints,
o a TCP/IP network flow, that has a server defined identifier and
represents in a TCP/IP 5-Tuple,
o a routing element, that specified in [RFC7921] and includes
routing capability information,
o an abstract network element, that has a server defined identifier
and represents a network node, link or their aggregation.
2.2. Entity Domain 2.2. Entity Domain
An entity domain is a set of entities. Examples of domains are the Each entity MUST be in one and only one entity domain. An entity
domain is a class of entities. Examples of entity domains are the
Internet address domains (see Section 3.1 and the PID domain (see Internet address domains (see Section 3.1 and the PID domain (see
Section 3.2). This document will define the domains precisely below. Section 3.2). The future documents can define new entity domains to
satisfy the additional requirements such as cellular network
information and routing capability exposure. But they are not in the
scope of this document.
2.3. Domain Name 2.3. Domain Name
Each entity domain has a unique name. A domain name MUST be no more Each entity domain has a unique name. A domain name MUST be no more
than 32 characters, and MUST NOT contain characters other than US- than 32 characters, and 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), hyphen ("-", U+002D), and low line ("_", U+005F). U+0061-U+007A), hyphen ("-", U+002D), and low line ("_", U+005F).
For example, the names "ipv4" and "ipv6" identify entities in the For example, the names "ipv4" and "ipv6" identify entities in the
Internet address domains (see Section 3.1). Internet address domains (see Section 3.1).
The type DomainName is used in this document to denote a JSON string The type DomainName is used in this document to denote a JSON string
with a domain name in this format. with a domain name in this format.
Domain names MUST be registered with the IANA, and the format of the Domain names MUST be registered with the IANA, and the format of the
entity addresses (see Section 2.4) in that entity domain, as well as entity addresses (see Section 2.4) in that entity domain, as well as
any hierarchical or inheritance rules (see Section 2.6) for those any hierarchical or inheritance rules (see Section 2.6) for those
entities, MUST be specified at the same time. entities, MUST be specified at the same time.
2.4. Entity Address 2.4. Entity Identifier
Each entity has a unique address of the format: Each entity has an identifier of the format:
EntityAddr ::= DomainName : DomainSpecificEntityAddr EntityId ::= DomainName : DomainSpecificEntityId
Examples from the IP domains include individual addresses such as An entity identifier uniquely identifies a particular entity within
an ALTO property map resource (see Section 4).
Examples from the IP domains include individual IP addresses such as
"ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks "ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks
such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48". such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48".
The type EntityAddr is used in this document to denote a JSON string The type EntityId is used in this document to denote a JSON string
with an entity address in this format. with an entity identifier in this format.
The format of the second part of an entity address depends on the The format of the second part of an entity identifier depends on the
entity domain, and MUST be specified when registering a new entity entity domain, and MUST be specified when registering a new entity
domain. Addresses MAY be hierarchical, and properties MAY be domain. Identifiers MAY be hierarchical, and properties MAY be
inherited based on that hierarchy. Again, the rules defining any inherited based on that hierarchy. Again, the rules defining any
hierarchy or inheritance MUST be defined when the entity domain is hierarchy or inheritance MUST be defined when the entity domain is
registered. registered.
Note that an entity address MAY have different textual Note that an entity address MAY have different textual
representations, for a given entity domain. For example, the strings representations, for a given entity domain. For example, the strings
"ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same "ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same
entity. entity.
2.5. Property Type and Property Name 2.5. Property Type and Property Name
Every entity in some domain MAY have one or more properties. Every Every entity in some domain MAY have one or more properties. Every
property MUST have a unique Property Type. property is identified by a Property Type and is specific to a
domain. Every property MUST have a unique Property Type.
This document defines property types in the domain-specific context. This document defines property types in the domain-specific
This design is to enforce that each property type MUST be registered semantics. Multiple property types with similar semantics MAY share
for a single specific entity domain. But multiple property types the same Property Name in different entity domains. But each
with the similar semantics MAY share the same Property Name in property type MUST be registered for a single specific entity domain
different entity domains. This design decision is adopted because of for the following reasons:
the following considerations:
o Some properties may only be applicable for particular entity o Some properties may only be applicable for particular entity
domains, not all. For example, the "pid" property is not domains, not all. For example, the "pid" property is not
applicable for entities in the "pid" domain. applicable for entities in the "pid" domain.
o The interpretation of the value of a property may depend on the o The interpretation of the value of a property may depend on the
entity domain. For different entity domains, not only the entity domain. For different entity domains, not only the
intended semantics but also the dependent resource types may be intended semantics but also the dependent resource types may be
totally different. For example, suppose that the "geo-location" totally different. For example, suppose that the "geo-location"
property is defined as the coordinates of a point, encoded as property is defined as the coordinates of a point, encoded as
(say) "latitude longitude [altitude]." When applied to an entity (say) "latitude longitude [altitude]." When applied to an entity
that represents a specific host computer, such as an Internet that represents a specific host computer, identified by an address
address, the property defines the host's location and has no in the ipv4 or ipv6 domain, the property defines the host's
required dependency. However, when applied to an entity in the location and has no required dependency. However, when applied to
"pid" domain, the property would indicate the location of the an entity in the "pid" domain, the property would indicate the
center of all hosts in this "pid" entity and depend on a Network location of the center of all hosts in this "pid" entity and
Map defining this "pid" entity. depend on the Network Map defining this "pid" entity.
To achieve this, each property type has a unique identifier encoded Therefore, each property type has a unique identifier encoded with
as the following format: the following format:
PropertyType ::= DomainName : PropertyName PropertyType ::= DomainName : PropertyName
The "DomainName" indicates which entity domain the property type o The "DomainName" indicates which entity domain the property type
applies to. The "PropertyName" SHOULD refer to the semantics of this applies to.
property type. It does not have to be global unique. In other
words, different property types could have the same property name o The "PropertyName" SHOULD relate to the semantics of this property
applied to different entity domains, if they have the similar type. It does not have to be globally unique. In other words,
semantics. For example, the property types "ipv4:pid" and "ipv6:pid" different property types could have the same property name applied
have the same property name "pid" applied to both "ipv4" and "ipv6" to different entity domains, if they have the similar semantics.
domains. For example, the property types "ipv4:pid" and "ipv6:pid" have the
same property name "pid" applied to both "ipv4" and "ipv6"
domains.
Property types MUST be registered with the IANA, and the intended Property types MUST be registered with the IANA, and the intended
semantics, as well as the media types of dependent resources and the semantics, as well as the media types of dependent resources and the
interpretation, MUST be specified at the same time. interpretation, MUST be specified at the same time.
2.6. Hierarchy and Inheritance 2.6. Hierarchy and Inheritance
Entities in a given domain MAY form a hierarchy based on entity Entities in a given domain MAY form a hierarchy based on entity
addresses, and introducing hierarchy allows the introduction of identifiers, and introducing hierarchy allows the introduction of
inheritance. Each entity domain MUST define its own hierarchy and inheritance. Each entity domain MUST define its own hierarchy and
inheritance rules when registered. The hierarchy and inheritance inheritance rules when registered. The hierarchy and inheritance
rule makes it possible for an entity to inherit a property value from rule makes it possible for an entity to inherit a property value from
another entity in the same domain. another entity in the same domain.
2.7. Relationship with Other ALTO Resources 2.7. Relationship with Other ALTO Resources
[RFC7285] recognizes that some properties for some entity domains MAY [RFC7285] recognizes that some properties for some entity domains MAY
be specific to an ALTO resource, such as a network map. Accordingly be specific to an ALTO resource, such as a network map. Accordingly
Section 10.8.1 of [RFC7285] defines the concept of "resource-specific Section 10.8.1 of [RFC7285] defines the concept of "resource-specific
endpoint properties", and indicates that dependency by prefixing the endpoint properties", and indicates that dependency by prefixing the
property name with the ID of the resource on which it depends. That property name with the ID of the resource on which it depends. That
document defines one resource-specific property, namely the "pid" document defines one resource-specific property, namely the "pid"
property, whose value is the name of the PID containing that endpoint property, whose value is the name of the PID containing that endpoint
in the associated network map. in the associated network map.
This document takes a different approach. Instead of defining the Because a property may be associated to more than one information
dependency by qualifying the property name, this document attaches resources within an entity domain, this document takes a different
the dependency to the entity domains. Thus each resource-specific approach as follows:
property of all entities in a specific domain depends on the same
resources; the properties of entities in another domain may depend on
another resource. For example, in a single property map, the "pid"
property of all entities in an Internet address domain MUST depend on
the same network map. Each property of all entities in the PID
domain MUST also depend on a network map; but different properties
may depend on different network maps.
Specifically, this document uses the "uses" and "dependent-vtags" o Firstly, instead of defining the dependency by prefixing the
fields defined in Sections 9.1.5 and 11.1 of [RFC7285], respectively, property name with a specific dependent resource identifier, this
to specify the preceding dependency: the "uses" field of an IRD entry document introduces a Property Type that appends a property name
providing entity domain related resources (see Property Map and to an entity domain name, and registers the dependency types for
Filtered Property Map resources below) specifies the dependent this Property Type. This gives a hint on the types of dependent
resources, and the "dependent-vtags" field specifies dependency in resources. For example, the fictitious property "pid:region"
message responses. applying to entities in the PID domain depends on the network map
in which the input PID entities have been defined; but the
fictitious property "ipv4:region" does not depend on any
information resource.
o Secondly, it sets a rule saying that in a property map, all
provided property types MUST have the same dependency types. For
example, "pid:region" and "ipv4:region" cannot be provided by an
individual property map.
o Finally, it identifies, in the IRD and Server responses, the
sequence of information resources associated to all provided
properties in a particular property map. If a property depends on
some different information resources from other properties, the
ALTO server should define a different property map to provide it.
For example, the property "ipv4:pid" provided by a particular
property map MUST depend on one and only one network map. If an
ALTO server wants to provide "ipv4:pid" for PIDs defined in both
network maps "net1" and "net2", it MUST define two individual
property maps.
To specify the aforementionned dependencies, this document uses the
"uses" and "dependent-vtags" fields defined respectively in Sections
9.1.5 and 11.1 of [RFC7285].
o the "uses" field is included in the IRD entry of a resources-
dependent information resource and specifies the dependent IRD
resource.
o the "dependent-vtags" member is used in a Server response message
to specify the dependent resource.
3. Entity Domains 3. Entity Domains
This document defines three entity domains. The definition of each This document defines three entity domains. The definition of each
entity domain below includes the following: (1) domain name, (2) entity domain below includes the following: (1) domain name, (2)
domain-specific addresses, and (3) hierarchy and inheritance domain-specific entity identifiers, and (3) hierarchy and inheritance
semantics. semantics.
3.1. Internet Address Domains 3.1. Internet Address Domains
The document defines two entity domains (IPv4 and IPv6) for Internet The document defines two entity domains (IPv4 and IPv6) for Internet
addresses. Both entity domains include individual addresses and addresses. Both entity domains include individual addresses and
blocks of addresses. Since the two domains use the same hierarchy blocks of addresses. Since the two domains use the same hierarchy
and inheritance semantics, we define the semantics together, instead and inheritance semantics, we define the semantics together, instead
of repeating for each. of repeating for each.
3.1.1. IPv4 Domain 3.1.1. IPv4 Domain
3.1.1.1. Domain Name 3.1.1.1. Domain Name
ipv4 ipv4
3.1.1.2. Domain-Specific Entity Addresses 3.1.1.2. Domain-Specific Entity Identifiers
Individual addresses are strings as specified by the IPv4Addresses Individual addresses are strings as specified by the IPv4Addresses
rule of Section 3.2.2 of [RFC3986]; blocks of addresses are prefix- rule of Section 3.2.2 of [RFC3986]; blocks of addresses are prefix-
match strings as specified in Section 3.1 of [RFC4632]. For the match strings as specified in Section 3.1 of [RFC4632]. For the
purpose of defining properties, an individual Internet address and purpose of defining properties, an individual Internet address and
the corresponding full-length prefix are considered aliases for the the corresponding full-length prefix are considered aliases for the
same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are
equivalent. equivalent.
3.1.2. IPv6 Domain 3.1.2. IPv6 Domain
3.1.2.1. Domain Name 3.1.2.1. Domain Name
ipv6 ipv6
3.1.2.2. Domain-Specific Entity Addresses 3.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]; blocks of addresses are prefix-match strings as specified [RFC5952]; blocks of addresses are prefix-match strings as specified
in Section 7 of [RFC5952]. For the purpose of defining properties, in Section 7 of [RFC5952]. For the purpose of defining properties,
an individual Internet address and the corresponding 128-bit prefix an individual Internet address and the corresponding 128-bit prefix
are considered aliases for the same entity. That is, 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 the same set of properties. have the same set of properties.
3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains
skipping to change at page 10, line 20 skipping to change at page 11, line 20
3.2. PID Domain 3.2. PID Domain
The PID domain associates property values with the PIDs in a network The PID 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. map.
3.2.1. Domain Name 3.2.1. Domain Name
pid pid
3.2.2. Domain-Specific Entity Addresses 3.2.2. Domain-Specific Entity Identifiers
The entity addresses are the PID names of the associated network map. The entity identifiers are the PID names of the associated network
map.
3.2.3. Hierarchy and Inheritance 3.2.3. Hierarchy and Inheritance
There is no hierarchy or inheritance for properties associated with There is no hierarchy or inheritance for properties associated with
PIDs. PIDs.
3.2.4. Relationship To Internet Addresses Domains 3.2.4. 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
skipping to change at page 11, line 49 skipping to change at page 12, line 49
The capabilities are defined by an object of type The capabilities are defined by an object of type
PropertyMapCapabilities: PropertyMapCapabilities:
object { object {
DomainName entity-domains<1..*>; DomainName entity-domains<1..*>;
PropertyName properties<1..*>; PropertyName properties<1..*>;
} PropertyMapCapabilities; } PropertyMapCapabilities;
where "entity-domains" is an array specifying the entity domains, and where "entity-domains" is an array specifying the entity domains, and
"properties" is an array specifying the property names returned for "properties" is an array specifying the property names returned for
entities in those domains. The semantics is that each domain in entities in those domains. The semantics is that this property map
"entity-domains" provides all properties defined in "properties". If provides all property types generated by the cross product of
a property in "properties" is NOT supported by a domain in "entity- "entity-domains" and "properties". If a property in "properties" is
domains", the server can declare different property maps to conform NOT supported by a domain in "entity-domains", the server can declare
to the semantics. different property maps to conform to the semantics.
For example, the capability {"entity-domains": ["ipv4", "ipv6"],
"properties": ["pid"]} means the property map provides both property
types "ipv4:pid" and "ipv6:pid".
4.5. Uses 4.5. Uses
The "uses" field of a property map resource in an IRD entry specifies The "uses" field of a property map resource in an IRD entry specifies
dependencies as discussed in Section 2.7. It is an array of the dependencies as discussed in Section 2.7. It is an array of the
resource ID(s) of the resource(s) that properties of entities in resource ID(s) of the resource(s) that properties of entities in
domains specified in "entity-domains" depend on. domains specified in "entity-domains" depend on.
In a single property map, every property value of every entity In a single property map, every property value of every entity
depends on the same array of resources. Thus, if properties depend depends on the same array of resources. Thus, if properties
on different resources arrays would be provided, they MUST be split depending on different resources arrays would be provided, they MUST
into different property maps. be split into different property maps.
Note that according to [RFC7285], a legacy ALTO server with two Note that according to [RFC7285], a legacy ALTO server with two
network maps, with resource IDs "net1" and "net2", could offer a network maps, with resource IDs "net1" and "net2", could offer a
single Endpoint Property Service for the two properties "net1.pid" single Endpoint Property Service for the two properties "net1.pid"
and "net2.pid". An ALTO server which supports the property map and "net2.pid". An ALTO server which supports the property map
resource defined in this document, would, instead, offer two resource defined in this document, would, instead, offer two
different property maps for the "pid" property, one depending on different property maps for the "pid" property, one depending on
"net1", and the other on "net2". "net1", and the other on "net2".
4.6. Response 4.6. Response
skipping to change at page 12, line 42 skipping to change at page 13, line 46
the order MUST be consistent with the "uses" field of this property the order MUST be consistent with the "uses" field of this property
map resource. The data component of a property map response is named map resource. The data component of a property map response is named
"property-map", which is a JSON object of type PropertyMapData, "property-map", which is a JSON object of type PropertyMapData,
where: where:
object { object {
PropertyMapData property-map; PropertyMapData property-map;
} InfoResourceProperties : ResponseEntityBase; } InfoResourceProperties : ResponseEntityBase;
object-map { object-map {
EntityAddr -> EntityProps; EntityId -> EntityProps;
} PropertyMapData; } PropertyMapData;
object { object {
PropertyName -> JSONValue; PropertyName -> JSONValue;
} EntityProps; } EntityProps;
The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. The ResponseEntityBase type is defined in Section 8.4 of [RFC7285].
Specifically, a PropertyMapData object has one member for each entity Specifically, a PropertyMapData object has one member for each entity
in the property map. The entity's properties are encoded in the in the property map. The entity's properties are encoded in the
skipping to change at page 13, line 48 skipping to change at page 14, line 50
5.3. Accept Input Parameters 5.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:
object { object {
EntityAddr entities<1..*>; EntityId entities<1..*>;
PropertyName properties<1..*>; PropertyName properties<1..*>;
} ReqFilteredPropertyMap; } ReqFilteredPropertyMap;
with fields: with fields:
entities: List of entity addresses for which the specified entities: List of entity identifiers for which the specified
properties are to be returned. The ALTO server MUST interpret properties are to be returned. The ALTO server MUST interpret
entries appearing multiple times as if they appeared only once. entries appearing multiple times as if they appeared only once.
The domain of each entity MUST be included in the list of entity The domain of each entity MUST be included in the list of entity
domains in this resource's "capabilities" field (see Section 5.4). domains in this resource's "capabilities" field (see Section 5.4).
properties: List of properties to be returned for each entity. Each properties: List of properties to be returned for each entity. Each
specified property MUST be included in the list of properties in specified property MUST be included in the list of properties in
this resource's "capabilities" field (see Section 5.4). The ALTO this resource's "capabilities" field (see Section 5.4). The ALTO
server MUST interpret entries appearing multiple times as if they server MUST interpret entries appearing multiple times as if they
appeared only once. appeared only once.
skipping to change at page 14, line 42 skipping to change at page 15, line 44
5.6. Response 5.6. 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 as Specifically, a filtered property map request can be invalid as
follows: follows:
o An entity address in "entities" in the request is invalid if: o An entity identifiers in "entities" in the request is invalid if:
* The domain of this entity is not defined in the "entity-domain- * The domain of this entity is not defined in the "entity-domain-
types" capability of this resource in the IRD; types" capability of this resource in the IRD;
* The entity address is an invalid address in the entity domain. * The entity identifier is an invalid identifier in the entity
domain.
A valid entity address is never an error, even if this filtered A valid entity identifier is never an error, even if this filtered
property map resource does not define any properties for it. property map resource does not define any properties for it.
If an entity address in "entities" in the request is invalid, the If an entity identifier in "entities" in the request is invalid,
ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined the ALTO server MUST return an "E_INVALID_FIELD_VALUE" error
in Section 8.5.2 of [RFC7285], and the "value" field of the error defined in Section 8.5.2 of [RFC7285], and the "value" field of
message SHOULD indicate this entity address. the error message SHOULD indicate this entity identifier.
o A property name in "properties" in the request is invalid if this o A property name in "properties" in the request is invalid if this
property name is not defined in the "property-types" capability of property name is not defined in the "property-types" capability of
this resource in the IRD. this resource in the IRD.
It is not an error that a filtered property map resource does not It is not an error that a filtered property map resource does not
define a requested property's value for a particular entity. In define a requested property's value for a particular entity. In
this case, the ALTO server MUST omit that property from the this case, the ALTO server MUST omit that property from the
response for that endpoint. response for that endpoint.
skipping to change at page 15, line 33 skipping to change at page 16, line 36
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 4.6), except that: (see Section 4.6), except that:
o The "dependent-vtags" field in its "meta" field only includes the o The "dependent-vtags" field in its "meta" field only includes the
version tags of resources on which the requested properties of the version tags of resources on which the requested properties of the
entity domains depend, and the order MUST be consistent with the entity domains depend, and the order MUST be consistent with the
"uses" field of this filtered property map resource. "uses" field of this filtered property map resource.
o It only includes the entities and properties requested by the o It only includes the entities and properties requested by the
client. If an entity in the request is an address block (e.g., an client. If an entity in the request is an identifier block (e.g.,
"ipv4" or "ipv6" entity), the response MUST cover properties for an "ipv4" or "ipv6" entity), the response MUST cover properties
all addresses in this block. for all identifiers in this block.
It is important that the filtered property map response MUST include It is important that the filtered property map response MUST include
all inherited property values for the requested entities and all the all inherited property values for the requested entities and all the
entities which are able to inherit property values from them. To entities which are able to inherit property values from them. To
achieve this goal, the ALTO server MAY follow three rules: achieve this goal, the ALTO server MAY follow three rules:
o If a property for a requested entity is inherited from another o If a property for a requested entity is inherited from another
entity not included in the request, the response SHOULD include entity not included in the request, the response SHOULD include
this property for the requested entity. For example, A full this property for the requested entity. For example, A full
property map may skip a property P for an entity A (e.g., property map may skip a property P for an entity A (e.g.,
skipping to change at page 17, line 16 skipping to change at page 18, line 18
definition of the "pid" property as follows. definition of the "pid" property as follows.
First, the name of the property is simply "pid"; the name is not First, the name of the property is simply "pid"; the name is not
prefixed with the resource ID of a network map. The "uses" prefixed with the resource ID of a network map. The "uses"
capability of the property map indicates the associated network map. capability of the property map indicates the associated network map.
This implies that a property map can only return the "pid" property This implies that a property map can only return the "pid" property
for one network map; if an ALTO server provides several network maps, for one network map; if an ALTO server provides several network maps,
it MUST provide a Property Map for each of the network maps. it MUST provide a Property Map for each of the network maps.
Second, a client MAY request the "pid" property for a block of Second, a client MAY request the "pid" property for a block of
addresses. An ALTO server determines the value of "pid" for an Internet addresses. An ALTO server determines the value of "pid" for
address block C as the rules defined in Section 5.6. an address block C as the rules defined in Section 5.6.
Note that although an ALTO server MAY provide a GET-mode property map Note that although an ALTO server MAY provide a GET-mode property map
which returns the entire map for the "pid" property, there is no need which returns the entire map for the "pid" property, there is no need
to do so, because that map is simply the inverse of the network map. to do so, because that map is simply the inverse of the network map.
6.4. Impact on Other Properties 6.4. Impact on Other Properties
In general, there should be little or no impact on other previously In general, there should be little or no impact on other previously
defined properties. The only consideration is that properties can defined properties. The only consideration is that properties can
now be defined on blocks of addresses, rather than just individual now be defined on blocks of identifiers, rather than just individual
addresses, which might change the semantics of a property. identifiers, which might change the semantics of a property.
7. Examples 7. Examples
7.1. Network Map 7.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:
defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0
pid1: ipv4:192.0.2.0/25 pid1: ipv4:192.0.2.0/25
pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28
skipping to change at page 27, line 30 skipping to change at page 28, line 30
Change controller: Internet Engineering Task Force Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org). (mailto:iesg@ietf.org).
9.2. ALTO Entity Domain Registry 9.2. ALTO Entity Domain Registry
This document requests IANA to create and maintain the "ALTO Entity This document requests IANA to create and maintain the "ALTO Entity
Domain Registry", listed in Table 2. Domain Registry", listed in Table 2.
+------------+----------------+------------------+------------------+ +------------+----------------+------------------+------------------+
| Identifier | Entity Address | Hierarchy & | Mapping to ALTO | | Identifier | Entity | Hierarchy & | Mapping to ALTO |
| | Encoding | Inheritance | Address Type | | | Identifier | Inheritance | Address Type |
| | Encoding | | |
+------------+----------------+------------------+------------------+ +------------+----------------+------------------+------------------+
| ipv4 | See | See | Yes | | ipv4 | See | See | Yes |
| | Section 3.1.1 | Section 3.1.3 | | | | Section 3.1.1 | Section 3.1.3 | |
| ipv6 | See | See | Yes | | ipv6 | See | See | Yes |
| | Section 3.1.2 | Section 3.1.3 | | | | Section 3.1.2 | Section 3.1.3 | |
| pid | See | None | No | | pid | See | None | No |
| | Section 3.2 | | | | | Section 3.2 | | |
+------------+----------------+------------------+------------------+ +------------+----------------+------------------+------------------+
Table 2: ALTO Entity Domains. Table 2: ALTO Entity Domains.
skipping to change at page 28, line 4 skipping to change at page 29, line 11
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 domains. Second, it states the identifiers referring to ALTO entity domains. Second, it states the
requirements for allocated entity domains. requirements for allocated entity domains.
9.2.1. Consistency Procedure between ALTO Address Type Registry and 9.2.1. Consistency Procedure between ALTO Address Type Registry and
ALTO Entity Domain Registry ALTO Entity Domain Registry
One potential issue of introducing the "ALTO Entity Domain Registry" One potential issue of introducing the "ALTO Entity Domain Registry"
is its relationship with the "ALTO Address Types Registry" already is its relationship with the "ALTO Address Types Registry" already
defined in Section 14.4 of [RFC7285]. In particular, the entity defined in Section 14.4 of [RFC7285]. In particular, the entity
address of an entity domain registered in the "ALTO Entity Domain identifier of an entity domain registered in the "ALTO Entity Domain
Registry" MAY match an address type defined in "ALTO Address Type Registry" MAY match an address type defined in "ALTO Address Type
Registry". It is necessary to precisely define and guarantee the Registry". It is necessary to precisely define and guarantee the
consistency between "ALTO Address Type Registry" and "ALTO Entity consistency between "ALTO Address Type Registry" and "ALTO Entity
Domain Registry". Domain Registry".
We define that the ALTO Entity Domain Registry is consistent with We define that the ALTO Entity Domain Registry is consistent with
ALTO Address Type Registry if two conditions are satisfied: ALTO Address Type Registry if two conditions are satisfied:
o When an address type is already or able to be registered in the o When an address type is already or able to be registered in the
ALTO Address Type Registry [RFC7285], the same identifier MUST be ALTO Address Type Registry [RFC7285], the same identifier MUST be
used when a corresponding entity domain is registered in the ALTO used when a corresponding entity domain is registered in the ALTO
Entity Domain Registry. Entity Domain Registry.
o If an ALTO entity domain has the same identifier as an ALTO o If an ALTO entity domain has the same identifier as an ALTO
address type, their addresses encoding MUST be compatible. address type, their addresses encoding 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 in a future document: before registering a new ALTO entity domain in a future document:
o Whether the ALTO Address Type Registry contains an address type o Whether the ALTO Address Type Registry contains an address type
that can be used as an entity address for the candidate domain that can be used as an entity identifier for the candidate domain
identifier. This has been done for the identifiers "ipv4" and identifier. This has been done for the identifiers "ipv4" and
"ipv6" in Table 2. "ipv6" in Table 2.
o Whether the candidate entity address of the entity domain is able o Whether the candidate entity identifier of the entity domain is
to be an endpoint address, as defined in Sections 2.1 and 2.2 of able to be an endpoint address, as defined in Sections 2.1 and 2.2
[RFC7285]. of [RFC7285].
When a new ALTO entity domain is registered, the consistency with the When a new ALTO entity domain is registered, the consistency with the
ALTO Address Type Registry MUST be ensured by the following ALTO Address Type Registry MUST be ensured by the following
procedure: procedure:
o Test: Do corresponding entity addresses match a known "network" o Test: Do corresponding entity identifiers match a known "network"
address type? address type?
* If yes (e.g., cell, MAC or socket addresses): * If yes (e.g., cell, MAC or socket addresses):
+ Test: Is such an address type present in the ALTO Address + Test: Is such an address type present in the ALTO Address
Type Registry? Type Registry?
- If yes: Set the new ALTO entity domain identifier to be - If yes: Set the new ALTO entity domain identifier to be
the found ALTO address type identifier. the found ALTO address type identifier.
- If no: Define a new ALTO entity domain identifier and use - If no: Define a new ALTO entity domain identifier and use
it to register a new address type in the ALTO Address it to register a new address type in the ALTO Address
Type Registry following Section 14.4 of [RFC7285]. Type Registry following Section 14.4 of [RFC7285].
+ Use the new ALTO entity domain identifier to register a new + Use the new ALTO entity domain identifier to register a new
ALTO entity domain in the ALTO Entity Domain Registry ALTO entity domain in the ALTO Entity Domain Registry
following Section 9.2.2 of this document. following Section 9.2.2 of this document.
skipping to change at page 29, line 19 skipping to change at page 30, line 25
* 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 registration as described in the ALTO Entity Domain registration as described in
Section 9.2.2. Section 9.2.2.
9.2.2. ALTO Entity Domain Registration Process 9.2.2. ALTO Entity Domain Registration Process
New ALTO entity domains are assigned after IETF Review [RFC5226] to New ALTO entity domains are assigned after IETF Review [RFC5226] to
ensure that proper documentation regarding the new ALTO entity ensure that proper documentation regarding the new ALTO entity
domains and their security considerations has been provided. RFCs domains and their security considerations has been provided. RFCs
defining new entity domains SHOULD indicate how an entity in a defining new entity domains SHOULD indicate how an entity in a
registered domain is encoded as an EntityAddr, and, if applicable, registered domain is encoded as an EntityId, and, if applicable, the
the rules defining the entity hierarchy and property inheritance. rules defining the entity hierarchy and property inheritance.
Updates and deletions of ALTO entity domains follow the same Updates and deletions of ALTO entity domains follow the same
procedure. procedure.
Registered ALTO entity domain identifiers MUST conform to the Registered ALTO entity domain identifiers MUST conform to the
syntactical requirements specified in Section 2.3. Identifiers are syntactical requirements specified in Section 2.3. 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 registry MUST include Requests to the IANA to add a new value to the registry MUST include
the following information: the following information:
o Identifier: The name of the desired ALTO entity domain. o Identifier: The name of the desired ALTO entity domain.
o Entity Address Encoding: The procedure for encoding the address of o Entity Identifier Encoding: The procedure for encoding the
an entity of the registered type as an EntityAddr (see identifier of an entity of the registered type as an EntityId (see
Section 2.4). If corresponding entity addresses of an entity Section 2.4). If corresponding entity identifiers of an entity
domain match a known "network" address type, the Entity Address domain match a known "network" address type, the Entity Identifier
Encoding of this domain identifier MUST include both Address Encoding of this domain identifier MUST include both Address
Encoding and Prefix Encoding of the same identifier registered in Encoding and Prefix Encoding of the same identifier registered in
the ALTO Address Type Registry [RFC7285]. For the purpose of the ALTO Address Type Registry [RFC7285]. For the purpose of
defining properties, an individual entity address and the defining properties, an individual entity identifier and the
corresponding full-length prefix MUST be considered aliases for corresponding full-length prefix MUST be considered aliases for
the same entity. the same entity.
o Hierarchy: If the entities form a hierarchy, the procedure for o Hierarchy: If the entities form a hierarchy, the procedure for
determining that hierarchy. determining that hierarchy.
o Inheritance: If entities can inherit property values from other o Inheritance: If entities can inherit property values from other
entities, the procedure for determining that inheritance. entities, the procedure for determining that inheritance.
o Mapping to ALTO Address Type: A boolean value to indicate if the o Mapping to ALTO Address Type: A boolean value to indicate if the
entity domain can be mapped to the ALTO address type with the same entity domain can be mapped to the ALTO address type with the same
identifier. identifier.
o Security Considerations: In some usage scenarios, entity addresses o Security Considerations: In some usage scenarios, entity
carried in ALTO Protocol messages may reveal information about an identifiers carried in ALTO Protocol messages may reveal
ALTO client or an ALTO service provider. Applications and ALTO information about an ALTO client or an ALTO service provider.
service providers using addresses of the registered type should be Applications and ALTO service providers using addresses of the
made aware of how (or if) the addressing scheme relates to private registered type should be made aware of how (or if) the addressing
information and network proximity. scheme relates to private information and network proximity.
This specification requests registration of the identifiers "ipv4", This specification requests registration of the identifiers "ipv4",
"ipv6" and "pid", as shown in Table 2. "ipv6" and "pid", as shown in Table 2.
9.3. ALTO Entity Property Type Registry 9.3. ALTO Entity Property Type Registry
This document requests IANA to create and maintain the "ALTO Entity This document requests IANA to create and maintain the "ALTO Entity
Property Type Registry", listed in Table 3. Property Type Registry", listed in Table 3.
To distinguish with the "ALTO Endpoint Property Type Registry", each To distinguish with the "ALTO Endpoint Property Type Registry", each
skipping to change at page 31, line 16 skipping to change at page 32, line 22
o Dependencies and Interpretation: Dependent ALTO resources MAY be o Dependencies and Interpretation: Dependent ALTO resources MAY be
required by ALTO clients to interpret ALTO entity properties. required by ALTO clients to interpret ALTO entity properties.
Hence, a document defining a new type SHOULD provide a sequence of Hence, a document defining a new type SHOULD provide a sequence of
media types in which the dependent ALTO resources are and the media types in which the dependent ALTO resources are and the
guidance how ALTO clients use them to interpret the property. guidance how ALTO clients use them to interpret the property.
This specification requests registration of the identifiers This specification requests registration of the identifiers
"ipv4:pid" and "ipv6:pid", as shown in Table 3. "ipv4:pid" and "ipv6:pid", as shown in Table 3.
9.4. Acknowledgments
The authors would like to thank discussions with Kai Gao, Qiao Xiang,
Shawn Lin, Xin Wang, Danny Perez, and Vijay Gurbani. The authors
thank Dawn Chen (Tongji University), and Shenshen Chen (Tongji/Yale
University) for their contributions to earlier drafts.
10. Normative References 10. Normative References
[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,
skipping to change at page 32, line 5 skipping to change at page 33, line 20
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
2014, <https://www.rfc-editor.org/info/rfc7159>. 2014, <https://www.rfc-editor.org/info/rfc7159>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S.,
Previdi, S., Roome, W., Shalunov, S., and R. Woundy, Previdi, S., Roome, W., Shalunov, S., and R. Woundy,
"Application-Layer Traffic Optimization (ALTO) Protocol", "Application-Layer Traffic Optimization (ALTO) Protocol",
RFC 7285, DOI 10.17487/RFC7285, September 2014, RFC 7285, DOI 10.17487/RFC7285, September 2014,
<https://www.rfc-editor.org/info/rfc7285>. <https://www.rfc-editor.org/info/rfc7285>.
[RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T.
Nadeau, "An Architecture for the Interface to the Routing
System", RFC 7921, DOI 10.17487/RFC7921, June 2016,
<https://www.rfc-editor.org/info/rfc7921>.
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
USA USA
Phone: +1-908-464-6975 Phone: +1-908-464-6975
Email: wendy@wdroome.com Email: wendy@wdroome.com
Shiwei Dawn Chen
Tongji University
4800 Caoan Road
Shanghai 201804
China
Email: dawn_chen_f@hotmail.com
Sabine Randriamasy Sabine Randriamasy
Nokia Bell Labs Nokia Bell Labs
Route de Villejust Route de Villejust
NOZAY 91460 NOZAY 91460
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
USA USA
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
 End of changes. 57 change blocks. 
176 lines changed or deleted 237 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/