Re: Question about BCP 14 / RFC 8174

[Brian E Carpenter <[e-mail]>]

Toerless, I agree with you but again, my concern is not really about MUST/MANDATORY or MAY/OPTIONAL. It's about SHOULD/RECOMMENDED, where it might often be better to write MUST... UNLESS without BCP 14 really being needed.

As in "You SHOULD look both ways before crossing the road" vs "You MUST look both ways before crossing the road UNLESS you are being chased by a grizzly bear." That's the BCP 14 interpretation of SHOULD, but we have often seen evidence of developers interpreting it as "You don't really have to look both ways before crossing the road."

I think operators are much less likely to make that mistake, whether the RFC cites BCP 14 or not.

Regards/Ngā mihi
    Brian Carpenter

On 29-Aug-25 11:12, Toerless Eckert wrote:
> I don't want to spend the time not to find appropriate RFCs, but i think
> there are operational BCP documents that do use BCP14 language.
> 
> I think such use is very useful, but the BCP14 language does not
> really support such a use well. Especially not section 6. limits
> of the use of MUST against interoperability or harm.
> 
> Operators MUST wash their hands before and after touching routers to
> limit propagation of infectuous deseases.
> 
> Ok, that might check off against the harm criteria, but i doubt that
> everybody who writes MUST (NOT) requirements in such a document has
> thought of arguing harm if/when challenged by IETF/IESG review.
> 
> Likewise, we did have for a long time a very limited view of interoperability.
> For example anything between two software entities within the same physical
> box (and hence single vendor! - haha) was not allowed to call on the interop
> justification. Which is why we never standardized (abstract) API in those days...
> Luckily there is evolution in interpretation. Even in IETF.
> 
> I guess if/when push comes to shove, one may even modify the BCP14
> disclaimer specifically for such a document to amend/modify the operational
> conditions deemed appropriate for MUST (NOT) - in this dcocument.
> 
> Cheers
>      Toerless
> 
> Operators MUST NOT
> 
> I think that such use can be highly useful, but iof the language could be useful, but
> especially the that can be useful although the language, especially
> the guidance on MUST does actually constrain the
> 
> On Wed, Aug 27, 2025 at 08:53:56AM +1200, Brian E Carpenter wrote:
>> On 27-Aug-25 03:17, Barry Leiba wrote:
>>> You're not noticing that the OLD text also talks only about IETF
>>> documents by saying "many standards track documents".  The NEW text is
>>> intentionally broader, including all IETF documents -- Informational
>>> and Experimental as well.  That's because we've realized over time
>>> that it's useful to include BCP 14 key words in those also, not just
>>> in standards.
>>
>> Yes. Personally I would always think carefully about whether to use
>> them apart from the standards track, and they have sometimes been
>> confusing when used in documents that are not protocol definitions,
>> but there's no value in attempting to prohibit them.
>>> It was not intentional to say that *only* IETF documents use these.
>>> But we're only writing, here, about and for the IETF, and BCP 14 only
>>> explicitly applies to the IETF.
>>
>> Again, yes. If they prove useful for a non-IETF RFC, that's fine.
>>
>> As far as non-RFC documents go, I don't know about RFC 8174, but
>> RFC 2119 has been cited by hundreds, if not thousands, of other
>> documents. (Random example: "Openid provider authentication
>> policy extension 1.0" from 2008.) I don't know how many of them
>> really use "SHOULD" or "RECOMMENDED" correctly.
>>
>>     Brian
>>
>>>
>>> Barry
>>>
>>> On Mon, Aug 25, 2025 at 4:44 PM Nico Williams <[e-mail]> wrote:
>>>>
>>>> I guess I've been hiding under a rock or something and missed RFC 8174.
>>>> I was... surprised to see that the NEW text specifically refers to "many
>>>> IETF documents" considering that many non-IETF documents also make use
>>>> of BCP 14 terminology.
>>>>
>>>> Of course anyone making use of BCP 14 outside IETF documents can just
>>>> either not mind or elide the IETF specificity, so maybe "who cares".
>>>> But I find this change surprising, and odd.
>>>>
>>>> Nico
>>>> --
>>>>
>>>
>