Bonjour Sabine, Thank you for revision -21, it addresses all my previous non-blocking comments.
Have a nice WE! Regards -éric On 26/11/2021, 14:57, "Randriamasy, Sabine (Nokia - FR/Paris-Saclay)" <[email protected]> wrote: Hello Éric, A new version has been posted to address your comments. We hope the updates meet your expectation and will like to have your feedback. Best regards, Sabine and co-authors The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-alto-unified-props-new/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-alto-unified-props-new-21 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-alto-unified-props-new-21 >-----Original Message----- >From: Randriamasy, Sabine (Nokia - FR/Paris-Saclay) ><[email protected]> >Sent: Thursday, November 25, 2021 2:29 PM >To: Éric Vyncke <[email protected]>; The IESG <[email protected]> >Cc: [email protected]; [email protected]; >[email protected]; Vijay Gurbani <[email protected]> >Subject: RE: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new- >20: (with COMMENT) > >Hello Éric, > >Thanks a lot for your review and comments. >Please find our answers inline. >A version 21 is under edition and will integrate the changes upon your >feedback. > >Best regards, >Sabine and co-authors > >>-----Original Message----- >>From: Éric Vyncke via Datatracker <[email protected]> >>Sent: Monday, November 22, 2021 11:01 AM >>To: The IESG <[email protected]> >>Cc: [email protected]; [email protected]; >>[email protected]; Vijay Gurbani <[email protected]>; >>[email protected] >>Subject: Éric Vyncke's No Objection on draft-ietf-alto-unified-props-new-20: >>(with COMMENT) >> >>Éric Vyncke has entered the following ballot position for >>draft-ietf-alto-unified-props-new-20: No Objection >> >>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/ >> >> >> >>---------------------------------------------------------------------- >>COMMENT: >>---------------------------------------------------------------------- >> >>Thank you for the work put into this document. >> >>Please find below some non-blocking COMMENT points (but replies would >>be appreciated even if only for my own education), and some nits. >> >>Special thanks to Vijay Gurbani for the shepherd's extended write-up >>about the WG consensus (even if not using the usual template). >> >>While the document supports clearly the two address families (IPv4 and >>IPv6), I can only regret that the vast majority of examples are for IPv4. >> >>I hope that this helps to improve the document, >> >>Regards, >> >>-éric >> >>== COMMENTS == >> >>While the documents is very detailed, I would have preferred to have a >>generic introduction of the concepts at the beginning. It also seems to >>me that part of the text is repetitive. > >[ [SR] ] The Introduction indeed, lists features such as entity, entity domain >and its type, resource specific entity domain, Filtered/Property map, that are >introduced at high level w.r.t. how they address the limitations of the current >protocol. > >The generic introduction of the concepts is provided right after the >Introduction, in the 4 pages Section 3. "Basic Features of the Entity Property >Map Extension". Section 3, in its introduction, also references a table that >summarizes all the features introduced by this extension, in the paragraph >below: >"The Entity Property Maps extension described in this document introduces a >number of features that are summarized in Appendix A, where Table 4 lists >the features and references the sections in this document that give a high- >level and normative description thereof." > >Do you think it would be helpful to move this paragraph to Section >1.Introduction, just before its last paragraph? >> >>-- Section 3.1 -- >>I am a little puzzled by the use of "TCP/IP network flow" as it mixes up layers. >>Also, the "associated 5-tuple" is redundant because TCP has always 6 as >>protocol so it is not really a 5-tuple as one is constant. >> >[ [SR] ] We propose to update item 5 as follows: >OLD >a TCP network flow, that is identified by a TCP 5-Tuple specifying its source >and destination addresses and port numbers and the utilized protocol, NEW a >TCP/UDP network flow, that is identified by a TCP/UDP 5-tuple specifying its >source and destination addresses and port numbers and the IP protocol > >>-- Section 4.6.1 -- >>The use of "ane" is done before its explanation later in section 4.6.2. >> >[ [SR] ] As citing "ane" does not add anything to understand the point, we >propose to remove it. >We propose to update sentence in parag 2 as follows: >OLD >... >This is useful for entity domain types that are by essence domain-specific, >such as "pid" and "ane" domain types. >... >NEW >... >This is useful for entity domain types that are by essence domain-specific, >such as the "pid" domain type. >... > >>-- Section 5.1.3 -- >>"net1.ipv6:2001:db8::1/48" is probably not an address block as it is a >>/128 address. >[ [SR] ] Thanks for catching this typo. We propose to replace >"net1.ipv6:2001:db8::1/48" with "net1.ipv6:2001:db8::/48". >> >>-- Section 10.4 (and possibly others) -- Please use RFC 5398 when using >>ASN in examples. >> >[ [SR] ] following section "4. IANA Considerations" of https://www.rfc- >editor.org/rfc/pdfrfc/rfc5398.txt.pdf, >we will use either of the 64496 - 64511 and 65536 - 65551 blocks reserved by >IANA for documentation purposes. > >Example ASN numbers 12345 and 12346 will be replaced with 65543, 65544 > >>-- Section 10.9 -- >>Is the JSON reply valid ? >> >[ [SR] ] Indeed, the property values are not to be exposed with their units, >thanks a lot for this catch. >The units will be removed and the reply will look like: >OLD >..... >{"storage-capacity" : 40000 Gbytes, "cpu" : 500 Cores}, ..... >NEW >..... >{"storage-capacity" : 40000, "cpu" : 500}, > >>-- Section 13 -- >>No hard feeling but I find it strange that the acknowledgements section >>also includes some affiliations. >> >[ [SR] ] we will remove the affiliations > >>== NITS == >> >>-- Section 10.1 -- >>RFC 5792 prefers ipv6:::/0 to ipv6:::0/0 >> >[ [SR] ] Thanks a lot for catching this typo We will replace " ipv6:::0/0" with " >ipv6:::/0" in the examples >> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
