idnits 2.17.1 draft-ietf-alto-unified-props-new-08.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 373 has weird spacing: '...esource doma...' == Line 985 has weird spacing: '...rtyName prop...' == Line 1191 has weird spacing: '...country stat...' -- The document date (July 8, 2019) is 1753 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: January 9, 2020 Y. Yang 6 Yale University 7 J. Zhang 8 Tongji University 9 July 8, 2019 11 Unified Properties for the ALTO Protocol 12 draft-ietf-alto-unified-props-new-08 14 Abstract 16 This document extends the Application-Layer Traffic Optimization 17 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint 18 properties" to domains of other entities, and by presenting those 19 properties as maps, similar to the network and cost maps in 20 [RFC7285]. 22 Requirements Language 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on January 9, 2020. 45 Copyright Notice 47 Copyright (c) 2019 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Overview: Basic Concepts . . . . . . . . . . . . . . . . . . 5 64 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 6 66 2.3. Property Map . . . . . . . . . . . . . . . . . . . . . . 6 67 2.4. Information Resource . . . . . . . . . . . . . . . . . . 6 68 2.5. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 7 69 2.5.1. Resource-Specific Entity Domain . . . . . . . . . . . 7 70 2.5.2. Relationship between Entity and Entity Domain . . . . 7 71 2.5.3. Aggregated Entity Domain . . . . . . . . . . . . . . 7 72 2.5.4. Resource-Specific Entity Property . . . . . . . . . . 8 73 2.6. Scope of Property Map . . . . . . . . . . . . . . . . . . 8 74 2.7. Entity Hierarchy and Property Inheritance . . . . . . . . 9 75 3. Protocol Specification: Basic Data Type . . . . . . . . . . . 10 76 3.1. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 10 77 3.1.1. Entity Domain Type . . . . . . . . . . . . . . . . . 10 78 3.1.2. Entity Domain Name . . . . . . . . . . . . . . . . . 10 79 3.1.3. Entity Identifier . . . . . . . . . . . . . . . . . . 11 80 3.1.4. Hierarchy and Inheritance . . . . . . . . . . . . . . 12 81 3.2. Entity Property . . . . . . . . . . . . . . . . . . . . . 12 82 3.2.1. Entity Property Type . . . . . . . . . . . . . . . . 12 83 3.2.2. Entity Property Name . . . . . . . . . . . . . . . . 13 84 3.3. Information Resource Export . . . . . . . . . . . . . . . 13 85 3.3.1. Resource-Specific Entity Domain Export . . . . . . . 13 86 3.3.2. Entity Property Mapping Export . . . . . . . . . . . 14 87 4. Entity Domain Types . . . . . . . . . . . . . . . . . . . . . 14 88 4.1. Internet Address Domain Types . . . . . . . . . . . . . . 14 89 4.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 14 90 4.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 15 91 4.1.3. Hierarchy and Inheritance of Internet Address Domains 15 92 4.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 16 93 4.2.1. Entity Domain Type . . . . . . . . . . . . . . . . . 16 94 4.2.2. Domain-Specific Entity Identifiers . . . . . . . . . 16 95 4.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 17 96 4.2.4. Relationship To Internet Addresses Domains . . . . . 17 97 4.3. Internet Address Properties vs. PID Properties . . . . . 17 98 5. Entity Domains and Property Mappings in Information Resources 17 99 5.1. Network Map Resource . . . . . . . . . . . . . . . . . . 17 100 5.1.1. Resource-Specific Entity Domain . . . . . . . . . . . 18 101 5.1.2. Entity Property Mapping . . . . . . . . . . . . . . . 18 102 5.2. Endpoint Property Resource . . . . . . . . . . . . . . . 18 103 5.2.1. Resource-Specific Entity Domain . . . . . . . . . . . 18 104 5.2.2. Entity Property Mapping . . . . . . . . . . . . . . . 19 105 5.3. Property Map Resource . . . . . . . . . . . . . . . . . . 19 106 6. Property Map . . . . . . . . . . . . . . . . . . . . . . . . 19 107 6.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 19 108 6.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 19 109 6.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 19 110 6.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 19 111 6.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 20 112 6.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 20 113 7. Filtered Property Map . . . . . . . . . . . . . . . . . . . . 21 114 7.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 21 115 7.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 21 116 7.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 21 117 7.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 22 118 7.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 22 119 7.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 22 120 8. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 24 121 8.1. Impact on Endpoint Property Service . . . . . . . . . . . 24 122 8.2. Impact on Resource-Specific Properties . . . . . . . . . 24 123 8.3. Impact on the pid Property . . . . . . . . . . . . . . . 25 124 8.4. Impact on Other Properties . . . . . . . . . . . . . . . 25 125 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 126 9.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 25 127 9.2. Property Definitions . . . . . . . . . . . . . . . . . . 26 128 9.3. Information Resource Directory (IRD) . . . . . . . . . . 27 129 9.4. Property Map Example . . . . . . . . . . . . . . . . . . 29 130 9.5. Filtered Property Map Example #1 . . . . . . . . . . . . 30 131 9.6. Filtered Property Map Example #2 . . . . . . . . . . . . 31 132 9.7. Filtered Property Map Example #3 . . . . . . . . . . . . 32 133 9.8. Filtered Property Map Example #4 . . . . . . . . . . . . 33 134 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34 135 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 136 11.1. application/alto-* Media Types . . . . . . . . . . . . . 35 137 11.2. ALTO Entity Domain Type Registry . . . . . . . . . . . . 36 138 11.2.1. Consistency Procedure between ALTO Address Type 139 Registry and ALTO Entity Domain Registry . . . . . . 37 140 11.2.2. ALTO Entity Domain 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 . . . . . . . . . . . . . . . . . . . . 40 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 two 158 limitations. 160 First, it allows properties to be associated with only a particular 161 domain of entities, namely individual IP addresses. It is reasonable 162 to think that collections of endpoints, as defined by CIDRs [RFC4632] 163 or PIDs, may also have properties. Since the EPS cannot be extended 164 to new entity domains, new services, with new request and response 165 messages, would have to be defined for new entity domains. 167 Second, the EPS is only defined as a POST-mode service. Clients must 168 request the properties for an explicit set of endpoint addresses. By 169 contrast, [RFC7285] defines a GET-mode cost map resource which 170 returns all available costs, so a client can get a full set of costs 171 once, and then processes costs lookups without querying the ALTO 172 server. [RFC7285] does not define an equivalent service for endpoint 173 properties. At first a map of endpoint properties might seem 174 impractical, because it could require enumerating the property value 175 for every possible endpoint. But in practice, it is highly unlikely 176 that properties will be defined for every endpoint address. It is 177 much more likely that properties may be defined for only a subset of 178 endpoint addresses, and the specification of properties uses an 179 aggregation representation to allow enumeration. This is 180 particularly true if blocks of endpoint addresses with a common 181 prefix (e.g., a CIDR) have the same value for a property. Entities 182 in other domains may very well allow aggregated representation and 183 hence be enumerable as well. 185 This document specifies a new approach for defining and retrieving 186 ALTO properties to address the two limitations. Specifically, this 187 document addresses the first limitation by introducing a generic 188 concept called ALTO Entity Domains, where an entity is a 189 generalization of an endpoint to also represent, a PID, a network 190 element, or a cell in a cellular network, etc. As a consequence, 191 ALTO Entity Domains defined in this document are a super-set of ALTO 192 Address Types defined in [RFC7285]. Their exact relationship is 193 specified in Section 11.2.1. 195 Entity domains and property names are extensible. New entity domains 196 can be defined without revising the messages defined in this 197 document, in the same way that new cost metrics and new endpoint 198 properties can be defined without revising the messages defined in 199 [RFC7285]. 201 Additional, this document addresses the second limitation by defining 202 two new types of resources, namely Property Map (see Section 6) and 203 Filtered Property Map (see Section 7). The former is a GET-mode 204 resource which returns the property values for all entities in a 205 domain, and is analogous to a network map or a cost map in [RFC7285]. 206 The latter is a POST-mode resource which returns the values for a set 207 of properties and entities requested by the client, and is analogous 208 to a filtered network map or a filtered cost map. 210 This document subsumes the Endpoint Property Service defined in 211 [RFC7285], although that service may be retained for legacy clients 212 (see Section 8). 214 2. Overview: Basic Concepts 216 Before we define the specification of unified properties, there are 217 several basic concepts which we need to introduce. 219 2.1. Entity 221 The entity concept generalizes the concept of the endpoint defined in 222 Section 2.1 of [RFC7285]. An entity is an object that can be an 223 endpoint and is identified by its network address, but can also be an 224 object that has a defined mapping to a set of one or more network 225 addresses or is even not related to any network address. 227 Examples of eligible entities are: 229 o a PID, defined in [RFC7285], that has a provider defined human 230 readable abstract identifier defined by a ALTO network map, which 231 maps a PID to a set of ipv4 and ipv6 addresses; 233 o an autonomous system (AS), that has an AS number (ASN) as its 234 identifier and maps to a set of ipv4 and ipv6 addresses; 236 o a region representing a country, that is identified by its country 237 code defined by ISO 3166 and maps to a set of cellular addresses; 239 o a TCP/IP network flow, that has a server defined identifier 240 consisting of the defining TCP/IP 5-Tuple, , which is an example 241 that all endpoints are entities while not all entities are 242 endpoints; 244 o a routing element, that is specified in [RFC7921] and includes 245 routing capability information; 247 o an abstract network element, that has a server defined identifier 248 and represents a network node, link or their aggregation. 250 2.2. Entity Property 252 An entity property defines a property of an entity. It is similar to 253 the endpoint property defined by Section 7.1 of [RFC7285], but can be 254 general besides network-aware. 256 For example, 258 o an "ipv4" entity may have a property whose value is an Autonomous 259 System (AS) number indicating the AS which this IPv4 address is 260 owned by; 262 o a "pid" entity may have a property which indicates the central 263 geographical location of endpoints included by it. 265 2.3. Property Map 267 An ALTO property map provides a set of properties for a set of 268 entities. These entities may be in different types. For example, an 269 ALTO property map may define the ASN property for both "ipv4" and 270 "ipv6" entities. 272 2.4. Information Resource 274 This document uses the same definition of the information resource as 275 defined by [RFC7285]. Each information resource usually has a JSON 276 format representation following a specific schema defined by its 277 media type. 279 For example, an ALTO network map resource is represented by a JSON 280 objectof type InfoResourceNetworkMap defined by the media type 281 "application/alto-networkmap+json". 283 2.5. Entity Domain 285 An entity domain defines a set of entities in the same type. This 286 type is also called the type of this entity domain. 288 Using entity domains, an ALTO property map can indicate which 289 entities the ALTO client can query to get their properties. 291 2.5.1. Resource-Specific Entity Domain 293 To define an entity domain, one naive solution is to enumerate all 294 entities in this entity domain. But it is inefficient when the size 295 of the entity domain is large. 297 To avoid enumerating all entities, this document introduces an 298 approach called "Resource-Specific Entity Domain" to define entity 299 domains: 301 Each information resource may define several types of entity domains. 302 And for each type of entity domain, an information resource can 303 define at most one entity domain. For example, an ALTO netowrk map 304 resource can define an IPv4 domain, an IPv6 domain and a pid domain. 305 In this document, these entity domains are called resource-specific 306 entity domains. An ALTO property map only need to indicate which 307 types of entity domain defined by which information resources can be 308 queried, the ALTO client will know which entities are effective to be 309 queried. 311 2.5.2. Relationship between Entity and Entity Domain 313 In this document, an entity is owned by exact one entity domain. It 314 requires that when an ALTO client or server references an entity, it 315 must indicate its entity domain explicitly. Even two entities in two 316 different entity domains may reflect to the same physical or logical 317 object, we treat them as different entities. 319 Because of this rule, although the resource-specific entity domain 320 approach has no ambiguity, it may introduce redundancy. 322 2.5.3. Aggregated Entity Domain 324 Two entities in two different resource-specific entity domains may 325 reflect to the same physical or logical object. For example, the 326 IPv4 entity "192.0.2.34" in the IPv4 domain of the network map 327 "netmap1" and the IPv4 entity "192.0.2.34" in the IPv4 domain of the 328 network map "netmap2" should indicate the same Internet endpoint 329 addressed by the IPv4 address "192.0.2.34". 331 Each entity in each resource-specific entity domain may only have 332 part of properties of its associated physical or logical object. For 333 example, the IPv4 entity in the IPv4 domain of the network map 334 "netmap1" only has the PID property defined by "netmap1"; same to the 335 IPv4 entity in the IPv4 domain of the network map "netmap2". If the 336 ALTO client wants to get the complete properties, using the resource- 337 specific entity domain, the ALTO client has to query the IPv4 entity 338 "192.0.2.34" twice. 340 To simplify the query process of the ALTO client, this document 341 introduces the concept "Aggregated Entity Domain". An aggregated 342 entity domain defines an aggregated set of entities coming from 343 multiple resource-specific entity domains in the same type. An 344 entity in the aggregated entity domain includes all properties 345 defined for the associated entity in each associated resource- 346 specific entity domains. For example, the IPv4 entity "192.0.2.34" 347 in the aggregated entity domain between the IPv4 domain of "netmap1" 348 and the IPv4 domain of "netmap2" has PID properties defined by both 349 "netmap1" and "netmap2". 351 2.5.4. Resource-Specific Entity Property 353 According to the example of the aggregated entity domain, an entity 354 may have multiple properties in the same type but associated to 355 different information resources. To distinguish them, this document 356 uses the same approach proposed by Section 10.8.1 of [RFC7285], which 357 is called "Resource-Specific Entity Property". 359 2.6. Scope of Property Map 361 Using entity domains to organize entities, an ALTO property map 362 resource actually provides a set of properties for some entity 363 domains. If we ignore the syntax sugar of the aggregated entity 364 domain, we can consider an ALTO property map resource just provides a 365 set of (ri, di) => (ro, po) mappings, where (ri, di) means a 366 resource-specific entity domain of type di defined by the information 367 resource ri, and (ro, po) means a resource-specific entity property 368 po defined by the information resource ro. 370 For each (ri, di) => (ro, po) mapping, the scope of an ALTO property 371 map resource must be one of cases in the following diagram: 373 domain.resource domain.resource 374 (ri) = r (ri) = this 375 +-----------------|-----------------+ 376 prop.resource | Export | Non-exist | 377 (ro) = r | | | 378 +-----------------|-----------------+ 379 prop.resource | Extend | Define | 380 (ro) = this | | | 381 +-----------------|-----------------+ 383 where "this" points to the resulting property map resource, "r" 384 presents an existing ALTO information resource other the resulting 385 property map resource. 387 o ri = ro = r ("export" mode): the property map resource just 388 transforms the property mapping di => po defined by r into the 389 unified representation format and exports it. For example: r = 390 "netmap1", di = "ipv4", po = "pid". The property map resource 391 exports the "ipv4 => pid" mapping defined by "netmap1". 393 o ri = r, ro = this ("extend" mode): the property map extends 394 properties of entities in the entity domain (r, di) and defines a 395 new property po on them. For example: the property map resource 396 ("this") defines a "geolocation" property on domain "netmap1.pid". 398 o ri = ro = this ("define" mode): the property map defines a new 399 intrinsic entity domain and defines property po for each entities 400 in this domain. For example: the property map resource ("this") 401 defines a new entity domain "asn" and defines a property 402 "ipprefixes" on this domain. 404 o ri = this, ro = r: in the scope of a property map resource, it 405 does not make sense that another existing ALTO information 406 resource defines a property for this property map resource. 408 2.7. Entity Hierarchy and Property Inheritance 410 Enumerating all individual effective entities are inefficient. Some 411 types of entities have the hierarchy format, e.g., cidr, which stand 412 for sets of individual entities. Many entities in the same 413 hierarchical format entity sets may have the same proprety values. 414 To reduce the size of the property map representation, this document 415 introduces an approach called "Property Inheritance". Individual 416 entities can inherit the property from its hierarchical format entity 417 set. 419 3. Protocol Specification: Basic Data Type 421 3.1. Entity Domain 423 3.1.1. Entity Domain Type 425 An entity domain has a type, which is defined by a string that MUST 426 be no more than 64 characters, and MUST NOT contain characters other 427 than US-ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, 428 and U+0061-U+007A), hyphen ("-", U+002D), and low line ("_", U+005F). 429 For example, the strings "ipv4", "ipv6", and "pid" are valid entity 430 domain types. 432 The type EntityDomainType is used in this document to denote a JSON 433 string confirming to the preceding requirement. 435 An entity domain type defines the semantics of a type of entity 436 domains. Each entity domain type MUST be registered with the IANA. 437 The format of the entity identifiers (see Section 3.1.3) in that type 438 of entity domains, as well as any hierarchical or inheritance rules 439 (see Section 3.1.4) for those entities, MUST be specified at the same 440 time. 442 3.1.2. Entity Domain Name 444 Each entity domain is identified by an entity domain name, a string 445 of the following format: 447 EntityDomainName ::= [ [ ResourceID ] '.' ] EntityDomainType 449 This document distinguish three types of entity domains: resource- 450 specific entity domains, self-defined entity domain and aggregated 451 entity domains. Their entity domain names are derived as follows. 453 Each ALTO information resource MAY define a resource-specific entity 454 domain (which could be empty) in a given entity domain type. A 455 resource-specific entity domain is identified by an entity domain 456 name derived as follows. It MUST start with a resource ID using the 457 ResourceID type defined in [RFC7285], followed by the "." separator 458 (U+002E), followed by an EntityDomainType typed string. For example, 459 if an ALTO server provides two network maps "netmap-1" and "netmap- 460 2", they can define two different "pid" domains identified by 461 "netmap-1.pid" and "netmap-2.pid" respectively. To be simplified, in 462 the scope of a specific information resource, the resource-specific 463 entity domain defined by itself can be identified by the "." 464 EntityDomainTyep without the ResourceID. 466 When the associated information resource of a resource-specific 467 entity domain is the current information resource itself, this 468 resource-specific entity domain is a self-defined entity domain, and 469 its ResourceID SHOULD be ignored from its entity domain name. 471 Given a set of ALTO information resources, there MAY be an aggregated 472 entity domain in a given entity domain type amongst them. An 473 aggregated entity domain is simply identified by its entity domain 474 type. For example, given two network maps "net-map-1" and "net-map- 475 2", "ipv4" and "ipv6" identify two aggregated Internet address entity 476 domains (see Section 4.1) between them. 478 Note that the "." separator is not allowed in EntityDomainType and 479 hence there is no ambiguity on whether an entity domain name refers 480 to a global entity domain or a resource-specific entity domain. 482 3.1.3. Entity Identifier 484 Entities in an entity domain are identified by entity identifiers 485 (EntityID) of the following format: 487 EntityID ::= EntityDomainName ':' DomainTypeSpecificEntityID 489 Examples from the Internet address entity domains include individual 490 IP addresses such as "net1.ipv4:192.0.2.14" and 491 "net1.ipv6:2001:db8::12", as well as address blocks such as 492 "net1.ipv4:192.0.2.0/26" and "net1.ipv6:2001:db8::1/48". 494 The format of the second part of an entity identifier depends on the 495 entity domain type, and MUST be specified when registering a new 496 entity domain type. Identifiers MAY be hierarchical, and properties 497 MAY be inherited based on that hierarchy. Again, the rules defining 498 any hierarchy or inheritance MUST be defined when the entity domain 499 type is registered. 501 The type EntityID is used in this document to denote a JSON string 502 representing an entity identifier in this format. 504 Note that two entity identifiers with different textual 505 representations may refer to the same entity, for a given entity 506 domain. For example, the strings "net1.ipv6:2001:db8::1" and 507 "net1.ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity in the 508 "ipv6" entity domain. 510 3.1.4. Hierarchy and Inheritance 512 To make the representation efficient, some types of entity domains 513 MAY allow the ALTO client/server to use a hierarchical format entity 514 identifier to represent a block of individual entities. e.g., In an 515 IPv4 domain "net1.ipv4", a cidr "net1.ipv4:192.0.2.0/26" represents 516 64 individual IPv4 entities. In this case, the corresponding 517 property inheritance rule MUST be defined for the entity domain type. 518 The hierarchy and inheritance rule MUST have no ambiguity. 520 3.2. Entity Property 522 Each entity property has a type to indicate the encoding and the 523 semantics of the value of this entity property, and has a name to be 524 identified. One entity MAY have multiple properties in the same 525 type. 527 3.2.1. Entity Property Type 529 The type EntityPropertyType is used in this document to indicate a 530 string denoting an entity property type. The string MUST be no more 531 than 32 characters, and it MUST NOT contain characters other than US- 532 ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 533 U+0061-U+007A), the hyphen ("-", U+002D), the colon (":", U+003A), or 534 the low line ('_', U+005F). 536 Each entity property type MUST be registered with the IANA. The 537 intended semantics of the entity property type MUST be specified at 538 the same time. 540 To distinguish with the endpoint property type, the entity property 541 type has the following features. 543 o Some entity property types may be applicable to entities in only 544 particular types of entity domains, not all. For example, the 545 "pid" property is not applicable to entities in a "pid" typed 546 entity domain, but is applicable to entities in the "ipv4" or 547 "ipv6" domains. 549 o The intended semantics of the value of a entity property may also 550 depend on the the entity domain type of this entity. For example, 551 suppose that the "geo-location" property is defined as the 552 coordinates of a point, encoded as (say) "latitude longitude 553 [altitude]." When applied to an entity that represents a specific 554 host computer, identified by an address in the "ipv4" or "ipv6" 555 entity domain, the property defines the host's location. However, 556 when applied to an entity in a "pid" domain, the property would 557 indicate the location of the center of all hosts in this "pid" 558 entity. 560 3.2.2. Entity Property Name 562 Each entity property is identified by an entity property name, which 563 is a string of the following format: 565 EntityPropertyName ::= [ ResourceID ] '.' EntityPropertyType 567 Similar to the endpoint property type defined in Section 10.8 of 568 [RFC7285], each entity property may be defined by either the property 569 map itself (self-defined) or some other specific information resource 570 (resource-specific). 572 The entity property name of a resource-specific entity property 573 starts with a string of the type ResourceID defined in [RFC7285], 574 followed by the "." separator (U+002E) and a EntityDomainType typed 575 string. For example, the "pid" properties of an "ipv4" entity 576 defined by two different maps "net-map-1" and "net-map-2" are 577 identified by "net-map-1.pid" and "net-map-2.pid" respectively. 579 When the associated information resource of the entity property is 580 the current information resource itself, the ResourceID in the 581 property name SHOULD be ignored. For example, the ".asn" property of 582 an "ipv4" entity indicates the AS number of the AS which this IPv4 583 address is owned by. 585 3.3. Information Resource Export 587 Each information resource MAY export a set of entity domains and 588 entity property mappings. 590 3.3.1. Resource-Specific Entity Domain Export 592 Each type of information resource MAY export several types of entity 593 domains. For example, a network map resource defines a "pid" domain, 594 a "ipv4" domain and a "ipv6" domain (which may be empty). 596 When a new ALTO information resource type is registered, if this type 597 of information resource can export an existing type of entity domain, 598 the corresponding document MUST define how to export such type of 599 entity domain from such type of information resource. 601 When a new entity domain type is defined, if an existing type of 602 information resource can export an entity domain in this entity 603 domain type, the corresponding document MUST define how to export 604 such type of entity domain from such type of information resource. 606 3.3.2. Entity Property Mapping Export 608 For each entity domain which could be exported by an information 609 resource, this information resource MAY also export some mapping from 610 this entity domain to some entity property. For example, a network 611 map resource can map an "ipv4" entity to its "pid" property. 613 When a new ALTO information resource type is registered, if this type 614 of information resource can export an entity domain in an existing 615 entity domain type, and map entities in this entity domain to an 616 existing type of entity property, the corresponding document MUST 617 define how to export such type of an entity property. 619 When a new ALTO entity domain type or a new entity property type is 620 defined, if an existing type of resource can export an entity domain 621 in this entity domain type, and map entities in this entity domain to 622 this type of entity property, the corresponding document MUST define 623 how to export such type of an entity property. 625 4. Entity Domain Types 627 This document defines three entity domain types. The definition of 628 each entity domain type below includes the following: (1) entity 629 domain type name, (2) entity domain-specific entity identifiers, and 630 (3) hierarchy and inheritance semantics. Since a global entity 631 domain type defines a single global entity domain, we say entity 632 domain instead of entity domain type. 634 4.1. Internet Address Domain Types 636 The document defines two entity domain types (IPv4 and IPv6) for 637 Internet addresses. Both types are global entity domain types and 638 hence define a corresponding global entity domain as well. Since the 639 two domains use the same hierarchy and inheritance semantics, we 640 define the semantics together, instead of repeating for each. 642 4.1.1. IPv4 Domain 644 4.1.1.1. Entity Domain Type 646 ipv4 648 4.1.1.2. Domain-Specific Entity Identifiers 650 Individual addresses are strings as specified by the IPv4Addresses 651 rule of Section 3.2.2 of [RFC3986]; blocks of addresses are prefix- 652 match strings as specified in Section 3.1 of [RFC4632]. For the 653 purpose of defining properties, an individual Internet address and 654 the corresponding full-length prefix are considered aliases for the 655 same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are 656 equivalent. 658 4.1.2. IPv6 Domain 660 4.1.2.1. Entity Domain Type 662 ipv6 664 4.1.2.2. Domain-Specific Entity Identifiers 666 Individual addresses are strings as specified by Section 4 of 667 [RFC5952]; blocks of addresses are prefix-match strings as specified 668 in Section 7 of [RFC5952]. For the purpose of defining properties, 669 an individual Internet address and the corresponding 128-bit prefix 670 are considered aliases for the same entity. That is, 671 "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and 672 have the same set of properties. 674 4.1.3. Hierarchy and Inheritance of Internet Address Domains 676 Both Internet address domains allow property values to be inherited. 677 Specifically, if a property P is not defined for a specific Internet 678 address I, but P is defined for some block C which prefix-matches I, 679 then the address I inherits the value of P defined for block C. If 680 more than one such block defines a value for P, I inherits the value 681 of P in the block with the longest prefix. It is important to notice 682 that this longest prefix rule will ensure no multiple inheritance, 683 and hence no ambiguity. 685 Address blocks can also inherit properties: if a property P is not 686 defined for a block C, but is defined for some block C' which covers 687 all IP addresses in C, and C' has a shorter mask than C, then block C 688 inherits the property from C'. If there are several such blocks C', 689 C inherits from the block with the longest prefix. 691 As an example, suppose that a server defines a property P for the 692 following entities: 694 ipv4:192.0.2.0/26: P=v1 695 ipv4:192.0.2.0/28: P=v2 696 ipv4:192.0.2.0/30: P=v3 697 ipv4:192.0.2.0: P=v4 699 Figure 1: Defined Property Values. 701 Then the following entities have the indicated values: 703 ipv4:192.0.2.0: P=v4 704 ipv4:192.0.2.1: P=v3 705 ipv4:192.0.2.16: P=v1 706 ipv4:192.0.2.32: P=v1 707 ipv4:192.0.2.64: (not defined) 708 ipv4:192.0.2.0/32: P=v4 709 ipv4:192.0.2.0/31: P=v3 710 ipv4:192.0.2.0/29: P=v2 711 ipv4:192.0.2.0/27: P=v1 712 ipv4:192.0.2.0/25: (not defined) 714 Figure 2: Inherited Property Values. 716 An ALTO server MAY explicitly indicate a property as not having a 717 value for a particular entity. That is, a server MAY say that 718 property P of entity X is "defined to have no value", instead of 719 "undefined". To indicate "no value", a server MAY perform different 720 behaviours: 722 o If that entity would inherit a value for that property, then the 723 ALTO server MUST return a "null" value for that property. In this 724 case, the ALTO client MUST recognize a "null" value as "no value" 725 and "do not apply the inheritance rules for this property." 727 o If the entity would not inherit a value, then the ALTO server MAY 728 return "null" or just omit the property. In this case, the ALTO 729 client cannot infer the value for this property of this entity 730 from the Inheritance rules. So the client MUST interpret that 731 this property has no value. 733 If the ALTO server does not define any properties for an entity, then 734 the server MAY omit that entity from the response. 736 4.2. PID Domain 738 The PID domain associates property values with the PIDs in a network 739 map. Accordingly, this entity domain always depends on a network 740 map. 742 4.2.1. Entity Domain Type 744 pid 746 4.2.2. Domain-Specific Entity Identifiers 748 The entity identifiers are the PID names of the associated network 749 map. 751 4.2.3. Hierarchy and Inheritance 753 There is no hierarchy or inheritance for properties associated with 754 PIDs. 756 4.2.4. Relationship To Internet Addresses Domains 758 The PID domain and the Internet address domains are completely 759 independent; the properties associated with a PID have no relation to 760 the properties associated with the prefixes or endpoint addresses in 761 that PID. An ALTO server MAY choose to assign some or all properties 762 of a PID to the prefixes in that PID. 764 For example, suppose "PID1" consists of the prefix 765 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 766 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24", 767 in the IPv4 domain MAY have a value for the property "P", and if they 768 do, it is not necessarily "v1". 770 4.3. Internet Address Properties vs. PID Properties 772 Because the Internet address and PID domains are completely separate, 773 the question may arise as to which entity domain is the best for a 774 property. In general, the Internet address domains are RECOMMENDED 775 for properties that are closely related to the Internet address, or 776 are associated with, and inherited through, blocks of addresses. 778 The PID domain is RECOMMENDED for properties that arise from the 779 definition of the PID, rather than from the Internet address prefixes 780 in that PID. 782 For example, because Internet addresses are allocated to service 783 providers by blocks of prefixes, an "ISP" property would be best 784 associated with the Internet address domain. On the other hand, a 785 property that explains why a PID was formed, or how it relates a 786 provider's network, would best be associated with the PID domain. 788 5. Entity Domains and Property Mappings in Information Resources 790 5.1. Network Map Resource 792 The ALTO network map resource defined by the media type "application/ 793 alto-networkmap+json" exports the following types of entity domains 794 and entity property mappings. 796 5.1.1. Resource-Specific Entity Domain 798 An ALTO network map resource defines a "pid" domain, an "ipv4" domain 799 and an "ipv6" domain by follows: 801 o The defined "pid" domain includes all PIDs in keys of the 802 "network-map" object. 804 o The defined "ipv4" domain includes all IPv4 addresses appearing in 805 the "ipv4" field of the endpoint address group of each PID. 807 o The defined "ipv6" domain includes all IPv6 addresses appearing in 808 the "ipv6" field of the endpoint address group of each PID. 810 5.1.2. Entity Property Mapping 812 For each of the preceding entity domains, an ALTO network map 813 resource provides the properties mapping as follows: 815 ipv4 -> pid: An "networkmap" typed resource can map an "ipv4" entity 816 to a "pid" property whose value is a PID defined by this 817 "networkmap" resource and including the IPv4 address of this 818 entity. 820 ipv6 -> pid: An "networkmap" typed resource can map an "ipv6" entity 821 to a "pid" property whose value is a PID defined by this 822 "networkmap" resource and including the IPv6 address of this 823 entity. 825 5.2. Endpoint Property Resource 827 The ALTO endpoint property resource defined by the media type 828 "application/alto-endpointprop+json" exports the following types of 829 entity domains and entity property mappings. 831 5.2.1. Resource-Specific Entity Domain 833 An ALTO endpoint property resource defined an "ipv4" domain and an 834 "ipv6" domain by follows: 836 o The defined "ipv4" domain includes all IPv4 addresses appearing in 837 keys of the "endpoint-properties" object. 839 o The defined "ipv6" domain includes all IPv6 addresses appearing in 840 keys of the "endpoint-properties" object. 842 5.2.2. Entity Property Mapping 844 For each of the preceding entity domains, an ALTO endpoint property 845 resource exports the properties mapping from it to each supported 846 global endpoint property. The property value is the corresponding 847 global endpoint property value in the "endpiont-properties" object. 849 5.3. Property Map Resource 851 To avoid the nested reference and its potential complexity, this 852 document does not specify the export rule of resource-specific entity 853 domain and entity property mapping for the ALTO property map resource 854 defined by the media type "application/alto-propmap+json" (see 855 Section 6.1). 857 6. Property Map 859 A property map returns the properties defined for all entities in one 860 or more domains, e.g., the "location" property of entities in "pid" 861 domain, and the "ASN" property of entities in "ipv4" and "ipv6" 862 domains. 864 Section 9.4 gives an example of a property map request and its 865 response. 867 6.1. Media Type 869 The media type of a property map is "application/alto-propmap+json". 871 6.2. HTTP Method 873 The property map is requested using the HTTP GET method. 875 6.3. Accept Input Parameters 877 None. 879 6.4. Capabilities 881 The capabilities are defined by an object of type 882 PropertyMapCapabilities: 884 object { 885 EntityPropertyMapping mappings; 886 } PropertyMapCapabilities; 888 object-map { 889 EntityDomainName -> EntityPropertyName<1..*>; 890 } EntityPropertyMapping 892 with fields: 894 mappings: A JSON object whose keys are names of entity domains and 895 values are the supported entity properties of the corresponding 896 entity domains. 898 6.5. Uses 900 The "uses" field of a property map resource in an IRD entry specifies 901 dependent resources of this property map. It is an array of the 902 resource ID(s) of the resource(s). 904 6.6. Response 906 If the entity domains in this property map depend on other resources, 907 the "dependent-vtags" field in the "meta" field of the response MUST 908 be an array that includes the version tags of those resources, and 909 the order MUST be consistent with the "uses" field of this property 910 map resource. The data component of a property map response is named 911 "property-map", which is a JSON object of type PropertyMapData, 912 where: 914 object { 915 PropertyMapData property-map; 916 } InfoResourceProperties : ResponseEntityBase; 918 object-map { 919 EntityID -> EntityProps; 920 } PropertyMapData; 922 object { 923 EntityPropertyName -> JSONValue; 924 } EntityProps; 926 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 928 Specifically, a PropertyMapData object has one member for each entity 929 in the property map. The entity's properties are encoded in the 930 corresponding EntityProps object. EntityProps encodes one name/value 931 pair for each property, where the property names are encoded as 932 strings of type PropertyName. A protocol implementation SHOULD 933 assume that the property value is either a JSONString or a JSON 934 "null" value, and fail to parse if it is not, unless the 935 implementation is using an extension to this document that indicates 936 when and how property values of other data types are signaled. 938 For each entity in the property map: 940 o If the entity is in a resource-specific entity domain, the ALTO 941 server SHOULD only return self-defined properties and resource- 942 specific properties which depend on the same resource as the 943 entity does. The ALTO client SHOULD ignore the resource-specific 944 property in this entity if their mapping is not registered in the 945 ALTO Resource Entity Property Transfer Registry of the type of the 946 corresponding resource. 948 o If the entity is in a shared entity domain, the ALTO server SHOULD 949 return self-defined properties and all resource-specific 950 properties defined for all resource-specific entities which have 951 the same domain-specific entity identifier as this entity does. 953 For efficiency, the ALTO server SHOULD omit property values that are 954 inherited rather than explicitly defined; if a client needs inherited 955 values, the client SHOULD use the entity domain's inheritance rules 956 to deduce those values. 958 7. Filtered Property Map 960 A filtered property map returns the values of a set of properties for 961 a set of entities selected by the client. 963 Section 9.5, Section 9.6, Section 9.7 and Section 9.8 give examples 964 of filtered property map requests and responses. 966 7.1. Media Type 968 The media type of a property map resource is "application/alto- 969 propmap+json". 971 7.2. HTTP Method 973 The filtered property map is requested using the HTTP POST method. 975 7.3. Accept Input Parameters 977 The input parameters for a filtered property map request are supplied 978 in the entity body of the POST request. This document specifies the 979 input parameters with a data format indicated by the media type 980 "application/alto-propmapparams+json", which is a JSON object of type 981 ReqFilteredPropertyMap: 983 object { 984 EntityID entities<1..*>; 985 EntityPropertyName properties<1..*>; 986 } ReqFilteredPropertyMap; 988 with fields: 990 entities: List of entity identifiers for which the specified 991 properties are to be returned. The ALTO server MUST interpret 992 entries appearing multiple times as if they appeared only once. 993 The domain of each entity MUST be included in the list of entity 994 domains in this resource's "capabilities" field (see Section 7.4). 996 properties: List of properties to be returned for each entity. Each 997 specified property MUST be included in the list of properties in 998 this resource's "capabilities" field (see Section 7.4). The ALTO 999 server MUST interpret entries appearing multiple times as if they 1000 appeared only once. 1002 Note that the "entities" and "properties" fields MUST have at 1003 least one entry each. 1005 7.4. Capabilities 1007 The capabilities are defined by an object of type 1008 PropertyMapCapabilities, as defined in Section 6.4. 1010 7.5. Uses 1012 Same to the "uses" field of the Property Map resource (see 1013 Section 6.5). 1015 7.6. Response 1017 The response MUST indicate an error, using ALTO protocol error 1018 handling, as defined in Section 8.5 of [RFC7285], if the request is 1019 invalid. 1021 Specifically, a filtered property map request can be invalid as 1022 follows: 1024 o An entity identifier in "entities" in the request is invalid if: 1026 * The domain of this entity is not defined in the "entity- 1027 domains" capability of this resource in the IRD; 1029 * The entity identifier is an invalid identifier in the entity 1030 domain. 1032 A valid entity identifier is never an error, even if this filtered 1033 property map resource does not define any properties for it. 1035 If an entity identifier in "entities" in the request is invalid, 1036 the ALTO server MUST return an "E_INVALID_FIELD_VALUE" error 1037 defined in Section 8.5.2 of [RFC7285], and the "value" field of 1038 the error message SHOULD indicate this entity identifier. 1040 o A property name in "properties" in the request is invalid if this 1041 property name is not defined in the "properties" capability of 1042 this resource in the IRD. 1044 It is not an error that a filtered property map resource does not 1045 define a requested property's value for a particular entity. In 1046 this case, the ALTO server MUST omit that property from the 1047 response for that endpoint. 1049 If a property name in "properties" in the request is invalid, the 1050 ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined 1051 in Section 8.5.2 of [RFC7285]. The "value" field of the error 1052 message SHOULD indicate the property name. 1054 The response to a valid request is the same as for the Property Map 1055 (see Section 6.6), except that: 1057 o If the requested entities include entities in the shared entity 1058 domain, the "dependent-vtags" field in its "meta" field MUST 1059 include version tags of all dependent resources appearing in the 1060 "uses" field. 1062 o If the requested entities only include entities in resource- 1063 specific entity domains, the "dependent-vtags" field in its "meta" 1064 field MUST include version tags of resources which requested 1065 resource-specific entity domains and requested resource-specific 1066 properties are dependent on. 1068 o The response only includes the entities and properties requested 1069 by the client. If an entity in the request is identified by a 1070 hierarchical identifier (e.g., an "ipv4" or "ipv6" address block), 1071 the response MUST cover properties for all identifiers in this 1072 hierarchical identifier. 1074 It is important that the filtered property map response MUST include 1075 all inherited property values for the requested entities and all the 1076 entities which are able to inherit property values from them. To 1077 achieve this goal, the ALTO server MAY follow three rules: 1079 o If a property for a requested entity is inherited from another 1080 entity not included in the request, the response SHOULD include 1081 this property for the requested entity. For example, A full 1082 property map may skip a property P for an entity A (e.g., 1083 ipv4:192.0.2.0/31) if P can be derived using inheritance from 1084 another entity B (e.g., ipv4:192.0.2.0/30). A filtered property 1085 map request may include only A but not B. In such a case, the 1086 property P SHOULD be included in the response for A. 1088 o If there are entities covered by a requested entity but having 1089 different values for the requested properties, the response SHOULD 1090 include all those entities and the different property values for 1091 them. For example, considering a request for property P of entity 1092 A (e.g., ipv4:192.0.2.0/31), if P has value v1 for 1093 A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the 1094 response SHOULD include A1 and A2. 1096 o If an entity in the response is already covered by some other 1097 entities in the same response, it SHOULD be removed from the 1098 response for compactness. For example, in the previous example, 1099 the entity A=ipv4:192.0.2.0/31 SHOULD be removed because A1 and A2 1100 cover all the addresses in A. 1102 An ALTO client should be aware that the entities in the response MAY 1103 be different from the entities in its request. 1105 8. Impact on Legacy ALTO Servers and ALTO Clients 1107 8.1. Impact on Endpoint Property Service 1109 Since the property map and the filtered property map defined in this 1110 document provide the functionality of the Endpoint Property Service 1111 (EPS) defined in Section 11.4 of [RFC7285], it is RECOMMENDED that 1112 the EPS be deprecated in favor of Property Map and Filtered Property 1113 Map. However, ALTO servers MAY provide an EPS for the benefit of 1114 legacy clients. 1116 8.2. Impact on Resource-Specific Properties 1118 Section 10.8 of [RFC7285] defines two categories of endpoint 1119 properties: "resource-specific" and "global". Resource-specific 1120 property names are prefixed with the ID of the resource they depend 1121 upon, while global property names have no such prefix. The property 1122 map and the filtered property map defined in this document do not 1123 distinguish between those two types of properties. Instead, if there 1124 is a dependency, it is indicated by the "uses" capability of a 1125 property map, and is shared by all properties and entity domains in 1126 that map. Accordingly, it is RECOMMENDED that resource-specific 1127 endpoint properties be deprecated, and no new resource-specific 1128 endpoint properties be defined. 1130 8.3. Impact on the pid Property 1132 Section 7.1.1 of [RFC7285] defines the resource-specific endpoint 1133 property name "pid", whose value is the name of the PID containing 1134 that endpoint. For compatibility with legacy clients, an ALTO server 1135 which provides the "pid" property via the EPS MUST use that 1136 definition, and that syntax. 1138 However, when used with property maps, this document amends the 1139 definition of the "pid" property as follows. 1141 First, the name of the property is simply "pid"; the name is not 1142 prefixed with the resource ID of a network map. The "uses" 1143 capability of the property map indicates the associated network map. 1144 This implies that a property map can only return the "pid" property 1145 for one network map; if an ALTO server provides several network maps, 1146 it MUST provide a Property Map for each of the network maps. 1148 Second, a client MAY request the "pid" property for a block of 1149 Internet addresses. An ALTO server determines the value of "pid" for 1150 an address block C as the rules defined in Section 7.6. 1152 Note that although an ALTO server MAY provide a GET-mode property map 1153 which returns the entire map for the "pid" property, there is no need 1154 to do so, because that map is simply the inverse of the network map. 1156 8.4. Impact on Other Properties 1158 In general, there should be little or no impact on other previously 1159 defined properties. The only consideration is that properties can 1160 now be defined on blocks of identifiers, rather than just individual 1161 identifiers, which might change the semantics of a property. 1163 9. Examples 1165 9.1. Network Map 1167 The examples in this section use a very simple default network map: 1169 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1170 pid1: ipv4:192.0.2.0/25 1171 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 1172 pid3: ipv4:192.0.3.0/28 1173 pid4: ipv4:192.0.3.16/28 1175 Figure 3: Example Default Network Map 1177 And another simple alternative network map: 1179 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 1180 pid1: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 1181 pid2: ipv4:192.0.3.0/28 ipv4:192.0.3.16/28 1183 Figure 4: Example Alternative Network Map 1185 9.2. Property Definitions 1187 Beyond "pid", the examples in this section use four additional 1188 properties for Internet address domains, "ISP", "ASN", "country" and 1189 "state", with the following values: 1191 ISP ASN country state 1192 ipv4:192.0.2.0/23: BitsRus - us - 1193 ipv4:192.0.2.0/28: - 12345 - NJ 1194 ipv4:192.0.2.16/28: - 12345 - CT 1195 ipv4:192.0.2.0: - - - PA 1196 ipv4:192.0.3.0/28: - 12346 - TX 1197 ipv4:192.0.3.16/28: - 12346 - MN 1199 Figure 5: Example Property Values for Internet Address Domains 1201 And the examples in this section use the property "region" for the 1202 PID domain of the default network map with the following values: 1204 region 1205 pid:defaultpid: - 1206 pid:pid1: us-west 1207 pid:pid2: us-east 1208 pid:pid3: us-south 1209 pid:pid4: us-north 1211 Figure 6: Example Property Values for Default Network Map's PID 1212 Domain 1214 Note that "-" means the value of the property for the entity is 1215 "undefined". So the entity would inherit a value for this property 1216 by the inheritance rule if possible. For example, the value of the 1217 "ISP" property for "ipv4:192.0.2.0" is "BitsRus" because of 1218 "ipv4:192.0.2.0/24". But the "region" property for "pid:defaultpid" 1219 has no value because no entity from which it can inherit. 1221 Similar to the PID domain of the default network map, the examples in 1222 this section use the property "ASN" for the PID domain of the 1223 alternative network map with the following values: 1225 ASN 1226 pid:defaultpid: - 1227 pid:pid1: 12345 1228 pid:pid2: 12346 1230 Figure 7: Example Property Values for Alternative Network Map's PID 1231 Domain 1233 9.3. Information Resource Directory (IRD) 1235 The following IRD defines the relevant resources of the ALTO server. 1236 It provides two property maps, one for the "ISP" and "ASN" 1237 properties, and another for the "country" and "state" properties. 1238 The server could have provided a single property map for all four 1239 properties, but did not, presumably because the organization that 1240 runs the ALTO server believes any given client is not interested in 1241 all four properties. 1243 The server provides two filtered property maps. The first returns 1244 all four properties, and the second just returns the "pid" property 1245 for the default network map. 1247 The filtered property maps for the "ISP", "ASN", "country" and 1248 "state" properties do not depend on the default network map (it does 1249 not have a "uses" capability), because the definitions of those 1250 properties do not depend on the default network map. The Filtered 1251 Property Map for the "pid" property does have a "uses" capability for 1252 the default network map, because that defines the values of the "pid" 1253 property. 1255 Note that for legacy clients, the ALTO server provides an Endpoint 1256 Property Service for the "pid" property for the default network map. 1258 "meta" : { 1259 ... 1260 "default-alto-network-map" : "default-network-map" 1261 }, 1262 "resources" : { 1263 "default-network-map" : { 1264 "uri" : "http://alto.example.com/networkmap/default", 1265 "media-type" : "application/alto-networkmap+json" 1266 }, 1267 "alt-network-map" : { 1268 "uri" : "http://alto.example.com/networkmap/alt", 1269 "media-type" : "application/alto-networkmap+json" 1270 }, 1271 .... property map resources .... 1272 "ia-property-map" : { 1273 "uri" : "http://alto.example.com/propmap/full/inet-ia", 1274 "media-type" : "application/alto-propmap+json", 1275 "uses": [ "default-network-map", "alt-network-map" ], 1276 "capabilities" : { 1277 "mappings": { 1278 "ipv4": [ ".ISP", ".ASN" ], 1279 "ipv6": [ ".ISP", ".ASN" ] 1280 } 1281 } 1282 }, 1283 "iacs-property-map" : { 1284 "uri" : "http://alto.example.com/propmap/full/inet-iacs", 1285 "media-type" : "application/alto-propmap+json", 1286 "accepts": "application/alto-propmapparams+json", 1287 "uses": [ "default-network-map", "alt-network-map" ], 1288 "capabilities" : { 1289 "mappings": { 1290 "ipv4": [ ".ISP", ".ASN", ".country", ".state" ], 1291 "ipv6": [ ".ISP", ".ASN", ".country", ".state" ] 1292 } 1293 } 1294 }, 1295 "region-property-map": { 1296 "uri": "http://alto.exmaple.com/propmap/region", 1297 "media-type": "application/alto-propmap+json", 1298 "accepts": "application/alto-propmapparams+json", 1299 "uses" : [ "default-network-map", "alt-network-map" ], 1300 "capabilities": { 1301 "mappings": { 1302 "default-network-map.pid": [ ".region" ], 1303 "alt-network-map.pid": [ ".ASN" ], 1304 } 1305 } 1306 }, 1307 "ip-pid-property-map" : { 1308 "uri" : "http://alto.example.com/propmap/lookup/pid", 1309 "media-type" : "application/alto-propmap+json", 1310 "accepts" : "application/alto-propmapparams+json", 1311 "uses" : [ "default-network-map", "alt-network-map" ], 1312 "capabilities" : { 1313 "mappings": { 1314 "ipv4": [ "default-network-map.pid", 1315 "alt-network-map.pid" ], 1316 "ipv6": [ "default-network-map.pid", 1317 "alt-network-map.pid" ] 1318 } 1319 } 1320 }, 1321 "legacy-endpoint-property" : { 1322 "uri" : "http://alto.example.com/legacy/eps-pid", 1323 "media-type" : "application/alto-endpointprop+json", 1324 "accepts" : "application/alto-endpointpropparams+json", 1325 "capabilities" : { 1326 "properties" : [ "default-network-map.pid", 1327 "alt-network-map.pid" ] 1328 } 1329 } 1330 } 1332 Figure 8: Example IRD 1334 9.4. Property Map Example 1336 The following example uses the properties and IRD defined above to 1337 retrieve a Property Map for entities with the "ISP" and "ASN" 1338 properties. 1340 Note that, to be compact, the response does not includes the entity 1341 "ipv4:192.0.2.0", because values of all those properties for this 1342 entity are inherited from other entities. 1344 Also note that the entities "ipv4:192.0.2.0/28" and 1345 "ipv4:192.0.2.16/28" are merged into "ipv4:192.0.2.0/27", because 1346 they have the same value of the "ASN" property. The same rule 1347 applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28". 1348 Both of "ipv4:192.0.2.0/27" and "ipv4:192.0.3.0/27" omit the value 1349 for the "ISP" property, because it is inherited from 1350 "ipv4:192.0.2.0/23". 1352 GET /propmap/full/inet-ia HTTP/1.1 1353 Host: alto.example.com 1354 Accept: application/alto-propmap+json,application/alto-error+json 1355 HTTP/1.1 200 OK 1356 Content-Length: ### 1357 Content-Type: application/alto-propmap+json 1359 { 1360 "meta": { 1361 "dependent-vtags": [ 1362 {"resource-id": "default-network-map", 1363 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1364 {"resource-id": "alt-network-map", 1365 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1366 ] 1367 }, 1368 "property-map": { 1369 "ipv4:192.0.2.0/23": {".ISP": "BitsRus"}, 1370 "ipv4:192.0.2.0/27": {".ASN": "12345"}, 1371 "ipv4:192.0.3.0/27": {".ASN": "12346"} 1372 } 1373 } 1375 9.5. Filtered Property Map Example #1 1377 The following example uses the filtered property map resource to 1378 request the "ISP", "ASN" and "state" properties for several IPv4 1379 addresses. 1381 Note that the value of "state" for "ipv4:192.0.2.0" is the only 1382 explicitly defined property; the other values are all derived by the 1383 inheritance rules for Internet address entities. 1385 POST /propmap/lookup/inet-iacs HTTP/1.1 1386 Host: alto.example.com 1387 Accept: application/alto-propmap+json,application/alto-error+json 1388 Content-Length: ### 1389 Content-Type: application/alto-propmapparams+json 1391 { 1392 "entities" : [ "ipv4:192.0.2.0", 1393 "ipv4:192.0.2.1", 1394 "ipv4:192.0.2.17" ], 1395 "properties" : [ ".ISP", ".ASN", ".state" ] 1396 } 1397 HTTP/1.1 200 OK 1398 Content-Length: ### 1399 Content-Type: application/alto-propmap+json 1401 { 1402 "meta": { 1403 "dependent-vtags": [ 1404 {"resource-id": "default-network-map", 1405 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1406 {"resource-id": "alt-network-map", 1407 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1408 ] 1409 }, 1410 "property-map": { 1411 "ipv4:192.0.2.0": 1412 {".ISP": "BitsRus", ".ASN": "12345", ".state": "PA"}, 1413 "ipv4:192.0.2.1": 1414 {".ISP": "BitsRus", ".ASN": "12345", ".state": "NJ"}, 1415 "ipv4:192.0.2.17": 1416 {".ISP": "BitsRus", ".ASN": "12345", ".state": "CT"} 1417 } 1418 } 1420 9.6. Filtered Property Map Example #2 1422 The following example uses the filtered property map resource to 1423 request the "ASN", "country" and "state" properties for several IPv4 1424 prefixes. 1426 Note that the property values for both entities "ipv4:192.0.2.0/26" 1427 and "ipv4:192.0.3.0/26" are not explicitly defined. They are 1428 inherited from the entity "ipv4:192.0.2.0/23". 1430 Also note that some entities like "ipv4:192.0.2.0/28" and 1431 "ipv4:192.0.2.16/28" in the response are not listed in the request 1432 explicitly. The response includes them because they are refinements 1433 of the requested entities and have different values for the requested 1434 properties. 1436 The entity "ipv4:192.0.4.0/26" is not included in the response, 1437 because there are neither entities which it is inherited from, nor 1438 entities inherited from it. 1440 POST /propmap/lookup/inet-iacs HTTP/1.1 1441 Host: alto.example.com 1442 Accept: application/alto-propmap+json,application/alto-error+json 1443 Content-Length: ### 1444 Content-Type: application/alto-propmapparams+json 1446 { 1447 "entities" : [ "ipv4:192.0.2.0/26", 1448 "ipv4:192.0.3.0/26", 1449 "ipv4:192.0.4.0/26" ], 1450 "properties" : [ ".ASN", ".country", ".state" ] 1451 } 1453 HTTP/1.1 200 OK 1454 Content-Length: ### 1455 Content-Type: application/alto-propmap+json 1457 { 1458 "meta": { 1459 "dependent-vtags": [ 1460 {"resource-id": "default-network-map", 1461 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1462 {"resource-id": "alt-network-map", 1463 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1464 ] 1465 }, 1466 "property-map": { 1467 "ipv4:192.0.2.0/26": {".country": "us"}, 1468 "ipv4:192.0.2.0/28": {".ASN": "12345", 1469 ".state": "NJ"}, 1470 "ipv4:192.0.2.16/28": {".ASN": "12345", 1471 ".state": "CT"}, 1472 "ipv4:192.0.2.0": {".state": "PA"}, 1473 "ipv4:192.0.3.0/26": {".country": "us"}, 1474 "ipv4:192.0.3.0/28": {".ASN": "12345", 1475 ".state": "TX"}, 1476 "ipv4:192.0.3.16/28": {".ASN": "12345", 1477 ".state": "MN"} 1478 } 1479 } 1481 9.7. Filtered Property Map Example #3 1483 The following example uses the filtered property map resource to 1484 request the "pid" property for several IPv4 addresses and prefixes. 1486 Note that the entity "ipv4:192.0.3.0/27" is redundant in the 1487 response. Although it can inherit a value of "defaultpid" for the 1488 "pid" property from the entity "ipv4:0.0.0.0/0", none of addresses in 1489 it is in "defaultpid". Because blocks "ipv4:192.0.3.0/28" and 1490 "ipv4:192.0.3.16/28" have already cover all addresses in that block. 1491 So an ALTO server who wants a compact response can omit this entity. 1493 POST /propmap/lookup/pid HTTP/1.1 1494 Host: alto.example.com 1495 Accept: application/alto-propmap+json,application/alto-error+json 1496 Content-Length: ### 1497 Content-Type: application/alto-propmapparams+json 1499 { 1500 "entities" : [ 1501 "ipv4:192.0.2.128", 1502 "ipv4:192.0.3.0/27" ], 1503 "properties" : [ "default-network-map.pid" ] 1504 } 1506 HTTP/1.1 200 OK 1507 Content-Length: ### 1508 Content-Type: application/alto-propmap+json 1510 { 1511 "meta": { 1512 "dependent-vtags": [ 1513 {"resource-id": "default-network-map", 1514 "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"}, 1515 {"resource-id": "alt-network-map", 1516 "tag": "c0ce023b8678a7b9ec00324673b98e54656d1f6d"} 1517 ] 1518 }, 1519 "property-map": { 1520 "ipv4:192.0.2.128": {"default-network-map.pid": "defaultpid"}, 1521 "ipv4:192.0.2.0/27": {"default-network-map.pid": "defaultpid"}, 1522 "ipv4:192.0.3.0/28": {"default-network-map.pid": "pid3"}, 1523 "ipv4:192.0.3.16/28": {"default-network-map.pid": "pid4"} 1524 } 1525 } 1527 9.8. Filtered Property Map Example #4 1529 The following example uses the filtered property map resource to 1530 request the "region" property for several PIDs defined in "default- 1531 network-map". The value of the "region" property for each PID is not 1532 defined by "default-network-map", but the reason why the PID is 1533 defined by the network operator. 1535 POST /propmap/lookup/region HTTP/1.1 1536 Host: alto.example.com 1537 Accept: application/alto-propmap+json,application/alto-error+json 1538 Content-Length: ### 1539 Content-Type: application/alto-propmapparams+json 1541 { 1542 "entities" : ["default-network-map.pid:pid1", 1543 "default-network-map.pid:pid2"], 1544 "properties" : [ ".region" ] 1545 } 1547 HTTP/1.1 200 OK 1548 Content-Length: ### 1549 Content-Type: application/alto-propmap+json 1551 { 1552 "meta" : { 1553 "dependent-vtags" : [ 1554 {"resource-id": "default-network-map", 1555 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1556 ] 1557 }, 1558 "property-map": { 1559 "default-network-map.pid:pid1": { 1560 ".region": "us-west" 1561 }, 1562 "default-network-map.pid:pid2": { 1563 ".region": "us-east" 1564 } 1565 } 1566 } 1568 10. Security Considerations 1570 Both Property Map and Filtered Property Map defined in this document 1571 fit into the architecture of the ALTO base protocol, and hence the 1572 Security Considerations (Section 15 of [RFC7285]) of the base 1573 protocol fully apply: authenticity and integrity of ALTO information 1574 (i.e., authenticity and integrity of Property Maps), potential 1575 undesirable guidance from authenticated ALTO information (e.g., 1576 potentially imprecise or even wrong value of a property such as geo- 1577 location), confidentiality of ALTO information (e.g., exposure of a 1578 potentially sensitive entity property such as geo-location), privacy 1579 for ALTO users, and availability of ALTO services should all be 1580 considered. 1582 A particular fundamental security consideration when an ALTO server 1583 provides a Property Map is to define precisely the policies on who 1584 can access what properties for which entities. Security mechanisms 1585 such as authentication and confidentiality mechanisms then should be 1586 applied to enforce the policy. For example, a policy can be that a 1587 property P can be accessed only by its owner (e.g., the customer who 1588 is allocated a given IP address). Then, the ALTO server will need to 1589 deploy corresponding mechanisms to realize the policy. The policy 1590 may allow non-owners to access a coarse-grained value of the property 1591 P. In such a case, the ALTO server may provide a different URI to 1592 provide the information. 1594 11. IANA Considerations 1596 This document defines additional application/alto-* media types, and 1597 extends the ALTO endpoint property registry. 1599 11.1. application/alto-* Media Types 1601 This document registers two additional ALTO media types, listed in 1602 Table 1. 1604 +--------------+--------------------------+------------------------+ 1605 | Type | Subtype | Specification | 1606 +--------------+--------------------------+------------------------+ 1607 | application | alto-propmap+json | Section 6.1 | 1608 | application | alto-propmapparams+json | Section 7.3 | 1609 +--------------+--------------------------+------------------------+ 1611 Table 1: Additional ALTO Media Types. 1613 Type name: application 1615 Subtype name: This document registers multiple subtypes, as listed 1616 in Table 1. 1618 Required parameters: n/a 1620 Optional parameters: n/a 1622 Encoding considerations: Encoding considerations are identical to 1623 those specified for the "application/json" media type. See 1624 [RFC7159]. 1626 Security considerations: Security considerations related to the 1627 generation and consumption of ALTO Protocol messages are discussed 1628 in Section 15 of [RFC7285]. 1630 Interoperability considerations: This document specifies formats of 1631 conforming messages and the interpretation thereof. 1633 Published specification: This document is the specification for 1634 these media types; see Table 1 for the section documenting each 1635 media type. 1637 Applications that use this media type: ALTO servers and ALTO clients 1638 either stand alone or are embedded within other applications. 1640 Additional information: 1642 Magic number(s): n/a 1644 File extension(s): This document uses the mime type to refer to 1645 protocol messages and thus does not require a file extension. 1647 Macintosh file type code(s): n/a 1649 Person & email address to contact for further information: See 1650 Authors' Addresses section. 1652 Intended usage: COMMON 1654 Restrictions on usage: n/a 1656 Author: See Authors' Addresses section. 1658 Change controller: Internet Engineering Task Force 1659 (mailto:iesg@ietf.org). 1661 11.2. ALTO Entity Domain Type Registry 1663 This document requests IANA to create and maintain the "ALTO Entity 1664 Domain Type Registry", listed in Table 2. 1666 +-------------+---------------------------+-------------------------+ 1667 | Identifier | Entity Identifier | Hierarchy & Inheritance | 1668 | | Encoding | | 1669 +-------------+---------------------------+-------------------------+ 1670 | ipv4 | See Section 4.1.1 | See Section 4.1.3 | 1671 | ipv6 | See Section 4.1.2 | See Section 4.1.3 | 1672 | pid | See Section 4.2 | None | 1673 +-------------+---------------------------+-------------------------+ 1675 Table 2: ALTO Entity Domains. 1677 This registry serves two purposes. First, it ensures uniqueness of 1678 identifiers referring to ALTO entity domains. Second, it states the 1679 requirements for allocated entity domains. 1681 11.2.1. Consistency Procedure between ALTO Address Type Registry and 1682 ALTO Entity Domain Registry 1684 One potential issue of introducing the "ALTO Entity Domain Registry" 1685 is its relationship with the "ALTO Address Types Registry" already 1686 defined in Section 14.4 of [RFC7285]. In particular, the entity 1687 identifier of an entity domain registered in the "ALTO Entity Domain 1688 Registry" MAY match an address type defined in "ALTO Address Type 1689 Registry". It is necessary to precisely define and guarantee the 1690 consistency between "ALTO Address Type Registry" and "ALTO Entity 1691 Domain Registry". 1693 We define that the ALTO Entity Domain Registry is consistent with 1694 ALTO Address Type Registry if two conditions are satisfied: 1696 o When an address type is already or able to be registered in the 1697 ALTO Address Type Registry [RFC7285], the same identifier MUST be 1698 used when a corresponding entity domain is registered in the ALTO 1699 Entity Domain Registry. 1701 o If an ALTO entity domain has the same identifier as an ALTO 1702 address type, their addresses encoding MUST be compatible. 1704 To achieve this consistency, the following items MUST be checked 1705 before registering a new ALTO entity domain in a future document: 1707 o Whether the ALTO Address Type Registry contains an address type 1708 that can be used as an entity identifier for the candidate domain 1709 identifier. This has been done for the identifiers "ipv4" and 1710 "ipv6" in Table 2. 1712 o Whether the candidate entity identifier of the entity domain is 1713 able to be an endpoint address, as defined in Sections 2.1 and 2.2 1714 of [RFC7285]. 1716 When a new ALTO entity domain is registered, the consistency with the 1717 ALTO Address Type Registry MUST be ensured by the following 1718 procedure: 1720 o Test: Do corresponding entity identifiers match a known "network" 1721 address type? 1723 * If yes (e.g., cell, MAC or socket addresses): 1725 + Test: Is such an address type present in the ALTO Address 1726 Type Registry? 1728 - If yes: Set the new ALTO entity domain identifier to be 1729 the found ALTO address type identifier. 1731 - If no: Define a new ALTO entity domain identifier and use 1732 it to register a new address type in the ALTO Address 1733 Type Registry following Section 14.4 of [RFC7285]. 1735 + Use the new ALTO entity domain identifier to register a new 1736 ALTO entity domain in the ALTO Entity Domain Registry 1737 following Section 11.2.2 of this document. 1739 * If no (e.g., pid name, ane name or country code): Proceed with 1740 the ALTO Entity Domain registration as described in 1741 Section 11.2.2. 1743 11.2.2. ALTO Entity Domain Registration Process 1745 New ALTO entity domains are assigned after IETF Review [RFC5226] to 1746 ensure that proper documentation regarding the new ALTO entity 1747 domains and their security considerations has been provided. RFCs 1748 defining new entity domains SHOULD indicate how an entity in a 1749 registered domain is encoded as an EntityId, and, if applicable, the 1750 rules defining the entity hierarchy and property inheritance. 1751 Updates and deletions of ALTO entity domains follow the same 1752 procedure. 1754 Registered ALTO entity domain identifiers MUST conform to the 1755 syntactical requirements specified in Section 3.1.2. Identifiers are 1756 to be recorded and displayed as strings. 1758 Requests to the IANA to add a new value to the registry MUST include 1759 the following information: 1761 o Identifier: The name of the desired ALTO entity domain. 1763 o Entity Identifier Encoding: The procedure for encoding the 1764 identifier of an entity of the registered type as an EntityId (see 1765 Section 3.1.3). If corresponding entity identifiers of an entity 1766 domain match a known "network" address type, the Entity Identifier 1767 Encoding of this domain identifier MUST include both Address 1768 Encoding and Prefix Encoding of the same identifier registered in 1769 the ALTO Address Type Registry [RFC7285]. For the purpose of 1770 defining properties, an individual entity identifier and the 1771 corresponding full-length prefix MUST be considered aliases for 1772 the same entity. 1774 o Hierarchy: If the entities form a hierarchy, the procedure for 1775 determining that hierarchy. 1777 o Inheritance: If entities can inherit property values from other 1778 entities, the procedure for determining that inheritance. 1780 o Mapping to ALTO Address Type: A boolean value to indicate if the 1781 entity domain can be mapped to the ALTO address type with the same 1782 identifier. 1784 o Security Considerations: In some usage scenarios, entity 1785 identifiers carried in ALTO Protocol messages may reveal 1786 information about an ALTO client or an ALTO service provider. 1787 Applications and ALTO service providers using addresses of the 1788 registered type should be made aware of how (or if) the addressing 1789 scheme relates to private information and network proximity. 1791 This specification requests registration of the identifiers "ipv4", 1792 "ipv6" and "pid", as shown in Table 2. 1794 11.3. ALTO Entity Property Type Registry 1796 This document requests IANA to create and maintain the "ALTO Entity 1797 Property Type Registry", listed in Table 3. 1799 To distinguish with the "ALTO Endpoint Property Type Registry", each 1800 entry in this registry is an ALTO entity property type defined in 1801 Section 3.2.1. Thus, registered ALTO entity property type identifier 1802 MUST conform to the syntactical requirements specified in that 1803 section. 1805 The initial registered ALTO entity property types are listed in 1806 Table 3. 1808 +-------------+---------------------------------+ 1809 | Identifier | Intended Semantics | 1810 +-------------+---------------------------------+ 1811 | pid | See Section 7.1.1 of [RFC7285] | 1812 +-------------+---------------------------------+ 1814 Table 3: ALTO Entity Property Types. 1816 Requests to the IANA to add a new value to the registry MUST include 1817 the following information: 1819 o Identifier: The unique id for the desired ALTO entity property 1820 type. The format MUST be as defined in Section 3.2.1 of this 1821 document. It includes the information of the applied ALTO entity 1822 domain and the property name. 1824 o Intended Semantics: ALTO entity properties carry with them 1825 semantics to guide their usage by ALTO clients. Hence, a document 1826 defining a new type SHOULD provide guidance to both ALTO service 1827 providers and applications utilizing ALTO clients as to how values 1828 of the registered ALTO entity property should be interpreted. 1830 This document requests registration of the identifier "pid", as shown 1831 in Table 3. 1833 11.4. ALTO Resource-Specific Entity Domain Registries 1835 11.4.1. Network Map 1837 Media-type: application/alto-networkmap+json 1839 +---------------------+---------------------+ 1840 | Entity Domain Type | Intended Semantics | 1841 +---------------------+---------------------+ 1842 | ipv4 | See Section 5.1.1 | 1843 | ipv6 | See Section 5.1.1 | 1844 | pid | See Section 5.1.1 | 1845 +---------------------+---------------------+ 1847 Table 4: ALTO Network Map Resource-Specific Entity Domain. 1849 11.4.2. Endpoint Property 1851 Media-type: application/alto-endpointprop+json 1853 +---------------------+---------------------+ 1854 | Entity Domain Type | Intended Semantics | 1855 +---------------------+---------------------+ 1856 | ipv4 | See Section 5.2.1 | 1857 | ipv6 | See Section 5.2.1 | 1858 +---------------------+---------------------+ 1860 Table 5: ALTO Endpoint Property Resource-Specific Entity Domain. 1862 11.5. ALTO Resource Entity Property Mapping Registries 1864 11.5.1. Network Map 1866 Media-type: application/alto-networkmap+json 1867 +----------------+-----------------+-------------+------------------+ 1868 | Mapping | Entity Domain | Property | Intended | 1869 | Descriptor | Type | Type | Semantics | 1870 +----------------+-----------------+-------------+------------------+ 1871 | ipv4 -> pid | ipv4 | pid | See | 1872 | | | | Section 5.1.2 | 1873 | ipv6 -> pid | ipv6 | pid | See | 1874 | | | | Section 5.1.2 | 1875 +----------------+-----------------+-------------+------------------+ 1877 Table 6: ALTO Network Map Entity Property Mapping. 1879 12. Acknowledgments 1881 The authors would like to thank discussions with Kai Gao, Qiao Xiang, 1882 Shawn Lin, Xin Wang, Danny Perez, and Vijay Gurbani. The authors 1883 thank Dawn Chen (Tongji University), and Shenshen Chen (Tongji/Yale 1884 University) for their contributions to earlier drafts. 1886 13. Normative References 1888 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1889 Requirement Levels", BCP 14, RFC 2119, 1890 DOI 10.17487/RFC2119, March 1997, 1891 . 1893 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1894 Resource Identifier (URI): Generic Syntax", STD 66, 1895 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1896 . 1898 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1899 (CIDR): The Internet Address Assignment and Aggregation 1900 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1901 2006, . 1903 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1904 IANA Considerations Section in RFCs", RFC 5226, 1905 DOI 10.17487/RFC5226, May 2008, 1906 . 1908 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1909 Address Text Representation", RFC 5952, 1910 DOI 10.17487/RFC5952, August 2010, 1911 . 1913 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1914 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1915 2014, . 1917 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1918 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1919 "Application-Layer Traffic Optimization (ALTO) Protocol", 1920 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1921 . 1923 [RFC7921] Atlas, A., Halpern, J., Hares, S., Ward, D., and T. 1924 Nadeau, "An Architecture for the Interface to the Routing 1925 System", RFC 7921, DOI 10.17487/RFC7921, June 2016, 1926 . 1928 Authors' Addresses 1930 Wendy Roome 1931 Nokia Bell Labs (Retired) 1932 124 Burlington Rd 1933 Murray Hill, NJ 07974 1934 USA 1936 Phone: +1-908-464-6975 1937 Email: wendy@wdroome.com 1939 Sabine Randriamasy 1940 Nokia Bell Labs 1941 Route de Villejust 1942 NOZAY 91460 1943 FRANCE 1945 Email: Sabine.Randriamasy@nokia-bell-labs.com 1947 Y. Richard Yang 1948 Yale University 1949 51 Prospect Street 1950 New Haven, CT 06511 1951 USA 1953 Phone: +1-203-432-6400 1954 Email: yry@cs.yale.edu 1955 Jingxuan Jensen Zhang 1956 Tongji University 1957 4800 Caoan Road 1958 Shanghai 201804 1959 China 1961 Email: jingxuan.n.zhang@gmail.com