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

[Scott Bradner <[e-mail]>]

I like John's suggestion - it gets to the issue I am worried about

Scott

> On Feb 11, 2022, at 11:13 AM, John C Klensin <[e-mail]> wrote:
> 
> 
> 
> --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
>