Refclocks and formatting

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> > Mode 6 should really not be shipping those flag bits in hex at all; it
> > should decode them into a list of mode strings. That would be the *right*
> > fix, but of course it would break mode 6 backward compatibility.
> 
> > I'm tempted to do it anyway.  I'm normally extremely wary of doing things
> > that might break sysadmin scripts, but this is a rather improbable case -
> > somebody would have to be decoding those bits with a thing that isn't ntpq
> > or ntpmon itself to be affected.
> 
> We could ship both hex and text.  New code could use the text and ignore the 
> hex.  Old code would continue doing whatever it did.

Here's the thing - I really don't think old code ever did anything but present
this particular item for eyeballing.  And the argument against shipping hex is
that it's a bad idea to visibly ship bits the interpretation of which could
change in the future for reasons beyond our control.

That's what makes the PLL bits different from the other status-word bits.
The others we control.  As long as we don't mess with the definitions in
code files, nothing else is going to break.

> > We could keep the old behavior under ENABLE_CLASSIC_MODE.  Hm.  Hal, what do
> > you you think our actual risk exposure is here? 
> 
> That doesn't feel right, but I can't come up with a simple example to 
> demonstrate why.

Not very helpful, there.

> I think the exposure is very low.   Any geek that has written a mode 6 client 
> can probably fix it quickly.

That's what I think too.

> The real problem is that this is just the tip of an iceberg.  I'm sure there 
> will be other fixes we want to make that are not backward compatible.  Is 
> shipping both a good general policy?

If you mean changes to Mode 6, I'm not sure enough that shipping both hex and
text would fix anything to we want to do it.  How do we know old code wouldn't
barf on the following text?  Naive implementations in scripting languages
would do that.

> Do we need to start tracking what we will support and/or develop a policy for 
> when we drop support for a slot?

I've been obsessive about documenting visible changes; see docs/ntpsec.txt for
them all.  There have not been many such things, and only one change in Mode 6.
There's one context in which it ships a driver name rather than a number now.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

Please consider contributing to my Patreon page at https://www.patreon.com/esr
so I can keep the invisible wheels of the Internet turning. Give generously -
the civilization you save might be your own.