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

["Scharf, Michael" <[e-mail]>]

Thx. I'll use this wording.

Michael

> -----Original Message-----
> From: [e-mail]
> <[e-mail]>
> Sent: Thursday, June 10, 2021 5:21 PM
> To: Scharf, Michael <[e-mail]>; [e-mail]
> Cc: tcpm-chairs <[e-mail]>
> 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:[e-mail]] De la part de
> > [e-mail]
> > Envoyé : jeudi 10 juin 2021 16:49
> > À : Scharf, Michael <[e-mail]>; [e-mail]
> > Cc : tcpm-chairs <[e-mail]>
> > 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:[e-mail]] De la part de Scharf,
> > Michael
> > > Envoyé : jeudi 10 juin 2021 11:03 À : [e-mail] Cc : tcpm-
> > chairs
> > > <[e-mail]> 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
> > > <[e-mail]>.
> > >
> > > 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
> > > [e-mail]
> > > 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
> > [e-mail]
> > 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.