On 2012-05-20 17:29, John C Klensin wrote:
>
> --On Sunday, May 20, 2012 07:53 +0100 Brian E Carpenter
> <brian.e.carpenter@xxxxxxxxx> wrote:
>
>> On 2012-05-19 20:39, Ofer Inbar wrote:
>> ...
>>
>>> But don't change the rules. 2119 works well as is IMO.
>> Just to be clear about the current rules, 2119 makes it clear
>> that upper case keywords are optional ("These words are often
>> capitalized"). Indeed, numerous standards track documents
>> don't use them.
>
> Brian,
>
> I've been trying really hard to avoid this discussion, but I
> think the above is misleading.
My personal preference is to use RFC 2119, but if the IESG made
that into a rule without community consensus, I think it would
be wrong.
>
> In recent years, various IESG members have insisted that any
> IETF Track document that contains anything approximating
> conformance language include the 2119 reference and whatever the
> strict interpretation of the week is about caps, etc. As Randy
> suggests, there have been signs of more nuance in the last IESG
> or two, but...
>
> The same problem applies to the other issue with 2119, which is
> that we have history for at least two different interpretations
> of those words, the ones in 2119 that are interpreted as
> "necessary for interoperability" and the ones in, e.g.,
> 1122/1123 (Section 1.3.2 in the latter) which are "requirements
> of the specification" without binding those requirements to a
> particular reason. From my point of view, the other difficulty
> with treating 2119 like Received Wisdom and a set of absolute
> requirements is that the interoperability criterion often makes
> no sense for what are perfectly reasonable requirements. As an
> example drawn from 1123, a specification might reasonably say
> "this option MUST be configurable" because it is necessary to
> make things work in a plausible way even if that statement
> cannot be explicitly linked to "won't interoperate unless it
> does". But again, in recent years, some IESG members (and
> others) have insisted that only the 2119 definitions are
> permitted.
>
> The combination of the two is known in some quarters as writing
> technically poor or deficient specs in the interest of clear
> conformance to procedures. At least historically, that was a
> trap the IETF tried to avoid.
Yes, it would be sad if the IETF were no longer to allow itself to
apply common sense rather than rules.
Brian
>
> john
>
>
>
>
>
>
>