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
