OPEN ISSUE: Standards Track

[Charles E. Perkins]

Hello Randy,

I think it is a serious problem.  Lengthy gestation periods
for Proposed Standards means that we don't get experience with
using the technology except in limited deployments and labs.
With faster publication of a Proposed Standard that would
be subject to further refinement, we would get better
operational experience sooner, and overall faster progress.

As it is, even with the too-long process, we see that hasty
decisions are taken at the end to satisfy all possible
stakeholders, even those who have not done any work on the
protocol.  Since it takes so long to do the process, at the
end the hardest working people are burned out and just want
to get it over with, so compromise is shunned because that
takes too much discussion, so the specification just gets
axed in order to avoid debate.  This leads to some unwise
elimination of tested, interoperable, known-good features
only in the name of getting the damned process finished.

I'd prefer more interoperability assurance than longer
processing time.  If dozens of teams can build it and get
good results, I think that says something more relevant
about the readiness of the specification, than whether anyone
in any corner of the IESG can think of something that might
possibly go wrong under some hypothetical set of circumstances.

Of course I do not mean that this is all black and white,
and that interoperability trumps all architectural
considerations.

I just think it's tilted much too far in the "what if"
direction than the "what is" direction.

As an example, I think it was a terrible mistake to delay
Mobile IPv6 for so long pending the completion of the world's
most sophisticated and super robost security solution (slight
exaggeration, but ...).  I guess I don't have to describe the
effect this can have in a world moving at what used to be
called "Internet speed".

Regards,
Charlie P.



Randy Bush wrote:
> 
> > The process document current says:
> >
> >> There is also a more fundamental issue with the IETF's engineering
> >> practices.  Although our current standards track contains three
> >> levels of maturity (Proposed Standard, Draft Standard and Full
> >> Standard), we do not have sufficient differentiation regarding the
> >> quality and completeness of documents required at each stage.  The
> >> bar is set very high for publication at Proposed Standard, and very
> >> few documents advance beyond this stage. [OPEN ISSUE: Do we have
> >> IETF consensus that this is a problem?]
> >
> > We're hearing proposed solutions to this problem, so it looks like there
> > are folks who agree that it's a problem.
> >
> > Are there folks who DON'T agree that this is a problem?
> 
> how does this 'problem' do damage to
> 
>    the ietf's goal is to produce high quality, relevant, and timely
>    standards for internet technology.
> 
> randy