Subject: [tcpm] Please review 793bis!

From: "Scharf, Michael" <[email-masked]>
Date: Fri, 26 Jul 2019 15:17:20 +0000

Hi all,

As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis in order to complete this important TCPM milestone. The draft can be found at:

https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13

If you care about TCP (after all you have decided to subscribe the TCPM list for some reason, no?), please try to find some cycles and please have a look at this document.

Thanks

Michael

---

From: Tommy Pauly <[email-masked]>
Date: Sat, 27 Jul 2019 21:43:46 -0400

Hi Michael,

Thanks for the note about this (indeed important!) document. I unfortunately had a conflict for tcpm, so missed the recent meeting, but I do have some questions about what the group wants to see in reviews of this document.

As expected, much of the text remains unchanged from RFC793. While I understand and agree that it is a non-goal to change any behavior, reading the document does still feel like it is out of place amongst current RFCs from a terminology and organizational standpoint. If this is going to be published as a full STD document, it would be great to have something that also makes the reading clearer and easier for people new to TCP. Specifically, as some people are now working on implementations of TCP for user space stacks or minimal IoT devices, a clean reference would be a fantastic asset.

Some initial examples of changes that came to mind:

- Structure; there is both a Terminology section (3.2) relatively early on, and a glossary (3.11) near the end. It seems more typical nowadays to have a terminology section up front, and just refer inline to supporting documents (like IP, for example).
- Many of the RFCs referenced are the older or obsoleted versions
- Consistency and freshness; some of the terminology feels dated, such as "the local and remote socket numbers" for referring to what is called "port numbers" elsewhere in the document and in current parlance.

There's a lot of possible work to be done here, so before people embark on such reviews, can you clarify which of these categories of input are useful, and would be incorporated?

Best
Tommy

> On Jul 26, 2019, at 11:17 AM, Scharf, Michael <[email-masked]> wrote:
> 
> Hi all,
> 
> _______________________________________________
> tcpm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tcpm

---

From: Tim Wicinski <[email-masked]>
Date: Sat, 27 Jul 2019 22:06:58 -0400

Tommy

For Implementation advice, I would refer people to the TCP Roadmap document
(rfc7414) which feels to me to be a better location.
rfc7414 (or what may be the best location) should be spelled out more
clearly to readers.

I noticed on reading through the document structure, there are references
to RFC793, yet the document is being Obsoleted.
If we're obsoleting an entire document, is it wise to refer back to it?
Does that confuse a casual reader?   If there are references to the

793, such as in Section 2, I think it should be included.

Tim

On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hi Michael,
>
> Thanks for the note about this (indeed important!) document. I
> unfortunately had a conflict for tcpm, so missed the recent meeting, but I
> do have some questions about what the group wants to see in reviews of this
> document.
>
> As expected, much of the text remains unchanged from RFC793. While I
> understand and agree that it is a non-goal to change any behavior, reading
> the document does still feel like it is out of place amongst current RFCs
> from a terminology and organizational standpoint. If this is going to be
> published as a full STD document, it would be great to have something that
> also makes the reading clearer and easier for people new to TCP.
> Specifically, as some people are now working on implementations of TCP for
> user space stacks or minimal IoT devices, a clean reference would be a
> fantastic asset.
>
> - Structure; there is both a Terminology section (3.2) relatively early
> on, and a glossary (3.11) near the end. It seems more typical nowadays to
> have a terminology section up front, and just refer inline to supporting
> documents (like IP, for example).
> - Consistency and freshness; some of the terminology feels dated, such as
> "the local and remote socket numbers" for referring to what is called "port
> numbers" elsewhere in the document and in current parlance.
>
> There's a lot of possible work to be done here, so before people embark on
> such reviews, can you clarify which of these categories of input are
> useful, and would be incorporated?
>
> Best
> Tommy
>
> > As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis
> in order to complete this important TCPM milestone. The draft can be found
> at:
> >
> > If you care about TCP (after all you have decided to subscribe the TCPM
> list for some reason, no?), please try to find some cycles and please have
> a look at this document.
> >
> > Thanks
> >
> > Michael
> >

---

From: Tommy Pauly <[email-masked]>
Date: Sun, 28 Jul 2019 05:57:53 -0400

