> > -----Original Message----- > > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of Melinda Shore > > Sent: Thursday, September 01, 2011 12:45 PM > > To: ietf@xxxxxxxx > > Subject: Re: Minimum Implementation Requirements (Was: 2119bis) > > > > Can anybody point to an incident in which lack of clarity around > > 2119 language caused problems, and it was determined that 2119 > > itself was the problem and not authors or editors being careless? > +1. > As we've defined SHOULD and MUST in RFC2119, they lay out conformance requirements. I still don't see what's broken. > If the "Why is this a SHOULD and not a MUST?" question that Spencer pointed > out is a common one, then guidance to authors might be an appropriate > addition. The fact that reviewers sometimes question the choice between a SHOULD and MUST (in either direction) demonstrates absolutely nothing in and of itself. In fact I see such questions as entirely healthy and appropriate, indeed, if they didn't come up fairly regularly I'd strongly suspect we have a much bigger problem with our specifications not taking operational realities into account. Now, if when such questions arise the eventual outcome is often that the SHOULD gets changed to a MUST or vice versa, then we may have an issue with using the terms that needs to be addressed. Or we may not - there are plenty of other possible explanations. But we can save the root cause analysis until there is at least some evidence that compliance terms are regularly being *changed* as a result of review feedback. AFAIK such evidence has not been introduced. Ned P.S. And if anyone seeks to provide such evidence, please remember that data is not the plural of anecdote. _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf