Reviewer: Robert Sparks Review result: Ready with Nits 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. -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
