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

[Benjamin Kaduk <[e-mail]>]

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!

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

> >>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.)

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