Hello, I am the co-author of the draft. It seems that Gabor (the primary author of the draft) had mail trouble, and didn't receive your email which is describing the updates. I am now contacting him and we will respond as soon as possible.
Regards, On Fri, Jan 3, 2025 at 2:15 AM Alanna Paloma <apal...@amsl.com> wrote: > Hi Gábor and Keiichi, > > This is a friendly reminder that we await your response to our follow-up > questions: > > > 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? > > ) 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 > > > >> 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. > > > > 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 > > > Once these questions have been addressed and we have received approvals > from each author, we will move this document forward in the publication > process. > > For the AUTH48 status of this document, please see: > https://www.rfc-editor.org/auth48/rfc9693 > > Best regards, > RFC Editor/ap > > > > On Dec 16, 2024, at 8:42 AM, Alanna Paloma <apal...@amsl.com> wrote: > > > > Hi Warren, > > > > Thank you for approval. We have noted it on the AUTH48 status page: > > https://www.rfc-editor.org/auth48/rfc9693 > > > > Best regards, > > RFC Editor/ap > > > >> On Dec 16, 2024, at 7:11 AM, Warren Kumari <war...@kumari.net> wrote: > >> > >> > >> > >> > >> > >> On Mon, Dec 09, 2024 at 3:05 PM, Alanna Paloma <apal...@amsl.com> > wrote: > >> 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. > >> > >> > >> WFM! > >> > >> Thank you! > >> W > >> > >> > >> > >> 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. > 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? > >> ) 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 > >> 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. 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 > >> ... > >> 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) > >> 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 > >> On Dec 6, 2024, at 12:43 PM, Dr. Lencse Gábor <len...@sze.hu> wrote: > >> Dear RFC Editor, > >> Please see my answers inline. > >> On 04/12/2024 00:24, rfc-edi...@rfc-editor.org wrote: > >> Authors, > >> While reviewing this document during AUTH48, please resolve (as > necessary) the following questions, which are also in the XML file. > >> 1) <!-- [rfced] As RFC 4814 is mentioned in this document's Abstract > and Introduction, may we remove the reference to it from the title? > >> Original: > >> Benchmarking Methodology for Stateful NATxy Gateways using RFC 4814 > Pseudorandom Port Numbers > >> Perhaps: > >> Benchmarking Methodology for Stateful NATxy Gateways Using Pseudorandom > Port Numbers > >> --> > >> I can accept it. Moreover, as I was thinking about the title, I noticed > something. Originally, the title reflected the content well: we used a > single IP address pair and pseudorandom port numbers (as recommended by RFC > 4814). Later we introduced the usage of multiple, pseudorandom IP > addresses, too. However, we did not update the title to reflect the change. > To that end, one could use one of the following titles: > >> "Benchmarking Methodology for Stateful NATxy Gateways Using > Pseudorandom Port Numbers and Pseudorandom IP Addresses" or > >> "Benchmarking Methodology for Stateful NATxy Gateways Using > Pseudorandom Port Numbers and IP Addresses" 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? > >> 2) <!-- [rfced] Per Section 3.6 of RFC 7322 ("RFC Style Guide"), > abbreviations must be expanded upon first use. To avoid expanding "NAPT" > upon first use here and stacking multiple sets of parentheses, we have > rephrased as follows (because "NAPT" is introduced and expanded later in > this document). Please let us know of any objections. > >> Original: > >> However, none of them discussed, how to apply [RFC4814] pseudorandom > port numbers, when benchmarking stateful NATxy (NAT44 (also called NAPT) > [RFC3022], NAT64 [RFC6146], and NAT66) gateways. (It should be noted that > stateful NAT66 is not an IETF specification but refers to an IPv6 version > of the stateful NAT44 specification.) > >> Current: > >> However, none of them discussed how to apply pseudorandom port numbers > from > >> [RFC4814] when benchmarking stateful NATxy gateways (such as NAT44 > >> [RFC3022], NAT64 [RFC6146], and NAT66). (It should be noted that > stateful NAT66 is not an IETF specification but refers to an IPv6 version > of the stateful NAT44 specification.) > >> --> > >> OK. > >> 3) <!-- [rfced] In the sentence below, may we clarify "also in the case > of UDP using the same kind of entries as in the case of TCP" as follows? > >> Original: > >> * Connection: Although UDP itself is a connection-less protocol, > stateful NATxy gateways keep track of their translation mappings in the > form of a "connection" also in the case of UDP using the same kind of > entries as in the case of TCP. > >> Perhaps: > >> Connection: Although UDP itself is a connectionless protocol, stateful > NATxy gateways keep track of their translation mappings in the form of a > "connection" as well as in the case of UDP using the same kind of entries > as in TCP. > >> --> > >> I am not a native speaker. If it sounds better, I am OK with it. > >> 4) <!-- [rfced] For clarity, may we update "in the order of a few times > ten thousand" to "in the order of a few tens of thousands"? > >> Original: > >> If it is possible, the size of the source port number range SHOULD be > larger (e.g. in the order of a few times ten thousand), whereas the size of > the destination port number range SHOULD be smaller (may vary from a few to > several hundreds or thousands as needed). > >> Perhaps: > >> If it is possible, the size of the source port number range SHOULD be > larger (e.g., in the order of a few tens of thousands), whereas the size of > the destination port number range SHOULD be smaller (may vary from a few to > several hundreds or thousands as needed). > >> --> > >> I am not a native speaker, but I trust in you. > >> Just for clarity: - If there are 1,000 apples in a container, and we > have a few containers, I would say: We have a few thousands of apples. - If > there are 10,000 apples in a container, and we have a few containers, I > would say: We have a few times 10,000 of apples. (This is the literal > translation of what I would say in Hungarian.) In the latter case, would a > native speaker say: "We have a few tens of thousands of apples."? > >> 5) <!-- [rfced] FYI - To improve readability, we have reformatted the > text below to read as a bulleted list. Please let us know any objections. > >> Original: > >> When multiple IP addresses are used, then the port number ranges should > be even more restricted, as the number of potential network flows is the > product of the size of the source IP address range, the size of the source > port number range, the size of the destination IP address range, and the > size of the destination port number range. > >> Current: > >> When multiple IP addresses are used, then the port number ranges should > be even more restricted, as the number of potential network flows is the > product of the size of: > >> * the source IP address range, > >> * the source port number range, > >> * the destination IP address range, and > >> * the destination port number range. > >> --> > >> Yes, I like it. I think this formatting helps the understanding. > >> 6) <!-- [rfced] How may we clarify "that is throughput" in the text > below? > >> Original: > >> Test phase 1 serves two purposes: > >> 1. The connection tracking table of the DUT is filled. It is important, > because its maximum connection establishment rate may be lower than its > maximum frame forwarding rate (that is throughput). > >> Perhaps: > >> Test phase 1 serves two purposes: > >> 1. The connection tracking table of the DUT is filled. This is > important because its maximum connection establishment rate may be lower > than its maximum frame forwarding rate (that is, its throughput). > >> --> > >> Perfect. > >> 7) <!--[rfced] As "REQUIRES" is not a key word per RFCs 2119/8174, may > we rephrase this sentence to use "REQUIRED"? > >> 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. > >> Perhaps: > >> 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 face with. > >> --> > >> Yes, this was my intention. Thank you for the correction. > >> 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]. > >> 9) <!-- [rfced] FYI - We have reformatted the text below to read as a > bulleted list to improve readability. Please review and let us know of any > objections. > >> Original: > >> Procedure: The Initiator sends a specific number of test frames using > all different four tuples at a specific rate through the DUT. The Responder > counts the frames that are successfully translated by the DUT. If the count > of offered frames is equal to the count of received frames, the rate of the > offered stream is raised and the test is rerun. If fewer frames are > received than were transmitted, the rate of the offered stream is reduced > and the test is rerun. > >> Current: > >> The procedure is as follows: > >> * The Initiator sends a specific number of test frames using all > different four tuples at a specific rate through the DUT. > >> * The Responder counts the frames that are successfully translated by > the DUT. > >> * If the count of offered frames is equal to the count of received > frames, the rate of the offered stream is raised and the test is rerun. > >> * If fewer frames are received than were transmitted, the rate of the > offered stream is reduced and the test is rerun. > >> --> > >> Thank you! I definitely agree with it. > >> 10) <!-- [rfced] Please review whether any of the notes in this > document should be in the <aside> element. It is defined as "a container > for content that is semantically less important or tangential to the > content that surrounds it" > >> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). > >> --> > >> I prefer not using it. > >> 11) <!--[rfced] May we clarify the singular/plural usage in this > sentence as follows?? > >> Original: > >> ...but it is RECOMMENDED to perform measurement series through which > the value of one or more parameter(s) is/are changed to discover how the > various values of the given parameter(s) influence the performance of the > DUT. > >> Perhaps: > >> ...but it is RECOMMENDED to perform measurement series through which > the value of each parameter is changed to discover how the various values > of the each given parameter influences the performance of the DUT. > >> --> > >> I disagree with this solution. > >> There may be several parameters. In a given measurement series, only > one of them changes. In another one, two of them changes. I saw that in the > edited version that "is/are" was replaced by "are". I did not object it in > my previous e-mail, because I thought that it could be better grammatically > than my solution, but I feel that "is/are" fits better to the subjective > ("one or more parameter(s)"). > >> 12) <!-- [rfced] FYI - We have added expansions for abbreviations upon > first use per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > each expansion in the document carefully to ensure correctness. > >> Border Relay (BR) > >> Mapping of Address and Port using Translation (MAP-T) Datagram > Congestion Control Protocol (DCCP) > >> Stream Control Transmission Protocol (SCTP) > >> --> > >> Thank you. > >> 13) <!-- [rfced] Please review the "Inclusive Language" portion of the > online Style Guide < > https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let > us know if any changes are needed. Updates of this nature typically result > in more precise language, which is helpful for readers. > >> a. For example, please consider whether "black" should be updated. > >> "Black box testing" should be kept. It is a well-known and widely-used > term. > >> b. In addition, please consider whether "tradition" and "traditional" > should be updated for clarity. While the NIST website > >> < > https://www.nist.gov/nist-research-library/nist-technical-series-publications-author-instructions#table1> > indicates that this term is potentially biased, it is also ambiguous. > >> "Tradition" is a subjective term, as it is not the same for everyone. > >> --> > >> The term "Traditional NAT" was defined by [RFC3022]. > >> Thank you. > >> RFC Editor/kf/ap > >> Once again, thank you very much for your careful editing work! Best > regards, > >> Gábor Lencse > >> On Dec 3, 2024, at 3:23 PM, rfc-edi...@rfc-editor.org wrote: > >> *****IMPORTANT***** > >> Updated 2024/12/03 > >> RFC Author(s): > >> -------------- > >> Instructions for Completing AUTH48 > >> Your document has now entered AUTH48. Once it has been reviewed and > approved by you and all coauthors, it will be published as an RFC. If an > author is no longer available, there are several remedies available as > listed in the FAQ (https://www.rfc-editor.org/faq/). > >> You and you coauthors are responsible for engaging other parties > >> (e.g., Contributors or Working Group) as necessary before providing > your approval. > >> Planning your review > >> --------------------- > >> Please review the following aspects of your document: > >> * RFC Editor questions > >> Please review and resolve any questions raised by the RFC Editor that > have been included in the XML file as comments marked as follows: > >> <!-- [rfced] ... --> > >> These questions will also be sent in a subsequent email. > >> * Changes submitted by coauthors > >> Please ensure that you review any changes submitted by your coauthors. > We assume that if you do not speak up that you agree to changes submitted > by your coauthors. > >> * Content > >> Please review the full content of the document, as this cannot change > once the RFC is published. Please pay particular attention to: > >> - IANA considerations updates (if applicable) > >> - contact information > >> - references > >> * Copyright notices and legends > >> Please review the copyright notice and legends as defined in RFC 5378 > and the Trust Legal Provisions > >> (TLP – https://trustee.ietf.org/license-info). > >> * Semantic markup > >> Please review the markup in the XML file to ensure that elements of > content are correctly tagged. For example, ensure that <sourcecode> and > <artwork> are set correctly. See details at > >> <https://authors.ietf.org/rfcxml-vocabulary>. > >> * Formatted output > >> Please review the PDF, HTML, and TXT files to ensure that the formatted > output, as generated from the markup in the XML file, is reasonable. Please > note that the TXT will have formatting limitations compared to the PDF and > HTML. > >> Submitting changes > >> ------------------ > >> To submit changes, please reply to this email using ‘REPLY ALL’ as all > the parties CCed on this message need to see your changes. The parties > include: > >> * your coauthors > >> * rfc-edi...@rfc-editor.org (the RPC team) > >> * other document participants, depending on the stream (e.g., IETF > Stream participants are your working group chairs, the responsible ADs, and > the document shepherd). > >> * auth48archive@rfc-editor.org, which is a new archival mailing list > to preserve AUTH48 conversations; it is not an active discussion list: > >> * More info: > >> > https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc > >> * The archive itself: > >> https://mailarchive.ietf.org/arch/browse/auth48archive/ > >> * Note: If only absolutely necessary, you may temporarily opt out of > the archiving of messages (e.g., to discuss a sensitive matter). If needed, > please add a note at the top of the message that you have dropped the > address. When the discussion is concluded, auth48archive@rfc-editor.org > will be re-added to the CC list and its addition will be noted at the top > of the message. > >> You may submit your changes in one of two ways: > >> An update to the provided XML file > >> — OR — > >> An explicit list of changes in this format > >> Section # (or indicate Global) > >> OLD: > >> old text > >> NEW: > >> new text > >> You do not need to reply with both an updated XML file and an explicit > list of changes, as either form is sufficient. > >> We will ask a stream manager to review and approve any changes that > seem beyond editorial in nature, e.g., addition of new text, deletion of > text, and technical changes. Information about stream managers can be found > in the FAQ. Editorial changes do not require approval from a stream manager. > >> Approving for publication > >> -------------------------- > >> To approve your RFC for publication, please reply to this email stating > that you approve this RFC for publication. Please use ‘REPLY ALL’, as all > the parties CCed on this message need to see your approval. > >> Files > >> ----- > >> The files are available here: > >> https://www.rfc-editor.org/authors/rfc9693.xml > >> https://www.rfc-editor.org/authors/rfc9693.html > >> https://www.rfc-editor.org/authors/rfc9693.pdf > >> https://www.rfc-editor.org/authors/rfc9693.txt > >> Diff file of the text: > >> https://www.rfc-editor.org/authors/rfc9693-diff.html > https://www.rfc-editor.org/authors/rfc9693-rfcdiff.html (side by side) > >> Diff of the XML: > >> https://www.rfc-editor.org/authors/rfc9693-xmldiff1.html > >> Tracking progress > >> ----------------- > >> The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9693 > >> Please let us know if you have any questions. > >> Thank you for your cooperation, > >> RFC Editor > >> -------------------------------------- > >> RFC9693 (draft-ietf-bmwg-benchmarking-stateful-09) > >> Title : Benchmarking Methodology for Stateful NATxy Gateways using RFC > 4814 Pseudorandom Port Numbers Author(s) : G. Lencse, K. Shima > >> WG Chair(s) : Sarah Banks, Giuseppe Fioccola > >> Area Director(s) : Warren Kumari, Mahesh Jethanandani > > > > > >
-- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
