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 <nico@xxxxxxxxxxxxxxxx> 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
--
