Hi Benjamin, Thanks a lot, no worries. Please find my responses inline. Best regards, Sabine
>-----Original Message----- >From: Benjamin Kaduk <ka...@mit.edu> >Sent: Friday, January 28, 2022 5:23 AM >To: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ><sabine.randriam...@nokia-bell-labs.com> >Cc: The IESG <i...@ietf.org>; 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 > >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! > [ [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 >> >> >> >> >> _______________________________________________ alto mailing list alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
