[auth48] [AD] Re: AUTH48: RFC-to-be 9411 <draft-ietf-bmwg-ngfw-performance-15> for your review

[Alanna Paloma <[e-mail]>]

Authors and AD*,

*Warren - As the AD, please review and approve of the added informative reference in the diff file below (the added citation in the text can be seen in Section 4.2.1, and the added reference can be seen in Section 10.2):
  https://www.rfc-editor.org/authors/rfc9411-auth48diff.html 

Authors - Thank you for your replies. We have updated the files accordingly and noted your approvals on the AUTH48 status page. 

We will await any further changes you may have and approval from the *AD prior to moving forward in the publication process.

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

 The relevant diff files are posted here:
  https://www.rfc-editor.org/authors/rfc9411-diff.html (comprehensive diff)
  https://www.rfc-editor.org/authors/rfc9411-auth48diff.html (all AUTH48 changes)
  https://www.rfc-editor.org/authors/rfc9411-lastdiff.html (htmlwdiff diff between last version and this)
  https://www.rfc-editor.org/authors/rfc9411-lastrfcdiff.html (rfcdiff between last version and this)

Please see the AUTH48 status page for this document here:
https://www.rfc-editor.org/auth48/rfc9411

Thank you,
RFC Editor/ap

> On Mar 8, 2023, at 7:53 AM, [e-mail] wrote:
> 
> Alanna,
>  
> I concur with Carsten and Bala. I approve the draft to be published as RFC9411.
>  
> Brian
>  
> From: Bala Balarajah <[e-mail]> 
> Sent: Wednesday, March 8, 2023 10:24 AM
> To: Alanna Paloma <[e-mail]>
> Cc: RFC Errata System <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]; [e-mail]
> Subject: Re: AUTH48: RFC-to-be 9411 <draft-ietf-bmwg-ngfw-performance-15> for your review
>  
> Hi Alanna,
>  
> Thank you very much for your review and editing.
> Please see our responses below:
>  
> 1) It should be listed as an informative reference.
> 
> 2) For consistency, we would like to update the title of section 4.5 as "Concurrent TCP Connection Capacity with HTTP Traffic".
> 
> 3) The notes in the documents are important. We would like to leave them as they are.
>  
>  
>  I approve RFC-to-be 9411 for publication
>  
> Best regards,
> Bala
>  
> Am Di., 7. März 2023 um 23:40 Uhr schrieb Alanna Paloma <[e-mail]>:
>> Hi Bala,
>> 
>> Thank you for your reply. We have updated as requested. Please note that we have some follow-up questions.
>> 
>> 1) Per your response, should the reference for the CVE list be listed as normative or informative?
>> 
>> > 2) yes, we would like to add the reference https://www.cvedetails.com/ for the CVE list
>> 
>> 
>> 
>> 2) There is an additional instance of “TCP/HTTP”. May we update the title of Section 7.5 as follows?
>> 
>> Original:
>> 7.5.  Concurrent TCP/HTTP Connection Capacity
>> 
>> Perhaps:
>> 7.5.  Concurrent TCP Connection Capacity with HTTP Traffic
>> 
>> 
>> 3) We have a formatting question that has not yet been addressed:
>> 
>> > c) 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).
>> 
>> ...
>> The files have been posted here (please refresh):
>>  https://www.rfc-editor.org/authors/rfc9411.xml
>>  https://www.rfc-editor.org/authors/rfc9411.txt
>>  https://www.rfc-editor.org/authors/rfc9411.html
>>  https://www.rfc-editor.org/authors/rfc9411.pdf
>> 
>> The relevant diff files have been posted here:
>>  https://www.rfc-editor.org/authors/rfc9411-diff.html (comprehensive diff)
>>  https://www.rfc-editor.org/authors/rfc9411-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/rfc9411
>> 
>> Thank you,
>> RFC Editor/ap
>> 
>> 
>> > On Mar 5, 2023, at 2:00 PM, Bala Balarajah <[e-mail]> wrote:
>> > 
>> > Hello RFC Editors,
>> > Thank you for the review. Please see our responses to your comments and questions below:
>> > 
>> > 1) agreed
>> > 
>> > 2) yes, we would like to add the reference https://www.cvedetails.com/ for the CVE list
>> > 
>> > 3) agreed
>> > 
>> > 4) agreed
>> > 
>> > 5) Please modify the text as follows: "The HTTP/3 server pool listens on any UDP port"
>> > 
>> > OLD: 4.3.2.4.
>> > ....
>> >  The HTTP/3 server pool listens on UDP port 443
>> > or any port.
>> > ....
>> > 
>> > NEW: 4.3.2.4.
>> > ....
>> > The HTTP/3 server pool listens on any UDP port.
>> > ....
>> > 
>> > 6) We agree with your suggested text.
>> > 
>> > OLD: Section 4.3.3
>> > At the beginning of the test, the server endpoint
>> > initializes and will be ready to accept connection states including
>> > initialization of the TCP or QUIC stack as well as bound HTTP and
>> > HTTPS servers.  When a client endpoint is needed, it will initialize
>> > and be given attributes such as a MAC and IP address.  The behavior
>> > of the client is to sweep through the given server IP space,
>> > generating a recognizable service by the DUT. 
>> > 
>> > NEW: Section 4.3.3
>> > At the beginning of the test (the init phase; see Section 4.3.4),
>> > the server endpoint initializes, and the server endpoint will be
>> > ready to accept TCP or QUIC connections as well as inbound HTTP and
>> > HTTPS requests.  The client endpoints initialize and are given
>> > attributes such as a MAC and IP address. After the init phase of
>> > the test, each client sweeps through the given server IP space,
>> > generating a service recognizable by the DUT. 
>> >    
>> >    To answer your questions:
>> >    The server will be ready to accept connections.
>> >    The initialization of the transport stack is the init phase of the traffic load profile
>> >    The HTTP(S) servers are inbound connections.
>> >    The clients are added during the init phase only.
>> >  
>> > 7) agreed
>> > 
>> > 8) agreed
>> > 
>> > 9) Please add the bullets to improve the readability.
>> > 
>> > 10) If TLS inspection is disabled on DUT, it impacts the performance of encrypted traffic which is a part of the specific application traffic mix.
>> > we preferred to modify your suggested text slightly as follows:
>> > 
>> > OLD: Section 7.1.3.1.
>> > ....
>> > In case the DUT/SUT is configured without TLS inspection, the test
>> > report MUST explain the implications of this to the relevant
>> > application traffic mix encrypted traffic.
>> >  
>> > NEW: Section 7.1.3.1.
>> > ....
>> > If the DUT/SUT is configured without TLS inspection, the test report MUST explain how this impacts the encrypted traffic of the relevant application traffic mix.
>> > 
>> > 11) agreed
>> > 
>> > 12) It should be "initial throughput"
>> > 
>> > OLD: Section 7.3.4.1
>> > ....
>> > Configure the traffic load profile of the test equipment to establish
>> > "Initial inspected throughput" as defined in Section 7.3.3.2.
>> > ...
>> > The traffic load profile MUST be defined as described in
>> > Section 4.3.4.  The DUT/SUT MUST reach the "Initial inspected
>> > throughput" during the sustain phase.
>> > ...
>> > 
>> > NEW: Section 7.3.4.1
>> > ....
>> > Configure the traffic load profile of the test equipment to establish
>> > "Initial throughput" as defined in Section 7.3.3.2.
>> > ...
>> > The traffic load profile MUST be defined as described in
>> > Section 4.3.4.  The DUT/SUT MUST reach the "Initial throughput" during the sustain phase.
>> >    ....
>> > 
>> > 13) Please add "Initial concurrent connections" instead of "Initial concurrent TCP connections" in Sections 7.5.4.1 and 7.9.4.1 
>> > 
>> > OLD: 7.5.4.1
>> > ....
>> > Configure test equipment to establish "Initial concurrent TCP
>> > connections" defined in Section 7.5.3.2.
>> > 
>> > NEW: 7.5.4.1
>> > ....
>> > Configure test equipment to establish "Initial concurrent 
>> > connections" defined in Section 7.5.3.2.
>> > ....
>> > During the sustain phase, the DUT/SUT MUST reach the "Initial
>> > concurrent connections".
>> > ....
>> > 
>> > OLD: 7.9.4.1
>> > ....
>> > Configure test equipment to establish "Initial concurrent TCP
>> > connections" defined in Section 7.9.3.2.
>> > ....
>> > 
>> > NEW: 7.9.4.1
>> > Configure test equipment to establish "Initial concurrent
>> > connections" defined in Section 7.9.3.2.   
>> > 
>> > 14) agreed
>> > 
>> > 15) agreed
>> > 
>> > 16) agreed
>> > 
>> > 17) Yes, the section number (Appendix A.3.2) should be included.
>> > 
>> > 18) agreed
>> > 
>> > 19)
>> > a) If possible, please format Figure 3 as a <table> instead. We couldn't manage to create a table due to the additional header row " DUT/SUT Classification Rules"
>> > 
>> > b) Thanks for the update. Please also add the following parameters as well as a part of the bulleted list.
>> > 
>> > In section 7.1.3.2, the text "One of the ciphers and keys defined in Section 4.3.1.4 is RECOMMENDED to use for this benchmarking test" should also be part of the bulleted list.
>> > 
>> > OLD: 7.1.3.2.  Test Equipment Configuration Parameters
>> > 
>> >    Test equipment configuration parameters MUST conform to the
>> >    requirements defined in Section 4.3.  The following parameters MUST
>> >    be documented for this benchmarking test:
>> > 
>> >    *  Client IP address ranges defined in Section 4.3.1.3
>> > 
>> >    *  Server IP address ranges defined in Section 4.3.2.3
>> > 
>> >    *  Traffic distribution ratio between IPv4 and IPv6 defined in
>> >       Section 4.3.1.3
>> > 
>> >    *  Target inspected throughput: Aggregated line rate of one or more
>> >       interfaces used in the DUT/SUT or the value defined based on the
>> >       requirement for a specific deployment scenario
>> > 
>> >    *  Initial throughput: 10% of the "Target inspected throughput"
>> > 
>> >       Note: Initial throughput is not a KPI to report.  This value is
>> >       configured on the traffic generator and used to perform Step 1
>> >       (Test Initialization and Qualification) described in
>> >       Section 7.1.4.
>> > 
>> >    One of the ciphers and keys defined in Section 4.3.1.4 is RECOMMENDED
>> >    to use for this benchmarking test.
>> >    
>> > NEW: 7.1.3.2.  Test Equipment Configuration Parameters
>> > 
>> >    Test equipment configuration parameters MUST conform to the
>> >    requirements defined in Section 4.3.  The following parameters MUST
>> >    be documented for this benchmarking test:
>> > 
>> >    *  Client IP address ranges defined in Section 4.3.1.3
>> > 
>> >    *  Server IP address ranges defined in Section 4.3.2.3
>> > 
>> >    *  Traffic distribution ratio between IPv4 and IPv6 defined in
>> >       Section 4.3.1.3
>> > 
>> >    *  Target inspected throughput: Aggregated line rate of one or more
>> >       interfaces used in the DUT/SUT or the value defined based on the
>> >       requirement for a specific deployment scenario
>> > 
>> >    *  Initial throughput: 10% of the "Target inspected throughput"
>> > 
>> >       Note: Initial throughput is not a KPI to report.  This value is
>> >       configured on the traffic generator and used to perform Step 1
>> >       (Test Initialization and Qualification) described in
>> >       Section 7.1.4.
>> > 
>> >    *  One of the ciphers and keys defined in Section 4.3.1.4 is RECOMMENDED
>> >  to use for this benchmarking test.
>> > -->
>> > 
>> > In section 7.2.3.2, the text "The RECOMMENDED response object sizes are 1, 2, 4, 16, and 64 KBytes" should also be part of the bulleted list and therefore, please move this text above to the sentence "The client MUST negotiate HTTP and close ....."
>> > 
>> > OLD: 7.2.3.2.  Test Equipment Configuration Parameters
>> > 
>> >    Test equipment configuration parameters MUST conform to the
>> >    requirements defined in Section 4.3.  The following parameters MUST
>> >    be documented for this benchmarking test:
>> > 
>> >    *  Client IP address ranges defined in Section 4.3.1.3
>> > 
>> >    *  Server IP address ranges defined in Section 4.3.2.3
>> > 
>> >    *  Traffic distribution ratio between IPv4 and IPv6 defined in
>> >       Section 4.3.1.3
>> > 
>> >    *  Target connections per second: Initial value from the product
>> >       datasheet or the value defined based on the requirement for a
>> >       specific deployment scenario
>> > 
>> >    *  Initial connections per second: 10% of "Target connections per
>> >       second"
>> > 
>> >       Note: Initial connections per second is not a KPI to report.  This
>> >       value is configured on the traffic generator and used to perform
>> >       Step 1 (Test Initialization and Qualification) described in
>> >       Section 7.2.4.
>> > 
>> >    The client MUST negotiate HTTP and close the connection with FIN
>> >    immediately after the completion of one transaction.  In each test
>> >    iteration, the client MUST send a GET request requesting a fixed HTTP
>> >    response object size.
>> > 
>> >    The RECOMMENDED response object sizes are 1, 2, 4, 16, and 64 KBytes.
>> >    
>> > NEW: 7.2.3.2.  Test Equipment Configuration Parameters
>> > 
>> >    Test equipment configuration parameters MUST conform to the
>> >    requirements defined in Section 4.3.  The following parameters MUST
>> >    be documented for this benchmarking test:
>> > 
>> >    *  Client IP address ranges defined in Section 4.3.1.3
>> > 
>> >    *  Server IP address ranges defined in Section 4.3.2.3
>> > 
>> >    *  Traffic distribution ratio between IPv4 and IPv6 defined in
>> >       Section 4.3.1.3
>> > 
>> >    *  Target connections per second: Initial value from the product
>> >       datasheet or the value defined based on the requirement for a
>> >       specific deployment scenario
>> > 
>> >    *  Initial connections per second: 10% of "Target connections per
>> >       second"
>> > 
>> >       Note: Initial connections per second is not a KPI to report.  This
>> >       value is configured on the traffic generator and used to perform
>> >       Step 1 (Test Initialization and Qualification) described in
>> >       Section 7.2.4.
>> >  
>> >    *  The RECOMMENDED response object sizes are 1, 2, 4, 16, and 64 KBytes.
>> > 
>> >    The client MUST negotiate HTTP and close the connection with FIN
>> >    immediately after the completion of one transaction.  In each test
>> >    iteration, the client MUST send a GET request requesting a fixed HTTP
>> >    response object size.
>> > --->
>> > 
>> > In section 7.6.3.2, the last sentence "The RECOMMENDED object sizes are 1, 2, 4, 16, and 64 KBytes." should also be part of the bulleted list and therefore this sentence can be moved above the paragraph "The client MUST negotiate HTTPS and close the connection..."
>> > 
>> > OLD: 7.6.3.2.  Test Equipment Configuration Parameters
>> > 
>> >    Test equipment configuration parameters MUST conform to the
>> >    requirements defined in Section 4.3.  The following parameters MUST
>> >    be documented for this benchmarking test:
>> > 
>> >    *  Client IP address ranges defined in Section 4.3.1.3
>> > 
>> >    *  Server IP address ranges defined in Section 4.3.2.3
>> > 
>> >    *  Traffic distribution ratio between IPv4 and IPv6 defined in
>> >       Section 4.3.1.3
>> > 
>> >    *  Target connections per second: Initial value from the product
>> >       datasheet or the value defined based on the requirement for a
>> >       specific deployment scenario
>> > 
>> >    *  Initial connections per second: 10% of "Target connections per
>> >       second"
>> > 
>> >       Note: Initial connections per second is not a KPI to report.  This
>> >       value is configured on the traffic generator and used to perform
>> >       Step 1 (Test Initialization and Qualification) described in
>> >       Section 7.6.4.)
>> > 
>> >    *  RECOMMENDED ciphers and keys defined in Section 4.3.1.4
>> > 
>> >    The client MUST negotiate HTTPS and close the connection without
>> >    error immediately after the completion of one transaction.  In each
>> >    test iteration, the client MUST send a GET request requesting a fixed
>> >    HTTPS response object size. The RECOMMENDED object sizes are 1, 2,
>> >    4, 16, and 64 KBytes.
>> >    
>> > NEW: 7.6.3.2.  Test Equipment Configuration Parameters
>> > 
>> >    Test equipment configuration parameters MUST conform to the
>> >    requirements defined in Section 4.3.  The following parameters MUST
>> >    be documented for this benchmarking test:
>> > 
>> >    *  Client IP address ranges defined in Section 4.3.1.3
>> > 
>> >    *  Server IP address ranges defined in Section 4.3.2.3
>> > 
>> >    *  Traffic distribution ratio between IPv4 and IPv6 defined in
>> >       Section 4.3.1.3
>> > 
>> >    *  Target connections per second: Initial value from the product
>> >       datasheet or the value defined based on the requirement for a
>> >       specific deployment scenario
>> > 
>> >    *  Initial connections per second: 10% of "Target connections per
>> >       second"
>> > 
>> >       Note: Initial connections per second is not a KPI to report.  This
>> >       value is configured on the traffic generator and used to perform
>> >       Step 1 (Test Initialization and Qualification) described in
>> >       Section 7.6.4.)
>> > 
>> >    *  RECOMMENDED ciphers and keys defined in Section 4.3.1.4
>> >    
>> >    *  The RECOMMENDED object sizes are 1, 2, 4, 16, and 64 KBytes.
>> > 
>> >    The client MUST negotiate HTTPS and close the connection without
>> >    error immediately after the completion of one transaction.  In each
>> >    test iteration, the client MUST send a GET request requesting a fixed
>> >    HTTPS response object size.
>> > --->
>> > 
>> > 20) agreed
>> > 
>> > 21) agreed
>> > 
>> > 22)
>> > a) agreed
>> > 
>> > b) "TCP/QUIC connections" means "TCP or QUIC connections". We agreed to replace "TCP/QUIC connections" to "TCP or QUIC connections" in the whole document.
>> > 
>> > c) "TCP/HTTP connections" means "TCP connections carrying HTTP traffic"
>> > If the terminology "TCP/HTTP" doesn't provide clarity, we would like to change as follows:
>> > 
>> > OLD: 7.2
>> > 7.2.  TCP/HTTP Connections Per Second
>> > ....
>> > 
>> > NEW: 7.2
>> > 7.2.  TCP Connections Per Second with HTTP Traffic
>> >     ....
>> > --->
>> > 
>> > OLD: 7.4.3.2.
>> >    ....
>> >    *  Target objective for scenario 1: 50% of the connections per second
>> >       measured in the benchmarking test TCP/HTTP Connections Per Second
>> >       (Section 7.2)
>> >    ....  
>> > 
>> > NEW: 7.4.3.2.
>> >    .....
>> >    *  Target objective for scenario 1: 50% of the connections per second
>> >       measured in the benchmarking test TCP connections per second with HTTP traffic
>> >       (Section 7.2)
>> >    ....  
>> > --->
>> > 
>> > OLD: 7.5.3.2.
>> >    ....
>> >    *  Maximum connections per second during ramp up phase: 50% of
>> >       maximum connections per second measured in the benchmarking test
>> >       TCP/HTTP Connections per second (Section 7.2)
>> > 
>> > NEW: 7.5.3.2.
>> >    ....
>> >    *  Maximum connections per second during ramp up phase: 50% of
>> >       maximum connections per second measured in the benchmarking test
>> >       TCP connections per second with HTTP traffic (Section 7.2)
>> >    ....
>> > --->
>> > 
>> > 23) We are also fine to change "dummy rules" to "placeholder rules" instead. Apart from that, no other changes are needed.
>> > 
>> > 
>> > Thank you and best regards,
>> > Bala
>> > 
>> > Am Mi., 1. März 2023 um 00:31 Uhr schrieb <[e-mail]>:
>> > Authors,
>> > 
>> > While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file.
>> > 
>> > 1) <!--[rfced] Section 1. FYI, we have updated instances where "ACL" is expanded as "access control rule" to be "access control list". Please review and let us know if further updates are needed.
>> > 
>> > Original:
>> >    Firewalls have evolved significantly from the days of simple ACL 
>> >    filters.
>> >    ...
>> >    In addition, a realistic number of access control rules (ACL) SHOULD
>> >    be configured on the DUT/SUT where ACLs are configurable and
>> >    reasonable based on the deployment scenario.
>> > 
>> > Current:
>> >    Firewalls have evolved significantly from the days of simple access
>> >    control list (ACL) filters.
>> >    ...
>> >    In addition, a realistic number of access control lists (ACLs) SHOULD
>> >    be configured on the DUT/SUT where ACLs are configurable and
>> >    reasonable based on the deployment scenario.
>> > -->   
>> > 
>> > 
>> > 2) <!-- [rfced] Section 4.2.1. Would you like to provide a reference for the Common Vulnerabilities and Exposures (CVE) list?
>> > 
>> > Original:
>> >    This section defines
>> >    the selection of the security vulnerability sets from the Common
>> >    Vulnerabilities and Exposures (CVE) list for testing.
>> > -->
>> > 
>> > 
>> > 3) <!-- [rfced] Section 4.3.1.3.  FYI, we have updated the following sentence by removing "be". Please let us know if any changes are necessary:
>> > 
>> > Original:
>> > 
>> >    *  If multiple IP blocks are used, they MUST be consist of multiple
>> >       unique, discontinuous static address blocks.
>> > 
>> > Current:
>> > 
>> >    *  If multiple IP blocks are used, they MUST consist of multiple
>> >       unique, discontinuous static address blocks.
>> > -->
>> > 
>> > 
>> > 4) <!-- [rfced] Section 4.3.1.4.  We have updated the following HTTP/2 terms to match RFC 9113. Please let us know if any updates are needed:
>> > 
>> > Original:
>> > 
>> >    *  Maximum Frame size: 16384 bytes
>> > 
>> >    *  Initial Window size: 65535 bytes
>> > 
>> >    *  HPACK Header table size: 4096 bytes
>> > 
>> >    *  Server PUSH enable: false
>> > 
>> > 
>> > Current (using lowercase and changing "Header table" to "header field table"):
>> > 
>> >    *  Maximum frame size: 16384 bytes
>> > 
>> >    *  Initial window size: 65535 bytes
>> > 
>> >    *  HPACK header field table size: 4096 bytes
>> > 
>> >    *  Server push enable: false
>> > -->
>> > 
>> > 
>> > 5) <!--[rfced] Section 4.3.2.4. Is "any port" all encompassing? Should "UDP port 443" be removed?
>> > 
>> > Original:
>> >   HTTP/3 server pool listens on UDP port 443 or
>> >   any port.
>> > 
>> > Perhaps:
>> >   The HTTP/3 server pool listens on any port.
>> > -->  
>> > 
>> > 
>> > 6) <!-- [rfced] Section 4.3.3.  We are having difficulty parsing the following. Will the server be ready to accept "connection states" or just "connections"? Is the initialization of the transport stack part of the init phase or the ramp up phase of the traffic load profile? Are the HTTP(S) servers bound or are their connections inbound? Are clients added throughout the testing, as implied by "When a client endpoint is needed", or only during the init phase, as described in Section 4.3.4? Please let us know how to make this clearer.
>> > 
>> > Original:
>> >    At the beginning of the test, the server endpoint
>> >    initializes and will be ready to accept connection states including
>> >    initialization of the TCP or QUIC stack as well as bound HTTP and
>> >    HTTPS servers.  When a client endpoint is needed, it will initialize
>> >    and be given attributes such as a MAC and IP address.  The behavior
>> >    of the client is to sweep through the given server IP space,
>> >    generating a recognizable service by the DUT.   
>> > 
>> > Possibly (clarifying load phase and server connections; tweaking the wording of client behavior):
>> >    At the beginning of the test (the init phase; see Section 4.3.4), 
>> >    the server endpoint initializes, and the server endpoint will be 
>> >    ready to accept TCP or QUIC connections as well as inbound HTTP and 
>> >    HTTPS requests.  The client endpoints initialize and are given 
>> >    attributes such as a MAC and IP address. After the init phase of 
>> >    the test, each client sweeps through the given server IP space,
>> >    generating a service recognizable by the DUT.    
>> > -->
>> > 
>> > 
>> > 7) <!-- [rfced] Section 4.3.3.1. Does the following suggestion improve the readability of the sentence?
>> > 
>> > Original:
>> >    If using SNI, the server MUST then perform an SNI name check 
>> >    with the proposed FQDN compared to the domain embedded in
>> >    the certificate.
>> > 
>> > Perhaps (changing "with...compared to" to "by comparing...to"):
>> >    If using SNI, the server MUST then perform an SNI name check 
>> >    by comparing the proposed FQDN to the domain embedded in
>> >    the certificate.
>> > -->
>> > 
>> > 
>> > 8) <!-- [rfced] Section 5. Does the following update improve the readability of the sentence?
>> > 
>> > Original:
>> > 
>> >    3.  Ensure that any ancillary switching or routing functions added in
>> >        the test equipment do not limit the performance by introducing
>> >        network metrics such as packet loss and latency.
>> > 
>> > Perhaps (removing "network metrics such as" because the terms "packet loss and latency" don't refer to metrics in this case):
>> > 
>> >    3.  Ensure that any ancillary switching or routing functions added in
>> >        the test equipment do not limit performance by introducing
>> >        packet loss or latency.
>> > -->
>> > 
>> > 
>> > 9) <!--[rfced] Section 6.1. As both of the bullet points listed below list multiple items, should their contents be separated into multiple bullet points?
>> > 
>> > Original:
>> >    *  If the DUT/SUT is a Virtual Network Function (VNF), host
>> >       (server) hardware and software details, interface
>> >       acceleration type such as DPDK and SR-IOV, used CPU cores,
>> >       used RAM, resource sharing (e.g.  Pinning details and NUMA
>> >       Node) configuration details, hypervisor version, virtual
>> >       switch version
>> >       ...
>> >    *  If the test equipment is a virtual solution, the host
>> >       (server) hardware and software details, interface
>> >       acceleration type such as DPDK and SR-IOV, used CPU cores,
>> >       used RAM, resource sharing (e.g.  Pinning details and NUMA
>> >       Node) configuration details, hypervisor version, virtual
>> >       switch version      
>> > -->           
>> > 
>> > 
>> > 10) <!-- [rfced] Section 7.1.3.1. We are having difficulty parsing the following sentence. Does TLS inspection impact the mix of encrypted traffic at the application layer? 
>> > 
>> > Original:
>> >    In case the DUT/SUT is configured without TLS inspection, the test 
>> >    report MUST explain the implications of this to the relevant 
>> >    application traffic mix encrypted traffic.
>> > 
>> > Possibly:
>> >    If the DUT/SUT is configured without TLS inspection, the test 
>> >    report MUST explain how this impacts the mix of relevant encrypted 
>> >    traffic at the application layer.
>> > -->
>> > 
>> > 
>> > 11) <!-- [rfced] Section 7.2.4 and also 7.6.4. Do the following updates clarify these two sentences?
>> > 
>> > Original:
>> >    The test procedure is designed to measure the TCP connections per
>> >    second rate of the DUT/SUT at the sustaining period of the traffic
>> >    load profile.  
>> >    ...
>> >    The test procedure is designed to measure the TCP or QUIC connections
>> >    per second rate of the DUT/SUT at the sustaining period of the
>> >    traffic load profile.  
>> > 
>> > Perhaps (clarifying what is being measured and when):
>> >    The test procedure is designed to measure the DUT/SUT's rate of TCP 
>> >    connections per second during the sustaining period of the traffic
>> >    load profile.  
>> >    ...
>> >    The test procedure is designed to measure the DUT/SUT's rate of TCP
>> >    or QUIC connections per second during the sustaining period of the
>> >    traffic load profile.  
>> > -->
>> > 
>> > 
>> > 12) <!--[rfced] Section 7.3.4.1. "Initial inspected throughput" is not defined in Section 7.3.3.2, but that section does define "Target inspected throughput" and "Initial throughput". Please review and let us know how to update.
>> > 
>> > Original:
>> >    Configure the traffic load profile of the test equipment to establish
>> >    "Initial inspected throughput" as defined in Section 7.3.3.2.
>> >    ...
>> >    The traffic load profile MUST be defined as described in
>> >    Section 4.3.4.  The DUT/SUT MUST reach the "Initial inspected
>> >    throughput" during the sustain phase. 
>> > -->
>> > 
>> > 
>> > 13) <!--[rfced] Sections 7.5.4.1 and 7.9.4.1. We note that Sections 7.5.3.2 and 7.9.3.2 do not contain definitions of "Initial concurrent TCP connections", but it does contain "Initial concurrent connections". Please review and let us know how to update. 
>> > 
>> > Original:
>> >    Configure test equipment to establish "Initial concurrent TCP
>> >    connections" defined in Section 7.5.3.2.
>> >    ...
>> >    Configure test equipment to establish "Initial concurrent TCP
>> >    connections" defined in Section 7.9.3.2.   
>> > -->   
>> > 
>> > 
>> > 14) <!-- [rfced] Informative References. FYI, we updated the Wikipedia reference to include the title, date, and a dated URI. Please let us know if any updates are necessary.
>> > 
>> > Original:
>> >    [Wiki-NGFW]
>> >               "",
>> >               <https://en.wikipedia.org/wiki/Next-generation_firewall>.
>> > 
>> > Current:
>> >    [Wiki-NGFW]
>> >               Wikipedia, "Next-generation firewall", January 2023,
>> >               <https://en.wikipedia.org/w/index.php?title=Next-
>> >               generation_firewall&oldid=1133673904>.
>> > -->
>> > 
>> > 
>> > 15) <!-- [rfced] Informative References. FYI, we updated the title of this reference to the title of the URL provided.
>> > 
>> > Original:
>> >    [fastly]   Oku, K. and J. Iyengar, "Can QUIC match TCP's
>> >               computational efficiency?", 30 April 2020,
>> >               <https://www.fastly.com/blog/measuring-quic-vs-tcp-
>> >               computational-efficiency>.
>> > 
>> > Current:
>> >    [fastly]   Oku, K. and J. Iyengar, "QUIC vs TCP: Which is
>> >               Better?", 30 April 2020,
>> >               <https://www.fastly.com/blog/measuring-quic-vs-tcp-
>> >               computational-efficiency>.
>> > -->
>> > 
>> > 
>> > 16) <!--[rfced] Appendix A.5. FYI, to parallel the other terminology defined in Appendix A.5, we have updated the text as follows. Please let us know of any objections.
>> > 
>> > Original:
>> >    -  Heavily impacted: Considered as "Heavily impacted" if any
>> >       deviation of traffic forwarding rate is greater than 10% (i.e. 
>> >       large spikes) or reduced the background HTTP(S) throughput
>> >       greater than 10%
>> > 
>> > Current:
>> >    -  Heavy impact: Considered as "heavy impact" if any
>> >       deviation of the traffic forwarding rate is greater than 10% (i.e.,
>> >       large spikes) or reduced the background HTTP(S) throughput
>> >       greater than 10%
>> > -->
>> > 
>> > 
>> > 17) <!--[rfced] Appendix A.6.2. Should the section number be included here?
>> > 
>> > Original:
>> >    While generating background traffic (in sustain phase), send the CVE
>> >    traffic as defined in the parameter section.
>> > 
>> > Perhaps:
>> >    While generating background traffic (in sustain phase), send the CVE
>> >    traffic as defined in the parameter section (Appendix A.3.2).
>> > -->   
>> > 
>> > 
>> > 18) <!-- [rfced] Appendix A.6.2. Does the following reordering of the conditional phrase improve the readability of the sentence? 
>> > 
>> > Original:
>> >    In addition, the DUT/SUT should either report the detected
>> >    vulnerabilities in the log correctly or if, for example, a different
>> >    naming convention is used, there MUST be reference material available
>> >    that will allow for verification that the correct vulnerability was
>> >    detected. 
>> > 
>> > Perhaps (moving the example conditional phrase to the end):
>> >    In addition, the DUT/SUT should report the detected 
>> >    vulnerabilities in the log correctly, or there MUST be reference 
>> >    material available that will allow for verification that the correct 
>> >    vulnerability was detected if, for example, a different naming 
>> >    convention is used.
>> > -->
>> > 
>> > 
>> > 19) <!-- [rfced] Formatting Questions:
>> > 
>> > a) Section 4.2. Would you like to format Figure 3 as a <table> instead?
>> > 
>> > b) Please review the lists in the "Test Equipment Configuration Parameters" sections listed below to ensure correctness. We updated to use bulleted lists for the parameters (the original xml contained a mix of <ul empty="true" spacing="normal"> and <t>).
>> > 
>> > 7.2.3.2
>> > 7.3.3.2
>> > 7.4.3.2
>> > 7.5.3.2
>> > 7.6.3.2
>> > 7.7.3.2
>> > 7.8.3.2
>> > 7.9.3.2
>> > 
>> > In particular, in Section 7.2.3.2, should the last two paragraphs (after the Note) be part of the bulleted list? Also, in Section 7.6.3.2, should the last paragraph be part of the bulleted list?  
>> > 
>> > c) 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).
>> > -->
>> > 
>> > 
>> > 20) <!--[rfced] FYI, to make the use of the terms "target objective" and "initial objective" consistent, we have updated '"Initial objective"' to 'initial objectives' and '"Target objective"' to 'target objectives' when the terms were referring to multiple objectives. Please let us know if any changes are needed. For example:
>> > 
>> > Original:
>> >    Configure the traffic load profile of the test equipment to establish
>> >    the "Initial objective" as defined in Section 7.4.3.2.
>> > 
>> > Current (made 'initial objective' plural because there are two initial objectives specified in Section 7.4.3.2): 
>> >    Configure the traffic load profile of the test equipment to establish
>> >    the initial objectives as defined in Section 7.4.3.2.
>> > -->
>> > 
>> > 
>> > 21) <!-- [rfced] Throughout the text, the KPIs appear to be capitalized inconsistently. May we make the KPIs lower case when used generally in the text and upper case in section titles and when they are being defined?
>> > 
>> > For example:
>> > Original:
>> >    The duration for the ramp
>> >    up phase MUST be configured long enough that the test equipment
>> >    does not overwhelm the DUT/SUTs stated performance metrics
>> >    defined in Section 6.3 namely, TCP or QUIC Connections Per
>> >    Second, Inspected Throughput, Concurrent TCP or QUIC Connections,
>> >    and Application Transactions Per Second.
>> >    ...
>> >    *  Application Transactions Per Second
>> > 
>> >       The average number of successfully completed transactions per
>> >       second.  For a particular transaction to be considered successful,
>> >       all data MUST have been transferred in its entirety.  In case of
>> >       HTTP(S) transactions, it MUST have a valid status code (200 OK).
>> > 
>> > Perhaps:
>> >    The duration for the ramp up phase
>> >    MUST be configured long enough that the test equipment does not
>> >    overwhelm the DUT's/SUT's stated performance metrics defined in
>> >    Section 6.3, namely TCP/QUIC connections per second, inspected
>> >    throughput, concurrent TCP/QUIC connections, and application
>> >    transactions per second.
>> >    ...
>> >    Application Transactions Per Second
>> >       The average number of successfully completed transactions per
>> >       second.  For a particular transaction to be considered successful,
>> >       all data MUST have been transferred in its entirety.  In case of
>> >       an HTTP(S) transaction, it MUST have a valid status code (200 OK).
>> > 
>> > List of the specific KPIs that are capitalized inconsistently:
>> > Concurrent TCP/QUIC Connections vs. concurrent TCP/QUIC connections
>> > Connections Per Second vs. connections per second vs. Connections per second vs.  Connections per Second
>> >    Note that the following is consistently capitalized: Initial connections per second
>> > Handshake Rate vs. handshake rate
>> > HTTP/HTTPS Throughput vs. HTTP/HTTPS throughput
>> > HTTP/HTTPS Transaction Latency vs. HTTP/HTTPS transaction latency
>> > Initial throughput vs. initial throughput
>> > Inspected Throughput vs. inspected throughput
>> > Transactions Per Second vs. transactions per second
>> > -->
>> > 
>> > 
>> > 22) <!-- [rfced] Terminology 
>> > 
>> > a) May we update "KBytes" to "KB" to match more common usage?
>> > 
>> > b) Please review the use of "TCP/QUIC connections". Does this mean "TCP or QUIC", "TCP and QUIC", or "TCP and/or QUIC"?
>> > 
>> > c) Please review the use of "TCP/HTTP connections". Does this mean "TCP connections carrying HTTP traffic"?
>> > -->
>> > 
>> > 
>> > 23) <!-- [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.
>> > 
>> > For example, please consider whether "dummy" should be updated.
>> > -->
>> > 
>> > 
>> > Thank you.
>> > 
>> > RFC Editor/ap/jm
>> > 
>> > 
>> > On 2/28/23 5:23 PM, [e-mail] wrote:
>> > 
>> > *****IMPORTANT*****
>> > 
>> > Updated 2023/02/28
>> > 
>> > 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
>> > 
>> >    *  [e-mail] (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).
>> > 
>> >    *  [e-mail], 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, 
>> >         [e-mail] 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/rfc9411.xml
>> >    https://www.rfc-editor.org/authors/rfc9411.html
>> >    https://www.rfc-editor.org/authors/rfc9411.pdf
>> >    https://www.rfc-editor.org/authors/rfc9411.txt
>> > 
>> > Diff file of the text:
>> >    https://www.rfc-editor.org/authors/rfc9411-diff.html
>> >    https://www.rfc-editor.org/authors/rfc9411-rfcdiff.html (side by side)
>> > 
>> > For your convenience, we have also created an alt-diff file that will 
>> > allow you to more easily view changes where text has been deleted or 
>> > moved: 
>> >    https://www.rfc-editor.org/authors/rfc9411-alt-diff.html 
>> > 
>> > Diff of the XML: 
>> >    https://www.rfc-editor.org/authors/rfc9411-xmldiff1.html
>> > 
>> > The following files are provided to facilitate creation of your own 
>> > diff files of the XML.  
>> > 
>> > Initial XMLv3 created using XMLv2 as input:
>> >    https://www.rfc-editor.org/authors/rfc9411.original.v2v3.xml 
>> > 
>> > XMLv3 file that is a best effort to capture v3-related format updates 
>> > only: 
>> >    https://www.rfc-editor.org/authors/rfc9411.form.xml
>> > 
>> > 
>> > Tracking progress
>> > -----------------
>> > 
>> > The details of the AUTH48 status of your document are here:
>> >    https://www.rfc-editor.org/auth48/rfc9411
>> > 
>> > Please let us know if you have any questions.  
>> > 
>> > Thank you for your cooperation,
>> > 
>> > RFC Editor
>> > 
>> > --------------------------------------
>> > RFC9411 (draft-ietf-bmwg-ngfw-performance-15)
>> > 
>> > Title            : Benchmarking Methodology for Network Security Device Performance
>> > Author(s)        : B. Balarajah, C. Rossenhoevel, B. Monkman
>> > WG Chair(s)      : Sarah Banks, Al Morton
>> > 
>> > Area Director(s) : Warren Kumari, Robert Wilton
>> > 
>> > 
>>