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

[[e-mail]]

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.