[auth48] Re: [AD] Re: AUTH48: RFC-to-be 9693 <draft-ietf-bmwg-benchmarking-stateful-09> for your review

["Dr. Lencse Gábor" <[e-mail]>]

Dear Alanna Paloma,

Now I reply to your e-mail on "Mon, 09 December 2024 20:05 UTC". I copy here the text fromauth48archive and put my answers into "<GL> </GL>" tags.

---- Copied text starts here ----

Hi Gábor and Warren (AD)*,

*Warren - As the AD, please review and approve of the updated key word in Section 4.4:

Original:
    [RFC4814] REQUIRES pseudorandom port numbers, which the authors
    believe is a good approximation of the distribution of the source
    port numbers a NATxy gateway on the Internet may face with.

Current:
    As described in [RFC4814], pseudorandom port numbers are REQUIRED,
    which the authors believe is a good approximation of the distribution
    of the source port numbers a NATxy gateway on the Internet may be
    faced with.

See this diff file:
  https://www.rfc-editor.org/authors/rfc9693-auth48diff.html  


Gábor - Thank you for your replies.  We have updated as requested.

<GL> Thank you very much for that! </GL>


Please note that we have some follow-up queries.

> But both of them are rather lengthy. Thus, the best title could be simply:
> "Benchmarking Methodology for Stateful NATxy Gateways"
> Rationale: This RFC will be the first one talking about benchmarking of stateleful NAT boxes. The proposed title expresses the topic clearly and it is concise (it does not contain anything unnecessary). It should be noted that the current version is partial: it mentions pseudorandom port numbers but it does not mention pseudorandom IP addresses. This is not logical.
> I discussed it with my co-author, Keiichi Shima and he agrees with the proposed title.
> Is it possible the change the title to this version?

<GL> Thank you for updating the title! </GL>



) As “NATxy” has not appeared in previous RFCs and is defined in the Abstract, may we further update the title?

Current:
    Benchmarking Methodology for Stateful NATxy Gateways

Perhaps:
    Benchmarking Methodology for Stateful NAT Gateways

<GL>

Please rather keep "Stateful NATxy" in the title because changing it to "Stateful NAT" would loose the important information that there can be IP version translation. (IMHO, people would simply think of stateful NAT44 and not of stateful NAT64.)

</GL>


>> 8) <!-- [rfced] For clarity, how may we rephrase "it may be computing efficiently
>> generated by preparing" in the text below?
>> 
>> Original:
>> 
>> It may be computing efficiently generated by preparing a
>> random permutation of the previously enumerated all possible four
>> tuples using Durstenfeld's random shuffle algorithm [DUST1964].
>> 
>> Perhaps:
>> 
>> Efficient computing may be generated by preparing a
>> random permutation of the previously enumerated all possible four
>> tuples using Durstenfeld's random shuffle algorithm [DUST1964].
>> 
>> -->
>> 
> I am sorry, I do not understand your version. I think that the ambiguity was caused in the original text by the first word of the sentence: "It". To that end I would clarify the sentence as follows:
> New:
> Pseudorandom enumeration of all possible four tuples may be computing efficiently generated by preparing a
> random permutation of the previously enumerated all possible four
> tuples using Durstenfeld's random shuffle algorithm [DUST1964].

) We have updated the text per your suggestion; however, “may be computing efficiently generated by…” still reads awkwardly. May we further clarify the text as follows?

Perhaps:
    Pseudorandom enumeration of all possible four tuples may compute efficiently
    by using Durstenfeld’s random shuffle algorithm [DUST1964] to prepare a
    random permutation of the previously enumerated all possible four tuples.

<GL>

I do not understand the recommended text. The problematic part is "four tuples may compute efficiently".

We want to generate a pseudorandom enumeration of something. And we want to do it in an efficient way that we do not use too much computing power.

Therefore, I would rewrite your latest recommendation as follows:

     Pseudorandom enumeration of all possible four tuples may be generated in a computationally efficient way
     by using Durstenfeld’s random shuffle algorithm [DUST1964] to prepare a
     random permutation of the previously enumerated all possible four tuples.

