[bmwg] Ready for IETF LAST CALL: Version 12, draft-ietf-bmwg-ngfw-performance

["MORTON JR., AL" <[e-mail]>]

Hi Warren and BMWG,

I now confirm that the Document Shepherd's comments have been resolved in version 12 of the draft, and I changed the state to "Publication Requested" to begin next steps (AD-Review.  Warren has completed AD-review now, and IETF Last Call can begin.

Al
doc shepherd and bmwg co-chair

From: bmwg <[e-mail]> On Behalf Of MORTON JR., AL
Sent: Saturday, November 6, 2021 2:08 PM
To: [e-mail]; [e-mail]
Cc: [e-mail]
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.
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/<https://urldefense.com/v3/__http:/www.ietf.org/tools/idnits/__;!!BhdT!x7N0Uz6TqXL1jrqLzzXck77axqknF-T75gHEm813qW8RHjUburKzta7yzBDv$> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Saturday, October 16, 2021 6:12 PM
To: MORTON JR., AL <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>; 'Carsten Rossenhoevel' <[e-mail]<mailto:[e-mail]>>
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/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/review-ietf-bmwg-ngfw-performance-00-secdir-early-moriarty-2019-07-08/__;!!BhdT!x7N0Uz6TqXL1jrqLzzXck77axqknF-T75gHEm813qW8RHjUburKztVJ0OPt2$>

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 <[e-mail]<mailto:[e-mail]>> On Behalf Of MORTON JR., AL
Sent: Sunday, September 26, 2021 12:54 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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 <[e-mail]<mailto:[e-mail]>> On Behalf Of [e-mail]<mailto:[e-mail]>
Sent: Sunday, September 26, 2021 10:31 AM
To: [e-mail]<mailto:[e-mail]>
Cc: [e-mail]<mailto:[e-mail]>
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: [phone]
Fax: [phone]
Mobile: [phone]

[cid:image001.png@01D7F1A5.B7165170]
https://www.netsecopen.org<https://urldefense.com/v3/__https:/www.netsecopen.org__;!!BhdT!wpaM8GOInxvNJdztL0uqXkYCL1UWmjmmAASp8hiMJEKN0JgjzEyGqz2m7207$>