[alto] Review of draft-roome-alto-unified-props-new-00

[Shenshen Chen <[e-mail]>]

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