[bmwg] Éric Vyncke's Yes on draft-ietf-bmwg-ngfw-performance-14: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-bmwg-ngfw-performance-14: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-bmwg-ngfw-performance/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document and for addressing my previous
DISCUSS and my previous COMMENT. They are kept below only for archiving purpose.

Thanks to Toerless for his deep and detailed IoT directorate review, I have
seen as well that the authors are engaged in email discussions on this review:
https://datatracker.ietf.org/doc/review-ietf-bmwg-ngfw-performance-13-iotdir-telechat-eckert-2022-01-30/

Special thanks to Al Morton for the shepherd's write-up including the section
about the WG consensus.

I hope that this helps to improve the document,

Regards,

-éric

# previous DISCUSS for archiving

As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a
DISCUSS ballot is a request to have a discussion on the following topics

The document obsoletes RFC 3511, but it does not include any performance
testing of IP fragmentation (which RFC 3511 did), which is AFAIK still a
performance/evasion problem. What was the reason for this lack of IP
fragmentation support ? At the bare minimum, there should be some text
explaining why IP fragmentation can be ignored.

# previous COMMENT for archiving

One generic comment about the lack of testing with IPv6 extension headers as
they usually reduce the performance (even for NGFW/NGIPS). There should be some
words about this lack of testing.

## Section 4.1

Please always use "ARP/ND" rather than "ARP".

## Section 4.2

Any reason why "SSL" is used rather than "TLS" ?

Suggest to replace "IP subnet" by "IP prefix".

## Section 4.3.1.2 (and other sections)

"non routable Private IPv4 address ranges" unsure what it is ? RFC 1918
addresses are routable albeit private, or is it about link-local IPv4 address ?
169.254.0.0/16 or 198.18.0.0/15 ?

## Section 4.3.1.3

Suggest to add a date information (e.g., 2022) in the sentence "The above
ciphers and keys were those commonly used enterprise grade encryption cipher
suites for TLS 1.2".

In "[RFC8446] defines the following cipher suites for use with TLS 1.3." is
this about a SHOULD or a MUST ?

## Section 6.1

In "Results SHOULD resemble a pyramid in how it is reported" I have no clue how
a report could resemble a pyramid. Explanations/descriptions are welcome in the
text.

## Section 7.8.4 (and other sections)

In "This test procedure MAY be repeated multiple times with different IP types
(IPv4 only, IPv6 only and IPv4 and IPv6 mixed traffic distribution)" should it
be a "SHOULD" rather than a "MAY" ?