Internet DRAFT - draft-roome-alto-pid-properties
draft-roome-alto-pid-properties
ALTO WG W. Roome
Internet-Draft Alcatel-Lucent
Intended status: Standards Track Y. Yang
Expires: July 27, 2015 Yale
January 23, 2015
PID Property Extension for ALTO Protocol
draft-roome-alto-pid-properties-03
Abstract
This document extends the Application-Layer Traffic Optimization
(ALTO) Protocol [RFC7285] by defining PID-based properties in much
the same way that the original ALTO Protocol defined endpoint-based
properties.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on July 27, 2015.
Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
Roome & Yang Expires July 27, 2015 [Page 1]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Consistency and Inheritance Design Views . . . . . . . . . 4
3. PID Property Names . . . . . . . . . . . . . . . . . . . . . . 4
4. A Hierarchical View of a Network Map . . . . . . . . . . . . . 5
4.1. Nested And Overlapping PIDs . . . . . . . . . . . . . . . 5
4.2. Definition Of PID Property Inheritence . . . . . . . . . . 6
5. Protocol Specification: New Service Information Resources . . 7
5.1. Full PID Property Map . . . . . . . . . . . . . . . . . . 7
5.1.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 7
5.1.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 7
5.1.3. Accept Input Parameters . . . . . . . . . . . . . . . 7
5.1.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 7
5.1.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.6. Response . . . . . . . . . . . . . . . . . . . . . . . 8
5.1.7. Example . . . . . . . . . . . . . . . . . . . . . . . 9
5.2. Filtered PID Property Map . . . . . . . . . . . . . . . . 10
5.2.1. Media Type . . . . . . . . . . . . . . . . . . . . . . 10
5.2.2. HTTP Method . . . . . . . . . . . . . . . . . . . . . 10
5.2.3. Accept Input Parameters . . . . . . . . . . . . . . . 10
5.2.4. Capabilities . . . . . . . . . . . . . . . . . . . . . 10
5.2.5. Uses . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.6. Response . . . . . . . . . . . . . . . . . . . . . . . 11
5.2.7. Example . . . . . . . . . . . . . . . . . . . . . . . 11
6. IRD Example . . . . . . . . . . . . . . . . . . . . . . . . . 12
7. Extensions To Endpoint Property Service . . . . . . . . . . . 13
8. Security Considerations . . . . . . . . . . . . . . . . . . . 14
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
9.1. application/alto-* Media Types . . . . . . . . . . . . . . 14
9.2. ALTO Endpoint Property Type Registry . . . . . . . . . . . 15
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Roome & Yang Expires July 27, 2015 [Page 2]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
1. Introduction
A key abstraction introduced by the ALTO Protocol [RFC7285] is a PID
(Provider-defined Identifier): a named set of endpoint addresses.
For IPv4/IPv6 networks, this set is defined by one or more endpoint
address prefixes, or CIDRs [RFC4632].
An ALTO Server defines one or more Network Maps. Each Network Map is
defined as a set of uniquely named PIDs, with the constraint that any
given CIDR may appear in only one PID. Thus a Network Map logically
partitions the space of endpoint addresses into groups defined by the
PIDs.
An ALTO Server may define several Network Maps, partitioning the
endpoints in different ways. For example, one Network Map might
partition endpoints according to geographical locations, with each
PID representing the set of endpoints at a given location. Another
Network Map might partition the endpoints according to their network
capabilities (e.g., CDN delivery protocols such as HTTP or HTTPS).
In this case, each PID defined in the Network Map represents
endpoints with similar capabilities.
Another abstraction introduced by the ALTO protocol is an Endpoint
Property, which is a named value associated with an endpoint.
Properties can include data such as the endpoint's ISP or ASN
(Autonomous System Number), or the endpoint's latitude and longitude,
or the country or continent codes for the endpoint's location. The
ALTO protocol defines the mechanism for a client to query a server
for these property values, but does not define the Endpoint
Properties themselves; that is left to extensions.
Just as Endpoint Properties are useful, it is reasonable to expect
that it will be useful for sets of endpoints -- that is, PIDs -- to
have properties as well. A PID Property might be an Endpoint
Property shared by all endpoints in that PID (e.g., their ISP or
ASN). Alternatively, a PID Property could be the aggregation of
individual properties of the endpoints in the PID (e.g., the latitude
and longitude of their geographic bounding box). Or a PID Property
might simply be inherent in the way in which the ALTO Server defined
the PID.
However, the base ALTO protocol does not define the concept of PID
Properties, or present a mechanism for a client to obtain PID
Properties from an ALTO Server. This extension remedies that
omission.
Roome & Yang Expires July 27, 2015 [Page 3]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
2. The Consistency and Inheritance Design Views
A key goal for defining PID Properties is that they should be
consistent with, and generalize, Endpoint Properties. Specifically,
in the base ALTO Protocol, the ALTO Server may associate a set of
(name,value) pairs with any endpoint. These sets are the Endpoint
Properties. The ALTO Protocol specifies the mechanism for a client
to retrieve those Endpoint Properties from a server.
Consider the Endpoint Property PR and all endpoints defined in the
PID P. If those endpoints all have the same value for PR, then the
PID property PR for P should also have that same value.
For the more general case, assume that P consists of the set of
endpoint addresses {EPi}, and EPi.PR is the value of property PR for
endpoint EPi. Then we could obtain the value of PR for PID P by
evaluating an aggregation function over the endpoint values {EPi.PR}.
Typical aggregation functions include average/mean, mode, geo-center,
union, bounding box, etc., although of course the actual aggregation
function would depend on the semantics of the property.
Complementing the bottom-up aggregation view, we also adopt a top-
down inheritance view. That is, if a property PR is not explicitly
defined for an endpoint, but the endpoint's PID does define a value
for PR, then the endpoint inherits the value of PID property. The
concept of inheritance is a simple, but powerful concept to reduce
information redundancy.
3. PID Property Names
PID Property names MUST follow the same rules as Global Endpoint
Property names (Section 10.8.2 of [RFC7285]), and non-private names
MUST be registered with IANA.
Furthermore, PID Properties and Endpoint Properties share the same
name space, and their definitions MUST be consistent. That is, if PR
is used as both a PID Property and an Endpoint Property, then the
semantics of PR as a PID Property must be clearly related to
semantics of PR as an Endpoint Property. For example, when used as a
PID Property, PR could be defined as the average (or some other
representative value) of the values of PR for a set of endpoints.
This document will use the type PIDPropertyType to indicate a string
denoting a PID Property Name. This type is identical to
EndpointPropertyType as defined in Section 10.8 of [RFC7285].
Roome & Yang Expires July 27, 2015 [Page 4]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
4. A Hierarchical View of a Network Map
4.1. Nested And Overlapping PIDs
Each PID in a Network Map covers a set of endpoint addresses, and
these sets can form a nested hierarchy. As an example, consider the
following Network Map:
PID p0: [0.0.0.0/0, ::0/0]
PID p1: [1.0.0.0/8]
PID p2a: [1.0.0.0/16]
PID p2b: [1.1.0.0/16]
Every endpoint in p2a and p2b is also in the set covered by p1, and
every possible IPV4 endpoint is also covered by PID p0. We would
like to take advantage of this hierarchy to allow PIDs to inherit
properties, just as a class in an object oriented programming
language inherits attributes from its parent class. In the example,
it is reasonable to expect that PIDs p2a and p2b would inherit any
property of p1 that they do not override, and every PID would inherit
the properties of PID p0.
Note that when calculating costs, the ALTO Protocol requires every
endpoint to be in one, and only one, PID. The ALTO Protocol resolves
this by using the "longest match" rule. That is, the ALTO Protocol
says when an endpoint address is covered by more than one prefix, the
address is in the PID with the prefix with the longest mask. Because
any given prefix can be on only one PID, this ensures each endpoint
is in only one PID. Thus in our example, 1.0.0.1 is in p2a, 1.1.0.1
is in p2b, and 1.2.0.1 in in p1.
However, while PIDs can nest within other PIDs, they do not
necessarily form a simple hierarchy. Suppose we add PID p3 to the
previous Network Map:
PID p0: [0.0.0.0/0, ::0/0]
PID p1: [1.0.0.0/8]
PID p2a: [1.0.0.0/16]
PID p2b: [1.1.0.0/16]
PID p3: [1.0.255.0/24, 1.1.0.0/24]
Some endpoints in p3 are in p2a, and others are in p2b. Thus p3 is
partially contained in PIDs p2a and p2b, without being completely
contained in either. So we would not expect p3 to inherit properties
Roome & Yang Expires July 27, 2015 [Page 5]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
from p2a or p2b. But p3 is completely contained in p1 and p0, so it
is reasonable to expect p3 to inherit properties from p1 and p0 that
are not overridden in p2a or p2b. In short, "PID inheritance" raises
issues similar to those of "multiple inheritance" in object oriented
programming languages.
4.2. Definition Of PID Property Inheritence
While PID inheritance raises some complications, it is too useful to
ignore. Fortunately CIDRs do form a simple "single parent"
hierarchy, so we will use CIDR inheritance as the basis for defining
PID inheritance. We believe this preserves the useful cases, and
avoids the pathological ones.
Note that the ALTO Protocol did not define "PID inheritance" because
it was not relevant to the base protocol.
Definition: A parent of CIDR C is any CIDR, in the set of CIDRs for
all PIDs in the Network Map, which covers all endpoints covered by
C, and whose mask is shorter than the mask of C.
Definition: The immediate parent of CIDR C is the parent of C with
the longest prefix. The immediate parent CIDR might not exist,
but if it does, it is unique.
Definition: A CIDR C inherits the value V for property PR if the PID
containing its immediate parent CIDR defines the value V for
property PR, or if its immediate parent CIDR inherits the value V
for property PR.
Definition: A PID P has the value V for property PR if PR is
explicitly defined with value V in P, or if every CIDR C in P
inherits the same value V for PR.
Suppose the following properties are defined for PIDs described
above:
PID p1: ISP="Verizon" country="us"
PID p2a: ASN="12345" state="NJ"
PID p2b: ASN="12345" state="CT"
Then p2a, p2b, and p3 all inherit the "ISP" and "country" properties
from p1, because those properties are not defined for p2a or p2b. p3
would inherit "12345" for the "ASN" property, because although p2a
and p2b both define that property, they give it the same value.
However, p3 would not inherit the "state" property, because it has
Roome & Yang Expires July 27, 2015 [Page 6]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
different values in p2a and p2b.
5. Protocol Specification: New Service Information Resources
This document defines two new ALTO resources. The PID Property Map
returns the values of a set of properties for all PIDs in a Network
Map. The Filtered PID Property Map returns PID Properties for a
subset of PIDs and properties selected by the client. These are
analogous to the Full and Filtered Network Maps in the base ALTO
Protocol.
An ALTO Server may provide any number of resource of these types,
provided that they have unique capabilities. For example, an ALTO
Server may offer several Full PID Property Maps, for the same Network
Map, as long as each one returns a different set of properties.
Both services are optional. In particular, an ALTO Server may
provide a Full PID Property Map without providing a corresponding
Filtered PID Property Map, and vice versa.
5.1. Full PID Property Map
A Full PID Property Map returns the properties defined for all PIDs
in a Network Map.
5.1.1. Media Type
The media type of an ALTO PID Property Map resource is "application/
alto-pidprop+json".
5.1.2. HTTP Method
An ALTO PID Property Map resource is requested using the HTTP GET
method.
5.1.3. Accept Input Parameters
None.
5.1.4. Capabilities
The capabilities are defined by an object of type
PIDPropertyCapabilities:
object {
PIDPropertyType prop-types<1..*>;
} PIDPropertyCapabilities;
Roome & Yang Expires July 27, 2015 [Page 7]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
where "prop-types" is an array with the names of the PID Properties
returned by this resource.
5.1.5. Uses
An array with the resource-id of the Network Map which defines the
PIDs whose properties are returned.
5.1.6. Response
The "dependent-vtags" field in the "meta" field of the response MUST
be an array that includes the version tag of the ALTO Network Map
defining these PIDs.
The data component of a PID Properties response is named "pid-
properties", which is a JSON object of type PIDPropertyMapData,
where:
object {
PIDPropertyMapData pid-properties;
} InfoResourcePIDProperties : ResponseEntityBase;
object-map {
PIDName -> PIDProps;
} PIDPropertyMapData;
object {
PIDPropertyType -> JSONValue;
} PIDProps
The PIDName and ResponseEntityBase types are defined in Sections 10.1
and 8.4 of the ALTO Protocol [RFC7285].
Specifically, a PIDPropertyMapData object has one member for each PID
in the Network Map. The PID's properties are encoded in the
corresponding PIDProps object. PIDProps encodes one name/value pair
for each property, where the property names are encoded as strings of
type PIDPropertyType. A protocol implementation SHOULD assume that
the property value is a JSONString and fail to parse if it is not,
unless the implementation is using an extension to this document that
indicates when and how property values of other data types are
signaled.
For each PID in the Network Map, the ALTO Server returns the value
defined for each of the PID Properties specified in this resource's
"capabilities" list. For efficiency, the ALTO Server SHOULD omit
property values that are inherited rather than explicitly defined.
The client SHOULD use the algorithm defined in Section 4.2 to
Roome & Yang Expires July 27, 2015 [Page 8]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
determine inherited property values.
An ALTO Server MAY explicitly define a property as not having a value
for a particular PID. That is, a server may say that a property is
"defined to have no value", as opposed to the property being
"undefined". In this case, if the PID would not inherit a value for
that property, then the ALTO Server MUST either omit the property, or
else return a "null" value for it. However, if that PID would
inherit a value for that property, then the ALTO server MUST return a
"null" value. An ALTO Client MUST recognize a "null" value as
meaning "do not apply the inheritance rules for this property in the
PID."
If the ALTO Server does not define any properties for a PID, then the
server MAY omit that PID from the response.
5.1.7. Example
The following example uses the Network Map and PID Properties defined
above. Note that the response does not include entries for PIDs p0
or p3. The former was omitted because no properties were defined for
it, and the latter because its only properties are inherited.
GET /pidprop/full HTTP/1.1
Host: alto.example.com
Accept: application/alto-pidprop+json,application/alto-error+json
HTTP/1.1 200 OK
Content-Length: ###
Content-Type: application/alto-pidprop+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
}
]
},
"pid-properties": {
"p1" : { "ISP": "Verizon", "country": "us" },
"p2a": { "ASN": "12345", "state": "NJ" },
"p2b": { "ASN": "12345", "state": "CT" }
}
}
Roome & Yang Expires July 27, 2015 [Page 9]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
5.2. Filtered PID Property Map
A Filtered PID Property Map returns the values for set of PIDs and
properties selected by the client.
5.2.1. Media Type
The media type of an ALTO Filtered PID Property Map resource is the
same as a Full PID Property Map, and is defined in Section 5.1.1.
5.2.2. HTTP Method
An ALTO Filtered PID Property Map resource is requested using the
HTTP POST method.
5.2.3. Accept Input Parameters
The input parameters for a Filtered PID Property Map request are
supplied in the entity body of the POST request. This document
specifies the input parameters with a data format indicated by the
media type "application/alto-pidpropparams+json", which is a JSON
object of type ReqPIDProp:
object {
PIDPropertyType properties<1..*>;
PIDName pids<1..*>
} ReqPIDProp;
with fields:
properties: List of PID properties to be returned for each PID.
Each specified property MUST be included in the list of supported
properties indicated by this resource's "capabilities" field
(Section 5.2.4). The ALTO server MUST interpret entries appearing
multiple times as if they appeared only once.
pids: List of PID names for which the specified properties are to be
returned. The ALTO server MUST interpret entries appearing
multiple times as if they appeared only once.
5.2.4. Capabilities
The capabilities are defined by an object of type
PIDPropertyCapabilities, as defined above.
Roome & Yang Expires July 27, 2015 [Page 10]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
5.2.5. Uses
An array with the resource-id of the Network Map which defines the
PIDs whose properties are returned.
5.2.6. Response
The response is the same as for the Full PID Property Map
(Section 5.1.6), except that it only includes the properties and PIDs
requested by the client.
Also, Filtered PID Property Map response MUST include all inherited
PID property values (unlike the Full PID Property Map, the Filtered
PID Property Map response does not include enough information for the
client to calculate the inherited values).
5.2.7. Example
The following example uses the Network Map and PID Properties defined
above. Note that the response includes the inherited property "ISP"
for PID p2a, and "state" and "ISP" for p3.
Roome & Yang Expires July 27, 2015 [Page 11]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
POST /pidprop/lookup HTTP/1.1
Host: alto.example.com
Content-Length: ###
Content-Type: application/alto-pidpropparams+json
Accept: application/alto-pidprop+json,application/alto-error+json
{
"properties" : [ "ISP", "ASN", "state" ]",
"pids" : [ "p1", "p2a", "p3" ]
}
HTTP/1.1 200 OK
Content-Length: ###
Content-Type: application/alto-pidprop+json
{
"meta" : {
"dependent-vtags" : [
{"resource-id": "my-default-network-map",
"tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"
}
]
},
"pid-properties" : {
"p1" : { "ISP": "Verizon" },
"p2a": { "ISP": "Verizon", "ASN": "12345", "state": "NJ" },
"p3" : { "ISP": "Verizon", "ASN": "12345" }
}
}
6. IRD Example
Here is an example of an ALTO Information Resource Directory (IRD)
which defines several PID Property resources. Note that "full-pid-
property-map" returns several PID Properties for all PIDs in the
Network Map, while "asn-pid-property-map" returns just the ASN
property. The resource "filtered-pid-properties" resource returns
values for properties and PIDs selected by the client.
Roome & Yang Expires July 27, 2015 [Page 12]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
...
"resources" : {
"my-default-network-map" : {
"uri" : "http://alto.example.com/networkmap",
"media-type" : "application/alto-networkmap+json"
},
"endpoint-property" : {
"uri" : "http://alto.example.com/endpointprop/lookup",
"media-type" : "application/alto-endpointprop+json",
"accepts" : "application/alto-endpointpropparams+json",
"capabilities" : {
"prop-types" : [ "my-default-network-map.pid",
"priv:ietf-example-prop" ]
},
},
"full-pid-property-map" : {
"uri" : "http://alto.example.com/pidprop/full",
"media-type" : "application/alto-pidprop+json",
"uses" : ["my-default-network-map" ]
"capabilities" : {
"prop-types" : [ "ISP", "country", "ASN", "state" ]
},
}
"asn-pid-property-map" : {
"uri" : "http://alto.example.com/pidprop/asn",
"media-type" : "application/alto-pidprop+json",
"uses" : ["my-default-network-map" ]
"capabilities" : {
"prop-types" : [ "ASN" ]
},
}
"filtered-pid-properties" : {
"uri" : "http://alto.example.com/pidprop/lookup",
"media-type" : "application/alto-pidprop+json",
"accepts" : "application/alto-pidpropparams+json",
"uses" : ["my-default-network-map" ]
"capabilities" : {
"prop-types" : [ "ISP", "country", "ASN", "state" ]
},
}
}
7. Extensions To Endpoint Property Service
As described in Section 10.8 of [RFC7285], Endpoint Property names
may be prefixed with the Resource ID of a Network Map. For such
Roome & Yang Expires July 27, 2015 [Page 13]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
resource-specific properties, if a value is not explicitly defined
for an endpoint, the Endpoint Property Service MUST return the value
that a PID Property Map would return for the PID containing that
endpoint.
For property names that are not prefixed by a Network Map Resource
ID, if a value is not defined for an endpoint, the Endpoint Property
Service MAY return the value defined for that property in one of the
ALTO Server's PID Property Maps for the PID containing the endpoint.
8. Security Considerations
As with Endpoint Properties, PID Properties may have sensitive
customer-specific information. If this is the case, an ALTO Server
may limit access to those properties by providing several different
PID Property services. For non-sensitive properties, the ALTO Server
would provide a URI which accepts requests from any client.
Sensitive properties, on the other hand, would only be available via
a secure URI which would require client authentication.
9. IANA Considerations
This document defines additional application/alto-* media types, and
extends the ALTO endpoint property registry.
9.1. application/alto-* Media Types
This document registers two additional ALTO media types, listed in
Table 1.
+-------------+-------------------------+---------------+
| Type | Subtype | Specification |
+-------------+-------------------------+---------------+
| application | alto-pidprop+json | Section 5.1.1 |
| application | alto-pidpropparams+json | Section 5.2.3 |
+-------------+-------------------------+---------------+
Table 1: Additional ALTO Media Types
Type name: application
Subtype name: This documents registers multiple subtypes, as listed
in Table 1.
Roome & Yang Expires July 27, 2015 [Page 14]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
Required parameters: n/a
Optional parameters: n/a
Encoding considerations: Encoding considerations are identical to
those specified for the "application/json" media type. See
[RFC7159].
Security considerations: Security considerations relating to the
generation and consumption of ALTO Protocol messages are discussed
in Section 15 of [RFC7285].
Interoperability considerations: This document specifies format of
conforming messages and the interpretation thereof.
Published specification: This document is the specification for
these media types; see Table 1 for the section documenting each
media type.
Applications that use this media type: ALTO servers and ALTO clients
either stand alone or are embedded within other applications.
Additional information:
Magic number(s): n/a
File extension(s): This document uses the mime type to refer to
protocol messages and thus does not require a file extension.
Macintosh file type code(s): n/a
Person & email address to contact for further information: See
Authors' Addresses section.
Intended usage: COMMON
Restrictions on usage: n/a
Author: See Authors' Addresses section.
Change controller: Internet Engineering Task Force
(mailto:iesg@ietf.org).
9.2. ALTO Endpoint Property Type Registry
The ALTO Endpoint Property Type Registry was created by [RFC7285].
If possible, the name of that registry should be changed to "ALTO
Property Type Registry", to indicate that it is not restricted to
Roome & Yang Expires July 27, 2015 [Page 15]
Internet-Draft PID Property Extension for ALTO Protocol January 2015
Endpoint Properties. If it is not feasible to change the name, the
description must be amended to indicate that it registers PID
Properties as well as Endpoint Properties.
10. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP 14, March 1997.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing
(CIDR): The Internet Address Assignment and Aggregation
Plan", RFC 4632, BCP 122, August 2006.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014.
[RFC7285] Almi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S.,
Roome, W., Shalunov, S., and R. Woundy, "Application-Layer
Traffic Optimization (ALTO) Protocol", RFC 7285,
September 2014.
Authors' Addresses
Wendy Roome
Alcatel-Lucent/Bell Labs
600 Mountain Ave, Rm 3B-324
Murray Hill, NJ 07974
USA
Phone: +1-908-582-7974
Email: w.roome@alcatel-lucent.com
Y. Richard Yang
Yale University
51 Prospect St.
New Haven, CT
USA
Email: yry@cs.yale.edu
Roome & Yang Expires July 27, 2015 [Page 16]
