Re: [tcpm] Please review 793bis!

Wesley Eddy <wes@mti-systems.com> Mon, 29 July 2019 19:33 UTC

Return-Path: <wes@mti-systems.com>
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 A5C3712002E for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 12:33:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mti-systems-com.20150623.gappssmtp.com
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 G9Ou8O-RijYW for <tcpm@ietfa.amsl.com>; Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
Received: from mail-io1-xd34.google.com (mail-io1-xd34.google.com [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75C5120025 for <tcpm@ietf.org>; Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
Received: by mail-io1-xd34.google.com with SMTP id h6so36108047iom.7 for <tcpm@ietf.org>; Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mti-systems-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=g/pxeUs/6XHNYqvrpdRxZML7b+91Wc7zW7IcNFeOGWg=; b=gfo5/nJxB7L4msuZ23FoZZfXH3w2d/26vQVqdLTND0su8jIN7HHYRKGv5217GgfpWF jSOtoIdq2KzXvmV7GbGEz8MwPqdM6gVXU1n5tblGqxYdBHRT5GXuXUCjcIqKrc4GqN+y B2R+dqqm/M+QzTYx7p0INYjMpGsK/N5mrRdUN2grJhnC5fwxFAMefHXGzyrqqjK57kar a2ngjMksgvmB60DoA8VFt7JPTb11iAHCRjTxt839P3scvdDAlM0Tj0tPnTssiBN2fBiK 7/mC8TFe/b89Pi6y92srpyaWW0HkqXB5AKiap47iTbvXtExplFwPFHiE2NTjudBJQUSx TdEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=g/pxeUs/6XHNYqvrpdRxZML7b+91Wc7zW7IcNFeOGWg=; b=fsERnfYy5SDPQCJ0p/Coa8QNf1H5tFr6fJ5lmfIOhoejIGxE0iQnaMpTwvCC4ZyC2I tjroCCRqpz2f8xk/lfCjr2k4oBgfeXIFGN/WTe8VfAfJjtSE1DxkN3p/6XisJCC+DZe9 D0SKNLPddhRS2+bl6vQIQml/I43U0N4V+in3IpRuyOhAWFoGxHiOQN1EKZhNCCDjtH6Z uKu3AdZfe7+WzskHS4x5u1A0WWnntHv8JSs0RR8ukoLyWvfuUSUflXt2lexbY1lQSk6s taBjXmTV5WcFNcuNOV9AGb6krxoa52n/UOb18BE1K/K9oR7OelivJCW1pSyw4zFWATW0 q90w==
X-Gm-Message-State: APjAAAWSEqGj7PKoD4UxAR8ocKWmuIG7ep65NYPtycpBxVhRZOkm2dGA 21gMac80xrOw022DBiYHeMk=
X-Google-Smtp-Source: APXvYqynwGPNZnClDJbNhOBpLoRlDqDWvG9OAFQa1/oMv0BPdiUha3wwGadDF7KPnxtcghUC8cBnHg==
X-Received: by 2002:a6b:8bcb:: with SMTP id n194mr3002921iod.194.1564428819008; Mon, 29 Jul 2019 12:33:39 -0700 (PDT)
Received: from [192.168.1.119] (rrcs-69-135-1-122.central.biz.rr.com. [69.135.1.122]) by smtp.gmail.com with ESMTPSA id b3sm53318415iot.23.2019.07.29.12.33.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Jul 2019 12:33:38 -0700 (PDT)
To: tcpm@ietf.org, mohamed.boucadair@orange.com
References: <6EC6417807D9754DA64F3087E2E2E03E2D3CB17C@rznt8114.rznt.rzdir.fht-esslingen.de> <787AE7BB302AE849A7480A190F8B9330312EA496@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
From: Wesley Eddy <wes@mti-systems.com>
Message-ID: <a76f089a-71c2-cccf-54ea-55244243f780@mti-systems.com>
Date: Mon, 29 Jul 2019 15:33:36 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <787AE7BB302AE849A7480A190F8B9330312EA496@OPEXCAUBMA2.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/y_A1F8xzwTMV5qqFodgJGj8WjSQ>
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 19:33:42 -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.


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


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


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