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

[Wesley Eddy <[e-mail]>]

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