[bmwg] Murray Kucherawy's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)

Murray Kucherawy via Datatracker <noreply@ietf.org> Thu, 03 February 2022 05:24 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: bmwg@ietf.org
Delivered-To: bmwg@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E4353A1C49; Wed, 2 Feb 2022 21:24:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Murray Kucherawy via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-bmwg-ngfw-performance@ietf.org, bmwg-chairs@ietf.org, bmwg@ietf.org, Al Morton <acm@research.att.com>
X-Test-IDTracker: no
X-IETF-IDTracker: 7.44.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Murray Kucherawy <superuser@gmail.com>
Message-ID: <164386586568.20734.14136987065393258244@ietfa.amsl.com>
Date: Wed, 02 Feb 2022 21:24:26 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/fR9wiw_vVvHrx4GgZU3C6peGNp4>
Subject: [bmwg] Murray Kucherawy's Discuss on draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2022 05:24:27 -0000

Murray Kucherawy has entered the following ballot position for
draft-ietf-bmwg-ngfw-performance-13: Discuss

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/blog/handling-iesg-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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I may be wandering into unfamiliar territory here, i.e., how benchmarking specs
are typically written, but this is sufficiently confusing that I'd like to
discuss it.

I note that RFC 3511, which this document obsoletes, didn't cite RFC 2119 (BCP
14) but rather defined those same key words on its own.  Then it used SHOULD
rather liberally, in a way that seems kind of peculiar to me (especially
compared to the text of Section 6 of RFC 2119).  Do any of them matter to the
outcome of the benchmark being constructed or executed?  If so and they would
spoil the test, shouldn't they be MUSTs?  If not, why include them?  Or in the
alternative, why might I, as someone setting up a test, legitimately do
something contrary to the SHOULD in each case (which "SHOULD" expressly
permits)?

This document does cite BCP 14 directly, and then seems to take that curious
pattern to the next level.  Among the 130+ SHOULDs in here, I'm particularly
confused by stuff like this in Section 4.3.1:

   This section specifies which parameters SHOULD be considered while
   configuring clients using test equipment.

I have no idea what this means to the test.  If I've simply thought about these
parameters, have I met the burden here?

This in Section 4.3.1.1 ("TCP Stack Attributes") seems an odd thing to have to
stipulate:

  The client SHOULD initiate and close TCP connections.

Then Section 7.1.3, which contains subsections about each of the test
parameters for the benchmark described in Section 7.1, consists of this text:

   In this section, the benchmarking test specific parameters SHOULD be
   defined.

As I read it, this is a self-referential SHOULD about this document!  I'm very
confused.  This happens again in Section 7.2.3, 7.3.3, etc., up to 7.9.3, and
even Appendix A.3.  I think in each case you just want:

   This section defines test-specific parameters for this benchmark.


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

Nits not yet mentioned by others:

Section 4.2:

* "... users SHOULD configure their device ..." -- s/device/devices/ (unless
all users share one device)

Section 6.3:

* "The value SHOULD be expressed in millisecond." -- s/millisecond/milliseconds/