Hi Tim,

> On Jul 27, 2019, at 10:07 PM, Tim Wicinski <[email-masked]> wrote:
> 
> 
> Tommy
> 
> For Implementation advice, I would refer people to the TCP Roadmap document (rfc7414) which feels to me to be a better location. 
> rfc7414 (or what may be the best location) should be spelled out more clearly to readers.

Indeed! I was not suggesting that there be any implementation guidance in this document. Rather, I was suggesting that modernizing some of the structure and terminology would make the document more easily accessible to readers. 
> 
> I noticed on reading through the document structure, there are references to RFC793, yet the document is being Obsoleted. 
> If we're obsoleting an entire document, is it wise to refer back to it?  Does that confuse a casual reader?   If there are references to the 

Right. I assume these references would need to be updated to refer within this document, as a link to an interior anchor point. 

Tommy

> Tim
> 
> 
> 
> 
>> On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly <tpauly=[email-masked]> wrote:
>> Hi Michael,
>> 
>> > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <Michael.Scharf@hs-esslingen..de> wrote:
>> > 
>> > Hi all,
>> >

---

From: "Scharf, Michael" <[email-masked]>
Date: Sun, 28 Jul 2019 11:21:48 +0000

Hi Tommy,

_any_ feedback is welcome.

This is a -bis document and it is not intended to change the TCP standards. Within that limit, we should try to come up with the best document we can. The document is owned by the working group. The question what changes will be incorporated is up to the working group as a whole. On that, I have not more to say than any other contributor to TCPM…

Personally, I think that your points are all valid concerns and I can think of ways this can be addressed (at least partially) without disrupting the document. But I’ll leave it to the document editor to comment on the impact.

In a nutshell, I believe your input falls within the very useful categories. Please continue. For instance, if there are other terms that may be outdated, flag them and let us know.

Thanks a lot!

Michael

Von: Tommy Pauly<mailto:[email-masked]>
Gesendet: Sonntag, 28. Juli 2019 03:44
An: Scharf, Michael<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Betreff: Re: [tcpm] Please review 793bis!

Hi Michael,

Best
Tommy

---

From: <[email-masked]>
Date: Mon, 29 Jul 2019 09:35:30 +0000

Hi all, 

Please find below some very minor comments to enhance the readability of the document:

* Consider moving Section 2.1 to be listed under Section 3.

* Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned with https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a special meaning: "Reserved:  Not assigned and not available for assignment.")

* Add a pointer to the "TCP Header Flags" registry: https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml  

* Add an IANA action to update the above registry to include all TCP flags, not only those in 3168. Also, the description text in that page should be reworked, IMHO. Unassigned bits should also be indicated as such in that page.

I would like to have those referenced in that page rather than having documents requiring access to these bits to duplicate the effort: see for example  RFC8519 (look for "reserved" and "flags" in Page 33).

* Position titles right after figure #, e.g., 

OLD:

                               TCP Header Format

             Note that one tick mark represents one bit position.

                                 Figure 1

NEW:

             Note that one tick mark represents one bit position.

                                 Figure 1: TCP Header Format

* Introduce some notations used in the document (and a pointer to Appendix B), e.g., 

     The window size MUST be treated as an unsigned number, or else
     large window sizes will appear like negative windows and TCP will
     now work (MUST-1) .  It is RECOMMENDED that implementations will
              ^^^^^^^^
     reserve 32-bit fields for the send and receive window sizes in the
     connection record and do all window computations with 32 bits (REC-
                                                                    ^^^^
     1 ).

Idem for SHLD-, etc. 

* Section 3.1

OLD:

     The checksum also covers a pseudo header conceptually prefixed to
     the TCP header.  The pseudo header is 96 bits for IPv4 and 320 bits
     for IPv6.  For IPv4, this pseudo header contains the Source
     Address, the Destination Address, the Protocol, and TCP length.

NEW:
     The checksum also covers a pseudo header conceptually prefixed to
     the TCP header.  The pseudo header is 96 bits for IPv4 and 320 bits
     for IPv6.  For IPv4, this pseudo header contains the Source
     Address, the Destination Address, the Protocol (PTCL), and TCP length.
                                                    ^^^^^^ 

