NTS client configuration support has landed

[Gary E. Miller]

Yo Eric!

On Fri, 1 Feb 2019 16:53:37 -0500
"Eric S. Raymond" <esr at thyrsus.com> wrote:

> Gary E. Miller via devel <devel at ntpsec.org>:
> > > If there's a good semantic reason to have a separate nts
> > > statement, I can do that.  
> > 
> > The options for the 'nts' and 'server' statements in the config file
> > will be different.  Trying to merge them will confuse everyone.  
> 
> Heh.  The "confuse" ship has long since sailed, Gary.  The server,
> pool, and refclock declarations are handled by the same portion of the
> grammar - the only reason they look distinct is that I created
> refclock as a synonym for "server" to make the mess a bit
> more readable.  

Right, and if we use the 'nts' keyword, that is no longer the case.

Major simplification.

> In fact grammatically they all take the same options

No.  There are at least 5 new options for the nts.  

Worse, some of the options mean different things for server and nts.

> - it's just that
> the config builder selectively ignores various option subsets
> depending on the entry type.  It's not really a very well constructed
> grammar; makes for poor error messages.

Exactly.  So don't do that!

Worse, confusing to the parser means confusing to the user.

> To "deconfuse" the situation I'd have to tear down the grammar and
> redesign it in a way that wouldn't be backwards-compatible. Crash
> landing.

The new 'nts' keyword does not require any teardown.  Just the opposite.

> 
> > Right now, server looks like this:
> > 
> > server address [key key] [burst] [iburst] [version version]
> >        [minpoll minpoll] [maxpoll maxpoll]
> > 
> > nts looks like this (not well decided or documented yet):
> > 
> > nts address [[ask address]|[require address]] [noval]] [burst]
> > [iburst] [prefer] [minpoll minpoll] [maxpoll maxpoll]  
> 
> OK, it wasn't clear before that the new "nts" declaration was
> supposed to *entirely replace* a server declaration rather than
> attaching nts options to an existing entry.  Next time do a better
> job of spec-writing, please!

How about asking before just removing next time?

And, expect several more options to the 'nts' keyword.

> I therefore withdraw my DRY objection.  That is reasonable and very
> close to what I have actually implemented. In fact the only
> difference is that what you'd spell "nts <hostname>" I spell "server
> <hostname> nts" Actually "nts" could occur anywhere in the option
> list.

And if it is anywhere in the server list it makes parsing much more
difficult as you have to parse the entire line before you can
decide what a particular keyward argument means, or is even valid.

> The remaining design question is a subtle one: in what natural kind
> are "server", "pool", and "refclock" alternatives?  Is "nts" another
> alternative in that natural kind, or is it a property of instances of
> one of the existing request alternatives?

'nts' is very much different from the others.  Totally different
protocol.  Different options.

> My design goes with a user story in which "server", "pool", and
> "refclock" are alternatives in the natural kind "time source
> requests", and "nts" is a property that may be had by instances of
> the request alternatives "server" and maybe "pool" (but not
> "refclock").

I disagree, it is very much an alternative.  Different protocol, different
options, different failure mechanisms.

> What is the natural kind in which "nts" is an alternative to "server",
> "pool", and "refclock"?  If there is such a kind, how does that square
> with the possibility that "nts" may become a property of pool request
> instances?

Since the discussion has not figured out how that can even work, premature
to make that a given.  My gut feel is that 'nts' can not be part of
the 'pool' as then a casual attacker can break the system.

> Yes, I actually care about this kind of language consistency, and not
> because I'm an irremediable pedant.

Me too.  But you are making it less consistent, not more.  Adding all
sorts of unneeded complexity.

>  (Actually I *am* an irremediable
> pedant, but that's not important right now.)  Being careful about this
> sort of detail can make all the difference between a DSL that is
> handy to use and easily retained, versus one that...*isn't*.

We all agree, thus our lengthy discussions instead of making instinctual
rash decisions.

> So: if you want me to make "nts" a declaration of its own, tell me
> the user story in which that choice makes sense.

Which I start to do in nts.adoc.  But since you just deleted it, instead
of asking questions, we no longer have a common basis to discuss.

I still can't find where you moved the nts stuff to.

> > I suspect some more options will be needed for the nts.  
> 
> When you specify them, I'll implement them. This part is easy.

Easier if on a separate keyword, and hard for the user to understand
why keywords changed meaning.  That was the consensus and why the
nts.adoc was the way it was.  Much discussion already rejected your
idea.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
	gem at rellim.com  Tel:+1 541 382 8588

	    Veritas liberabit vos. -- Quid est veritas?
    "If you can’t measure it, you can’t improve it." - Lord Kelvin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 851 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190201/c6ca51e3/attachment.bin>