On Mon, Aug 6, 2012 at 8:18 AM, Ted Lemon <[email protected]> wrote: > On Aug 6, 2012, at 12:58 AM, Kerry Lynn wrote: >>> Domains like .local seem like a good idea to geeks like us, but how many >>> regular users ever use them? >> Every single user who has added a printer to OS X or Linux in the last >> several years. > > No. You think that because you're a geek like the rest of us.
I think there may be two kinds of geeks on this list, those who want to take corporate networks and scale them down for home users and those who want to extend existing home networks and make them more functional. These two points of view may lead to a common solution for any given problem, but that's not yet evident. > Every single user who has added a printer to OS X has done so from a UI that > presented a list of printers doing bonjour. This list named the printers by > brand. The user clicked on a printer from the list, and that was the end of > it. The user certainly never saw Canon_PIXMA_900.local in any UI. I'm > fairly sure this is true of Linux as well. > Sorry, not sure I'm getting your point. Yes, the user is using a UI to solve her problem. The UI in this case is using (multicast) DNS. DNS requires a zone to scope the query. That zone is ".local.". My car probably has 15 microcontrollers and I use them when I drive to the market whether I'm aware of it (which I don't want to be) or not. What appears in my list is a _default_ SRV record name consisting of the printer model plus "gibberish" (in my case "Office Jet Pro A909g [4C0EA4]"). The gibberish is the least significant 24-bits of the MAC address (printed on the box, on a sticker near the network port, on the test page that ejects from the printer, and from the setup menu on the printer's screen. The user is given the chance to change the name when the printer is added; thereafter it is only slightly more complicated to change it. Another advantage to adding gibberish to the SRV name (aside from those I listed earlier) is that it reduces the probability of name conflicts. There can be many sources for this gibberish, but it is relatively easy to use some intrinsic identifier. The "hack" above is slightly worse than a five-digit zip code, slightly better than a nine-digit zip code - the point being that users already deal with a certain amount of gibberish in their lives. >> Apparently multicast DNS works even in the absence of mental models. > > It works in the sense that if you know the name of the machine you are > trying, and tack ".local" on the end, there is a small chance that you will > get to that machine. But usually you won't, because various network > glitches will have caused the machine to rename itself to machine-04.local by > the time you try to address it, even though there were never any > machine.locals other than that one. Hard for me to buy this, unless the device is hearing from itself via tape delay. > mDNS is a nice hack, but fairly useless for the particular application we are > talking about. It's pretty good for service discovery (showing a list of > printers in a UI). > >>> IMHO, we shouldn't promote bad solutions, and .local is a bad solution. >> A bad solution to what problem? > > Well, indeed. We are clearly talking about different problems. > Yes, there are at least two problems: how to disambiguate name collisions in locally served zones and how to access remote resources. We agree that these problems collapse if you outlaw locally served zones. We disagree on the utility and/or reliability of locally served zones. This is why I'm pushing back and saying the problems you raise with mDNS are solvable. I think that in the short run it is easier to connect users to their existing networks (e.g. through tunnels) than it is to educate them on the workings of DNS and require them to deploy a global zone before they can connect to any device. >> Several people spoke in favor of supporting existing solutions (a.k.a. >> running code). >> I'd like to see us gauge consensus for this point here on the list. > > I'm against it, as you know. The problem with the current running code is > that namespaces overlap, and the UI has no way to detect or present this. > Settling on a half solution because we have running code is the wrong way to > go. > >> I tried to show in the print server example that the client >> may cache unique information about the server (GUID, unique host name, etc.) >> that makes >> disambiguation a non-issue. > > But it's not a non-issue, because the user doesn't know the GUID, and hence > doesn't know which "fridge" is the right one. (I'm just repeating Stuart > Cheshire here, from a conversation we had last week). So the GUID doesn't > give us the information we want, and indeed can produce confusing results in > the UI. A per-site naming scheme, with a nice UI on top of it, _does_ give > us that. Fridge can be fridge (home) and fridge (here) in the UI, for > instance, because we know we aren't at home. > And I'm saying it can just as easily be presented as fridge(this) and fridge(that). While I haven't tried the experiment, I believe that if you and I both had HP Mumble Jet printers and I was connected to your homenet and I tried to print something then my printer would not even appear as an available option, because under the hood the UI has determined that my printer is not on the local network. >> It was agreed that name-<random>.local. is equivalent to >> name.local-<random>. from a CS standpoint. > > Here you are definitely arguing about the wrong problem. At the > presentation layer, both are equivalent, and both are wrong. What we want > is not fridge-1.local and fridge-2.local, but fridge (here) and fridge > (there). > I thought I was discussing the problem referenced in the subject line... >> - it is relatively easy to retrofit this behavior to hosts and servers >> and difficult (or >> impossible) to reflash existing printers > > You don't need to update the printers. Just have the CPE device say where > you are. This stuff can all happen at the presentation layer—at the > protocol layer, it's perfectly fine if the printer is "printer.local" as long > as the CPE says what "local" means, and the UI presents it correctly. > >> - using .local-<random>. based on ULA means complexity equivalent to ULA >> distribution problem. This is a big issue when homenets are coalesced and >> can't be solved by routing alone. > > In general, the homenet merge is not likely to be a homenet merge in the > sense you mean, but rather a decommissioning of one of two routers, and a > migration of the devices formerly connected to the one router to the network > operated by the other router. Even though we can locally route between them just fine? This sounds like a new thread... > In this case, a CPE-advertised location will solve the problem in a nice, > intuitive way—all the devices will appear in the UI as being connected to the > local network. > >> I think you're referring to a _different_ problem; resolving your >> site's resources >> while you are mobile. Am I mistaken? > > I'm claiming that this isn't a separate problem. > Well, the definition of "solution" certainly depends on the problem statement. If you define the problem as being able to access remote resources then there are existing ways to solve this, e.g. tunnels and dyndns. At every step in the transition, the dominant paradigm is likely to be the one that is most understandable and least expensive. -K- _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