* Section 3.1: Add missing figure legend, e.g., 

                   +--------+--------+--------+--------+
                   |           Source Address          |
                   +--------+--------+--------+--------+
                   |         Destination Address       |
                   +--------+--------+--------+--------+
                   |  zero  |  PTCL  |    TCP Length   |
                   +--------+--------+--------+--------+

* Section 3.3:

OLD: 
 The synchronization requires each side to send it's own initial

NEW:
 The synchronization requires each side to send its own initial
 
Cheers,
Med

> -----Message d'origine-----
> De : tcpm [mailto:[email-masked]] De la part de Scharf, Michael
> Envoyé : vendredi 26 juillet 2019 17:17
> À : [email-masked]
> Objet : [tcpm] Please review 793bis!
> 
> Hi all,
> 
> As discussed at IETF 105, we need reviews of draft-ietf-tcpm-rfc793bis in
> order to complete this important TCPM milestone. The draft can be found
> at:
>

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 29 Jul 2019 14:53:45 -0400

Thanks for looking at this, and trying to figure out how to make it feel 
less dated.

I fully agree with you that people doing new implementations are one of 
the important targets for doing this work.  When we initially adopted 
it, we mentioned IoT and userspace code as being likely to "get it 
wrong" if people needed to slog through 793 + 1122 + errata (if they 
even found them) + all the other relevant RFCs coming later that make 
little tweaks here and there.

At high level, I think purely editorial changes are "ok", but we need to 
be vigilant that they're actually purely editorial!  (actually, one of 
your suggestions below is not quite technically correct, so it is a good 
example of how this is harder than it seems and innocent mistakes are 
easy to creep in ... I have tried to avoid it as much as possible for 
exactly this reason)

More specific thoughts on your examples below:

> - Structure; there is both a Terminology section (3.2) relatively early on, and a glossary (3.11) near the end. It seems more typical nowadays to have a terminology section up front, and just refer…

These are a bit different, and the section 3.2 labelled "terminology" 
really is more of a quick overview of a few of the variables that 
reoccur frequently, along with the state machine states.  It could be 
split into subsections like "Key Connection State Variables" and "State 
Machine Overview", if that would be more clear (and that would be purely 
editorial).  The glossary is more like an actual terminology section ... 
whether it goes up front or not is not something I have a strong opinion 
on. Personally, I have never liked the style in some more recent RFCs 
where terms are defined before a reader has much clue what they're 
relevant to, so have slight preference to leave it alone at the end.

> - Many of the RFCs referenced are the older or obsoleted versions

Those cases should probably be fixed, unless there is a reason for 
them.  If you indicate them, I'll happily make updates.

> - Consistency and freshness; some of the terminology feels dated, such as "the local and remote socket numbers" for referring to what is called "port numbers" elsewhere in the document and in curre…

That's a case of not rewriting text from 793/1122.  Do you think it 
would confuse anyone?

To correct you though, the socket numbers are not just the port numbers, 
they also include the IP addresses.  That might be something good to put 
in the glossary?  It's explained in RFC 793 at top of page 5 (but this 
was a section of 793 that we originally decided to leave out, because it 
was very basic content that people working in the Internet protocols 
today learn from textbooks - that they didn't have in 1981, so was in 
the RFC, and it would be harder to update accurately with regard to all 
the things that have changed in IP, link layers, other transports, etc, 
in the meantime).

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 29 Jul 2019 14:59:49 -0400

Hi Tim, I think I agree with the spirit of what you're saying, but am 
unsure what you suggest changing.

The abstract and introduction are pretty verbose about the relation to 
793 (why it's being obsoleted) and the history (in what ways it's now 
obsolete), and there are pointers to the TCP roadmap in sections 1 and 2.

Do we need to say things differently somehow?  Any suggestions are welcome.

