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

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 10 Jun 2021 09:02:38 +0000

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 <[email-masked]>.

The responsible Area Director is Martin Duke <[email-masked]>.

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 congestion 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!

---

From: <[email-masked]>
Date: Thu, 10 Jun 2021 14:49:16 +0000

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:[email-masked]] De la part de Scharf,
> Michael
> Envoyé : jeudi 10 juin 2021 11:03
> À : [email-masked]
> Cc : tcpm-chairs <[email-masked]>
> 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).
> 
> 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 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.
> 
> 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
> [email-masked]
> 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.

---

From: <[email-masked]>
Date: Thu, 10 Jun 2021 15:21:10 +0000

Re-,

FWIW, here is a proposal for the IANA part of the write-up: 

OLD: 

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

> De : tcpm [mailto:[email-masked]] De la part de
> [email-masked]
> Envoyé : jeudi 10 juin 2021 16:49
> À : Scharf, Michael <[email-masked]>; [email-masked]
> 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.
> 
> > Envoyé : jeudi 10 juin 2021 11:03 À : [email-masked] Cc : tcpm-
> chairs
> > <[email-masked]> Objet : [tcpm] Draft schepherd write-up for
> > 793bis
> >
> > Dear all,
> >
> the
> > TCPM consensus. Therefore, I share the text before actually
> hitting
> > the button.
> >
> > 1122, and it should be considered as a replacement for the
> portions of
> > that document dealing with TCP requirements.
> >
> functional
> > specification and unify them into an update of RFC 793.
> 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.
> >
> Standards.
> > The same applies to 793bis. The TCPM working group requests
> > publication of 793bis on Standards Track. If approved, the
> document
> 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.
> >
> 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
> 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.
> >
> > 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.
> >
> RFC
> > 1122. While there are numerous RFCs that specify TCP congestion
> 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.
> >
> 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
> >
> protocol,
> > relevant IPR would have to be disclosed already for the existing
> RFCs
> > included in 793bis.
> >
> TCPM
> > working group there are no known concerns regarding this IPR
> > all false positives. The document refers to some obsolete
> documents to
> > provide historical context.
> >
> 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.
> >
> ____________________________________________________________________
> _____________________________________________________
> 
> 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.
>

---

From: tom petch <[email-masked]>
Date: Thu, 10 Jun 2021 16:14:16 +0000

From: tcpm <[email-masked]> on behalf of Scharf, Michael <[email-masked]>
Sent: 10 June 2021 10:02

Dear all,

<tp>
Michael

Lots of good stuff but it does not appear to follow the template, a layout which I find  useful when wanting to check on an aspect thereof, such as validation by sundry tools, as it saves me having to work my way through it.

Tom Petch
p.s. Reviewing 793bis has been on mytodo list for an embarrassing number of years:-(

Thanks

Michael

***

1. Summary

2. Review and Consensus

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.

3. Intellectual Property

4. Other Points

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 10 Jun 2021 16:23:45 +0000

The write-up uses the official "essay" template https://www.ietf.org/chairs/document-writeups/ .

I personally prefer that template over the "Q&A" one, and have used the "essay" one in the past many times already.

Michael

> -----Original Message-----
> From: tom petch <[email-masked]>
> Sent: Thursday, June 10, 2021 6:14 PM
> To: Scharf, Michael <[email-masked]>; [email-masked]
> Cc: tcpm-chairs <[email-masked]>
> Subject: Re: Draft schepherd write-up for 793bis
> 
> 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).
> 
> Lots of good stuff but it does not appear to follow the template, a layout
> which I find  useful when wanting to check on an aspect thereof, such as
> validation by sundry tools, as it saves me having to work my way through it.
> 
> Tom Petch
> 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
> 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
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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 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
> referenced. RFC 5961 mostly affects MAY-12 in 793bis, i.e., the changes
> described in RFC 5961 are optional and not mandatory-to-implement.
> 
> 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.
> 
> 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!
>

---

From: "Scharf, Michael" <[email-masked]>
Date: Thu, 10 Jun 2021 16:47:03 +0000

Thx. I'll use this wording.

Michael

> From: [email-masked]
> <[email-masked]>
> Sent: Thursday, June 10, 2021 5:21 PM
> Subject: RE: Draft schepherd write-up for 793bis
> 
> Re-,
> 
> (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.
> __________________________________________________________
> __________________________________________________________
> _____
> 
> confidentielles ou privilegiees et ne doivent donc
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration,
> This message and its attachments may contain confidential or privileged
> information that may be protected by law;