> On 23 Apr 2016, at 17:39, Juliusz Chroboczek <j...@pps.univ-paris-diderot.fr> > wrote: >> I don’t see how dns gets updated. Are such updates out of scope of >> shncpd? > > Do you mean, (1) how is a DNS resolver advertised to clients, or > (2) how clients are registered in DNS ? > > (1) is done by using the -N flag on the router advertising an external > connection (-E). This flag can be repeated multiple times. > > (2) is a host issue, so I believe it is better handled outside of shncpd, > but I'm quite willing to be convinced otherwise. (The obvious alternative > would be to have shncpd update DNS when it gives out a DHCP lease, but > that would mean giving up on stateless autoconf.) > >> Are they in scope for the other homenet protocols? > > Markus, Steven, Ted? What's the plan here? Do we count on mDNS proxying, > or should we be advertising an RFC 2136 server over HNCP? > Well that went well and created what I hope have been useful interactions.
So my next question is ‘what is External and what is Internal?’ How is this topolgical aspect identified and the ‘shared, agreed topology’ communicated between routing entities (I’m eschewing the term router here, to emphasise for my own benefit that routers aren’t necessarily on separate pieces of hardware - and in consumer IoT, I’m expecting the combination to be increasingly common), and how do they update the flags on the shncpd instances that have been started? Or is it expected that the user nominates the topology and it’s static? I’ve seen such topologies shift over varying timescales (seconds to years). Sometimes the change is a fault. Sometimes it’s expected. Both usecases are important. I think that I read in the homenet documentation that directed graph topologies are anticipated, but I’m not clear how. It may be that they’re either scoped out, or future work. Sorry if that’s a bit of a neophyte’s question. > -- Juliusz Tim _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
