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
> > > --
> > >
> >
--
---
tte@xxxxxxxxx
