idnits 2.17.1 draft-roome-alto-unified-props-new-01.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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 624 has weird spacing: '...rtyName prop...' == Line 752 has weird spacing: '...country stat...' -- The document date (July 3, 2017) is 2460 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) == Outdated reference: A later version (-25) exists of draft-ietf-alto-path-vector-00 ** Downref: Normative reference to an Experimental draft: draft-ietf-alto-path-vector (ref. 'I-D.ietf-alto-path-vector') ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 5 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 R. Yang 5 Expires: January 4, 2018 Yale University 6 July 3, 2017 8 Extensible Property Maps for the ALTO Protocol 9 draft-roome-alto-unified-props-new-01 11 Abstract 13 This document extends the Application-Layer Traffic Optimization 14 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint 15 properties" to other entity domains, and by presenting those 16 properties as maps, similar to the network and cost maps in ALTO. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC 2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 4, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Definitions and Concepts . . . . . . . . . . . . . . . . . . 4 60 2.1. Entity . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.2. Domain . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 2.3. Entity Address . . . . . . . . . . . . . . . . . . . . . 4 63 2.4. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.5. Property Name . . . . . . . . . . . . . . . . . . . . . . 5 65 2.6. Property Value . . . . . . . . . . . . . . . . . . . . . 6 66 2.7. Hierarchy and Inheritance . . . . . . . . . . . . . . . . 6 67 2.8. Relationship to Network Maps . . . . . . . . . . . . . . 6 68 3. Entity Domains . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.1. Internet Address Domains . . . . . . . . . . . . . . . . 7 70 3.1.1. IPv4 Domain . . . . . . . . . . . . . . . . . . . . . 7 71 3.1.2. IPv6 Domain . . . . . . . . . . . . . . . . . . . . . 8 72 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains . . . 8 73 3.1.4. Relationship to Network Maps . . . . . . . . . . . . 9 74 3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 10 76 3.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 10 77 3.2.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 10 78 3.2.4. Relationship To Internet Addresses Domains . . . . . 10 79 3.3. Internet Address Properties vs. PID Properties . . . . . 10 80 3.4. ANE Domain . . . . . . . . . . . . . . . . . . . . . . . 11 81 3.4.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 11 82 3.4.2. Domain-Specific Entity Addresses . . . . . . . . . . 11 83 3.4.3. Hierarchy and Inheritance . . . . . . . . . . . . . . 11 84 3.4.4. Relationship to Cost Map . . . . . . . . . . . . . . 11 85 4. Property Map Resource . . . . . . . . . . . . . . . . . . . . 11 86 4.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 11 87 4.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 12 88 4.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 12 89 4.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 12 90 4.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 12 91 4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 92 5. Filtered Property Map Resource . . . . . . . . . . . . . . . 13 93 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 14 94 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 14 95 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 14 96 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 14 97 5.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 5.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 15 99 6. Impact on Legacy ALTO Servers and ALTO Clients . . . . . . . 15 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 . . . . . . . . . . . . . . 16 103 6.4. Impact on Other Properties . . . . . . . . . . . . . . . 16 104 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16 105 7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 16 106 7.2. Property Definitions . . . . . . . . . . . . . . . . . . 17 107 7.3. Information Resource Directory (IRD) . . . . . . . . . . 17 108 7.4. Property Map Example . . . . . . . . . . . . . . . . . . 19 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 . . . . . . . . . . . . . . . . . . . 23 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 115 9.1. application/alto-* Media Types . . . . . . . . . . . . . 24 116 9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 25 117 9.3. ALTO Endpoint Property Type Registry . . . . . . . . . . 26 118 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 119 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 121 1. Introduction 123 The ALTO protocol [RFC7285] introduced the concept of "properties" 124 attached to "endpoint addresses," and defined the Endpoint Property 125 Service (EPS) to allow clients to retrieve those properties. While 126 useful, the EPS, as defined in RFC7285, has at least two limitations. 128 First, it only allows properties to be associated with a particular 129 domain of entities, namely individual IP addresses. It is reasonable 130 to think that collections of endpoints, as defined by CIDRs 131 ([RFC4632]) or PIDs, may also have properties. Furthermore, recent 132 proposal ([I-D.ietf-alto-path-vector]) have suggested new classes of 133 entities (ANE) with properties. The EPS cannot be extended to new 134 entity domains. Instead, new services, with new request and response 135 messages, would have to be defined for each new entity domain. 137 Second, the EPS is only defined as a POST-mode service. Clients must 138 request the properties for an explicit set of addresses. By 139 contrast, [RFC7285] defines a GET-mode Cost Map resource which 140 returns all available costs, so a client can get the full set of 141 costs once, and then lookup costs without querying the ALTO server. 142 RFC7285 does not define an equivalent service for endpoint 143 properties. And it is unlikely a property will be defined for every 144 possible address. It is very likely that properties will only be 145 defined for a subset of addresses, and that subset would be small 146 enough to enumerate. This is particularly true if blocks of 147 addresses with a common prefix (e.g., a CIDR) have the same value for 148 a property. Furthermore, entities in other domains may very well be 149 enumerable. 151 This document proposes a new approach to retrieve ALTO properties. 152 Specifically, it defines two new resource types, namely Property Maps 153 (see Section 4) and Filtered Property Maps (see Section 5). The 154 former are GET-mode resources which return the property values for 155 all entities in a domain, and are analogous to the ALTO's Network 156 Maps and Cost Maps. The latter are POST-mode resources which return 157 the values for a set of properties and entities requested by the 158 client, and are analogous to ALTO's Filtered Network Maps and 159 Filtered Cost Maps. 161 Entity domains and property names are extensible, so that new domains 162 can be defined without revising the messages defined in this 163 document, in the same way that new cost metrics and new endpoint 164 properties can be defined without revising the messages defined by 165 the ALTO protocol. 167 This proposal would subsume the Endpoint Property Service defined in 168 RFC7285, although that service may be retained for legacy clients 169 (see Section 6). 171 2. Definitions and Concepts 173 2.1. Entity 175 An entity is an object with a (possibly empty) set of properties. 176 Every entity is in a domain, such as the IPv4 and IPv6 domains, and 177 has a unique address. 179 2.2. Domain 181 A domain is a family of entities. Two examples are the Internet 182 address and PID domain (see Section 3.1 and Section 3.2) that this 183 document will define. An additional example is the proposed domain 184 of Abstract Network Elements associated with topology and routing, as 185 suggested by [I-D.ietf-alto-path-vector]. 187 2.3. Entity Address 189 Each entity has a unique address of the format: 191 domain-name : domain-specific-entity-address 193 Examples from the IP domain include individual addresses such as 194 "ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks 195 such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48". 197 The type EntityAddr denotes a JSON string with an entity address in 198 this format. 200 The format of the second part of an entity address depends on the 201 domain, and MUST be specified when registering a new domain. 202 Addresses MAY be hierarchical, and properties MAY be inherited based 203 on that hierarchy. Again, the rules defining any hierarchy or 204 inheritance MUST be defined when the domain is registered. 206 Note that entity addresses MAY have different textual 207 representations, for a given domain. For example, the strings 208 "ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same 209 entity. 211 2.4. Domain Name 213 Each domain has a unique name. A domain name MUST be no more than 32 214 characters, and MUST NOT contain characters other than US-ASCII 215 alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 216 U+0061-U+007A), hyphen ('-', U+002D), and low line ('_', U+005F). 217 For example, the names "ipv4" and "ipv6" identify objects in the 218 Internet address domain (Section 3.1). 220 The type DomainName denotes a JSON string with a domain name in this 221 format. 223 Domain names MUST be registered with the IANA, and the format of the 224 entity addresses in that domain, as well as any hierarchical or 225 inheritance rules for those entities, MUST be specified at the same 226 time. 228 2.5. Property Name 230 The space of property names associated with entities defined by this 231 document is the same as, and is shared with, the endpoint property 232 names defined by [RFC7285]. Thus entity property names are as 233 defined in Section 10.8.2 of that document, and MUST be registered 234 with the "ALTO Endpoint Property Type Registry" defined in 235 Section 14.3 of that document. 237 The type PropertyName denotes a JSON string with a property name in 238 this format. 240 A main design decision is that property names are defined in a single 241 namespace, not specific to a domain, although some properties MAY 242 only be applicable for particular domains. This design decision is 243 to enforce a design that similar properties are named similarly. 245 The interpretation of the value of a property, however, MAY depend on 246 the domain. For example, suppose the "geo-location" property is 247 defined as the coordinates of a point, encoded as "latitude longitude 248 [altitude]." When applied to an entity that represents a specific 249 host computer, such as an Internet address, the property defines the 250 host's location. When applied to an entity that represents a set of 251 computers, such as a CIDR, the property would be the location of the 252 center of that set. If it is necessary to represent the bounding box 253 of a set of hosts, another property, such as "geo-region", SHOULD be 254 defined. 256 2.6. Property Value 258 The property value MAY BE defined or undefined. If it is defined, it 259 SHOULD BE a JSONString or a JSON "null" value. Otherwise, a protocol 260 implementation SHOULD fail to parse the property value, unless the 261 implementation is using an extension to this document that indicates 262 when and how property values of other data types are signaled. 264 2.7. Hierarchy and Inheritance 266 Entities in a given domain MAY form hiearchy based on entity address. 267 Each domain MAY define its own hierarchy and inheritance semantics. 268 Given a property, the semantics MUST NOT allow an entity with a 269 defined property value to inherit the property value of another 270 entity. Given a property, the semantics MAY allow an entity with an 271 undefined property value to inherit the property value of another 272 entity. An entity may not be able to inherit a property value if no 273 other entities satisfy the inheritance conditions defined by the 274 semantics. The hierarchy and inheritance semantics SHOULD be defined 275 carefully to avoid multiple inheritance. 277 2.8. Relationship to Network Maps 279 [RFC7285] recognizes that some properties MAY be specific to an ALTO 280 resource, such as a network map. Accordingly [RFC7285] defines the 281 concept of "resource-specific endpoint properties" (Section 10.8.1), 282 and indicates that dependency by prefixing the property name with the 283 ID of the resource on which it depends. That document defines one 284 resource-specific property, namely the "pid" property, whose value is 285 the name of the PID containing that endpoint in the associated 286 network map. 288 This document takes a different approach. Instead of defining the 289 dependency by qualifying the property name, this document attaches 290 the dependency to the property map as a whole. Thus all properties 291 in a given property map depend on the same resource. Furthermore, 292 entity addresses MAY depend on a network map (for example, the 293 Abstract Network Elements suggested by [I-D.ietf-alto-path-vector]). 294 Associating the dependency with the property map handles any entity 295 address dependencies as well. 297 The "uses" field in an IRD entry defines the dependencies of a 298 property map resource, and the "dependent-vtags" field in a property 299 map response defines the dependencies of that map. These fields are 300 defined in Sections 9.1.5 and 11.1 of [RFC7285], respectively. 302 This is similar to how RFC7285 handles dependencies between cost maps 303 and network maps. Recall that cost maps present the costs between 304 PIDs, and PID names depend on a network map. If an ALTO server 305 provides the "routingcost" metric for the network maps "net1" and 306 "net2", then the server defines two separate cost maps, one for 307 "net1" and the other for "net2". 309 According to [RFC7285], a legacy ALTO server with two network maps, 310 with resource IDs "net1" and "net2", could offer a single Endpoint 311 Property Service for the two properties "net1.pid" and "net2.pid". 312 An ALTO server which supports the extensions defined in this 313 document, would, instead, offer two different Property Maps for the 314 "pid" property, one depending on "net1", the other on "net2". 316 3. Entity Domains 318 This document defines the following entity domains. For the 319 definition of each domain, it includes the following template: domain 320 name, domain-specific addresses, and hierarchy and inheritance 321 semantics. 323 3.1. Internet Address Domains 325 The document defines two domains (IPv4 and IPv6) for Internet 326 addresses. Both domains include individual addresses and blocks of 327 addresses. 329 3.1.1. IPv4 Domain 331 3.1.1.1. Domain Name 333 ipv4 335 3.1.1.2. Domain-Specific Entity Addresses 337 Individual addresses are strings as specified by the IPv4Addresses 338 rule of Section 3.2.2 of [RFC3986]. Blocks of addresses are prefix- 339 match strings as specified in Section 3.1 of [RFC4632]. For the 340 purpose of defining properties, an individual Internet address and 341 the corresponding full-length prefix are considered aliases for the 342 same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are 343 equivalent. 345 3.1.2. IPv6 Domain 347 3.1.2.1. Domain Name 349 ipv6 351 3.1.2.2. Domain-Specific Entity Addresses 353 Individual addresses are strings as specified by Section 4 of 354 [RFC5952]. Blocks of addresses are prefix-match strings as specified 355 in Section 7 of [RFC5952]. For the purpose of defining properties, 356 an individual Internet address and the corresponding 128-bit prefix 357 are considered aliases for the same entity. That is, 358 "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and 359 have the same set of properties. 361 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains 363 Both domains allow property values to be inherited. Specifically, if 364 a property P is not defined for a specific Internet address IP, but P 365 is defined for some block C which prefix-matches IP, then the address 366 IP inherits the value of P defined for block C. If more than one 367 such block defines a value for P, IP inherits the value of P in the 368 block with the longest prefix. It is important to notice that this 369 longest prefix rule will ensure no multiple inheritance, and hence no 370 ambiguity. 372 Address blocks can also inherit properties: if property P is not 373 defined for a block C, but is defined for some block C' prefix- 374 matches C, and C' has a shorter mask than C, then block C inherits 375 the property from C'. If there are several such blocks C', C 376 inherits from the block with the longest prefix. 378 ipv4:192.0.2.0/26: P=v1 379 ipv4:192.0.2.0/28: P=v2 380 ipv4:192.0.2.0/30: P=v3 381 ipv4:192.0.2.0: P=v4 383 Figure 1: Defined Property Values. 385 Then the following entities have the indicated values: 387 ipv4:192.0.2.0: P=v4 388 ipv4:192.0.2.1: P=v3 389 ipv4:192.0.2.16: P=v1 390 ipv4:192.0.2.32: P=v1 391 ipv4:192.0.2.64: (not defined) 392 ipv4:192.0.2.0/32: P=v4 393 ipv4:192.0.2.0/31: P=v3 394 ipv4:192.0.2.0/29: P=v2 395 ipv4:192.0.2.0/27: P=v1 396 ipv4:192.0.2.0/25: (not defined) 398 Figure 2: Inherited Property Values. 400 An ALTO Server MAY explicitly define a property as not having a value 401 for a particular entity. That is, a server MAY say that a property 402 is "defined to have no value", as opposed to the property being 403 "undefined". If that entity would inherit a value for that property, 404 then the ALTO server MUST return a "null" value for that property, 405 and an ALTO client MUST recognize a "null" value means "do not apply 406 the inheritance rules for this property." If the entity would not 407 inherit a value, the ALTO server MAY return "null" or MAY just omit 408 the property. TODO: Discuss more. 410 If the ALTO Server does not define any properties for an entity, then 411 the server MAY omit that entity from the response. 413 3.1.4. Relationship to Network Maps 415 TODO: Need discussion. An Internet address domain MAY be associated 416 with an ALTO network map resource. Logically, there is a map of 417 Internet address entities to property values for each network map 418 defined by the ALTO server, plus an additional property map for 419 Internet address entities which are not associated with a network 420 map. These maps are separate from each other. The prefixes in the 421 property map do not have to correspond to the prefixes defining the 422 network map's PIDs. For example, the property map for a network map 423 MAY assign properties to "ipv4:192.0.2.0/24" even if that prefix is 424 not associated with any PID in the network map. 426 3.2. PID Domain 428 The PID domain associates property values with the PIDs in a network 429 map. Accordingly, this domain always depends on a network map. 431 3.2.1. Domain Name 433 pid 435 3.2.2. Domain-Specific Entity Addresses 437 The entity addresses are the PID names of the associated network map. 439 3.2.3. Hierarchy and Inheritance 441 There is no hierarchy or inheritance for properties associated with 442 PIDs. 444 3.2.4. Relationship To Internet Addresses Domains 446 The PID domain and the Internet address domains are completely 447 independent; the properties associated with a PID have no relation to 448 the properties associated with the prefixes or endpoint addresses in 449 that PID. An ALTO server MAY choose to assign some or all properties 450 of a PID to the prefixes in that PID. 452 For example, suppose "PID1" consists of the prefix 453 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 454 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24", 455 in the IPv4 domain MAY have a value for the property "P", and if they 456 do, it is not necessarily "v1". 458 3.3. Internet Address Properties vs. PID Properties 460 Because the Internet address and PID domains are completely separate, 461 the question may arise as to which domain is best for a property. In 462 general, the Internet address domain is RECOMMENDED for properties 463 that are closely related to the Internet address, or are associated 464 with, and inherited through, blocks of addresses. 466 The PID domain is RECOMMENDED for properties that arise from the 467 definition of the PID, rather than from the Internet address prefixes 468 in that PID. 470 For example, because Internet addresses are allocated to service 471 providers by blocks of prefixes, an "ISP" property would be best 472 associated with the Internet address domain. On the other hand, a 473 property that explains why a PID was formed, or how it relates the a 474 provider's network, would best be associated with the PID domain. 476 3.4. ANE Domain 478 3.4.1. Domain Name 480 ane 482 3.4.2. Domain-Specific Entity Addresses 484 The entity address of ane domain is encoded as a JSON string. The 485 string MUST be no more than 64 characters, and it MUST NOT contain 486 characters other than US-ASCII alphanumeric characters 487 (U+0030-U+0039, U+0041-U+005A, and U+0061-U+007A), the hyphen ('-', 488 U+002D), the colon (':', U+003A), the at sign ('@', code point 489 U+0040), the low line ('_', U+005F), or the '.' separator (U+002E). 490 The '.' separator is reserved for future use and MUST NOT be used 491 unless specifically indicated in this document, or an extension 492 document. 494 3.4.3. Hierarchy and Inheritance 496 There is no hierarchy or inheritance for properties associated with 497 ANEs. 499 3.4.4. Relationship to Cost Map 501 TBA 503 4. Property Map Resource 505 A Property Map returns the properties defined for all entities in one 506 or more domains. Note that Property Map Resource is not applicable 507 to ANE domain. 509 Section 7.4 gives an example of a property map request and its 510 response. 512 4.1. Media Type 514 The media type of an ALTO Property Map resource is "application/alto- 515 propmap+json". 517 4.2. HTTP Method 519 An ALTO Property Map resource is requested using the HTTP GET method. 521 4.3. Accept Input Parameters 523 None. 525 4.4. Capabilities 527 The capabilities are defined by an object of type 528 PropertyMapCapabilities: 530 object { 531 DomainName domain-types<1..*>; 532 PropertyName prop-types<1..*>; 533 } PropertyMapCapabilities; 535 where "domain-types" is an array with the domains of the entities in 536 this property map, and "prop-types" is an array with the names of the 537 properties returned for entities in those domains. TODO: discuss 538 semantics and requirements of multiple domains. 540 4.5. Uses 542 An array with the resource ID(s) of resource(s) with which the 543 domains in this map are associated. In most cases, this array will 544 have at most one ID, for example, for a network map resource. TODO: 545 discuss semantics and requirements of multiple resources. 547 4.6. Response 549 If the domains in this property map depend on other resources, the 550 "dependent-vtags" field in the "meta" field of the response MUST be 551 an array that includes the version tags of those resources. The data 552 component of a Property Map response is named "property-map", which 553 is a JSON object of type PropertyMapData, where: 555 object { 556 PropertyMapData property-map; 557 } InfoResourceProperties : ResponseEntityBase; 559 object-map { 560 EntityAddr -> EntityProps; 561 } PropertyMapData; 563 object { 564 PropertyName -> JSONValue; 565 } EntityProps; 567 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 569 Specifically, a PropertyMapData object has one member for each entity 570 in the Property Map. The entity's properties are encoded in the 571 corresponding EntityProps object. EntityProps encodes one name/value 572 pair for each property, where the property names are encoded as 573 strings of type PropertyName. A protocol implementation SHOULD 574 assume that the property value is either a JSONString or a JSON 575 "null" value, and fail to parse if it is not, unless the 576 implementation is using an extension to this document that indicates 577 when and how property values of other data types are signaled. 579 An ALTO Server MAY explicitly define a property as not having a value 580 for a particular entity. That is, a server MAY say that a property 581 is "defined to have no value", as opposed to the property being 582 "undefined". If that entity would inherit a value for that property, 583 then the ALTO server MUST return a "null" value for that property, 584 and an ALTO client MUST recognize a "null" value means "do not apply 585 the inheritance rules for this property." If the entity would not 586 inherit a value, the ALTO server MAY return "null" or MAY just omit 587 the property. 589 For each entity in the Property Map, the ALTO Server returns the 590 value defined for each of the properties specified in this resource's 591 "capabilities" list. For efficiency, the ALTO Server SHOULD omit 592 property values that are inherited rather than explicitly defined; if 593 a client needs inherited values, the client SHOULD use the domain's 594 inheritance rules to deduce those values. 596 5. Filtered Property Map Resource 598 A Filtered Property Map returns the values of a set of properties for 599 a set of entities selected by the client. 601 Section 7.5, Section 7.6 and Section 7.7 give examples of filtered 602 property map requests and responses. 604 5.1. Media Type 606 The media type of an ALTO Property Map resource is "application/alto- 607 propmap+json". 609 5.2. HTTP Method 611 An ALTO Filtered Property Map resource is requested using the HTTP 612 POST method. 614 5.3. Accept Input Parameters 616 The input parameters for a Filtered Property Map request are supplied 617 in the entity body of the POST request. This document specifies the 618 input parameters with a data format indicated by the media type 619 "application/alto-propmapparams+json", which is a JSON object of type 620 ReqFilteredPropertyMap: 622 object { 623 EntityAddr entities<1..*>; 624 PropertyName properties<1..*>; 625 } ReqFilteredPropertyMap; 627 with fields: 629 entities: List of entity addresses for which the specified 630 properties are to be returned. The ALTO server MUST interpret 631 entries appearing multiple times as if they appeared only once. 632 The domain of each entity MUST be included in the list of domains 633 in this resource's "capabilities" field (Section 5.4). 635 properties: List of properties to be returned for each entity. Each 636 specified property MUST be included in the list of properties in 637 this resource's "capabilities" field (Section 5.4). The ALTO 638 server MUST interpret entries appearing multiple times as if they 639 appeared only once. 641 Note that the "entities" and "properties" fields MUST have at 642 least one entry each. 644 5.4. Capabilities 646 The capabilities are defined by an object of type 647 PropertyMapCapabilities, as defined in Section 4.4. 649 5.5. Uses 651 An array with the resource ID(s) of resource(s) with which the 652 domains in this map are associated. In most cases, this array will 653 have at most one ID, and it will be for a network map resource. 655 5.6. Response 657 The response is the same as for the property map (Section 4.6), 658 except that it only includes the entities and properties requested by 659 the client. 661 Also, the Filtered Property Map response MUST include all inherited 662 property values for the specified entities (unlike the Full Property 663 Map, the Filtered Property Map response does not include enough 664 information for the client to calculate the inherited values). 666 Discussion Needed: sometimes the client can compute some inherited 667 property values. In this case, can the Filter Property Map response 668 only contain the uncomputable inherited property values instead of 669 all of them? 671 6. Impact on Legacy ALTO Servers and ALTO Clients 673 6.1. Impact on Endpoint Property Service 675 The Property Maps defined in this document provide the same 676 functionality as the Endpoint Property Service (EPS) defined in 677 Section 11.4 of [RFC7285]. Accordingly, it is RECOMMENDED that the 678 EPS be deprecated in favor of Property Maps. However, ALTO servers 679 MAY provide an EPS for the benefit of legacy clients. 681 6.2. Impact on Resource-Specific Properties 683 Section 10.8 of [RFC7285] defines two categories of endpoint 684 properties: "resource-specific" and "global". Resource-specific 685 property names are prefixed with the ID of the resource they depended 686 upon, while global property names have no such prefix. The property 687 map resources defined in this document do not distinguish between 688 those two types of properties. Instead, if there is a dependency, it 689 is indicated by the "uses" capability of a property map, and is 690 shared by all properties and entity domains in that map. 691 Accordingly, it is RECOMMENDED that resource-specific endpoint 692 properties be deprecated, and no new resource-specific endpoint 693 properties be defined. 695 6.3. Impact on the "pid" Property 697 Section 7.1.1 of [RFC7285] defines the resource-specific endpoint 698 property "pid", whose value is the name of the PID containing that 699 endpoint. For compatibility with legacy clients, an ALTO server 700 which provides the "pid" property via the Endpoint Property Service 701 MUST use that definition, and that syntax, in the EPS resource. 703 However, when used with Property Maps, this document amends the 704 definition of the "pid" property as follows. 706 First, the name of the property is simply "pid"; the name is not 707 prefixed with the resource ID of a network map. The "uses" 708 capability of the property map resource indicates the associated 709 network map. This implies that a property map can only return the 710 "pid" property for one network map; if an ALTO server provides 711 several network maps, it MUST provide a property map resource for 712 each one. 714 Second, a client MAY request the "pid" property for a block of 715 addresses. An ALTO server determines the value of "pid" for an 716 address block C as follows. Let CS be the set of all address blocks 717 in the network map. If C is in CS, then the value of "pid" is the 718 name of the PID associated with C. Otherwise, find the longest block 719 C' in CS such that C' prefix-matches C, but is shorter than C. If 720 there is such a block C', the value of "pid" is the name of the PID 721 associated with C'. If not, then "pid" has no value for block C. 723 Note that although an ALTO server MAY provide a GET-mode property map 724 resource which returns the entire map for the "pid" property, there 725 is no need to do so, because that map is simply the inverse of the 726 network map. 728 6.4. Impact on Other Properties 730 In general, there should be little or no impact on other previously 731 defined properties. The only consideration is that properties can 732 now be defined on blocks of addresses, rather than just individual 733 addresses, which might change the semantics of a property. 735 7. Examples 737 7.1. Network Map 739 The examples in this section use a very simple default network map: 741 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 742 pid1: ipv4:192.0.2.0/25 743 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 745 Figure 3: Example Network Map 747 7.2. Property Definitions 749 The examples in this section use four additional properties, "ISP", 750 "ASN", "country" and "state", with the following values: 752 ISP ASN country state 753 ipv4:192.0.2.0/24: BitsRus - us - 754 ipv4:192.0.2.0/28: - 12345 - NJ 755 ipv4:192.0.2.16/28: - 12345 - CT 756 ipv4:192.0.2.0: - - - PA 758 Figure 4: Example Property Values 760 7.3. Information Resource Directory (IRD) 762 The following IRD defines the relevant resources of the ALTO server. 763 It provides two Property Map resources, one for the "ISP" and "ASN" 764 properties, and another for the "country" and "state" properties. 765 The server could have provided a Property Map resource for all four 766 properties, but did not, presumably because the organization that 767 runs the ALTO server believes any given client is not interested in 768 all four properties. 770 The server provides two Filtered Property Maps. The first returns 771 all four properties, and the second just returns the "pid" property 772 for the default network map. 774 The Filtered Property Maps for the "ISP", "ASN", "country" and 775 "state" properties do not depend on the default network map (it does 776 not have a "uses" capability), because the definitions of those 777 properties do not depend on the default network map. The Filtered 778 Property Map for the "pid" property does have a "uses" capability for 779 the default network map, because that defines the values of the "pid" 780 property. 782 Note that for legacy clients, the ALTO server provides an Endpoint 783 Property Service for the "pid" property for the default network map. 785 "meta": { ... }, 786 "resources" : { 787 "default-network-map" : { 788 "uri" : "http://alto.example.com/networkmap", 789 "media-type" : "application/alto-networkmap+json" 790 }, 791 .... property map resources .... 792 "country-state-property-map" : { 793 "uri" : "http://alto.example.com/propmap/full/inet-cs", 794 "media-type" : "application/alto-propmap+json", 795 "capabilities" : { 796 "domain-types": [ "ipv4", "ipv6" ], 797 "prop-types" : [ "country", "state" ] 798 } 799 }, 800 "isp-asn-property-map" : { 801 "uri" : "http://alto.example.com/propmap/full/inet-ia", 802 "media-type" : "application/alto-propmap+json", 803 "capabilities" : { 804 "domain-types": [ "ipv4", "ipv6" ], 805 "prop-types" : [ "ISP", "ASN" ] 806 } 807 }, 808 "iacs-property-map" : { 809 "uri" : "http://alto.example.com/propmap/lookup/inet-iacs", 810 "media-type" : "application/alto-propmap+json", 811 "accepts" : "application/alto-propmapparams+json", 812 "capabilities" : { 813 "domain-types": [ "ipv4", "ipv6" ], 814 "prop-types" : [ "ISP", "ASN", "country", "state" ] 815 } 816 }, 817 "pid-property-map" : { 818 "uri" : "http://alto.example.com/propmap/lookup/pid", 819 "media-type" : "application/alto-propmap+json", 820 "accepts" : "application/alto-propmapparams+json", 821 "uses" : [ "default-network-map" ] 822 "capabilities" : { 823 "domain-types" : [ "ipv4", "ipv6" ], 824 "prop-types" : [ "pid" ] 825 } 826 }, 827 "availbw-property-map" : { 828 "uri" : "http://alto.example.com/propmap/lookup/availbw", 829 "media-type" : "application/alto-propmap+json", 830 "accepts" : "application/alto-propmapparams+json", 831 "capabilities" : { 832 "domain-types" : [ "ane" ], 833 "prop-types" : [ "availbw", "delay" ] 834 } 835 }, 836 "legacy-pid-property-map" : { 837 "uri" : "http://alto.example.com/legacy/eps-pid", 838 "media-type" : "application/alto-endpointprop+json", 839 "accepts" : "application/alto-endpointpropparams+json", 840 "capabilities" : { 841 "prop-types" : [ "default-network-map.pid" ] 842 } 843 } 844 } 846 Figure 5: Example IRD 848 7.4. Property Map Example 850 The following example uses the properties and IRD defined above to 851 retrieve a property map for entities with the "ISP" and "ASN" 852 properties. Note that the response does not include the entity 853 "ipv4:192.0.2.0", because it does not have a value for either of 854 those properties. Also note that the entities "ipv4:192.0.2.0/28" 855 and "ipv4:192.0.2.16/28" are refinements of "ipv4:192.0.2.0/24", and 856 hence inherit its value for "ISP" property. But because that value 857 is inherited, it is not 859 GET /propmap/full/inet-ia HTTP/1.1 860 Host: alto.example.com 861 Accept: application/alto-propmap+json,application/alto-error+json 863 HTTP/1.1 200 OK 864 Content-Length: ### 865 Content-Type: application/alto-propmap+json 867 { 868 "property-map": { 869 "ipv4:192.0.2.0/24": {"ISP: "BitsRus"}, 870 "ipv4:192.0.2.0/28": {"ASN": "12345"}, 871 "ipv4:192.0.2.16/28": {"ASN": "12345"} 872 } 873 } 875 7.5. Filtered Property Map Example #1 877 The following example uses the Filtered Property Map resource to 878 request the "ISP", "ASN" and "state" properties for several IPv4 879 addresses. Note that the value of "state" for "ipv4:192.0.2.0" is 880 the only explicitly defined property; the other values are all 881 derived by the inheritance rules for Internet address entities. 883 POST /propmap/lookup/inet-iacs HTTP/1.1 884 Host: alto.example.com 885 Accept: application/alto-propmap+json,application/alto-error+json 886 Content-Length: ### 887 Content-Type: application/alto-propmapparams+json 889 { 890 "entities" : [ "ipv4:192.0.2.0", 891 "ipv4:192.0.2.1", 892 "ipv4:192.0.2.17" ], 893 "properties" : [ "ISP", "ASN", "state" ] 894 } 896 HTTP/1.1 200 OK 897 Content-Length: ### 898 Content-Type: application/alto-propmap+json 900 { 901 "property-map": { 902 "ipv4:192.0.2.0": 903 {"ISP": "BitsRus", "ASN": "12345", "state": "PA"}, 904 "ipv4:192.0.2.1": 905 {"ISP": "BitsRus", "ASN": "12345", "state": "NJ"}, 906 "ipv4:192.0.2.17": 907 {"ISP": "BitsRus", "ASN": "12345", "state": "CT"} 908 } 909 } 911 7.6. Filtered Property Map Example #2 913 The following example uses the Filtered Property Map resource to 914 request the "ASN", "country" and "state" properties for several IPv4 915 prefixes. Note that none of the returned property values were 916 explicitly defined; all values are derived by the inheritance rules 917 for Internet address entities. 919 Also note the "ASN" property has the value "12345" for both the 920 blocks "ipv4:192.0.2.0/28" and "ipv4:192.0.2.16/28", so every address 921 in the block "ipv4:192.0.2.0/27" has that property value. However 922 the block "ipv4:192.0.2.0/27" itself does not have a value for "ASN": 923 address blocks cannot inherit properties from blocks with longer 924 prefixes, even if every such block has the same value. 926 POST /propmap/lookup/inet-iacs HTTP/1.1 927 Host: alto.example.com 928 Accept: application/alto-propmap+json,application/alto-error+json 929 Content-Length: ### 930 Content-Type: application/alto-propmapparams+json 932 { 933 "entities" : [ "ipv4:192.0.2.0/26", 934 "ipv4:192.0.2.0/27", 935 "ipv4:192.0.2.0/28" ], 936 "properties" : [ "ASN", "country", "state" ] 937 } 939 HTTP/1.1 200 OK 940 Content-Length: ### 941 Content-Type: application/alto-propmap+json 943 { 944 "property-map": { 945 "ipv4:192.0.2.0/26": {"country": "us"}, 946 "ipv4:192.0.2.0/27": {"country": "us"}, 947 "ipv4:192.0.2.0/28": {"ASN": "12345", 948 "country": "us", 949 "state": "NJ"} 950 } 951 } 953 7.7. Filtered Property Map Example #3 955 The following example uses the Filtered Property Map resource to 956 request the "pid" property for several IPv4 addresses and prefixes. 958 Note that the value of "pid" for the prefix "ipv4:192.0.2.0/26" is 959 "pid1", even though all addresses in that block are in "pid2", 960 because "ipv4:192.0.2.0/25" is the longest prefix in the network map 961 which prefix-matches "ipv4:192.0.2.0/26", and that prefix is in 962 "pid1". 964 POST /propmap/lookup/pid HTTP/1.1 965 Host: alto.example.com 966 Accept: application/alto-propmap+json,application/alto-error+json 967 Content-Length: ### 968 Content-Type: application/alto-propmapparams+json 970 { 971 "entities" : [ 972 "ipv4:192.0.2.0", 973 "ipv4:192.0.2.16", 974 "ipv4:192.0.2.64", 975 "ipv4:192.0.2.128", 976 "ipv4:192.0.2.0/26", 977 "ipv4:192.0.2.0/30" ], 978 "properties" : [ "pid" ] 979 } 981 HTTP/1.1 200 OK 982 Content-Length: ### 983 Content-Type: application/alto-propmap+json 985 { 986 "meta" : { 987 "dependent-vtags" : [ 988 {"resource-id": "default-network-map", 989 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 990 ] 991 }, 992 "property-map": { 993 "ipv4:192.0.2.0": {"pid": "pid2"}, 994 "ipv4:192.0.2.16": {"pid": "pid2"}, 995 "ipv4:192.0.2.64": {"pid": "pid1"}, 996 "ipv4:192.0.2.128": {"pid": "defaultpid"}, 997 "ipv4:192.0.2.0/26": {"pid": "pid1"}, 998 "ipv4:192.0.2.0/30": {"pid": "pid2"} 999 } 1000 } 1002 7.8. Filtered Property Map Example #4 1004 The following example uses the Filtered Property Map resource to 1005 request the "availbw" property for several abstract network elements. 1007 POST /propmap/lookup/availbw HTTP/1.1 1008 Host: alto.example.com 1009 Accept: application/alto-propmap+json,application/alto-error+json 1010 Content-Length: ### 1011 Content-Type: application/alto-propmapparams+json 1013 { 1014 "entities" : [ 1015 "ane:L001", 1016 "ane:Lae0", 1017 "ane:L3eb ], 1018 "properties" : [ "availbw" ] 1019 } 1021 HTTP/1.1 200 OK 1022 Content-Length: ### 1023 Content-Type: application/alto-propmap+json 1025 { 1026 "property-map": { 1027 "ane:L001": {"availbw": "55"}, 1028 "ane:Lae0": {"availbw": "70"}, 1029 "ane:L3eb": {"availbw": "40"} 1030 } 1031 } 1033 8. Security Considerations 1035 As discussed in Section 15 of [RFC7285], properties MAY have 1036 sensitive customer-specific information. If this is the case, an 1037 ALTO Server MAY limit access to those properties by providing several 1038 different Property Maps. For non-sensitive properties, the ALTO 1039 Server would provide a URI which accepts requests from any client. 1040 Sensitive properties, on the other hand, would only be available via 1041 a secure URI which would require client authentication. 1043 Also, while technically this document does not introduce any security 1044 risks not inherent in the Endpoint Property Service defined by 1045 [RFC7285], the GET-mode property map resource defined in this 1046 document does make it easier for a client to download large numbers 1047 of property values. Accordingly, an ALTO Server SHOULD limit GET- 1048 mode Property Maps to properties which do not contain sensitive data. 1050 9. IANA Considerations 1052 This document defines additional application/alto-* media types, and 1053 extends the ALTO endpoint property registry. 1055 9.1. application/alto-* Media Types 1057 This document registers two additional ALTO media types, listed in 1058 Table 1. 1060 +--------------+--------------------------+-----------------------+ 1061 | Type | Subtype | Specification | 1062 +--------------+--------------------------+-----------------------+ 1063 | application | alto-propmap+json | Section 4.1 | 1064 | application | alto-propmapparams+json | Section 5.3 | 1065 +--------------+--------------------------+-----------------------+ 1067 Table 1: Additional ALTO Media Types. 1069 Type name: application 1071 Subtype name: This document registers multiple subtypes, as listed 1072 in Table 1. 1074 Required parameters: n/a 1076 Optional parameters: n/a 1078 Encoding considerations: Encoding considerations are identical to 1079 those specified for the "application/json" media type. See 1080 [RFC7159]. 1082 Security considerations: Security considerations related to the 1083 generation and consumption of ALTO Protocol messages are discussed 1084 in Section 15 of [RFC7285]. 1086 Interoperability considerations: This document specifies formats of 1087 conforming messages and the interpretation thereof. 1089 Published specification: This document is the specification for 1090 these media types; see Table 1 for the section documenting each 1091 media type. 1093 Applications that use this media type: ALTO servers and ALTO clients 1094 either stand alone or are embedded within other applications. 1096 Additional information: ~ Magic number(s): ~ n/a File extension(s): ~ 1097 This document uses the mime type to refer to protocol messages and 1098 thus does not require a file extension. Macintosh file type code(s): 1099 ~ n/a 1101 Person & email address to contact for further information: See 1102 Authors' Addresses section. 1104 Intended usage: COMMON 1106 Restrictions on usage: n/a 1108 Author: See Authors' Addresses section. 1110 Change controller: Internet Engineering Task Force 1111 (mailto:iesg@ietf.org). 1113 9.2. ALTO Entity Domain Registry 1115 This document requests IANA to create and maintain the "ALTO Entity 1116 Domain Registry", listed in Table 2. 1118 +------------+-----------------------------+------------------------+ 1119 | Identifier | Entity Address Encoding | Hierarchy & | 1120 | | | Inheritance | 1121 +------------+-----------------------------+------------------------+ 1122 | ipv4 ipv6 | See Section 3.1.1 See | See Section 3.1.3 See | 1123 | pid ane | Section 3.1.2 See Section | Section 3.1.3 None | 1124 | | 3.2 See Section 3.4 | None | 1125 +------------+-----------------------------+------------------------+ 1127 Table 2: ALTO Entity Domain Names. 1129 This registry serves two purposes. First, it ensures uniqueness of 1130 identifiers referring to ALTO entity domains. Second, it states the 1131 requirements for allocated domain names. 1133 New ALTO entity domains are assigned after IETF Review [RFC5226] to 1134 ensure that proper documentation regarding the new ALTO entity 1135 domains and their security considerations has been provided. RFCs 1136 defining new entity domains SHOULD indicate how an entity in a 1137 registered domain is encoded as an EntityName, and, if applicable, 1138 the rules defining the entity hierarchy and property inheritance. 1139 Updates and deletions of ALTO entity domains follow the same 1140 procedure. 1142 Registered ALTO entity domain identifiers MUST conform to the 1143 syntactical requirements specified in Section 2.4. Identifiers are 1144 to be recorded and displayed as strings. 1146 Requests to add a new value to the registry MUST include the 1147 following information: 1149 o Identifier: The name of the desired ALTO entity domain. 1151 o Entity Address Encoding: The procedure for encoding the address of 1152 an entity of the registered type as an EntityAddr (see 1153 Section 2.3). 1155 o Hierarchy: If the entities form a hierarchy, the procedure for 1156 determining that hierarchy. 1158 o Inheritance: If entities can inherit property values from other 1159 entities, the procedure for determining that inheritance. 1161 o Security Considerations: In some usage scenarios, entity addresses 1162 carried in ALTO Protocol messages MAY reveal information about an 1163 ALTO client or an ALTO service provider. Applications and ALTO 1164 service providers using addresses of the registered type SHOULD be 1165 made aware of how (or if) the addressing scheme relates to private 1166 information and network proximity. 1168 This specification requests registration of the identifiers "ipv4", 1169 "ipv6" and "pid", as shown in Table 2. 1171 9.3. ALTO Endpoint Property Type Registry 1173 The ALTO Endpoint Property Type Registry was created by [RFC7285]. 1174 If possible, the name of that registry SHOULD be changed to "ALTO 1175 Entity Property Type Registry", to indicate that it is not restricted 1176 to Endpoint Properties. If it is not feasible to change the name, 1177 the description MUST be amended to indicate that it registers 1178 properties in all domains, rather than just the Internet address 1179 domain. 1181 10. References 1183 [I-D.ietf-alto-path-vector] 1184 Bernstein, G., Chen, S., Gao, K., Lee, Y., Roome, W., 1185 Scharf, M., Yang, Y., and J. Zhang, "ALTO Extension: Path 1186 Vector Cost Mode", draft-ietf-alto-path-vector-00 (work in 1187 progress), May 2017. 1189 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1190 Requirement Levels", BCP 14, RFC 2119, 1191 DOI 10.17487/RFC2119, March 1997, 1192 . 1194 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1195 Resource Identifier (URI): Generic Syntax", STD 66, 1196 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1197 . 1199 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1200 (CIDR): The Internet Address Assignment and Aggregation 1201 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1202 2006, . 1204 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1205 IANA Considerations Section in RFCs", RFC 5226, 1206 DOI 10.17487/RFC5226, May 2008, 1207 . 1209 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1210 Address Text Representation", RFC 5952, 1211 DOI 10.17487/RFC5952, August 2010, 1212 . 1214 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1215 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1216 2014, . 1218 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1219 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1220 "Application-Layer Traffic Optimization (ALTO) Protocol", 1221 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1222 . 1224 Authors' Addresses 1226 Wendy Roome 1227 Nokia Bell Labs 1228 600 Mountain Ave, Rm 3B-324 1229 Murray Hill, NJ 07974 1230 USA 1232 Phone: +1-908-582-7974 1233 Email: wendy@roome.com 1234 Y. Yang 1235 Yale University 1236 51 Prospect Street 1237 New Haven, CT 06511 1238 USA 1240 Phone: +1-203-432-6400 1241 Email: yry@cs.yale.edu