On Wed, Mar 30, 2016 at 10:57:35AM +0000, Harlan Stenn wrote: > Miroslav Lichvar writes: > > If the server is not able to respond in time (whatever that means), it > > shouldn't respond at all. The client will try again later. Responding > > with a plain NTP message would not help as the client would ignore the > > reply. Even if it didn't ignore it, the new request would have to be > > the same NTS message as before, because the server doesn't have the > > previous request. I doubt any server implementation would want to > > cache requests and replies. > > I disagree, but this may need to become a local policy choice. > > Are you suggesting the server saves state between the first incoming > client request that we can't respond to "fast enough" and then on the > next poll the server sees that the client request is identical, so it > can immediately respond with the data it has had time to generate?
Yes, if you really needed to significantly delay the response, this would be one way do to it without having to modify the NTS spec. But I still don't see how it's useful and I'd be worried about DoS attacks it could bring in. > > What restrictions would you like to lose? The suspension of the NTS > > protocol with plain NTP messages you described seems to me like a > > major complication in the protocol, which would require the server to > > cache the client's requests. > > As opposed to degrading the server's performance? I'm not sure I follow. How is this related to the server's performance? > I think we should define as few restrictions as possible here, and leave > it to the implementation to decide what works best. As long as the protocol stays simple and secure, I'm ok with that. -- Miroslav Lichvar _______________________________________________ TICTOC mailing list [email protected] https://www.ietf.org/mailman/listinfo/tictoc
