I agree with what Christian and others have said. BCP 14 is as clear as it reasonably can be, and everybody involved in processing a draft should be looking out for SHOULDs that lack explanation for the exceptions or MUSTs that are over-zealous.
(There used to be a school of thought that a protocol without a state diagram was not properly defined, but that is not a popular doctrine in the IETF.)
Regards/Ngā mihi
Brian Carpenter
On 31-Aug-25 07:09, Christian Huitema wrote:
On 8/30/2025 12:24 AM, Carsten Bormann wrote:
On Aug 30, 2025, at 07:15, Christian Huitema <huitema@xxxxxxxxxxx> wrote:
Not that SHOULD effectively means "MUST UNLESS". That is, "You SHOULD do this" is equivalent to "You MUST do this, unless you have a very good reason not too" ... but the reason is generally left unstated, except in the "SHOULD but MAY" construct as in the examples above.
For a previous message, I asked an LLM to find BCP 14 SHOULD/RECOMMENDED usages without stated exception conditions, for example in RFC 8949.
It found some, including a NOT RECOMMENDED in
https://www.rfc-editor.org/rfc/rfc8949.html#section-3.4-10
Good to know that an LLM can help finding these.
But in this case, the whole paragraph is there to alert the registrant (who is the one addressed by the NOT RECOMMENDED) about the undesirable consequences of an exception to this NOT RECOMMENDED.
So I think in this instance we are well within the spirit of what is being discussed here.
This makes me not so sure we want to enshrine specific phrasings of the "You SHOULD do X because if you don’t, you get Y, which is less preferable because Z” (here: You SHOULD NOT do X̅ because if you do, you don’t get Y̅, which is preferable because Z) into further rulemaking.
This sub-thread about MUST/SHOULD started with Toerless questioning the
use of MUST or MUST NOT in operational documents. I have to read a bit
between the lines, but he seemed to be concerned that WG will specify
that the operator MUST do something when in fact their was a bit of a
gray area and some operators had a need to break the rule for good
reasons, and that the strict requirement could lead to interoperability
failures between those enforcing the mandate and those believing they
cannot follow it. Should we somehow update BCP 14 to somehow qualify
MUST statements in standards?
For me, that's the core of the difference between MUST and SHOULD. If a
behavior is mandated by a MUST statement, not following it is a protocol
violation, and the peers MAY take some action such as terminating the
connection. It is indeed an interop failure, but that failure is caused
by the peer not following the standard. The onus is on the offender to
change their implementation and correct their behavior. On the other
hand, if the recommended behavior is actually optional, not following it
is OK. An entity who would refuse to interop because the peer doe not
follow the recommendation is wrong. They, not their peers, have to
change their implementation or their behavior.
All this has implications on how we write and review standards. If we
are too strict and write "MUST" when there are in fact good reasons for
exceptions, we cause future interop failures. But there are also
consequences of being to lenient, because standards that allow
exceptions do cause the kind of "standard drift" outlines in RFC 9413.
Good standard writing means avoiding these two failure modes. If there
are known exceptions, it is better to list them, using either something
like "SHOULD but MAY" or "MUST ... UNLESS". If there are unknown
exceptions, then the standard should use SHOULD, but it should also
explain what to do if the peer does not follow the recommendation.
The good news is that many reviewers are aware of that. It is quite
common to see last call reviews flagging the use of unqualified SHOULD
and asking the authors to specify what kind of exceptions they have in
mind. That's a behavior that we need to encourage -- and I don't think
that we need to rewrite BCP 14 to do that.
As for Toerless original point, if the way a proposed standard is
written does cause interop failure, the remedy is probably to file an
errata and trigger a discussion in the working group.
-- Christian Huitema
