Subject: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt

From: [email-masked]
Date: Tue, 27 Oct 2020 05:35:52 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the TCP Maintenance and Minor Extensions WG of the IETF.

        Title           : Transmission Control Protocol (TCP) Specification
        Author          : Wesley M. Eddy
	Filename        : draft-ietf-tcpm-rfc793bis-19.txt
	Pages           : 109
	Date            : 2020-10-27

Abstract:
   This document specifies the Transmission Control Protocol (TCP).  TCP
   is an important transport layer protocol in the Internet protocol
   stack, and has continuously evolved over decades of use and growth of
   the Internet.  Over this time, a number of changes have been made to
   TCP as it was specified in RFC 793, though these have only been
   documented in a piecemeal fashion.  This document collects and brings
   those changes together with the protocol specification from RFC 793.
   This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093,
   6429, 6528, and 6691 that updated parts of RFC 793.  It updates RFC
   1122, and should be considered as a replacement for the portions of
   that document dealing with TCP requirements.  It also updates RFC
   5961 by adding a small clarification in reset handling while in the
   SYN-RECEIVED state.  The TCP header control bits from RFC 793 have
   also been updated based on RFC 3168.

   RFC EDITOR NOTE: If approved for publication as an RFC, this should
   be marked additionally as "STD: 7" and replace RFC 793 in that role.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tcpm-rfc793bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-19
https://datatracker.ietf.org/doc/html/draft-ietf-tcpm-rfc793bis-19

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tcpm-rfc793bis-19

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: <[email-masked]>
Date: Tue, 27 Oct 2020 13:15:12 +0000

Hi all, 

I like the changes. Thank you for taking care of this, Wes. 

I do still think the MSS part of MUST-4 is redundant with MUST-14 (and other reco in 3.6.1). 

Cheers,
Med

> -----Message d'origine-----
> De : I-D-Announce [mailto:[email-masked]] De la part
> de [email-masked]
> Envoyé : mardi 27 octobre 2020 13:36
> À : [email-masked]
> Cc : [email-masked]
> Objet : I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
> 
> 
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> tools.ietf.org.
> 
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html or
> ftp://ftp.ietf.org/ietf/1shadow-sites.txt

_________________________________________________________________________________________________________________________

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: Joseph Touch <[email-masked]>
Date: Tue, 27 Oct 2020 11:27:27 -0700

Looks good to me too, but one question:

The update below that is already in -19 doesn’t include a MUST-##. I didn’t know if that was expected, but FYI.

Joe

> On Oct 22, 2020, at 3:47 PM, Joseph Touch <[email-masked]> wrote:
> 
> The following text should include a MUST, as shown below:
> 
>    (all TCP options except End of option list and No-Operation
>     MUST have length fields)

-------

> On Oct 27, 2020, at 5:35 AM, [email-masked] wrote:
> 
>

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 27 Oct 2020 19:00:54 -0400

I meant to explain this one to the list, but was side-tracked earlier, 
and you've beat me to it :)

When adding that text, I'd noticed that the "MUST" is applicable to 
other specs that define options (saying they need to include the length 
field), but isn't exactly something that you would check an 
implementation against for conformance (since it would just implement 
the options as properly specified).

If people think it makes sense to number it and add to the checklist, 
that's totally fine with me, but it didn't seem very meaningful.

On 10/27/2020 2:27 PM, Joseph Touch wrote:
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Wesley Eddy <[email-masked]>
Date: Tue, 27 Oct 2020 19:11:08 -0400

> I do still think the MSS part of MUST-4 is redundant with MUST-14 (and other reco in 3.6.1).

I agree those seem redundant.  For reference, one is saying the 
mandatory option set must be supported, and another is saying that 
sending and receiving the MSS option must be supported.  MSS is one of 
the mandatory options, so this is just something more specific that's 
implied by supporting the mandatory set.

