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
