Skip to main content

Early Review of draft-ietf-opsawg-tsvwg-udp-ipfix-03
review-ietf-opsawg-tsvwg-udp-ipfix-03-tsvart-early-pauly-2024-01-02-00

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 https://mailarchive.ietf.org/arch/msg/tsv-art/Dz9T8NbgpbrDcOXYZN6uYCgMJuM
Reviewed revision 03 (document currently at 10)
Result Almost ready
Completed 2024-01-02
review-ietf-opsawg-tsvwg-udp-ipfix-03-tsvart-early-pauly-2024-01-02-00
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 https://www.iana.org/assignments/ipfix/ipfix.xhtml, 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
https://www.rfc-editor.org/rfc/rfc7011#section-6.2 is that an unsigned64 can be
automatically encoded as an unsigned32 if the value is small enough, so the
definition can just use unsigned64.