idnits 2.17.1 draft-ietf-alto-unified-props-new-03.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 583 has weird spacing: '...rtyName prop...' == Line 714 has weird spacing: '...country stat...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: o An entity MAY or MAY NOT be an endpoint. For example, "pid" is registered as an entity domain in Table 2, but it is not an endpoint address type. -- The document date (March 5, 2018) is 2215 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) Summary: 4 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). 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: September 6, 2018 Tongji University 6 S. Randriamasy 7 Nokia Bell Labs 8 Y. Yang 9 Yale University 10 J. Zhang 11 Tongji University 12 March 5, 2018 14 Unified Properties for the ALTO Protocol 15 draft-ietf-alto-unified-props-new-03 17 Abstract 19 This document extends the Application-Layer Traffic Optimization 20 (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint 21 properties" to other entity domains, 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 http://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 September 6, 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 (http://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. Domain . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 2.3. Domain Name . . . . . . . . . . . . . . . . . . . . . . . 4 69 2.4. Entity Address . . . . . . . . . . . . . . . . . . . . . 5 70 2.5. Property Name . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 4.6. Response . . . . . . . . . . . . . . . . . . . . . . . . 12 92 5. Filtered Property Map Resource . . . . . . . . . . . . . . . 12 93 5.1. Media Type . . . . . . . . . . . . . . . . . . . . . . . 13 94 5.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . . . 13 95 5.3. Accept Input Parameters . . . . . . . . . . . . . . . . . 13 96 5.4. Capabilities . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . . . . . . . . 14 101 6.2. Impact on Resource-Specific Properties . . . . . . . . . 14 102 6.3. Impact on the "pid" Property . . . . . . . . . . . . . . 15 103 6.4. Impact on Other Properties . . . . . . . . . . . . . . . 15 104 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 15 105 7.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . 18 110 7.6. Filtered Property Map Example #2 . . . . . . . . . . . . 19 111 7.7. Filtered Property Map Example #3 . . . . . . . . . . . . 20 112 7.8. Filtered Property Map Example #4 . . . . . . . . . . . . 21 113 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 114 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 115 9.1. application/alto-* Media Types . . . . . . . . . . . . . 23 116 9.2. ALTO Entity Domain Registry . . . . . . . . . . . . . . . 24 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 [RFC4632] 131 or PIDs, may also have properties. The EPS cannot be extended to new 132 entity domains. Instead, new services, with new request and response 133 messages, would have to be defined for each new entity domain. 135 Second, the EPS is only defined as a POST-mode service. Clients must 136 request the properties for an explicit set of addresses. By 137 contrast, [RFC7285] defines a GET-mode Cost Map resource which 138 returns all available costs, so a client can get a full set of costs 139 once, and then processes costs lookup without querying the ALTO 140 server. [RFC7285] does not define an equivalent service for endpoint 141 properties. At first a map might seem impractical, because it could 142 require enumerating the property value for every possible endpoint. 144 But in practice, it is highly unlikely that properties will be 145 defined for every address. It is much more likely that properties 146 will only be defined for a subset of addresses, and that subset would 147 be small enough to enumerate. This is particularly true if blocks of 148 addresses with a common prefix (e.g., a CIDR) have the same value for 149 a property. Furthermore, entities in other domains may very well be 150 enumerable. 152 This document proposes a new approach to retrieve ALTO properties. 153 Specifically, it defines two new resource types, namely Property Maps 154 (see Section 4) and Filtered Property Maps (see Section 5). The 155 former are GET-mode resources which return the property values for 156 all entities in a domain, and are analogous to the ALTO's Network 157 Maps and Cost Maps. The latter are POST-mode resources which return 158 the values for a set of properties and entities requested by the 159 client, and are analogous to the ALTO's Filtered Network Maps and 160 Filtered Cost Maps. 162 Entity domains and property names are extensible. New domains can be 163 defined without revising the messages defined in this document, in 164 the same way that new cost metrics and new endpoint properties can be 165 defined without revising the messages defined by 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. 185 2.3. Domain Name 187 Each domain has a unique name. A domain name MUST be no more than 32 188 characters, and MUST NOT contain characters other than US-ASCII 189 alphanumeric characters (U+0030-U+0039, U+0041-U+005A, and 190 U+0061-U+007A), hyphen ('-', U+002D), and low line ('_', U+005F). 192 For example, the names "ipv4" and "ipv6" identify objects in the 193 Internet address domain (see Section 3.1). 195 The type DomainName is used in this document to denote a JSON string 196 with a domain name in this format. 198 Domain names MUST be registered with the IANA, and the format of the 199 entity addresses in that domain, as well as any hierarchical or 200 inheritance rules for those entities, MUST be specified at the same 201 time. 203 2.4. Entity Address 205 Each entity has a unique address of the format: 207 domain-name : domain-specific-entity-address 209 Examples from the IP domain include individual addresses such as 210 "ipv4:192.0.2.14" and "ipv6:2001:db8::12", as well as address blocks 211 such as "ipv4:192.0.2.0/26" and "ipv6:2001:db8::1/48". 213 The type EntityAddr is used in this document to denote a JSON string 214 with an entity address in this format. 216 The format of the second part of an entity address depends on the 217 domain, and MUST be specified when registering a new domain. 218 Addresses MAY be hierarchical, and properties MAY be inherited based 219 on that hierarchy. Again, the rules defining any hierarchy or 220 inheritance MUST be defined when the domain is registered. 222 Note that an entity address MAY have different textual 223 representations, for a given domain. For example, the strings 224 "ipv6:2001:db8::1" and "ipv6:2001:db8:0:0:0:0:0:1" refer to the same 225 entity. 227 2.5. Property Name 229 The space of property names associated with entities defined by this 230 document is the same as, and is shared with, the endpoint property 231 names defined by [RFC7285]. Thus entity property names are as 232 defined in Section 10.8.2 of that document, and must be registered 233 with the "ALTO Endpoint Property Type Registry" defined in 234 Section 9.3 of that document. The type PropertyName denotes a JSON 235 string with a property name in this format. 237 This document defines uniform property names specified in a single 238 property name space rather than being scoped by a specific domain, 239 although some properties may only be applicable for particular 240 domains. This design decision is to enforce a design so that similar 241 properties are named similarly. The interpretation of the value of a 242 property, however, may depend on the domain. For example, suppose 243 the "geo-location" property is defined as the coordinates of a point, 244 encoded as (say) "latitude longitude [altitude]." When applied to an 245 entity that represents a specific host computer, such as an Internet 246 address, the property defines the host's location. When applied to 247 an entity that represents a set of computers, such as a CIDR, the 248 property would be the location of the center of that set. If it is 249 necessary to represent the bounding box of a set of hosts, another 250 property, such as "geo-region", should be defined. 252 2.6. Hierarchy and Inheritance 254 Entities in a given domain MAY form hierarchy based on entity 255 address. Each domain MUST define its own hierarchy and inheritance 256 rules when registered. The hierarchy and inheritance rule makes it 257 possible for an entity to inherit a property value from another 258 entity in the same domain. If and only if the property of an entity 259 is undefined, the hierarchy and inheritance rules are applied. 261 2.7. Relationship with Other ALTO Resources 263 [RFC7285] recognizes that some properties MAY be specific to another 264 ALTO resource, such as a network map. Accordingly [RFC7285] defines 265 the concept of "resource-specific endpoint properties" (see 266 Section 10.8.1), and indicates that dependency by prefixing the 267 property name with the ID of the resource on which it depends. That 268 document defines one resource-specific property, namely the "pid" 269 property, whose value is the name of the PID containing that endpoint 270 in the associated network map. 272 This document takes a different approach. Instead of defining the 273 dependency by qualifying the property name, this document attaches 274 the dependency to the domains. Thus all properties of a specific 275 domain depend on the same resource, the properties of another domain 276 may depend on another resource. For example, entities in the PID 277 domain depend on a network map. 279 The "uses" field in an IRD entry defines the dependencies of a 280 property map resource, and the "dependent-vtags" field in a property 281 map response defines the dependencies of that map. These fields are 282 defined in Sections 9.1.5 and 11.1 of [RFC7285], respectively. 284 The "uses" field in an IRD entry MUST NOT include two dependent 285 resources with the same media type. This is similar to how [RFC7285] 286 handles dependencies between cost maps and network maps. Recall that 287 cost maps present the costs between PIDs, and PID names depend on a 288 network map. If an ALTO server provides the "routingcost" metric for 289 the network maps "net1" and "net2", then the server defines two 290 separate cost maps, one for "net1" and the other for "net2". 292 According to [RFC7285], a legacy ALTO server with two network maps, 293 with resource IDs "net1" and "net2", could offer a single Endpoint 294 Property Service for the two properties "net1.pid" and "net2.pid". 295 An ALTO server which supports the extensions defined in this 296 document, would, instead, offer two different Property Maps for the 297 "pid" property, one depending on "net1", the other on "net2". 299 3. Entity Domains 301 This document defines the following entity domains. For the 302 definition of each domain, it includes the following template: domain 303 name, domain-specific addresses, and hierarchy and inheritance 304 semantics. 306 3.1. Internet Address Domains 308 The document defines two domains (IPv4 and IPv6) for Internet 309 addresses. Both domains include individual addresses and blocks of 310 addresses. 312 3.1.1. IPv4 Domain 314 3.1.1.1. Domain Name 316 ipv4 318 3.1.1.2. Domain-Specific Entity Addresses 320 Individual addresses are strings as specified by the IPv4Addresses 321 rule of Section 3.2.2 of [RFC3986]. Blocks of addresses are prefix- 322 match strings as specified in Section 3.1 of [RFC4632]. For the 323 purpose of defining properties, an individual Internet address and 324 the corresponding full-length prefix are considered aliases for the 325 same entity. Thus "ipv4:192.0.2.0" and "ipv4:192.0.2.0/32" are 326 equivalent. 328 3.1.2. IPv6 Domain 330 3.1.2.1. Domain Name 332 ipv6 334 3.1.2.2. Domain-Specific Entity Addresses 336 Individual addresses are strings as specified by Section 4 of 337 [RFC5952]. Blocks of addresses are prefix-match strings as specified 338 in Section 7 of [RFC5952]. For the purpose of defining properties, 339 an individual Internet address and the corresponding 128-bit prefix 340 are considered aliases for the same entity. That is, 341 "ipv6:2001:db8::1" and "ipv6:2001:db8::1/128" are equivalent, and 342 have the same set of properties. 344 3.1.3. Hierarchy and Inheritance of ipv4/ipv6 Domains 346 Both domains allow property values to be inherited. Specifically, if 347 a property P is not defined for a specific Internet address I, but P 348 is defined for some block C which prefix-matches I, then the address 349 I inherits the value of P defined for block C. If more than one such 350 block defines a value for P, I inherits the value of P in the block 351 with the longest prefix. It is important to notice that this longest 352 prefix rule will ensure no multiple inheritance, and hence no 353 ambiguity. 355 Address blocks can also inherit properties: if property P is not 356 defined for a block C, but is defined for some block C' which prefix- 357 matches C, and C' has a shorter mask than C, then block C inherits 358 the property from C'. If there are several such blocks C', C 359 inherits from the block with the longest prefix. 361 As an example, suppose that a server defines the property P for the 362 following entities: 364 ipv4:192.0.2.0/26: P=v1 365 ipv4:192.0.2.0/28: P=v2 366 ipv4:192.0.2.0/30: P=v3 367 ipv4:192.0.2.0: P=v4 369 Figure 1: Defined Property Values. 371 Then the following entities have the indicated values: 373 ipv4:192.0.2.0: P=v4 374 ipv4:192.0.2.1: P=v3 375 ipv4:192.0.2.16: P=v1 376 ipv4:192.0.2.32: P=v1 377 ipv4:192.0.2.64: (not defined) 378 ipv4:192.0.2.0/32: P=v4 379 ipv4:192.0.2.0/31: P=v3 380 ipv4:192.0.2.0/29: P=v2 381 ipv4:192.0.2.0/27: P=v1 382 ipv4:192.0.2.0/25: (not defined) 384 Figure 2: Inherited Property Values. 386 An ALTO Server MAY explicitly indicate a property as not having a 387 value for a particular entity. That is, a server MAY say that 388 property A of entity X is "defined to have no value", instead of 389 "undefined". To indicate "no value", a server MAY perform different 390 behaviours: 392 o If that entity would inherit a value for that property, then the 393 ALTO server MUST return a "null" value for that property. In this 394 case, the ALTO client MUST recognize a "null" value as "no value" 395 and "do not apply the inheritance rules for this property." 397 o If the entity would not inherit a value, then the ALTO server MAY 398 return "null" or just omit the property. In this case, the ALTO 399 client cannot infer the value for this property of this entity 400 from the Inheritance rules. So the client MUST interpret this 401 property has "no value". 403 If the ALTO Server does not define any properties for an entity, then 404 the server MAY omit that entity from the response. 406 3.1.4. Relationship to Network Maps 408 An Internet address domain MAY be associated with an ALTO network map 409 resource. Logically, there is a map of Internet address entities to 410 property values for each network map defined by the ALTO server, plus 411 an additional property map for Internet address entities which are 412 not associated with a network map. So, if there are n network maps, 413 the server can provide n+1 maps of Internet address entities to 414 property values. These maps are separate from each other. The 415 prefixes in the property map do not have to correspond to the 416 prefixes defining the network map's PIDs. For example, the property 417 map for a network map MAY assign properties to "ipv4:192.0.2.0/24" 418 even if that prefix is not associated with any PID in the network 419 map. 421 3.2. PID Domain 423 The PID domain associates property values with the PIDs in a network 424 map. Accordingly, this domain always depends on a network map. 426 3.2.1. Domain Name 428 pid 430 3.2.2. Domain-Specific Entity Addresses 432 The entity addresses are the PID names of the associated network map. 434 3.2.3. Hierarchy and Inheritance 436 There is no hierarchy or inheritance for properties associated with 437 PIDs. 439 3.2.4. Relationship To Internet Addresses Domains 441 The PID domain and the Internet address domains are completely 442 independent; the properties associated with a PID have no relation to 443 the properties associated with the prefixes or endpoint addresses in 444 that PID. An ALTO server MAY choose to assign some or all properties 445 of a PID to the prefixes in that PID. 447 For example, suppose "PID1" consists of the prefix 448 "ipv4:192.0.2.0/24", and has the property "P" with value "v1". The 449 Internet address entities "ipv4:192.0.2.0" and "ipv4:192.0.2.0/24", 450 in the IPv4 domain MAY have a value for the property "P", and if they 451 do, it is not necessarily "v1". 453 3.3. Internet Address Properties vs. PID Properties 455 Because the Internet address and PID domains are completely separate, 456 the question may arise as to which domain is best for a property. In 457 general, the Internet address domain is RECOMMENDED for properties 458 that are closely related to the Internet address, or are associated 459 with, and inherited through, blocks of addresses. 461 The PID domain is RECOMMENDED for properties that arise from the 462 definition of the PID, rather than from the Internet address prefixes 463 in that PID. 465 For example, because Internet addresses are allocated to service 466 providers by blocks of prefixes, an "ISP" property would be best 467 associated with the Internet address domain. On the other hand, a 468 property that explains why a PID was formed, or how it relates a 469 provider's network, would best be associated with the PID domain. 471 4. Property Map Resource 473 A Property Map returns the properties defined for all entities in one 474 or more domains. 476 Section 7.4 gives an example of a property map request and its 477 response. 479 4.1. Media Type 481 The media type of an ALTO Property Map resource is "application/alto- 482 propmap+json". 484 4.2. HTTP Method 486 An ALTO Property Map resource is requested using the HTTP GET method. 488 4.3. Accept Input Parameters 490 None. 492 4.4. Capabilities 494 The capabilities are defined by an object of type 495 PropertyMapCapabilities: 497 object { 498 DomainName domain-types<1..*>; 499 PropertyName prop-types<1..*>; 500 } PropertyMapCapabilities; 502 where "domain-types" is an array with the domains of the entities in 503 this property map, and "prop-types" is an array with the names of the 504 properties returned for entities in those domains. 506 4.5. Uses 508 An array with the resource ID(s) of resource(s) with which the 509 domains in this map are associated. In most cases, this array will 510 have at most one ID, for example, for a network map resource. 511 However, the "uses" field MUST NOT contain two resources of the same 512 resource type. For example, if a property map depends on network map 513 resource, the "uses" field MUST include exactly one network map 514 resource. 516 4.6. Response 518 If the domains in this property map depend on other resources, the 519 "dependent-vtags" field in the "meta" field of the response MUST be 520 an array that includes the version tags of those resources. The data 521 component of a Property Map response is named "property-map", which 522 is a JSON object of type PropertyMapData, where: 524 object { 525 PropertyMapData property-map; 526 } InfoResourceProperties : ResponseEntityBase; 528 object-map { 529 EntityAddr -> EntityProps; 530 } PropertyMapData; 532 object { 533 PropertyName -> JSONValue; 534 } EntityProps; 536 The ResponseEntityBase type is defined in Section 8.4 of [RFC7285]. 538 Specifically, a PropertyMapData object has one member for each entity 539 in the Property Map. The entity's properties are encoded in the 540 corresponding EntityProps object. EntityProps encodes one name/value 541 pair for each property, where the property names are encoded as 542 strings of type PropertyName. A protocol implementation SHOULD 543 assume that the property value is either a JSONString or a JSON 544 "null" value, and fail to parse if it is not, unless the 545 implementation is using an extension to this document that indicates 546 when and how property values of other data types are signaled. 548 For each entity in the Property Map, the ALTO Server returns the 549 value defined for each of the properties specified in this resource's 550 "capabilities" list. For efficiency, the ALTO Server SHOULD omit 551 property values that are inherited rather than explicitly defined; if 552 a client needs inherited values, the client SHOULD use the domain's 553 inheritance rules to deduce those values. 555 5. Filtered Property Map Resource 557 A Filtered Property Map returns the values of a set of properties for 558 a set of entities selected by the client. 560 Section 7.5, Section 7.6 and Section 7.7 give examples of filtered 561 property map requests and responses. 563 5.1. Media Type 565 The media type of an ALTO Property Map resource is "application/alto- 566 propmap+json". 568 5.2. HTTP Method 570 An ALTO Filtered Property Map resource is requested using the HTTP 571 POST method. 573 5.3. Accept Input Parameters 575 The input parameters for a Filtered Property Map request are supplied 576 in the entity body of the POST request. This document specifies the 577 input parameters with a data format indicated by the media type 578 "application/alto-propmapparams+json", which is a JSON object of type 579 ReqFilteredPropertyMap: 581 object { 582 EntityAddr entities<1..*>; 583 PropertyName properties<1..*>; 584 } ReqFilteredPropertyMap; 586 with fields: 588 entities: List of entity addresses for which the specified 589 properties are to be returned. The ALTO server MUST interpret 590 entries appearing multiple times as if they appeared only once. 591 The domain of each entity MUST be included in the list of domains 592 in this resource's "capabilities" field (see Section 5.4). 594 properties: List of properties to be returned for each entity. Each 595 specified property MUST be included in the list of properties in 596 this resource's "capabilities" field (see Section 5.4). The ALTO 597 server MUST interpret entries appearing multiple times as if they 598 appeared only once. 600 Note that the "entities" and "properties" fields MUST have at 601 least one entry each. 603 5.4. Capabilities 605 The capabilities are defined by an object of type 606 PropertyMapCapabilities, as defined in Section 4.4. 608 5.5. Uses 610 An array with the resource ID(s) of resource(s) with which the 611 domains in this map are associated. In most cases, this array will 612 have at most one ID, and it will be for a network map resource. 614 5.6. Response 616 The response is the same as for the property map (see Section 4.6), 617 except that it only includes the entities and properties requested by 618 the client. 620 Also, the Filtered Property Map response MUST include all inherited 621 property values for the specified entities (unlike the Full Property 622 Map, the Filtered Property Map response does not include enough 623 information for the client to calculate the inherited values). 625 If the ALTO server does not define a requested property's value for a 626 particular entity, then it MUST omit that property from the response 627 for only that endpoint. 629 If the ALTO server does not support a requested entity's domain, then 630 it MUST return an E_INVALID_FIELD_VALUE error defined in 631 Section 8.5.2 of [RFC7285]. 633 6. Impact on Legacy ALTO Servers and ALTO Clients 635 6.1. Impact on Endpoint Property Service 637 The Property Maps defined in this document provide the same 638 functionality as the Endpoint Property Service (EPS) defined in 639 Section 11.4 of [RFC7285]. Accordingly, it is RECOMMENDED that the 640 EPS be deprecated in favor of Property Maps. However, ALTO servers 641 MAY provide an EPS for the benefit of legacy clients. 643 6.2. Impact on Resource-Specific Properties 645 Section 10.8 of [RFC7285] defines two categories of endpoint 646 properties: "resource-specific" and "global". Resource-specific 647 property names are prefixed with the ID of the resource they depend 648 upon, while global property names have no such prefix. The property 649 map resources defined in this document do not distinguish between 650 those two types of properties. Instead, if there is a dependency, it 651 is indicated by the "uses" capability of a property map, and is 652 shared by all properties and entity domains in that map. 653 Accordingly, it is RECOMMENDED that resource-specific endpoint 654 properties be deprecated, and no new resource-specific endpoint 655 properties be defined. 657 6.3. Impact on the "pid" Property 659 Section 7.1.1 of [RFC7285] defines the resource-specific endpoint 660 property "pid", whose value is the name of the PID containing that 661 endpoint. For compatibility with legacy clients, an ALTO server 662 which provides the "pid" property via the Endpoint Property Service 663 MUST use that definition, and that syntax, in the EPS resource. 665 However, when used with Property Maps, this document amends the 666 definition of the "pid" property as follows. 668 First, the name of the property is simply "pid"; the name is not 669 prefixed with the resource ID of a network map. The "uses" 670 capability of the property map resource indicates the associated 671 network map. This implies that a property map can only return the 672 "pid" property for one network map; if an ALTO server provides 673 several network maps, it MUST provide a property map resource for 674 each one. 676 Second, a client MAY request the "pid" property for a block of 677 addresses. An ALTO server determines the value of "pid" for an 678 address block C as follows. Let CS be the set of all address blocks 679 in the network map. If C is in CS, then the value of "pid" is the 680 name of the PID associated with C. Otherwise, find the longest block 681 C' in CS such that C' prefix-matches C, but is shorter than C. If 682 there is such a block C', the value of "pid" is the name of the PID 683 associated with C'. If not, then "pid" has no value for block C. 685 Note that although an ALTO server MAY provide a GET-mode property map 686 resource which returns the entire map for the "pid" property, there 687 is no need to do so, because that map is simply the inverse of the 688 network map. 690 6.4. Impact on Other Properties 692 In general, there should be little or no impact on other previously 693 defined properties. The only consideration is that properties can 694 now be defined on blocks of addresses, rather than just individual 695 addresses, which might change the semantics of a property. 697 7. Examples 699 7.1. Network Map 701 The examples in this section use a very simple default network map: 703 defaultpid: ipv4:0.0.0.0/0 ipv6:::0/0 704 pid1: ipv4:192.0.2.0/25 705 pid2: ipv4:192.0.2.0/28 ipv4:192.0.2.16/28 707 Figure 3: Example Network Map 709 7.2. Property Definitions 711 The examples in this section use four additional properties, "ISP", 712 "ASN", "country" and "state", with the following values: 714 ISP ASN country state 715 ipv4:192.0.2.0/24: BitsRus - us - 716 ipv4:192.0.2.0/28: - 12345 - NJ 717 ipv4:192.0.2.16/28: - 12345 - CT 718 ipv4:192.0.2.0: - - - PA 720 Figure 4: Example Property Values 722 7.3. Information Resource Directory (IRD) 724 The following IRD defines the relevant resources of the ALTO server. 725 It provides two Property Map resources, one for the "ISP" and "ASN" 726 properties, and another for the "country" and "state" properties. 727 The server could have provided a Property Map resource for all four 728 properties, but did not, presumably because the organization that 729 runs the ALTO server believes any given client is not interested in 730 all four properties. 732 The server provides two Filtered Property Maps. The first returns 733 all four properties, and the second just returns the "pid" property 734 for the default network map. 736 The Filtered Property Maps for the "ISP", "ASN", "country" and 737 "state" properties do not depend on the default network map (it does 738 not have a "uses" capability), because the definitions of those 739 properties do not depend on the default network map. The Filtered 740 Property Map for the "pid" property does have a "uses" capability for 741 the default network map, because that defines the values of the "pid" 742 property. 744 Note that for legacy clients, the ALTO server provides an Endpoint 745 Property Service for the "pid" property for the default network map. 747 "meta": { ... }, 748 "resources" : { 749 "default-network-map" : { 750 "uri" : "http://alto.example.com/networkmap", 751 "media-type" : "application/alto-networkmap+json" 752 }, 753 .... property map resources .... 754 "country-state-property-map" : { 755 "uri" : "http://alto.example.com/propmap/full/inet-cs", 756 "media-type" : "application/alto-propmap+json", 757 "capabilities" : { 758 "domain-types": [ "ipv4", "ipv6" ], 759 "prop-types" : [ "country", "state" ] 760 } 761 }, 762 "isp-asn-property-map" : { 763 "uri" : "http://alto.example.com/propmap/full/inet-ia", 764 "media-type" : "application/alto-propmap+json", 765 "capabilities" : { 766 "domain-types": [ "ipv4", "ipv6" ], 767 "prop-types" : [ "ISP", "ASN" ] 768 } 769 }, 770 "iacs-property-map" : { 771 "uri" : "http://alto.example.com/propmap/lookup/inet-iacs", 772 "media-type" : "application/alto-propmap+json", 773 "accepts" : "application/alto-propmapparams+json", 774 "capabilities" : { 775 "domain-types": [ "ipv4", "ipv6" ], 776 "prop-types" : [ "ISP", "ASN", "country", "state" ] 777 } 778 }, 779 "pid-property-map" : { 780 "uri" : "http://alto.example.com/propmap/lookup/pid", 781 "media-type" : "application/alto-propmap+json", 782 "accepts" : "application/alto-propmapparams+json", 783 "uses" : [ "default-network-map" ] 784 "capabilities" : { 785 "domain-types" : [ "ipv4", "ipv6" ], 786 "prop-types" : [ "pid" ] 787 } 788 }, 789 "availbw-property-map" : { 790 "uri" : "http://alto.example.com/propmap/lookup/availbw", 791 "media-type" : "application/alto-propmap+json", 792 "accepts" : "application/alto-propmapparams+json", 793 "capabilities" : { 794 "domain-types" : [ "ane" ], 795 "prop-types" : [ "availbw", "delay" ] 796 } 797 }, 798 "legacy-pid-property-map" : { 799 "uri" : "http://alto.example.com/legacy/eps-pid", 800 "media-type" : "application/alto-endpointprop+json", 801 "accepts" : "application/alto-endpointpropparams+json", 802 "capabilities" : { 803 "prop-types" : [ "default-network-map.pid" ] 804 } 805 } 806 } 808 Figure 5: Example IRD 810 7.4. Property Map Example 812 The following example uses the properties and IRD defined above to 813 retrieve a property map for entities with the "ISP" and "ASN" 814 properties. Note that the response does not include the entity 815 "ipv4:192.0.2.0", because it does not have a value for either of 816 those properties. Also note that the entities "ipv4:192.0.2.0/28" 817 and "ipv4:192.0.2.16/28" are refinements of "ipv4:192.0.2.0/24", and 818 hence inherit its value for "ISP" property. But because that value 819 is inherited, it is not explicitly listed in the property map. 821 GET /propmap/full/inet-ia HTTP/1.1 822 Host: alto.example.com 823 Accept: application/alto-propmap+json,application/alto-error+json 825 HTTP/1.1 200 OK 826 Content-Length: ### 827 Content-Type: application/alto-propmap+json 829 { 830 "property-map": { 831 "ipv4:192.0.2.0/24": {"ISP": "BitsRus"}, 832 "ipv4:192.0.2.0/28": {"ASN": "12345"}, 833 "ipv4:192.0.2.16/28": {"ASN": "12345"} 834 } 835 } 837 7.5. Filtered Property Map Example #1 839 The following example uses the Filtered Property Map resource to 840 request the "ISP", "ASN" and "state" properties for several IPv4 841 addresses. Note that the value of "state" for "ipv4:192.0.2.0" is 842 the only explicitly defined property; the other values are all 843 derived by the inheritance rules for Internet address entities. 845 POST /propmap/lookup/inet-iacs HTTP/1.1 846 Host: alto.example.com 847 Accept: application/alto-propmap+json,application/alto-error+json 848 Content-Length: ### 849 Content-Type: application/alto-propmapparams+json 851 { 852 "entities" : [ "ipv4:192.0.2.0", 853 "ipv4:192.0.2.1", 854 "ipv4:192.0.2.17" ], 855 "properties" : [ "ISP", "ASN", "state" ] 856 } 858 HTTP/1.1 200 OK 859 Content-Length: ### 860 Content-Type: application/alto-propmap+json 862 { 863 "property-map": { 864 "ipv4:192.0.2.0": 865 {"ISP": "BitsRus", "ASN": "12345", "state": "PA"}, 866 "ipv4:192.0.2.1": 867 {"ISP": "BitsRus", "ASN": "12345", "state": "NJ"}, 868 "ipv4:192.0.2.17": 869 {"ISP": "BitsRus", "ASN": "12345", "state": "CT"} 870 } 871 } 873 7.6. Filtered Property Map Example #2 875 The following example uses the Filtered Property Map resource to 876 request the "ASN", "country" and "state" properties for several IPv4 877 prefixes. Note that none of the returned property values is 878 explicitly defined; all values are derived by the inheritance rules 879 for Internet address entities. 881 Also note the "ASN" property has the value "12345" for both the 882 blocks "ipv4:192.0.2.0/28" and "ipv4:192.0.2.16/28", so every address 883 in the block "ipv4:192.0.2.0/27" has that property value. However 884 the block "ipv4:192.0.2.0/27" itself does not have a value for "ASN": 885 address blocks cannot inherit properties from blocks with longer 886 prefixes, even if every such block has the same value. 888 POST /propmap/lookup/inet-iacs HTTP/1.1 889 Host: alto.example.com 890 Accept: application/alto-propmap+json,application/alto-error+json 891 Content-Length: ### 892 Content-Type: application/alto-propmapparams+json 894 { 895 "entities" : [ "ipv4:192.0.2.0/26", 896 "ipv4:192.0.2.0/27", 897 "ipv4:192.0.2.0/28" ], 898 "properties" : [ "ASN", "country", "state" ] 899 } 901 HTTP/1.1 200 OK 902 Content-Length: ### 903 Content-Type: application/alto-propmap+json 905 { 906 "property-map": { 907 "ipv4:192.0.2.0/26": {"country": "us"}, 908 "ipv4:192.0.2.0/27": {"country": "us"}, 909 "ipv4:192.0.2.0/28": {"ASN": "12345", 910 "country": "us", 911 "state": "NJ"} 912 } 913 } 915 7.7. Filtered Property Map Example #3 917 The following example uses the Filtered Property Map resource to 918 request the "pid" property for several IPv4 addresses and prefixes. 920 Note that the value of "pid" for the prefix "ipv4:192.0.2.0/26" is 921 "pid1", even though all addresses in that block are in "pid2", 922 because "ipv4:192.0.2.0/25" is the longest prefix in the network map 923 which prefix-matches "ipv4:192.0.2.0/26", and that prefix is in 924 "pid1". 926 POST /propmap/lookup/pid 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" : [ 934 "ipv4:192.0.2.0", 935 "ipv4:192.0.2.16", 936 "ipv4:192.0.2.64", 937 "ipv4:192.0.2.128", 938 "ipv4:192.0.2.0/26", 939 "ipv4:192.0.2.0/30" ], 940 "properties" : [ "pid" ] 941 } 943 HTTP/1.1 200 OK 944 Content-Length: ### 945 Content-Type: application/alto-propmap+json 947 { 948 "meta" : { 949 "dependent-vtags" : [ 950 {"resource-id": "default-network-map", 951 "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"} 952 ] 953 }, 954 "property-map": { 955 "ipv4:192.0.2.0": {"pid": "pid2"}, 956 "ipv4:192.0.2.16": {"pid": "pid2"}, 957 "ipv4:192.0.2.64": {"pid": "pid1"}, 958 "ipv4:192.0.2.128": {"pid": "defaultpid"}, 959 "ipv4:192.0.2.0/26": {"pid": "pid1"}, 960 "ipv4:192.0.2.0/30": {"pid": "pid2"} 961 } 962 } 964 7.8. Filtered Property Map Example #4 966 The following example uses the Filtered Property Map resource to 967 request the "availbw" property for several abstract network elements. 969 POST /propmap/lookup/availbw HTTP/1.1 970 Host: alto.example.com 971 Accept: application/alto-propmap+json,application/alto-error+json 972 Content-Length: ### 973 Content-Type: application/alto-propmapparams+json 975 { 976 "entities" : [ 977 "ane:L001", 978 "ane:Lae0", 979 "ane:L3eb ], 980 "properties" : [ "availbw" ] 981 } 983 HTTP/1.1 200 OK 984 Content-Length: ### 985 Content-Type: application/alto-propmap+json 987 { 988 "property-map": { 989 "ane:L001": {"availbw": "55"}, 990 "ane:Lae0": {"availbw": "70"}, 991 "ane:L3eb": {"availbw": "40"} 992 } 993 } 995 8. Security Considerations 997 As discussed in Section 15 of [RFC7285], properties MAY have 998 sensitive customer-specific information. If this is the case, an 999 ALTO Server MAY limit access to those properties by providing several 1000 different Property Maps. For non-sensitive properties, the ALTO 1001 Server would provide a URI which accepts requests from any client. 1002 Sensitive properties, on the other hand, would only be available via 1003 a secure URI which would require client authentication. 1005 Also, while technically this document does not introduce any security 1006 risks not inherent in the Endpoint Property Service defined by 1007 [RFC7285], the GET-mode property map resource defined in this 1008 document does make it easier for a client to download large numbers 1009 of property values. Accordingly, an ALTO Server SHOULD limit GET- 1010 mode Property Maps to properties which do not contain sensitive data. 1012 9. IANA Considerations 1014 This document defines additional application/alto-* media types, and 1015 extends the ALTO endpoint property registry. 1017 9.1. application/alto-* Media Types 1019 This document registers two additional ALTO media types, listed in 1020 Table 1. 1022 +--------------+--------------------------+-----------------------+ 1023 | Type | Subtype | Specification | 1024 +--------------+--------------------------+-----------------------+ 1025 | application | alto-propmap+json | Section 4.1 | 1026 | application | alto-propmapparams+json | Section 5.3 | 1027 +--------------+--------------------------+-----------------------+ 1029 Table 1: Additional ALTO Media Types. 1031 Type name: application 1033 Subtype name: This document registers multiple subtypes, as listed 1034 in Table 1. 1036 Required parameters: n/a 1038 Optional parameters: n/a 1040 Encoding considerations: Encoding considerations are identical to 1041 those specified for the "application/json" media type. See 1042 [RFC7159]. 1044 Security considerations: Security considerations related to the 1045 generation and consumption of ALTO Protocol messages are discussed 1046 in Section 15 of [RFC7285]. 1048 Interoperability considerations: This document specifies formats of 1049 conforming messages and the interpretation thereof. 1051 Published specification: This document is the specification for 1052 these media types; see Table 1 for the section documenting each 1053 media type. 1055 Applications that use this media type: ALTO servers and ALTO clients 1056 either stand alone or are embedded within other applications. 1058 Additional information: ~ Magic number(s): ~ n/a File extension(s): ~ 1059 This document uses the mime type to refer to protocol messages and 1060 thus does not require a file extension. Macintosh file type code(s): 1061 ~ n/a 1063 Person & email address to contact for further information: See 1064 Authors' Addresses section. 1066 Intended usage: COMMON 1068 Restrictions on usage: n/a 1070 Author: See Authors' Addresses section. 1072 Change controller: Internet Engineering Task Force 1073 (mailto:iesg@ietf.org). 1075 9.2. ALTO Entity Domain Registry 1077 This document requests IANA to create and maintain the "ALTO Entity 1078 Domain Registry", listed in Table 2. 1080 +-------------+--------------------------+--------------------------+ 1081 | Identifier | Entity Address Encoding | Hierarchy & Inheritance | 1082 +-------------+--------------------------+--------------------------+ 1083 | ipv4 | See Section 3.1.1 | See Section 3.1.3 | 1084 | ipv6 | See Section 3.1.2 | See Section 3.1.3 | 1085 | pid | See Section 3.2 | None | 1086 +-------------+--------------------------+--------------------------+ 1088 Table 2: ALTO Entity Domain Names. 1090 This registry serves two purposes. First, it ensures uniqueness of 1091 identifiers referring to ALTO entity domains. Second, it states the 1092 requirements for allocated domain names. 1094 This registry is considered as an extension of the "ALTO Address Type 1095 Registry" defined in Section 14.4 of [RFC7285]. In particularly, 1097 o An entity MAY or MAY NOT be an endpoint. For example, "pid" is 1098 registered as an entity domain in Table 2, but it is not an 1099 endpoint address type. 1101 o An endpoint MUST be an entity. For example, "ipv4" and "ipv6" are 1102 already registered in "ALTO Address Type Registry" in [RFC7285], 1103 so they MUST be registered as entity domains. 1105 New ALTO entity domains are assigned after IETF Review [RFC5226] to 1106 ensure that proper documentation regarding the new ALTO entity 1107 domains and their security considerations has been provided. RFCs 1108 defining new entity domains SHOULD indicate how an entity in a 1109 registered domain is encoded as an EntityName, and, if applicable, 1110 the rules defining the entity hierarchy and property inheritance. 1111 Updates and deletions of ALTO entity domains follow the same 1112 procedure. 1114 Registered ALTO entity domain identifiers MUST conform to the 1115 syntactical requirements specified in Section 2.3. Identifiers are 1116 to be recorded and displayed as strings. 1118 When a new address type is registered in the ALTO Address Type 1119 Registry [RFC7285], the same identifier MUST be also registered in 1120 the ALTO Entity Domain Registry. And the Entity Address Encoding of 1121 this entity domain identifier MUST include both Address Encoding and 1122 Prefix Encoding of the same identifier registered in the ALTO Address 1123 Type Registry [RFC7285]. For the purpose of defining properties, an 1124 individual entity address and the corresponding full-length prefix 1125 MUST be considered aliases for the same entity. 1127 Requests to add a new value to the registry MUST include the 1128 following information: 1130 o Identifier: The name of the desired ALTO entity domain. 1132 o Entity Address Encoding: The procedure for encoding the address of 1133 an entity of the registered type as an EntityAddr (see 1134 Section 2.4). 1136 o Hierarchy: If the entities form a hierarchy, the procedure for 1137 determining that hierarchy. 1139 o Inheritance: If entities can inherit property values from other 1140 entities, the procedure for determining that inheritance. 1142 o Security Considerations: In some usage scenarios, entity addresses 1143 carried in ALTO Protocol messages MAY reveal information about an 1144 ALTO client or an ALTO service provider. Applications and ALTO 1145 service providers using addresses of the registered type SHOULD be 1146 made aware of how (or if) the addressing scheme relates to private 1147 information and network proximity. 1149 This specification requests registration of the identifiers "ipv4", 1150 "ipv6" and "pid", as shown in Table 2. 1152 9.3. ALTO Endpoint Property Type Registry 1154 The ALTO Endpoint Property Type Registry was created by [RFC7285]. 1155 If possible, the name of that registry SHOULD be changed to "ALTO 1156 Entity Property Type Registry", to indicate that it is not restricted 1157 to Endpoint Properties. If it is not feasible to change the name, 1158 the description MUST be amended to indicate that it registers 1159 properties in all domains, rather than just the Internet address 1160 domain. 1162 10. References 1164 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1165 Requirement Levels", BCP 14, RFC 2119, 1166 DOI 10.17487/RFC2119, March 1997, . 1169 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1170 Resource Identifier (URI): Generic Syntax", STD 66, 1171 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1172 . 1174 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 1175 (CIDR): The Internet Address Assignment and Aggregation 1176 Plan", BCP 122, RFC 4632, DOI 10.17487/RFC4632, August 1177 2006, . 1179 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1180 IANA Considerations Section in RFCs", RFC 5226, 1181 DOI 10.17487/RFC5226, May 2008, . 1184 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1185 Address Text Representation", RFC 5952, 1186 DOI 10.17487/RFC5952, August 2010, . 1189 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1190 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1191 2014, . 1193 [RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., 1194 Previdi, S., Roome, W., Shalunov, S., and R. Woundy, 1195 "Application-Layer Traffic Optimization (ALTO) Protocol", 1196 RFC 7285, DOI 10.17487/RFC7285, September 2014, 1197 . 1199 Authors' Addresses 1201 Wendy Roome 1202 Nokia Bell Labs (Retired) 1203 124 Burlington Rd 1204 Murray Hill, NJ 07974 1205 USA 1207 Phone: +1-908-464-6975 1208 Email: wendy@wdroome.com 1210 Shiwei Dawn Chen 1211 Tongji University 1212 4800 Caoan Road 1213 Shanghai 201804 1214 China 1216 Email: dawn_chen_f@hotmail.com 1218 Sabine Randriamasy 1219 Nokia Bell Labs 1220 Route de Villejust 1221 NOZAY 91460 1222 FRANCE 1224 Email: Sabine.Randriamasy@nokia-bell-labs.com 1226 Y. Richard Yang 1227 Yale University 1228 51 Prospect Street 1229 New Haven, CT 06511 1230 USA 1232 Phone: +1-203-432-6400 1233 Email: yry@cs.yale.edu 1235 Jingxuan Jensen Zhang 1236 Tongji University 1237 4800 Caoan Road 1238 Shanghai 201804 1239 China 1241 Email: jingxuan.n.zhang@gmail.com