Subject: Re: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

From: "MORTON JR., AL" <[email-masked]>
Date: Sat, 6 Nov 2021 18:08:11 +0000

Hi Bala, Carsten, and Brian,
(Authors of Version 11, draft-ietf-bmwg-ngfw-performance)

I just checked version 11, and it appears that some of the comments raised during my document shepherd's review have not yet been addressed. I'm sorry for the tardiness of this finding, but it means there is a simple way to find the comments (and they are all in category: editorial).  These comments were included in the document shepherd's form (which was attached to my original message, and attached here again), in addition to a small number of comments at the end of my message about version 10 (which may have caused some confusion).

This time, in case there is a problem finding the >>> comments in the attachment, I will extract them below.

I don't feel that any of these comments should hold-up a publication request, but we can discuss this on Monday with Warren, our AD-Advisor.

many thanks for your patience and your efforts,
Al

(in the doc shepherd form technical summary)

>>> One important comment remains to be addressed:
Since this memo Obsoletes RFC 3511, a sentence indicating this action must be added to the Abstract according to current practice.

>>> One additional comment on version 10:
The Security Directorate Review usually goes more smoothly when the Security Considerations section (9) re-enforces that the scope of this document is a laboratory Isolated Test Environment (and not production network testing). Sample text is available to use in this section, consistent with BMWG's lab-only charter.

Also, see a few ">>>" below.
....