If people think this is a problem, I'm happy to de-duplicate these 
(though renumbering doesn't seem like it will be a very fun editing task!).

---

From: <[email-masked]>
Date: Wed, 28 Oct 2020 06:25:00 +0000

Hi Wes, 

What is meant by "MSS support" is actually what is specified in 3.6.1. 

One way to avoid troubles with renumbering is to add a pointer to section 3.6.1 right after MUST-4 to state this. 

Cheers,
Med

> De : tcpm [mailto:[email-masked]] De la part de Wesley Eddy
> Envoyé : mercredi 28 octobre 2020 00:11
> À : [email-masked]
> Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
> 
> sending and receiving the MSS option must be supported.  MSS is one
> of the mandatory options, so this is just something more specific
> that's implied by supporting the mandatory set.
>

---

From: <[email-masked]>
Date: Wed, 28 Oct 2020 07:12:01 +0000

Re-,

I agree with Wes that this one does not need to be numbered. I would even remove that sentence as the specs defining the options will call out the legal length. 

If the text is maintained, the normative language should be removed for the internal consistency of the document:

==
   Each use of RFC 2119 keywords in the document is individually labelled
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   and referenced in Appendix B that summarizes implementation
   requirements.
==

OLD:

NEW:
     have length fields)

Cheers,
Med

> Envoyé : mercredi 28 octobre 2020 00:01
> À : [email-masked]
> I meant to explain this one to the list, but was side-tracked
> earlier, and you've beat me to it :)
> 
> other specs that define options (saying they need to include the
> length field), but isn't exactly something that you would check an
> implementation against for conformance (since it would just
> implement the options as properly specified).
> 
> If people think it makes sense to number it and add to the
> checklist, that's totally fine with me, but it didn't seem very
> meaningful.
> 
> 
> > The update below that is already in -19 doesn’t include a MUST-##.
> I didn’t know if that was expected, but FYI.
> >
> > Joe
> >

---

From: Joseph Touch <[email-masked]>
Date: Wed, 28 Oct 2020 08:14:09 -0700

FWIW, here’s the issue:

- TCP relies on the fact that ALL *new* options MUST include the length field.

That’s a design constraint on extensions. It’s not merely asserted when each new option is defined.

If that requirement is not established, then TCP has *no way* to know how many bytes to jump over in a SYN to ignore options it does not support.

So this document absolutely needs this requirement - perhaps reworded to be more clear that ONLY the options defined herein with fixed length can omit that field.

Joe

> On Oct 28, 2020, at 12:12 AM, [email-masked] wrote:
> 
> Re-,
>

---

From: <[email-masked]>
Date: Wed, 28 Oct 2020 15:56:23 +0000

Hi Joe, 

I was assuming that "case 2" is used for defining new options. I agree that we should say this explicitly in the doc.

Thanks. 

Cheers,
Med

