Re: [bmwg] FW: WGLC on New version of draft-ietf-bmwg-ngfw-performance

[[e-mail]]

Hi Al,

 

Thanks for sending this over. Our comments are embedded below, prefaced by
[bpm].

 

Brian

 

From: MORTON JR., AL <[e-mail]> 
Sent: Wednesday, May 19, 2021 10:01 PM
To: [e-mail]; 'Gabor LENCSE' <[e-mail]>
Cc: 'MORTON, ALFRED C (AL)' <[e-mail]>; [e-mail]; 'Bala
Balarajah' <[e-mail]>; 'Bala Balarajah' <[e-mail]>
Subject: RE: [bmwg] FW: WGLC on New version of
draft-ietf-bmwg-ngfw-performance

 

Thanks to the authors/editor for continuing to chase-down comments and
resolving them.

I know very well how much work this is.

 

I’m trying to finish-up my review tonight (as a participant):

 

   o  Inspected Throughput

      The number of bits per second of allowed traffic a network

      security device is able to transmit to the correct destination

      interface(s) in response to a specified offered load.  The

      throughput benchmarking tests defined in Section 7 SHOULD measure

      the average OSI model Layer 2 throughput value.  This document

      recommends presenting the throughput value in Gbit/s rounded to

      two places of precision with a more specific Kbit/s in

      parenthesis.

 

Let me suggest a couple of tweaks on this definition:

 

It took me several minutes to remember that “inspected” invokes the role of
security device, for some reason.

 

The OSI model doesn’t have a good reputation here at IETF, and the Internet
was not built based on ISO’s model.

 

So I’ll try a little editing:

 

   o  Inspected Throughput

      The number of bits per second of examined and allowed traffic a
network

      security device is able to transmit to the correct destination

      interface(s) in response to a specified offered load.  The

      throughput benchmarking tests defined in Section 7 SHOULD measure

      the average Layer 2 throughput value when the DUT is “inspecting”
traffic.  This document

      recommends presenting the inspected throughput value in Gbit/s rounded
to

      two places of precision with a more specific Kbit/s in

      parenthesis.

 

[bpm] Good suggestion. We will change the wording.

 

I also checked the nits, which revealed use of 2 incorrect addresses as
examples.

BMWG has it’s own IPv4 and v6 address space assigned. Please use it where
appropriate.

I’m not sure where the offending addresses are, sorry!

 

Checking nits according to https://www.ietf.org/id-info/checklist :
 
----------------------------------------------------------------------------
 
  == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses
     in the document.  If these are example addresses, they should be
changed.
 
  == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses
     in the document.  If these are example addresses, they should be
changed.

 

