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
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
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
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
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
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
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
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
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
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
Yo Daniel!
On Thu, 29 Sep 2016 20:30:49 -0400
Daniel Franke wrote:
> On Sep 29, 2016 8:22 PM, "Eric S. Raymond" wrote:
> >
> > Gary E. Miller :
> > > > But we have one mission imperative that trumps drop-in
> > > > replacement: security. And what makes these modes targets for
> > > > removal
On Sep 29, 2016 8:22 PM, "Eric S. Raymond" wrote:
>
> Gary E. Miller :
> > > But we have one mission imperative that trumps drop-in replacement:
> > > security. And what makes these modes targets for removal is that,
> > > according to Daniel, there are fundamentally impossible to secure.
> >
> >
Gary E. Miller :
> > But we have one mission imperative that trumps drop-in replacement:
> > security. And what makes these modes targets for removal is that,
> > according to Daniel, there are fundamentally impossible to secure.
>
> I would split that hair. Maybe ntpd could still send broadcast
Yo Eric!
On Thu, 29 Sep 2016 19:39:28 -0400
"Eric S. Raymond" wrote:
> Gary E. Miller :
> > On Thu, 29 Sep 2016 19:19:28 -0400
> > "Eric S. Raymond" wrote:
> >
> > > So, the question for our domain experts is, are there any serious
> > > use cases for broadcast modes? They cost a lot in con
Gary E. Miller :
> On Thu, 29 Sep 2016 19:19:28 -0400
> "Eric S. Raymond" wrote:
>
> > So, the question for our domain experts is, are there any serious use
> > cases for broadcast modes? They cost a lot in configuration and
> > code complexity; it would be nice to just drop them. How much
> > s
Yo Eric!
On Thu, 29 Sep 2016 19:19:28 -0400
"Eric S. Raymond" wrote:
> So, the question for our domain experts is, are there any serious use
> cases for broadcast modes? They cost a lot in configuration and
> code complexity; it would be nice to just drop them. How much
> screaming might that c
Mark, heads up! Possible policy/PR issue.
I have merged Daniel Franke's refactoring of the NTP protocol machine.
It seems to work. However, there are some operation modes of Classic
that may be broken and need fixing.
After the refactor:
(1) Interleave mode is outright gone. This is OK, as it
17 matches
Mail list logo
