Last Call Review of draft-ietf-tsvwg-udp-options-38
review-ietf-tsvwg-udp-options-38-genart-lc-sparks-2025-02-09-00

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<https://wiki.ietf.org/en/group/gen/GenArtFAQ>.

Document: draft-ietf-tsvwg-udp-options-38
Reviewer: Robert Sparks
Review Date: 2025-02-09
IETF LC End Date: 2025-02-10
IESG Telechat date: 2025-03-06

Summary: Ready (with nits) for publication as a Proposed Standard RFC

This is an exceptionally well-structured document. I appreciate the >>
convention for use of 2119 requirements.

Please check that this and the split out DPLPMTUD and this document are
consistent on this point? This document notes that "UDP itself never
automatically responds to a REQ with a RES", but that document discusses "an
implementation of DTPLMTUD within the UDP transport service".

This document notes that these options are intended for unicast use, and has a
"Multicast Considerations" section. Should that section also discuss Broadcast?
Or are there even more broadcast considerations that might warrant their own
section? Have discussions of using these options with DHCP already started?

The document asks IANA to restructure an existing registry (as a bit of a late
surprise - consider noting that it does so early in the document). I assume a
separate registry was considered, but taking this approach (requiring more work
from IANA) was deemed better. Consider a short discussion of the tradeoffs in
the document - its an opportunity for informing future working groups making
similar decisions.

There is a normative requirement in Appendix A. Can the exposition be
restructured so that it either isn't used, or appears outside the appendix?

There are three cases where the document uses "should be the minimum". Why are
these "should" not "SHOULD"?

Please skim the document for consistent pressure on the use of logging. There
are places where text says logging SHOULD be rate limited, and other places
that say some things MUST be logged.

Page 16 at "UNSAFE options MUST be used only with the FRAG option, in a manner
that prevents them from being silently ignored while still passing up
potentially modified UDP payload." There's a lot going on in this sentence -
could it be simplified, perhaps by splitting it into several sentences? Can you
point to the sources of potential modification of the payload here? Is it
correct to say (this isn't a proposal for the document text, just me making
sure I understand the sentence) "It is an implementation error to pass a UDP
payload up to higher layers if the UNSAFE options were present, but silently
ignored?" This is the only use of "passing up" in the document. There's one
other use of "passed up" which explicitly says "passed up to upper layers".
Consider adding that here, or otherwise being more precise.

Two blocks later at "Other than FRAG, each option SHOULD NOT occur more than
once in a single UDP datagram, the only exceptions being NOP, EXP, and UEXP."
Consider reworking this - it's structure is strange (other than "A" each letter
in the alphabet should not be used more than once, the only exceptions being
"B", "C", and "D").  Maybe discuss FRAG first and then NOP EXP and UEXP?Why is
this particular SHOULD NOT not a MUST NOT given the rest of the paragraph?

Is it possible (I think it is) that RES and REQ might both be present in a
single packet? If so consider noting that this is expected to occur.