Re: [saad] About saad

"James Kempf" <kempf@docomolabs-usa.com> Fri, 17 October 2003 20:01 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 QAA20926 for <saad-archive@odin.ietf.org>; Fri, 17 Oct 2003 16:01:26 -0400 (EDT)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAamX-0007hT-8m for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:01:05 -0400
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id h9HK15Ip029598 for saad-archive@odin.ietf.org; Fri, 17 Oct 2003 16:01:05 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAamX-0007hJ-4H for saad-web-archive@optimus.ietf.org; Fri, 17 Oct 2003 16:01:05 -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 QAA20897 for <saad-web-archive@ietf.org>; Fri, 17 Oct 2003 16:00:55 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAamV-0000PU-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:01:03 -0400
Received: from ietf.org ([132.151.1.19] helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AAamV-0000PR-00 for saad-web-archive@ietf.org; Fri, 17 Oct 2003 16:01:03 -0400
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAamU-0007fv-5m; Fri, 17 Oct 2003 16:01:02 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AAala-0007d0-2W for saad@optimus.ietf.org; Fri, 17 Oct 2003 16:00: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 PAA20837 for <saad@ietf.org>; Fri, 17 Oct 2003 15:59:56 -0400 (EDT)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AAalY-0000OT-00 for saad@ietf.org; Fri, 17 Oct 2003 16:00:04 -0400
Received: from key1.docomolabs-usa.com ([216.98.102.225] helo=fridge.docomolabs-usa.com ident=fwuser) by ietf-mx with esmtp (Exim 4.12) id 1AAalX-0000OH-00 for saad@ietf.org; Fri, 17 Oct 2003 16:00:03 -0400
Message-ID: <034f01c394e9$49bb7a60$396015ac@dclkempt40>
From: James Kempf <kempf@docomolabs-usa.com>
To: Dave Crocker <dcrocker@brandenburg.com>, saad@ietf.org
References: <DD7FE473A8C3C245ADA2A2FE1709D90B06C658@server2003.arneill-py.sacramento.ca.us> <018201c393ff$a7431200$396015ac@dclkempt40> <6.0.0.22.2.20031016120745.04522090@mira-sjc5-b.cisco.com> <3F8FF09D.7A9B0787@zurich.ibm.com> <7325372774.20031017151023@brandenburg.com>
Subject: Re: [saad] About saad
Date: Fri, 17 Oct 2003 13:00:16 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
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

Dave,

So, as I understand it (and having read through the MAST paper), what you
are proposing is a Layer 3.5 or maybe Layer 4 Session-like Layer in which
the FQDNs are used for global node identification initially to set up a more
compact temporary node identifier.

Is that right?

            jak

----- Original Message ----- 
From: "Dave Crocker" <dhc@dcrocker.net>
To: <saad@ietf.org>
Sent: Friday, October 17, 2003 12:10 PM
Subject: Re: [saad] About saad


> Brian,
>
> BEC> The reasons why FQDNs are imperfect EIDs have been listed quite
recently
> BEC> (on one of the IPV6 lists I think).
>
> As a proponent of using domain names as endpoint identifiers -- for those
> situations requiring only occasional exchanges -- I have put some effort
> into looking for the discussions that argue against their use.
>
> My goal is, of course, to then try to refute the arguments.  If I can't
> find convincing counter-arguments, I'll change my advocacy.
>
> So far, I have not found arguments that are pragmatic and operational.
> The arguments against domain names have primarily been based on
> principles and aesthetics. These are important for guidance, but should
> not get in the way of pragmatics.  New namespaces are expensive,
> particularly when they need global administration.
>
> What I am looking for are arguments that explain how use of domain names
> as EIDs "will not work" or arguments that explain how use of them will
> break other things.
>
> I've even tried to ask such questions in a few venues. Sadly, responses
> that attend to pragmatics have not been forthcoming.
>
> So, if there is a discussion that really explains the pragmatic problems
> with using domain names, I would greatly appreciate being pointed at it.
>
> Failing that, I'm afraid that, yes, this list should discuss the
> question.
>
> Let me prime the pump:
>
>
> 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?
>
>
> 2. Concern: DNS administration is difficult
>
> Response: But it exists and it works. Persistent names need
> 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.
>
>
> 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.
>
>
> 5. Concern: Not all machines have domain names.
>
> Response:  _No_ machines have whatever the alternative might be.
>
> And so on.
>
> OK.  Consider the pump primed.
>
> d/
> --
>  Dave Crocker <dcrocker-at-brandenburg-dot-com>
>  Brandenburg InternetWorking <www.brandenburg.com>
>  Sunnyvale, CA  USA <tel:+1.408.246.8253>
>
>
> _______________________________________________
> Saad mailing list
> Saad@ietf.org
> https://www1.ietf.org/mailman/listinfo/saad
>


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