Re: [tsvwg] Rregarding soft-state and UDP options

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

On Fri, Jan 3, 2020 at 8:36 PM Joe Touch <[e-mail]> wrote:

> Lost in this discussion has been an example to motivate the need for “drop
> if not supported”.
>
[ ... ]

> Right now, until there is consensus otherwise, there isn’t justification
> to waste half the code point space on  hypotheticals. However, there’s no
> reason not to assign ONE code point for such use, e.g., as follows:
>
>         option 253 — defined as a prefix to “required options” code
> points, the next byte defines that code point
>         (these would be assigned as needed and have no relation to the UDP
> option code point values)
>
> That way there’s support for the *remote* possibility that this feature
> can be useful without wasting space needlessly - and, as importantly,
> avoiding the impression that “flipping a bit” can change any option from
> “optional” to “required”.
>

In an earlier quick read I missed this proposal. My apologies for not
reading the message carefully and thereby adding unnecessary noise to this
discussion.

Under the assumption that implementations of UDP options will be required
to ***recognize*** (but not necessarily to implement) all of the options
defined in the initial version of the specification, this proposal
will accomplish
the goal that I had in mind when I proposed to subdivide the Option Kind
space into two ranges, one for options that do not affect the handling of
user data ("this option is safe to ignore") and another for options that do
affect the handling of user data. ("this option is not safe to ignore").

I would suggest that the semantics of the prefix should be "if you don't
recognize the following option, don't deliver the accompanying payload data
to the user". I'm open to discussion as to whether a socket read should
signal a zero-length datagram and whether delivery of other options in the
packet should be suppressed.

I'll note in passing that the prefix could appear in front of the
experimental option code point in order to indicate an experimental option
that is not safe to ignore.

Thanks,

Mike Heard