Re: [alto] Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21: (with DISCUSS and COMMENT) - DISCUSS + COMMENTS on section

["Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[e-mail]>]

Hello Benjamin,

Thank you very much for your thorough review and guidance. 
The present e-mail addresses your DISCUSS points and COMMENTS on section 10, as they relate to a DISCUSS point.
Please see the responses inline.
The other COMMENTS and NITS will be addressed in a separate e-mail.

Best regards,
Sabine, Jensen, Kai, Richard

>-----Original Message-----
>From: Benjamin Kaduk via Datatracker <[e-mail]>
>Sent: Thursday, December 2, 2021 12:00 AM
>To: The IESG <[e-mail]>
>Cc: [e-mail]; [e-mail];
>[e-mail]; Vijay Gurbani <[e-mail]>;
>[e-mail]
>Subject: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>(with DISCUSS and COMMENT)
>
>Benjamin Kaduk has entered the following ballot position for
>draft-ietf-alto-unified-props-new-21: Discuss
>
>When responding, please keep the subject line intact and reply to all email
>addresses included in the To and CC lines. (Feel free to cut this introductory
>paragraph, however.)
>
>
>Please refer to https://www.ietf.org/blog/handling-iesg-ballot-positions/
>for more information about how to handle DISCUSS and COMMENT positions.
>
>
>The document, along with other ballot positions, can be found here:
>https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/
>
>
>
>----------------------------------------------------------------------
>DISCUSS:
>----------------------------------------------------------------------
>
>(1) Section 8.6 seems to have some conflicting requirements.  The filtered
>property map response "MUST include all the inherited property values for
>the requested entities and all the entities which are able to inherit property
>values from the requested entities."  We then go on to say that to do this, the
>server MAY follow three rules, that themselves include SHOULD-level
>guidance, but don't say how the MUST is achieved if the SHOULDs or MAY are
>ignored.  I was expecting to see a construction of the form "SHOULD do X, but
>if not, MUST do Y".
>
[ [SR] ] 
Indeed the requirements need to set clear rules. We propose to update the text as follows:
OLD 
... 
To achieve this goal, the ALTO server MAY follow three rules:

   *  If a property for a requested entity is inherited from another
      entity not included in the request, the response SHOULD include
      this property for the requested entity.  For example, A full
      property map may skip a property P for an entity A (e.g.,
      ipv4:192.0.2.0/31) if P can be derived using inheritance from
      another entity B (e.g., ipv4:192.0.2.0/30).  A filtered property
      map request may include only A but not B.  In such a case, the
      property P SHOULD be included in the response for A.

   *  If there are entities covered by a requested entity but having
      different values for the requested properties, the response SHOULD
      include all those entities and the different property values for
      them.  For example, considering a request for property P of entity
      A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
      A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the
      response SHOULD include A1 and A2.

   *  If an entity identifier in the response is already covered by
      other entities identifiers in the same response, it SHOULD be
      removed from the response, for the sake of compactness.  In the
      previous example, the entity A = ipv4:192.0.2.0/31 SHOULD be
      removed because A1 and A2 cover all the addresses in A.
NEW
... 
To achieve this goal, the ALTO server MUST follow two rules:

   *  If a property for a requested entity is inherited from another
      entity not included in the request, the response MUST include
      this property for the requested entity.  For example, A full
      property map may skip a property P for an entity A (e.g.,
      ipv4:192.0.2.0/31) if P can be derived using inheritance from
      another entity B (e.g., ipv4:192.0.2.0/30).  A filtered property
      map request may include only A but not B.  In such a case, the
      property P MUST be included in the response for A.

   *  If there are entities covered by a requested entity but having
      different values for the requested properties, the response MUST
      include all those entities and the different property values for
      them.  For example, considering a request for property P of entity
      A (e.g., ipv4:192.0.2.0/31), if P has value v1 for
      A1=ipv4:192.0.2.0/32 and v2 for A2=ipv4:192.0.2.1/32, then, the
      response MUST include A1 and A2.

For the sake of response compactness, the ALTO Server SHOULD obey the following rule:

   *  If an entity identifier in the response is already covered by
      other entities identifiers in the same response, it SHOULD be
      removed from the response.  In the
      previous example, the entity A = ipv4:192.0.2.0/31 SHOULD be
      removed because A1 and A2 cover all the addresses in A.


>(2) Many of the examples in Sections 10.X do not seem to match up with the
>prose that describes them and the previous data tables that they are intended
>to illustrate (see COMMENT).  We should make sure that the examples are
>internally consistent.
>
[ [SR] ] Please see our responses on the "COMMENTS on SECTION 10" section. 

>(3) Section 4.6.2 says:
>
>   *  Last, the entity domain types "asn" and "countrycode" defined in
>      [I-D.ietf-alto-cdni-request-routing-alto] do not have a defining
>      information resource.  Indeed, the entity identifiers in these two
>      entity domain types are already standardized in documents that the
>      Client can use.
>
>But earlier we said that "the defining information resource of a resource-
>specific entity domain D is unique", but this seems to be saying that the
>defining information resource of domains of the "asn"
>and "contrycode" type are *not* unique, by virtue of not existing at all.  How
>can we rectify these two statements?
>
[ [SR] ] To rectify this, we propose to update the text in Section 4.6.1  as follows: 
--- parag 2
OLD
"...This concept applies to resource-specific entity domains. ..."
NEW
"...A defining information resource is defined for resource-specific entity domains. It does not exist for entity domains that are not resource-specific such as "ipv4" or "ipv6". Neither does it exist for entity domains that are covering entity identifiers already defined in other standardization documents, at it is the case for country code identifiers standardized in [ISO3166-1] or AS numbers allocated by the IANA. ..."

--- parag 3,
OLD
 "the defining information resource of a resource-specific entity domain D is unique... "
NEW
"the defining information resource of a resource-specific entity domain D, when it exists, is unique... "
>
>----------------------------------------------------------------------
>COMMENT:[ [SR] ]  on SECTION 10
>----------------------------------------------------------------------
>
>Section 10.x
>
>I am not really an HTTP expert, but the content-lengths in these examples
>seem to be based on byte counts with Unix-style line separators, whereas (per
>draft-ietf-httpbis-messaging) my understanding is that the values should be
>computed with CRLF as the line separator.
>
[ [SR] ] In this document, all the examples use Unix-style line separators. But in neither draft-ietf-httpbis-messaging-19 nor RFC7230, did we find any statement saying that the content-length value should be computed with CRLF as EoL. CRLF is only used to separate different HTTP header field lines and chunked data (Sec 2.1 and 7.1 of draft-ietf-httpbis-messaging-19), not the message body. 
If you think the content-length computation is not clear, how about we add the following sentence at the beginning of Sec 10:
NEW
In this document, the HTTP message bodies of all the examples use Unix-style line-ending character (%x0A) as the line separator.

>Section 10.2
>
>   Beyond "pid", the examples in this section use four additional
>   properties for Internet address domains, "ISP", "ASN", "country" and
>   "state", with the following values:
>
>Are these property names, types, or both?
>Should we use "countrycode" that is defined by draft-ietf-alto-cdni-request-
>routing-alto, rather than the very similar sounding "country"?
>
[ [SR] ] yes, we can use "countrycode" and will update the examples accordingly
OLD
   Beyond "pid", the examples in this section use four additional
   properties for Internet address domains, "ISP", "ASN", "country" and
   "state", with the following values:
NEW
   Beyond "pid", the examples in this section use four additional
   property types for entities of domain type "ipv4":  "countrycode", "ASN",  "ISP", and "state". 
These properties are assumed to be resource-agnostic so their name is identical to their type.  
The entities have the following values:

>Section 10.3
>
>   The following IRD defines ALTO Server information resources that are
>   relevant to the Entity Property Service.  It provides two property
>   maps: one for the "ISP" and "ASN" properties, and another one for the
>   "country" and "state" properties.  [...]
>
>I may be misreading things, but I could only find the former of these two.  I
>should be looking for resources that have the "application/alto-
>propmap+json" media-type and do not accept parameters, right?
>
[ [SR] ] thanks for catching this. This text is inherited from previous versions. We will update as follows:
OLD
The following IRD defines ALTO Server information resources that are
   relevant to the Entity Property Service.  It provides two property
   maps: one for the "ISP" and "ASN" properties, and another one for the
   "country" and "state" properties.  [...]
NEW
The following IRD defines ALTO Server information resources that are
   relevant to the Entity Property Service.  It provides a property
   map for the "ISP" and "ASN" properties.

>   The server provides several filtered property maps.  The first
>   returns all four properties, and the second returns only the "pid"
>   property for the default network map.
>
>Does it also return the "pid" property for the alt-network-map?
>
[ [SR] ] Yes, thanks.
OLD
... the second returns only the "pid"  property for the default network map.
NEW
... the second returns only the "pid"  property for the default network map and the "alt-network-map".

>   The filtered property maps for the "ISP", "ASN", "country" and
>   "state" properties do not depend on the default network map (it does
>   not have a "uses" capability), because the definitions of those
>
>I only see "ISP" showing up in the ia-property-map and the iacs-property-map,
>both of which list "uses" for the default-network-map.
>
[ [SR] ] Indeed, thanks. 
We will remove member "uses": [ "default-network-map", "alt-network-map" ] 
from "ia-property-map" and "iacs-property-map"

>   Note that for legacy clients, the ALTO server provides an Endpoint
>   Property Service for the "pid" property defined on the endpoints of
>   the default network map.
>
>Also the alt-network-map?
>
[ [SR] ] yes, indeed
OLD
... the "pid" property defined on the endpoints of the default network map.
NEW
... the "pid" property defined on the endpoints of the default network map and the "alt-network-map".

>I think there are a couple other property maps in the returned IRD that are
>not mentioned in the prose at all (not sure if they need to be).
>
[ [SR] ] Our intent is that the examples mentioned in the prose helps understanding the other ones.

>Section 10.4
>
>   Note that, to be compact, the response does not include the entity
>   "ipv4:192.0.2.0", because values of all those properties for this
>   entity are inherited from other entities.
>
>Is this really the single IP address, equivalent to 192.0.2.0/32?  I don't see why
>it's special enough to get called out, as opposed to the other addresses in
>192.0.2.0/27.
>
[ [SR] ] this is a typo here. "ipv4:192.0.2.0" in this paragraph should be "ipv4:192.0.2.1".
OLD
Note that, to be compact, the response does not include the entity
   "ipv4:192.0.2.0", because values of all those properties for this
   entity are inherited from other entities.
NEW
Note that, to be compact, the response does not include the entity
   "ipv4:192.0.2.1", because values of all those properties for this
   entity are inherited from other entities.

>    The same rule
>   applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28".
>
>Should one of these be 192.0.3.16/28?
>
[ [SR] ] yes indeed, thanks. 
OLD
applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.0/28".
NEW
applies to the entities "ipv4:192.0.3.0/28" and "ipv4:192.0.3.16/28".


>Section 10.5
>
>   Note that the value of "state" for "ipv4:192.0.2.0" is the only
>   explicitly defined property; the other values are all derived by the
>   inheritance rules for Internet address entities.
>
>I think the .2.1 is explicitly defined and .2.0 is inherited...
>
[ [SR] ] SR, yes indeed, thanks
OLD
Note that the value of "state" for "ipv4:192.0.2.0" is the only
   explicitly defined property; the other values are all derived by the
   inheritance rules for Internet address entities.
NEW
Note that the value of "state" for "ipv4:192.0.2.1" is the only
   explicitly defined property; the other values are all derived by the
   inheritance rules for Internet address entities.

>     "property-map": {
>       "ipv4:192.0.2.0":
>              {".ISP": "BitsRus", ".ASN": "65543", ".state": "PA"},
>       "ipv4:192.0.2.1":
>              {".ISP": "BitsRus", ".ASN": "65543", ".state": "NJ"},
>       "ipv4:192.0.2.17":
>              {".ISP": "BitsRus", ".ASN": "65543", ".state": "CT"}
>
>...and my reading of the table in §10.2 would have .2.0 as NJ and .2.1 as PA.
>
[ [SR] ] Indeed, thanks, we will correct

>Section 10.6
>
>       "ipv4:192.0.2.0":     {".state": "PA"},
>
>As above, I think this has to be .2.1.
>
[ [SR] ] yes, thanks.  We will correct

>       "ipv4:192.0.3.0/28":  {".ASN": "65543",
>                              ".state": "TX"},
>       "ipv4:192.0.3.16/28": {".ASN": "65543",
>                              ".state": "MN"}
>
>These ASNs should be 65544.
>
[ [SR] ] yes, thanks. We will correct
>
>