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

[Qiao Xiang <[e-mail]>]

Hi Wendy, Richard and all,

I reviewed the unified property map draft. I agree with
all Shenshen's comments. In addition, please see my other comments in the
following.

In addition to the review, the key design questions I want to raise
discussions are (1) how does property map handle dynamic entity, e.g., ane
defined in the path-vector draft? (2) is the inheritance design in the
property map draft too rigid? (see my comments marked with <QX??>) and (3)
in the current path vector draft the ane is defined with no inheritance or
hierarchy, but aggregating/compressing multiple ane's is an important
process for the path vector service to reduce overhead and provide privacy
of networks. how should we modify/improve the designs of both path vector
and property map to make the whole solution a unified one. I will work on
these three questions in the next few days and share my thoughts.
Menawhile, would you please also share any comments/thoughts you may have?
Thank you very much.


*Reviews:*
*Page 4*

   This document proposes a new approach to ALTO properties.
*<QX> "approach to ALTO properties" -> "approach to retrieve 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
*<QX> "analogous the ALTO's " -> "analogous to the ALTO's "*

   are POST-mode resources which return the values for a set of
   properties and entities requested by the client, and are analogous to
*<QX> "the values for a set of properties and entities" -> "the values of a
set of properties for a set of entities"*

   ALTO's Filtered Network Maps and Filtered Cost Maps.

*Page 5*

   The format of the second part of an entity address depends on the
   domain, and must be specified when registering a new domain.
*<QX> "must" -> "MUST"*

   Addresses may be hierarchical, and properties may be inherited based
   on that hierarchy.  Again, the rules defining any hierarchy or
   inheritance must be defined when the domain is registered.
*<QX> "must" -> "MUST"*

   Note that entity addresses do NOT have a unique textual
   representation.  For example, the strings "ipv6:2001:db8::1" and
   "ipv6:2001:db8:0:0:0:0:0:1" refer to the same entity.
*<QX> "NOT" is not defined in RFC2119. "do NOT have a unique" -> "MAY have
different"*

   ...

   Domain names must be registered with the IANA, and the format of the
   entity addresses in that domain, as well as any hierarchical or
   inheritance rules for those entities, must be specified at the same
   time.
*<QX> "must"->"MUST"*

   ...

   Property names are not specific to a domain, although some properties
   may only be applicable for particular domains, and the interpretation
   of the value may depend on the domain.  For example, suppose the
   "geo-location" property is defined as the coordinates of a point,
   encoded as (say) "latitude longitude [altitude]."  When applied to an
*<QX> "as (say)" -> "as"*

*Page 6*

   ...

   [RFC7285] recognizes that some properties may be specific to another
   ALTO resource, such as a network map.  Accordingly [RFC7285] defines
   the concept of "resource-specific endpoint properties"
   (Section 10.8.1), and indicates that dependency by prefixing the
   property name with the ID of the resource on which it depends.  That
   document defines one resource-specific property, namely the "pid"
   property, whose value is the name of the name of the PID containing
*<QX> "the name of the name of the PID" -> "the name of the PID"*

   that endpoint in the associated network map.

   ...
   According to [RFC7285], an ALTO server with two network maps, with
*<QX> "an ALTO server" -> "a legacy ALTO server"*

*Page 7*

3.1.  Internet Address Domains

   The domain of internet addresses consists of two domains (IPv4 and
   IPv6).  Both domains include individual addresses and blocks of
   addresses.
*<QX> After reading the beginning of Sec 3.2, I feel that Section 3.1
should add a sentence like "this domain does not have to depend on an ALTO
network map resource." in the beginning.*

3.1.1.  IPV4 Domain
*<QX> "IPV4" -> "IPv4"*

   ...
   For the purpose of defining properties, an individual internet
   address and the corresponding full-length prefix are considered
   aliases for the same entity.  Thus "ipv4:192.0.2.0" and
   "ipv4:192.0.2.0/32" are equivalent, and have the same set of
   properties, as are "ipv6:2001:db8::" and "ipv6:2001:db8::/128".
*<QX> remove ", as are "ipv6:2001:db8::" and "ipv6:2001:db8::/128" because
this section is about IPv4 domain.*

3.1.2.  IPV6 Domain
*<QX> "IPV6" -> "IPv6"*

    ...
3.1.2.2.  Domain-Specific Entity Addresses

   ...
   For the purpose of defining properties, an individual internet
   address and the corresponding 128-bit prefix are considered aliases
   for the same entity.  That is, "ipv6:2001:db8::1" and
   "ipv:2001:db8::1/128" are equivalent, and have the same set of
   properties.
*<QX> "ipv:2001:db8::1/128" -> "ipv6:2001:db8::1/128"*

*Page 8*

   ...
   Then the following entities have the indicated values:

          ipv4:192.0.2.0:    P=v4
          ipv4:192.0.2.1:    P=v3
          ipv4:192.0.2.16:   P=v2
*<QX> "ipv4:192.0.2.16 <http://192.0.2.16>:   P=v2" -> "ipv4:192.0.2.16
<http://192.0.2.16>:   P=v1", if we want an example of P=v2, we can use
"ipv4:192.0.2.8 <http://192.0.2.8>:   P=v2"*

          ipv4:192.0.2.32:   P=v1
          ipv4:192.0.2.64:   (not defined)
          ipv4:192.0.2.0/32: P=v4
          ipv4:192.0.2.0/31: P=v3
          ipv4:192.0.2.0/29: P=v2
          ipv4:192.0.2.0/27: P=v1
          ipv4:192.0.2.0/25: (not defined)

                         Inherited Property Values
    ...
