I am not going to comment on each point, but your general perspective
highlights the problem at hand. The discussions on the multi6 mail
list have basically been about how the routing community believes the
address is the topology locator, while your & Dave's comments show the
app community believes it is an identifier.
it's clear that it is both of these, and furthermore that this was a
deliberate design compromise for the sake of reduced complexity.
Where the two communities
agree is that the DNS as currently deployed and operated is not up to
the task of handling the identifier role. My point is that this is due
more to implementation & operation than architecture.
disagree. it's largely a consequence of the design decision to make the
DNS namespace federated and the lookup widely distributed across the
network. if DNS didn't work this way, it wouldn't be nearly as usable
for the things we use DNS for. the fact that DNS doesn't solve all
naming problems shouldn't bother us any more than the fact that IP
doesn't solve all naming problems.
Also I believe
the multi6 discussion about creating a new identifier, to get the app
community to stop camping on the topology locator, will end up
creating a distributed database infrastructure almost identical to
DNS.
if what you claim is true (I haven't followed multi6) it's clearly
unworkable.
to ease transition, any new identifier needs to use the same structure
as an IP address; and indirection is far better handled as a side-effect
of sending a packet than by requiring an explicit lookup. also,
proactive propagation of updates (replication) is far better at
producing reliable results than retroactive propagation (cacheing). IOW,
mobile IP is a lot closer to a reasonable solution to this problem than
DNS.
We don't need two of those, so we should fix DNS.
DNS could certainly be improved in various ways, but you can't fix DNS
to serve the purpose you want it to serve.
Keith