Ballot for draft-ietf-opsawg-ipfix-fixes
Yes
No Objection
No Record
Note: This ballot was opened for revision 10 and is now closed.
As an aside, I find the choice (not yours, long-standing) to keep the references to RFC 5102 in place in the IPFIX registry to be weird verging on problematic; it is probably too much scope creep to fix it in this document though. :-(
Thank you to Behcet Sarikaya for the GENART review.
Thank you to the authors for writing this document -- it looks like a necessary, but extremely un-fun to write doc. Also thanks to Qin Wu for the helpful Ops-Dir review (https://datatracker.ietf.org/doc/review-ietf-opsawg-ipfix-fixes-03-opsdir-early-wu-2023-12-25/) and to Med for addressing the comments. I'd like to add a further nit: Introduction: "When OPSAWG was considering ... " What is this OPSAWG of which you speak? (s/OPSAWG/Operations and Management Area Working Group (OPSAWG)/)
Thanks for working on this specification. My review didn't surface transport protocol related concerns. Thanks to Martin Duke for his TSVART review.
# É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.