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]>]

Hi Benjamin,

Thanks a lot, no worries. Please find my responses inline.
Best regards,
Sabine

>-----Original Message-----
>From: Benjamin Kaduk <[e-mail]>
>Sent: Friday, January 28, 2022 5:23 AM
>To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay)
><[e-mail]>
>Cc: The IESG <[e-mail]>; [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
>
>Hi Sabine, all,
>
>Thanks for posting the -22, and my apologies for not having responded earlier
>to the thread -- there were a lot of things going on for me.
>I'm happy to say that the changes have addressed my discuss points, and I will
>go update my ballot position shortly.
>
>A few remaining notes inline...
>
>On Tue, Jan 25, 2022 at 01:34:06PM +0000, Randriamasy, Sabine (Nokia -
>FR/Paris-Saclay) wrote:
>> 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.
>
>Looking at this more carefully, I now think that what you describe here is
>correct.  Sorry for making the extra work for you due to my misunderstanding!
>
[ [SR] ] No problem

>> >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.
>
>This is okay to include, but in light of the above, not needed.  If you want to
>remove it again, I do not object.

[ [SR] ] Then, we will consider removing the sentence
>
>> >>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:
>
>Excellent, thank you for this and for propagating the change through the
>whole section.  (Doing a quick search for the string "country" in the -22, I see it
>appears in §10.6, but I have lost track of whether a
>country->countrycode replacement would be appropriat there or not.)
>

[ [SR] ] We will double check, thanks

>The rest of this all looks good.
>
>Many thanks,
>
>Ben
>
>> >>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
>> >>
>> >>
>>