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).
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. 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. On 9/30/16, Eric S. Raymond <e...@thyrsus.com> wrote: > Daniel Franke <dfoxfra...@gmail.com>: >> With all that said, I'm not actually advocating for removing it, >> because I want to keep it around to use as a testbed for the >> DTLS-encapsulated-NTPv4 portion of my NTS proposal. > > When will you be able to budget time to fix it? > > I'm asking because we're now in the somewhat awkward position that our > 1.0 release is mainly blocked on two of your projects - the protocol > refactor and the new restriction language > > We'll need you to spend some concentrated time on these things. > -- > <a href="http://www.catb.org/~esr/";>Eric S. Raymond</a> > _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel
