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) ><[email protected]> >Sent: Tuesday, December 21, 2021 3:23 PM >To: Benjamin Kaduk <[email protected]>; The IESG <[email protected]> >Cc: [email protected]; [email protected]; >[email protected]; Vijay Gurbani <[email protected]> >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 <[email protected]> >>Sent: Thursday, December 2, 2021 12:00 AM >>To: The IESG <[email protected]> >>Cc: [email protected]; [email protected]; >>[email protected]; Vijay Gurbani <[email protected]>; >>[email protected] >>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 >> >> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
