Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9293 <draft-ietf-tcpm-rfc793bis-28> for your review

Jean Mahoney <jmahoney@amsl.com> Fri, 29 July 2022 18:17 UTC

Return-Path: <jmahoney@amsl.com>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86831C159485; Fri, 29 Jul 2022 11:17:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.209
X-Spam-Level:
X-Spam-Status: No, score=-4.209 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8aQ75wBRn25; Fri, 29 Jul 2022 11:17:16 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C8E2C14CF1E; Fri, 29 Jul 2022 11:16:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 633CA424B44B; Fri, 29 Jul 2022 11:16:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eahe868Ukg5P; Fri, 29 Jul 2022 11:16:34 -0700 (PDT)
Received: from [192.168.1.203] (unknown [47.186.48.51]) by c8a.amsl.com (Postfix) with ESMTPSA id 05850424B440; Fri, 29 Jul 2022 11:16:33 -0700 (PDT)
Content-Type: multipart/alternative; boundary="------------HousXRZohWT9L6CEykY4u0Bl"
Message-ID: <0fd6dab2-a186-a81f-210d-f05adb830d9a@amsl.com>
Date: Fri, 29 Jul 2022 13:16:33 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
Content-Language: en-US
To: Wesley Eddy <wes@mti-systems.com>, rfc-editor@rfc-editor.org
Cc: tcpm-ads@ietf.org, tcpm-chairs@ietf.org, michael.scharf@hs-esslingen.de, auth48archive@rfc-editor.org
References: <20220715224748.2A6E92029F@rfcpa.amsl.com> <677ac4da-4a57-e21a-c103-8f4224c37527@mti-systems.com> <46b14f92-300d-271e-2631-7343821ce540@amsl.com> <b24221f4-46f9-1503-e3b2-94d4340bdcb9@mti-systems.com>
From: Jean Mahoney <jmahoney@amsl.com>
In-Reply-To: <b24221f4-46f9-1503-e3b2-94d4340bdcb9@mti-systems.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/EzJLb22SVK4v9xP43pAQIjIvKUA>
Subject: Re: [auth48] [AD] Re: AUTH48: RFC-to-be 9293 <draft-ietf-tcpm-rfc793bis-28> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Jul 2022 18:17:20 -0000

Wesley,

Thanks for your reply. We've updated the document:

https://www.rfc-editor.org/authors/rfc9293-lastrfcdiff.html (these 
changes side by side)

Regarding the spelling of "acknowledgment", we discovered that we had 
already made that change (and that change was highlighted in question 
56a). Apologies for any confusion caused by asking about it again.

https://www.rfc-editor.org/authors/rfc9293.txt
https://www.rfc-editor.org/authors/rfc9293.pdf
https://www.rfc-editor.org/authors/rfc9293.html
https://www.rfc-editor.org/authors/rfc9293.xml
https://www.rfc-editor.org/authors/rfc9293-diff.html (all changes inline)
https://www.rfc-editor.org/authors/rfc9293-rfcdiff.html (all changes 
side by side)
https://www.rfc-editor.org/authors/rfc9293-auth48diff.html (all AUTH48 
changes inline)


We'll await word from you and the ADs regarding other changes and/or 
approval.

Best regards,

RFC Editor/jm


On 7/29/22 11:20 AM, Wesley Eddy wrote:
>
> Thank you; replies are below:
>
>
> On 7/28/2022 6:45 PM, Jean Mahoney wrote:
>>
>> *AD, please see the Wesley's questions at the bottom of this message.
>>
>> Wesley,
>>
>> Thank you for your response. We have updated the document with your 
>> feedback:
>>
>> https://www.rfc-editor.org/authors/rfc9293-lastrfcdiff.html (this 
>> changes side by side)
>>
>> https://www.rfc-editor.org/authors/rfc9293.txt
>> https://www.rfc-editor.org/authors/rfc9293.pdf
>> https://www.rfc-editor.org/authors/rfc9293.html
>> https://www.rfc-editor.org/authors/rfc9293.xml
>> https://www.rfc-editor.org/authors/rfc9293-diff.html (all changes inline)
>> https://www.rfc-editor.org/authors/rfc9293-rfcdiff.html (all changes 
>> side by side)
>> https://www.rfc-editor.org/authors/rfc9293-auth48diff.html (all 
>> AUTH48 changes inline)
>>
>>
>> We also have two new questions and a followup question:
>>
>> 1) <!-- [rfced] Section 3.9.1.1: Please review the placement of 
>> commas in the
>> following. We note that "local IP address," has a comma following it, but
>> the other options have the comma before.
>>
>> Current:
>>
>>       Format: OPEN (local port, remote socket, active/passive [,
>>       timeout] [, Diffserv field] [, security/compartment] [local IP
>>       address,] [, options]) -> local connection name
>> -->
>>
> You're correct, the comment should be before, as with the other 
> optional parameters.
>
>
>> 2) <!-- [rfced] Sections 3.9.1.2 and 3.9.1.3: In the following format 
>> statements,
>> should square brackets be used to indicate optional items? FYI, we have
>> updated "push flag" to "PUSH flag" and "urgent flag" to "URGENT flag" in
>> the second format statement.
>>
>> Current:
>>
>>    Format: SEND (local connection name, buffer address, byte count,
>>    PUSH flag (optional), URGENT flag [,timeout])
>>    ...
>>
>>    Format: RECEIVE (local connection name, buffer address, byte
>>    count) -> byte count, URGENT flag, PUSH flag (optional)
>> -->
>>
> Yes, I think this is a good idea for consistency within the document, 
> thank you.
>
> I think that would be:
>
>     Format: SEND (local connection name, buffer address, byte count, URGENT flag [, PUSH
>     flag] [, timeout])
>
>     Format: RECEIVE (local connection name, buffer address, byte count)
>     -> byte count, URGENT flag [, PUSH flag]
>
>
>
>> 3) <!-- [rfced] Terminology:
>>
>> b) The following are used inconsistently. The number of instances are 
>> provided in parentheses. Please let us know how we can make these 
>> terms consistent.
>>
>> acknowledgement (13) / acknowledgment (66)
>>
>> -->
>>
> I noticed in older RFCs there is a mixture, but in newer ones the 
> spelling without the extra 'e' seems prevalent.  So, lets go with 
> "acknowledgment" (with one exception in the references list, where 
> it's spelled with the extra 'e' in the title of RFC 2883).
>
>