Re: [tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions

[Joe Touch <[e-mail]>]

I omitted the note for this one:

On 9/1/2019 11:16 AM, Joe Touch wrote:
> Section 3 - OLD:
>     Reserved for future use.  Must be zero in generated segments and
>     must be ignored in received segments, if corresponding future
>     features are unimplemented by the sending or receiving host.
> - why is this not an RFC2119 requirement to set and check the reserve fields, this
> would seem much more normal and the receiver behaviour at least is required?

In this case, because the intent is that legacy will silently ignore its
use in future variants (future uses will be optional). That's not the
only choice, though.

i.e.,:

In general, fields reserved for future use have the following properties:

    MUST be set by non-participating (legacy) transmitters to a known
value (zero, typically)

depending on use, one of the following two MUST be selected *at initial
design time*:

a) for fields that are intended to be optional to legacy variants:

    legacy receivers MUST ignore the field value

b) for fields that are intended to be required in future variants:

    legacy receivers MUST validate that the field has the known
legacy-transmitter value

        and if not, MUST specify a behavior (silently drop the packet,
drop the packet and reply/signal, drop the connection, etc.)

Fields with more than two values can specify a number of receiver behaviors.

Joe