Daniel Franke <dfoxfra...@gmail.com>:
> I can probably make the time next week to make any needed fixes to
> symmetric mode and to drop multicast-client/broadcast-client mode (I
> haven't touched anything that would break
> multicast-server/broadcast-server mode).
Oh, that's good. I think Garry's suggestion that we drop the client side
of those only was excellent.
(And what the hell is "manycast", anyway? Where does it fit into all this?)
> The new restriction language is going to be an order of magnitude more
> work than that and I don't think I can get to it any time soon, but I
> also don't think 1.0 needs to block on it. Now that the refactor is in
> place, supporting both languages at once will be much less painful
> than it would have been before.
Deferring that to after 1.0 was my plan B. The reason I'd like to get
it in 1.0 is psychological, really; I expect resistence to new
features to be at its lowest point right after a shiny initial
release, and to tend to rise afterwards.
> An empty specification in my new language has different semantics than
> an empty specification in the old language so at some point there will
> have to be a flag day as to which way it is interpreted, but I don't
> think this is as big a deal as you've made it out to be. When the new
> language is first added, the rule can be: if you have any old-style
> restrict lines and no new new-style ones, you get only old-style
> behavior. Otherwise, both sets of rules are applied. That way, users
> with no restrict directives at all are the only ones who see any
> change in behavior, and that change is from a horribly insecure
> configuration to a sensible one which will break for very few people.
Normally I wouldn't consider we can accept backward incompatibility that
bad, but we can invoke the great god Security in this case.
--
<a href="http://www.catb.org/~esr/";>Eric S. Raymond</a>
_______________________________________________
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
