Skip to main content

Early Review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

Request Review of draft-ietf-opsawg-tsvwg-udp-ipfix
Requested revision No specific revision (document currently at 10)
Type Early Review
Team Transport Area Review Team (tsvart)
Deadline 2024-01-08
Requested 2023-12-18
Requested by Joe Clarke
Authors Mohamed Boucadair , Tirumaleswar Reddy.K
I-D last updated 2024-01-02
Completed reviews Genart Last Call review of -08 by Robert Sparks (diff)
Secdir Last Call review of -08 by Watson Ladd (diff)
Tsvart Last Call review of -07 by Tommy Pauly (diff)
Intdir Last Call review of -08 by Dr. Joseph D. Touch (diff)
Tsvart Early review of -03 by Tommy Pauly (diff)
Intdir Early review of -03 by Dr. Joseph D. Touch (diff)
Assignment Reviewer Tommy Pauly
State Completed
Request Early review on draft-ietf-opsawg-tsvwg-udp-ipfix by Transport Area Review Team Assigned
Posted at
Reviewed revision 03 (document currently at 10)
Result Almost ready
Completed 2024-01-02
Thanks for writing a clear and succinct draft. I only found one issue of note,
around the registration of the new udpOptions Information Element.

Section 4.1:
The data type used for the “udpOptions” entry is just listed as “unsigned”, and
is described as being either an unsigned32 or an unsigned64. However, when I
look at the registry at, I
don’t see any entries that use this abstract “unsigned” type, and it is not
listed as an option in the element data types. Is there a reason this shouldn’t
just be registered as an unsigned64? My understanding from is that an unsigned64 can be
automatically encoded as an unsigned32 if the value is small enough, so the
definition can just use unsigned64.