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

[[e-mail]]

Thanks everyone for your input and comments. They are helpful to the
authours.

Brian

-----Original Message-----
From: John C Klensin <[e-mail]> 
Sent: Friday, February 11, 2022 11:13 AM
To: Stewart Bryant <[e-mail]>; Scott Bradner <[e-mail]>
Cc: [e-mail]; IETF <[e-mail]>; The IESG <[e-mail]>;
[e-mail]; [e-mail]
Subject: Re: [bmwg] Murray Kucherawy's Discuss on
draft-ietf-bmwg-ngfw-performance-13: (with DISCUSS and COMMENT)



--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