Re: [tsvwg] New Version Notification for draft-herbert-udp-space-hdr-01.txt

[Joe Touch <[e-mail]>]

On 2019-07-10 16:24, Tom Herbert wrote:

> On Wed, Jul 10, 2019 at 3:49 PM Joe Touch <[e-mail]> wrote: 
> 
>> ...
>> 
>> In summary, please look at the current draft and note that OCS is now 3 bytes. That is incorrect in the table (we already noted that on the list; it's in the next round of opdates) but not in the text of the OCS section.
> Actually, there are two places that say it is a one byte checksum:
> 
> +--------+--------+
> | Kind=2 |checksum|
> +--------+--------+
> 
> 2*      2         Option checksum (OCS)

The first one doesn't "say" anything per se, but yes, it could be
extended to make it more clear. As I noted, this was mentioned already
on the list and is on the pending items. 

> Assuming that this is supposed to be a two byte checksum:
> 
> 1) An optional checksum cannot protect against corruption of the type
> field containing the option. I've have mentioned this several times
> and there has never be a reasonable response as to why this isn't a
> problem

It's a choice, just as whether to use checksums in IPv4 UDP. It's the
user's choice and it saves bytes when not desired. The default is to use
it, though. 

> 2) The checksum option is at least three bytes, or four bytes if
> alignment is required. A fixed checksum only consumes two bytes.

Yes, and we've been around that block before too. A fixed checksum could
take 2-4 bytes too - due to the same alignment issues. So we're talking
about 1 byte and the design is based on the principle that ALL options
are optional in UDP - there is no "default" header. 

> 3) A fixed checksum disambiguates uses standard uses from legacy uses
> of the surplus space. An optional checksum doesn't help with that.

Yes, it does. Optionally. However, note that we still have exactly ZERO
legacy uses discovered. And if - or when - we get comfortable with that,
it can be optionally omitted. 

Joe