Hi John,
At 10:23 29-05-2013, John C Klensin wrote:
The IETF has traditionally chosen the first model and a great
deal of our thinking and public rhetoric are based on it. Even
when we have adopted proposals, sometimes implemented ones,
from elsewhere, we have insisted on change control and usually
taken that seriously. One could claim that an adaptation of
the second model would make the Internet more uniform, but a
consensus of existing practice cannot aspire to "working
better" except in the narrow sense of substitutability of
conforming products.
The note is thoughtful. It's the first time I see a message where
the "working better" angle is discussed.
If we are not going to move significantly in the direction of
"consensus of industry practice", then it seems to me that we
need to be careful about the arguments that are made (or at
least those that are considered legitimate) in support of
advancement into or on the standards track.
If the IETF were to move in the direction of "consensus of industry
practice" it would be moving towards consensus of industry practice
based on the opinions of people in the industry who are active in the
IETF. Michael Richardson asked the following question:
"Given that the [Country X] mandated them, why wasn't the IETF involved
earlier? The regulator really should have reached out to the IETF here.
If people from Country X do not come to the IETF with the problem the
IETF won't know about the problem. If people from Country X do not
provide input about their industry practice the IETF will know about it.
For example, if we agree on a relaxed registration procedure
for some protocol parameters, it is not reasonable to later
turn around and ask that that those parameters be standardized,
unchanged, because they are already registered (and maybe
deployed). For standardization, the IETF generally needs not
only change control but an opportunity to comment on and affect
the actual design and specification of whatever is being
standardized.
Country X would also have to allow the IETF to have change control on
the specification or else it is like asking the IETF to rubber-stamp
the specification.
If I am not mistaken the relaxed registration procedure is so that
there can be a registry of what is being used on the Internet. The
difference here is that the IETF does not review the design, or it
may set some minimal criteria for the review before allocating the code point.
Similarly, we sometimes hear it argued that we should accept a
specification for Proposed Standard unchanged because it has
been extensively developed and reviewed elsewhere. That may be
reasonable in some cases although I'd hope we wouldn't make it
a common practice. But, if a specification adopted for
Proposed Standard on that basis is then proposed for
advancement to Internet Standard, I think the review should be
comprehensive --perhaps even more comprehensive than the usual
such review-- because the Internet Standard is unambiguously an
IETF product and recommendation not that of the other body. If
we allow a specification to advance to Proposed Standard
without an open and critical review because it was developed
and reviewed comprehensively by outside expert organizations
and then allow the Last Call review for Internet Standard to be
constrained by existing deployment, we would have gone into the
rubber stamping business that we regularly say is incompatible
with our standardization model. That doesn't mean, of course,
that changes during review for Internet Standard are likely to
be a good idea. Those who propose changes to the spec, and
especially to the protocol, should have to convince the
community that those changes are important enough to overcome
the costs, including those of incompatibility with deployed
versions. But I don't think we can reasonably exclude them
from raising the issues and making those arguments.
If an intended Proposed Standard has actually been developed and
reviewed elsewhere the Last Call and IESG Evaluation is not a
problem, i.e. any problem in the specification has already been
identified and addressed. One of the issues here is the rhetoric
(the undue use of exaggeration, or from an IETF perspective, making
unpleasant comments to discourage people from identifying problems).
It is difficult to have an open and critical review of an Internet
Standard. There is a significant cost for any change made at that
level as it may cause interoperability issues. What "we" mean when
we standardize something is that "we" will think carefully before
making a change as "we" would like the specification to be stable
even if that means not fixing some minor errors. Internet Standard
could have been used to say "we" are not going to tinker with this
specification and it is your best bet if you want to deploy the code
and forget about it for a few years.
As an unrelated comment, what could "we" mean? It could mean:
1. doing what is right to make you look good
2. doing what is right for your company
3. doing what is right for a country
4. doing what is right for the IETF
Regards,
-sm
