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

[[e-mail]]

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.