Re: A question about requirements

[Bernard Aboba <aboba@internaut.com>]

> As I watch discussions in some other groups, and am possibly
> approaching such an issue in my WG, I have started wondering about the
> force of requirements documents published as Informational.

> yet fill them with words like MUST, MUST NOT, SHOULD etc...

One thing to understand is that these terms do not have the same meaning
in a requirements document as they do in a specification fulfilling the
requirements.   For example, saying that a protocol satisfying the requirements
MUST support encryption is not the same thing as saying that encryption
MUST be mandatory-to-implement or mandatory to use within the protocol itself.
One might even argue that optional encryption support could satisfy the
requirement.  This means that in requirements documents normative language
is inherently weaker than in a protocol specification.

> My question is, what force do words like these have in a document that
> is merely informational.

They have whatever force the WG (and the IESG) wishes to give them.  Many
of the recent requirements documents might be better off being forgotten
entirely -- and some have been deemed so valuable as to not even be worth
finishing.

> Are IETF 'requirements' only guidelines that MAY or MAY NOT be minded?
> Or have I missed some BCP that defines such force?

In practice there are elements of requirements documents which appear
foolish in hindsight -- and I would argue that they only need be minded
to the extent that they make sense once the WG understands the problem
better.