Hi, Robert, Thanks for the detailed feedback - I created one issue in our Github for each paragraph below, except that I also split the two issues in the second major paragraph (DHCP seems separate from broadcast).
We’ll address these in the Github repository directly. Joe — Dr. Joe Touch, temporal epistemologist www.strayalpha.com > On Feb 9, 2025, at 1:38 PM, Robert Sparks via Datatracker <nore...@ietf.org> > wrote: > > 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-c...@ietf.org > To unsubscribe send an email to last-call-le...@ietf.org
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
