>> I've been planning to implement it on the server side, but other >> things have been coming up.
> No worries. Let me know if you have plans to do something with it, and I can reorder my todo list. > As one of many examples of tricky policy issues As usual, Dave, you're overcomplicating things. It's not *that* bad. > I don't see a way how to do ahcp-pd right without all the servers > maintaining some shared global state No, the address space is partitioned between servers, there's no shared state. That's an important design criterion. > and/or potentially naking or adding a state like "I can help you but > perhaps someone else has better data, get back to me later" - to an > initial pd request. That's done on the client side. When a client receives an OFFER from a server, it can decide whether the offer is good enough (in which case it sends a REQUEST), or whether it prefers to continue the increasing-diameter search. > Then there's ugh - security. Yeah, but that's orthogonal to policy -- AHCP, just like DHCP, is a completely insecure protocol. (You may have a strict policy in an insecure system, as you can have a lax policy that's enforced securely.) > Then the relay problem Eh? What relay problem? -- Juliusz _______________________________________________ Babel-users mailing list Babel-users@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/babel-users