Eric S. Raymond via devel writes: > I don't see any requests from Delta to Charlie. Of course we have > polling from Alpha to Charlie and (unusually) KODs in the > other direction. > > Bravo Delta > NTS client ---------------> NTS server > ^ ^ > | | > Alpha Charlie > NTP client <--------------> NTP server > > Does this diagram look correct?
No. What the heck is an NTS client supposed to be? The description in the file suggests it is the NTS-KE described in the RFC, so it clearly belongs to the server infrastructure (in fact it's the root of trust). It might be different from the entity serving NTS to actual clients or the same box or even process, but it is logically a separate entity. There is no separation of NTS and NTP server either, an NTS server is supposed to answer plain NTP clients with the old style NTP packets. > I'm leaning towards an organization in which the NTS client code lives > inside ntpd; this would reduce deployment friction slightly. Is there > any scenario in which we'd want to run these pieces on different > hosts? Yes, if you shard the service among different physical boxes that are supposed to have the same root of trust. The figure in the draft pretty much tells you what this looks like. It makes most sense in datacenters I think and will probably not have a lot of traction otherwise. Although, come to think of it, I could see the NTP pool folks adopting it in order to unburden their server donors from that part. Another consdideration that may tilt the scales towards separating it out is that NTS-KE has a different load and risk profile than a plain NTS server without that functionality. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel