Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24

Gorry Fairhurst <> Mon, 06 September 2021 07:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1DAB03A2484 for <>; Mon, 6 Sep 2021 00:13:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id i0TbwjNu-3pd for <>; Mon, 6 Sep 2021 00:13:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id CE0C63A2483 for <>; Mon, 6 Sep 2021 00:13:29 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 4FA191B0022D; Mon, 6 Sep 2021 08:12:33 +0100 (BST)
Content-Type: multipart/alternative; boundary="Apple-Mail-19DD49AB-89C4-48D7-B433-2EEC4BAB9A41"
Content-Transfer-Encoding: 7bit
From: Gorry Fairhurst <>
Mime-Version: 1.0 (1.0)
Date: Mon, 06 Sep 2021 08:12:29 +0100
Message-Id: <>
References: <>
Cc: Wesley Eddy <>, tcpm IETF list <>
In-Reply-To: <>
To: Kyle Rose <>
X-Mailer: iPad Mail (17E262)
Archived-At: <>
Subject: Re: [tcpm] Secdir last call review of draft-ietf-tcpm-rfc793bis-24
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: Mon, 06 Sep 2021 07:13:36 -0000

> On 5 Sep 2021, at 18:34, Kyle Rose <> wrote:
>> On Sun, Sep 5, 2021 at 12:51 PM Gorry Fairhurst <> wrote:
>> To me, this has a much more complicated history, and I think TCP has been extended many times - albeit not sucessfully in the ways mentioned above, but in other watys. It seems like a discussion of whether ossification has been good or bad. I'd also really quite concerned to see words like "often" used without clarifying further -  there are legitimate cases where filtering can be useful for managing the security of TCP connections: A firewall in one context might do many things, and that might actually be a good security model; in another context that might be different. 
> I'm not in favor of making a value judgment or discussing the wisdom of approaches to addressing ossification in this document, but I do think, given the rare opportunity of publishing a 793bis, that it's worth putting the implications of TCP ossification in writing so we don't have to relitigate these issues or explain in detail why such-and-such won't work whenever they come up in future attempts to extend TCP. I guess I'm arguing that we shouldn't need Joe Touch to explain multiple times to multiple groups why a given proposal won't work when we can explain it once and mic-drop a one-line reference to that.
>> I'd also question the importance of, in relation to the core TCP spec, even though the message is clear for MPTCP.
> This is why I put it in a parenthetical. It's not directly relevant to TCP, but it does indicate to the interested reader an approach that newer protocol designs have taken to avoid one of the causes of ossification. I agree it's not essential.
> Kyle
Thanks for the reply. Seems like you and Wes converged on something slimmer. You could cite RFC 9065, if you wanted another ref. 

Best wishes,