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

Gorry Fairhurst <gorry@erg.abdn.ac.uk> Mon, 02 September 2019 07:10 UTC

Return-Path: <gorry@erg.abdn.ac.uk>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63E2C1200E9 for <tcpm@ietfa.amsl.com>; Mon, 2 Sep 2019 00:10:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id imeXLB_yYwzx for <tcpm@ietfa.amsl.com>; Mon, 2 Sep 2019 00:10:00 -0700 (PDT)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 1FC9212002E for <tcpm@ietf.org>; Mon, 2 Sep 2019 00:10:00 -0700 (PDT)
Received: from MacBook-Pro-5.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 5BD1E1B001FC; Mon, 2 Sep 2019 08:09:57 +0100 (BST)
Message-ID: <5D6CC045.2010205@erg.abdn.ac.uk>
Date: Mon, 02 Sep 2019 08:09:57 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Reply-To: gorry@erg.abdn.ac.uk
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
To: Joe Touch <touch@strayalpha.com>
CC: "tcpm@ietf.org" <tcpm@ietf.org>
References: <5D669BDA.3000506@erg.abdn.ac.uk> <5D66A044.3060904@erg.abdn.ac.uk> <3836C819-F176-42A1-B3B3-9C41C25AB3A9@strayalpha.com> <49b8440e-c677-6ad9-94cc-ea95a622ccc2@strayalpha.com>
In-Reply-To: <49b8440e-c677-6ad9-94cc-ea95a622ccc2@strayalpha.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/bsFYX34zFO7DNzaOsF0Irxte2i0>
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Sep 2019 07:10:01 -0000

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