idnits 2.17.1 draft-ietf-alto-unified-props-new-04.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 599 has weird spacing: '...rtyName prop...' == Line 742 has weird spacing: '...country stat...' -- The document date (June 29, 2018) is 2125 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) == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-03 Summary: 3 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 Nokia Bell Labs 4 Intended status: Standards Track S. Chen 5 Expires: December 31, 2018 Tongji University 6 S. Randriamasy 7 Nokia Bell Labs 8 Y. Yang 9 Yale University 10 J. Zhang 11 Tongji University 12 June 29, 2018 14 Unified Properties for the ALTO Protocol 15 draft-ietf-alto-unified-props-new-04 17 Abstract 19 This document extends the Application-Layer Traffic Optimization 20 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint 21 properties" to domains of other entities, and by presenting those 22 properties as maps, similar to the network and cost maps in ALTO. 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 December 31, 2018. 47 Copyright Notice 49 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Definitions and Concepts . . . . . . . . . . . . . . . . . . 4 66 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2.2. Entity Domain . . . . . . . . . . . . . . . . . . . . . . 5 68 2.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 5 69 2.4. Entity Address . . . . . . . . . . . . . . . . . . . . . 5 70 2.5. Property Name . . . . . . . . . . . . . . . . . . . . . . 6 71 2.6. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 6 72 2.7. Relationship with Other ALTO Resources . . . . . . . . . 6 73 3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.1. Internet Address Domains . . . . . . . . . . . . . . . . 7 75 3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 7 76 3.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 8 77 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains . . . 8 78 3.1.4. Relationship to Network Maps . . . . . . . . . . . . 9 79 3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 10 80 3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10 81 3.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 82 3.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 10 83 3.2.4. Relationship To Internet Addresses Domains . . . . . 10 84 3.3. Internet Address Properties vs. PID Properties . . . . . 10 85 4. Property Map Resource . . . . . . . . . . . . . . . . . . . . 11 86 4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 11 88 4.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 11 89 4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 11 90 4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 92 5. Filtered Property Map Resource . . . . . . . . . . . . . . . 13 93 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 13 94 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 13 96 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 97 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 98 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 14 99 6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 14 100 6.1. Impact on Endpoint Property Service . . . . . . . . . . . 15 101 6.2. Impact on Resource-Specific Properties . . . . . . . . . 15 102 6.3. Impact on the pid Property . . . . . . . . . . . . . . . 15 103 6.4. Impact on Other Properties . . . . . . . . . . . . . . . 16 104 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 105 7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 16 106 7.2. Property Definitions . . . . . . . . . . . . . . . . . . 16 107 7.3. Information Resource Directory (IRD) . . . . . . . . . . 16 108 7.4. Property Map Example . . . . . . . . . . . . . . . . . . 18 109 7.5. Filtered Property Map Example #1 . . . . . . . . . . . . 19 110 7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 20 111 7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 21 112 7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 22 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 115 9.1. application/alto-* Media Types . . . . . . . . . . . . . 24 116 9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 25 117 9.2.1. Consistency Procedure between ALTO Address Type 118 Registry and ALTO Entity Domain Registry . . . . . . 26 119 9.2.2. ALTO Entity Domain Registration Process . . . . . . . 27 120 9.3. ALTO Endpoint Property Type Registry . . . . . . . . . . 28 121 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 122 10.1. Normative References . . . . . . . . . . . . . . . . . . 28 123 10.2. Informative References . . . . . . . . . . . . . . . . . 29 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 126 1. Introduction 128 The ALTO protocol [RFC7285] introduced the concept of "properties" 129 attached to "endpoint addresses", and defined the Endpoint Property 130 Service (EPS) to allow clients to retrieve those properties. While 131 useful, the EPS, as defined in [RFC7285], has at least two 132 limitations. 134 First, it only allows properties to be associated with a particular 135 domain of entities, namely individual IP addresses. It is reasonable 136 to think that collections of endpoints, as defined by CIDRs [RFC4632] 137 or PIDs, may also have properties. The EPS cannot be extended to new 138 entity domains. Instead, new services, with new request and response 139 messages, would have to be defined for each new entity domain. 141 Second, the EPS is only defined as a POST-mode service. Clients must 142 request the properties for an explicit set of addresses. By 143 contrast, [RFC7285] defines a GET-mode Cost Map resource which 144 returns all available costs, so a client can get a full set of costs 145 once, and then processes costs lookup without querying the ALTO 146 server. [RFC7285] does not define an equivalent service for endpoint 147 properties. At first a map might seem impractical, because it could 148 require enumerating the property value for every possible endpoint. 149 But in practice, it is highly unlikely that properties will be 150 defined for every address. It is much more likely that properties 151 will only be defined for a subset of addresses, and that subset would 152 be small enough to enumerate. This is particularly true if blocks of 153 addresses with a common prefix (e.g., a CIDR) have the same value for 154 a property. Furthermore, entities in other domains may very well be 155 enumerable. 157 This document proposes a new approach to retrieve ALTO properties. 158 Specifically, it defines two new resource types, namely Property Maps 159 (see Section 4) and Filtered Property Maps (see Section 5). The 160 former are GET-mode resources which return the property values for 161 all entities in a domain, and are analogous to the ALTO's Network 162 Maps and Cost Maps. The latter are POST-mode resources which return 163 the values for a set of properties and entities requested by the 164 client, and are analogous to the ALTO's Filtered Network Maps and 165 Filtered Cost Maps. 167 Additionally, this document introduces ALTO Entity Domains, where 168 entities extend the concept of endpoints to objects that may be 169 endpoints as defined in [RFC7285] but also, for example, PIDs, 170 Abstract Network Elements as defined in [I-D.ietf-alto-path-vector] 171 or cells. As a consequence, ALTO Entity Domains are a super-set of 172 ALTO Address Types and their relation is specified in Section 9.2.1. 174 Entity domains and property names are extensible. New entity domains 175 can be defined without revising the messages defined in this 176 document, in the same way that new cost metrics and new endpoint 177 properties can be defined without revising the messages defined by 178 the ALTO protocol. 180 This proposal would subsume the Endpoint Property Service defined in 181 [RFC7285], although that service may be retained for legacy clients 182 (see Section 6). 184 2. Definitions and Concepts 186 2.1. Entity 188 The entity is an extended concept of the endpoint defined in 189 Section 2.1 of [RFC7285]. An entity is an object with a (possibly 190 empty) set of properties. Every entity is in a domain, such as the 191 IPv4 and IPv6 domains, and has a unique address. 193 2.2. Entity Domain 195 An entity domain is a family of entities. Two examples are the 196 Internet address and PID domain (see Section 3.1 and Section 3.2) 197 that this document will define. 199 2.3. Domain Name 201 Each entity domain has a unique name. A domain name MUST be no more 202 than 32 characters, and MUST NOT contain characters other than US- 203 ASCII alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 204 U+0061-U+007A), hyphen ("-", U+002D), and low line ("_", U+005F). 205 For example, the names "ipv4" and "ipv6" identify objects in the 206 Internet address domain (see Section 3.1). 208 The type DomainName is used in this document to denote a JSON string 209 with a domain name in this format. 211 Domain names MUST be registered with the IANA, and the format of the 212 entity addresses in that entity domain, as well as any hierarchical 213 or inheritance rules for those entities, MUST be specified at the 214 same time. 216 2.4. Entity Address 218 Each entity has a unique address of the format: 220 domain-name : domain-specific-entity-address 222 Examples from the IP domain include individual addresses such as 223 "ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks 224 such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48". 226 The type EntityAddr is used in this document to denote a JSON string 227 with an entity address in this format. 229 The format of the second part of an entity address depends on the 230 entity domain, and MUST be specified when registering a new entity 231 domain. Addresses MAY be hierarchical, and properties MAY be 232 inherited based on that hierarchy. Again, the rules defining any 233 hierarchy or inheritance MUST be defined when the entity domain is 234 registered. 236 Note that an entity address MAY have different textual 237 representations, for a given entity domain. For example, the strings 238 "ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same 239 entity. 241 2.5. Property Name 243 The space of property names associated with entities defined by this 244 document is the same as, and is shared with, the endpoint property 245 names defined by [RFC7285]. Thus entity property names are as 246 defined in Section 10.8.2 of that document, and must be registered 247 with the "ALTO Endpoint Property Type Registry" defined in 248 Section 9.3 of that document. The type PropertyName denotes a JSON 249 string with a property name in this format. 251 This document defines uniform property names specified in a single 252 property name space rather than being scoped by a specific entity 253 domain, although some properties may only be applicable for 254 particular entity domains. This design decision is to enforce a 255 design so that similar properties are named similarly. The 256 interpretation of the value of a property, however, may depend on the 257 entity domain. For example, suppose the "geo-location" property is 258 defined as the coordinates of a point, encoded as (say) "latitude 259 longitude [altitude]." When applied to an entity that represents a 260 specific host computer, such as an Internet address, the property 261 defines the host's location. When applied to an entity that 262 represents a set of computers, such as a CIDR, the property would be 263 the location of the center of that set. If it is necessary to 264 represent the bounding box of a set of hosts, another property, such 265 as "geo-region", should be defined. 267 2.6. Hierarchy and Inheritance 269 Entities in a given domain MAY form hierarchy based on entity 270 address. Each entity domain MUST define its own hierarchy and 271 inheritance rules when registered. The hierarchy and inheritance 272 rule makes it possible for an entity to inherit a property value from 273 another entity in the same domain. If and only if the property of an 274 entity is undefined, the hierarchy and inheritance rules are applied. 276 2.7. Relationship with Other ALTO Resources 278 [RFC7285] recognizes that some properties MAY be specific to another 279 ALTO resource, such as a network map. Accordingly [RFC7285] defines 280 the concept of "resource-specific endpoint properties" (see 281 Section 10.8.1), and indicates that dependency by prefixing the 282 property name with the ID of the resource on which it depends. That 283 document defines one resource-specific property, namely the "pid" 284 property, whose value is the name of the PID containing that endpoint 285 in the associated network map. 287 This document takes a different approach. Instead of defining the 288 dependency by qualifying the property name, this document attaches 289 the dependency to the entity domains. Thus all properties of a 290 specific entity domain depend on the same resource, the properties of 291 another entity domain may depend on another resource. For example, 292 entities in the PID domain depend on a network map. 294 The "uses" field in an IRD entry defines the dependencies of a 295 property map resource, and the "dependent-vtags" field in a property 296 map response defines the dependencies of that map. These fields are 297 defined in Sections 9.1.5 and 11.1 of [RFC7285], respectively. 299 The "uses" field in an IRD entry MUST NOT include two dependent 300 resources with the same media type. This is similar to how [RFC7285] 301 handles dependencies between cost maps and network maps. Recall that 302 cost maps present the costs between PIDs, and PID names depend on a 303 network map. If an ALTO server provides the "routingcost" metric for 304 the network maps "net1" and "net2", then the server defines two 305 separate cost maps, one for "net1" and the other for "net2". 307 According to [RFC7285], a legacy ALTO server with two network maps, 308 with resource IDs "net1" and "net2", could offer a single Endpoint 309 Property Service for the two properties "net1.pid" and "net2.pid". 310 An ALTO server which supports the extensions defined in this 311 document, would, instead, offer two different Property Maps for the 312 "pid" property, one depending on "net1", the other on "net2". 314 3. Entity Domains 316 This document defines the following entity domains. For the 317 definition of each entity domain, it includes the following template: 318 domain name, domain-specific addresses, and hierarchy and inheritance 319 semantics. 321 3.1. Internet Address Domains 323 The document defines two entity domains (IPv4 and IPv6) for Internet 324 addresses. Both entity domains include individual addresses and 325 blocks of addresses. 327 3.1.1. IPv4 Domain 329 3.1.1.1. Domain Name 331 ipv4 333 3.1.1.2. Domain-Specific Entity Addresses 335 Individual addresses are strings as specified by the IPv4Addresses 336 rule of Section 3.2.2 of [RFC3986]. Blocks of addresses are prefix- 337 match strings as specified in Section 3.1 of [RFC4632]. For the 338 purpose of defining properties, an individual Internet address and 339 the corresponding full-length prefix are considered aliases for the 340 same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are 341 equivalent. 343 3.1.2. IPv6 Domain 345 3.1.2.1. Domain Name 347 ipv6 349 3.1.2.2. Domain-Specific Entity Addresses 351 Individual addresses are strings as specified by Section 4 of 352 [RFC5952]. Blocks of addresses are prefix-match strings as specified 353 in Section 7 of [RFC5952]. For the purpose of defining properties, 354 an individual Internet address and the corresponding 128-bit prefix 355 are considered aliases for the same entity. That is, 356 "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and 357 have the same set of properties. 359 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains 361 Both entity domains allow property values to be inherited. 362 Specifically, if a property P is not defined for a specific Internet 363 address I, but P is defined for some block C which prefix-matches I, 364 then the address I inherits the value of P defined for block C. If 365 more than one such block defines a value for P, I inherits the value 366 of P in the block with the longest prefix. It is important to notice 367 that this longest prefix rule will ensure no multiple inheritance, 368 and hence no ambiguity. 370 Address blocks can also inherit properties: if property P is not 371 defined for a block C, but is defined for some block C' which prefix- 372 matches C, and C' has a shorter mask than C, then block C inherits 373 the property from C'. If there are several such blocks C', C 374 inherits from the block with the longest prefix. 376 As an example, suppose that a server defines the property P for the 377 following entities: 379 ipv4:192.0.2.0/26: P=v1 380 ipv4:192.0.2.0/28: P=v2 381 ipv4:192.0.2.0/30: P=v3 382 ipv4:192.0.2.0: P=v4 384 Figure 1: Defined Property Values. 386 Then the following entities have the indicated values: 388 ipv4:192.0.2.0: P=v4 389 ipv4:192.0.2.1: P=v3 390 ipv4:192.0.2.16: P=v1 391 ipv4:192.0.2.32: P=v1 392 ipv4:192.0.2.64: (not defined) 393 ipv4:192.0.2.0/32: P=v4 394 ipv4:192.0.2.0/31: P=v3 395 ipv4:192.0.2.0/29: P=v2 396 ipv4:192.0.2.0/27: P=v1 397 ipv4:192.0.2.0/25: (not defined) 399 Figure 2: Inherited Property Values. 401 An ALTO Server MAY explicitly indicate a property as not having a 402 value for a particular entity. That is, a server MAY say that 403 property A of entity X is "defined to have no value", instead of 404 "undefined". To indicate "no value", a server MAY perform different 405 behaviours: 407 o If that entity would inherit a value for that property, then the 408 ALTO server MUST return a "null" value for that property. In this 409 case, the ALTO client MUST recognize a "null" value as "no value" 410 and "do not apply the inheritance rules for this property." 412 o If the entity would not inherit a value, then the ALTO server MAY 413 return "null" or just omit the property. In this case, the ALTO 414 client cannot infer the value for this property of this entity 415 from the Inheritance rules. So the client MUST interpret this 416 property has no value. 418 If the ALTO Server does not define any properties for an entity, then 419 the server MAY omit that entity from the response. 421 3.1.4. Relationship to Network Maps 423 An Internet address domain MAY be associated with an ALTO network map 424 resource. Logically, there is a map of Internet address entities to 425 property values for each network map defined by the ALTO server, plus 426 an additional property map for Internet address entities which are 427 not associated with a network map. So, if there are n network maps, 428 the server can provide n+1 maps of Internet address entities to 429 property values. These maps are separate from each other. The 430 prefixes in the property map do not have to correspond to the 431 prefixes defining the network map's PIDs. For example, the property 432 map for a network map MAY assign properties to "ipv4:192.0.2.0/24" 433 even if that prefix is not associated with any PID in the network 434 map. 436 3.2. PID Domain 438 The PID domain associates property values with the PIDs in a network 439 map. Accordingly, this entity domain always depends on a network 440 map. 442 3.2.1. Domain Name 444 pid 446 3.2.2. Domain-Specific Entity Addresses 448 The entity addresses are the PID names of the associated network map. 450 3.2.3. Hierarchy and Inheritance 452 There is no hierarchy or inheritance for properties associated with 453 PIDs. 455 3.2.4. Relationship To Internet Addresses Domains 457 The PID domain and the Internet address domains are completely 458 independent; the properties associated with a PID have no relation to 459 the properties associated with the prefixes or endpoint addresses in 460 that PID. An ALTO server MAY choose to assign some or all properties 461 of a PID to the prefixes in that PID. 463 For example, suppose "PID1" consists of the prefix 464 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 465 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24", 466 in the IPv4 domain MAY have a value for the property "P", and if they 467 do, it is not necessarily "v1". 469 3.3. Internet Address Properties vs. PID Properties 471 Because the Internet address and PID domains are completely separate, 472 the question may arise as to which entity domain is the best for a 473 property. In general, the Internet address domain is RECOMMENDED for 474 properties that are closely related to the Internet address, or are 475 associated with, and inherited through, blocks of addresses. 477 The PID domain is RECOMMENDED for properties that arise from the 478 definition of the PID, rather than from the Internet address prefixes 479 in that PID. 481 For example, because Internet addresses are allocated to service 482 providers by blocks of prefixes, an "ISP" property would be best 483 associated with the Internet address domain. On the other hand, a 484 property that explains why a PID was formed, or how it relates a 485 provider's network, would best be associated with the PID domain. 487 4. Property Map Resource 489 A Property Map returns the properties defined for all entities in one 490 or more domains. 492 Section 7.4 gives an example of a property map request and its 493 response. 495 4.1. Media Type 497 The media type of an ALTO Property Map resource is "application/alto- 498 propmap+json". 500 4.2. HTTP Method 502 An ALTO Property Map resource is requested using the HTTP GET method. 504 4.3. Accept Input Parameters 506 None. 508 4.4. Capabilities 510 The capabilities are defined by an object of type 511 PropertyMapCapabilities: 513 object { 514 DomainName entity-domain-types<1..*>; 515 PropertyName prop-types<1..*>; 516 } PropertyMapCapabilities; 518 where "entity-domain-types" is an array with the domains of the 519 entities in this property map, and "prop-types" is an array with the 520 names of the properties returned for entities in those domains. 522 4.5. Uses 524 An array with the resource ID(s) of resource(s) with which the entity 525 domains in this map are associated. In most cases, this array will 526 have at most one ID, for example, for a network map resource. 527 However, the "uses" field MUST NOT contain two resources of the same 528 resource type. For example, if a property map depends on network map 529 resource, the "uses" field MUST include exactly one network map 530 resource. 532 4.6. Response 534 If the entity domains in this property map depend on other resources, 535 the "dependent-vtags" field in the "meta" field of the response MUST 536 be an array that includes the version tags of those resources. The 537 data component of a Property Map response is named "property-map", 538 which is a JSON object of type PropertyMapData, where: 540 object { 541 PropertyMapData property-map; 542 } InfoResourceProperties : ResponseEntityBase; 544 object-map { 545 EntityAddr -> EntityProps; 546 } PropertyMapData; 548 object { 549 PropertyName -> JSONValue; 550 } EntityProps; 552 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 554 Specifically, a PropertyMapData object has one member for each entity 555 in the Property Map. The entity's properties are encoded in the 556 corresponding EntityProps object. EntityProps encodes one name/value 557 pair for each property, where the property names are encoded as 558 strings of type PropertyName. A protocol implementation SHOULD 559 assume that the property value is either a JSONString or a JSON 560 "null" value, and fail to parse if it is not, unless the 561 implementation is using an extension to this document that indicates 562 when and how property values of other data types are signaled. 564 For each entity in the Property Map, the ALTO Server returns the 565 value defined for each of the properties specified in this resource's 566 "capabilities" list. For efficiency, the ALTO Server SHOULD omit 567 property values that are inherited rather than explicitly defined; if 568 a client needs inherited values, the client SHOULD use the entity 569 domain's inheritance rules to deduce those values. 571 5. Filtered Property Map Resource 573 A Filtered Property Map returns the values of a set of properties for 574 a set of entities selected by the client. 576 Section 7.5, Section 7.6 and Section 7.7 give examples of filtered 577 property map requests and responses. 579 5.1. Media Type 581 The media type of an ALTO Property Map resource is "application/alto- 582 propmap+json". 584 5.2. HTTP Method 586 An ALTO Filtered Property Map resource is requested using the HTTP 587 POST method. 589 5.3. Accept Input Parameters 591 The input parameters for a Filtered Property Map request are supplied 592 in the entity body of the POST request. This document specifies the 593 input parameters with a data format indicated by the media type 594 "application/alto-propmapparams+json", which is a JSON object of type 595 ReqFilteredPropertyMap: 597 object { 598 EntityAddr entities<1..*>; 599 PropertyName properties<1..*>; 600 } ReqFilteredPropertyMap; 602 with fields: 604 entities: List of entity addresses for which the specified 605 properties are to be returned. The ALTO server MUST interpret 606 entries appearing multiple times as if they appeared only once. 607 The domain of each entity MUST be included in the list of entity 608 domains in this resource's "capabilities" field (see Section 5.4). 610 properties: List of properties to be returned for each entity. Each 611 specified property MUST be included in the list of properties in 612 this resource's "capabilities" field (see Section 5.4). The ALTO 613 server MUST interpret entries appearing multiple times as if they 614 appeared only once. 616 Note that the "entities" and "properties" fields MUST have at 617 least one entry each. 619 5.4. Capabilities 621 The capabilities are defined by an object of type 622 PropertyMapCapabilities, as defined in Section 4.4. 624 5.5. Uses 626 An array with the resource ID(s) of resource(s) with which the entity 627 domains in this map are associated. In most cases, this array will 628 have at most one ID, and it will be for a network map resource. 630 5.6. Response 632 The response is the same as for the property map (see Section 4.6), 633 except that it only includes the entities and properties requested by 634 the client. 636 Also, the Filtered Property Map response MUST include all inherited 637 property values for the specified entities (unlike the Full Property 638 Map, the Filtered Property Map response does not include enough 639 information for the client to calculate the inherited values). 641 If an entity in "entities" in the request is invalid, the ALTO server 642 MUST return an "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 643 of [RFC7285]. An entity can be invalid if the domain of the entity 644 is not defined in the IRD for this service or the entity address is 645 an invalid address of the entity domain. On the other hand, a valid 646 entity address is not an error, even if the server does not define a 647 value for a requested property. In this case, the server MUST omit 648 that property from the response for only that entity. If a request 649 contains a property in "properties" and the property is not specified 650 in the IRD for the service, the ALTO server MUST return an 651 "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285]. 652 The "value" of the error message SHOULD indicate the wrong property. 654 If the ALTO server does not define a requested property's value for a 655 particular entity, then it MUST omit that property from the response 656 for only that endpoint. 658 If the ALTO server does not support a requested entity's domain, then 659 it MUST return an E_INVALID_FIELD_VALUE error defined in 660 Section 8.5.2 of [RFC7285]. 662 6. Impact on Legacy ALTO Servers and ALTO Clients 663 6.1. Impact on Endpoint Property Service 665 The Property Maps defined in this document provide the same 666 functionality as the Endpoint Property Service (EPS) defined in 667 Section 11.4 of [RFC7285]. Accordingly, it is RECOMMENDED that the 668 EPS be deprecated in favor of Property Maps. However, ALTO servers 669 MAY provide an EPS for the benefit of legacy clients. 671 6.2. Impact on Resource-Specific Properties 673 Section 10.8 of [RFC7285] defines two categories of endpoint 674 properties: "resource-specific" and "global". Resource-specific 675 property names are prefixed with the ID of the resource they depend 676 upon, while global property names have no such prefix. The property 677 map resources defined in this document do not distinguish between 678 those two types of properties. Instead, if there is a dependency, it 679 is indicated by the "uses" capability of a property map, and is 680 shared by all properties and entity domains in that map. 681 Accordingly, it is RECOMMENDED that resource-specific endpoint 682 properties be deprecated, and no new resource-specific endpoint 683 properties be defined. 685 6.3. Impact on the pid Property 687 Section 7.1.1 of [RFC7285] defines the resource-specific endpoint 688 property name "pid", whose value is the name of the PID containing 689 that endpoint. For compatibility with legacy clients, an ALTO server 690 which provides the "pid" property via the Endpoint Property Service 691 MUST use that definition, and that syntax, in the EPS resource. 693 However, when used with Property Maps, this document amends the 694 definition of the "pid" property as follows. 696 First, the name of the property is simply "pid"; the name is not 697 prefixed with the resource ID of a network map. The "uses" 698 capability of the property map resource indicates the associated 699 network map. This implies that a property map can only return the 700 "pid" property for one network map; if an ALTO server provides 701 several network maps, it MUST provide a property map resource for 702 each one. 704 Second, a client MAY request the "pid" property for a block of 705 addresses. An ALTO server determines the value of "pid" for an 706 address block C as follows. Let CS be the set of all address blocks 707 in the network map. If C is in CS, then the value of "pid" is the 708 name of the PID associated with C. Otherwise, find the longest block 709 C' in CS such that C' prefix-matches C, but is shorter than C. If 710 there is such a block C', the value of "pid" is the name of the PID 711 associated with C'. If not, then "pid" has no value for block C. 713 Note that although an ALTO server MAY provide a GET-mode property map 714 resource which returns the entire map for the "pid" property, there 715 is no need to do so, because that map is simply the inverse of the 716 network map. 718 6.4. Impact on Other Properties 720 In general, there should be little or no impact on other previously 721 defined properties. The only consideration is that properties can 722 now be defined on blocks of addresses, rather than just individual 723 addresses, which might change the semantics of a property. 725 7. Examples 727 7.1. Network Map 729 The examples in this section use a very simple default network map: 731 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 732 pid1: ipv4:192.0.2.0/25 733 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 735 Figure 3: Example Network Map 737 7.2. Property Definitions 739 The examples in this section use four additional properties, "ISP", 740 "ASN", "country" and "state", with the following values: 742 ISP ASN country state 743 ipv4:192.0.2.0/24: BitsRus - us - 744 ipv4:192.0.2.0/28: - 12345 - NJ 745 ipv4:192.0.2.16/28: - 12345 - CT 746 ipv4:192.0.2.0: - - - PA 748 Figure 4: Example Property Values 750 7.3. Information Resource Directory (IRD) 752 The following IRD defines the relevant resources of the ALTO server. 753 It provides two Property Map resources, one for the "ISP" and "ASN" 754 properties, and another for the "country" and "state" properties. 755 The server could have provided a Property Map resource for all four 756 properties, but did not, presumably because the organization that 757 runs the ALTO server believes any given client is not interested in 758 all four properties. 760 The server provides two Filtered Property Maps. The first returns 761 all four properties, and the second just returns the "pid" property 762 for the default network map. 764 The Filtered Property Maps for the "ISP", "ASN", "country" and 765 "state" properties do not depend on the default network map (it does 766 not have a "uses" capability), because the definitions of those 767 properties do not depend on the default network map. The Filtered 768 Property Map for the "pid" property does have a "uses" capability for 769 the default network map, because that defines the values of the "pid" 770 property. 772 Note that for legacy clients, the ALTO server provides an Endpoint 773 Property Service for the "pid" property for the default network map. 775 "meta": { ... }, 776 "resources" : { 777 "default-network-map" : { 778 "uri" : "http://alto.example.com/networkmap", 779 "media-type" : "application/alto-networkmap+json" 780 }, 781 .... property map resources .... 782 "country-state-property-map" : { 783 "uri" : "http://alto.example.com/propmap/full/inet-cs", 784 "media-type" : "application/alto-propmap+json", 785 "capabilities" : { 786 "entity-domain-types": [ "ipv4", "ipv6" ], 787 "prop-types" : [ "country", "state" ] 788 } 789 }, 790 "isp-asn-property-map" : { 791 "uri" : "http://alto.example.com/propmap/full/inet-ia", 792 "media-type" : "application/alto-propmap+json", 793 "capabilities" : { 794 "entity-domain-types": [ "ipv4", "ipv6" ], 795 "prop-types" : [ "ISP", "ASN" ] 796 } 797 }, 798 "iacs-property-map" : { 799 "uri" : "http://alto.example.com/propmap/lookup/inet-iacs", 800 "media-type" : "application/alto-propmap+json", 801 "accepts" : "application/alto-propmapparams+json", 802 "capabilities" : { 803 "entity-domain-types": [ "ipv4", "ipv6" ], 804 "prop-types" : [ "ISP", "ASN", "country", "state" ] 806 } 807 }, 808 "pid-property-map" : { 809 "uri" : "http://alto.example.com/propmap/lookup/pid", 810 "media-type" : "application/alto-propmap+json", 811 "accepts" : "application/alto-propmapparams+json", 812 "uses" : [ "default-network-map" ] 813 "capabilities" : { 814 "entity-domain-types" : [ "ipv4", "ipv6" ], 815 "prop-types" : [ "pid" ] 816 } 817 }, 818 "location-property-map": { 819 "uri": "http://alto.exmaple.com/propmap/location", 820 "media-type": "application/alto-propmap+json", 821 "accepts": "application/alto-propmapparams+json", 822 "uses" : [ "default-network-map" ], 823 "capabilities": { 824 "domain-types": [ "pid" ], 825 "prop-types": [ "country", "state" ] 826 } 827 }, 828 "legacy-pid-property" : { 829 "uri" : "http://alto.example.com/legacy/eps-pid", 830 "media-type" : "application/alto-endpointprop+json", 831 "accepts" : "application/alto-endpointpropparams+json", 832 "capabilities" : { 833 "prop-types" : [ "default-network-map.pid" ] 834 } 835 } 836 } 838 Figure 5: Example IRD 840 7.4. Property Map Example 842 The following example uses the properties and IRD defined above to 843 retrieve a property map for entities with the "ISP" and "ASN" 844 properties. Note that the response does not include the entity 845 "ipv4:192.0.2.0", because it does not have a value for either of 846 those properties. Also note that the entities "ipv4:192.0.2.0/28" 847 and "ipv4:192.0.2.16/28" are refinements of "ipv4:192.0.2.0/24", and 848 hence inherit its value for "ISP" property. But because that value 849 is inherited, it is not explicitly listed in the property map. 851 GET /propmap/full/inet-ia HTTP/1.1 852 Host: alto.example.com 853 Accept: application/alto-propmap+json,application/alto-error+json 855 HTTP/1.1 200 OK 856 Content-Length: ### 857 Content-Type: application/alto-propmap+json 859 { 860 "property-map": { 861 "ipv4:192.0.2.0/24": {"ISP": "BitsRus"}, 862 "ipv4:192.0.2.0/28": {"ASN": "12345"}, 863 "ipv4:192.0.2.16/28": {"ASN": "12345"} 864 } 865 } 867 7.5. Filtered Property Map Example #1 869 The following example uses the Filtered Property Map resource to 870 request the "ISP", "ASN" and "state" properties for several IPv4 871 addresses. Note that the value of "state" for "ipv4:192.0.2.0" is 872 the only explicitly defined property; the other values are all 873 derived by the inheritance rules for Internet address entities. 875 POST /propmap/lookup/inet-iacs HTTP/1.1 876 Host: alto.example.com 877 Accept: application/alto-propmap+json,application/alto-error+json 878 Content-Length: ### 879 Content-Type: application/alto-propmapparams+json 881 { 882 "entities" : [ "ipv4:192.0.2.0", 883 "ipv4:192.0.2.1", 884 "ipv4:192.0.2.17" ], 885 "properties" : [ "ISP", "ASN", "state" ] 886 } 888 HTTP/1.1 200 OK 889 Content-Length: ### 890 Content-Type: application/alto-propmap+json 892 { 893 "property-map": { 894 "ipv4:192.0.2.0": 895 {"ISP": "BitsRus", "ASN": "12345", "state": "PA"}, 896 "ipv4:192.0.2.1": 897 {"ISP": "BitsRus", "ASN": "12345", "state": "NJ"}, 898 "ipv4:192.0.2.17": 899 {"ISP": "BitsRus", "ASN": "12345", "state": "CT"} 900 } 901 } 903 7.6. Filtered Property Map Example #2 905 The following example uses the Filtered Property Map resource to 906 request the "ASN", "country" and "state" properties for several IPv4 907 prefixes. Note that none of the returned property values is 908 explicitly defined; all values are derived by the inheritance rules 909 for Internet address entities. 911 Also note the "ASN" property has the value "12345" for both the 912 blocks "ipv4:192.0.2.0/28" and "ipv4:192.0.2.16/28", so every address 913 in the block "ipv4:192.0.2.0/27" has that property value. However 914 the block "ipv4:192.0.2.0/27" itself does not have a value for "ASN": 915 address blocks cannot inherit properties from blocks with longer 916 prefixes, even if every such block has the same value. 918 POST /propmap/lookup/inet-iacs HTTP/1.1 919 Host: alto.example.com 920 Accept: application/alto-propmap+json,application/alto-error+json 921 Content-Length: ### 922 Content-Type: application/alto-propmapparams+json 924 { 925 "entities" : [ "ipv4:192.0.2.0/26", 926 "ipv4:192.0.2.0/27", 927 "ipv4:192.0.2.0/28" ], 928 "properties" : [ "ASN", "country", "state" ] 929 } 931 HTTP/1.1 200 OK 932 Content-Length: ### 933 Content-Type: application/alto-propmap+json 935 { 936 "property-map": { 937 "ipv4:192.0.2.0/26": {"country": "us"}, 938 "ipv4:192.0.2.0/27": {"country": "us"}, 939 "ipv4:192.0.2.0/28": {"ASN": "12345", 940 "country": "us", 941 "state": "NJ"} 942 } 943 } 945 7.7. Filtered Property Map Example #3 947 The following example uses the Filtered Property Map resource to 948 request the "pid" property for several IPv4 addresses and prefixes. 950 Note that the value of "pid" for the prefix "ipv4:192.0.2.0/26" is 951 "pid1", even though all addresses in that block are in "pid2", 952 because "ipv4:192.0.2.0/25" is the longest prefix in the network map 953 which prefix-matches "ipv4:192.0.2.0/26", and that prefix is in 954 "pid1". 956 POST /propmap/lookup/pid HTTP/1.1 957 Host: alto.example.com 958 Accept: application/alto-propmap+json,application/alto-error+json 959 Content-Length: ### 960 Content-Type: application/alto-propmapparams+json 962 { 963 "entities" : [ 964 "ipv4:192.0.2.0", 965 "ipv4:192.0.2.16", 966 "ipv4:192.0.2.64", 967 "ipv4:192.0.2.128", 968 "ipv4:192.0.2.0/26", 969 "ipv4:192.0.2.0/30" ], 970 "properties" : [ "pid" ] 971 } 973 HTTP/1.1 200 OK 974 Content-Length: ### 975 Content-Type: application/alto-propmap+json 977 { 978 "meta" : { 979 "dependent-vtags" : [ 980 {"resource-id": "default-network-map", 981 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 982 ] 983 }, 984 "property-map": { 985 "ipv4:192.0.2.0": {"pid": "pid2"}, 986 "ipv4:192.0.2.16": {"pid": "pid2"}, 987 "ipv4:192.0.2.64": {"pid": "pid1"}, 988 "ipv4:192.0.2.128": {"pid": "defaultpid"}, 989 "ipv4:192.0.2.0/26": {"pid": "pid1"}, 990 "ipv4:192.0.2.0/30": {"pid": "pid2"} 991 } 992 } 994 7.8. Filtered Property Map Example #4 996 The following example uses the Filtered Property Map resource to 997 request the "country" and "state" property for several PIDs defined 998 in "default-network-map". 1000 POST /propmap/lookup/location HTTP/1.1 1001 Host: alto.example.com 1002 Accept: application/alto-propmap+json,application/alto-error+json 1003 Content-Length: ### 1004 Content-Type: application/alto-propmapparams+json 1006 { 1007 "entities" : ["pid:pid3", 1008 "pid:pid4", 1009 "pid:pid5", 1010 "pid:pid6", 1011 "pid:pid7"], 1012 "properties" : [ "country", "state" ] 1013 } 1015 HTTP/1.1 200 OK 1016 Content-Length: ### 1017 Content-Type: application/alto-propmap+json 1019 { 1020 "meta" : { 1021 "dependent-vtags" : [ 1022 {"resource-id": "default-network-map", 1023 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 1024 ] 1025 }, 1026 "property-map": { 1027 "pid:pid3": { 1028 "country": "us", 1029 "state": "CA" 1030 }, 1031 "pid:pid4": { 1032 "country": "us", 1033 "state": "CT" 1034 }, 1035 "pid:pid5": { 1036 "country": "ca", 1037 "state": "QC" 1038 }, 1039 "pid:pid6": { 1040 "country": "ca", 1041 "state": "NT" 1042 }, 1043 "pid:pid7": { 1044 "country": "fr" 1045 } 1046 } 1047 } 1049 8. Security Considerations 1051 As discussed in Section 15 of [RFC7285], properties MAY have 1052 sensitive customer-specific information. If this is the case, an 1053 ALTO Server MAY limit access to those properties by providing several 1054 different Property Maps. For non-sensitive properties, the ALTO 1055 Server would provide a URI which accepts requests from any client. 1056 Sensitive properties, on the other hand, would only be available via 1057 a secure URI which would require client authentication. 1059 Also, while technically this document does not introduce any security 1060 risks not inherent in the Endpoint Property Service defined by 1061 [RFC7285], the GET-mode property map resource defined in this 1062 document does make it easier for a client to download large numbers 1063 of property values. Accordingly, an ALTO Server SHOULD limit GET- 1064 mode Property Maps to properties which do not contain sensitive data. 1066 9. IANA Considerations 1068 This document defines additional application/alto-* media types, and 1069 extends the ALTO endpoint property registry. 1071 9.1. application/alto-* Media Types 1073 This document registers two additional ALTO media types, listed in 1074 Table 1. 1076 +--------------+--------------------------+-----------------------+ 1077 | Type | Subtype | Specification | 1078 +--------------+--------------------------+-----------------------+ 1079 | application | alto-propmap+json | Section 4.1 | 1080 | application | alto-propmapparams+json | Section 5.3 | 1081 +--------------+--------------------------+-----------------------+ 1083 Table 1: Additional ALTO Media Types. 1085 Type name: application 1087 Subtype name: This document registers multiple subtypes, as listed 1088 in Table 1. 1090 Required parameters: n/a 1092 Optional parameters: n/a 1094 Encoding considerations: Encoding considerations are identical to 1095 those specified for the "application/json" media type. See 1096 [RFC7159]. 1098 Security considerations: Security considerations related to the 1099 generation and consumption of ALTO Protocol messages are discussed 1100 in Section 15 of [RFC7285]. 1102 Interoperability considerations: This document specifies formats of 1103 conforming messages and the interpretation thereof. 1105 Published specification: This document is the specification for 1106 these media types; see Table 1 for the section documenting each 1107 media type. 1109 Applications that use this media type: ALTO servers and ALTO clients 1110 either stand alone or are embedded within other applications. 1112 Additional information: 1114 Magic number(s): n/a 1116 File extension(s): This document uses the mime type to refer to 1117 protocol messages and thus does not require a file extension. 1119 Macintosh file type code(s): n/a 1121 Person & email address to contact for further information: See 1122 Authors' Addresses section. 1124 Intended usage: COMMON 1126 Restrictions on usage: n/a 1128 Author: See Authors' Addresses section. 1130 Change controller: Internet Engineering Task Force 1131 (mailto:iesg@ietf.org). 1133 9.2. ALTO Entity Domain Registry 1135 This document requests IANA to create and maintain the "ALTO Entity 1136 Domain Registry", listed in Table 2. 1138 +-------------+--------------------------+--------------------------+ 1139 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1140 +-------------+--------------------------+--------------------------+ 1141 | ipv4 | See Section 3.1.1 | See Section 3.1.3 | 1142 | ipv6 | See Section 3.1.2 | See Section 3.1.3 | 1143 | pid | See Section 3.2 | None | 1144 +-------------+--------------------------+--------------------------+ 1146 Table 2: ALTO Entity Domains. 1148 This registry serves two purposes. First, it ensures uniqueness of 1149 identifiers referring to ALTO entity domains. Second, it states the 1150 requirements for allocated entity domains. 1152 9.2.1. Consistency Procedure between ALTO Address Type Registry and 1153 ALTO Entity Domain Registry 1155 One potential issue of introducing the "ALTO Entity Domain Registry" 1156 is its relationship with the "ALTO Address Types Registry" already 1157 defined in Section 14.4 of [RFC7285]. In particular, the entity 1158 address of an entity domain registered in the "ALTO Entity Domain 1159 Registry" MAY match an address type defined in "ALTO Address Type 1160 Registry". It is necessary to precisely define and guarantee the 1161 consistency between "ALTO Address Type Registry" and "ALTO Entity 1162 Domain Registry". 1164 We define that the ALTO Entity Domain Registry is consistent with 1165 ALTO Address Type Registry if two conditions are satisfied: 1167 o When an address type is already or able to be registered in the 1168 ALTO Address Type Registry [RFC7285], the same identifier MUST be 1169 used when a corresponding entity domain is registered in the ALTO 1170 Entity Domain Registry. 1172 o If an ALTO entity domain has the same identifier as an ALTO 1173 address type, their addresses encoding MUST be compatible. 1175 To achieve this consistency, the following items MUST be checked 1176 before registering a new ALTO entity domain in a future document: 1178 o Whether the ALTO Address Type Registry contains an address type 1179 that can be used as an entity address for the candidate domain 1180 identifier. This has been done for the identifiers "ipv4" and 1181 "ipv6" in Table 2. 1183 o Whether the candidate entity address of the entity domain is able 1184 to be an endpoint address, as defined in Sections 2.1 and 2.2 of 1185 [RFC7285]. 1187 When a new ALTO entity domain is registered, the consistency with the 1188 ALTO Address Type Registry MUST be ensured by the following 1189 procedure: 1191 o test: Do corresponding entity addresses match a known "network" 1192 address type? 1194 * if yes: (e.g., cell, MAC or socket addresses) 1196 + test: Is such an address type present in the ALTO Address 1197 Type Registry? 1199 - if yes: Set the new ALTO entity domain identifier to be 1200 the found ALTO address type identifier. 1202 - if no: Define a new ALTO entity domain identifier and use 1203 it to register a new address type in the ALTO Address 1204 Type Registry following Section 14.4 of [RFC7285]. 1206 + Use the new ALTO entity domain identifier to register a new 1207 ALTO entity domain in the ALTO Entity Domain Registry 1208 following Section 9.2.2 of this document. 1210 * if no (e.g., pid name, ane name or country code): Proceed with 1211 the ALTO Entity Domain registration as described in 1212 Section 9.2.2. 1214 9.2.2. ALTO Entity Domain Registration Process 1216 New ALTO entity domains are assigned after IETF Review [RFC5226] to 1217 ensure that proper documentation regarding the new ALTO entity 1218 domains and their security considerations has been provided. RFCs 1219 defining new entity domains SHOULD indicate how an entity in a 1220 registered domain is encoded as an EntityAddr, and, if applicable, 1221 the rules defining the entity hierarchy and property inheritance. 1222 Updates and deletions of ALTO entity domains follow the same 1223 procedure. 1225 Registered ALTO entity domain identifiers MUST conform to the 1226 syntactical requirements specified in Section 2.3. Identifiers are 1227 to be recorded and displayed as strings. 1229 Requests to the IANA to add a new value to the registry MUST include 1230 the following information: 1232 o Identifier: The name of the desired ALTO entity domain. 1234 o Entity Address Encoding: The procedure for encoding the address of 1235 an entity of the registered type as an EntityAddr (see 1236 Section 2.4). If corresponding entity addresses of an entity 1237 domain match a known "network" address type, the Entity Address 1238 Encoding of this domain identifier MUST include both Address 1239 Encoding and Prefix Encoding of the same identifier registered in 1240 the ALTO Address Type Registry [RFC7285]. For the purpose of 1241 defining properties, an individual entity address and the 1242 corresponding full-length prefix MUST be considered aliases for 1243 the same entity. 1245 o Hierarchy: If the entities form a hierarchy, the procedure for 1246 determining that hierarchy. 1248 o Inheritance: If entities can inherit property values from other 1249 entities, the procedure for determining that inheritance. 1251 o Security Considerations: In some usage scenarios, entity addresses 1252 carried in ALTO Protocol messages MAY reveal information about an 1253 ALTO client or an ALTO service provider. Applications and ALTO 1254 service providers using addresses of the registered type SHOULD be 1255 made aware of how (or if) the addressing scheme relates to private 1256 information and network proximity. 1258 This specification requests registration of the identifiers "ipv4", 1259 "ipv6" and "pid", as shown in Table 2. 1261 9.3. ALTO Endpoint Property Type Registry 1263 The ALTO Endpoint Property Type Registry was created by [RFC7285]. 1264 If possible, the name of that registry SHOULD be changed to "ALTO 1265 Entity Property Type Registry", to indicate that it is not restricted 1266 to Endpoint Properties. If it is not feasible to change the name, 1267 the description MUST be amended to indicate that it registers 1268 properties in all entity domains, rather than just the Internet 1269 address domain. 1271 10. References 1273 10.1. Normative References 1275 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1276 Requirement Levels", BCP 14, RFC 2119, 1277 DOI 10.17487/RFC2119, March 1997, 1278 . 1280 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1281 Resource Identifier (URI): Generic Syntax", STD 66, 1282 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1283 . 1285 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1286 (CIDR): The Internet Address Assignment and Aggregation 1287 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1288 2006, . 1290 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1291 IANA Considerations Section in RFCs", RFC 5226, 1292 DOI 10.17487/RFC5226, May 2008, 1293 . 1295 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1296 Address Text Representation", RFC 5952, 1297 DOI 10.17487/RFC5952, August 2010, 1298 . 1300 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1301 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1302 2014, . 1304 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1305 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1306 "Application-Layer Traffic Optimization (ALTO) Protocol", 1307 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1308 . 1310 10.2. Informative References 1312 [I-D.ietf-alto-path-vector] 1313 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 1314 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 1315 Vector Cost Type", draft-ietf-alto-path-vector-03 (work in 1316 progress), March 2018. 1318 Authors' Addresses 1320 Wendy Roome 1321 Nokia Bell Labs (Retired) 1322 124 Burlington Rd 1323 Murray Hill, NJ 07974 1324 USA 1326 Phone: +1-908-464-6975 1327 Email: wendy@wdroome.com 1328 Shiwei Dawn Chen 1329 Tongji University 1330 4800 Caoan Road 1331 Shanghai 201804 1332 China 1334 Email: dawn_chen_f@hotmail.com 1336 Sabine Randriamasy 1337 Nokia Bell Labs 1338 Route de Villejust 1339 NOZAY 91460 1340 FRANCE 1342 Email: Sabine.Randriamasy@nokia-bell-labs.com 1344 Y. Richard Yang 1345 Yale University 1346 51 Prospect Street 1347 New Haven, CT 06511 1348 USA 1350 Phone: +1-203-432-6400 1351 Email: yry@cs.yale.edu 1353 Jingxuan Jensen Zhang 1354 Tongji University 1355 4800 Caoan Road 1356 Shanghai 201804 1357 China 1359 Email: jingxuan.n.zhang@gmail.com