Re: [tsvwg] draft-ietf-udp-options issues from IETF 104

[Wesley Eddy <[e-mail]>]

On 7/11/2019 11:11 AM, Tom Herbert wrote:
>
>     Regarding soft-state coordination:
>     - Sec 13 already addresses the general notion of soft state in a
>     general sense.
>     - on 3/20/19, I noted on the list that soft state mechanisms are
>     not specified because each option might vary in how this is achieved
>     - if this isn’t sufficient, can you please clarify?
>
>
> It's not sufficient. The point of a protocol specification is to 
> describe how the protocol works, without normative requirements and 
> procedures there is no interoperability and no robustness.
>
> Consider the proposal that receivers could require optional checksums. 
> How would the sender know that it must use the checksum option for 
> some particular peer? This isn't magic, somehow the sender needs to 
> acquire information about the receiver. That's a protocol. It needs 
> some sort of negotiation, or probing, or other. And since UDP is 
> stateless "negotiation" may become obsolete so that fallbacks and 
> periodic renegotiation are needed which I assume is what you mean by 
> soft state. Furthermore, as reported, network devices in the path may 
> require the checksum. So the sender needs to consider how to deal with 
> that, and paths can similarly change so sender needs to be prepared 
> for that also.
>
> I suggest that you spell out the protocol for receivers requiring 
> checksums. I don't think the protocol for this is at all trivial, and 
> doing the exercise to specify the protocol may very well lead you to 
> the conclusion that it's far simpler to just put checksum in fixed 
> header as the designers of IP, TCP, and UDP already figured out.
>

The way I understand it, this is supposed to be handled by the 
application (or other protocol) on top of UDP.

Section 9 talks about how the API needs to be extended for the 
application to indicate receive options that are required, and which 
ones should be included on a sent datagram.

Maybe that section should also just explicitly say that the application 
protocol (either by its definition or in its signalling) is supposed to 
work out compatible sets of sent and received options, based on what the 
application needs.  I think that would solve the question you raise.