RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)

"Michel Py" <michel@arneill-py.sacramento.ca.us> Fri, 28 March 2003 08:15 UTC

Received: from ran.ietf.org (ran.ietf.org [10.27.6.60]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20362; Fri, 28 Mar 2003 03:15:25 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 18ypAC-0006MI-00 for ietf-list@ran.ietf.org; Fri, 28 Mar 2003 03:24:36 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 18yp9g-0006KK-00 for ietf@ran.ietf.org; Fri, 28 Mar 2003 03:24:04 -0500
Received: from SERVER2000.arneill-py.sacramento.ca.us (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20292 for <ietf@ietf.org>; Fri, 28 Mar 2003 03:08:31 -0500 (EST)
Content-class: urn:content-classes:message
Subject: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Fri, 28 Mar 2003 00:10:53 -0800
Message-ID: <963621801C6D3E4A9CF454A1972AE8F54D35@server2000.arneill-py.sacramento.ca.us>
X-MimeOLE: Produced By Microsoft Exchange V6.5.6803.0
Thread-Topic: site local addresses (was Re: Fw: Welcome to the InterNAT...)
Thread-Index: AcL07UYkHhUcU0j1S5GJSTQZcjAEpgAD5NYw
From: Michel Py <michel@arneill-py.sacramento.ca.us>
To: Eliot Lear <lear@cisco.com>
Cc: Ted Hardie <hardie@qualcomm.com>, The IETF <ietf@ietf.org>
Sender: owner-ietf@ietf.org
Precedence: bulk
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA20362

Eliot,

> Eliot Lear wrote:
> What you say is possible, and has happened. But dumb
> things happen. Those dumb things could happen with non
> site-local addresses as well.

More limited, that's the point. Not perfect, but better than unregulated
anarchy. However, between a network design that does not meet RFPs (and
therefore does not get implemented) and anarchy, I pick anarchy,
especially when I'm not the one dealing with it later.

This community designs protocols to please code developers and protocol
designers. If it designed protocols with users in mind maybe less dumb
things would happen because dumb users would not have to do dumb hacks
to make things work.


> But look.  Ultimately I think we as a community do
> need to own up to better tooling, which can lead to
> better expectations.

This requires teamwork and what we have today is a bunch of people
entrenched in their positions and unwilling to compromise. If you want
better tooling, why don't you talk to the whiners that want to have the
cake and eat the cake? You know, the same kind of people that wrote a
"real" operating system or designed a "real" router that managed to
capture 0.5% of the market but of course is better than the
implementation that captured 75% of the market.

Maybe if these people had compromised instead of digging their heels
they would not be whining about proprietary implementations.


> The tools need to set expectations, and perhaps some
> of the DHCP prefix delegation code can help here.

Care to explain?

Michel.