Thanks for the explanation!

RjS

On 2/9/25 5:01 PM, C. M. Heard 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

Reply via email to