Hi Gábor and Keiichi, Thank you for your replies and for handling the email issues. As all our outstanding questions have been addressed, we will await any further changes you may have and approval from each author prior to moving this document forward in the publication process.
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) https://www.rfc-editor.org/authors/rfc9693-lastdiff.html (htmlwdiff diff between last version and this) https://www.rfc-editor.org/authors/rfc9693-lastrfcdiff.html (rfcdiff between last version and this) For the AUTH48 status of this document, please see: https://www.rfc-editor.org/auth48/rfc9693 Thank you, RFC Editor/ap > On Jan 6, 2025, at 10:53 AM, Dr. Lencse Gábor <[email protected]> wrote: > > Dear Alanna Paloma, > > Now I reply to your e-mail on "Mon, 09 December 2024 20:05 UTC". I copy here > the text from auth48archive 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 -- [email protected] To unsubscribe send an email to [email protected]
