On Sun, Aug 25, 2019 at 1:49 PM Achim Gratz via devel
wrote:
> Mark Atwood via devel writes:
> > How does everyone feel about next Saturday, Aug 31 2019-07-31?
>
> You've got a time machine? 8-)
>
No, but as Chronos is not implemented, he can set time to what ever he
wants on the NIST and
Mark Atwood via devel writes:
> How does everyone feel about next Saturday, Aug 31 2019-07-31?
You've got a time machine? 8-)
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
> How does everyone feel about next Saturday, Aug 31 2019-07-31?
Looks good to me.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
There is discussion of a need for a point release of NTPsec.
I agree, we've done a bunch of useful and user visible stuff.
How does everyone feel about next Saturday, Aug 31 2019-07-31?
That gives us a week to beat on our new features, and to merge and beat on
pending merge requests.
..m
Hal Murray :
>
> e...@thyrsus.com said:
> > But doing the right thing is better than a switch. And the test is a cost
> > that only needs to be paid once.
>
> I think your no-switch approach is good for things where the choice is A or
> B,
> like picking the right baud rate.
>
> But this
Hal Murray via devel writes:
>> Basically, I wish to highlight that things may *break* with pre 1.2.0
>
> Do we have any hints that anybody else who interoperated with our old code
> depended on our bug?
Pretty much everybody seems to have had the same bug: accepting whatever
the server sent
I just changed the NTS key rotation timer from 1 hour to 1 day.
The spec is setup for 1 day. 1 hour enables testing.
--
These are my opinions. I hate spam.
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
e...@thyrsus.com said:
> But doing the right thing is better than a switch. And the test is a cost
> that only needs to be paid once.
I think your no-switch approach is good for things where the choice is A or B,
like picking the right baud rate.
But this isn't one of those cases. This is
> Would this be a better formulation? The NTS ALPN negotiation sequence now
> checks for length of the handshake string. This may break interoperability
> with other, non-compliant, NTS implementations.
> Basically, I wish to highlight that things may *break* with pre 1.2.0
Do we have any
Richard Laager via devel :
> On 8/23/19 6:55 PM, Hal Murray via devel wrote:
> > Or maybe wait for the NTS RFC to come out so we have a good reason for the
> > release.
>
> What is the official (or barring that, consensus) view on the quality of
> NTS in NTPsec? Is it something that is usable in
Hal Murray :
>
> >> Is there time to add an IPv4 only initialization option for NTS?
> > Options are bad, in general. Explain why you want this>
>
> (I was going to poke you on this.)
>
> There is a bug waiting for your comment - #666. Looks like you found it.
>
> > I hate options. They add
Sanjeev Gupta :
> Eric
>
> NEWS:
> The NTS ALPN negotiation sequence has been modified for improved
> interoperability with orther NTS implementations.
>
> Would this be a better formulation?
> The NTS ALPN negotiation sequence now checks for length of the handshake
> string.
> This may break
devel@ntpsec.org said:
>> Or maybe wait for the NTS RFC to come out so we have a good
>> reason for the release.
> What is the official (or barring that, consensus) view on the quality of NTS
> in NTPsec? Is it something that is usable in production? If so, please cut a
> release sooner rather
Eric
NEWS:
The NTS ALPN negotiation sequence has been modified for improved
interoperability with orther NTS implementations.
Would this be a better formulation?
The NTS ALPN negotiation sequence now checks for length of the handshake
string.
This may break interoperability with other,
On 8/23/19 6:55 PM, Hal Murray via devel wrote:
> Or maybe wait for the NTS RFC to come out so we have a good reason for the
> release.
What is the official (or barring that, consensus) view on the quality of
NTS in NTPsec? Is it something that is usable in production? If so,
please cut a
> Does it make sense to call this 1.2.0 instead of 1.1.7? Especially since we
> have the ALPN compatiblity fix?
I suggest 1.1.7 soon, then a round of testing and cleanup before 1.2.0.
Or maybe wait for the NTS RFC to come out so we have a good reason for the
release.
--
These are my
>> Is there time to add an IPv4 only initialization option for NTS?
> Options are bad, in general. Explain why you want this>
(I was going to poke you on this.)
There is a bug waiting for your comment - #666. Looks like you found it.
> I hate options. They add complexity and proliferate
On Fri, Aug 23, 2019 at 12:41 PM Eric S. Raymond wrote:
> James Browning via devel :
> > AFAICT issues 599 and 566 still affect FreeBSD.
>
> Not urgent, IMO. In particular, I'm now fweeking more pressure to get
> the NTS fix out.
>
Then they can wait. Sanjeev pointed out that there are lots of
James, I am not sure on the time frame to patch and merge the issues you
mentioned, but I am concerned about the change to the behaviour of NTS.
We are not short of integers, 1.3.0 can be next week :-)
On Sat, 24 Aug 2019, 3:27 AM James Browning via devel,
wrote:
> On Fri, Aug 23, 2019 at 9:43
James Browning via devel :
> AFAICT issues 599 and 566 still affect FreeBSD.
Not urgent, IMO. In particular, I'm now fweeking more pressure to get
the NTS fix out.
> There is a stub in devel/README mentioning devel/tidy which never made it
> into the tree.
Oops. Just fixed.
> Is there time
On Fri, Aug 23, 2019 at 9:43 AM Sanjeev Gupta via devel
wrote:
> We need a point release. Significant things that have happened recently:
>
>
>- The g and G suffixes
>- Removal of neoclock4x
>- Some doc changes
>- The ALPN change
>
> The last is critical, it throws into doubt all
On Sat, Aug 24, 2019 at 2:36 AM Matthew Selsky
wrote:
> Does it make sense to call this 1.2.0 instead of 1.1.7? Especially since
> we have the ALPN compatiblity fix?
>
Yes, please. Although NTS implementation internally has (only trivially)
changed, a bump to 1.2.0 would provide more warning
On Fri, Aug 23, 2019 at 02:12:21PM -0400, Eric S. Raymond via devel wrote:
> Sanjeev Gupta :
> > We need a point release. Significant things that have happened recently:
> >
> >
> >- The g and G suffixes
> >- Removal of neoclock4x
> >- Some doc changes
> >- The ALPN change
> >
>
Sanjeev Gupta :
> We need a point release. Significant things that have happened recently:
>
>
>- The g and G suffixes
>- Removal of neoclock4x
>- Some doc changes
>- The ALPN change
>
> The last is critical, it throws into doubt all the interop we have with
> other NTS
On Fri, Aug 23, 2019, 9:43 AM Sanjeev Gupta via devel
wrote:
> We need a point release. Significant things that have happened recently:
>
>
>- The g and G suffixes
>- Removal of neoclock4x
>- Some doc changes
>- The ALPN change
>
> The last is critical, it throws into doubt all
We need a point release. Significant things that have happened recently:
- The g and G suffixes
- Removal of neoclock4x
- Some doc changes
- The ALPN change
The last is critical, it throws into doubt all the interop we have with
other NTS implementations. We need a tag to describe
26 matches
Mail list logo
