Re: [tcpm] Draft schepherd write-up for 793bis

"Scharf, Michael" <> Thu, 10 June 2021 16:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D54DC3A45AB; Thu, 10 Jun 2021 09:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id hoLC0pGGX-J3; Thu, 10 Jun 2021 09:23:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BFBA93A45A9; Thu, 10 Jun 2021 09:23:49 -0700 (PDT)
Received: from localhost (localhost.localdomain []) by (Postfix) with ESMTP id 4D24025A20; Thu, 10 Jun 2021 18:23:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=mail; t=1623342227; bh=rPY7DRBIKbjhHVuXb7BXk+mgLPYxuJOkwRS06Z9qvS4=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=ppKEp3LQOy9dSFmLgWo5H8+dBEH03clbRAH9qMGYcbZpfgGlOuB5Xs0tPDZ7TPLCd kApHuhJyT92DhZNWl7tckgvFnH+dO0ImNS9xwTmJBDh50XWh2v4XyCJ2S4zWEPr3HS MT2Z2gAzTKlD+G9094335iZoL+VIij97lU9JX4ZM=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 19KLAG2ZSjCP; Thu, 10 Jun 2021 18:23:45 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Thu, 10 Jun 2021 18:23:45 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 10 Jun 2021 18:23:45 +0200
Received: from ([fe80::aca4:171a:3ee1:57e0]) by ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Thu, 10 Jun 2021 18:23:45 +0200
From: "Scharf, Michael" <>
To: tom petch <>, "" <>
CC: tcpm-chairs <>
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAPNXYwAABWk3A=
Date: Thu, 10 Jun 2021 16:23:45 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: de-DE, en-US
Content-Language: de-DE
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [tcpm] Draft schepherd write-up for 793bis
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: Thu, 10 Jun 2021 16:23:56 -0000

The write-up uses the official "essay" template .

I personally prefer that template over the "Q&A" one, and have used the "essay" one in the past many times already.


