Re: [tcpm] Draft schepherd write-up for 793bis
"Scharf, Michael" <Michael.Scharf@hs-esslingen.de> Thu, 10 June 2021 16:47 UTC
Return-Path: <Michael.Scharf@hs-esslingen.de>
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 B16DC3A07E2; Thu, 10 Jun 2021 09:47:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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_DNSWL_BLOCKED=0.001, 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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-esslingen.de
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 neeRiRtQWGtk; Thu, 10 Jun 2021 09:47:08 -0700 (PDT)
Received: from mail.hs-esslingen.de (mail.hs-esslingen.de [134.108.32.78]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115F73A07BA; Thu, 10 Jun 2021 09:47:07 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.hs-esslingen.de (Postfix) with ESMTP id E36F925A22; Thu, 10 Jun 2021 18:47:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-esslingen.de; s=mail; t=1623343626; bh=1imB9AnkCyekid8qnN9C3thmeG+/blezCGQs274kXWM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=MTX1wDwZOlDHA9Zt9nC5KGZPISBaq2hIC3mCrSHlqh6sENjTuxRWeF3Zhw60IFQgr /FE5C5k+V6pmAgUoJRlTje7fvJcsL6EEJrtizobyiAHp6wvb21R2YDyqZyZVjylvJJ itYvi/T1cqse7S+w+xm97mrYi2eRsVoYpQ8KJED8=
X-Virus-Scanned: by amavisd-new-2.7.1 (20120429) (Debian) at hs-esslingen.de
Received: from mail.hs-esslingen.de ([127.0.0.1]) by localhost (hs-esslingen.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-57lLA8Wadz; Thu, 10 Jun 2021 18:47:04 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (rznt8202.hs-esslingen.de [134.108.48.165]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.hs-esslingen.de (Postfix) with ESMTPS; Thu, 10 Jun 2021 18:47:04 +0200 (CEST)
Received: from rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) by rznt8202.rznt.rzdir.fht-esslingen.de (134.108.48.165) 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:47:03 +0200
Received: from rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0]) by rznt8202.rznt.rzdir.fht-esslingen.de ([fe80::aca4:171a:3ee1:57e0%3]) with mapi id 15.01.2176.014; Thu, 10 Jun 2021 18:47:03 +0200
From: "Scharf, Michael" <Michael.Scharf@hs-esslingen.de>
To: "mohamed.boucadair@orange.com" <mohamed.boucadair@orange.com>, "tcpm@ietf.org" <tcpm@ietf.org>
CC: tcpm-chairs <tcpm-chairs@ietf.org>
Thread-Topic: Draft schepherd write-up for 793bis
Thread-Index: Addd1jp8v9JHxVLlQJqEoECOEi9ZnQAMP1VQAAEn3SAAAxek4A==
Date: Thu, 10 Jun 2021 16:47:03 +0000
Message-ID: <c290733d1c31481f80354f9d79e5d9b8@hs-esslingen.de>
References: <37960e79a8d940d6812cb494732b066f@hs-esslingen.de> <3560_1623336557_60C2266D_3560_462_1_787AE7BB302AE849A7480A190F8B9330353A7B8D@OPEXCAUBMA2.corporate.adroot.infra.ftgroup> <14061_1623338471_60C22DE7_14061_318_1_787AE7BB302AE849A7480A190F8B9330353A7C4C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
In-Reply-To: <14061_1623338471_60C22DE7_14061_318_1_787AE7BB302AE849A7480A190F8B9330353A7C4C@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [134.108.140.248]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/DVW47hrHHITVYdphjigjJilCj6s>
Subject: Re: [tcpm] Draft schepherd write-up for 793bis
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: Thu, 10 Jun 2021 16:47:14 -0000
Thx. I'll use this wording. Michael > -----Original Message----- > From: mohamed.boucadair@orange.com > <mohamed.boucadair@orange.com> > Sent: Thursday, June 10, 2021 5:21 PM > To: Scharf, Michael <Michael.Scharf@hs-esslingen.de>; tcpm@ietf.org > Cc: tcpm-chairs <tcpm-chairs@ietf.org> > Subject: RE: Draft schepherd write-up for 793bis > > Re-, > > FWIW, here is a proposal for the IANA part of the write-up: > > OLD: > > 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. > > NEW: > > The IANA section includes many actions: > (1) Update the structure of the TCP flags registry to include a new column > called "Assignment Notes" > (2) Rename "Bit" column of the TCP flags registry to "Bit Offset" > (3) Update the TCP flags registry to include all assigned TCP flags, not only > those initially assigned in RFC 3168. 10-15 values are assigned. > (4) Move the existing TCP flags registry to be as sub-registry of the TCP > registry. > > There was unanimous consensus in TCPM with these changes. > > Cheers, > Med > > > -----Message d'origine----- > > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de > > mohamed.boucadair@orange.com > > Envoyé : jeudi 10 juin 2021 16:49 > > À : Scharf, Michael <Michael.Scharf@hs-esslingen.de>; tcpm@ietf.org > > Cc : tcpm-chairs <tcpm-chairs@ietf.org> > > Objet : Re: [tcpm] Draft schepherd write-up for 793bis > > > > Hi Michael, > > > > One comment about the IANA part, we have agreed to move one existing > > IANA **registry** to be a **sub-registry** under the existing TCP > > registry. I would update the IANA part accordingly. > > > > Other than that, this looks good. Thanks. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De : tcpm [mailto:tcpm-bounces@ietf.org] De la part de Scharf, > > Michael > > > Envoyé : jeudi 10 juin 2021 11:03 À : tcpm@ietf.org Cc : tcpm- > > chairs > > > <tcpm-chairs@ietf.org> Objet : [tcpm] Draft schepherd write-up for > > > 793bis > > > > > > 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. > > > > > > Thanks > > > > > > Michael > > > > > > > > > *** > > > > > > 1. Summary > > > > > > The document shepherd is Michael Scharf <michael.scharf@hs- > > > esslingen.de>. > > > > > > The responsible Area Director is Martin Duke > > > <martin.h.duke@gmail.com>. > > > > > > 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 > > > (https://datatracker.ietf.org/ipr/421/) 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 > > > https://datatracker.ietf.org/ipr/421/ 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 > > > tcpm@ietf.org > > > https://www.ietf.org/mailman/listinfo/tcpm > > > > > __________________________________________________________ > __________ > > _____________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre > > diffuses, exploites ou copies sans autorisation. Si vous avez recu > > ce message par erreur, veuillez le signaler a l'expediteur et le > > detruire ainsi que les pieces jointes. Les messages electroniques > > etant susceptibles d'alteration, Orange decline toute responsabilite > > si ce message a ete altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not > > be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender > > and delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that > > have been modified, changed or falsified. > > Thank you. > > > > _______________________________________________ > > tcpm mailing list > > tcpm@ietf.org > > https://www.ietf.org/mailman/listinfo/tcpm > > __________________________________________________________ > __________________________________________________________ > _____ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce > message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete > this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been > modified, changed or falsified. > Thank you.
- [tcpm] Draft schepherd write-up for 793bis Scharf, Michael
- Re: [tcpm] Draft schepherd write-up for 793bis mohamed.boucadair
- Re: [tcpm] Draft schepherd write-up for 793bis mohamed.boucadair
- Re: [tcpm] Draft schepherd write-up for 793bis tom petch
- Re: [tcpm] Draft schepherd write-up for 793bis Scharf, Michael
- Re: [tcpm] Draft schepherd write-up for 793bis Scharf, Michael