Thanks everyone for your input and comments. They are helpful to the authours. Brian -----Original Message----- From: John C Klensin <john-ietf@xxxxxxx> Sent: Friday, February 11, 2022 11:13 AM To: Stewart Bryant <stewart.bryant@xxxxxxxxx>; Scott Bradner <sob@xxxxxxxxx> Cc: bmwg-chairs@xxxxxxxx; IETF <ietf@xxxxxxxx>; The IESG <iesg@xxxxxxxx>; bmwg@xxxxxxxx; draft-ietf-bmwg-ngfw-performance@xxxxxxxx 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 <stewart.bryant@xxxxxxxxx> wrote: > > >> On 11 Feb 2022, at 12:08, Scott Bradner <sob@xxxxxxxxx> 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
