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 <john-ietf@xxxxxxx> wrote: > > > > --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 >
