Re: [Int-dir] Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-03

["[e-mail]" <[e-mail]>]

Please see below.

—
Dr. Joe Touch, temporal epistemologist
www.strayalpha.com

> On Jan 15, 2024, at 12:26 AM, [e-mail] wrote:
> 
> Hi Joe, 
> 
> Thanks for the review. 
> 
> Please see inline. 
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Joseph Touch via Datatracker <[e-mail]>
>> Envoyé : samedi 13 janvier 2024 05:03
>> À : [e-mail]
>> Cc : [e-mail];
>> [e-mail]
>> Objet : Intdir early review of draft-ietf-opsawg-tsvwg-udp-ipfix-
>> 03
>> 
>> Reviewer: Joseph Touch
>> Review result: Ready with Issues
>> 
>> This review is performed as part of the INTAREA cross-area
>> review.
>> 
>> There do not appear to be any INTAREA issues in this document.
>> 
>> NOTE: as author of the UDP options on which this document is
>> based, I have some other concerns noted below, which are the
>> "issues" indicated in the review result (ready with issues).
>> 
>> There are some misconceptions about UDP options that should be
>> corrected in this document:
>> 
>> Regarding SAFE options:
>> -       “Such options can be silently ignored by receivers
>> without affecting
>> the meaning of the UDP user data” -       Should be “Such options
>> can be
>> silently ignored by legacy receivers because they do not alter
>> the UDP user data”
>> 
>> Regarding UNSAFE options:
>> -       “Such options are not safe to ignore”
>> -       Should be “Such options are not safe tor legacy receivers
>> to ignore
>> because they alter the UDP user data”
>> 
> 
> [Med] Fixed.

It would be useful to use a consistent phrase to describe the "UDP user data" (e.g., as per your Fig 1), i.e., rather than also “UDP data payload”.

> 
>> The document should be more clear that UDP options occur per-
>> packet within a flow and can be introduced at any time in the
>> flow (unlike TCP).
> 
> [Med] Added a new statement to echo this. The export process covers any option that is observed in a flow.
> 
>> 
>> Sec 4.1 needs to indicate use of a field with 256 possible
>> values; it currently is defined for only 32 or 64 values.
>> 
>> 
> 
> [Med] 32/64 are provided as examples to illustrate the use of reduced encoding. The full 256 range is covered in the spec. Thanks. 

“Unsigned” without numeric qualifiers is not an IPFIX data type, per RFC7011 Sec 6.1.1.

Sec 6.2 indicates the specific encoding types where reduced encoding applies, and also uses unsigned only with numeric qualifiers.

Joe