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

[Haizhou Du <[e-mail]>]

Hi all,
I reviewed the unified property map draft. I agree with all Shenshen and
Qiao's comments.  And I want to give some comments for Qiao's discussions:
 (1) how does property map handle dynamic entity, e.g., ane defined in the
path-vector draft?
I think we can handle Property Map of the dynamic entity in the path-vector
draft.  We can extend the ane property.
 (2) is the inheritance design in the property map draft too rigid?
I agree with Qiao. We can inherit all kinds of value for that
property, Including "null" in the Property Map. If the entity and his son
entity inherits a "null"  value, the ALTO server MAY  just omit all of them
from the root entity.
 (3) How should we modify/improve the designs of both path vector and
property map to make the whole solution a unified one?
I think we can extend the ane property in path vector draft. And we can
define the inheritance and hierarchy of ane property for unified one.

If you have any comments, please share with me? Thank you so much. In
addition, please see my other comments in the following.

*Page 5*
Note that entity addresses may NOT have a unique textual representation.
*[HZ] "may NOT" is not defined in RFC2119. "may NOT have a unique" -> "MAY
have different"*

*Page 10*

3.2.3.  Hierarchy And Inheritance


*[HZ]"And"->"and"*
*Page 23*
Accordingly, an ALTO Server should limit GET-mode property maps for to
properties which do not contain sensitive data.
*[HZ] "should" -> "SHOULD"*

On Wed, Jun 28, 2017 at 9:08 PM, Qiao Xiang <[e-mail]> wrote:

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


-- 
Thanks a lot!
Sincerely!
*************************************************************
Haizhou Du,
Department of Computer Science
*************************************************************