Daniel Franke :
> On Tue, Mar 5, 2019 at 2:37 AM Daniel Franke wrote:
> >
> > I'll post a rebuttal sometime later this week. As for IETF processes,
> > though, you're years late. The WG already had a consensus call in 2016
> > on what NTS-KE's framing format should look like, and it was
> >
On Tue, Mar 5, 2019 at 2:37 AM Daniel Franke wrote:
>
> I'll post a rebuttal sometime later this week. As for IETF processes,
> though, you're years late. The WG already had a consensus call in 2016
> on what NTS-KE's framing format should look like, and it was
> unanimous. You can still comment
Richard Laager via devel :
> Is microjson something I can dynamically link against, or is it embed only?
There are two parts to a microjson deplyment: the generic microjson runtime,
and a set of application-specific structure initializers you have to declare to
tell the runtime how to parse. The
Yo Richard!
On Thu, 7 Mar 2019 13:50:20 -0600
Richard Laager via devel wrote:
> On 3/7/19 1:22 PM, Gary E. Miller via devel wrote:
> > Yo Richard!
> >
> > On Thu, 7 Mar 2019 11:06:58 -0600
> > Richard Laager via devel wrote:
> >
> >> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
>
On 3/7/19 1:22 PM, Gary E. Miller via devel wrote:
> Yo Richard!
>
> On Thu, 7 Mar 2019 11:06:58 -0600
> Richard Laager via devel wrote:
>
>> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
>>> JSON is C is normally *very* awkward, vastly worse than Go, because
>>> full JSON parse needs to
Yo Richard!
On Thu, 7 Mar 2019 11:06:58 -0600
Richard Laager via devel wrote:
> On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
> > JSON is C is normally *very* awkward, vastly worse than Go, because
> > full JSON parse needs to do fancy dancing with dynamic memory to
> > handle
On 3/7/19 12:56 AM, Eric S. Raymond via devel wrote:
> JSON is C is normally *very* awkward, vastly worse than Go, because
> full JSON parse needs to do fancy dancing with dynamic memory to
> handle heterogenous arrays. The good news is that I ran into this
> problem back in 2009 on GPSD, solved
Hal Murray :
> Interesting, but...
>
> Why isn't refclock_gpsd a good example?
The protocol isn't bad. The implementation is kludgy and shoddy enough
to make me want to raze it to the ground and start over. Maybe I
ought to do exactly that...
> Is there a good package for working with JSON?
Interesting, but...
Why isn't refclock_gpsd a good example?
Is there a good package for working with JSON?
I'm not convinced that NTP is a good example. Sure, in hindsight, we can see
some problems, but it's not obvious to me that JSON is the answer. Are there
any interesting alternatives?
Yo Ian!
On Wed, 6 Mar 2019 13:16:28 -0600
Ian Bruene via devel wrote:
> On 3/6/19 1:01 PM, Richard Laager via devel wrote:
> > On 3/6/19 12:19 PM, Achim Gratz via devel wrote:
> >> SNMP is as dead as a Dodo if you ask me…
> > It's used all over the place if you ask me.
>
> Common, dead,
On 3/6/19 12:19 PM, Achim Gratz via devel wrote:
> SNMP is as dead as a Dodo if you ask me…
It's used all over the place if you ask me.
--
Richard
___
devel mailing list
devel@ntpsec.org
http://lists.ntpsec.org/mailman/listinfo/devel
Hal Murray via devel writes:
> Eric said:
>>> I don't want the UI side of HTTP in ntpd.
>> I'd like to understand better what you mean by "the UI side" and
>> what your objection is.
>
> Web stuff is complicated. We'll get into UI wars.
> You can't easily script things.
Huh? HTTP is a transport
Eric said:
>> I don't want the UI side of HTTP in ntpd.
> I'd like to understand better what you mean by "the UI side" and
> what your objection is.
Web stuff is complicated. We'll get into UI wars.
You can't easily script things.
If you want a web UI, we should build that on top of Mode 6
dfoxfra...@gmail.com said:
[using ALPN]
> I've never tried it myself, but I think Nginx can handle this. Use
> ngx_stream_ssl_preread_module to check ALPN, then based on what's there
> either terminate TLS locally or forward traffic at the TCP layer to some
> other port on ::1. AFAIK Apache
On Tue, Mar 5, 2019 at 4:10 PM Hal Murray wrote:
> How does that work in practice? 443 is for HTTPS. Does Apache have a call
> out mode? Is there a standard utility that does ALPN dispatching? What
> fraction of clients send ALPN info?
I've never tried it myself, but I think Nginx can handle
> The spec already mandates that ALPN always be used and allocates a tag with
> IANA.
My call to
SSL_CTX_set_alpn_protos(client_ctx, alpn, sizeof(alpn));
is inside
#if (OPENSSL_VERSION_NUMBER > 0x1000200fL)
> tcp/123 is already a new firewall hole. If you want to work around
>
On Tue, Mar 5, 2019 at 2:28 PM Eric S. Raymond wrote:
> Thanks. I didn't see that in the RFC draft. Did I simply miss it or is
> it in a registry that is entirely separate?
Last sentence of section 3, first sentence of section 4, and section 7.2.
___
On Tue, Mar 5, 2019 at 1:52 PM Eric S. Raymond wrote:
> If you end up going with a non-123 port number, I requst that the RFC
> allow use on other ports when and if ALPN is available and specify
> the ALPN tag to be used.
The spec already mandates that ALPN always be used and allocates a tag
Daniel Franke :
> On Tue, Mar 5, 2019 at 7:21 AM Eric S. Raymond wrote:
> > You yourself advocated that Mode 6 ought to be replaced by an HTTP
> > service on TCP port 123. I think that's a good idea, if we can do
> > it. The problem is than NTS-KE *also* wants to have TCP 123.
>
> Like Hal
On Tue, Mar 5, 2019 at 7:21 AM Eric S. Raymond wrote:
> You yourself advocated that Mode 6 ought to be replaced by an HTTP
> service on TCP port 123. I think that's a good idea, if we can do
> it. The problem is than NTS-KE *also* wants to have TCP 123.
Like Hal pointed out, ALPN makes this a
Hal Murray :
>
> Eric said:
> > You yourself advocated that Mode 6 ought to be replaced by an HTTP service
> > on
> > TCP port 123. I think that's a good idea, if we can do it. The problem is
> > than NTS-KE *also* wants to have TCP 123.
>
> I don't want the UI side of HTTP in ntpd.
I'd like
Eric said:
> You yourself advocated that Mode 6 ought to be replaced by an HTTP service on
> TCP port 123. I think that's a good idea, if we can do it. The problem is
> than NTS-KE *also* wants to have TCP 123.
I don't want the UI side of HTTP in ntpd.
> What that says to me is that whatever
Daniel Franke :
> I'll post a rebuttal sometime later this week. As for IETF processes,
> though, you're years late. The WG already had a consensus call in 2016
> on what NTS-KE's framing format should look like, and it was
> unanimous. You can still comment during IETF Last Call and try to
>
I'll post a rebuttal sometime later this week. As for IETF processes,
though, you're years late. The WG already had a consensus call in 2016
on what NTS-KE's framing format should look like, and it was
unanimous. You can still comment during IETF Last Call and try to
convince the IESG to block the
This is why my design sketch for NTPv5 is a JSON profile, and wgy I
intend to file an objection to the KE protocol in the NTS draft.
http://esr.ibiblio.org/?p=8254
--
http://www.catb.org/~esr/;>Eric S. Raymond
I cannot undertake to lay my finger on that article of the
25 matches
Mail list logo
