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.