My first positive structural change to NTP

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> > Here's how I think it should look:
> 
> > ----------------------------------------------------------------------
> > refclock shm unit 0 refid GPS
> > refclock shm unit 1 prefer refid PPS
> > ----------------------------------------------------------------------
> 
> I think you should start a list of that sort of change.

There already is one, right on the https://docs.ntpsec.org/latest/
main page: 'Differences from NTP Classic'.  It's not long; before this
I've been very cautious about user-visible changes.

> Currently, we can switch between our code and ntpd classic.  The same 
> ntp.conf works for both.
>
> I think we should preserve that until we make an explicit decision that it's 
> the right time to make the break.

I have no plans to do otherwise. It's easy to write the configuration
parser so that the old and new refclock syntaxes are different,
non-conflicting subgrammars (in fact I've already achieved this).  My
intention is to not remove the old subgrammar, but to only document
the new, simpler one.  This is an easy call because they'll share
almost all their code - only the Yacc grammar and a little bit of glue
will differ.

Daniel's proposed restrict changes are a different matter.
Implementing those will necessarily be a flag day, because the empty
subgrammar has a different meaning - no specification in Daniel's
sublanguage is a secured configuration, while in the present syntax
it's not.  (Daniel says the defaults shipped by every distro in the
world are insecure.  I have no reason to doubt him.)

Daniel and Mark and I had a conversation about this on the NTPsec Signal
channel.  I don't think we have a final decision yet - it's not one
to make casually - but I think we're leaning towards flag day because
of the security issue.

> > Oh well...almost everyone disables remote querying anyway.  
> 
> It may be disabled for general IP addresses, but it's used all the time for 
> monitoring your own servers.

Understood. My assumption was that people within a close enough jurisdictional
circle that "your own server" is a meaningful concept will either be running
matching versions or know why they're not doing it and be prepared for a few
minor incompatibilities.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>