> De : Joseph Touch [mailto:[email-masked]]
> Envoyé : mercredi 28 octobre 2020 16:14
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
> Cc : Wes Eddy <[email-masked]>; [email-masked]
> If that requirement is not established, then TCP has *no way* to
> know how many bytes to jump over in a SYN to ignore options it does
> not support.
> 
> So this document absolutely needs this requirement - perhaps
> reworded to be more clear that ONLY the options defined herein with
> fixed length can omit that field.
> 
> Joe
> 
> > I agree with Wes that this one does not need to be numbered. I
> would even remove that sentence as the specs defining the options
> will call out the legal length.
> >
> > If the text is maintained, the normative language should be
> removed for the internal consistency of the document:
> >
> > ==
> >> Envoyé : mercredi 28 octobre 2020 00:01 À : [email-masked] Objet :
> Re:
> >> [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt
> >>
> checklist,
> >>>> On Oct 22, 2020, at 3:47 PM, Joseph Touch
> <[email-masked]>
> >> wrote:
> >>>>
> ____________________________________________________________________
> __
> > ___________________________________________________
> >
> > 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: Joseph Touch <[email-masked]>
Date: Wed, 28 Oct 2020 10:58:25 -0700

Right - that’s the point of the text below - including where it appears. 

Perhaps more strictly, we should say “All future options MUST use the kind/length format”. But it does need a number (MUST-##).

Joe

> On Oct 28, 2020, at 8:56 AM, [email-masked] wrote:
> 
> Hi Joe, 
>

---

From: <[email-masked]>
Date: Thu, 29 Oct 2020 07:46:29 +0000

Hi Joe,

I would personally leave with the following:

OLD: 
        Case 1: A single octet of option-kind.

        Case 2: An octet of option-kind (Kind), an octet of option-
        length, and the actual option-data octets.

NEW:
        Case 1: A single octet of option-kind. This case is 
        exclusively reserved to "End of option List" and "No-Operation"
        defined in this document. 

        Case 2: An octet of option-kind (Kind), an octet of option-
        length, and the actual option-data octets. This layout has to be 
        used when defining future options.  

Cheers,
Med

> Envoyé : mercredi 28 octobre 2020 18:58
> Perhaps more strictly, we should say “All future options MUST use
> the kind/length format”. But it does need a number (MUST-##).
> 
> Joe
> 
> > I was assuming that "case 2" is used for defining new options. I
> agree that we should say this explicitly in the doc.
> >
> > Thanks.
> >
> > Cheers,
> > Med

---

From: Joseph Touch <[email-masked]>
Date: Thu, 29 Oct 2020 09:29:40 -0700

Hi, Med,

I disagree.

TCP correctness relies on its ability to process unknown options. The requirement needs to be a MUST, “have to” should never appear in an RFC when describing a protocol function.

It is a strict, testable implementation requirement that ensures that all future options are processed correctly. It also is a design requirement on new options (or at least a hurdle they need to overcome, as with TCP-opt-ext).

Wiggle words like “exclusively reserved” and “has to be used” are insufficient. This sort of constraint is exactly what MUST addresses.

Joe

> On Oct 29, 2020, at 12:46 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Joe,
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tcpm <https://www.ietf.org/mailman/listinfo/tcpm>

---

From: <[email-masked]>
Date: Fri, 30 Oct 2020 09:38:31 +0000

Hi Joe,

You made fair points, but one of the reasons I think we can avoid the normative language here is that practically new options are likely to be defined first following the layout in RFC 6994. That one requires a length to be present.

Cheers,
Med

De : Joseph Touch [mailto:[email-masked]]
Envoyé : jeudi 29 octobre 2020 17:30
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]>
Cc : [email-masked]
Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt

Hi, Med,

I disagree.

Joe

On Oct 29, 2020, at 12:46 AM, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

Hi Joe,

OLD:

NEW:

Cheers,
Med

-----Message d'origine-----
De : Joseph Touch [mailto:[email-masked]]
Envoyé : mercredi 28 octobre 2020 18:58
À : BOUCADAIR Mohamed TGI/OLN <[email-masked]<mailto:[email-masked]>>
Cc : [email-masked]<mailto:[email-masked]>
Objet : Re: [tcpm] I-D Action: draft-ietf-tcpm-rfc793bis-19.txt

Right - that’s the point of the text below - including where it
appears.

Joe

On Oct 28, 2020, at 8:56 AM, [email-masked]<mailto:[email-masked]> wrote:

Hi Joe,

Thanks.

Cheers,
Med

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Joseph Touch <[email-masked]>
Date: Fri, 30 Oct 2020 09:33:35 -0700

Hi, Med,

RFC6994 applies only to experimental options. This doc still needs to indicate the constraint on use of the standards-track (at least as typically required) code points.

Those options were assigned most recently in March of this past year (MPTCP) and May 2019 (even though Experimental).

Joe

> On Oct 30, 2020, at 2:38 AM, <[email-masked]> <[email-masked]> wrote:
> 
> Hi Joe,
>  
> On Oct 29, 2020, at 12:46 AM, <[email-masked] <mailto:[email-masked]>> <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi Joe,
> 
> De : Joseph Touch [mailto:[email-masked] <mailto:[email-masked]>]
> À : BOUCADAIR Mohamed TGI/OLN <[email-masked] <mailto:[email-masked]>>
> Cc : [email-masked] <mailto:[email-masked]>
> On Oct 28, 2020, at 8:56 AM, [email-masked] <mailto:[email-masked]> wrote:
> 
> Hi Joe,
>