On Tue, 11 Jul 2023 at 06:04, Tal Mizrahi <tal.mizrahi.phd@xxxxxxxxx> wrote:
Regarding the question about the intended status of the document,
there was quite a bit of discussion in the NTP working group about
whether the document should be informational or experimental, and the
decision was to proceed with informational. We believe that
"informational" fits this draft for two reasons: firstly, an
experimental evaluation was performed by the authors, and contributed
to how Khronos is currently defined, and secondly, Khronos can be
implemented without affecting or compromising interoperability with
existing NTPv4 implementations. While the NTF implementation is in
progress, we believe it should not affect the intended status of the
current document.
Given that Ask Bjørn Hansen, the longtime unpaid and underappreciated administrator of pool.ntp.org has expressed his concern that Khronos presents an existential threat to pool.ntp.org due to the increased DNS query load in particular, keeping in mind that the DNS servers are not running traditional DNS software with static zones but rather custom DNS software to provide location-customized responses [1], and given there is no comparable alternative NTP pool upon which Khronos can rely, I would argue Experimental status or withdrawal of the draft entirely until an alternative pool can be provisioned is in order.
Despite the authors' assertions that the increased query load on the pool DNS and NTP servers is negligible, in my opinion Khronos represents an extremely selfish tragedy of the commons risk by proposing widespread use of an approach which uses hundreds of servers per client to crowdsource time.. Yes, I am aware the designers believe only a dozen or so NTP servers will be queried and those queries will be 10 times less frequent than NTPv4's, but I am also aware that when conditions are right, hundreds of NTP servers will be queried simultaneously. Given the lack of third-party real-world experience of how infrequent such "panic mode" events will be in practice, I would counsel caution and at a minimum change the proposed status to Experimental.
Cheers,
Dave Hart
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
