Re: [tsvwg] WGLC for comments for draft-ietf-tsvwg-udp-options and draft-ietf-tsvwg-udp-options-dplpmtud to end 1st May 2024

["C. M. Heard" <[e-mail]>]

On Fri, Apr 26, 2024 at 2:18 AM Erik Auerswald wrote:

> Hi,
>
> I'd like to make two remarks regarding draft-ietf-tsvwg-udp-options-32:
>
>  1. There seems to be a small inconsistency at the end of section 24,
>     "Security Considerations":
>
>     The second to last paragraph starts with the sentence:
>
>      "Some UDP options are never passed to the receiving application,
>       notably FRAG, NOP, and EOL."
>
>     But the last paragraph of the same section uses SHOULD instead of
>     MUST for this:
>
>      "Such implementations SHOULD ensure FRAG, NOP, and EOL are not
>       passed to the receiving user[...]"
>
>     I would expect that "SHOULD" to be a "MUST" for any implementation,
>     please see below for reasons:
>

[ ... reasons snipped ... ]

I concur that this is an error, but I would go further: since FRAG,
NOP, and EOL are never passed to the receiving user/application,
just change the last sentence to:

   Such implementations SHOULD return options in an order not related
   to their sequence in the received packet.

Issue #56 <https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/56> has
been opened for this.

 2. I do not understand the "Note" in enumeration item 3 of the
>     fragmentation procedure in section 11.4, "Fragmentation (FRAG)"
>     on page 25:
>
>      "Note: per packet options can occur either at the end of the
>       original user data or be placed after the FRAG option of the
>       first fragment, with the Reassembled Datagram Option Start (RDOS)
>       in the terminal FRAG option set accordingly. This includes its
>       use in atomic fragments, where the terminal option is the initial
>       and only fragment."
>
>     How exactly would RDOS be set to indicate that the per-packet (a.k.a
>     per-datagram) options are located outside the reassembled datagram
>     after the FRAG option of the first fragment[, but before the fragment
>     data], in the case non-atomic fragments?  RDOS is a positive offset
>     from the start of the reassembled datagram (a.k.a. packet).
>
>     It seems to me as if this note should be deleted.  Alternatively,
>     it could be simplified to pertain only to atomic fragments, e.g.:
>
>       In atomic fragments, where the the terminal option is the initial
>       and only fragment, both per-fragment and per-datagram options
>       affect the same UDP payload.
>

Good catch! The updated text submitted to close Issue #2
<https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/2> had this
paragraph deleted; that change did not make it into the -23 draft.
My apologies for having missed that.

IMO the correct solution is to delete the whole paragraph, since there
are now explicit instructions on how to collect per-fragment options
and pass them to the user/application in the definition of each option.
Note that the definition of APC is such that it is not useful as a
per-fragment option, even in an atomic fragment; it must be sent as a
per-datagram option in order to be useful.

Issue #57 <https://github.com/tsvwg/draft-ietf-tsvwg-udp-options/issues/57>
has been opened for this.

Thanks for the review.

Mike Heard