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

[Joe Touch <[e-mail]>]

Updating the subject line...

> On Jul 10, 2019, at 8:56 PM, Tom Herbert <[e-mail]> wrote:
> ...
> So it took the better part of a day and quite a few emails to conclude that the only remaining issue in this proposal is one that we’ve already discussed at length.
> 
> Hardly the only remaining issue if you're referring to UDP options.

> Please look at minutes from last IETF. Both the subject of disambiguation of surplus space
> as well as negotiation of UDP options was raised (i.e. if the receiver requires checksum how
> does sender know that). I haven't seen these addressed by UDP options draft at least…

If you review the minutes from IETF 104, you will note that the next steps were yours and QUICs, not mine.

But let me jump in:

- regarding other uses of the option space:
	- as I’ve already noted in this thread, this was discussed on this list long before IETF 104
	- past uses (if there are any) would be protected (if necessary) by use of OCS (when OCS is used)
	- future uses need not be differentiated independently; they should be using the UDP option code points instead

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?

Regarding use of options with encrypted transports:
	- I don’t know what “encrypted transports” means
	- UDP options includes AE, which is encryption and compatible with UDP options
	- transport *payload* encryption is independent of transport encryption and should have no impact on UDP AE
	- nobody from QUIC has contacted me on this issue

Joe