The tables below are from RFC 6890:

                    +----------------------+---------------+
                    | Attribute            | Value         |
                    +----------------------+---------------+
                    | Address Block        | 198.18.0.0/15 |
                    | Name                 | Benchmarking  |
                    | RFC                  | [RFC2544
<https://datatracker.ietf.org/doc/html/rfc2544> ]     |
                    | Allocation Date      | March 1999    |
                    | Termination Date     | N/A           |
                    | Source               | True          |
                    | Destination          | True          |
                    | Forwardable          | True          |
                    | Global               | False         |
                    | Reserved-by-Protocol | False         |
                    +----------------------+---------------+
 
          Table 12: Network Interconnect Device Benchmark Testing

 

and 

 

 
                    +----------------------+----------------+
                    | Attribute            | Value          |
                    +----------------------+----------------+
                    | Address Block        | 2001:2::/48    |
                    | Name                 | Benchmarking   |
                    | RFC                  | [RFC5180
<https://datatracker.ietf.org/doc/html/rfc5180> ]      |
                    | Allocation Date      | April 2008     |
                    | Termination Date     | N/A            |
                    | Source               | True           |
                    | Destination          | True           |
                    | Forwardable          | True           |
                    | Global               | False          |
                    | Reserved-by-Protocol | False          |
                    +----------------------+----------------+
 
                          Table 24: Benchmarking

 

[bpm] We have looked through the document multiple times and in multiple
ways and cannot find anything that might trigger this. However, we did catch
a format error in the IPv6 address in section 8 – IANA considerations. So,
we are updating that section. 

 

 

Also:

 

  Miscellaneous warnings:
 
----------------------------------------------------------------------------
 
  == The document seems to lack the recommended RFC 2119 boilerplate, even
if
     it appears to use RFC 2119 keywords. 
 
     (The document does seem to have the reference to RFC 2119 which the
     ID-Checklist requires).
 

The section seems to exist, but may need slight re-wording, 

to match RFC 8174, or this version of the nits-checker is out of date

(it doesn’t mention rfc 8174?):

 

2
<https://datatracker.ietf.org/doc/html/draft-ietf-bmwg-ngfw-performance-08#s
ection-2> .  Requirements
 
   The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in BCP
<https://datatracker.ietf.org/doc/html/bcp14> 
   14 <https://datatracker.ietf.org/doc/html/bcp14>  [RFC2119
<https://datatracker.ietf.org/doc/html/rfc2119> ], [RFC8174
<https://datatracker.ietf.org/doc/html/rfc8174> ] when, and only when, they
appear in all
   capitals, as shown here.

 

[bpm] I went and looked at the wording RFC 8174 and it is identical to the
wording above.

 

 

thanks,

Al

 

 

From: bmwg <[e-mail] <mailto:[e-mail]> > On Behalf
Of MORTON JR., AL
Sent: Monday, May 10, 2021 1:34 PM
To: [e-mail] <mailto:[e-mail]> ; 'Gabor
LENCSE' <[e-mail] <mailto:[e-mail]> >
Cc: 'MORTON, ALFRED C (AL)' <[e-mail]
<mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ;
'Bala Balarajah' <[e-mail] <mailto:[e-mail]> >; 'Bala
Balarajah' <[e-mail] <mailto:[e-mail]> >
Subject: Re: [bmwg] FW: WGLC on New version of
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.

of course Brian and Gábor, I can use the extra time myself.

 

 

BMWG,

We will extend the deadline for WGLC to May 21, as requested.

Al

bmwg co-chair

 

From: [e-mail] <mailto:[e-mail]>
<[e-mail] <mailto:[e-mail]> > 
Sent: Monday, May 10, 2021 1:02 PM
To: 'Gabor LENCSE' <[e-mail] <mailto:[e-mail]> >
Cc: 'Bala Balarajah' <[e-mail] <mailto:[e-mail]> >;
'Bala Balarajah' <[e-mail] <mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]> ; 'MORTON, ALFRED C (AL)'
<[e-mail] <mailto:[e-mail]> >; 'Sarah Banks'
<[e-mail] <mailto:[e-mail]> >
Subject: RE: [bmwg] FW: WGLC on New version of
draft-ietf-bmwg-ngfw-performance

 

Thanks Gabor.

 

Al, could you extend the deadline for WGLC to May 21st from May 17th?

 

Brian

 

From: Gabor LENCSE <[e-mail] <mailto:[e-mail]> > 
Sent: Monday, May 10, 2021 12:58 PM
To: [e-mail] <mailto:[e-mail]> 
Cc: 'Bala Balarajah' <[e-mail] <mailto:[e-mail]> >;
'Bala Balarajah' <[e-mail] <mailto:[e-mail]> >;
[e-mail] <mailto:[e-mail]> ; 'MORTON, ALFRED C (AL)'
<[e-mail] <mailto:[e-mail]> >; 'Sarah Banks'
<[e-mail] <mailto:[e-mail]> >
Subject: Re: [bmwg] FW: WGLC on New version of
draft-ietf-bmwg-ngfw-performance

 

Hi Brian,

Perhaps I can do another chunk later this week, and I plan to complete it
next week. 

Best regards,

Gábor

On 5/10/2021 6:45 PM, [e-mail]
<mailto:[e-mail]>  wrote:

Hi Gabor,

 

Thank you very much for your comments. On initial review they all look
reasonable to us. How long do you think it will take you to complete your
review of the rest of the document?

 

Brian