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 <brynosau...@gmail.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@ietf.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@ietf.org https://www.ietf.org/mailman/listinfo/ietf