Hi Gábor and Keiichi, We have now received all necessary approvals and consider AUTH48 complete: https://www.rfc-editor.org/auth48/rfc9693
Thank you for your attention and guidance during the AUTH48 process. We will move this document forward in the publication process at this time. RFC Editor/ap > On Jan 7, 2025, at 2:26 AM, 島 慶一（先端技術研究所）- Shima Keiichi - > <keiichi.sh...@g.softbank.co.jp> wrote: > > Dear Alanna and all, > > As a co-author, I am also OK with the latest version and approve for > publication. > > Thank you. > > --- > Keiichi Shima / 島慶一 <keiichi.sh...@g.softbank.co.jp> > Research Institute of Advanced Technology > SoftBank Corp. > > > 2025年1月7日(火) 17:28 Dr. Lencse Gábor <len...@sze.hu>: > Dear Alanna, > > Thank you very much for your quick reply and for the update of our I-D > according to my requests. I have checked the latest changes at > https://www.rfc-editor.org/authors/rfc9693-lastdiff.html and I do not > have any further request. > > Hereby I approve the document for publication. > > Best regards, > > Gábor > > p.s.: Our system administrator replied to my request for investigation: > it was the spam filter that held your e-mails in spam quarantine. As a > partial mitigation, he signaled at the interface of the spam filter that > they were not spam e-mails (hoping that the algorithm might improve) and > added your e-mail address to the "good senders" list. > > 06/01/2025 21:52 keltezéssel, Alanna Paloma írta: > > 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 <len...@sze.hu> 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 -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