On 7/27/2019 10:06 PM, Tim Wicinski wrote:
> Tommy
>
> For Implementation advice, I would refer people to the TCP Roadmap 
> document (rfc7414) which feels to me to be a better location.
> I noticed on reading through the document structure, there are 
> references to RFC793, yet the document is being Obsoleted.
> If we're obsoleting an entire document, is it wise to refer back to 
> it?  Does that confuse a casual reader? If there are references to the
> On Sat, Jul 27, 2019 at 9:44 PM Tommy Pauly 
> <tpauly=[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Michael,
>
>     unfortunately had a conflict for tcpm, so missed the recent
>     meeting, but I do have some questions about what the group wants
>     to see in reviews of this document.
>
>     As expected, much of the text remains unchanged from RFC793. While
>     I understand and agree that it is a non-goal to change any
>     behavior, reading the document does still feel like it is out of
>     place amongst current RFCs from a terminology and organizational
>     standpoint. If this is going to be published as a full STD
>     document, it would be great to have something that also makes the
>     reading clearer and easier for people new to TCP. Specifically, as
>     some people are now working on implementations of TCP for user
>     space stacks or minimal IoT devices, a clean reference would be a
>     fantastic asset.
>
>     - Structure; there is both a Terminology section (3.2) relatively
>     early on, and a glossary (3.11) near the end. It seems more
>     typical nowadays to have a terminology section up front, and just
>     refer inline to supporting documents (like IP, for example).
>     - Consistency and freshness; some of the terminology feels dated,
>     such as "the local and remote socket numbers" for referring to
>     what is called "port numbers" elsewhere in the document and in
>     current parlance.
>
>     There's a lot of possible work to be done here, so before people
>     embark on such reviews, can you clarify which of these categories
>     of input are useful, and would be incorporated?
>
>     Best
>     Tommy
>
>     > On Jul 26, 2019, at 11:17 AM, Scharf, Michael
>     <Michael.Scharf@hs-esslingen..de
>     <mailto:[email-masked]>> wrote:
>     >
>     > Hi all,
>     >
>     > As discussed at IETF 105, we need reviews of
>     draft-ietf-tcpm-rfc793bis in order to complete this important TCPM
>     milestone. The draft can be found at:
>     >
>     > If you care about TCP (after all you have decided to subscribe
>     the TCPM list for some reason, no?), please try to find some
>     cycles and please have a look at this document.
>     >
>     > Thanks
>     >
>     > Michael
>     >
>     > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 29 Jul 2019 12:06:32 -0700

> On Jul 29, 2019, at 11:53 AM, Wesley Eddy <[email-masked]> wrote:
> 
> Thanks for looking at this, and trying to figure out how to make it feel less dated.
> 
> I fully agree with you that people doing new implementations are one of the important targets for doing this work.  When we initially adopted it, we mentioned IoT and userspace code as being likely to "get it wrong" if people needed to slog through 793 + 1122 + errata (if they even found them) + all the other relevant RFCs coming later that make little tweaks here and there.
> 
> At high level, I think purely editorial changes are "ok", but we need to be vigilant that they're actually purely editorial!  (actually, one of your suggestions below is not quite technically correct, so it is a good example of how this is harder than it seems and innocent mistakes are easy to creep in ... I have tried to avoid it as much as possible for exactly this reason)

Yes, I absolutely agree that it's critical to make sure that the editorial changes don't change the meaning. These are good opportunities to tease apart the terminology for things that may be confusing to a current audience, as is the example you cite.

> These are a bit different, and the section 3.2 labelled "terminology" really is more of a quick overview of a few of the variables that reoccur frequently, along with the state machine states.  It could be split into subsections like "Key Connection State Variables" and "State Machine Overview", if that would be more clear (and that would be purely editorial).  The glossary is more like an actual terminology section ... whether it goes up front or not is not something I have a strong opinion on. Personally, I have never liked the style in some more recent RFCs where terms are defined before a reader has much clue what they're relevant to, so have slight preference to leave it alone at the end.

+1 to splitting up the terminology section into subsections with titles.

I do agree that just placing the full glossary at the front would be a bit much. Usually, the terminology up front is most useful for defining the most common terms that would otherwise lead to misinterpretation. For example, terms that the glossary defines that are otherwise generic, like "connection", may be good to just define in a rigorous manner up front as what "connection" means in this document.

Some of the other glossary entries are already in the terminology section, like RCV.NXT... it's possible they're not needed twice.

A couple of the glossary entries likely should just be RFC references—such as for FTP and IP.

> Those cases should probably be fixed, unless there is a reason for them.  If you indicate them, I'll happily make updates.

I can run through these in a review pass, yes.
> That's a case of not rewriting text from 793/1122.  Do you think it would confuse anyone?

Yes, I think it is a bit confusing, since it is not a clear definition in the current version of the document, and doesn't reference anything else. It's fairly particular to the environment in which TCP was implemented when designed.
> 
> To correct you though, the socket numbers are not just the port numbers, they also include the IP addresses.  That might be something good to put in the glossary?  It's explained in RFC 793 at top of page 5 (but this was a section of 793 that we originally decided to leave out, because it was very basic content that people working in the Internet protocols today learn from textbooks - that they didn't have in 1981, so was in the RFC, and it would be harder to update accurately with regard to all the things that have changed in IP, link layers, other transports, etc, in the meantime).

