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

Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 16 February 2022 01:57 UTC

Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B203A12D3; Tue, 15 Feb 2022 17:57:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.098
X-Spam-Level:
X-Spam-Status: No, score=-7.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tavkiR9nvNz1; Tue, 15 Feb 2022 17:57:26 -0800 (PST)
Received: from mail-vk1-xa32.google.com (mail-vk1-xa32.google.com [IPv6:2607:f8b0:4864:20::a32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAE33A12D7; Tue, 15 Feb 2022 17:57:26 -0800 (PST)
Received: by mail-vk1-xa32.google.com with SMTP id n142so494012vkf.5; Tue, 15 Feb 2022 17:57:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ct+Td86sm2sfmwjyg8Z5qsDhSvf2BwhATkBlVyVYdC4=; b=FWVW8aAt/8tr6NXuz99mcTjcdcvk0Kiv1DYG1XuJS39eGSJNvsmFVKYAoIwDo8GXQo +jM1/vzVmVCcFRoILJdUCaGS0d+KDbTcyenkvVVwM8k+VgMmWKj7TU8wCGahfjZBDVWe ABxgXHoi6oPYTzFupdcdsya53AB2RWXBQ49Q+vmV1Coa4B3QtNoS3Ol/UmMD1OU17c8x ULhQSoAeahVAUVvM98hLpRmQmUgSeq7XzYIeP/HqXX2Sump3/5EyfvAgkVpsa6cj45fJ ykL7Aw+9RhnqHtxnxjvlfKAX+KwviPgoI5gbrBuiIqfSIbhElV3uWhzk+2XmFfweavkM J3Pw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ct+Td86sm2sfmwjyg8Z5qsDhSvf2BwhATkBlVyVYdC4=; b=NTK5ZPz53XYbdWGM35qxm/MqZfhBOZrNcDnCbhP+KEItw2ZX1E5e1SG0pP+VLTBHPe 90ZDyCjwjnKfmTQY5otl4SQ56CI0DOHNhl+axk6oM2OOm3z/bp2nF4JM+sh9Pj44C+GY IP6EaoM0aaVMovKtDAuErrDxY304mnX0yuZ9gcifgqU1BVknZ3j+20s8XDba6j8yw4pL p0QXSK0YO2j/8NbFThM33nWBXxjEbx/taFUGYCARr8/LC5WsfuDSpk5f0arsch1xobJg trsfQT0DN/84SKRq+xE6k5r2RfNQ7kDPALykYsRBSjAeo5O+3oS19H0xMOI94trGXneq qoaw==
X-Gm-Message-State: AOAM532eJ2wvl/pBWtrbzkae7K/ZgvInHPTOlcoEEE4IRWk3F7JOVc0b C/DJoh01pmpNnTCDmPCcekBQ5XmwwRUjolxya0A=
X-Google-Smtp-Source: ABdhPJwE031xRaiyTjmAdZBIWeij1YOLai/tQS3LTWCu6LHRuyPzNRzbrFu9iF6DY3fag9/DdiMSqznRJ+ApqDL7dYI=
X-Received: by 2002:a05:6122:20aa:b0:32d:4894:f680 with SMTP id i42-20020a05612220aa00b0032d4894f680mr231828vkd.1.1644976643998; Tue, 15 Feb 2022 17:57:23 -0800 (PST)
MIME-Version: 1.0
References: <164386586568.20734.14136987065393258244@ietfa.amsl.com> <fdb1df79-3a53-ea53-8532-ffb8d2545996@eantc.de> <CAL0qLwaDu9U1Kj_GtgNEY6JWpJncyC-t=NYA_uwOHs8zZmCHpQ@mail.gmail.com> <01D0C656-F323-4A7A-BF5B-764D646E2CD8@sobco.com> <5AAFE998-739E-48DA-B82D-2FBCD5989E42@gmail.com> <23A0A262ECC84B5B369983ED@PSB>
In-Reply-To: <23A0A262ECC84B5B369983ED@PSB>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Tue, 15 Feb 2022 19:56:58 -0600
Message-ID: <CAKKJt-fbmsh0sHEFtmWovCcRPOieSUJj1ObYKwKcE=uTgCGc+g@mail.gmail.com>
To: John C Klensin <john-ietf@jck.com>
Cc: Stewart Bryant <stewart.bryant@gmail.com>, Scott Bradner <sob@sobco.com>, draft-ietf-bmwg-ngfw-performance@ietf.org, bmwg-chairs@ietf.org, IETF <ietf@ietf.org>, bmwg@ietf.org, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008788fe05d818f8a6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/Es4LOH1Wua2NsCetVoQ72zO4CRM>
Subject: Re: [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
Precedence: list
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: Wed, 16 Feb 2022 01:57:32 -0000

I also agree with Barry's note further down in this thread, but wanted to
talk about one of John's points here.

On Fri, Feb 11, 2022 at 10:14 AM John C Klensin <john-ietf@jck.com> wrote:

>
>
> If SHOULD is used, then it must be accompanied by at least one
> of:
>  (1) A general description of the character of the
>         exceptions and/or in what areas exceptions are likely to
>         arise.  Examples are fine but, except in plausible and
>         rare cases, not enumerated lists.
>  (2) A statement about what should be done, or what the
>         considerations are, if the "SHOULD" requirement is not
>         met.
>  (3) A statement about why it is not a MUST.


I never understood how a receiver of  a packet that did not satisfy what I
might call a "naked SHOULD" (with none of these coverings) was supposed to
know what to do next.

Since the receiver can't count on the SHOULD requirement being satisfied,
it seems like the least a specification could do, was to provide guidance
about what to do next, as in (2).

So I think (2) is even more helpful than the helpful (1) and (3).

Best,

Spencer