--On Thursday, September 01, 2011 08:10 -0700 Pete Resnick
<presnick@xxxxxxxxxxxx> wrote:
>...
> Peter's document makes a change to 2119 that nobody has
> mentioned yet, and I think it is the one that is causing most
> of the strife in this discussion.
>
> Hector is exactly right. SHOULDs are optional. MAYs are
> optional. What he fails to point out is that MUSTs are also
> optional. They're all optional because.....
>
> RFC 2119 does *not* provide *conformance* terms.
>
> Peter's document uses the words "conform" and "conformance".
> They appear nowhere in RFC 2119. RFC 2119 was not coming up
> with a vocabulary for things that MUST be done if one is to
> conform to a specification. It came up with terms for things
> that MUST be done to interoperate. Or SHOULD be done (with a
> pretty specific meaning of "SHOULD"). Or MAY be done.
Pete,
This is right, but it is also close to (and hugely clarifies) my
earlier comment about the difference between 2119 language
(about interoperability requirements) and 1122/1123 language
(very much about conformance). A careful reading of the
introductions to those documents should make this clear. For
example, "This RFC enumerates standard protocols that a host
connected to the Internet must use,..." isn't a statement about
interoperability -- a host that doesn't support SMTP won't have
interoperability problems unless it decides to use some other
protocol on the relevant port.
Similarly,
"However, the specifications of this document must be
followed to meet the general goal of arbitrary host
interoperation across the diversity and complexity of
the Internet system."
talks about interoperation, but is actually a conformance
statement -- what one must do and conform to in order to meet an
interoperability goal.
Perhaps we should be saying something like "in a Technical
Specification, 2119-like language maps onto interoperability
conditions; in a Applicability Statement, the same language maps
onto conformance requirements". Unfortunately, we often mix the
two types of specifications together in single documents, so
such a provision would add, rather than reduce, confusion.
>...
> But if you think that the presence of SHOULD (or MUST) means
> that you *have to* implement a particular thing in a document,
> you're also wrong. There are not protocol police. We don't do
> conformance checks in the IETF.
But we do make conformity statements. We make an indirect one
every time we say "if some does X, it simply puts that outside
the specification". That doesn't translate as "won't
interoperate", in part because robustness provisions on the part
of a peer might cause it to work anyway, or because someone gets
lucky, or..., but it certainly translates as "doesn't conform".
> You might have a contract with someone who requires you to
> implement all MUSTs (or SHOULDs unless you provide an
> explanation of why you didn't). That's up to them. But the
> IETF ought not be in the business of conformance requirements.
That is actually a slightly different issue. We don't do
conformance testing or conformance certification, and I hope we
continue to stay far away from those swamps. But, until we
start saying, persuasively, "do not use RFCs in procurement
specifications" or "RFCs are unsuitable for procurement
specifications", we are in the conformance requirements business
whether we like it or not. And, were we to succeed in saying
those things, we would, IMO, swiftly become irrelevant.
> Maybe we do write documents now with conformance requirements.
> Maybe this ship has sailed. Maybe the elephant is on board. I
> hope not.
<insert: loud elephant trumpeting noise>
> Clarifying "SHOULD" is a fine thing. Making it conformance
> language is not. I don't like the 2119bis document in its
> current form.
And, precisely because it muddles a distinction I consider to be
even more important because I find both interoperability and
conformance language in different IETF documents, I don't like
it either.
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf