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 [email protected] https://www.ietf.org/mailman/listinfo/homenet
