Skip to main content

Simple Fixes to the IP Flow Information Export (IPFIX) Entities IANA Registry
draft-ietf-opsawg-ipfix-fixes-12

Yes

Mahesh Jethanandani

No Objection

Deb Cooley
Erik Kline
Gunter Van de Velde
Jim Guichard
Orie Steele
Paul Wouters

Note: This ballot was opened for revision 10 and is now closed.

Mahesh Jethanandani
Yes
Deb Cooley
No Objection
Erik Kline
No Objection
Gunter Van de Velde
No Objection
Jim Guichard
No Objection
John Scudder
No Objection
Comment (2024-07-10 for -11) Sent
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. :-(
Orie Steele
No Objection
Paul Wouters
No Objection
Roman Danyliw
No Objection
Comment (2024-07-09 for -11) Not sent
Thank you to Behcet Sarikaya for the GENART review.
Warren Kumari
No Objection
Comment (2024-07-09 for -11) Sent
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)/)
Zaheduzzaman Sarker
No Objection
Comment (2024-07-11 for -11) Not sent
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
No Objection
Comment (2024-07-05 for -10) Sent
# É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.