On 15 Aug 2012, at 11:30, Curtis Villamizar <[email protected]> wrote: > > ... and the difference between signed untrustworthy source of > information and an unsigned untrustworthy is ... what? > > This is putting yet another service in the cloud that need not be > there, though global DNS could be considered "in the cloud" as > commonly practiced for the home user. > > What we are trying to accomplish is getting a local name service that > is somehow authoritative for the local site, and optionally can be > made global. > > Putting the mapping to the local printer in the cloud would break > printing if the cloud were not accessible (hopefully temporarily) but > for some devices, like home alarms, utility metering, the fridge, > ... the kitchen sink, with low power wireless, the cloud might often > not be there. > >> but we have certainly discussed supporting suitable state >> replication/caching among signpost instances so that any >> locally-connected collection of signpost-enabled clients can do all of >> this without recourse to the public internet (eg., for cases where you >> still want to be able to interconnect your own devices and you're >> travelling, or you're at home your broadband uplink has gone down). > > Please give us a good reason to reinvent the wheel. I don't see one. > You need to say what DNS can't do, possibly with some extension. that > signpost offers.
I think you're missing the point. Signposts *is* a DNS(SEC)-based implementation and not trying to invent a new protocol, but has a very different focus from conventional DNS servers (personal tailored DNS for the individual). The server currently distributes presence information out-of-band to the other authoritative server for that domain (using the tunnels it has setup between devices). This means that you can have an authoritative server for your domain within your home network, which continues to function offline if disconnected from the wider Internet. When reconnected, it will resync with other nodes (in a loosely consistent way, which may result in a few tunnels being non-optimal, but only briefly). This'll be much more obvious as soon as we release some working code, which we're furiously hacking on at the moment. -anil _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
