--On Saturday, January 05, 2013 10:13 +0100 Mikael Abrahamsson
<swmike@xxxxxxxxx> wrote:
> The problem here is that I want them to pay back some of the
> money (or take back the equipment totally and give back all
> money) for breach of contract, when I discover that they
> haven't correctly (as in intention and interop) implemented
> the RFC they said they said they were compliant in supporting.
>
> Ianal, but it feels that it should easier to do this if there
> are MUST and SHOULD in there and I asked them to document all
> deviations from these.
Folks, there is a long-term tension in almost every standards
body (at least those who notice) between
-- a specification whose primary purpose is guidance for
implementers and, in particular, implementers who intend
to do the best job possible to make things work together.
-- a specification whose primary purpose is to set
boundaries for what constitutes a conforming
implementation so that, as Mikael suggests, one can hold
those whose implementations do not fall within those
boundaries can be help accountable legally and/or
financially.
The traditional position of the IETF is not only that the first
is much more important than the second, but that the test of a
successful specification is interoperable implementations. If
a pair of implementations do not interoperate, our assumption is
that something is broken, be it implementation 1, implementation
2, or the spec. Indeed, our old "Draft Standard" requirements
took it as at least a default that the problem lay in the spec,
in part because we weren't very worried about bad-faith
implementations.
Similarly, if there are a half-dozen implementations, all of
which are widely deployed and interoperate smoothly but disagree
with the spec, we usually look on the spec with suspicion and
fix it to conform to those implementations. In an organization
following the second model, the spec is paramount and all six of
those implementations are wrong (and can be held accountable by
third parties for being wrong).
In the IETF, that tension shows up in many ways. There are not
just arguments about the use of 2119 terms, but statements like
"the audience for IETF Standards and the RFC Series is
implementers". Those statements are hotly debated because,
among other things, our documents -- like it or not-- are used
in procurements and, if there are problems, in precisely the way
Mikael describes. Some of them work better in those contexts
than others.
Another tension is that, while "interoperability" is a good
criterion for some specs, it is less so for others. "If you do
X, things won't interoperate" can be a valid and important
statement, but so can "If you do Y, things may interoperate
perfectly well in the 'they work together' sense, but there will
be one operational mess after another". A very narrow reading
of 2119 would permit a MUST NOT for the first case, but not even
a SHOULD NOT for the second because the problem has nothing to
do with a narrow reading of "interoperability". This is the
reason why some of us have never particularly liked the
interoperability-linked language of 2119. Its intent, I think,
is to shift the concern toward the first model above and away
from the second but the side-effect of the language chosen has
been to create arguments against strong requirements for
operational quality and minimum implementation quality --
requirements that are perfectly consistent with the first model
above (and possibly even helpful for the second).
It is also why some of us have argued for years that invocation
of 2119 and its definitions should be optional. But "optional"
has often morphed in practice -- and with IESGs were were, IMO,
more interested in rules and their rigid interpretation than in
sensible and flexible understanding of particular situations and
needs -- into "optional only in theory" or "optional only if one
can prove to the satisfaction of the most rigid AD that it is
absolutely necessary".
And, again, that is further complicated by the observation that
IETF Standards are used for procurement and even for litigation
about product quality. We either need to accept that fact and,
where necessary, adjust our specification style to match or we
run the risk of bodies springing up who will profile our
Standards, write procurement-quality conformance statements for
their profiles, and become, de facto, the real standards-setter
for the marketplace (and obviously do so without any element of
IETF consensus).
Aside but really, IMO, at the core of these sorts of
discussions: Telling people what the IETF says they can't do is
pretty useless, at least until we organize the Protocol Police
to enforce our positions and, ideally, the Protocol Army and
Gallows to make the Protocol Police credible. If people think
they need to do something, they will do it without allowing us
to comment. And, if they think they need to standardize
whatever they are doing that we've told them they can't, they
will just find another forum. We then end up complaining about
how all those nasty people are modifying or extending our
standards without our permission and that is another activity
that may be satisfying but is rarely productive.
best.
john