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
--
auth48archive mailing list -- auth48archive@rfc-editor.org
To unsubscribe send an email to auth48archive-le...@rfc-editor.org