> -----Original Message-----
> From: tom petch <>
> Sent: Thursday, June 10, 2021 6:14 PM
> To: Scharf, Michael <>de>;
> Cc: tcpm-chairs <>
> Subject: Re: Draft schepherd write-up for 793bis
> From: tcpm <> on behalf of Scharf, Michael
> <>
> Sent: 10 June 2021 10:02
> Dear all,
> As document shepherd, I have started to work on my write-up for 793bis.
> Given that 793bis may one of the most important deliverables of TCPM, I'd
> like to ensure that the write-up correctly describes the TCPM consensus.
> Therefore, I share the text before actually hitting the button.
> If the write-up listed below is not accurate or misses important details,
> please let me know ASAP (on-list of off-list).
> I plan to forward 793bis to our AD tomorrow.
> <tp>
> Michael
> Lots of good stuff but it does not appear to follow the template, a layout
> which I find  useful when wanting to check on an aspect thereof, such as
> validation by sundry tools, as it saves me having to work my way through it.
> Tom Petch
> p.s. Reviewing 793bis has been on mytodo list for an embarrassing number of
> years:-(
> Thanks
> Michael
> ***
> 1. Summary
> The document shepherd is Michael Scharf <michael.scharf@hs-
> The responsible Area Director is Martin Duke <>om>.
> This document specifies the Transmission Control Protocol (TCP) as "bis"
> document to RFC 793. It obsoletes RFC 793 as well as a several other RFCs
> that specified additions to RFC 793. It also updates RFC 1122, and it should be
> considered as a replacement for the portions of that document dealing with
> TCP requirements.
> The purpose of this document is to bring together all the IETF Standards Track
> changes that have been made to the base TCP functional specification and
> unify them into an update of RFC 793. The document focuses on the
> common basis all TCP implementations must support to interoperate. With
> one exception, protocol modifications compared to RFC 793 are limited to
> standards-track RFCs or verified erratas, i.e., changes of TCP standards that
> already have IETF consensus.
> RFC 793 and RFC 1122 are ubiquitously implemented Internet Standards. The
> same applies to 793bis. The TCPM working group requests publication of
> 793bis on Standards Track. If approved, the document should replace RFC 793
> as "STD 7".
> 2. Review and Consensus
> The TCPM working group has worked on this document for more than 6
> years, and many TCPM contributors have reviewed the specification during
> that time. In particular, many TCP implementers have provided detailed
> comments based on operational experience. The document was relatively
> stable in the latest versions. During and after WGLC, several comprehensive
> reviews flagged some open issues that all got resolved.
> 793bis improves the specification of TCP but it does not modify the TCP
> protocol. TCP is a complex protocol and even minor wording details in the
> protocol specification can matter. Given the restriction to TCP changes that
> already have IETF consensus, there has never been any major controversy
> about the main content.
> Nonetheless, several questions were non-trivial and triggered longer
> discussions in TCPM. These issues can roughly be subdivided in three
> categories:
> 1/ Being published in 1981, RFC 793 defines several protocol mechanisms that
> have become outdated and may not be implemented at all in a modern
> TCP/IP stack. However, in some cases the corresponding specification in RFC
> 793 never got updated or obsoleted and is still formally valid. Appendix A.1
> summarizes some of these issues. The TCPM consensus for those cases is to
> document the issues in 793bis, but not to change the TCP standards. The
> required changes to the TCP standards should be handled by dedicated,
> narrow-focused RFCs that would have to reach IETF consensus first. This de-
> risk strategy ensures that each TCP protocol change can be properly and
> comprehensively reviewed.
> 2/ There are some known issues in the standards-track specification of TCP
> that exist but only matter in corner cases. An example is documented in
> Appendix A.2. In Internet usage of TCP, these conditions are rarely occurring.
> Common operating systems include different alternative mitigations, and the
> standard has not been updated yet to codify one of them. Also, there is no
> known best approach. Given the lack of practical relevance, the TCPM
> consensus is to describe these known problems, but not to change the TCP
> standards in 793bis. Again, these problems could be solved by future,
> dedicated, narrow-focused RFC that would have to reach IETF consensus
> first.
> 3/ There are known deviations between mandatory-to-implement
> requirements in the TCP standard and some widely deployed
> implementations. An example are some details in Section 3.8.3, such as the
> numerical value in MUST-23. Those cases typically do not affect
> interoperability with other implementations. The TCPM working group has
> discussed whether to change the standard in such cases (e.g., downgrade
> MUST-23 to a SHOULD), but finally refrained from going down that road in
> 793bis, given the huge installed base with a very large variety of TCP
> implementations. Similar like in the previous cases, 793bis may get updated
> by narrow-focused RFCs.
> There is one important exception to the decision not to include new
> guidance in 793bis. The exception is Section 3.8.2 "TCP Congestion Control".
> TCP congestion control was developed after publication of RFC 793 and the
> state-of-the-art has evolved a lot as compared to RFC 1122. While there are
> numerous RFCs that specify TCP congestion control, there is no clear
> normative guidance on the required minimum in all TCP implementations
> that would be appropriate for 793bis. However, 793bis cannot just stay silent
> on congestion control. Given the lack of other applicable wording in existing
> standards, Section 3.8.2 includes new text and is therefore different to the
> rest of the document. Section 3.8.2 was comprehensively reviewed by the
> TCPM working group and in particular by TCP implementers. The section is
> short and straightforward, and the wording was chosen very carefully to
> reflect existing TCP standards and operational experience in the Internet.
> Also, given ongoing research, TCP conge
>  stion control will most likely further evolve in future. Section 3.8.2 enables
> such a further evolution while defining important base requirements.
> Running code exists - in billions of TCP/IP stacks. Given the very limited scope
> of modifications in the 793bis document, all TCP implementations that are
> already compliant to the TCP standards before publication of 793bis should
> be compliant to 793bis as well.
> The shepherd believes that the 793bis document has unanimous support
> from the entire TCPM working group.
> 3. Intellectual Property
> The editor has stated that his direct, personal knowledge of any IPR related
> to this document has already been disclosed, in conformance with BCPs 78
> and 79. The editor is not aware of any IPR relevant for the base TCP protocol.
> Since 793bis does not change the TCP protocol, relevant IPR would have to
> be disclosed already for the existing RFCs included in 793bis.
> There is a Cisco IPR disclosure from year 2004 related to the Internet-Draft
> that resulted in RFC 5961 ( RFC 5961 is
> one source of changes included in 793bis. In all places in 793bis where the
> recommendations from RFC 5961 are mentioned, 5961 is prominently
> referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes
> described in RFC 5961 are optional and not mandatory-to-implement.
> It has been suggested that the owner of the IPR disclosed in
> updates the IPR disclosure to make
> clear whether it applies to 793bis, or not.
> The TCPM working group is aware of the IPR disclosure related to RFC 5961,
> which is known already for a long time. The document shepherd has verified
> on the TCPM mailing list that the TCPM working group is fine with the
> proposed text in 793bis related to RFC 5961. In the TCPM working group
> there are no known concerns regarding this IPR disclosure related to an
> optional mechanism.
> 4. Other Points
> The intended status listed in the document is "Proposed Standard". As all
> main TCP implementations are supposed to comply with 793bis, the
> document may fulfill the requirements of an "Internet Standard" according
> to RFC 2026 and RFC 7127.
> idnits reports some warnings, such as obsolete references. These are all false
> positives. The document refers to some obsolete documents to provide
> historical context.
> The IANA Considerations in Section 5 include some editorial clean-up of the
> TCP entries in the IANA registry. The modifications neither change any
> allocation nor any policy in the IANA registry. These purely editorial changes
> have been discussed in the TCPM working group for a long time and there is
> unanimous consensus in TCPM that this clean-up is useful.
> All errata to RFC 793 and related RFCs have been considered in this "bis"
> document.
> When Wes started working on a 793bis document in 2013, the document
> shepherd, as well as many other TCPM contributors, were pretty convinced
> that writing a 793bis document is an impossible endeavor. Well, after many
> years, we are proven wrong. Many thanks to Wes as editor!
> _______________________________________________
> tcpm mailing list