The need for smaller protocol specifications
charliep at IPRG.nokia.com
Mon Jun 9 12:20:52 CEST 2003
I'm going to try to describe what I see as a major problem, but
the solution is not a black-and-white cure-all rule. It's more a
matter of perspective, balance, and judgement.
Put simply, protocol specifications are being required to
contain too many features. In my favorite example, a very
simple signaling protocol specification was eventually required
to also incorporate other related specifications:
- A discovery algorithm
- A key distribution algorithm
- Renumbering algorithms
- Compatibility recipes for an incompatible security protocol
- other stuff too.
The requirement for the key distribution algorithm delayed
the specification for almost three years.
In addition to the obvious problem, there is a more subtle effect
that causes more and more delay. That is, that as more stuff
gets into the specification, people become less confident about
what is there, and more likely to strip out actually useful features
in a misguided attempt to make the document smaller and more
timely. All along, the problem is that we are not being allowed to
make small specifications because we have to do all the stuff that
other protocol specifications had to do before the IESG would
approve them. Stuff, by the way, that is often undocumented, so
that we have to rely on word of mouth and anecdotal information.
Another way to say this, is that we are being required to specify
entire systems instead of protocol components. I think this is a
very bad idea. I think the IESG should sincerely reconsider this
policy, and let protocol specifications be published EVEN IF
they do not solve the entire problem domain, but just a part of it.
Typically, the part that the original protocol specification DOES
solve, will be implemented and tested for interoperability. The
other stuff that gets glued on will just sit there like a dark jungle.
Related to John's note below, it is interesting to observe that the
problem I have described causes _all three_ of the problems
that John described as "root problems".
john.loughney at nokia.com wrote:
>Cutting out the parts of the discussion not relevant to my view:
>>if we come to agreement that producing quality and scaling are two
>>core problems, then i think there is some organizational and
>>management experience from within the computer industry and outside
>>from which we can draw some ideas on quality management etc. but i
>>don't think we've reached consensus that these are the issues yet.
>If it matters, I believe two major core problems are
> 1) producing quality documents
> 2) solving current scaling problems
>and to add a third:
> 3) producing timely documents (this has relations to 1 & 2).
>Anyhow, perhaps a reasonable way forward would be to see if we
>can gain consensus on at least 2 or 3 (not limited to the one's
>I've listed) core problems & start to move forward on them;
>while still examining other problems.
More information about the Problem-statement