[homenet] About Ted's naming architecture presentation and document

[Juliusz Chroboczek <[e-mail]>]

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