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

[Joe Touch <[e-mail]>]

> On Jan 5, 2020, at 3:28 PM, Tom Herbert <[e-mail]> wrote:
> 
> On Sun, Jan 5, 2020 at 1:57 PM Joe Touch <[e-mail]> wrote:
>> 
>> ...
>> It is TCP SYNs. They have to be interpreted without context.
> 
> TCP SYNs is the best you could come up with? One small part of a
> protocol that typically doesn't carry user data, doesn't work with
> multicast and is part of a stateful protocol 3WHS. Nope, IPv6 is the
> better model.

TCP SYNs are transport and stateless. Yes, they’re the right model.

IPv6 is largely designed for intermediate devices - that’s not what we’re designing for here.

>> ...
>> First, it fails to be motivated by an example.
>> 
> Encryption option.

We already have a solution for that with FRAG+LITE.

Is there any example of a packet whose contents aren’t modified but MUST NOT be accepted if the option fails?

>> ...
>> Fail. That causes the same packet to be silently dropped by option-aware receivers and received as zero-length by legacy receivers.
> 
> There is no such requirement.

I’m claiming there should be a requirement to behave the same in these cases and I explained why.

> And as I pointed out if there were the
> draft would need to be changed to eliminate all cases where packets
> are dropped on error since that too  "causes the same packet to be
> silently dropped by option-aware receivers and received as zero-length
> by legacy receivers."

I already said that text was being changed. 

...
> 
>> 
>>> - If an option is received with [he needed signal]
>> 
>> (again, the rest of this sentence is implementation, not requirement)
>> 
>>> and the receiver does not recognize the option,
>>> then the packet MUST be dropped.
>> 
>> Same problem. Different behavior for legacy and option-aware.
> 
> Same response. Show me the requirement established by consensus of the
> WG that this violates.

We’re designing a system that has to work with legacy receivers. Having two distinctly different behaviors in those cases creates protocol complexity. 

> 
>> 
>> Declaring that an option CANNOT BE IGNORED affects ONLY THAT OPTION. We can decide to make it trash all other options, but we can’t make it drop a packet as a whole.
>> 
> The whole point of an option that cannot be ignored is that it is
> incorrect to process the packet if ignored.

The whole point is that it is incorrect to process the OPTIONS if ignored. Not the packet We can’t claim that it’s incorrect to process a packet if options are ignored - exactly because that’s what legacy receivers already do.

Joe