[tsvwg] Re: Shepherd review for draft-ietf-tsvwg-udp-options-36

[Erik Auerswald <[e-mail]>]

Hi Gorry,

I think that two of your change requests would make the document worse
instead of improving it.  Please see below ("inline") for details.

On Fri, Sep 27, 2024 at 01:18:59PM +0100, Gorry Fairhurst wrote:
> [...]
> I have the following requests for changes:
> [...]
> 6. OLD:
> SAFE UDP options can be silently ignored by legacy receivers without
>    affecting the meaning of the UDP user data.
> New:
> SAFE UDP options are, by default, silently ignored by legacy
> receivers without
> affecting the meaning of the UDP user data, unless configured to
> process the option.
> —  The current crisp definition troubles me a little, as  to what is
> the UDP receiver, is it the options processing or the application?
> The discussion around AUTH demonstrated that this simple statement
> can be quite difficult to understand.
> I think we ought we to say this is the default.

By definition, a legacy receiver can only ignore UDP options, it cannot
be configured to process them.  That makes a legacy receiver a legacy
receiver.  Thus the requested change is at least misleading.

> [...]
> 19. Section 15, API.
>  I would strongly encourage making all API description
> non-normative, and moving to an appendix. The recent trend - in
> protocols such as SCTP, is to define the appendix in a non-normative
> annexe. This can be included as a part of a PS and avoids any
> discussion of whether this specific API needs to be implemented - or
> one defined by POSIX, etc or a different IETF interface such as
> TAPS.

As far as I can tell, all API descriptions concern functionality
that is required to actually use UDP options.  One such addition,
enabling to set the size of the datagram to add padding, is required for
draft-ietf-tsvwg-udp-options-dplpmtud to work.

Making these descriptions non-normative would encourage to claim support
for UDP options without actually enabling the use of UDP options.  I do
not think the IETF should publish Standards Track specifications that
allow implementations that cannot work to conform to the specification.

> [...]

Thanks,
Erik