Re: What do we mean when we standardize something?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]