Re: [saad] About saad
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [saad] About saad



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




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.