(11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough.

The current nits-check is below, with [acm] comments:
...

  -- The draft header indicates that this document obsoletes RFC3511, but the
     abstract doesn't seem to mention this, which it should.
[acm]
>>> This needs fix, as mentioned earlier.

...

  Checking references for intended status: Informational
  ----------------------------------------------------------------------------

  -- Obsolete informational reference (is this intentional?): RFC 2616
     (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235)
[acm]
>>>> Authors, Please check this ref, see if it can be updated.  <<<<

...
(16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary.

>>> As mentioned twice above, RFC 3511 will become obsolete, and this fact needs to appear in the Abstract.
...
(17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 8126).

>>> The draft discusses the BMWG address assignments in this section (8). However, the draft makes no specific request of IANA, and should say that first.

From: MORTON JR., AL <[email-masked]>
Sent: Saturday, October 16, 2021 6:12 PM
To: MORTON JR., AL <[email-masked]>; [email-masked]; [email-masked]
Cc: [email-masked]; 'Carsten Rossenhoevel' <[email-masked]>
Subject: RE: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

Hi authors and BMWG,

Thank you for all efforts to complete the review, comment resolution, and document revisions!

I have completed the "first-pass" document shepherd's review of this draft.

I attached and uploaded the current version of the shepherd's review form, which contains Q&A with some action items for the authors.

I want to be sure that the authors considered the "early" Security review from Kathleen Moriarty:
https://datatracker.ietf.org/doc/review-ietf-bmwg-ngfw-performance-00-secdir-early-moriarty-2019-07-08/

Also, I have a few small suggestions below.

Thanks again,
Al
bmwg co-chair

We haven't tied the "in-line" terminology to the Figures; I think it would be good to do that. Many non-benchmarking experts will read this doc in the coming months (and this is an easy future comment to avoid).
OLD
3.  Scope

   This document provides testing terminology and testing methodology
   for modern and next-generation network security devices that are
   configured in Active ("Inline") mode.
NEW

3.  Scope

   This document provides testing terminology and testing methodology

   for modern and next-generation network security devices that are

   configured in Active ("Inline", see Figures 1 and 2) mode.

-=-=-=-=-=-

In section 4.3.3, the word "balanced\" appears, and the trailing slash needs to be deleted.

-=-=-=-=-=-=-

In section 7.1.1, the sentence beginning

OLD

   Based on customer use case, users can choose...

tripped me up, and a few more words will help, I think:

NEW

   Based on the test customer's specific use case, testers can choose...

(note that there is only one instance of "customer" in the doc, so we should make the customer's role clear here)

-=-=-=-=-=-=-

From: bmwg <[email-masked]<mailto:[email-masked]>> On Behalf Of MORTON JR., AL
Sent: Sunday, September 26, 2021 12:54 PM
To: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
BMWG,

Those who have submitted comments on recent versions (8,9) should check the diffs now.
Please confirm that your comments have been addressed in version 10, by e-mail, ASAP.

thanks,
Al
bmwg co-chair

From: bmwg <[email-masked]<mailto:[email-masked]>> On Behalf Of [email-masked]<mailto:[email-masked]>
Sent: Sunday, September 26, 2021 10:31 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

Folks,

An update to draft-ietf-bmwg-ngfw-performance has been posted. I believe the next step is WG Chair review.

Version 10 has gone through multiple reviews . As a result, we have corrected a number of typos and grammatical errors. Additionally, we clarified wording in a few spots. The following has also been changed as a result of comments/discussions from/with Sarah Banks. (Sarah, thank you.)

  *   Removed NGIDS from the draft
  *   Added the following text in section 3 for "Inline" mode and "Fail-open" clarification: " This document provides testing terminology and testing methodology for modern and next-generation network security devices that are configured in Active ("Inline") mode."
  *   Also, we added the following text in section 4.2:  "DUT/SUT MUST be configured in "Inline" mode so that the traffic is actively inspected by the DUT/SUT.  Also "Fail-Open" behavior MUST be disabled on the DUT/SUT."
  *   Added more clarification for the parameters and values defined in section "4.3.1.  Client Configuration": This section specifies which parameters SHOULD be considered while configuring clients using test equipment.  Also, this section specifies the RECOMMENDED values for certain parameters.  The values are the defaults used in most of the client operating systems currently.
  *   Rephrased section 5 " Testbed Consideration". Added recommended steps for reference test.
  *   Explained the usage of the parameter "Initial throughput": "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 under the Section 7.1.4."
Brian

---------
Brian Monkman
Executive Director, NetSecOPEN
Office: +1-717-610-0808
Fax: +1-717-506-0460
Mobile: +1-717-462-5422

https://www.netsecopen.org<https://urldefense.com/v3/__https:/www.netsecopen.org__;!!BhdT!wpaM8GOInxvNJdztL0uqXkYCL1UWmjmmAASp8hiMJEKN0JgjzEyGqz2m7207$>

---

From: <[email-masked]>
Date: Sat, 6 Nov 2021 17:24:36 -0400

Thanks Al. Apologies for missing this. Not sure how we overlooked it.

Brian

From: MORTON JR., AL <[email-masked]> 
Sent: Saturday, November 6, 2021 2:08 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]; 'Carsten Rossenhoevel' <[email-masked]>
Subject: RE: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

I just checked version 11, and it appears that some of the comments raised
during my document shepherd's review have not yet been addressed. I'm sorry
for the tardiness of this finding, but it means there is a simple way to
find the comments (and they are all in category: editorial).  These comments
were included in the document shepherd's form (which was attached to my
original message, and attached here again), in addition to a small number of
comments at the end of my message about version 10 (which may have caused
some confusion).

This time, in case there is a problem finding the >>> comments in the
attachment, I will extract them below.

I don't feel that any of these comments should hold-up a publication
request, but we can discuss this on Monday with Warren, our AD-Advisor.

Al

>>> One important comment remains to be addressed:

Since this memo Obsoletes RFC 3511, a sentence indicating this action must
be added to the Abstract according to current practice.

>>> One additional comment on version 10:

The Security Directorate Review usually goes more smoothly when the Security
Considerations section (9) re-enforces that the scope of this document is a
laboratory Isolated Test Environment (and not production network testing).
Sample text is available to use in this section, consistent with BMWG's
lab-only charter.

....

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

...

  -- The draft header indicates that this document obsoletes RFC3511, but
the

[acm]

...

     (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC
7235)

[acm]

...

(16) Will publication of this document change the status of any existing
RFCs? Are those RFCs listed on the title page header, listed in the
abstract, and discussed in the introduction? If the RFCs are not listed in
the Abstract and Introduction, explain why, and point to the part of the
document where the relationship of this document to the other RFCs is
discussed. If this information is not in the document, explain why the WG
considers it unnecessary.

...

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes are
associated with the appropriate reservations in IANA registries. Confirm
that any referenced IANA registries have been clearly identified. Confirm
that newly created IANA registries include a detailed specification of the
initial contents for the registry, that allocations procedures for future
registrations are defined, and a reasonable name for the new registry has
been suggested (see RFC 8126). 

>>> The draft discusses the BMWG address assignments in this section (8).
However, the draft makes no specific request of IANA, and should say that
first.

 

From: MORTON JR., AL <[email-masked] <mailto:[email-masked]> > 
Sent: Saturday, October 16, 2021 6:12 PM
To: MORTON JR., AL <[email-masked] <mailto:[email-masked]> >;
[email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> ; 'Carsten
Rossenhoevel' <[email-masked] <mailto:[email-masked]> >
Subject: RE: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

Hi authors and BMWG,

Thank you for all efforts to complete the review, comment resolution, and
document revisions!

I attached and uploaded the current version of the shepherd's review form,
which contains Q&A with some action items for the authors.

I want to be sure that the authors considered the "early" Security review
from Kathleen Moriarty:

https://datatracker.ietf.org/doc/review-ietf-bmwg-ngfw-performance-00-secdir
-early-moriarty-2019-07-08/

Thanks again,

Al

bmwg co-chair

We haven't tied the "in-line" terminology to the Figures; I think it would
be good to do that. Many non-benchmarking experts will read this doc in the
coming months (and this is an easy future comment to avoid).

OLD 

3.  Scope

NEW 

3.  Scope

-=-=-=-=-=-
 
In section 4.3.3, the word "balanced\" appears, and the trailing slash needs
to be deleted.
 
-=-=-=-=-=-=-

 
(note that there is only one instance of "customer" in the doc, so we should
make the customer's role clear here)
-=-=-=-=-=-=-

 

From: bmwg <[email-masked] <mailto:[email-masked]> > On Behalf
Of MORTON JR., AL
Sent: Sunday, September 26, 2021 12:54 PM
To: [email-masked] <mailto:[email-masked]> ; [email-masked]
<mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: Re: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

BMWG,

Those who have submitted comments on recent versions (8,9) should check the
diffs now.

Please confirm that your comments have been addressed in version 10, by
e-mail, ASAP.

thanks,

Al

bmwg co-chair

From: bmwg <[email-masked] <mailto:[email-masked]> > On Behalf
Of [email-masked] <mailto:[email-masked]> 
Sent: Sunday, September 26, 2021 10:31 AM
To: [email-masked] <mailto:[email-masked]> 
Cc: [email-masked] <mailto:[email-masked]> 
Subject: [bmwg] Version 10, draft-ietf-bmwg-ngfw-performance

Folks,

An update to draft-ietf-bmwg-ngfw-performance has been posted. I believe the
next step is WG Chair review.

Version 10 has gone through multiple reviews . As a result, we have
corrected a number of typos and grammatical errors. Additionally, we
clarified wording in a few spots. The following has also been changed as a
result of comments/discussions from/with Sarah Banks. (Sarah, thank you.)

*	Removed NGIDS from the draft
*	Added the following text in section 3 for "Inline" mode and
"Fail-open" clarification: " This document provides testing terminology and
testing methodology for modern and next-generation network security devices
that are configured in Active ("Inline") mode."
*	Also, we added the following text in section 4.2:  "DUT/SUT MUST be
configured in "Inline" mode so that the traffic is actively inspected by the
DUT/SUT.  Also "Fail-Open" behavior MUST be disabled on the DUT/SUT."
*	Added more clarification for the parameters and values defined in
section "4.3.1.  Client Configuration": This section specifies which
parameters SHOULD be considered while configuring clients using test
equipment.  Also, this section specifies the RECOMMENDED values for certain
parameters.  The values are the defaults used in most of the client
operating systems currently.
*	Rephrased section 5 " Testbed Consideration". Added recommended
steps for reference test.
*	Explained the usage of the parameter "Initial throughput": "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 under the Section 7.1.4."

Brian

---------

Brian Monkman

Office: +1-717-610-0808 

Fax: +1-717-506-0460

Mobile: +1-717-462-5422

https://www.netsecopen.org
<https://urldefense.com/v3/__https:/www.netsecopen.org__;!!BhdT!wpaM8GOInxvN
JdztL0uqXkYCL1UWmjmmAASp8hiMJEKN0JgjzEyGqz2m7207$>