--On Sunday, October 29, 2017 23:02 -0400 Alia Atlas
<akatlas@xxxxxxxxx> wrote:
> After some discussion, my co-authors and I have written down a
> proposed policy that would clearly and specifically allow
> standards-track RFCs to have external non-SDO normative
> references. It's not disallowed now - but determining early
> when it is ok is unclear.
>
> My hope is that this will facilitate improved standard
> technology that can use "de-facto standards" that are suitably
> open and mature.
>
> Please take a read (between all the fun technical drafts) and
> let us know what you think.
Alia,
While others have said parts of this in different ways (I
believe and several of the comments since you posted your note
are really just about symptoms), I think it is important to come
back to the fundamental tension between at least one critical
objective for open source and the main objective of standards
and standardization.
In the former case, the hope is that open source (and general
permission to make adaptation and modification) will permit the
community to rapidly evolve and improve systems, or at least
adjust them to different preferences and requirements. By
contrast, standards are about interoperability (there should be
a high expectation that two conforming implementations will work
together) and interchangeability or substitutability (one should
be able to pull out one conforming implementation and replace it
with another with a minimum of fuss, disruption, and cost.
Those goals are often contradictory with local or frequent
changes, especially ones that are not very precisely documented.
IETF has traditionally put its primary focus on
interoperability. One could argue that is an historical
accident of how we got here of that it is a necessity in a
network environment in which the main purpose of protocols is to
allow communication and smooth interworking of implementations
by different groups and often on different platforms. Our
colleagues at ISO and ITU have tended to emphasize
substitutability. Again, that could be an accident relating to
their history (especially in ISO's case) with supporting
definitions and procurement of physical products. Their
interpretation of that principle for computer networking is
probably on the "why OSI failed" list somewhere.
But, ultimately, both are important. The stable normative
reference requirement in anything we claim to be a standard is
ultimately just a corollary: if there is something I need to
understand or depend on in order to implement a specification in
an interoperable and substitutable way, than whatever that is
can't change out from under that standard spec. At one point,
we wouldn't even allow a Full Standard to reference a Proposed
one. The relaxation to allow normative references to
Informational RFCs should be no threat because the IETF and the
RFC Editor control any changes and RFC numbers are absolutely
stable (we do have some issues about what happens when one
document references another that is replaced or becomes
obsolete, but that is mostly a separate topic). It does impose
a requirement, which I'm not sure we are taking seriously
enough, to verify that the Informational document does not
depend normatively on anything that is less stable than our
standards-track documents.
The rule about recognized SDOs isn't a significant relaxation
either, assuming the IESG is informed and responsible enough to
"recognize" only those SDOs who take the stability and, clarity,
and dependencies of standards at least as seriously as we do.
But referencing something that may be a less-than-complete or
less-than-precise spec, that may be out of synch with the
software it supposedly describes (in standards terms, where the
software may not conform to the spec), or that may represent the
opinion of some semi-random party about what the spec should
actually be without adequate review by others --and many of us
have seen all of those with open source software and systems--
threatens the integrity of the IETF standards themselves. Not
a good idea.
There is another issue about this that I don't think anyone has
mentioned. We went through some very painful discussions and
times to get various standards bodies, governments, and even a
few corporations, to agree that IETF standards could be
referenced in their specifications, regulations, and procurement
requirements. Some of that recognition was based on our
persuading them that our standards were stable,
carefully-considered, and hence actually meaningful. I would
assume that, if normative references to unstable material were
allowed, those recognition decisions and agreements might well
come unglued. I don't think we want to go there.
Just say "no".
john