Re: Two modest proposals

[Harald Tveit Alvestrand <[e-mail]>]

At 00:35 25.11.98 -0700, Vernon Schryver wrote:
>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.

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
[e-mail]