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) > ><sabine.randriam...@nokia-bell-labs.com> > >Sent: Tuesday, December 21, 2021 3:23 PM > >To: Benjamin Kaduk <ka...@mit.edu>; The IESG <i...@ietf.org> > >Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org; > >alto@ietf.org; Vijay Gurbani <vijay.gurb...@gmail.com> > >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 <nore...@ietf.org> > >>Sent: Thursday, December 2, 2021 12:00 AM > >>To: The IESG <i...@ietf.org> > >>Cc: draft-ietf-alto-unified-props-...@ietf.org; alto-cha...@ietf.org; > >>alto@ietf.org; Vijay Gurbani <vijay.gurb...@gmail.com>; > >>vijay.gurb...@gmail.com > >>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 > >> > >> > _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto