IETF mission (RE: pausable explanation for the Document Series)

C. M. Heard heard at pobox.com
Thu Jun 12 16:26:56 CEST 2003


On Tue, 10 Jun 2003, John C Klensin wrote:
> [ ... ] what were groups like the IETF doing that they needed 
> to imitate, co-opt, or defeat?
> 
> There were several answers:
> 
> (1) We didn't standardize fantasies about where the industry was 
> likely to go, or where we wanted it to go.  No "anticipatory 
> standards" here.  Documents didn't advance to full standard, or 
> even draft standard, unless there was solid implementation 
> experience.

This is (or was) a good thing about the IETF, and we should try
to keep it (or reinstate it).  A two-grade process (Experimental
and Standard) along the lines I proposed a few days ago, viz:

% - specs start out in life as Experimental, recycling there
% [as] necessary until
%
% - there are no known problems and at least two interoperable
% implementations, at which point they would be eligible for
% elevation to Standard (and could stay there on subsequent
% revisions, if the changes were not "too drastic")

would allow us to do that, and at least has the possibility of
being better geared to reality than our current three-grade
system.

> (2) We didn't have a mandatory five-year (or other) review cycle 
> that led to permanent WGs dedicated to each [group of] 
> standards, provided a full-employment situation for WG chairs, 
> and virtually guaranteed second-system effects (while the 
> initial development WG often contained solid engineering 
> expertise and was usually in touch with real customer and 
> product requirements, and the first review cycle might contain 
> some of those people in order to fix bugs that had been 
> discovered, by the time of the second review (third time around) 
> sponsoring companies had almost always pulled out the useful 
> designers, replacing them with people whose fantasies about 
> improvements usually exceeded their experience and knowledge).

Hmm.  I've often thought that the lack of mandatory review for
standards (especially full standards) is a big PROBLEM in the
way the IETF works.  It hurts in several ways:

- we don't update specs to remove things that are clearly
obsolete.  An excellent example is the TOS stuff that peppers
RFC 791, RFC 1112, and RFC 1812 ... all this was officially
retired when the DiffServ stuff was launched.  The specs
should be brought up-to-date to match the reality.

- we don't do maintenance revisions that are probably
necessary.  An example of this is the SMIv2 specs.  We
found some ambiguities and errata in the SMIv2 RFCs in
the course of developing "Guidelines for MIB Authors and
Reviewers."  In addition, there are some known omissions
(i.e., lack of 64-bit data types) that we are using
kludges to work around.  If we want this stuff to last
for a while, a maintenance revision to fix the bugs and
small omissions would, I think, be in order.

- we don't retire obsolete stuff as soon as we should.
RFC 1643 is an example of this.

In fairness, these problems are not entirely due to the
lack of mandatory periodic review;  I think they are also
attributable in part to a reluctance to make small changes
to an Internet Standard, since it forces a recycling back
to Proposed Standard.  This can hit at any stage of the
process ... if I remember correctly, that was one reason
why adding 64-bit data types to SMIv2 was ruled out-of-scope
in the 1998-1999 time frame when the specs were being updated
for advancement from Draft Standard to (full) Standard.

> (3) We were reluctant to simply declare an old standard obsolete 
> and replace it.   Instead, we worried a great deal about 
> compatibility and interoperability between old versions and new 
> ones.   And we didn't "withdraw" the old documents from the 
> marketplace, making copies of it essentially unavailable.

Good point ... in adopting a proposal such as the two-grade
proposal above, changes that break backward compatibility
in a significant way should be deemed "too drastic" to permit
recycling in grade.  But the current doctrine of permitting
nothing new at all is counterproductive, IMHO.

//cmh



More information about the Problem-statement mailing list