On Tue, 11 Jul 2023 at 09:34, Harlan Stenn <stenn@xxxxxxxxxx> wrote:
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.
Are you aware of another publicly-accessible pool of 500 NTP servers? The draft specifically mentions pool.ntp.org. I did not say that Khronos must use pool.ntp.org, but I am unaware of any alternative at present.
> 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.
Are we discussing an RFC draft or a commercial software package? I don't understand the business model in the latter case. There is nothing preventing someone from offering such a solution today, and they don't need an RFC to do it. On the other hand, with an RFC or draft in the wild, it would not take much investment to whip up compliant code. Where is the value proposition that would throw off enough revenue to fund hundreds of servers, and in that case why not authenticate the servers to the clients and dispose of the need to crowdsource time in the first place?
Cheers,
Dave Hart
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
