Subject: Re: Two modest proposals

From: Vernon Schryver <[email-masked]>
Date: Tue, 24 Nov 1998 21:25:33 -0700 (MST)

As long as we're talking about "Modest Proposals," it seems appropriate
to remember the origin and connotations of that phrase.  

The flood of draft announcements is not a serious a problem compared to
the deluge of drafts itself.  My modest proposal is that no draft be
published without the affirmation of at least two technically competant
people other than the author and the colleagues of the author that draft
appears technically sound and plausible.  Define 'technically competent'
as people who could design and write the code necessary to implement the
draft, as demonstrated by other substantial code that they are publically
known to have written within the last 10 years.  (The other code would
not need to be freely available--just some way to separate those who talk
about implementing and those who actually implement at least once or twice
a decade.)

For how many of the current drafts could you find support from two such
independent, technically competent people?  My guess is that fewer than
10% of the drafts would meet this test.

How many of the drafts will ever have two or more independent
implementations?  My guess is that the notion of writing code makes
sense for fewer than 30% of the drafts, and of those, fewer than
10% will ever be implemented by anyone, including their authors.

I'd be glad to hear that I'm wrong in those estimates, so please prove me
wrong.  It should be easy to point to several dozen drafts of the many
hundreds in the last 24 months that have a couple of implementations.

Assume that I am wrong.  How many drafts can the IETF handle per year?
Never mind the machinery of putting them in reposititories, but consider
the approvals by the IAB, allocating numbers by the IANA, last calls, and
so forth.

Compare the sizes of the memberships of the IETF, ANSI, ITU, and IEEE.
Then compare the number of documents produced annually by the other
outfits with the number of IETF drafts.

Now consider the effects of the noise drafts on the future standards drafts
within the working groups.  At some point, the signal/noise ratio must be
so high that the noise drafts saturate the system, and important drafts
do not get considered.  0.1 is not so high a s/n ratio to paralyze the
IETF processes, but 0.000001 certainly is.  My guess is that current noise
level is at the critical threshold.

The IETF is in serious danger of failing through its success.  It might
already be too late.

Vernon Schryver    [email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 1998 01:09:15 -0500

> 10% of the drafts would meet this test.

My guess is that greater than 85% would meet the test.

Most of the drafts I see appear to be written by "technically
competent" people, even by your definition of "technically competent."
(i.e. even if the authors don't fit your definition of "technically
competent", the drafts are indistinguishable from drafts written
by people who do fit that definition.)

IMHO, ability to write code, while a useful skill, isn't nearly 
so important as having experience to draw on, to inform the 
design of the protocol.  Being able to write code makes for a 
clearer specification; having appropriate experience makes it 
more likely that the protocol will actually work well.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 1998 01:09:15 -0500

Keith

---

From: Michael Ridley <[email-masked]>
Date: Tue, 24 Nov 1998 22:50:45 -0800

> more likely that the protocol will actually work well.

What would you define as "appropriate experience"?  I think the
point Mr. Schryver is trying to make is that if the author (or
technical reviewers) are in touch with the actual steps required
to implement a protocol/protocol extension/whatever and how it would
fit into the overall scheme of protocols and related OS and application
code, then they'll have a much better time coming up with really
useful and needed protocols.

Certainly knowing how to actually implement a protocol isn't the
only way to be in touch with this, but what better way?  Also,
even if you have all the protocol experience in the world, if you
aren't working with your finger on the pulse of the implementation
then do you really know what is needed/desired?  Maybe, maybe not, but
if you are actively developing the end implementation you're one step
closer to knowing.

Anyway, I don't want to speak for Mr. Schryver since I don't really know
if that's his point or not, but it is my point so I'll speak for
myself. :-)

-- 
Michael Ridley
[email-masked]

---

From: Michael Ridley <[email-masked]>
Date: Tue, 24 Nov 1998 22:50:45 -0800

-- 
Michael Ridley
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 1998 02:24:39 -0500

[ I sent my last reply prematurely... there was more of Vernon's mesage
  left to comment on.]

> 10% will ever be implemented by anyone, including their authors.

This doesn't sound so bad.  In most cases people should get
their propoals reviewed before they actually start to implement
them, because any proposal is likely to change a fair amount
before it gains consensus.

I'd far rather we implement only the best 1/3 (if even that many) of
our proposals, than to prematurely implement all of them.

> the approvals by the IAB, allocating numbers by the IANA, last calls, and

There is indeed a problem here, but it's usually not the working group 
documents that are causing the problem.  The IESG spends a lot of time 
reviewing submissions from individuals or vendors who don't have any 
obvious community support for their proposals, but who want to publish RFCs.
This takes up individual IESG members' time to do the actual reviews; 
it also takes a lot of time during IESG's bi-weekly conference calls,
and there's also the time required to keep track of the additional 
documents - which ones have been reviewed, which ones sent back to
the author requesting changes, etc.  Often it appears that the 
individuals or vendors in question aren't interested in submitting
their work to the standards process, or indeed to any kind of review,
but they simply want to benefit from being able to quote an RFC number 
for their private specification.  (Some vendors go so far to refer to 
such works as standards even though they're published as Informational.)

Some individual submissions are worth publishing; many are not.  But if 
IESG recommends against publication, then IESG is expected to explain 
why - and sometimes even doing this takes too much time.

So to use your analogy, I'd agree that the s/n ratio of IDs that
IESG has to review is dangerously high, and most of the "n" is
due to individual submissions.

Part of the answer might be to establish more formal criteria for
deciding whether to publish an individual (non-working-group) RFC.
Another part of the answer might be to very firmly declare that
the RFC Editor is not required to publish any contribution submitted
to it.  (some people seem to be under the illusion that it does) 

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 1998 02:24:39 -0500

Keith

---

From: Antony Bowesman <[email-masked]>
Date: Wed, 25 Nov 1998 17:03:56 +0900

> known to have written within the last 10 years.  (The other code would

That's an interesting definition.  How would you quantify publicly
known?  Technical competence is not defined by quantity of code
written.  As Keith Moore said, code writing is useful, however the
design expertise is more important and along with that a broad overview
of the overall framework within which the protocol fits.  Being a
technically competent programmer does not necessarily make you a good
designer.  I am sure there are draft writers who have written code in
the past who cringe when presented with some of their old code :)
 
Rgds
-- 
Antony Bowesman
[email-masked]

---

From: Antony Bowesman <[email-masked]>
Date: Wed, 25 Nov 1998 17:03:56 +0900

Rgds
-- 
Antony Bowesman
[email-masked]

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 1998 04:05:15 -0500

> What would you define as "appropriate experience"?  

"appropriate" is a poor choice of words.
"relevant" would be a better word.

> I think the

there's no argument that implementation experience is useful;
I was just objecting to that as a sole criterion.

Keith

---

From: Keith Moore <[email-masked]>
Date: Wed, 25 Nov 1998 04:05:15 -0500

Keith