Dear authors of alto-unified-props and all,
In section 2.5, I feel "property type" could be better (because RFC7285
names
sections using "property type", but not "property name") and "property
value"
should be mentioned (includes the "null" value mentioned in section 4.6).
I also suggest showing the "null" value can be inherited explicitly
in the section 3.1.3 or emphasizing it as a normal property value.
Here is a list of typos (comments are marked with ">>>"):
[Page 2]
3.1.3. Heirarchy And Inheritance . . . . . . . . . . . . . . 7
3.1.4. Relationship To Network Maps . . . . . . . . . . . . 8
3.2. PID Domain . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1. Domain Name . . . . . . . . . . . . . . . . . . . . . 9
3.2.2. Domain-Specific Entity Addresses . . . . . . . . . . 9
3.2.3. Heirarchy And Inheritance . . . . . . . . . . . . . . 9
3.2.4. Relationship To Internet Addresses Domains . . . . . 9
>>> "To" => "to", "And" => "and", "Heirarchy" => "Hierarchy"
[Page 3]
Second, the EPS is only defined as a POST-mode service. Clients must
request the properties for an explicit set of addresses. By
contrast, [RFC7285] defines a GET-mode Cost Map resource which
returns all available costs, so a client can get the full set of
costs once, and then lookup costs without querying the ALTO server.
RFC7285 does not define an equivalent service for endpoint
properties. Granted, it is not be practical to enumerate the
>>> "is not be" => "is not"
[Page 4]
This document proposes a new approach to ALTO properties.
Specifically, it defines two new resource types, namely Property Maps
and Filtered Property Maps. The former are GET-mode resources which
return the property values for all entities in a domain, and are
analogous the ALTO's Network Map and Cost Map resources. The latter
>>> "Network Map and Cost Map resources" => "Network Maps and Cost Maps"
I think it should keep the same format with "Filtered Network Maps
and Filtered Cost Maps" in the last sentence of this paragraph.
are POST-mode resources which return the values for a set of
properties and entities requested by the client, and are analogous to
ALTO's Filtered Network Maps and Filtered Cost Maps.
[Page 7]
3.1.3. Heirarchy And Inheritance
[Page 9]
3.2.3. Heirarchy And Inheritance
>>> "Heirarchy" => "Hierarchy"
[Page 19]
Note that the value of "pid" for the prefix "ipv4:10.0.0.0/15" is
"pid1", even though all addresses in that block are in "pid2",
because "ipv4:10.0.0.0/8" is the longest prefix in the network map
which prefix-matches "ipv4:10.0.0.0/15", and that prefix is in
"pid1".
POST /propmap/lookup/pid HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: ###
Content-Type: application/alto-propmapparams+json
{
"entities" : [
"ipv4:192.0.2.0 10.0.0.0",
"ipv4:192.0.2.16 10.1.0.0",
"ipv4:192.0.2.64 10.3.0.0",
"ipv4:192.0.2.128 11.0.0.0",
"ipv4:192.0.2.0/26 10.0.0.0/15",
"ipv4:192.0.2.0/30 10.0.0.0/17" ],
"properties" : [ "pid" ]
}
>>> This part should be modified into:
Note that the value of "pid" for the prefix "ipv4:192.0.2.0/26" is
"pid1", even though all addresses in that block are in "pid2",
because "ipv4:192.0.2.0/25" is the longest prefix in the network map
which prefix-matches "ipv4:192.0.2.0/26", and that prefix is in
"pid1".
POST /propmap/lookup/pid HTTP/1.1
Host: alto.example.com
Accept: application/alto-propmap+json,application/alto-error+json
Content-Length: ###
Content-Type: application/alto-propmapparams+json
{
"entities" : [
"ipv4:192.0.2.0",
"ipv4:192.0.2.16",
"ipv4:192.0.2.64",
"ipv4:192.0.2.128",
"ipv4:192.0.2.0/26",
"ipv4:192.0.2.0/30" ],
"properties" : [ "pid" ]
}
[Page 23]
New ALTO entity domains are assigned after IETF Review [RFC5226] to
ensure that proper documentation regarding the new ALTO entity
domains and their security considerations has been provided. RFCs
>>> "has been" => "have been"
defining new entity domains should indicate how an entity in a
registered domain is encoded as an EntityName, and, if applicable,
the rules defining the entity hierarchy and property inheritance.
Updates and deletions of ALTO entity domains follow the same
procedure.
Best Regards,
Shenshen
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
