idnits 2.17.1 draft-ietf-alto-unified-props-new-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC7285]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 404 has weird spacing: '...esource doma...' == Line 1015 has weird spacing: '...rtyName prop...' == Line 1194 has weird spacing: '...country stat...' -- The document date (September 4, 2019) is 1695 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Downref: Normative reference to an Informational RFC: RFC 7921 Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO WG W. Roome 3 Internet-Draft S. Randriamasy 4 Intended status: Standards Track Nokia Bell Labs 5 Expires: March 7, 2020 Y. Yang 6 Yale University 7 J. Zhang 8 Tongji University 9 K. Gao 10 Sichuan University 11 September 4, 2019 13 Unified Properties for the ALTO Protocol 14 draft-ietf-alto-unified-props-new-09 16 Abstract 18 This document extends the Application-Layer Traffic Optimization 19 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint 20 properties" to generic types of entities, and by presenting those 21 properties as maps, similar to the network and cost maps in 22 [RFC7285]. 24 Requirements Language 26 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 27 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 28 document are to be interpreted as described in RFC 2119 [RFC2119]. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 7, 2020. 47 Copyright Notice 49 Copyright (c) 2019 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (https://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 65 2. Overview: Basic Concepts . . . . . . . . . . . . . . . . . . 6 66 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 6 67 2.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 6 68 2.3. Property Map . . . . . . . . . . . . . . . . . . . . . . 7 69 2.4. Information Resource . . . . . . . . . . . . . . . . . . 7 70 2.5. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 7 71 2.5.1. Resource-Specific Entity Domain . . . . . . . . . . . 7 72 2.5.2. Relationship between Entity and Entity Domain . . . . 8 73 2.5.3. Aggregated Entity Domain . . . . . . . . . . . . . . 8 74 2.5.4. Resource-Specific Entity Property . . . . . . . . . . 9 75 2.6. Scope of Property Map . . . . . . . . . . . . . . . . . . 9 76 2.7. Entity Hierarchy and Property Inheritance . . . . . . . . 10 77 3. Protocol Specification: Basic Data Type . . . . . . . . . . . 10 78 3.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 10 79 3.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 10 80 3.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 11 81 3.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 11 82 3.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 12 83 3.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 12 84 3.2.1. Entity Property Type . . . . . . . . . . . . . . . . 12 85 3.2.2. Entity Property Name . . . . . . . . . . . . . . . . 13 86 3.3. Information Resource Export . . . . . . . . . . . . . . . 14 87 3.3.1. Resource-Specific Entity Domain Export . . . . . . . 14 88 3.3.2. Entity Property Mapping Export . . . . . . . . . . . 14 89 4. Entity Domain Types . . . . . . . . . . . . . . . . . . . . . 14 90 4.1. Internet Address Domain Types . . . . . . . . . . . . . . 15 91 4.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 15 92 4.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 15 93 4.1.3. Hierarchy and Inheritance of Internet Address Domains 15 94 4.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 17 95 4.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 17 96 4.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 17 97 4.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 17 98 4.2.4. Relationship To Internet Addresses Domains . . . . . 17 99 4.3. Internet Address Properties vs. PID Properties . . . . . 17 100 5. Entity Domains and Property Mappings in Information Resources 18 101 5.1. Network Map Resource . . . . . . . . . . . . . . . . . . 18 102 5.1.1. Resource-Specific Entity Domain . . . . . . . . . . . 18 103 5.1.2. Entity Property Mapping . . . . . . . . . . . . . . . 18 104 5.2. Endpoint Property Resource . . . . . . . . . . . . . . . 19 105 5.2.1. Resource-Specific Entity Domain . . . . . . . . . . . 19 106 5.2.2. Entity Property Mapping . . . . . . . . . . . . . . . 19 107 5.3. Property Map Resource . . . . . . . . . . . . . . . . . . 19 108 6. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 19 109 6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 19 110 6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 20 111 6.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 20 112 6.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 20 113 6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 20 114 6.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 20 115 7. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 22 116 7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 22 117 7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 22 118 7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 22 119 7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 23 120 7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 23 121 7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 23 122 8. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 25 123 8.1. Impact on Endpoint Property Service . . . . . . . . . . . 25 124 8.2. Impact on Resource-Specific Properties . . . . . . . . . 25 125 8.3. Impact on Other Properties . . . . . . . . . . . . . . . 25 126 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 127 9.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 25 128 9.2. Property Definitions . . . . . . . . . . . . . . . . . . 26 129 9.3. Information Resource Directory (IRD) . . . . . . . . . . 27 130 9.4. Property Map Example . . . . . . . . . . . . . . . . . . 29 131 9.5. Filtered Property Map Example #1 . . . . . . . . . . . . 30 132 9.6. Filtered Property Map Example #2 . . . . . . . . . . . . 31 133 9.7. Filtered Property Map Example #3 . . . . . . . . . . . . 32 134 9.8. Filtered Property Map Example #4 . . . . . . . . . . . . 33 135 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 136 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 137 11.1. application/alto-* Media Types . . . . . . . . . . . . . 35 138 11.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 36 139 11.2.1. Consistency Procedure between ALTO Address Type 140 Registry and ALTO Entity Domain Type Registry . . . 37 141 11.2.2. ALTO Entity Domain Type Registration Process . . . . 38 142 11.3. ALTO Entity Property Type Registry . . . . . . . . . . . 39 143 11.4. ALTO Resource-Specific Entity Domain Registries . . . . 40 144 11.4.1. Network Map . . . . . . . . . . . . . . . . . . . . 40 145 11.4.2. Endpoint Property . . . . . . . . . . . . . . . . . 40 146 11.5. ALTO Resource Entity Property Mapping Registries . . . . 40 147 11.5.1. Network Map . . . . . . . . . . . . . . . . . . . . 41 148 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 41 149 13. Normative References . . . . . . . . . . . . . . . . . . . . 41 150 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 152 1. Introduction 154 The ALTO protocol [RFC7285] introduces the concept of "properties" 155 attached to "endpoint addresses", and defines the Endpoint Property 156 Service (EPS) to allow ALTO clients to retrieve those properties. 157 While useful, the EPS, as defined in [RFC7285], has at least three 158 limitations. 160 First, the EPS allows properties to be associated with only endpoints 161 which are identified by individual communication addresses like IPv4 162 and IPv6 addresses. It is reasonable to think that collections of 163 endpoints, as defined by CIDRs [RFC4632] or PIDs, may also have 164 properties. Furthermore, recent ALTO use cases show that properties 165 of network flows [RFC7011] and routing elements [RFC7921] are also 166 very useful. Since the EPS cannot be extended to those generic 167 entities, new services, with new request and response messages, would 168 have to be defined for them. 170 Second, the EPS only allows endpoints identified by global 171 communication addresses. However, many other generic entities like 172 PIDs may not have global identifiers. Even for Internet addresses, 173 there may be some local IP addresses and anycast IP addresses which 174 are also not global unique. 176 Third, the EPS is only defined as a POST-mode service. Clients must 177 request the properties for an explicit set of endpoint addresses. By 178 contrast, [RFC7285] defines a GET-mode cost map resource which 179 returns all available costs, so a client can get a full set of costs 180 once, and then processes costs lookups without querying the ALTO 181 server. [RFC7285] does not define a similar service for endpoint 182 properties. At first a map of endpoint properties might seem 183 impractical, because it could require enumerating the property value 184 for every possible endpoint. But in practice, it is highly unlikely 185 that properties will be defined for every endpoint address. It is 186 much more likely that properties may be defined for only a subset of 187 endpoint addresses, and the specification of properties uses an 188 aggregation representation to allow enumeration. This is 189 particularly true if blocks of endpoint addresses with a common 190 prefix (e.g., a CIDR) have the same value for a property. Entities 191 in other domains may very well allow aggregated representation and 192 hence be enumerable as well. 194 This document specifies a new approach for defining and retrieving 195 ALTO properties to address the three limitations: 197 o This document addresses the first limitation by introducing a 198 generic concept called ALTO Entity which is a generalization of an 199 endpoint to represent a PID, a network element, a cell in a 200 cellular network, or other physical or logical objects used by 201 ALTO. Each entity is included by a collection called ALTO Entity 202 Domain. And each entity domain includes only one type of 203 entities. Thus, each entity domain also has a type to indicate 204 the type of entities in it. 206 o Additionally, this document addresses the second limitation by 207 using resource-specific entity domains. A resource-specific 208 entity domain is an entity domain exported by an existing ALTO 209 information resource. And a resource-specific entity domain is 210 named by its type and the resource id of the ALTO information 211 resource which exports it. As each resource-specific entity 212 domain name is unique, an entity can be uniquely identified by the 213 name of a resource-specific entity domain and its domain-specific 214 identifier. 216 o Finally, this document addresses the third limitation by defining 217 two new types of ALTO information resources, namely Property Map 218 (see Section 6) and Filtered Property Map (see Section 7). The 219 former is a GET-mode resource which returns the property values 220 for all entities in some entity domains, and is analogous to a 221 network map or a cost map in [RFC7285]. The latter is a POST-mode 222 resource which returns the values for a set of properties and 223 entities requested by the client, and is analogous to a filtered 224 network map or a filtered cost map. 226 This approach is extensible, because new entity domain types can be 227 defined without revising the protocol specification defined in this 228 document, in the same way that new cost metrics and new endpoint 229 properties can be defined without revising the protocol specification 230 defined in [RFC7285]. 232 This document subsumes the Endpoint Property Service defined in 233 [RFC7285], although that service may be retained for legacy clients 234 (see Section 8). 236 2. Overview: Basic Concepts 238 Before we define the specification of unified properties, there are 239 several basic concepts which we need to introduce. 241 2.1. Entity 243 The entity concept generalizes the concept of the endpoint defined in 244 Section 2.1 of [RFC7285]. An entity is an object that can be an 245 endpoint and is identified by its network address, but can also be an 246 object that has a defined mapping to a set of one or more network 247 addresses or is even not related to any network address. 249 Examples of eligible entities are: 251 o a PID, defined in [RFC7285], that has a provider defined human 252 readable abstract identifier defined by a ALTO network map, which 253 maps a PID to a set of ipv4 and ipv6 addresses; 255 o an autonomous system (AS), that has an AS number (ASN) as its 256 identifier and maps to a set of ipv4 and ipv6 addresses; 258 o a region representing a country, that is identified by its country 259 code defined by ISO 3166 and maps to a set of cellular addresses; 261 o a TCP/IP network flow, that has a server defined identifier 262 consisting of the defining TCP/IP 5-Tuple, , which is an example 263 that all endpoints are entities while not all entities are 264 endpoints; 266 o a routing element, that is specified in [RFC7921] and includes 267 routing capability information; 269 o an abstract network element, that has a server defined identifier 270 and represents a network node, link or their aggregation. 272 2.2. Entity Property 274 An entity property defines a property of an entity. It is similar to 275 the endpoint property defined by Section 7.1 of [RFC7285], but can be 276 general besides network-aware. 278 For example, 280 o an "ipv4" entity may have a property whose value is an Autonomous 281 System (AS) number indicating the AS which this IPv4 address is 282 owned by; 284 o a "pid" entity may have a property which indicates the central 285 geographical location of endpoints included by it. 287 2.3. Property Map 289 An ALTO property map provides a set of properties for a set of 290 entities. These entities may be in different types. For example, an 291 ALTO property map may define the ASN property for both "ipv4" and 292 "ipv6" entities. 294 2.4. Information Resource 296 This document uses the same definition of the information resource as 297 defined by [RFC7285]. Each information resource usually has a JSON 298 format representation following a specific schema defined by its 299 media type. 301 For example, an ALTO network map resource is represented by a JSON 302 objectof type InfoResourceNetworkMap defined by the media type 303 "application/alto-networkmap+json". 305 2.5. Entity Domain 307 An entity domain defines a set of entities in the same type. This 308 type is also called the type of this entity domain. 310 Using entity domains, an ALTO property map can indicate which 311 entities the ALTO client can query to get their properties. 313 2.5.1. Resource-Specific Entity Domain 315 To define an entity domain, one naive solution is to enumerate all 316 entities in this entity domain. But it is inefficient when the size 317 of the entity domain is large. 319 To avoid enumerating all entities, this document introduces an 320 approach called "Resource-Specific Entity Domain" to define entity 321 domains: 323 Each information resource may define several types of entity domains. 324 And for each type of entity domain, an information resource can 325 define at most one entity domain. For example, an ALTO netowrk map 326 resource can define an IPv4 domain, an IPv6 domain and a pid domain. 327 In this document, these entity domains are called resource-specific 328 entity domains. An ALTO property map only need to indicate which 329 types of entity domain defined by which information resources can be 330 queried, the ALTO client will know which entities are effective to be 331 queried. 333 2.5.2. Relationship between Entity and Entity Domain 335 In this document, an entity is owned by exact one entity domain. It 336 requires that when an ALTO client or server references an entity, it 337 must indicate its entity domain explicitly. Even two entities in two 338 different entity domains may reflect to the same physical or logical 339 object, we treat them as different entities. 341 Because of this rule, although the resource-specific entity domain 342 approach has no ambiguity, it may introduce redundancy. 344 2.5.3. Aggregated Entity Domain 346 Two entities in two different resource-specific entity domains may 347 reflect to the same physical or logical object. For example, the 348 IPv4 entity "192.0.2.34" in the IPv4 domain of the network map 349 "netmap1" and the IPv4 entity "192.0.2.34" in the IPv4 domain of the 350 network map "netmap2" should indicate the same Internet endpoint 351 addressed by the IPv4 address "192.0.2.34". 353 Each entity in each resource-specific entity domain may only have 354 part of properties of its associated physical or logical object. For 355 example, the IPv4 entity in the IPv4 domain of the network map 356 "netmap1" only has the PID property defined by "netmap1"; same to the 357 IPv4 entity in the IPv4 domain of the network map "netmap2". If the 358 ALTO client wants to get the complete properties, using the resource- 359 specific entity domain, the ALTO client has to query the IPv4 entity 360 "192.0.2.34" twice. 362 To simplify the query process of the ALTO client, this document 363 introduces the concept "Aggregated Entity Domain". An aggregated 364 entity domain defines a union set of entities coming from multiple 365 resource-specific entity domains in the same type. An entity in the 366 aggregated entity domain inherits all properties defined for its 367 associated entity in each associated resource-specific entity 368 domains. For example, the IPv4 entity "192.0.2.34" in the aggregated 369 entity domain between the IPv4 domain of "netmap1" and the IPv4 370 domain of "netmap2" has PID properties defined by both "netmap1" and 371 "netmap2". 373 Note that some resource-specific entity domains may not be able to be 374 aggregated even if they are in the same type. For example, a 375 property map "propmap1" may define the "asn" property on both PID 376 domains "netmap1.pid" and "netmap2.pid". But the PID "pid1" in 377 "netmap1.pid" and the PID with the same name in "netmap2.pid" have 378 different "asn" property values. It does not make sense to define an 379 aggregated PID domain between "netmap1.pid" and "netmap2.pid" to 380 provide the "propmap1.asn" property because it is ambiguous. 382 2.5.4. Resource-Specific Entity Property 384 According to the example of the aggregated entity domain, an entity 385 may have multiple properties in the same type but associated to 386 different information resources. To distinguish them, this document 387 uses the same approach proposed by Section 10.8.1 of [RFC7285], which 388 is called "Resource-Specific Entity Property". 390 2.6. Scope of Property Map 392 Using entity domains to organize entities, an ALTO property map 393 resource actually provides a set of properties for some entity 394 domains. If we ignore the syntax sugar of the aggregated entity 395 domain, we can consider an ALTO property map resource just provides a 396 set of (ri, di) => (ro, po) mappings, where (ri, di) means a 397 resource-specific entity domain of type di defined by the information 398 resource ri, and (ro, po) means a resource-specific entity property 399 po defined by the information resource ro. 401 For each (ri, di) => (ro, po) mapping, the scope of an ALTO property 402 map resource must be one of cases in the following diagram: 404 domain.resource domain.resource 405 (ri) = r (ri) = this 406 +-----------------|-----------------+ 407 prop.resource | Export | Non-exist | 408 (ro) = r | | | 409 +-----------------|-----------------+ 410 prop.resource | Extend | Define | 411 (ro) = this | | | 412 +-----------------|-----------------+ 414 where "this" points to the resulting property map resource, "r" 415 presents an existing ALTO information resource other the resulting 416 property map resource. 418 o ri = ro = r ("export" mode): the property map resource just 419 transforms the property mapping di => po defined by r into the 420 unified representation format and exports it. For example: r = 421 "netmap1", di = "ipv4", po = "pid". The property map resource 422 exports the "ipv4 => pid" mapping defined by "netmap1". 424 o ri = r, ro = this ("extend" mode): the property map extends 425 properties of entities in the entity domain (r, di) and defines a 426 new property po on them. For example: the property map resource 427 ("this") defines a "geolocation" property on domain "netmap1.pid". 429 o ri = ro = this ("define" mode): the property map defines a new 430 intrinsic entity domain and defines property po for each entities 431 in this domain. For example: the property map resource ("this") 432 defines a new entity domain "asn" and defines a property 433 "ipprefixes" on this domain. 435 o ri = this, ro = r: in the scope of a property map resource, it 436 does not make sense that another existing ALTO information 437 resource defines a property for this property map resource. 439 2.7. Entity Hierarchy and Property Inheritance 441 Enumerating all individual effective entities are inefficient. Some 442 types of entities have the hierarchy format, e.g., cidr, which stand 443 for sets of individual entities. Many entities in the same 444 hierarchical format entity sets may have the same proprety values. 445 To reduce the size of the property map representation, this document 446 introduces an approach called "Property Inheritance". Individual 447 entities can inherit the property from its hierarchical format entity 448 set. 450 3. Protocol Specification: Basic Data Type 452 3.1. Entity Domain 454 3.1.1. Entity Domain Type 456 An entity domain has a type, which is defined by a string that MUST 457 be no more than 64 characters, and MUST NOT contain characters other 458 than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, 459 and U+0061-U+007A), hyphen ("-", U+002D), and low line ("_", U+005F). 460 For example, the strings "ipv4", "ipv6", and "pid" are valid entity 461 domain types. 463 The type EntityDomainType is used in this document to denote a JSON 464 string confirming to the preceding requirement. 466 An entity domain type defines the semantics of a type of entity 467 domains. Each entity domain type MUST be registered with the IANA. 468 The format of the entity identifiers (see Section 3.1.3) in that type 469 of entity domains, as well as any hierarchical or inheritance rules 470 (see Section 3.1.4) for those entities, MUST be specified at the same 471 time. 473 3.1.2. Entity Domain Name 475 Each entity domain is identified by an entity domain name, a string 476 of the following format: 478 EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType 480 This document distinguish three types of entity domains: resource- 481 specific entity domains, self-defined entity domain and aggregated 482 entity domains. Their entity domain names are derived as follows. 484 Each ALTO information resource MAY define a resource-specific entity 485 domain (which could be empty) in a given entity domain type. A 486 resource-specific entity domain is identified by an entity domain 487 name derived as follows. It MUST start with a resource ID using the 488 ResourceID type defined in [RFC7285], followed by the "." separator 489 (U+002E), followed by an EntityDomainType typed string. For example, 490 if an ALTO server provides two network maps "netmap-1" and "netmap- 491 2", they can define two different "pid" domains identified by 492 "netmap-1.pid" and "netmap-2.pid" respectively. To be simplified, in 493 the scope of a specific information resource, the resource-specific 494 entity domain defined by itself can be identified by the "." 495 EntityDomainTyep without the ResourceID. 497 When the associated information resource of a resource-specific 498 entity domain is the current information resource itself, this 499 resource-specific entity domain is a self-defined entity domain, and 500 its ResourceID SHOULD be ignored from its entity domain name. 502 Given a set of ALTO information resources, there MAY be an aggregated 503 entity domain in a given entity domain type amongst them. An 504 aggregated entity domain is simply identified by its entity domain 505 type. For example, given two network maps "net-map-1" and "net-map- 506 2", "ipv4" and "ipv6" identify two aggregated Internet address entity 507 domains (see Section 4.1) between them. 509 Note that the "." separator is not allowed in EntityDomainType and 510 hence there is no ambiguity on whether an entity domain name refers 511 to a global entity domain or a resource-specific entity domain. 513 3.1.3. Entity Identifier 515 Entities in an entity domain are identified by entity identifiers 516 (EntityID) of the following format: 518 EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID 519 Examples from the Internet address entity domains include individual 520 IP addresses such as "net1.ipv4:192.0.2.14" and 521 "net1.ipv6:2001:db8::12", as well as address blocks such as 522 "net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::1/48". 524 The format of the second part of an entity identifier depends on the 525 entity domain type, and MUST be specified when registering a new 526 entity domain type. Identifiers MAY be hierarchical, and properties 527 MAY be inherited based on that hierarchy. Again, the rules defining 528 any hierarchy or inheritance MUST be defined when the entity domain 529 type is registered. 531 The type EntityID is used in this document to denote a JSON string 532 representing an entity identifier in this format. 534 Note that two entity identifiers with different textual 535 representations may refer to the same entity, for a given entity 536 domain. For example, the strings "net1.ipv6:2001:db8::1" and 537 "net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the 538 "ipv6" entity domain. 540 3.1.4. Hierarchy and Inheritance 542 To make the representation efficient, some types of entity domains 543 MAY allow the ALTO client/server to use a hierarchical format entity 544 identifier to represent a block of individual entities. e.g., In an 545 IPv4 domain "net1.ipv4", a cidr "net1.ipv4:192.0.2.0/26" represents 546 64 individual IPv4 entities. In this case, the corresponding 547 property inheritance rule MUST be defined for the entity domain type. 548 The hierarchy and inheritance rule MUST have no ambiguity. 550 3.2. Entity Property 552 Each entity property has a type to indicate the encoding and the 553 semantics of the value of this entity property, and has a name to be 554 identified. One entity MAY have multiple properties in the same 555 type. 557 3.2.1. Entity Property Type 559 The type EntityPropertyType is used in this document to indicate a 560 string denoting an entity property type. The string MUST be no more 561 than 32 characters, and it MUST NOT contain characters other than US- 562 ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 563 U+0061-U+007A), the hyphen ("-", U+002D), the colon (":", U+003A), or 564 the low line ('_', U+005F). 566 Each entity property type MUST be registered with the IANA. The 567 intended semantics of the entity property type MUST be specified at 568 the same time. 570 To distinguish with the endpoint property type, the entity property 571 type has the following features. 573 o Some entity property types may be applicable to entities in only 574 particular types of entity domains, not all. For example, the 575 "pid" property is not applicable to entities in a "pid" typed 576 entity domain, but is applicable to entities in the "ipv4" or 577 "ipv6" domains. 579 o The intended semantics of the value of a entity property may also 580 depend on the the entity domain type of this entity. For example, 581 suppose that the "geo-location" property is defined as the 582 coordinates of a point, encoded as (say) "latitude longitude 583 [altitude]." When applied to an entity that represents a specific 584 host computer, identified by an address in the "ipv4" or "ipv6" 585 entity domain, the property defines the host's location. However, 586 when applied to an entity in a "pid" domain, the property would 587 indicate the location of the center of all hosts in this "pid" 588 entity. 590 3.2.2. Entity Property Name 592 Each entity property is identified by an entity property name, which 593 is a string of the following format: 595 EntityPropertyName ::= [ ResourceID ] '.' EntityPropertyType 597 Similar to the endpoint property type defined in Section 10.8 of 598 [RFC7285], each entity property may be defined by either the property 599 map itself (self-defined) or some other specific information resource 600 (resource-specific). 602 The entity property name of a resource-specific entity property 603 starts with a string of the type ResourceID defined in [RFC7285], 604 followed by the "." separator (U+002E) and a EntityDomainType typed 605 string. For example, the "pid" properties of an "ipv4" entity 606 defined by two different maps "net-map-1" and "net-map-2" are 607 identified by "net-map-1.pid" and "net-map-2.pid" respectively. 609 When the associated information resource of the entity property is 610 the current information resource itself, the ResourceID in the 611 property name SHOULD be ignored. For example, the ".asn" property of 612 an "ipv4" entity indicates the AS number of the AS which this IPv4 613 address is owned by. 615 3.3. Information Resource Export 617 Each information resource MAY export a set of entity domains and 618 entity property mappings. 620 3.3.1. Resource-Specific Entity Domain Export 622 Each type of information resource MAY export several types of entity 623 domains. For example, a network map resource defines a "pid" domain, 624 a "ipv4" domain and a "ipv6" domain (which may be empty). 626 When a new ALTO information resource type is registered, if this type 627 of information resource can export an existing type of entity domain, 628 the corresponding document MUST define how to export such type of 629 entity domain from such type of information resource. 631 When a new entity domain type is defined, if an existing type of 632 information resource can export an entity domain in this entity 633 domain type, the corresponding document MUST define how to export 634 such type of entity domain from such type of information resource. 636 3.3.2. Entity Property Mapping Export 638 For each entity domain which could be exported by an information 639 resource, this information resource MAY also export some mapping from 640 this entity domain to some entity property. For example, a network 641 map resource can map an "ipv4" entity to its "pid" property. 643 When a new ALTO information resource type is registered, if this type 644 of information resource can export an entity domain in an existing 645 entity domain type, and map entities in this entity domain to an 646 existing type of entity property, the corresponding document MUST 647 define how to export such type of an entity property. 649 When a new ALTO entity domain type or a new entity property type is 650 defined, if an existing type of resource can export an entity domain 651 in this entity domain type, and map entities in this entity domain to 652 this type of entity property, the corresponding document MUST define 653 how to export such type of an entity property. 655 4. Entity Domain Types 657 This document defines three entity domain types. The definition of 658 each entity domain type below includes the following: (1) entity 659 domain type name, (2) entity domain-specific entity identifiers, and 660 (3) hierarchy and inheritance semantics. Since a global entity 661 domain type defines a single global entity domain, we say entity 662 domain instead of entity domain type. 664 4.1. Internet Address Domain Types 666 The document defines two entity domain types (IPv4 and IPv6) for 667 Internet addresses. Both types are global entity domain types and 668 hence define a corresponding global entity domain as well. Since the 669 two domains use the same hierarchy and inheritance semantics, we 670 define the semantics together, instead of repeating for each. 672 4.1.1. IPv4 Domain 674 4.1.1.1. Entity Domain Type 676 ipv4 678 4.1.1.2. Domain-Specific Entity Identifiers 680 Individual addresses are strings as specified by the IPv4Addresses 681 rule of Section 3.2.2 of [RFC3986]; blocks of addresses are prefix- 682 match strings as specified in Section 3.1 of [RFC4632]. For the 683 purpose of defining properties, an individual Internet address and 684 the corresponding full-length prefix are considered aliases for the 685 same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are 686 equivalent. 688 4.1.2. IPv6 Domain 690 4.1.2.1. Entity Domain Type 692 ipv6 694 4.1.2.2. Domain-Specific Entity Identifiers 696 Individual addresses are strings as specified by Section 4 of 697 [RFC5952]; blocks of addresses are prefix-match strings as specified 698 in Section 7 of [RFC5952]. For the purpose of defining properties, 699 an individual Internet address and the corresponding 128-bit prefix 700 are considered aliases for the same entity. That is, 701 "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and 702 have the same set of properties. 704 4.1.3. Hierarchy and Inheritance of Internet Address Domains 706 Both Internet address domains allow property values to be inherited. 707 Specifically, if a property P is not defined for a specific Internet 708 address I, but P is defined for some block C which prefix-matches I, 709 then the address I inherits the value of P defined for block C. If 710 more than one such block defines a value for P, I inherits the value 711 of P in the block with the longest prefix. It is important to notice 712 that this longest prefix rule will ensure no multiple inheritance, 713 and hence no ambiguity. 715 Address blocks can also inherit properties: if a property P is not 716 defined for a block C, but is defined for some block C' which covers 717 all IP addresses in C, and C' has a shorter mask than C, then block C 718 inherits the property from C'. If there are several such blocks C', 719 C inherits from the block with the longest prefix. 721 As an example, suppose that a server defines a property P for the 722 following entities: 724 ipv4:192.0.2.0/26: P=v1 725 ipv4:192.0.2.0/28: P=v2 726 ipv4:192.0.2.0/30: P=v3 727 ipv4:192.0.2.0: P=v4 729 Figure 1: Defined Property Values. 731 Then the following entities have the indicated values: 733 ipv4:192.0.2.0: P=v4 734 ipv4:192.0.2.1: P=v3 735 ipv4:192.0.2.16: P=v1 736 ipv4:192.0.2.32: P=v1 737 ipv4:192.0.2.64: (not defined) 738 ipv4:192.0.2.0/32: P=v4 739 ipv4:192.0.2.0/31: P=v3 740 ipv4:192.0.2.0/29: P=v2 741 ipv4:192.0.2.0/27: P=v1 742 ipv4:192.0.2.0/25: (not defined) 744 Figure 2: Inherited Property Values. 746 An ALTO server MAY explicitly indicate a property as not having a 747 value for a particular entity. That is, a server MAY say that 748 property P of entity X is "defined to have no value", instead of 749 "undefined". To indicate "no value", a server MAY perform different 750 behaviours: 752 o If that entity would inherit a value for that property, then the 753 ALTO server MUST return a "null" value for that property. In this 754 case, the ALTO client MUST recognize a "null" value as "no value" 755 and "do not apply the inheritance rules for this property." 757 o If the entity would not inherit a value, then the ALTO server MAY 758 return "null" or just omit the property. In this case, the ALTO 759 client cannot infer the value for this property of this entity 760 from the Inheritance rules. So the client MUST interpret that 761 this property has no value. 763 If the ALTO server does not define any properties for an entity, then 764 the server MAY omit that entity from the response. 766 4.2. PID Domain 768 The PID domain associates property values with the PIDs in a network 769 map. Accordingly, this entity domain always depends on a network 770 map. 772 4.2.1. Entity Domain Type 774 pid 776 4.2.2. Domain-Specific Entity Identifiers 778 The entity identifiers are the PID names of the associated network 779 map. 781 4.2.3. Hierarchy and Inheritance 783 There is no hierarchy or inheritance for properties associated with 784 PIDs. 786 4.2.4. Relationship To Internet Addresses Domains 788 The PID domain and the Internet address domains are completely 789 independent; the properties associated with a PID have no relation to 790 the properties associated with the prefixes or endpoint addresses in 791 that PID. An ALTO server MAY choose to assign some or all properties 792 of a PID to the prefixes in that PID. 794 For example, suppose "PID1" consists of the prefix 795 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 796 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24", 797 in the IPv4 domain MAY have a value for the property "P", and if they 798 do, it is not necessarily "v1". 800 4.3. Internet Address Properties vs. PID Properties 802 Because the Internet address and PID domains are completely separate, 803 the question may arise as to which entity domain is the best for a 804 property. In general, the Internet address domains are RECOMMENDED 805 for properties that are closely related to the Internet address, or 806 are associated with, and inherited through, blocks of addresses. 808 The PID domain is RECOMMENDED for properties that arise from the 809 definition of the PID, rather than from the Internet address prefixes 810 in that PID. 812 For example, because Internet addresses are allocated to service 813 providers by blocks of prefixes, an "ISP" property would be best 814 associated with the Internet address domain. On the other hand, a 815 property that explains why a PID was formed, or how it relates a 816 provider's network, would best be associated with the PID domain. 818 5. Entity Domains and Property Mappings in Information Resources 820 5.1. Network Map Resource 822 The ALTO network map resource defined by the media type "application/ 823 alto-networkmap+json" exports the following types of entity domains 824 and entity property mappings. 826 5.1.1. Resource-Specific Entity Domain 828 An ALTO network map resource defines a "pid" domain, an "ipv4" domain 829 and an "ipv6" domain by follows: 831 o The defined "pid" domain includes all PIDs in keys of the 832 "network-map" object. 834 o The defined "ipv4" domain includes all IPv4 addresses appearing in 835 the "ipv4" field of the endpoint address group of each PID. 837 o The defined "ipv6" domain includes all IPv6 addresses appearing in 838 the "ipv6" field of the endpoint address group of each PID. 840 5.1.2. Entity Property Mapping 842 For each of the preceding entity domains, an ALTO network map 843 resource provides the properties mapping as follows: 845 ipv4 -> pid: An "networkmap" typed resource can map an "ipv4" entity 846 to a "pid" property whose value is a PID defined by this 847 "networkmap" resource and including the IPv4 address of this 848 entity. 850 ipv6 -> pid: An "networkmap" typed resource can map an "ipv6" entity 851 to a "pid" property whose value is a PID defined by this 852 "networkmap" resource and including the IPv6 address of this 853 entity. 855 5.2. Endpoint Property Resource 857 The ALTO endpoint property resource defined by the media type 858 "application/alto-endpointprop+json" exports the following types of 859 entity domains and entity property mappings. 861 5.2.1. Resource-Specific Entity Domain 863 An ALTO endpoint property resource defined an "ipv4" domain and an 864 "ipv6" domain by follows: 866 o The defined "ipv4" domain includes all IPv4 addresses appearing in 867 keys of the "endpoint-properties" object. 869 o The defined "ipv6" domain includes all IPv6 addresses appearing in 870 keys of the "endpoint-properties" object. 872 5.2.2. Entity Property Mapping 874 For each of the preceding entity domains, an ALTO endpoint property 875 resource exports the properties mapping from it to each supported 876 global endpoint property. The property value is the corresponding 877 global endpoint property value in the "endpiont-properties" object. 879 5.3. Property Map Resource 881 To avoid the nested reference and its potential complexity, this 882 document does not specify the export rule of resource-specific entity 883 domain and entity property mapping for the ALTO property map resource 884 defined by the media type "application/alto-propmap+json" (see 885 Section 6.1). 887 6. Property Map 889 A property map returns the properties defined for all entities in one 890 or more domains, e.g., the "location" property of entities in "pid" 891 domain, and the "ASN" property of entities in "ipv4" and "ipv6" 892 domains. 894 Section 9.4 gives an example of a property map request and its 895 response. 897 6.1. Media Type 899 The media type of a property map is "application/alto-propmap+json". 901 6.2. HTTP Method 903 The property map is requested using the HTTP GET method. 905 6.3. Accept Input Parameters 907 None. 909 6.4. Capabilities 911 The capabilities are defined by an object of type 912 PropertyMapCapabilities: 914 object { 915 EntityPropertyMapping mappings; 916 } PropertyMapCapabilities; 918 object-map { 919 EntityDomainName -> EntityPropertyName<1..*>; 920 } EntityPropertyMapping 922 with fields: 924 mappings: A JSON object whose keys are names of entity domains and 925 values are the supported entity properties of the corresponding 926 entity domains. 928 6.5. Uses 930 The "uses" field of a property map resource in an IRD entry specifies 931 dependent resources of this property map. It is an array of the 932 resource ID(s) of the resource(s). 934 6.6. Response 936 If the entity domains in this property map depend on other resources, 937 the "dependent-vtags" field in the "meta" field of the response MUST 938 be an array that includes the version tags of those resources, and 939 the order MUST be consistent with the "uses" field of this property 940 map resource. The data component of a property map response is named 941 "property-map", which is a JSON object of type PropertyMapData, 942 where: 944 object { 945 PropertyMapData property-map; 946 } InfoResourceProperties : ResponseEntityBase; 948 object-map { 949 EntityID -> EntityProps; 950 } PropertyMapData; 952 object { 953 EntityPropertyName -> JSONValue; 954 } EntityProps; 956 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 958 Specifically, a PropertyMapData object has one member for each entity 959 in the property map. The entity's properties are encoded in the 960 corresponding EntityProps object. EntityProps encodes one name/value 961 pair for each property, where the property names are encoded as 962 strings of type PropertyName. A protocol implementation SHOULD 963 assume that the property value is either a JSONString or a JSON 964 "null" value, and fail to parse if it is not, unless the 965 implementation is using an extension to this document that indicates 966 when and how property values of other data types are signaled. 968 For each entity in the property map: 970 o If the entity is in a resource-specific entity domain, the ALTO 971 server SHOULD only return self-defined properties and resource- 972 specific properties which depend on the same resource as the 973 entity does. The ALTO client SHOULD ignore the resource-specific 974 property in this entity if their mapping is not registered in the 975 ALTO Resource Entity Property Transfer Registry of the type of the 976 corresponding resource. 978 o If the entity is in a shared entity domain, the ALTO server SHOULD 979 return self-defined properties and all resource-specific 980 properties defined for all resource-specific entities which have 981 the same domain-specific entity identifier as this entity does. 983 For efficiency, the ALTO server SHOULD omit property values that are 984 inherited rather than explicitly defined; if a client needs inherited 985 values, the client SHOULD use the entity domain's inheritance rules 986 to deduce those values. 988 7. Filtered Property Map 990 A filtered property map returns the values of a set of properties for 991 a set of entities selected by the client. 993 Section 9.5, Section 9.6, Section 9.7 and Section 9.8 give examples 994 of filtered property map requests and responses. 996 7.1. Media Type 998 The media type of a property map resource is "application/alto- 999 propmap+json". 1001 7.2. HTTP Method 1003 The filtered property map is requested using the HTTP POST method. 1005 7.3. Accept Input Parameters 1007 The input parameters for a filtered property map request are supplied 1008 in the entity body of the POST request. This document specifies the 1009 input parameters with a data format indicated by the media type 1010 "application/alto-propmapparams+json", which is a JSON object of type 1011 ReqFilteredPropertyMap: 1013 object { 1014 EntityID entities<1..*>; 1015 EntityPropertyName properties<1..*>; 1016 } ReqFilteredPropertyMap; 1018 with fields: 1020 entities: List of entity identifiers for which the specified 1021 properties are to be returned. The ALTO server MUST interpret 1022 entries appearing multiple times as if they appeared only once. 1023 The domain of each entity MUST be included in the list of entity 1024 domains in this resource's "capabilities" field (see Section 7.4). 1026 properties: List of properties to be returned for each entity. Each 1027 specified property MUST be included in the list of properties in 1028 this resource's "capabilities" field (see Section 7.4). The ALTO 1029 server MUST interpret entries appearing multiple times as if they 1030 appeared only once. 1032 Note that the "entities" and "properties" fields MUST have at 1033 least one entry each. 1035 7.4. Capabilities 1037 The capabilities are defined by an object of type 1038 PropertyMapCapabilities, as defined in Section 6.4. 1040 7.5. Uses 1042 Same to the "uses" field of the Property Map resource (see 1043 Section 6.5). 1045 7.6. Response 1047 The response MUST indicate an error, using ALTO protocol error 1048 handling, as defined in Section 8.5 of [RFC7285], if the request is 1049 invalid. 1051 Specifically, a filtered property map request can be invalid as 1052 follows: 1054 o An entity identifier in "entities" in the request is invalid if: 1056 * The domain of this entity is not defined in the "entity- 1057 domains" capability of this resource in the IRD; 1059 * The entity identifier is an invalid identifier in the entity 1060 domain. 1062 A valid entity identifier is never an error, even if this filtered 1063 property map resource does not define any properties for it. 1065 If an entity identifier in "entities" in the request is invalid, 1066 the ALTO server MUST return an "E_INVALID_FIELD_VALUE" error 1067 defined in Section 8.5.2 of [RFC7285], and the "value" field of 1068 the error message SHOULD indicate this entity identifier. 1070 o A property name in "properties" in the request is invalid if this 1071 property name is not defined in the "properties" capability of 1072 this resource in the IRD. 1074 It is not an error that a filtered property map resource does not 1075 define a requested property's value for a particular entity. In 1076 this case, the ALTO server MUST omit that property from the 1077 response for that endpoint. 1079 If a property name in "properties" in the request is invalid, the 1080 ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined 1081 in Section 8.5.2 of [RFC7285]. The "value" field of the error 1082 message SHOULD indicate the property name. 1084 The response to a valid request is the same as for the Property Map 1085 (see Section 6.6), except that: 1087 o If the requested entities include entities in the shared entity 1088 domain, the "dependent-vtags" field in its "meta" field MUST 1089 include version tags of all dependent resources appearing in the 1090 "uses" field. 1092 o If the requested entities only include entities in resource- 1093 specific entity domains, the "dependent-vtags" field in its "meta" 1094 field MUST include version tags of resources which requested 1095 resource-specific entity domains and requested resource-specific 1096 properties are dependent on. 1098 o The response only includes the entities and properties requested 1099 by the client. If an entity in the request is identified by a 1100 hierarchical identifier (e.g., an "ipv4" or "ipv6" address block), 1101 the response MUST cover properties for all identifiers in this 1102 hierarchical identifier. 1104 It is important that the filtered property map response MUST include 1105 all inherited property values for the requested entities and all the 1106 entities which are able to inherit property values from them. To 1107 achieve this goal, the ALTO server MAY follow three rules: 1109 o If a property for a requested entity is inherited from another 1110 entity not included in the request, the response SHOULD include 1111 this property for the requested entity. For example, A full 1112 property map may skip a property P for an entity A (e.g., 1113 ipv4:192.0.2.0/31) if P can be derived using inheritance from 1114 another entity B (e.g., ipv4:192.0.2.0/30). A filtered property 1115 map request may include only A but not B. In such a case, the 1116 property P SHOULD be included in the response for A. 1118 o If there are entities covered by a requested entity but having 1119 different values for the requested properties, the response SHOULD 1120 include all those entities and the different property values for 1121 them. For example, considering a request for property P of entity 1122 A (e.g., ipv4:192.0.2.0/31), if P has value v1 for 1123 A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the 1124 response SHOULD include A1 and A2. 1126 o If an entity in the response is already covered by some other 1127 entities in the same response, it SHOULD be removed from the 1128 response for compactness. For example, in the previous example, 1129 the entity A=ipv4:192.0.2.0/31 SHOULD be removed because A1 and A2 1130 cover all the addresses in A. 1132 An ALTO client should be aware that the entities in the response MAY 1133 be different from the entities in its request. 1135 8. Impact on Legacy ALTO Servers and ALTO Clients 1137 8.1. Impact on Endpoint Property Service 1139 Since the property map and the filtered property map defined in this 1140 document provide the functionality of the Endpoint Property Service 1141 (EPS) defined in Section 11.4 of [RFC7285], it is RECOMMENDED that 1142 the EPS be deprecated in favor of Property Map and Filtered Property 1143 Map. However, ALTO servers MAY provide an EPS for the benefit of 1144 legacy clients. 1146 8.2. Impact on Resource-Specific Properties 1148 Section 10.8 of [RFC7285] defines two categories of endpoint 1149 properties: "resource-specific" and "global". Resource-specific 1150 property names are prefixed with the ID of the resource they depend 1151 upon, while global property names have no such prefix. The property 1152 map and the filtered property map defined in this document defines 1153 the similar categories for entity properties. The difference is that 1154 there is no "global" entity properties but the "self-defined" entity 1155 properties as the special case of the "resource-specific" entity 1156 properties instead. 1158 8.3. Impact on Other Properties 1160 In general, there should be little or no impact on other previously 1161 defined properties. The only consideration is that properties can 1162 now be defined on blocks of entity identifiers, rather than just 1163 individual entity identifiers, which might change the semantics of a 1164 property. 1166 9. Examples 1168 9.1. Network Map 1170 The examples in this section use a very simple default network map: 1172 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1173 pid1: ipv4:192.0.2.0/25 1174 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 1175 pid3: ipv4:192.0.3.0/28 1176 pid4: ipv4:192.0.3.16/28 1178 Figure 3: Example Default Network Map 1180 And another simple alternative network map: 1182 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1183 pid1: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 1184 pid2: ipv4:192.0.3.0/28 ipv4:192.0.3.16/28 1186 Figure 4: Example Alternative Network Map 1188 9.2. Property Definitions 1190 Beyond "pid", the examples in this section use four additional 1191 properties for Internet address domains, "ISP", "ASN", "country" and 1192 "state", with the following values: 1194 ISP ASN country state 1195 ipv4:192.0.2.0/23: BitsRus - us - 1196 ipv4:192.0.2.0/28: - 12345 - NJ 1197 ipv4:192.0.2.16/28: - 12345 - CT 1198 ipv4:192.0.2.0: - - - PA 1199 ipv4:192.0.3.0/28: - 12346 - TX 1200 ipv4:192.0.3.16/28: - 12346 - MN 1202 Figure 5: Example Property Values for Internet Address Domains 1204 And the examples in this section use the property "region" for the 1205 PID domain of the default network map with the following values: 1207 region 1208 pid:defaultpid: - 1209 pid:pid1: us-west 1210 pid:pid2: us-east 1211 pid:pid3: us-south 1212 pid:pid4: us-north 1214 Figure 6: Example Property Values for Default Network Map's PID 1215 Domain 1217 Note that "-" means the value of the property for the entity is 1218 "undefined". So the entity would inherit a value for this property 1219 by the inheritance rule if possible. For example, the value of the 1220 "ISP" property for "ipv4:192.0.2.0" is "BitsRus" because of 1221 "ipv4:192.0.2.0/24". But the "region" property for "pid:defaultpid" 1222 has no value because no entity from which it can inherit. 1224 Similar to the PID domain of the default network map, the examples in 1225 this section use the property "ASN" for the PID domain of the 1226 alternative network map with the following values: 1228 ASN 1229 pid:defaultpid: - 1230 pid:pid1: 12345 1231 pid:pid2: 12346 1233 Figure 7: Example Property Values for Alternative Network Map's PID 1234 Domain 1236 9.3. Information Resource Directory (IRD) 1238 The following IRD defines the relevant resources of the ALTO server. 1239 It provides two property maps, one for the "ISP" and "ASN" 1240 properties, and another for the "country" and "state" properties. 1241 The server could have provided a single property map for all four 1242 properties, but did not, presumably because the organization that 1243 runs the ALTO server believes any given client is not interested in 1244 all four properties. 1246 The server provides two filtered property maps. The first returns 1247 all four properties, and the second just returns the "pid" property 1248 for the default network map. 1250 The filtered property maps for the "ISP", "ASN", "country" and 1251 "state" properties do not depend on the default network map (it does 1252 not have a "uses" capability), because the definitions of those 1253 properties do not depend on the default network map. The Filtered 1254 Property Map for the "pid" property does have a "uses" capability for 1255 the default network map, because that defines the values of the "pid" 1256 property. 1258 Note that for legacy clients, the ALTO server provides an Endpoint 1259 Property Service for the "pid" property for the default network map. 1261 "meta" : { 1262 ... 1263 "default-alto-network-map" : "default-network-map" 1264 }, 1265 "resources" : { 1266 "default-network-map" : { 1267 "uri" : "http://alto.example.com/networkmap/default", 1268 "media-type" : "application/alto-networkmap+json" 1269 }, 1270 "alt-network-map" : { 1271 "uri" : "http://alto.example.com/networkmap/alt", 1272 "media-type" : "application/alto-networkmap+json" 1273 }, 1274 .... property map resources .... 1275 "ia-property-map" : { 1276 "uri" : "http://alto.example.com/propmap/full/inet-ia", 1277 "media-type" : "application/alto-propmap+json", 1278 "uses": [ "default-network-map", "alt-network-map" ], 1279 "capabilities" : { 1280 "mappings": { 1281 "ipv4": [ ".ISP", ".ASN" ], 1282 "ipv6": [ ".ISP", ".ASN" ] 1283 } 1284 } 1285 }, 1286 "iacs-property-map" : { 1287 "uri" : "http://alto.example.com/propmap/full/inet-iacs", 1288 "media-type" : "application/alto-propmap+json", 1289 "accepts": "application/alto-propmapparams+json", 1290 "uses": [ "default-network-map", "alt-network-map" ], 1291 "capabilities" : { 1292 "mappings": { 1293 "ipv4": [ ".ISP", ".ASN", ".country", ".state" ], 1294 "ipv6": [ ".ISP", ".ASN", ".country", ".state" ] 1295 } 1296 } 1297 }, 1298 "region-property-map": { 1299 "uri": "http://alto.exmaple.com/propmap/region", 1300 "media-type": "application/alto-propmap+json", 1301 "accepts": "application/alto-propmapparams+json", 1302 "uses" : [ "default-network-map", "alt-network-map" ], 1303 "capabilities": { 1304 "mappings": { 1305 "default-network-map.pid": [ ".region" ], 1306 "alt-network-map.pid": [ ".ASN" ], 1307 } 1308 } 1309 }, 1310 "ip-pid-property-map" : { 1311 "uri" : "http://alto.example.com/propmap/lookup/pid", 1312 "media-type" : "application/alto-propmap+json", 1313 "accepts" : "application/alto-propmapparams+json", 1314 "uses" : [ "default-network-map", "alt-network-map" ], 1315 "capabilities" : { 1316 "mappings": { 1317 "ipv4": [ "default-network-map.pid", 1318 "alt-network-map.pid" ], 1319 "ipv6": [ "default-network-map.pid", 1320 "alt-network-map.pid" ] 1321 } 1322 } 1323 }, 1324 "legacy-endpoint-property" : { 1325 "uri" : "http://alto.example.com/legacy/eps-pid", 1326 "media-type" : "application/alto-endpointprop+json", 1327 "accepts" : "application/alto-endpointpropparams+json", 1328 "capabilities" : { 1329 "properties" : [ "default-network-map.pid", 1330 "alt-network-map.pid" ] 1331 } 1332 } 1333 } 1335 Figure 8: Example IRD 1337 9.4. Property Map Example 1339 The following example uses the properties and IRD defined above to 1340 retrieve a Property Map for entities with the "ISP" and "ASN" 1341 properties. 1343 Note that, to be compact, the response does not includes the entity 1344 "ipv4:192.0.2.0", because values of all those properties for this 1345 entity are inherited from other entities. 1347 Also note that the entities "ipv4:192.0.2.0/28" and 1348 "ipv4:192.0.2.16/28" are merged into "ipv4:192.0.2.0/27", because 1349 they have the same value of the "ASN" property. The same rule 1350 applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". 1351 Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value 1352 for the "ISP" property, because it is inherited from 1353 "ipv4:192.0.2.0/23". 1355 GET /propmap/full/inet-ia HTTP/1.1 1356 Host: alto.example.com 1357 Accept: application/alto-propmap+json,application/alto-error+json 1358 HTTP/1.1 200 OK 1359 Content-Length: ### 1360 Content-Type: application/alto-propmap+json 1362 { 1363 "meta": { 1364 "dependent-vtags": [ 1365 {"resource-id": "default-network-map", 1366 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1367 {"resource-id": "alt-network-map", 1368 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1369 ] 1370 }, 1371 "property-map": { 1372 "ipv4:192.0.2.0/23": {".ISP": "BitsRus"}, 1373 "ipv4:192.0.2.0/27": {".ASN": "12345"}, 1374 "ipv4:192.0.3.0/27": {".ASN": "12346"} 1375 } 1376 } 1378 9.5. Filtered Property Map Example #1 1380 The following example uses the filtered property map resource to 1381 request the "ISP", "ASN" and "state" properties for several IPv4 1382 addresses. 1384 Note that the value of "state" for "ipv4:192.0.2.0" is the only 1385 explicitly defined property; the other values are all derived by the 1386 inheritance rules for Internet address entities. 1388 POST /propmap/lookup/inet-iacs HTTP/1.1 1389 Host: alto.example.com 1390 Accept: application/alto-propmap+json,application/alto-error+json 1391 Content-Length: ### 1392 Content-Type: application/alto-propmapparams+json 1394 { 1395 "entities" : [ "ipv4:192.0.2.0", 1396 "ipv4:192.0.2.1", 1397 "ipv4:192.0.2.17" ], 1398 "properties" : [ ".ISP", ".ASN", ".state" ] 1399 } 1400 HTTP/1.1 200 OK 1401 Content-Length: ### 1402 Content-Type: application/alto-propmap+json 1404 { 1405 "meta": { 1406 "dependent-vtags": [ 1407 {"resource-id": "default-network-map", 1408 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1409 {"resource-id": "alt-network-map", 1410 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1411 ] 1412 }, 1413 "property-map": { 1414 "ipv4:192.0.2.0": 1415 {".ISP": "BitsRus", ".ASN": "12345", ".state": "PA"}, 1416 "ipv4:192.0.2.1": 1417 {".ISP": "BitsRus", ".ASN": "12345", ".state": "NJ"}, 1418 "ipv4:192.0.2.17": 1419 {".ISP": "BitsRus", ".ASN": "12345", ".state": "CT"} 1420 } 1421 } 1423 9.6. Filtered Property Map Example #2 1425 The following example uses the filtered property map resource to 1426 request the "ASN", "country" and "state" properties for several IPv4 1427 prefixes. 1429 Note that the property values for both entities "ipv4:192.0.2.0/26" 1430 and "ipv4:192.0.3.0/26" are not explicitly defined. They are 1431 inherited from the entity "ipv4:192.0.2.0/23". 1433 Also note that some entities like "ipv4:192.0.2.0/28" and 1434 "ipv4:192.0.2.16/28" in the response are not listed in the request 1435 explicitly. The response includes them because they are refinements 1436 of the requested entities and have different values for the requested 1437 properties. 1439 The entity "ipv4:192.0.4.0/26" is not included in the response, 1440 because there are neither entities which it is inherited from, nor 1441 entities inherited from it. 1443 POST /propmap/lookup/inet-iacs HTTP/1.1 1444 Host: alto.example.com 1445 Accept: application/alto-propmap+json,application/alto-error+json 1446 Content-Length: ### 1447 Content-Type: application/alto-propmapparams+json 1449 { 1450 "entities" : [ "ipv4:192.0.2.0/26", 1451 "ipv4:192.0.3.0/26", 1452 "ipv4:192.0.4.0/26" ], 1453 "properties" : [ ".ASN", ".country", ".state" ] 1454 } 1456 HTTP/1.1 200 OK 1457 Content-Length: ### 1458 Content-Type: application/alto-propmap+json 1460 { 1461 "meta": { 1462 "dependent-vtags": [ 1463 {"resource-id": "default-network-map", 1464 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1465 {"resource-id": "alt-network-map", 1466 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1467 ] 1468 }, 1469 "property-map": { 1470 "ipv4:192.0.2.0/26": {".country": "us"}, 1471 "ipv4:192.0.2.0/28": {".ASN": "12345", 1472 ".state": "NJ"}, 1473 "ipv4:192.0.2.16/28": {".ASN": "12345", 1474 ".state": "CT"}, 1475 "ipv4:192.0.2.0": {".state": "PA"}, 1476 "ipv4:192.0.3.0/26": {".country": "us"}, 1477 "ipv4:192.0.3.0/28": {".ASN": "12345", 1478 ".state": "TX"}, 1479 "ipv4:192.0.3.16/28": {".ASN": "12345", 1480 ".state": "MN"} 1481 } 1482 } 1484 9.7. Filtered Property Map Example #3 1486 The following example uses the filtered property map resource to 1487 request the "pid" property for several IPv4 addresses and prefixes. 1489 Note that the entity "ipv4:192.0.3.0/27" is redundant in the 1490 response. Although it can inherit a value of "defaultpid" for the 1491 "pid" property from the entity "ipv4:0.0.0.0/0", none of addresses in 1492 it is in "defaultpid". Because blocks "ipv4:192.0.3.0/28" and 1493 "ipv4:192.0.3.16/28" have already cover all addresses in that block. 1494 So an ALTO server who wants a compact response can omit this entity. 1496 POST /propmap/lookup/pid HTTP/1.1 1497 Host: alto.example.com 1498 Accept: application/alto-propmap+json,application/alto-error+json 1499 Content-Length: ### 1500 Content-Type: application/alto-propmapparams+json 1502 { 1503 "entities" : [ 1504 "ipv4:192.0.2.128", 1505 "ipv4:192.0.3.0/27" ], 1506 "properties" : [ "default-network-map.pid" ] 1507 } 1509 HTTP/1.1 200 OK 1510 Content-Length: ### 1511 Content-Type: application/alto-propmap+json 1513 { 1514 "meta": { 1515 "dependent-vtags": [ 1516 {"resource-id": "default-network-map", 1517 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1518 {"resource-id": "alt-network-map", 1519 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1520 ] 1521 }, 1522 "property-map": { 1523 "ipv4:192.0.2.128": {"default-network-map.pid": "defaultpid"}, 1524 "ipv4:192.0.2.0/27": {"default-network-map.pid": "defaultpid"}, 1525 "ipv4:192.0.3.0/28": {"default-network-map.pid": "pid3"}, 1526 "ipv4:192.0.3.16/28": {"default-network-map.pid": "pid4"} 1527 } 1528 } 1530 9.8. Filtered Property Map Example #4 1532 The following example uses the filtered property map resource to 1533 request the "region" property for several PIDs defined in "default- 1534 network-map". The value of the "region" property for each PID is not 1535 defined by "default-network-map", but the reason why the PID is 1536 defined by the network operator. 1538 POST /propmap/lookup/region HTTP/1.1 1539 Host: alto.example.com 1540 Accept: application/alto-propmap+json,application/alto-error+json 1541 Content-Length: ### 1542 Content-Type: application/alto-propmapparams+json 1544 { 1545 "entities" : ["default-network-map.pid:pid1", 1546 "default-network-map.pid:pid2"], 1547 "properties" : [ ".region" ] 1548 } 1550 HTTP/1.1 200 OK 1551 Content-Length: ### 1552 Content-Type: application/alto-propmap+json 1554 { 1555 "meta" : { 1556 "dependent-vtags" : [ 1557 {"resource-id": "default-network-map", 1558 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1559 ] 1560 }, 1561 "property-map": { 1562 "default-network-map.pid:pid1": { 1563 ".region": "us-west" 1564 }, 1565 "default-network-map.pid:pid2": { 1566 ".region": "us-east" 1567 } 1568 } 1569 } 1571 10. Security Considerations 1573 Both Property Map and Filtered Property Map defined in this document 1574 fit into the architecture of the ALTO base protocol, and hence the 1575 Security Considerations (Section 15 of [RFC7285]) of the base 1576 protocol fully apply: authenticity and integrity of ALTO information 1577 (i.e., authenticity and integrity of Property Maps), potential 1578 undesirable guidance from authenticated ALTO information (e.g., 1579 potentially imprecise or even wrong value of a property such as geo- 1580 location), confidentiality of ALTO information (e.g., exposure of a 1581 potentially sensitive entity property such as geo-location), privacy 1582 for ALTO users, and availability of ALTO services should all be 1583 considered. 1585 A particular fundamental security consideration when an ALTO server 1586 provides a Property Map is to define precisely the policies on who 1587 can access what properties for which entities. Security mechanisms 1588 such as authentication and confidentiality mechanisms then should be 1589 applied to enforce the policy. For example, a policy can be that a 1590 property P can be accessed only by its owner (e.g., the customer who 1591 is allocated a given IP address). Then, the ALTO server will need to 1592 deploy corresponding mechanisms to realize the policy. The policy 1593 may allow non-owners to access a coarse-grained value of the property 1594 P. In such a case, the ALTO server may provide a different URI to 1595 provide the information. 1597 11. IANA Considerations 1599 This document defines additional application/alto-* media types, and 1600 extends the ALTO endpoint property registry. 1602 11.1. application/alto-* Media Types 1604 This document registers two additional ALTO media types, listed in 1605 Table 1. 1607 +--------------+--------------------------+------------------------+ 1608 | Type | Subtype | Specification | 1609 +--------------+--------------------------+------------------------+ 1610 | application | alto-propmap+json | Section 6.1 | 1611 | application | alto-propmapparams+json | Section 7.3 | 1612 +--------------+--------------------------+------------------------+ 1614 Table 1: Additional ALTO Media Types. 1616 Type name: application 1618 Subtype name: This document registers multiple subtypes, as listed 1619 in Table 1. 1621 Required parameters: n/a 1623 Optional parameters: n/a 1625 Encoding considerations: Encoding considerations are identical to 1626 those specified for the "application/json" media type. See 1627 [RFC7159]. 1629 Security considerations: Security considerations related to the 1630 generation and consumption of ALTO Protocol messages are discussed 1631 in Section 15 of [RFC7285]. 1633 Interoperability considerations: This document specifies formats of 1634 conforming messages and the interpretation thereof. 1636 Published specification: This document is the specification for 1637 these media types; see Table 1 for the section documenting each 1638 media type. 1640 Applications that use this media type: ALTO servers and ALTO clients 1641 either stand alone or are embedded within other applications. 1643 Additional information: 1645 Magic number(s): n/a 1647 File extension(s): This document uses the mime type to refer to 1648 protocol messages and thus does not require a file extension. 1650 Macintosh file type code(s): n/a 1652 Person & email address to contact for further information: See 1653 Authors' Addresses section. 1655 Intended usage: COMMON 1657 Restrictions on usage: n/a 1659 Author: See Authors' Addresses section. 1661 Change controller: Internet Engineering Task Force 1662 (mailto:iesg@ietf.org). 1664 11.2. ALTO Entity Domain Type Registry 1666 This document requests IANA to create and maintain the "ALTO Entity 1667 Domain Type Registry", listed in Table 2. 1669 +-------------+---------------------------+-------------------------+ 1670 | Identifier | Entity Identifier | Hierarchy & Inheritance | 1671 | | Encoding | | 1672 +-------------+---------------------------+-------------------------+ 1673 | ipv4 | See Section 4.1.1 | See Section 4.1.3 | 1674 | ipv6 | See Section 4.1.2 | See Section 4.1.3 | 1675 | pid | See Section 4.2 | None | 1676 +-------------+---------------------------+-------------------------+ 1678 Table 2: ALTO Entity Domains. 1680 This registry serves two purposes. First, it ensures uniqueness of 1681 identifiers referring to ALTO entity domains. Second, it states the 1682 requirements for allocated entity domains. 1684 11.2.1. Consistency Procedure between ALTO Address Type Registry and 1685 ALTO Entity Domain Type Registry 1687 One potential issue of introducing the "ALTO Entity Domain Type 1688 Registry" is its relationship with the "ALTO Address Types Registry" 1689 already defined in Section 14.4 of [RFC7285]. In particular, the 1690 entity identifier of a type of an entity domain registered in the 1691 "ALTO Entity Domain Type Registry" MAY match an address type defined 1692 in "ALTO Address Type Registry". It is necessary to precisely define 1693 and guarantee the consistency between "ALTO Address Type Registry" 1694 and "ALTO Entity Domain Registry". 1696 We define that the ALTO Entity Domain Type Registry is consistent 1697 with ALTO Address Type Registry if two conditions are satisfied: 1699 o When an address type is already or able to be registered in the 1700 ALTO Address Type Registry [RFC7285], the same identifier MUST be 1701 used when a corresponding entity domain type is registered in the 1702 ALTO Entity Domain Type Registry. 1704 o If an ALTO entity domain type has the same identifier as an ALTO 1705 address type, their addresses encoding MUST be compatible. 1707 To achieve this consistency, the following items MUST be checked 1708 before registering a new ALTO entity domain type in a future 1709 document: 1711 o Whether the ALTO Address Type Registry contains an address type 1712 that can be used as an entity identifier for the candidate domain 1713 identifier. This has been done for the identifiers "ipv4" and 1714 "ipv6" in Table 2. 1716 o Whether the candidate entity identifier of the type of the entity 1717 domain is able to be an endpoint address, as defined in Sections 1718 2.1 and 2.2 of [RFC7285]. 1720 When a new ALTO entity domain type is registered, the consistency 1721 with the ALTO Address Type Registry MUST be ensured by the following 1722 procedure: 1724 o Test: Do corresponding entity identifiers match a known "network" 1725 address type? 1727 * If yes (e.g., cell, MAC or socket addresses): 1729 + Test: Is such an address type present in the ALTO Address 1730 Type Registry? 1732 - If yes: Set the new ALTO entity domain type identifier to 1733 be the found ALTO address type identifier. 1735 - If no: Define a new ALTO entity domain type identifier 1736 and use it to register a new address type in the ALTO 1737 Address Type Registry following Section 14.4 of 1738 [RFC7285]. 1740 + Use the new ALTO entity domain type identifier to register a 1741 new ALTO entity domain type in the ALTO Entity Domain Type 1742 Registry following Section 11.2.2 of this document. 1744 * If no (e.g., pid name, ane name or country code): Proceed with 1745 the ALTO Entity Domain Type registration as described in 1746 Section 11.2.2. 1748 11.2.2. ALTO Entity Domain Type Registration Process 1750 New ALTO entity domain types are assigned after IETF Review [RFC5226] 1751 to ensure that proper documentation regarding the new ALTO entity 1752 domain types and their security considerations has been provided. 1753 RFCs defining new entity domain types SHOULD indicate how an entity 1754 in a registered type of domain is encoded as an EntityID, and, if 1755 applicable, the rules defining the entity hierarchy and property 1756 inheritance. Updates and deletions of ALTO entity domains follow the 1757 same procedure. 1759 Registered ALTO entity domain type identifiers MUST conform to the 1760 syntactical requirements specified in Section 3.1.2. Identifiers are 1761 to be recorded and displayed as strings. 1763 Requests to the IANA to add a new value to the registry MUST include 1764 the following information: 1766 o Identifier: The name of the desired ALTO entity domain type. 1768 o Entity Identifier Encoding: The procedure for encoding the 1769 identifier of an entity of the registered type as an EntityID (see 1770 Section 3.1.3). If corresponding entity identifiers of an entity 1771 domain match a known "network" address type, the Entity Identifier 1772 Encoding of this domain identifier MUST include both Address 1773 Encoding and Prefix Encoding of the same identifier registered in 1774 the ALTO Address Type Registry [RFC7285]. For the purpose of 1775 defining properties, an individual entity identifier and the 1776 corresponding full-length prefix MUST be considered aliases for 1777 the same entity. 1779 o Hierarchy: If the entities form a hierarchy, the procedure for 1780 determining that hierarchy. 1782 o Inheritance: If entities can inherit property values from other 1783 entities, the procedure for determining that inheritance. 1785 o Mapping to ALTO Address Type: A boolean value to indicate if the 1786 entity domain type can be mapped to the ALTO address type with the 1787 same identifier. 1789 o Security Considerations: In some usage scenarios, entity 1790 identifiers carried in ALTO Protocol messages may reveal 1791 information about an ALTO client or an ALTO service provider. 1792 Applications and ALTO service providers using addresses of the 1793 registered type should be made aware of how (or if) the addressing 1794 scheme relates to private information and network proximity. 1796 This specification requests registration of the identifiers "ipv4", 1797 "ipv6" and "pid", as shown in Table 2. 1799 11.3. ALTO Entity Property Type Registry 1801 This document requests IANA to create and maintain the "ALTO Entity 1802 Property Type Registry", listed in Table 3. 1804 To distinguish with the "ALTO Endpoint Property Type Registry", each 1805 entry in this registry is an ALTO entity property type defined in 1806 Section 3.2.1. Thus, registered ALTO entity property type identifier 1807 MUST conform to the syntactical requirements specified in that 1808 section. 1810 The initial registered ALTO entity property types are listed in 1811 Table 3. 1813 +-------------+---------------------------------+ 1814 | Identifier | Intended Semantics | 1815 +-------------+---------------------------------+ 1816 | pid | See Section 7.1.1 of [RFC7285] | 1817 +-------------+---------------------------------+ 1819 Table 3: ALTO Entity Property Types. 1821 Requests to the IANA to add a new value to the registry MUST include 1822 the following information: 1824 o Identifier: The unique id for the desired ALTO entity property 1825 type. The format MUST be as defined in Section 3.2.1 of this 1826 document. It includes the information of the applied ALTO entity 1827 domain and the property name. 1829 o Intended Semantics: ALTO entity properties carry with them 1830 semantics to guide their usage by ALTO clients. Hence, a document 1831 defining a new type SHOULD provide guidance to both ALTO service 1832 providers and applications utilizing ALTO clients as to how values 1833 of the registered ALTO entity property should be interpreted. 1835 This document requests registration of the identifier "pid", as shown 1836 in Table 3. 1838 11.4. ALTO Resource-Specific Entity Domain Registries 1840 11.4.1. Network Map 1842 Media-type: application/alto-networkmap+json 1844 +---------------------+---------------------+ 1845 | Entity Domain Type | Intended Semantics | 1846 +---------------------+---------------------+ 1847 | ipv4 | See Section 5.1.1 | 1848 | ipv6 | See Section 5.1.1 | 1849 | pid | See Section 5.1.1 | 1850 +---------------------+---------------------+ 1852 Table 4: ALTO Network Map Resource-Specific Entity Domain. 1854 11.4.2. Endpoint Property 1856 Media-type: application/alto-endpointprop+json 1858 +---------------------+---------------------+ 1859 | Entity Domain Type | Intended Semantics | 1860 +---------------------+---------------------+ 1861 | ipv4 | See Section 5.2.1 | 1862 | ipv6 | See Section 5.2.1 | 1863 +---------------------+---------------------+ 1865 Table 5: ALTO Endpoint Property Resource-Specific Entity Domain. 1867 11.5. ALTO Resource Entity Property Mapping Registries 1868 11.5.1. Network Map 1870 Media-type: application/alto-networkmap+json 1872 +----------------+-----------------+-------------+------------------+ 1873 | Mapping | Entity Domain | Property | Intended | 1874 | Descriptor | Type | Type | Semantics | 1875 +----------------+-----------------+-------------+------------------+ 1876 | ipv4 -> pid | ipv4 | pid | See | 1877 | | | | Section 5.1.2 | 1878 | ipv6 -> pid | ipv6 | pid | See | 1879 | | | | Section 5.1.2 | 1880 +----------------+-----------------+-------------+------------------+ 1882 Table 6: ALTO Network Map Entity Property Mapping. 1884 12. Acknowledgments 1886 The authors would like to thank discussions with Kai Gao, Qiao Xiang, 1887 Shawn Lin, Xin Wang, Danny Perez, and Vijay Gurbani. The authors 1888 thank Dawn Chen (Tongji University), and Shenshen Chen (Tongji/Yale 1889 University) for their contributions to earlier drafts. 1891 13. Normative References 1893 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1894 Requirement Levels", BCP 14, RFC 2119, 1895 DOI 10.17487/RFC2119, March 1997, 1896 . 1898 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1899 Resource Identifier (URI): Generic Syntax", STD 66, 1900 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1901 . 1903 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1904 (CIDR): The Internet Address Assignment and Aggregation 1905 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1906 2006, . 1908 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1909 IANA Considerations Section in RFCs", RFC 5226, 1910 DOI 10.17487/RFC5226, May 2008, 1911 . 1913 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1914 Address Text Representation", RFC 5952, 1915 DOI 10.17487/RFC5952, August 2010, 1916 . 1918 [RFC7011] Claise, B., Ed., Trammell, B., Ed., and P. Aitken, 1919 "Specification of the IP Flow Information Export (IPFIX) 1920 Protocol for the Exchange of Flow Information", STD 77, 1921 RFC 7011, DOI 10.17487/RFC7011, September 2013, 1922 . 1924 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1925 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1926 2014, . 1928 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1929 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1930 "Application-Layer Traffic Optimization (ALTO) Protocol", 1931 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1932 . 1934 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1935 Nadeau, "An Architecture for the Interface to the Routing 1936 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 1937 . 1939 Authors' Addresses 1941 Wendy Roome 1942 Nokia Bell Labs (Retired) 1943 124 Burlington Rd 1944 Murray Hill, NJ 07974 1945 USA 1947 Phone: +1-908-464-6975 1948 Email: wendy@wdroome.com 1950 Sabine Randriamasy 1951 Nokia Bell Labs 1952 Route de Villejust 1953 NOZAY 91460 1954 FRANCE 1956 Email: Sabine.Randriamasy@nokia-bell-labs.com 1957 Y. Richard Yang 1958 Yale University 1959 51 Prospect Street 1960 New Haven, CT 06511 1961 USA 1963 Phone: +1-203-432-6400 1964 Email: yry@cs.yale.edu 1966 Jingxuan Jensen Zhang 1967 Tongji University 1968 4800 Caoan Road 1969 Shanghai 201804 1970 China 1972 Email: jingxuan.n.zhang@gmail.com 1974 Kai Gao 1975 Sichuan University 1976 Chengdu 610000 1977 China 1979 Email: kaigao@scu.edu.cn