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,

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:

    - Section 11.1, "End of Options List (EOL)", does not specify if EOL
      is passed to the user or not (perhaps that should be added there?).

    - Section 11.2, "No Operation (NOP)", specifies:

       "NOPs are not reported to the user"

    - Section 11.4., "Fragmentation (FRAG)", specifies:

       "FRAG is not reported to the user[...]"

    - Section 14., "Option inclusion and processing", notes:

       "Note that FRAG, NOP, and EOL are not passed to the user (see
        Section 15)."

    - Section 15, "UDP API Extensions", specifies:

       "Options and their processing status (success/fail) MUST be
        available to the user [...] except for FRAG, NOP, and EOL; those
        three options are handled within UDP option processing only."


 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.

Thanks,
Erik

P.S. While I have read version draft-ietf-tsvwg-udp-options-32, I have
     not performed a thorough review.


On Wed, Apr 24, 2024 at 08:02:12PM +0100, Gorry Fairhurst wrote:
> This is a reminder of the on-going 3 weeks WG Last Call to determine if the
> following TSVWG IDs are ready:
> 
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/
> https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options-dplpmtud/
> 
> These documents both target PROPOSED STANDARD.
> 
> The document shepherd for the UDP Options will be: Gorry Fairhurst.
> The document shepherd for DPLPMTUD with UDP Options will be: Marten Seemann.
> 
> The WGLC will end at midnight UTC on 1st May 2024.
> 
> Please do read the drafts, and please do send any comments/concerns
> to  the TSVWG mailing list, including notes on whether these are
> ready to publish (or send an email directly to the
> chairs<[e-mail]>).
> 
> Best wishes,
> Gorry and Marten
> (tsvwg co-chairs)
> 
> —
> 
> The IETF WG Last Call process is described in RFC 6174.
>