Deciding what modes to keep.

[Daniel Franke]

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 <esr at thyrsus.com> wrote:
> Daniel Franke <dfoxfranke at 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>
>