Does it work for you?

(Or "computing efficiently" may be used instead of "in a computationally efficient way", it that sounds better for a native speaker.)


</GL>

> In Section 6.
> 
> ORIGINAL: The table MUST be complemented with reporting the relevant parameters of the DUT. If the DUT is a general-purpose computer and some software NATxy gateway implementation is tested, then the hardware description SHOULD include: computer type, CPU type, and number of active CPU cores, memory type, size and speed, network interface card type (reflecting also the speed), the fact that direct cable connections were used or the type of the switch used for interconnecting the Tester and the DUT.
> 
> EDITED: The table MUST be complemented with reporting the relevant parameters of the DUT. If the DUT is a general-purpose computer and some software NATxy gateway implementation is tested, then the hardware description SHOULD include: the computer type, CPU type and number of active CPU cores, memory type, size and speed, network interface card type (also reflecting the speed), the fact that direct cable connections were used, and the type of the switch used for interconnecting the Tester and the DUT. 
> 
> Here the problem is, that the Tester and the DUT are connected either by direct cables or through a switch. The original text had an "or" but the edited text has an "and" between the two. I understand that the original text did not sound well. Could you please rephrase it so that its original meaning should remain?
> 
> Moreover, I found a mistake that is NOT a results of the editing, but it was present in the original text, and thus it was definitely my fault. Could you please correct it?


) We have updated the text and reformatted it to a bulleted list to improve readability. Please let us know if further updates are needed.

Current:
    The table MUST be complemented with reporting the relevant parameters
    of the DUT. If the DUT is a general-purpose computer and some
    software NATxy gateway implementation is tested, then the hardware
    description SHOULD include the following:

    * computer type

    * CPU type

    * number of active CPU cores

    * memory type

    * size and speed

    * network interface card type (also reflecting the speed)

    * direct cable connections or the type of switch used for
       interconnecting the Tester and the DUT

<GL>

I agree that the bulleted list is easier to parse. Moreover, the bulleted rewriting uncovered (the elimination of) some implied relations of the parameters in the original text.
(E.g., in the original text, "size and speed" referred to the memory; also direct cable connections are not really clear to me in the new text.)

Therefore, I recommend the following new text:

    The table MUST be complemented with reporting the relevant parameters
    of the DUT. If the DUT is a general-purpose computer and some
    software NATxy gateway implementation is tested, then the hardware
    description SHOULD include the following:

    * computer type

    * CPU type

    * number of active CPU cores

    * memory type, size, and speed

    * network interface card type (also reflecting the speed)

    * the fact that direct cable connections were used or the type of switch used for
       interconnecting the Tester and the DUT

</GL>

...
The files have been posted here (please refresh):
  https://www.rfc-editor.org/authors/rfc9693.xml
  https://www.rfc-editor.org/authors/rfc9693.txt
  https://www.rfc-editor.org/authors/rfc9693.html
  https://www.rfc-editor.org/authors/rfc9693.pdf

The relevant diff files have been posted here:
  https://www.rfc-editor.org/authors/rfc9693-diff.html  (comprehensive diff)
  https://www.rfc-editor.org/authors/rfc9693-auth48diff.html  (AUTH48 changes)

<GL>

The "AUTH48 changes" URL was very much helpful, thank you very much for including it!

</GL>

Please review the document carefully and contact us with any further updates you may have.  Note that we do not make changes once a document is published as an RFC.

We will await approvals from each party listed on the AUTH48 status page below prior to moving this document forward in the publication process.

For the AUTH48 status of this document, please see:
  https://www.rfc-editor.org/auth48/rfc9693

Thank you,
RFC Editor/ap

---- Copied text ends here ----

I have checked the further e-mails including the approval of Warren Kumari (Thank you Warren!) and your reply for it, my e-mail on December 17 and your reply for it, your reminder e-mail on January 2, and finally, the e-mail of Keiichi Shima about my e-mail issue, and I did not find anything else that needed an answer.

So I think I could process all my backlog by this single e-mail.

Thank you very much for your careful work and special thanks for your endurance in trying to reach me!

Best regards,

Gábor