Hi, Ben: I would like to ping your feedback on Sabine's response, thanks in advance. The new version will come soon after getting your feedback.
-Qin (On behalf of chairs) -----邮件原件----- 发件人: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) [mailto:sabine.randriam...@nokia-bell-labs.com] 发送时间: 2021年12月21日 22:23 收件人: Benjamin Kaduk <ka...@mit.edu>; 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> 主题: 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. 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 alto@ietf.org https://www.ietf.org/mailman/listinfo/alto
