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

tuexen@fh-muenster.de Thu, 03 June 2021 09:47 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 80EA53A31DB for <tcpm@ietfa.amsl.com>; Thu, 3 Jun 2021 02:47:47 -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 jQeHscEgGWSq for <tcpm@ietfa.amsl.com>; Thu, 3 Jun 2021 02:47:43 -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 C33EA3A3211 for <tcpm@ietf.org>; Thu, 3 Jun 2021 02:47:42 -0700 (PDT)
Received: from smtpclient.apple (ip-109-42-0-103.web.vodafone.de [109.42.0.103]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id AE9F87220B804; Thu, 3 Jun 2021 11:47:35 +0200 (CEST)
From: tuexen@fh-muenster.de
Message-Id: <025CE34B-A2DC-409C-9A2B-B5D7A4E826B1@fh-muenster.de>
Content-Type: multipart/signed; boundary="Apple-Mail=_F7EDBFC6-0017-4865-AAA8-C4C31F55ADFC"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
Date: Thu, 3 Jun 2021 11:47:34 +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/QYt5R-lzJ6uzupfx5KRa3HePcv4>
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, 03 Jun 2021 09:47:48 -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 found one more issue on page 79/80.

OLD
               SYN-RECEIVED STATE

                  If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED
                  state and continue processing with variables below set
                  to:

                     SND.WND <- SEG.WND
                     SND.WL1 <- SEG.SEQ
                     SND.WL2 <- SEG.ACK

                     If the segment acknowledgment is not acceptable,
                     form a reset segment,

                        <SEQ=SEG.ACK><CTL=RST>

                     and send it.
NEW
               SYN-RECEIVED STATE

                  If SND.UNA < SEG.ACK =< SND.NXT then enter ESTABLISHED
                  state and continue processing with variables below set
                  to:

                     SND.WND <- SEG.WND
                     SND.WL1 <- SEG.SEQ
                     SND.WL2 <- SEG.ACK

                  If the segment acknowledgment is not acceptable,
                  form a reset segment,

                     <SEQ=SEG.ACK><CTL=RST>

                  and send it.

The change is only the indentation of the last sentence.

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