Export of UDP Options Information in IP Flow Information Export (IPFIX)
draft-ietf-opsawg-tsvwg-udp-ipfix-14

I agree w/ Eric V on the timing of this publication with respect to the publication of draft-ietf-tsvwg-udp-options.  Since this draft will sit in the editor's queue, why not do them together?

I support Roman's discuss and Eric's comments. Personally, I think I would have omitted Section 3 entirely and just pointed to I-D.ietf-tsvwg-udp-options

Thank you to Robert Sparks for the GENART review.

Thank you for writing this document. Also thank you to Jouni Korhonen for the Ops-Dir review (https://datatracker.ietf.org/doc/review-ietf-opsawg-tsvwg-udp-ipfix-10-opsdir-lc-korhonen-2024-05-21/) and the excellent catch in it.

I support Roman's DISCUSS as well.

Thanks for discussing my discuss points. As wrote in the email I moved one clarification point to comment here.

> Another discussion - as this specification is based on
> draft-ietf-tsvwg-udp-options, that draft already defines number
> of Kind values
> for SAFE and UNSAFE options then why we are not defining IEs for
> them?
>

>[Med] Not sure to get your point. We do have IEs that can exports kinds for both SAFE and UNSAFE. We used to have these in one single IEn but abandoned that design because it was suboptimal for an encoding compactness perspective.

>I see, then it was not that clear that we are abandoned that desing in favour of encoding effiency. I think it would need  some backgoround and rational on that to clarify the design choice. 



I also believe publication of this draft should have been waited to be publised along with or after draft-ietf-tsvwg-udp-options and I strongly suggest that.

I also support Roman's comment that kind of echos why I have my previous comment on waitning on publication.

# Éric Vyncke, INT AD, comments for draft-ietf-opsawg-tsvwg-udp-ipfix-12

Thank you for the work put into this document.

Thanks to Joe Touch for his int-dir reviews but also kudos to the authors for reacting to Joe's issue about the SAFE/UNSAFE split and the normative reference to draft-ietf-opsawg-ipfix-tcpo-v6eh. The I-D is now in much better shape.

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

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)

## Link to draft-ietf-tsvwg-udp-options

There is a normative reference to draft-ietf-tsvwg-udp-options, so all is good, but it might have been better to wait for draft-ietf-tsvwg-udp-options rather than having to review this I-D without knowing what will be the published specification of UDP options.

## Section 1

s/widely deployed in *operators* networks/widely deployed in networks/ IPFIX is largely deployed outside of operators (in the sense if (I)SP) ;-)

s/The IE specified in Section 4.1 uses the new abstract data type defined/The IE specified in Section 4.1 uses the new abstract data type *unsigned256* defined/ ?

## Section 3

While is it nice for the reader to have a short description of UDP options, it does not say anything about "Kind" as in `Options indicated by Kind values`... So, the reader must anyway read the UDP options draft. Suggest adding a short description of the Kind.

## SAFE or safe

This document uses both "safe" and "SAFE" for what seems the same concept. Please select one writing everywhere to reduce confusion.

## Use of MUST w/o BCP14

There are a couple of "MUST" and "MUST NOT" in the text without any BCP14 template. This is OK, but the "MUST" is then equivalent to a "must", so suggest either using only lower case "must" or including BCP14 template. The lowercase "must" is anyway normative as it is part of a Proposed Standard but somehow less defined as the BCP14 "MUST".

## Section 4.1

s/The bit is set to 1 if the corresponding safe UDP option is observed in the Flow/The bit is set to 1 if the corresponding safe UDP option is observed *at least once* in the Flow/

s/The bit is set to 0 if the option is *not* observed in the Flow./The bit is set to 0 if the option is *never* observed in the Flow./

Same comment for the unsafe options in section 4.2

What about "UDP option extended format" ? I.e., where the Kind is expressed over 2 octets. Suggest adding some text restricting the use of this I-D to only "normal 1-octet Kind".


## Section 4.3

I am afraid that I do not understand what value to use based ont the Description. Are the only allowed values: 127 and 254 ?