We have a number of tasks ahead of us, and I'm hoping for volunteers to step up. I can't do all the code myself; I expect to have plenty on my plate documenting things, being everybody's utility coder for the interfaces between NTS and the rest of NTPsec, and reviewing code.
The tasks: 1. Prepare a note for the NTS WG on unresolved issues and underspecified things in the NTS draft. This needs to happen quickly, as the next WG meeting is on Feb 12, and the window for changes may not be open much longer. I will do this and run it by Daniel. 2. Put together client-side NTS support. This mainly means filling in ntpd/nts.c, as I have already written required the hooks into the protocol machine. Any of our devs could do this, but it looks to me like James Browning and Hal Murray have been tooling up to take on the job. They've both written code, James some library functions and Hal some socket-fu. If one of you wants to lead, say so. I will be at your service if you need more config knobs or hooks into the rest of ntpd. If you don't want it, also please say so, so another volunteer can step up. 3. It doesn't make any sense for us to build an NTS-KE server of our own before we've tested our client side's interop with the existing ones - Daniel's Python implementation and/or Martin Langer's C++ one. Therefore one of the tasks will be to study these implementations and run test instances we can verify the client side against. Gary or Ian seem like they might be fit for that job. We should probably start with Martin'sm as Daniel has mentioned his Python is not conformant to the current draft. Note that Martin Langer wrote this to me: >Furthermore I have 3 public NTS server and I'm able to create >special test cases for you if you need it. The first server >(http://nts1-e.ostfalia.de/) uses an older draft version (nts4ntp-11) >and will be updated very soon. It contains a web server too, so you >have access to log files >(http://nts1-e.ostfalia.de/homePi/SERVER/Logs/), certificates, >binaries and private keys (yes, I know. Its for tests :D). Feel free >to do what ever you want. It's a Raspberry Pi :D So it might well be the best way to handle this is to work with Martin. Whoever takes lead on this should work out the details. 4. Once we've verified the client-side code, *then* it's time to build our own NTS-KE service. A few hours ago Hal suggested implementing it as a service thread in ntpd. The more I think about this idea, the better I like it - it would simplify deployment, ease communication with the NTP side, and make it natural to put NTS-KE configuration in ntp.conf. Those of you I've mentioned, please indicate whether you can take on one of these tasks. Anybody else is also welcome to step in. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> "The power to tax involves the power to destroy;...the power to destroy may defeat and render useless the power to create...." -- Chief Justice John Marshall, 1819. _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel