What's left to doo on NTS.

[Eric S. Raymond]

Hal Murray <hmurray at megapathdsl.net>:
> 
> esr at thyrsus.com said:
> >> My big concern is that nobody else seems to be testing it.  There may be 
> >> dragons that I haven't poked.
> > Understood.  Unfortunately I myself can't be much help here - my outside view
> > of NTP is still weak, I have only limited ability to recognize what normal
> > operation should look like or spot deviations from it.  Gary or Achim or Matt
> > would be better for that end of things. 
> 
> I'm not worried about subtle problems.(*)  I'm interested in the big picture.  
> Is there too much crap in the log file?  Does the reach column in ntpq -p look 
> reasonable?  ...

Ah, well, that I can handle.

I'm past due to refresh the test farm software, anyway.

> The other half of the big picture is setting up certificates.

Yeah, that's the part I'm not looking forward to documenting.

> *) There is actually one interesting point that authentication makes more 
> interesting.  On receive, we get a time stamp when the packet arrives.  We can 
> take all day to inspect the packet and run authentication code.  On transmit, 
> we grab the time and put it in the packet.  All the delays between then and 
> when the packet hits the wire are contributing to a misleading time stamp.  
> Authentication code is on that path.  The same thing happens on both client 
> and server.  If they are similar CPUs, the offsets should cancel.  If not, ... 
>  I think we can measure this by comparing IPv4 and IPv6 with NTS on one.

Let me take a different tack: can we move the aut computation off path?
-- 
		<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.