OPEN ISSUE: Standards Track

Brian E Carpenter brian at hursley.ibm.com
Thu May 22 12:07:26 CEST 2003


Jonne.Soininen at nokia.com wrote:
> 
> Hi everybody,
> 
> > -----Original Message-----
> > From: ext Keith Moore [mailto:moore at cs.utk.edu]
> > Sent: Friday, May 16, 2003 9:02 AM
> > > *what sort of bugs, if detected, would make a protocol
> > unsuitable for
> > > Proposed Standard?*
> >
> > the way Proposed is treated by industry now, anything that would cause
> > problems in wide deployment should make a protocol unsuitable for
> > Proposed.
> >
> > certainly failure to interoperate would be in this list,
> > but so would failure to scale, lack of robustness, failure to provide
> > adequate security, and a lot of other problems.
> 
> I do not really think it is just the industry that is considering Proposed ready for wide development, but how we are going around in the IETF about the proposed standard actually makes it feel like it should be ready for wide scale implementation. When I first started coming to the IETF back in '99, I first read all the training material on the IETF web page. To my it was quite clear that proposed standard is no way stable, but either draft or full standard would be then really stable. Sadly, I had to be rehabilitated in the IETF to understand that proposed standard is mostly the last stage a protocol ever takes.
> 
> And now for something a bit different: I think we should have a new stability stage (proposed standard?) to the documentation process, where the specification is relatively stable. That would mean that the bugs can be fixed, and the the work has by no means stopped. However, the technical concept would already be quite stable. At the moment, the specifications can change quite a bit in the last stages before going to proposed. The relatively-stable-stage could help the vendors to standart to implement the protocol and find out the bugs, and not to have to change the implementation completely when the next version of the protocol is out. For instance, it could be considered that the specs are "functionally frozen", but the last bugs are to be taken out.
> 
> BTW, yes, I think too this is a real issue.

The answer to this is to recycle at Proposed. The last thing we need to do 
is to add a step to the process. It would be entirely recursive in effect -
after a few years, someone would be be asking "shall I implement
draft-jonnes-protocol-17.txt, or should I wait for the relatively-stable 
draft?"

We need to remove steps, not add them.

   Brian


More information about the Problem-statement mailing list