That's a great clarification to make. I don't see exactly how the previous explanation in RFC 793 on page 5 introduces the concept of a "socket number" particularly. I get that a local socket structure contains both the local/remote ports and addresses, and there is also a local fd number allocated to the socket, but there generally isn't just one "remote socket number" that represents both a port and address in my experience.

Elaborating the text to say that the TCB contains the local address, local port, remote address, and remote port, would be the most clear, I would argue.

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 29 Jul 2019 15:28:55 -0400

Wes

I've been staring at this one sentence

   It does not replicate or attempt to update the introduction
   and philosophy content in RFC 793
<https://tools.ietf.org/html/rfc793> (sections 1
<https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-1>
and 2 <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-2>
of *that*
   document).

The 793 link is the link to 793, but sections 1 & 2 are linked to this
document.
Is the intention to link to the older document, or to the -bis document?
That would help clear up "that document" or "this document" to me.

Back in Section 1:

    RFC 793 <https://tools.ietf.org/html/rfc793> and other updates also contain
   informative and descriptive text for human readers to understand
   aspects of the protocol design and operation.  This document does not
   attempt to alter or update this informative text, and is focused only
   on updating the normative protocol specification.

in DNSOP we struggled with this same question recently with 2845-bis
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc2845bis/
Initially, the idea was to make as few a changes as possible to the
document,
just make minor fixes.  But it became clear part of the reason there was an
issue with implementation was poor wording in the original document.
Sadly, I have no simple answers.

On Mon, Jul 29, 2019 at 2:59 PM Wesley Eddy <[email-masked]> wrote:

> The abstract and introduction are pretty verbose about the relation to 793
> (why it's being obsoleted) and the history (in what ways it's now
>> There's a lot of possible work to be done here, so before people embark
>> on such reviews, can you clarify which of these categories of input are
>> > On Jul 26, 2019, at 11:17 AM, Scharf, Michael <
>> Michael.Scharf@hs-esslingen..de <[email-masked]>> wrote:
>> >
>> > Hi all,
>> >
> tcpm mailing [email-masked]://www.ietf.org/mailman/listinfo/tcpm
>
>

---

From: Tim Wicinski <[email-masked]>
Date: Mon, 29 Jul 2019 15:31:48 -0400

And I don't want to bike shed all the non-normative language.
So I'm going to chew on this for awhile.

Tim

On Mon, Jul 29, 2019 at 3:28 PM Tim Wicinski <[email-masked]> wrote:

>    and philosophy content in RFC 793 <https://tools.ietf.org/html/rfc793> (sections 1 <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-1> and 2 <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-2> of *that*
>    document).
>
>
>>> - Consistency and freshness; some of the terminology feels dated, such
>>> as "the local and remote socket numbers" for referring to what is called
>>> "port numbers" elsewhere in the document and in current parlance.
>>>
>>> > If you care about TCP (after all you have decided to subscribe the
>>> TCPM list for some reason, no?), please try to find some cycles and please
>>> have a look at this document.
>>> >
>>> > Thanks
>>> >
>>> > Michael
>>> >

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 29 Jul 2019 15:33:36 -0400

Many thanks for your comments; my thoughts are below:

> * Consider moving Section 2.1 to be listed under Section 3.

Either way is fine with me; does anyone have strong preference? The 
section numbering is closer to the original 793 numbering currently, and 
this would probably bump that, but that is a very trivial concern.

> * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned with https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a special meaning: "Reserved:  Not assigned and not availa…

Thanks; I'll have to look at this in all cases and make sure we "do the 
right thing".  I hadn't really been aware of 8126.

> I would like to have those referenced in that page rather than having documents requiring access to these bits to duplicate the effort: see for example  RFC8519 (look for "reserved" and "flags" in…

Good point.  3168 created the registry, but then didn't fully populate 
it with the bits that 793 had defined.

>                                   Figure 1: TCP Header Format

Also a good idea ... I will make this change, unless anyone shouts.

>       connection record and do all window computations with 32 bits (REC-

Good point.  It seems like explaining this in the introduction will work.

> * Section 3.1: Add missing figure legend, e.g.,

Many thanks; all of the above suggestions look good to me.

---

From: Wesley Eddy <[email-masked]>
Date: Mon, 29 Jul 2019 15:49:49 -0400

On 7/29/2019 3:28 PM, Tim Wicinski wrote:
>     and philosophy content inRFC 793  <https://tools.ietf.org/html/rfc793>  (sections1  <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-1>  and2  <https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-2>  of*that*
>     document).
Aha! So, that hyperlinking appears to be a crazy thing that the IETF web 
tool for presenting HTML incorrectly inferred.  The XML source does not 
contain hyperlinks for those numbers.  Not sure how to fix ...

> Sadly, I have no simple answers.
Thanks for the perspective ... I'm hopeful that the most problematic 
parts of 793 in this regard have been fixed already in 1122 and 
elsewhere, and that by pasting in those updates, we've already handled 
them, but I guess will have to assess on a case-by-case basis.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Mon, 29 Jul 2019 13:35:43 -0700 (PDT)

> this would probably bump that, but that is a very trivial concern.

I would counter that section renumbering breaks all external
references to this document by section number and should probably
be avoided at all cost.

As an example if someone wrote someplace "See section 2.1 of rfc793",
that reference would be broken, other than the new document is called
rfc793bis, that may be lost on the seeker of the information.

A search of the RFCs for section references to 793 could be attempted.

> right thing".? I hadn't really been aware of 8126.

Though I am new here and may be wrong on this,
8126 is about IANA considerations and should, if I am
reading it correctly, only be apply to text in the IANA
consideration section of an RFC and not to the whole
body of it.

I especially do not like the definition of
Reserved as stated in 8126, that is more than reserved,
it is immutable.  But that is for the topic of another
draft.

> Good point.? 3168 created the registry, but then didn't fully populate 

This is probably of historical cause, 793 being a very early RFC.
It would be wrong of 3168 to populate anything
other than 3168 bits, but I see 793bis as populating
the other bits of TCP as a proper and needed update.

> Good point.? It seems like explaining this in the introduction will work.
> 
> 
> > * Section 3.1
> >
> > OLD:
> >

Indeed.

-- 
Rod Grimes                                                 [email-masked]

---

From: <[email-masked]>
Date: Tue, 30 Jul 2019 05:38:38 +0000

Hi Rodney, 

Please see iline. 

Cheers,
Med

> De : Rodney W. Grimes [mailto:[email-masked]]
> Envoyé : lundi 29 juillet 2019 22:36
> À : Wesley Eddy
> Cc : [email-masked]; BOUCADAIR Mohamed TGI/OLN
> Objet : Re: [tcpm] Please review 793bis!
> 

[Med] Hmm, there is no such 2.1 in RFC793:

RFC793

1.  INTRODUCTION ..................................................... 1

  1.1  Motivation .................................................... 1
  1.2  Scope ......................................................... 2
  1.3  About This Document ........................................... 2
  1.4  Interfaces .................................................... 3
  1.5  Operation ..................................................... 3

2.  PHILOSOPHY ....................................................... 7

  2.1  Elements of the Internetwork System ........................... 7
  2.2  Model of Operation ............................................ 7
  2.3  The Host Environment .......................................... 8
  2.4  Interfaces .................................................... 9
  2.5  Relation to Other Protocols ................................... 9
  2.6  Reliable Communication ........................................ 9
  2.7  Connection Establishment and Clearing ........................ 10
  2.8  Data Communication ........................................... 12
  2.9  Precedence and Security ...................................... 13
  2.10 Robustness Principle ......................................... 13

3.  FUNCTIONAL SPECIFICATION ........................................ 15

RFC793bis

   1.  Purpose and Scope . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Key TCP Concepts  . . . . . . . . . . . . . . . . . . . .   5
   3.  Functional Specification  . . . . . . . . . . . . . . . . . .   5

I think that Wes tried to preserve the overall structure of Section 3.  

> > > * Rsrvd - Reserved:  s/Reserved/Unassigned. This is to be aligned with
> https://tools.ietf.org/html/rfc8126#section-6 (reserved in 8126 has a
> special meaning: "Reserved:  Not assigned and not available for
> assignment.")
> >

[Med] It will be weird to use "Reserved" in the main text and "Unassigned" in the IANA section. Following RFC8126 would be my favorite here.   

> > > * Add a pointer to the "TCP Header Flags" registry:
> https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
> > >
> > > * Add an IANA action to update the above registry to include all TCP
> flags, not only those in 3168. Also, the description text in that page
> should be reworked, IMHO. Unassigned bits should also be indicated as such
> in that page.
> > >
> > > I would like to have those referenced in that page rather than having
> documents requiring access to these bits to duplicate the effort: see for
> example  RFC8519 (look for "reserved" and "flags" in Page 33).
> >

[Med] There is nothing wrong with another RFC than 793 to create and initialize the flags registry. 

> the other bits of TCP as a proper and needed update.

[Med] Hence the need to fix the registry rather than leaving it incomplete.

---

From: "Rodney W. Grimes" <[email-masked]>
Date: Tue, 30 Jul 2019 06:09:30 -0700 (PDT)

Hello Med,
Replied inline, trying to get this style, so pardon any
mistakes I may be making.

Regards,
Rod

> > De?: Rodney W. Grimes [mailto:[email-masked]]
> > Envoy??: lundi 29 juillet 2019 22:36
> > ??: Wesley Eddy
> > Cc?: [email-masked]; BOUCADAIR Mohamed TGI/OLN
> > Objet?: Re: [tcpm] Please review 793bis!
> > 

 [RWG] If infact the author "moves" section 2.1 to be under 3
in the draft in effect 2.1 would either go away, or become
something different.

> [Med] Hmm, there is no such 2.1 in RFC793:

 [RWG] Perhaps another cup of coffee?  :-)
 
