Re: Deciding what modes to keep.

2016-09-30 Thread John Bell
To All - Current sysadmin here. I think I can synthesize some user stories that may be relevant. > > > On Fri, 30 Sep 2016 14:50:12 -0400 > > > Daniel Franke wrote: > > > > > > > An empty specification in my new language has different semantics > > > > than an empty specification in

Re: Deciding what modes to keep.

2016-09-30 Thread Gary E. Miller
Yo Eric! On Fri, 30 Sep 2016 17:10:39 -0400 "Eric S. Raymond" wrote: > Gary E. Miller : > > Yo Daniel! > > > > On Fri, 30 Sep 2016 14:50:12 -0400 > > Daniel Franke wrote: > > > > > An empty specification in my new language has different semantics > > > than an empty specification in the old

Re: Deciding what modes to keep.

2016-09-30 Thread Eric S. Raymond
Gary E. Miller : > Yo Daniel! > > On Fri, 30 Sep 2016 14:50:12 -0400 > Daniel Franke wrote: > > > 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 inte

Re: Deciding what modes to keep.

2016-09-30 Thread Gary E. Miller
Yo Daniel! On Fri, 30 Sep 2016 15:46:49 -0400 Daniel Franke wrote: > On 9/30/16, Gary E. Miller wrote: > > So any upward extensible is fine, but trivial back-compatibility is > > essential. > > So what do you propose? I'm not there yet I do not graps what you are proposing yet to counter in

Re: Deciding what modes to keep.

2016-09-30 Thread Daniel Franke
On 9/30/16, Gary E. Miller wrote: > So any upward extensible is fine, but trivial back-compatibility is > essential. So what do you propose? We currently have insecure defaults. This must change, and *tautologically*, such a change necessarily involves breaking backward compatibility somewhere. I

Re: Deciding what modes to keep.

2016-09-30 Thread Gary E. Miller
Yo Daniel! On Fri, 30 Sep 2016 14:50:12 -0400 Daniel Franke wrote: > 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

Re: Deciding what modes to keep.

2016-09-30 Thread Eric S. Raymond
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). Oh, that's good. I think Garry's suggestion that we dr

Re: Deciding what modes to keep.

2016-09-30 Thread 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 tha

Re: Deciding what modes to keep.

2016-09-30 Thread Eric S. Raymond
Daniel Franke : > 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 awkw

Re: Deciding what modes to keep.

2016-09-30 Thread Daniel Franke
On 9/29/16, Gary E. Miller wrote: > I use that [peer mode] all the time. Why would someone not? it allows some > optimizations in the protocol and in the relationship between servers. Compared to simply making two hosts clients of each other, the only optimization you get is a 50% reduction in