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

[Joe Touch <[e-mail]>]

> On Jan 5, 2020, at 12:48 PM, C. M. Heard <[e-mail]> wrote:
...
> 
> 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".

As I just posted, at best it would mean “if the following option is not recognized, drop all options”. It should never mean anything else.

Any application that cannot tolerate zero-length messages should never use those options. Any app that handles zero-length options should then work on hosts that support or do not support options that way.

> 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

Now you’re getting into issues we cannot; it’s all or nothing:

- all options in the regular space MUST individually be ignored if not supported
- options in the 253-codepoint space would then cause the options - as a whole - to be dropped
	if you just wanted the option to be dropped, then the regular code point space would have been sufficient

Again, we cannot cause the PACKET to be dropped. If the packet contains regular data, it MUST be delivered to the application.

It is up to the receiving application to decide what to do. A receiving app that wants to enforce authentication would drop the packet THEN. UDP cannot.

> 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.

As noted in the proposal, this would a a *separate* code point space, but agreed, there would be an experimental value there too.

Joe