On 7/11/2023 12:32 AM, Dave Hart wrote:
On Tue, 11 Jul 2023 at 06:04, Tal Mizrahi <tal.mizrahi.phd@xxxxxxxxx
<mailto: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 <http://pool.ntp.org> has expressed his
concern that Khronos presents an existential threat to pool.ntp.org
<http://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.
I do not believe that Khronos MUST use the pool as its source of time
servers.
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.
[1] https://github.com/abh/geodns <https://github.com/abh/geodns>
I wonder if this is an implementation detail.
It could well be that, for some period of time, Khronos would not be a
free service, in which case there is a reasonable expectation that the
people willing to pay for Khronos protection provide the revenue stream
to fund the Khronos time server pool.
I am looking at Khronos as a mechanism. There are likely several
(local) policy choices around how Khronos will get its time and make its
choices.
Cheers,
Dave Hart
_______________________________________________
ntp mailing list
ntp@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ntp
--
Harlan Stenn <stenn@xxxxxxxxxx>
http://networktimefoundation.org - be a member!
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
