Subject: Re: Two modest proposals

From: Vernon Schryver <[email-masked]>
Date: Wed, 25 Nov 1998 00:35:31 -0700 (MST)

> From: Keith Moore <[email-masked]>

> > 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.
>
> My guess is that greater than 85% would meet the test.

Are you also asserting that more than a tiny minority of the flood
of drafts are ever implemented?  You can't be saying that more than
a numerically insignificant minority every have independent
implementations, since that would clearly be false.

Why not take the first 10 drafts announced after noon Tuesday and
see if you can get two independent, 'technically competent' (in my
special, restricted meaning) supporters for more than 8?  Of course,
you'll be able to find many supporters who consider themselves
technically competent by some definition other than mine. 
If you wish, I'll use some other phrase to denote my meaning.

> 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.)

I beg to differ.  I've found the drafts written by implementors
are both rare and obvious, without looking at the names of authors,
even when I personally think the ideas in the drafts are bad.

> 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.

It's true that being able to design and build things requires more than
just the knowing how to use a text editor or a GUI SDK.  However, merely
using a protocol (or a computer) never provides enough of your "appropriate
experience" to design a useful protocol (or system).

What is the saying that goes something like "everyone thinks they can do
X, although they'd never dream of doing brain surgery"?  What was X?

The IETF is suffering a catastrophic collapse in quality.  The
number of "Informational" RFC's is an objective indicator that even
non-implementors should be able to understand.  The number of drafts
that expire without implementation is another.

Even if you think that 85% of all drafts are good, you must admit that
there too many drafts for the IETF to do them all justice.

Remember Sturgeon's Law.

Vernon Schryver    [email-masked]

---

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

> of drafts are ever implemented?  

no, I'm saying that 85% are as good as if they were written by
people who had implemented them - the major flaws are more likely 
to be in overall architecture and scope than in specification.
and imprecise specifications are generally easier to find and fix 
than architectural flaws.

but this is beside the point - basically I don't believe it's in IETF's 
best interest to significantly raise the bar on submitting internet-drafts;
rather we should raise the bar for submission of individual RFCs.

> that expire without implementation is another.

your conclusions do not follow from your premise.  

> there too many drafts for the IETF to do them all justice.

absolutely.  But to me this is as it should be - I don't expect that 
more than a small percentage of I-Ds published should ever become RFCs.
To me the I-D publication process is useful largely because it doesn't
require any review.

Let's continue to let anyone publish an I-D, but require him/her to
win significant support for the draft before they can submit a request 
to have it published as an RFC.  (criteria for "significant support" are TBD)

Keith

---

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

Keith

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 25 Nov 1998 10:58:10 +0100

>If you wish, I'll use some other phrase to denote my meaning.

Hmm.....pair of facts beats house of supposition.
Let's try the 5 drafts currently on the top of my screen of I-D
announcements, which is easier.

--------------------------------------------------------------
	Title		: Dynamic Hostname Exchange Mechanism for ISIS
	Author(s)	: N. Shen, H. Smit
	Filename	: draft-shen-dyname-isis-00.txt
	Pages		: 3
	Date		: 23-Nov-98
	
 Currently there does not exist a simple and dynamic mechanism for
 routers running IS-IS to learn about symbolic hostnames. This
 document defines a new TLV which allows the IS-IS routers to flood
 their name to system ID mapping information across the IS-IS network.
--------------------------------------------------------------
If you believe IS-IS, and believe names are easier than numbers,
this may be competent. > 2 implementors? Probably.
----------------------------------------------------------------
	Title		: A Round-trip Delay Metric for IPPM
	Author(s)	: G. Almes, S. Kalidindi, M. Zekauskas
	Filename	: draft-ietf-ippm-rt-delay-00.txt
	Pages		: 20
	Date		: 23-Nov-98
	
   This memo defines a metric for round-trip delay of packets across
   Internet paths.  It builds on notions introduced and discussed in the
   IPPM Framework document, RFC 2330 [1], and follows closely the
   corresponding metric for One-way Delay ('A One-way Delay Metric for
   IPPM' <draft-ietf-ippm-delay-05.txt>) [2]; the reader is assumed to
   be familiar with those documents.
---------------------------------------------------------
Sure, people are going to measure this. And definitions are good for you.
---------------------------------------------------------

	Title		: Definitions of Managed Objects for the Delegation 
                          of Management Scripts
	Author(s)	: D. Levi, J. Schoenwaelder
	Filename	: draft-ietf-disman-script-mib-06.txt
	Pages		: 58
	Date		: 23-Nov-98
	
   This memo defines a portion of the Management Information Base (MIB)
   for use with network management protocols in the Internet community.
   In particular, it describes a set of managed objects that allow the
   delegation of management scripts to distributed managers.
-----------------------------------------------
This is going to be implemented for sure.
Whether it's the Right Way is a hot issue, but it's definitely
got very technically savvy people in favour of it. Implementors, too.
-----------------------------------------------
	Title		: Applicability Statement for HTTP State Management
	Author(s)	: K. Moore
	Filename	: draft-iesg-http-cookies-00.txt
	Pages		: 8
	Date		: 23-Nov-98
	
The mechanisms described in 'HTTP State Management Mechanism' [RFC-
XXXX]  and  its  predecessor  [RFC-2109], can be used for many different
purposes.  Even though this protocol has been approved for the  Internet
standards track, some current and potential uses of the protocol are not
within the scope of the standard approved by IESG.  This memo identifies
specific  uses  of  HTTP  State Management protocol which are either (a)
nonstandard and thus  not  recommended  by  IETF,  or  (b)  nonstandard,
believed  to  be  harmful,  and  discouraged.   This  memo  also details
additional privacy considerations which are  not  covered  by  the  HTTP
State Management protocol specification.
------------------------------------------
You can't implement this.
It's documenting a political problem wrt cookies.
But the author is, IMNSHO, competent. And people able to implement
cookies listen.
---------------------------------------
	Title		: Identity Representation for RSVP
	Author(s)	: S. Yadav, R. Pabbati, T. Moore, S. Herzog
	Filename	: draft-ietf-rap-rsvp-identity-00.txt
	Pages		: 15
	Date		: 23-Nov-98
	
   This document describes the representation of identity information
   in POLICY_DATA object [POL-EXT] for supporting policy based
   admission control in RSVP. The goal of identity representation is to
   allow a process on a system to securely identify the owner of the
   communicating process (e.g. user id) and convey this information in
   RSVP messages (PATH or RESV) in a secure manner. We describe the
   encoding of  identities as RSVP policy element. We describe the
   processing rules to generate identity policy elements for multicast
   merged flows. Subsequently, we describe representations of user
   identities for Kerberos and Public Key based user authentication
   mechanisms. In summary we describe the use of this identity
   information in an operational setting.
-------------------------------------------------
You can argue that the lack of this in RSVP shows missing
competence. But you can't argue that nobody will implement it.
------------------------------------------------------
(at this point, my cut/paste patience ran out)

Summary: Out of 5 randomly selected recently announced drafts,
I think I can easily come up with two technically savvy (in the sense
of "able/willing to implement the relevant mechanism") supporters for
5 of them. Can't beat that score....

                          Harald A

-- 
Harald Tveit Alvestrand, Maxware, Norway
[email-masked]

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Wed, 25 Nov 1998 10:58:10 +0100

Harald A