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

[Gorry Fairhurst <[e-mail]>]

On 01/09/2019, 20:08, Joe Touch wrote:
> 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
Something like that would seem good.

Gorry