The need for smaller protocol specifications

[Hallam-Baker, Phillip]

>Back in the early 90s, there was a concern that some vendors would not
>implement Proposed Standards, but wait for Draft - that was when IETF
>meeting attedance was under 500. Today is different as there seem to be
>many RFCs remaining at Proposed (and everyone confuses product
>differentation with protocol specifications)

I don't think anyone outside the IETF understands the difference 
between proposed, draft and standard. For that matter I don't think
anyone cares about the difference between an informational, 
experimental or standards track RFC.

My experience on HTTP was that by the time the process got arround
to draft the products were long out the door.

DNSSEC has been in standards limbo for ten years, PKIX for the same
length of time. CAT took much more than a decade. I don't know of any
developer that is going to wait that length of time, whether commercial
or independent.

Most of the time in my experience code gets written to the internet 
drafts. It is not unusual for a major software vendor to effectively
close debate on an issue by simply deploying software and letting
it be known that they have no plans to change anything until the next
major upgrade - typically a 3 year cycle.

The 'Draft' stage in the standards process is unnecessary, confusing and
should be eliminated immediately. This would immediately reduce the IESG
work load by a third and have no detrimental effect. All RFCs currently at
draft standard status would immediately progress to Standard.


		Phill