>   2.1  Elements of the Internetwork System ........................... 7

 [RWG] This does look to be a section 2.1 to me, did you miss it?

> I think that Wes tried to preserve the overall structure of Section 3.  

 [RWG] I am concerned about historical references to this document in
such things as code, text books, and other RFC's, but without solid
evidence to that effect I have little ground to stand on.

On the other hand I should further investigate:
./sys/netinet/tcp_fsm.h: * Per RFC793, September, 1981.
./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria for accepting SYN packets");
./sys/netinet/tcp_input.c:    "Follow RFC793 instead of RFC5961 criteria for accepting RST packets");
./sys/netinet/tcp_input.c:               * is equivalent to the smoothing algorithm in rfc793 with
./sys/netinet/tcp_input.c:               * equivalent to rfc793 smoothing with an alpha of .75
./sys/netinet/tcp_input.c:               * rfc793's wired-in beta.
./sys/netinet/tcp_syncache.c:    * See RFC 793 page 65, section SEGMENT ARRIVES.
./sys/netinet/tcp_syncache.c:    * RFC 793 page 37:

I do understand that the document name is changing, but how to make
it clear to a person reading the code above and pulling up 793bis that they
should be looking to 793 is unclear to me at this point in time.

Is it possible to use the datatracker to see the changes
from rfc793 to rfc793bis?

What about a section on "what has changed, added, and/or removed",
usually when a specification evolves over time there is a history
section that itemizes the changes.  This may be asking for far too
much in this case though.

> [Med] It will be weird to use "Reserved" in the main text and "Unassigned" in the IANA section. Following RFC8126 would be my favorite here.   

 [RWG] Have it read "Unassigned" in the spec that has almost 40
