Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ipfix-fixes-10: 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-ipfix-fixes/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-opsawg-ipfix-fixes-10 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 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) ## Abstract Section 1 Suggest using the full name of the IANA registry "IP Flow Information Export (IPFIX) Entities" (i.e., with "Entities" at the end). ## Section 1 Be more assertive in a PS: s/This document intends to update /This document updates / ## Section 4.3.2 Is it the "first" or "least-significant" byte in `A structure is currently associated with the first byte.`? Can only regret using the IPv4 terminology in 2024 as in `Bad TTL` rather than "Bad Hop-Limit/TTL" (would also suggest using "expired" as I do not know what a "bad" hop-limit is). I understand that this would require changing https://www.iana.org/assignments/ipfix/ipfix.xhtml#forwarding-status but why not doing it in the same "fix I-D" ? I would assume that Forwarding-Status should be a normative reference. ## Section 6.10.2 RFC 3022 does not contain the word "NAT44" so it cannot be a reference for NAT44 ;-) You may want to use "See [RFC3022] for the definition of NAT (commonly named NAT44)" or similar. BTW, thanks for fixing NAT66 into NPTv6 ;-) ## Sections 6.23.2 and 6.24.2 Suggest removing the reference to RFC 791 & 3234 as they are neither related to NAT nor used in the IANA registry. # NITS (non-blocking / cosmetic) ## Section 5 I am just puzzled by the order of the rows in table 1, it looks neither logical nor alphabetical. _______________________________________________ OPSAWG mailing list -- opsawg@ietf.org To unsubscribe send an email to opsawg-le...@ietf.org
