What's left to doo on NTS.

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> > What still needs to be done to fully land this feature? Key rotation?
> > Anything else?
> 
> I've been collecting major items in devel/TODO-NTS

Is there some reason this isn't just a section in nts.adoc?  (Which
may need some GC at this point.) The whole idea of that document was
to be a planning whiteboard.

> Mostly, it needs testing and probably an overview level documentation.  
> Something high level rather than the details of how to configure it.  Maybe a 
> HOWTO too.

I'll take responsibility for the documentation.

> We have to decide how paranoid we want to be about security.  The sort of 
> things that are good for debugging enable operation in insecure modes.  For 
> example, the "noval" option on certificates.  Maybe we should have a configure 
> time option.

Remember, I'm trying to get away from configure-time options. Forward
planning - every single one of those is going to become a serious pain
point if we port to Go, which is looking likelier all the time.  But
even if that weren't an issue, variant builds complicate CI and are
good to cut down on for that reason alone.

(Yes, no config options means conditionally configuring refclocks is
going to become a difficulty in Go-land.  I have an idea about how to
tackle that involves "go generate" and tricky games with the Go build
tags feature, but it's not an idea that generalizes to other kinds of
feature options easily.)

The philosophy I like to follow in situations like this is almost what
ntpd already does with tinker variables: (1) allow dangerous options,
(2) default them to safe values, (3) surround then with "here there be
dragons" warnings.

I say "almost" because I differ from Classic's implicit in that I assign a
higher downstream cost to having lots of code paths, so am more reluctant to
proliferate options.

But it seems to me that were're in a situation where we need the
debugging options, so the argument is really over (a) how to default
them, (b) how to document them (in particular, which ones get big
THESE COULD BE REMOVED AT ANY TIME warnings), and (c) what our policy
about actually removing options is.

> There are lots of small/cleanup items.  I don't have a list handy.

Those should go into devel/TODO-NTS...which should probably merge into
devel/nts.adoc.

> The NTS doc is still a draft, aka moving target, so we need to be prepared to 
> make incompatible changes.

Understood.

> We need to go through the doc and find all the MUST and SHOULD items and 
> verify that we do them or put them on an exception list.

I'm not sure who the best persion to do that would be.  At a guess, Daniel, with
you second and me third.

> I assume your "key rotation" includes saving keys to disk for recovery after 
> restart.

Yes.

> msyslog needs to be thread safe.  One way to do that is to make sure each line 
> is written as a single call to write.  That's somewhat complicated since the 
> same message goes to various combinations of 3 places: syslog, log file, 
> console/stdout.

Nah.  I've looked at it.  More bark on that problem than wood.  Three
hours' work start to finish, I'd say. I'll do it.

> A problem in this area is that we would like things to keep working if it 
> crashes within msyslog.  A simple lock would hang when we tried to print the 
> crash message.  I think POSIX locks have an option for threads to be able to 
> lock again.

Re-entrant locks are a thing, yes, but I think explicit locking here would be
asking for trouble.  Better to figure out what atomicity guarantee we believe
for write(2) and lean on that.  I think I know (and, as importantly, can
document) what assumptions to work on.
-- 
		<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>

My work is funded by the Internet Civil Engineering Institute: https://icei.org
Please visit their site and donate: the civilization you save might be your own.