Re: The Great Naming Debate (was Re: The internet architecture)

This is a very anal retentive discussion your all having here.  I support
Ford here.  Applications should be able to use names and IP addresses.   We
don't need the IP or DNS gestapo taking over application programs.

regards
joe baptista

On Sun, Dec 14, 2008 at 2:51 PM, Bryan Ford <brynosaurus(_at_)gmail(_dot_)com> 
wrote:

So, after being distracted by OSDI last week, I'm now trying to catch up on
the raging debates on TAE that are already exceeding all the wildest dreams
I had before setting up the list... :)

On the issue of weaning applications (and potentially transports) away from
IP addresses in favor of names of some kind, I feel that a lot of the
disagreement results from a misunderstanding of exactly what I (and perhaps
others who have made similar proposals) was proposing...

On Dec 4, 2008, at 10:29 PM, Keith Moore wrote:

Hallam-Baker, Phillip wrote:

I am trying to parse this claim.

Are you saying that the DNS is fragile and raw IP relatively robust?


DNS is layered on top of IP.  So for a large class of IP failures, DNS
won't work either.  And if IP routing fails, DNS is likely to be
irrelevant because the application using DNS won't work anyway.

And in practice, DNS is quite likely to fail due to configuration
errors, inadequate provisioning, outdated cache entries due to
unanticipated changes, brain-damaged DNS caches built into NATs, failure
of registries to transfer a DNS name in a timely fashion, etc.

So it's not a question of whether DNS is less reliable than IP (it is),
or even whether the reliability of DNS + IP is less than that of IP
alone (it is).  It's a question of whether increasing reliance on DNS by
trying to get apps and other things to use DNS names exclusively, makes
those apps and other things less reliable.  And I'd argue that it does,
except perhaps in a world where renumbering happened frequently, at
irregular intervals, and without notice.  And I don't think that's a
realistic scenario.


I entirely agree in principle with your concerns about reliability: if
everything has to work correctly in two layers (DNS and IP), then that's
strictly less likely to happen than hoping everything will work correctly in
only one layer (just IP) - unless DNS can somehow make up for unreliability
in the IP layer, which it occasionally might be able to do with some effort
(e.g., via DNS-based load balancers that take end-to-end IP reachability
information as input), but it usually doesn't because that's not the purpose
of DNS.  And I agree that some applications (and some users) sometimes need
to deal with IP addresses directly, and probably still will need to for a
long time, maybe forever.  You seem to be assuming that my proposal was to
disallow such "visibility into the network" entirely, but that wasn't my
intent at all.  I just would like it to become no longer _mandatory_ for
every application to know about the structure IP addresses in order to
accomplish anything.

To be specific, there are (at least) three positions we might be in:

1. ALL applications MUST know about IP addresses, in each IP address format
that exists, in order to operate at all.  This is the current state of the
world for applications that use the sockets API, because apps have to call
gethostbyname etc. and copy the resulting IP address(es) into sockaddr_in or
sockaddr_in6 structs to pass to connect() et al.  Even though the sockets
API is "generic" in that it supports multiple address families, its design
forces the application to have code specific to each family in order to
support that family at all, which is the key problem.

2. ALL applications MUST use only DNS names for all operations, and never
provide or see IP addresses for any reason.  This seems to be what you're
assuming I'm suggesting (i.e., where you say "...by trying to get apps and
other things to use DNS names >>exclusively<<").  That's a world we might
hold up as an ideal to strive for eventually, but it's indeed not realistic
in the short term, and it's not what I'm pushing for.  Besides, there may be
many different naming or host identity schemes we might eventually want to
support besides DNS names - e.g., UIA personal names, HIP cryptographic host
identities, ...

3. Applications MAY be aware of IP addresses if they need to be for
whatever reason, but aren't ALWAYS forced to have hard-coded dependencies on
the existence and structure of IP addresses by the API's design.
 Applications see IP addresses as variable-length string blobs of some kind
- e.g., along the lines Florian Weimer suggested in another message.
 Applications can parse/interpret or create these blobs if they want/need
to, but don't necessarily have to if they're just passing the blob through
from the GUI or URL parser to the OS's protocol stack.  This is the position
I think we need to be pushing for.

In short, I don't think either the current fascist extreme of an
"IP-address-only API" or the opposite fascist extreme of a "DNS-name-only
protocol stack" is very appealing; we need an environment in which different
kinds of names/addresses/identities can coexist.  You'll still be able to
enter an IPv4 or IPv6 address instead of a host name when you need to, and
applications will be able to tell when you do when they want to, but
hopefully not all applications will always need to care what the difference
is.

Cheers,
Bryan

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf




-- 
Joe Baptista
www.publicroot.org
PublicRoot Consortium
----------------------------------------------------------------
The future of the Internet is Open, Transparent, Inclusive, Representative &
Accountable to the Internet community @large.
----------------------------------------------------------------
 Office: +1 (360) 526-6077 (extension 052)
    Fax: +1 (509) 479-0084

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf