Re: Raising and lowering the roof of the DNS;-)... Wed, 07 August 2002 15:23 UTC

Received: from (loki []) by (8.9.1a/8.9.1a) with ESMTP id LAA23167 for <>; Wed, 7 Aug 2002 11:23:37 -0400 (EDT)
Received: (from adm@localhost) by (8.9.1b+Sun/8.9.1) id LAA00865 for; Wed, 7 Aug 2002 11:24:02 -0400 (EDT)
Received: from ( []) by (8.9.1b+Sun/8.9.1) with ESMTP id LAA00509 for <>; Wed, 7 Aug 2002 11:05:30 -0400 (EDT)
Received: by (8.9.1a/8.9.1a) id LAA22024 for; Wed, 7 Aug 2002 11:04:16 -0400 (EDT)
X-Authentication-Warning: majordom set sender to using -f
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id LAA22020 for <>; Wed, 7 Aug 2002 11:04:12 -0400 (EDT)
Received: from ([]) by (8.12.5/8.12.5) with ESMTP id g77F4FqH003182; Wed, 7 Aug 2002 11:04:48 -0400
Message-Id: <>
X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4+dev
To: Einar Stefferud <>
Cc: Internet Technical Community <>
Subject: Re: Raising and lowering the roof of the DNS;-)...
In-Reply-To: Your message of "Tue, 06 Aug 2002 16:55:59 PDT." <v0422080fb97606c6ace5@[]>
X-Face-Viewer: See to decode picture
X-Face: 34C9$Ewd2zeX+\!i1BA\j{ex+$/V'JBG#; 3_noWWYPa"|,I#`R"{n@w>#:{)FXyiAS7(8t( ^*w5O*!8O9YTe[r{e%7(yVRb|qxsRYw`7J!`AM}m_SHaj}f8eb@d^L>BrX7iO[<!v4-0bVIpaxF#-) %9#a9h6JXI|T|8o6t\V?kGl]Q!1V]GtNliUtz:3},0"hkPeBuu%E,j(:\iOX-P,t7lRR#
References: <20020806134223.1611.qmail@submit8.mail.intra> <> <v0422080fb97606c6ace5@[]>
Mime-Version: 1.0
Content-Type: multipart/signed; boundary="==_Exmh_-854721408P"; micalg="pgp-sha1"; protocol="application/pgp-signature"
Content-Transfer-Encoding: 7bit
Date: Wed, 07 Aug 2002 11:02:57 -0400
Precedence: bulk

On Tue, 06 Aug 2002 16:55:59 PDT, Einar Stefferud <>  said:

> My bottom line logic is that finding a way to resolve differences
> through constructive resolution processes is what we need, vice
> lobbing written grenades over walls, and building fortresses to close
> out communications.
> But, I fear this is off topic because it is not technical enough;-)...

No Stef, you're quite right here - we *do* need to remember the following:

1) Technical solutions for social problems almost never work.

2) We aren't designing technology for technology's sake, we are designing
technology to be deployed and used.  As such, we *will* end up with the
occasional design wart - we've had protocols done in weird ways because
some player had a patent on an algorithm.  I was going to add "and if
the US Govt said every third bit had to be painted green", and then I
remembered that we produced RFC1508 on GSSAPI - an interesting tap dance
around the "crypto in the hole" problem of the time.

There exist players big enough that they can mandate "there will exist
something like ICANN" and make it stick.  We're also stuck with the
technical considerations in RFC2826.  Any proposed solution will have
to deal with *both* those sets of issues.
				Valdis Kletnieks
				Computer Systems Senior Engineer
				Virginia Tech