The conclusion of the presentation today was that we should define a model for DNSSD+mDNS hybrid that will scale up to adding an authoritative name server and doing DNSSEC, so that if you buy a bunch of routers that do just the easy solution, you can buy one router later that does the real deal. Or, more likely, at least initially, just get OpenWRT.
On Wed, Nov 16, 2016 at 3:24 PM, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> wrote: > I've got three comments about the proposed naming architecture. > > > First point. I feel I'm not alone in feeling uncomfortable about the > sheer breadth of this document. I'm wondering if the main problem isn't > that it's trying to solve multiple problems, each of which is difficult in > itself: > > (1) naming within the homenet (the "epson.homenet" issue outlined by > Stuart); > (2) access to homenet devices from the Global Internet; > (3) a management API; > (4) probably others that I'm not yet able to identify. > > I think it would be worthwile working out which of the above are doable, > which of the above this working group actually cares about enough to get > them fully specified and fully implemented. In particular, I'm wondering > if dropping point (2) wouldn't yield a much simpler document. > > > Second point. Should we define a management API, it would be a waste if > it were bound to naming. Case in point, it has been requested in > a previous thread to be able to list the rogue wifi-enabled lightbulbs > that are on one's network, and prevent them from speaking to the Global > Internet. > > > Third point. Should we define a management API (and I'm not sure we > should), I'm really not worried about getting the client app into client > devices: the first implementation would be a bunch of javascript code > that's downloaded from the router's web interface. This implies, of > course, that the API is layered above something that Javascript can speak > (REST, as suggested by Ted, or simple RPC-over-JSON-over-HTTP(s), or RPC > over Websockets). > > (Aside: which is yet another argument in favour of opportunistic encryption > in HTTP, but that's not an issue for this particular working group.) > > -- Juliusz > > _______________________________________________ > homenet mailing list > homenet@ietf.org > https://www.ietf.org/mailman/listinfo/homenet _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
