Subject: The need for smaller protocol specifications

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Fri, 4 Jul 2003 14:21:26 -0700

>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

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 05 Jul 2003 01:05:30 +0200

> draft standard status would immediately progress to Standard.

The part of the IESG workload caused by moving stuff to Draft is far less 
than one third. More like three percent - apart from the number of 
documents (low), most of the stuff going to Draft is "known quantity" - we 
know what it's supposed to do, and what it's being used for, so reading the 
doc is MUCH easier....

there are good reasons to remove Draft (I think), but load on the IESG by 
the current process is not one of them.

                     Harald