Re: [saad] About saad

Brian E Carpenter <brc@zurich.ibm.com> Tue, 21 October 2003 17:35 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27428 for <saad-archive@odin.ietf.org>; Tue, 21 Oct 2003 13:35:24 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PS-000354-Jq for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 13:35:06 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9LHZ6Af011838 for saad-archive@odin.ietf.org; Tue, 21 Oct 2003 13:35:06 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PS-00034n-8f for saad-web-archive@optimus.ietf.org; Tue, 21 Oct 2003 13:35:06 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27398 for <saad-web-archive@ietf.org>; Tue, 21 Oct 2003 13:34:53 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0PQ-0006Q2-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 13:35:04 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AC0PP-0006Pz-00 for saad-web-archive@ietf.org; Tue, 21 Oct 2003 13:35:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0PN-000311-Jz; Tue, 21 Oct 2003 13:35:01 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AC0Og-0002nZ-Et for saad@optimus.ietf.org; Tue, 21 Oct 2003 13:34:18 -0400
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27360 for <saad@ietf.org>; Tue, 21 Oct 2003 13:34:05 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AC0Oe-0006Ot-00 for saad@ietf.org; Tue, 21 Oct 2003 13:34:16 -0400
Received: from d12lmsgate-5.de.ibm.com ([194.196.100.238] helo=d12lmsgate.de.ibm.com) by ietf-mx with esmtp (Exim 4.12) id 1AC0Od-0006OE-00 for saad@ietf.org; Tue, 21 Oct 2003 13:34:15 -0400
Received: from d12relay02.megacenter.de.ibm.com (d12relay02.megacenter.de.ibm.com [9.149.165.196]) by d12lmsgate.de.ibm.com (8.12.10/8.12.8) with ESMTP id h9LHXhNb111110 for <saad@ietf.org>; Tue, 21 Oct 2003 19:33:43 +0200
Received: from ochsehorn.zurich.ibm.com (ochsehorn.zurich.ibm.com [9.4.16.140]) by d12relay02.megacenter.de.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9LHXhZu159582 for <saad@ietf.org>; Tue, 21 Oct 2003 19:33:43 +0200
Received: from zurich.ibm.com (sig-9-145-224-49.de.ibm.com [9.145.224.49]) by ochsehorn.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id TAA61282 for <saad@ietf.org>; Tue, 21 Oct 2003 19:33:42 +0200
Message-ID: <3F956DD8.89B5E845@zurich.ibm.com>
Date: Tue, 21 Oct 2003 19:33:12 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,fr,de
MIME-Version: 1.0
To: saad@ietf.org
Subject: Re: [saad] About saad
References: <Roam.SIMC.2.0.6.1066744210.10742.nordmark@bebop.france>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: saad-admin@ietf.org
Errors-To: saad-admin@ietf.org
X-BeenThere: saad@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=unsubscribe>
List-Id: Scope Addressing Architecture Discussion <saad.ietf.org>
List-Post: <mailto:saad@ietf.org>
List-Help: <mailto:saad-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/saad>, <mailto:saad-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


Erik Nordmark wrote:
> 
> > 1. Concern: Domain names are overloaded; they get used for too many things
> > already.
> >
> > Response:  So?  What problems are caused by this and how does it prevent
> > them from being used as EIDs? How will using them as EIDs -- and we can
> > skip over the argument that they already _are_ EIDs, for the moment --
> > break any of the other uses for domain names?
> 
> It isn't the domain names per-see that are the issues but any implied
> semantics of having multiple AAAA records for the same RRset.
> 
> For instance, the AAAA RRset for www.example.com might return 5 addresses.

And might return different addresses on consecutive calls, if round robin
load sharing is in use. And the addresses returned might well be virtual,
i.e. dynamically assigned to a particular server at packet-delivery time.

So what such an FQDN actually refers to (except itself) is fuzzy indeed.

   Brian

> Does that mean that that those are different locators for the same
> stack/entity, 5 separate stacks, or some combination?
> Additional information in the DNS, or some negotation protocol between the
> endpoints can presumably be used to resolve this question.
> 
> > 2. Concern: DNS administration is difficult
> >
> > Response: But it exists and it works. Persistent names need
> > administration.
> 
> Depending on your definition of "administration" this might not be the
> case for statistically unique and cryptographically verifiable identifiers
> (also known as CBIDs or hashes of public keys).
> Any node could generate a 128 bit ID by generating a public/private key
> pair and doing the SHA1 hash of the public key; doesn't require any
> name space administration.
> 
> > Why is something new going to be easier? What can't the
> > mechanisms that make it easier be applied to the DNS? Why won't adding
> > them to DNS be substantially easier than creating a new, global
> > administrative mechanism?
> >
> >
> > 3. Concern: Domain names are inefficient to use
> >
> > Response: If they must be used in every packet, that is true.  If they
> > must be used only occasionally, such as at the start of an association
> > or at major state change events, then the bit-inefficiency of domain
> > names is irrelevant to the overall efficiency of the service that is
> > using it.
> 
> There is an aspect called "the DNS is inefficient to use" which
> doesn't seem to be part of your #3.
> Using domain names while preventing the redirection attacks that are
> implicit in any attempt to make ULP communication survive locator changes
> implies that some more DNS lookups will be performed.
> Understanding the performance of using the DNS for such
> a lookup (with and without DNSsec) with schemes based on CBIDs is
> definitely a worth-while effort.
> 
> > 4. Concern: Domain names are administered by a different entity than the
> > folks who administer IP operations
> >
> > Response: Is this a turf war?  Is there some reason to believe that
> > having the new namespace administered by another group is somehow going
> > to make the new names trivial to administer, compared with domain names?
> > The mere fact that the new namespace _might_ be administered by a
> > different group does not guarantee that the reality of administering it
> > is any better than the reality of administering domain names.
> 
> There is a level 9 meta-issue related to this.
> If a new rooted, hierarchical name space is needed somebody needs
> to be appointed to control and operate the root of that namespace.
> Resolving the food fight of who should be in control might take some
> time.
> 
> FWIW neither using the DNS as in MAST or using flat CBIDs have this
> problem.
> 
> > 5. Concern: Not all machines have domain names.
> >
> > Response:  _No_ machines have whatever the alternative might be.
> 
> Question is how hard it would be to add them.
> 
> I could get a CBID for my machines at home in a few seconds (the time
> it takes to generate the key pair). Convincing the ISP to assign me a domain
> name would take a lot longer.
> 
> Thus if both ends of the communication need a domain name this might be an
> impediment for deployment.
> 
>   Erik

_______________________________________________
Saad mailing list
Saad@ietf.org
https://www1.ietf.org/mailman/listinfo/saad