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.
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. 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. 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. 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? 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. 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. 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. Again, ditch the references to ISP with something "cloud-like". 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. 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. 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. 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? 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. 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. 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. 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. --- Overall, section 3.7 leaves me more confused than enlightened. It reads more like a stream of consciousness than an architecture. Mike _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
