Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-tsvwg-udp-ipfix-12: 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/about/groups/iesg/statements/handling-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-opsawg-tsvwg-udp-ipfix/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tsvwg-udp-ipfix-12 Thank you for the work put into this document. Thanks to Joe Touch for his int-dir reviews but also kudos to the authors for reacting to Joe's issue about the SAFE/UNSAFE split and the normative reference to draft-ietf-opsawg-ipfix-tcpo-v6eh. The I-D is now in much better shape. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Thomas Graf for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric # COMMENTS (non-blocking) ## Link to draft-ietf-tsvwg-udp-options There is a normative reference to draft-ietf-tsvwg-udp-options, so all is good, but it might have been better to wait for draft-ietf-tsvwg-udp-options rather than having to review this I-D without knowing what will be the published specification of UDP options. ## Section 1 s/widely deployed in *operators* networks/widely deployed in networks/ IPFIX is largely deployed outside of operators (in the sense if (I)SP) ;-) s/The IE specified in Section 4.1 uses the new abstract data type defined/The IE specified in Section 4.1 uses the new abstract data type *unsigned256* defined/ ? ## Section 3 While is it nice for the reader to have a short description of UDP options, it does not say anything about "Kind" as in `Options indicated by Kind values`... So, the reader must anyway read the UDP options draft. Suggest adding a short description of the Kind. ## SAFE or safe This document uses both "safe" and "SAFE" for what seems the same concept. Please select one writing everywhere to reduce confusion. ## Use of MUST w/o BCP14 There are a couple of "MUST" and "MUST NOT" in the text without any BCP14 template. This is OK, but the "MUST" is then equivalent to a "must", so suggest either using only lower case "must" or including BCP14 template. The lowercase "must" is anyway normative as it is part of a Proposed Standard but somehow less defined as the BCP14 "MUST". ## Section 4.1 s/The bit is set to 1 if the corresponding safe UDP option is observed in the Flow/The bit is set to 1 if the corresponding safe UDP option is observed *at least once* in the Flow/ s/The bit is set to 0 if the option is *not* observed in the Flow./The bit is set to 0 if the option is *never* observed in the Flow./ Same comment for the unsafe options in section 4.2 What about "UDP option extended format" ? I.e., where the Kind is expressed over 2 octets. Suggest adding some text restricting the use of this I-D to only "normal 1-octet Kind". ## Section 4.3 I am afraid that I do not understand what value to use based ont the Description. Are the only allowed values: 127 and 254 ? _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
