Comments in line... On 28 Feb 2013, at 22:09, Michael Thomas <[email protected]> wrote:
> In general, I do not think this is ready to go. From what I can see, there is > a significant amount of disagreement about whether mdns and/or sd have a > place in the homenet architecture, and more than a little bit of groping > around as to what the problems are that need to be solved. This section is > both prescriptive in ways it ought not be, and speculative in ways that an > architecture document shouldn't be doing. I personally think that enumerating > requirements for what any solution ought to solve for is way more important, > but is sadly lacking in this section. The aim of the document is to discuss the principles involved. > I think there is an unanswered question in this wg as to whether > naming should take a posture of how to integrate local naming into a wider > global scope, or figuring out how to adapt globally scoped naming into a > local context. In practical terms: whether we start with mdns and .local > and figure out how to hack it, or do we start with DNS and figure out how > to make it work against requirements. I will again say that the lack of > well agreed requirements for what we're doing hinders resolving this > question. I don't think that needs to be dictated here. We should be able to drive that from the principles that we can (hopefully) reach consensus on. > 3.7.1 Service Discovery > > This section starts out with telling us how it will be presented to the user > (GUI) > without any reference to why a user or anything else needs service discovery. > As service discovery is not common on the internet today, I think this > requires > a lot more motivation/requirements before jumping and telling us that out of > scope GUI's will come to the rescue -- it's not even clear that > machine-machine > interfaces to find and configure, say, my IP speakers to my IP home > entertainment > system won't be the norm. Service discovery *is* common in home networks today. Currently users see such SD via whatever GUIs they use. But sure, the future is likely to also include device to device SD. > Bottom line: remove the "how" and get immediately to the "why". Then we > can have a discussion. > > 3.7.2 Assigning Names > > I think this can be easily rewritten to not need any informative references > to yet > to be approved drafts that are not agreed upon. That reference to mDNS has been removed. > 3.7.3 Namespaces > > It's not clear to me why a single namespace is "desirable". Do rebellious > teenagers > really want to be part of their fuddy-duddy parent's namespace? Does it even > matter, architecturally? At least some motivation would be helpful. Part of my > uncomfort here is that there is a hidden assumption that a "home" is an > indivisible > unit. Is that really true? A fair point, a homenet realm may have its own namespace, potentially. Or any specific device could always independently use some 3rd party dynamic DNS service. > I'm not sure why ISP provided naming should be considered the default: we > really > don't know what will be the case, and obviously ISP's have a big downside both > from changing ISP's, as well as the multiple-ISP's standpoint. I think that > we can more > safely say that this service is just some "cloud" service provided somewhere > on the > net since there isn't any locality requirement that I'm aware of. Downgraded to 'likely'. > This section dwells in solution space far more than I think it ought, and is > highly > speculative (eg, .sitelocal, ulqdn, etc). Instead of speculating, it would be > better > to say what characteristics we want, and what requirements we need to fulfill. Trimmed a little in response. > 3.7.4 Homenet name service > > Somewhere in this document we really need to make clear how mobility figures > into > all of this. That is, what happens when things move around and what the > implications > are for naming, both in my home, and on yours. > > I don't think we should compare and contrast mdns as being "zeroconf" with > the implication that DNS is not. You can achieve "zeroconf" using service > announcement and not require multicast at all (at least not to announce the > service). In fact, until we have something resembling rough consensus, I don't > really think it's appropriate to favor one or the other in this document. I don't think the document does favour either. > > Again, ditch the references to ISP with something "cloud-like". Good idea. Or both. > I don't understand what mDNS has to do with service announcement to a > repository. mDNS is a way to find names in lieu of a repository (that is, each > device is it's own authoritative name service). Sending naming/service > announcements > to a repository is an adjunct of the repository protocols and has nothing to > do > with mDNS that I can figure out. Well, a device in a homenet today will commonly use both unicast and multicast DNS, the former for internal devices, the latter for external. > More speculation about mDNS vs. SRV records without any motivation of what > is trying to be accomplished and why... it just sort of appears out of thin > air here. So the important aspect is that devices can register themselves with a name service that would typically be hosted on the CER (and secondaried elsewhere). > I think more thought needs to be given to adding names automatically to a > repository. It mentions that a user may choose to do so, but what if there's > no meaningful "user" such as my IP-speakers with no UI? Should it try or not? > (I think it ought, but that's me). More to the point: what are the > implications > of things that don't have meaningful UI's. To be defined. But noted. > There should be some more discussion of the differences between a locally > significant domain name, and a globally significant one. What happens > when people camp on names they don't own? How might that interact with > mobility? Not sure what you mean here. > More speculation about dnydns without any motivation for why it's interesting > and/or significant. > > There seems to be no mention of the relationship between local/home resolvers > if the local resolver isn't the authoritative resolver. In particular, it's > not an > unusual situation to have a "cloud" (read: high bandwidth, well connected...) > authoritative dns be a slave to a local master. Or if you don't like that, > some > other way to achieve similar goals of not wanting my home network have to > know how to deal with ddos's on nameservers, as one for-instance. I think that's not precluded. The key bit is the homenet must be able to operate if disconnected. > 3.7.5 Independent Operation > > I'm generally skeptical that anything these days works well when you pull > the plug on the Internet. There are so many hidden assumptions about > connectivity that I don't think we should try to do anything heroic here. Sure. It's a fair goal though. > 3.7.6 Considerations for LLN's > > First I'll say that it's not just LLN's that have problems with chatty > networks: > it's anything with a battery. This should be rewritten from that perspective > and > stay away from speculation about whether proxies are needed for a particular > technology that doesn't necessarily have consensus. > > More to the point: this architecture should have considerations throughout > about > battery driven devices and their considerations, and not just whether mdns > will > cause daily trips to the store to buy new batteries. One for Anders to comment on, perhaps... > 3.7.7 DNS resolver discovery > > I don't understand this section: is there anything we need to do beyond what > SLAAC and/or DHCP do now? If there is, it might be nice to enumerate what > the problem is. This came up from Jari's own experiments. It implies stateless DHCP is available, or that the resolver address(es) are propagated by some other means. > --- > Overall, section 3.7 leaves me more confused than enlightened. It reads more > like a stream of consciousness than an architecture. For the reason Ted has observed. I agree it needs to be tighter, preferably. tim > > Mike > _______________________________________________ > homenet mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
