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

Joe Touch <> Sun, 01 September 2019 19:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6D8D11200B8 for <>; Sun, 1 Sep 2019 12:09:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.22
X-Spam-Status: No, score=-1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3BW7YRDFP4Gq for <>; Sun, 1 Sep 2019 12:08:59 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2429112007C for <>; Sun, 1 Sep 2019 12:08:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:References:Cc:To:From:Subject:Sender :Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WjZuiGWfeeCzhrbJMaqyZCOy8s/03iDntSyJARjUE+g=; b=O0Bf26Sx0D37lbDyYGwA+YSliH J3Bz83CmPGzqaNs+AE0kuDyPqUKq/CpR46xMZZDagNeJNK2enlR6PkepPiLR+d0Mq/NtRwXG6kGyZ SzMrSxfaKjYNcooJjFD9xqNquRkkzYDhOHZbeMzbwWQgOJO9mbyWu3WoN00j+pU4/KhxmA3e9mKQM flsLnnR2E7ie8AVowB9LURGRaWolMs/NK0exe1fcLFjxpv1LYjcZ1pwGI065rz7wu00DMGRXcJDXh ft2PPj9d2AcXjK6U6zx7XCwwngL4suVuucYU+AB1NkKwxUnxAswFr0pNXxAA8tAVyARefHHXXjSl9 MxcOFBLQ==;
Received: from ([]:58252 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <>) id 1i4VDa-001icr-HC; Sun, 01 Sep 2019 15:08:58 -0400
From: Joe Touch <>
Cc: "" <>
References: <> <> <>
Message-ID: <>
Date: Sun, 1 Sep 2019 12:08:53 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
X-From-Rewrite: unmodified, already matched
Archived-At: <>
Subject: Re: [tcpm] review of rev 14 of RFC 793 bis part 2 of 2 - Technical Comments & Questions
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 01 Sep 2019 19:09:00 -0000

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.


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.