I'd like to see a nss style mechanism for handling the topology/naming service . Something that users could easily plug in their own implementation, by returning the responses to the queries(or forwarding them on to another service). This would allow people to use flat files(of various suspect formats), a DNS implementation, ldap, whatever they dreamed up. There are lots of really nice properties about DNS that would be nice to reuse, but as Nico points out most DNS tooling isn't that great. Similar engineering/operational tradeoff statements can be made about most other name service backends, so it would be nice to have a built in mechanism to plugin an alternative implementation vs having to hack up something with config management tooling after the fact. On Sep 11, 2013 1:28 PM, "Nico Williams" <nico@xxxxxxxxxxxxxxxx> wrote: > > > I'd like to echo the concern that DNS is not as great a directory for > this purpose as one might think. Many enterprises push DNS (sometimes > including administration functionality) to third-party appliances. This > means that a fair bit of task-oriented front-end admin code needs to be > written in many > Also, most DNS DBs aren't really built with referential integrity in > mind... > > A good-enough nameservice abstraction should make it easy to create > bindings to DNS, bindings to flat files, ... Flat files will probably > do just fine in many cases. If you have a decent name service database > that can handle referential integrity, then you can easily generate the > flat files as reports. > > Regarding loop detection, the traditional answers are: either a packet > route limit (IP has this) or a spanning tree algorithm (bridges for > network protocols below IP tend to have this). Thinking of that, a > spanning tree protocol for routing topologies where routers have > statically-expressed connections to each other, would be a great way to > add dynamism. Of course, so would an OSPF-style protocol. Here one > would express only links (including backup links) and let nanomsg work > out topologies dynamically, without having to worry about loops. I > recommend adding the hop limit though, then you have both choices: > spanning tree / briding, and routing. > > Nico > -- > -matt