Hello Robert, Here is the proposed clarification of the paragraph restricting UNSAFE options to use with FRAG. Please let us know if it addresses the issue that you raised. <https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/84>
OLD: >> 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. This ensures their safe use in environments that might include legacy receivers (see Section 12), because the UDP payload occurs inside the FRAG option area and is silently discarded by legacy receivers. NEW: >> When UNSAFE options are present, the UDP user data MUST be empty, and any transport payload MUST be contained in a FRAG option (see Section 11.4). Recall that such options may alter the transport payload or signal a change in what its contents represent. This restriction ensures their safe use in environments that might include legacy receivers (see Section 12), because the transport payload occurs inside the FRAG option area and is silently discarded by legacy receivers. Respectfully, Mike Heard On Sun, Feb 9, 2025 at 3:01 PM C. M. Heard <he...@pobox.com> wrote: > Greetings, > > Many thanks for the review. The principal author and I will work > to get these issues into the github tracker > <https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues> and > addressed. > > Before doing that I would like to address this point: > > On Sun, Feb 9, 2025 at 1:38 PM Robert Sparks wrote: > >> Reviewer: Robert Sparks >> Review result: Ready with Nits >> [ ... ] >> 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. > > > Irrespective of whatever other changes are done, we clearly need to > add a forward reference to Section 11.4, which explains why it is > necessary to limit the use of FRAG and any options in the UNSAFE range > to UDP packets whose user data field is empty (UDP Length == 8). The > explanation is in the paragraph that starts at the bottom of page 21 > and ends at the top of page 22. > > The issue is not that it is an implementation error to pass a UDP > payload up to higher layers if the UNSAFE options are present, but > silently ignored, but rather that a legacy implementation cannot > avoid doing that if FRAG or any UNSAFE options are present in a > packet with a non-empty UDP user data field. So we are telling > implementations of UDP Options not to do that. > > I hope that this clarifies the intent. Stay tuned for text. > > Mike Heard >
_______________________________________________ Gen-art mailing list -- gen-art@ietf.org To unsubscribe send an email to gen-art-le...@ietf.org
