Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

"J. Noel Chiappa" <jnc@ginger.lcs.mit.edu> Tue, 01 April 2003 15:44 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 KAA21544; Tue, 1 Apr 2003 10:44:08 -0500 (EST)
Received: from majordomo by ran.ietf.org with local (Exim 4.10) id 190O15-0001Xx-00 for ietf-list@ran.ietf.org; Tue, 01 Apr 2003 10:49:39 -0500
Received: from odin.ietf.org ([10.27.2.28] helo=ietf.org) by ran.ietf.org with esmtp (Exim 4.10) id 1907tu-00068V-00 for ietf@ran.ietf.org; Mon, 31 Mar 2003 17:37:10 -0500
Received: from ginger.lcs.mit.edu (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA28172 for <ietf@ietf.org>; Mon, 31 Mar 2003 17:20:44 -0500 (EST)
Received: from ginger.lcs.mit.edu (localhost [127.0.0.1]) by ginger.lcs.mit.edu (8.12.9/8.12.9) with ESMTP id h2VMN9tU029073; Mon, 31 Mar 2003 17:23:09 -0500
Received: (from jnc@localhost) by ginger.lcs.mit.edu (8.12.9/8.12.9/Submit) id h2VMN9GY029072; Mon, 31 Mar 2003 17:23:09 -0500
Date: Mon, 31 Mar 2003 17:23:09 -0500
From: "J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>
Message-Id: <200303312223.h2VMN9GY029072@ginger.lcs.mit.edu>
To: ietf@ietf.org
Subject: Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))
Cc: jnc@ginger.lcs.mit.edu
Sender: owner-ietf@ietf.org
Precedence: bulk

    > From: Keith Moore <moore@cs.utk.edu>

    > actually it's bad to force all apps to use DNS names - which are often
    > less reliable, slower, less correct, and more ambiguous than IP
    > addresses.

This is like saying it's bad to force people to use cars/busses/whatever
because they occasionally break, and everyone should walk everytime they need
to go anywhere, because that's more reliable. That works in an agrarian
society, but not an industrialized one.

We have multiple namespaces, each with different characteristics for the
names, for very good reasons. If we really need a name with characteristic A,
and we instead wind up using one with characteristic ~A "because it's more
reliable", then that's not good.

If we have a need for a name, and the optimal characteristics for that name
are those of an address (i.e. the topological location of an interface to the
network), then fine, use an address. If not, don't.

If the system for mapping from one namespace to another has problems, we
ought to fix it, not say "oh, we'll just stop using it".

Don't try and make everything into a nail because the hammer is the most
reliable tool you have.

	Noel