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

[Jean Mahoney <[e-mail]>]

Thank you, Wesley! We have noted your approval on the AUTH48 status page:

https://www.rfc-editor.org/auth48/rfc9293

We'll await word from Martin regarding the creation of a Contributors 
section at the end of the document to capture Postel's and Oppermann's 
contributions.

Best regards,

RFC Editor/jm

On 8/10/22 7:28 PM, Wesley Eddy wrote:
>
> I approve.  The document looks great; thank you for your work on it 
> and the many improvements!
>
>
> On 8/3/2022 5:44 PM, Jean Mahoney wrote:
>> Martin,
>>
>> Thank you for your reply. We have added the text that required your 
>> approval:
>>
>> https://www.rfc-editor.org/authors/rfc9293-lastrfcdiff.html (these 
>> 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'll await word from you and Wesley regarding other changes and/or 
>> approval.
>>
>> Best regards,
>>
>> RFC Editor/jm
>>
>> On 8/3/22 11:41 AM, Martin Duke wrote:
>>> I approve.
>>>
>>> On Fri, Jul 29, 2022 at 11:17 AM Jean Mahoney <[e-mail]> wrote:
>>>
>>>     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 <http://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 <http://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).
>>>>
>>>>
>>