> 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.
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
