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,

We have posted a revision that addresses the DISCUSS points raised in your review, together with the related COMMENTS on section 10. 
Please see inline the e-mail below for the proposed updates. 
The other comments will be addressed in a next revision. 
Again thank you for your thorough review and guidance. 
Best regards,
Sabine and co-authors


>-----Original Message-----
>From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
><[e-mail]>
>Sent: Tuesday, December 21, 2021 3:23 PM
>To: Benjamin Kaduk <[e-mail]>; The IESG <[e-mail]>
>Cc: [e-mail]; [e-mail];
>[e-mail]; Vijay Gurbani <[e-mail]>
>Subject: RE: Benjamin Kaduk's Discuss on draft-ietf-alto-unified-props-new-21:
>(with DISCUSS and COMMENT) - DISCUSS + COMMENTS on section
>
>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
>>
>>