Re: [tcpm] Additional editorial comments on draft-ietf-tcpm-rfc793bis-20

tuexen@fh-muenster.de Thu, 27 May 2021 17:22 UTC

Return-Path: <tuexen@fh-muenster.de>
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 8B3C93A0BFD for <tcpm@ietfa.amsl.com>; Thu, 27 May 2021 10:22:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.481
X-Spam-Level:
X-Spam-Status: No, score=-1.481 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.398, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=no 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 0eo2Gs5H_OeP for <tcpm@ietfa.amsl.com>; Thu, 27 May 2021 10:22:53 -0700 (PDT)
Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4FAB03A0BF6 for <tcpm@ietf.org>; Thu, 27 May 2021 10:22:52 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2a02:8109:1140:c3d:35ee:a4bc:42a:c2e5]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AF9C6721A5A66; Thu, 27 May 2021 19:22:43 +0200 (CEST)
From: tuexen@fh-muenster.de
Message-Id: <2C7C260A-302C-42FE-A98D-4E04D8287A86@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_3354F697-42CF-43AD-B5A5-37345F008E52"; protocol="application/pkcs7-signature"; micalg="sha-256"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Thu, 27 May 2021 19:22:42 +0200
In-Reply-To: <3ece7e28-c247-f980-3f31-5ea64314fff3@mti-systems.com>
Cc: tcpm@ietf.org
To: Wesley Eddy <wes@mti-systems.com>
References: <62b0a3c2-3ec5-c3d9-7a1c-909e11a23d0c@erg.abdn.ac.uk> <3ece7e28-c247-f980-3f31-5ea64314fff3@mti-systems.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpm/PBJptbk_cPJGGEmxR8R0_DVZcfE>
Subject: Re: [tcpm] Additional editorial comments on draft-ietf-tcpm-rfc793bis-20
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: Thu, 27 May 2021 17:22:58 -0000

> On 17. May 2021, at 16:34, Wesley Eddy <wes@mti-systems.com> wrote:
> 
> On 3/12/2021 5:13 AM, Gorry Fairhurst wrote:
>> I did some very careful reading of a few sections of  rfc793bis, and have additional some late editorial comments.
>> 
>> I suspect these really are minor, but I'd hope worthwhile:
>> 
>> ---
>> 
>> (1a) The text uses /may not/, in these two places:
>> 
>> /Note that some options may not be included on all segments/
>> 
>> - I wonder if this is umambiguous to all English speakers (it's not so clear to me), I think it could be better as
>> 
>> /Note that some options might not be included on all segments/
>> 
>> or ...
>> 
>> /Some of the segments might not include include all options/
>> 
>> ... of something like that this?
>> 
>> ---
>> 
>> (1b) I'd suggest similarly avoiding /may not/ in the description of IP Option processing.
>> 
>> ---
>> 
>> (2) The document seems to be missing an IPv6 "view" of extensions in the IP Options part, section 3.6.1 (This is mentioned in the pseudo-header compuation). I suggest we add a brief sentence saying the calculation of "IPv6 Extension Headers" follows thar for IP Option size.
> 
> 
> I missed your couple of comments above in the prior -21 revision, but Michael S. reminded me of them, and I've incorporated them into the -22 revision just posted.  On the IPv6 comment, I changed the notion of "IP options" in a couple of places to "IPv4 options or IPv6 extension headers" which I think accomplishes the right thing.
Hi Wes,

I just noted one typo on page 73:

OLD TEXT:

         fourth check the SYN bit

            This step should be reached only if the ACK is ok, or there
            is no ACK, and it the segment did not contain a RST.


NEW TEXT:

         fourth check the SYN bit

            This step should be reached only if the ACK is ok, or there
            is no ACK, and if the segment did not contain a RST.
                           ^^

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