3.3.  Internet Address Properties vs. PID Properties

   ...

   For example, because internet addresses are allocated to server
*<QX> "server" -> "service"*

*Page 10*

4.  Property Map Resource

   A Property Map returns the properties defined for all entities in one
   of more domains.
*<QX> "of more" -> "or more"*

   ...

*Page 11*

   For each entity in the Property Map, the ALTO Server returns the
   value defined for each of the properties specified in this resource's
   "capabilities" list.  For efficiency, the ALTO Server SHOULD omit
   property values that are inherited rather than explicitly defined; if
   a client needs inherited values, the client SHOULD use the domain's
   inheritance rules to deduce those values.
*<QX??> in the current draft, inheritance is defined in an all-or-nothing
form. Either a domain allows inheritance or it does not. Since the
computation of a property is up to the implementation, shouldn't we let the
implementation decide how properties are inherited from a larger block to a
smaller block of entities? Consider the example in Section 7.6, the current
draft seems to tell the admin: either you come up with a better property
map stored in the ALTO server to avoid failed/inaccurate query, or there is
zero flexibility for you to compute or update property map on demand. My
feeling is this may not be the right way... *

*Page 12*

    ...
5.2.  HTTP Method

   An ALTO Property Map resource is requested using the HTTP POST
   method.
*<QX> "an ALTO Property Map" -> "an ALTO Filtered Property Map"*


*Page 13*

5.6.  Response

   The response is the same as for the property map (Section 4.6),
*<QX> "property map" -> "Property Map"*

   except that it only includes the entities and properties requested by
   the client.

   Also, the Filtered Property Map response MUST include all inherited
   property values for the specified entities (unlike the Full Property
*<QX> "Full" -> "full", since Full Property Map is not a term defined in
this document.*

   Map, the Filtered Property Map response does not include enough
   information for the client to calculate the inherited values).

6.  Impact On Legacy Servers And Clients
*<QX> "Legacy Servers And Clients" -> "Legacy ALTO Servers And ALTO
Clients"*

6.1.  Impact on Endpoint Property Service

   The property maps defined in this document provide the same
*<QX> "property maps" -> "Property Map"*

   functionality as the Endpoint Property Service (EPS) defined in
   Section 11.4 of [RFC7285].  Accordingly, it is RECOMMENDED that the
   EPS be deprecated in favor of property maps.  However, ALTO servers
*<QX> "property maps" -> "Property Map"*

   MAY provide an EPS for the benefit of legacy clients.

*Page 14*

   ...
   However, when used with property maps, this document amends the
*<QX> "property maps" -> "Property Map"*

   definition of the "pid" property as follows.

   First, the name of the property is simply "pid"; the name is not
   prefixed with the resource ID of a network map.  The "uses"
   capability of the property map resource indicates the associated
   network map.  This implies that a property map can only return the
   "pid" property for one network map; if an ALTO server provides
   several network maps, it must provide a property map resource for
   each one.
*<QX> "must provide" -> "MUST provide"*


*Page 15*

    ...
    7.3.  Information Resource Directory (IRD)

   ...
   The Property Maps for the "ISP", "ASN", "country" and "state"
*<QX> "Property Maps" -> "Filtered Property Map"*

   properties do not depend on the default network map (they do not have
*<QX> "do not depend on the default network map (they do not have" ->*
*     "does not depend on the default network map (it does not have"*

*Page 18*

    ...
7.6.  Filtered Property Map Example #2

   ...
   Also note the "ASN" property has the value "12345" for both the
   blocks "ipv4:192.0.2.0/28" and "ipv4:192.0.2.16/28", so every address
   in the block "ipv4:192.0.2.0/27" has that property value.  However
   the block "ipv4:192.0.2.0/27" itself does not have a value for "ASN":
   address blocks cannot inherit properties from blocks with longer
   prefixes, even if every such block has the same value.
*<QX> This is a very good example. Please see my comments makred in <QX??>
for page 11. And if we eventually insist the all-or-nothing inheritance
design, it would make the inheritance of properties much clearer to readers
if we use it in Section 3.1.3, instead of explaining the reasons here.*

*Page 19*

7.7.  Filtered Property Map Example #3

   ...
   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".
*<QX> I agree with Shenzhen's comments. 10.0.0.0/XX <http://10.0.0.0/XX> is
inconsistent with the settings in Section 7.1. It should be fixed in the
next version.*

*Page 21*

   Also, while technically this document does not introduce any security
   risks not inherent in the Endpoint Property Service defined by
   [RFC7285], the GET-mode property map resource defined in this
   document does make it easier for a client to download large numbers
   of property values.  Accordingly, an ALTO Server should limit GET-
   mode property maps for to properties which do not contain sensitive
   data.
*<QX> "for to properties" -> "to properties"*

9.1.  application/alto-* Media Types
   ...
   Security considerations:  Security considerations relating to the
*<QX> "relating" -> "related"*

      generation and consumption of ALTO Protocol messages are discussed
      in Section 15 of [RFC7285].

   Interoperability considerations:  This document specifies format of
*<QX> "format" -> "formats"*


On Mon, Jun 26, 2017 at 11:58 PM, Shenshen Chen <[e-mail]> wrote:

> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/alto
>
>


-- 
Qiao Xiang
Postdoctoral Fellow,
Department of Computer Science,
Yale University