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

[John C Klensin <[e-mail]>]

--On Friday, February 11, 2022 12:22 +0000 Stewart Bryant
<[e-mail]> wrote:

> 
> 
>> On 11 Feb 2022, at 12:08, Scott Bradner <[e-mail]> wrote:
>> 
>> I do not think it is useful to use SHOULD without
>> specifically saying what the escape clause is -  i.e.
>> specifically say when its OK to not act as if it was a MUST
> 
> Hi Scott
> 
> The problem with that is it requires perfect foresight on the
> exceptions.
> 
> I have always taken SHOULD to mean that you MUST do this
> unless you have a good reason not to do this and understand
> the consequences for your system in its deployment environment.
> 
> In other words I think we need to trust the engineer
> implementing the system to apply good judgement when they
> ignore the MUST element of the SHOULD.

Stewart,

As Scott probably remembers, I've advocated several times  --
with the IESG, IAB, and with the RFC Editor -- for a rule that
is a little more flexible than the one Scott suggests above but
that treats "good judgment" differently.  That suggestion has
been something like the following:

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.

The first option was not just because of your "perfect
foresight" comment above but because attempts to enumerate all
cases can easily lead into "what is not explicitly forbidden is
permitted" thinking which is never good for standards.  And,
especially if there is any ambiguity, all three need to be read
through the lens of the original intended interpretation of the
Robustness Principle.

I have no opinion about what should be done for the case of this
particular specification but, because this is not the first time
a problem like this has arisen _and_ because there have
occasionally been objections from within the IESG to documents
that discuss what to do if an implementation does not follow a
given specification, I would encourage the IESG and the
community to think about the issue more broadly.

   john