years of running code that call it rsrvd is of equal
concern from an implementers standpoint.  Any attempt
to back port RFC8126 language into the prior 8000 RFC's seems
difficult.

Should RFC8126 apply to any RFC prior to it unless
explicitly stated in the header of RFC8126?  Or is it the
fact that chrnologically RFC793bis is after 8126 that should
be applied here.  That would require one to have a date order
of issue index to the rfcs?

> [Med] There is nothing wrong with another RFC than 793 to create and initialize the flags registry. 

 [RWG] I think it would be incorrect to do so, it would surely mess up 
the presentation of information in the:
https://www.iana.org/assignments/tcp-header-flags/tcp-header-flags.xhtml
page which has back references to the RFC that had the IANA consideration.

If rfc3168 had populated say the SYN code point, the reference at IANA would
be to rfc3168 and yet in that RFC I would find little information on
the definition of the SYN flag.

> [Med] Hence the need to fix the registry rather than leaving it incomplete.
 [RWG] We fully agree on that

---

From: <[email-masked]>
Date: Tue, 30 Jul 2019 14:21:32 +0000

Re-,

Please see inline. 

Cheers,
Med

> Envoyé : mardi 30 juillet 2019 15:10
> À : BOUCADAIR Mohamed TGI/OLN
> Cc : Rodney W. Grimes; Wesley Eddy; [email-masked]
> > > > > Please find below some very minor comments to enhance the
> readability
> > > of the document:
> > > > >

[Med] I meant there is no "such" text in 793. See below ...

>  [RWG] This does look to be a section 2.1 to me, did you miss it?

[Med] No. The new text in 2.1 of 793bis has nothing to do with this one. If you used to cite that section from 793, then that citation will be broken when RFC793bis will be published. 

> evidence to that effect I have little ground to stand on.

[Med] Your concern is a valid one. There is a trade-off out there: readability vs. how to easily identify changes.

> from rfc793 to rfc793bis?

[Med] I'm afraid the diff provided by the datatracker is not helpful: https://www.ietf.org/rfcdiff?url1=rfc793&url2=draft-ietf-tcpm-rfc793bis-13. 

> What about a section on "what has changed, added, and/or removed",

[Med] There is already one: Please refer to https://tools.ietf.org/html/draft-ietf-tcpm-rfc793bis-13#section-4   

> > [Med] It will be weird to use "Reserved" in the main text and
> "Unassigned" in the IANA section. Following RFC8126 would be my favorite
> here.
> 

[Med] The name of the field can be maintained as it is. No need to change it to "UUUU". The change will be in the main text, e.g.,:

OLD: 

   Rsrvd - Reserved:  4 bits

     Reserved for future use.  Must be zero in generated segments and
     must be ignored in received segments, if corresponding future
     features are unimplemented by the sending or receiving host.

NEW:

   Rsrvd - Unassigned:  4 bits

     Not assigned, and available for assignment.  MUST be zero in generated segments and
     MUST be ignored in received segments, if corresponding future
     features are unimplemented by the sending or receiving host.

And in the IANA section:

NEW:
  New flags bits can be assigned via Standards Action [RFC8126].

> of issue index to the rfcs?

[Med] Given that there are pending IANA actions to fix the tcp flags registry, RFC8126 language should be followed.

> the definition of the SYN flag.

[Med] The reference clause of the SYN in such case will need to point to RFC793, not RFC3168. This is straightforward.  

>  [RWG] We fully agree on that

[Med] Great! Thanks.

> > > > >       reserve 32-bit fields for the send and receive window sizes
> in
> > > the
> > > > >       connection record and do all window computations with 32
> bits
> > > (REC-
> > > > >
> > > ^^^^
> > > > >       1 ).
> > > > >
> > > > > Idem for SHLD-, etc.
> > > >
> > > > >       The checksum also covers a pseudo header conceptually
> prefixed
> > > to
> > > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and
> 320
> > > bits
> > > > >       The checksum also covers a pseudo header conceptually
> prefixed
> > > to
> > > > >       the TCP header.  The pseudo header is 96 bits for IPv4 and
> 320
> > > bits
> > > > >       Address, the Destination Address, the Protocol (PTCL), and
> TCP
> > > length.
> > > > >                                                      ^^^^^^
> > > > >