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

[Erik Auerswald <[e-mail]>]

Hi,

On Sun, Apr 28, 2024 at 09:32:36AM -0700, C. M. Heard wrote:
> On Fri, Apr 26, 2024 at 2:18 AM Erik Auerswald wrote:
> > [...]
> >  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.

You are right, my suggested replacement is wrong.  I concur that the
paragraph should be deleted.

Best regards,
Erik