I have now also read the naming draft. I think it does a good job of summarising the desirable feature set, but it does strike me as being slightly on the complex side in certain respects, and trying to simplify things a bit might be worthwhile.
(I've been following homenet for a while but haven't commented much. I think having naming work right is an important piece of the puzzle, so hoping to add some momentum to the effort by weighing in). I'll start with Juliusz' comments below and maybe add one or two of my own. > These are some fairly ambitious requirements, and I believe that they > deserve discussion separately from the naming issue. More precisely: > > (1) Are wo to go to the effort of specifying and deploying a new ND option? As I read this, it is mostly an optimisation and could be left out in favour of simply timing out. Presumably the case it is solving (homenet configuration lost) is so uncommon that having a simple timeout is better than a new option that is probably not going to be very well tested in any case. > (2) Defining a management API goes against the Homenet tradition, which > is to negotiate things over HNCP rather than defining new APIs. I agree that the "Restful API" sticks out a bit in the document. Probably in part because it is a placeholder for something that is not defined yet. But I'm not sure that it is actually needed. Could the document not just specify that there must be some way to configure it appropriately, and leave the details to the implementations? > (3) HNCP does not currently mandate using a local resolver, and neither > does it define a means to advertise the address of a local resolver to > HNCP routers. Are we requiring a full DNS server with DNSsec support > on each HNCP node, including an HNCP speaker that is not a router? > (Note that I'd be strongly opposed to requiring that every HNCP > speaker must be a router, and I think my opinion on putting a DNS > forwarder on every HNCP node is similar.) As I read this, a resolver on each link is required to filter out spurious DNS updates (last sentence in section 4.1). If some other mechanism to prevent this is substituted, presumably the requirement to have a resolver on every link could be dropped? Another thing that stuck out to me was the suggestion (in section 6.1) to stick a captive portal in the user's face if there's a configuration problem (or does "triggering captive portal detection" instead refer to hijacking just the DNS names that, say, Android uses to detect the presence of a captive portal?). Not sure I agree that's a good idea - apart from captive portals being annoying as hell, this is again specifying a UI element in detail; should the spec really do that? Finally, the mechanism outlined in section 4.8 to use the homenet services outside the homenet seems somewhat brittle to me. It involves both caching logic and key management. I'm not sure to what extent this is considered a killer feature. Would it be unreasonable to tell users to simply add services they want to access from off-network to the public zone? -Toke _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
