Re: [tcpm] Please review 793bis!

"Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net> Mon, 29 July 2019 20:35 UTC

Return-Path: <4bone@gndrsh.dnsmgr.net>
X-Original-To: tcpm@ietfa.amsl.com
Delivered-To: tcpm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B72F120045 for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 13:35:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9jBCDpHyBVg for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 13:35:45 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6311C120043 for <tcpm@ietf.org>; Mon, 29 Jul 2019 13:35:45 -0700 (PDT)
Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x6TKZhpk045946; Mon, 29 Jul 2019 13:35:43 -0700 (PDT) (envelope-from 4bone@gndrsh.dnsmgr.net)
Received: (from 4bone@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x6TKZhQx045945; Mon, 29 Jul 2019 13:35:43 -0700 (PDT) (envelope-from 4bone)
From: "Rodney W. Grimes" <4bone@gndrsh.dnsmgr.net>
Message-Id: <201907292035.x6TKZhQx045945@gndrsh.dnsmgr.net>
In-Reply-To: <a76f089a-71c2-cccf-54ea-55244243f780@mti-systems.com>
To: Wesley Eddy <wes@mti-systems.com>
Date: Mon, 29 Jul 2019 13:35:43 -0700 (PDT)
CC: tcpm@ietf.org, mohamed.boucadair@orange.com
X-Mailer: ELM [version 2.4ME+ PL121h (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=US-ASCII
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/mYqZkwL6leU14yA_FX0TRF9-t_8>
Subject: Re: [tcpm] Please review 793bis!
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpm/>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 29 Jul 2019 20:35:47 -0000

> Many thanks for your comments; my thoughts are below:
> 
> On 7/29/2019 5:35 AM, mohamed.boucadair@orange.com wrote:
> > 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.
> 
> 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.

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.

> > * 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.")
> 
> 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.

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.

> 
> > * 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).
> 
> Good point.? 3168 created the registry, but then didn't fully populate 
> it with the bits that 793 had defined.

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.

> > * 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
> 
> Also a good idea ... I will make this change, unless anyone shouts.
> 
> 
> > * 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.
> 
> Good point.? It seems like explaining this in the introduction will work.
> 
> 
> > * 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
> 
> Many thanks; all of the above suggestions look good to me.

Indeed.

> _______________________________________________
> tcpm mailing list
> tcpm@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
Rod Grimes                                                 rgrimes@freebsd.org