Subject: [Ntp] My thoughts on flags

From: Watson Ladd <[email-masked]>
Date: Mon, 22 Jul 2019 21:37:58 -0700

Dear all,

One of the items on the agenda that didn't really discussed was a
number of drafts: draft-stenn-ntp-i-do-06,
draft-stenn-ntp-extension-fields-09,
draft-stenn-ntp-leap-smear-refid-00. All of them are masterworks of
repurposing fields, adding structure to hitherto unstructured
identifiers, and other tricks beloved of

And none of them are necessary. Autokey should be dispenced with now
that we have NTS. An NTS-KE exchange can easily be extended to include
information about server features, and in event of changes a rejection
of cookies can force a new NTS-KE exchange. This exchange can also
include smeared time, which wouldn't be necessary if we represented
timestamps in a format like MJD+seconds since midnight or somesuch
(even UTC if properly understood).

I would like to see us adopt the attitude of the web community where
new features are gated on TLS support to spur adoption.

Sincerely,
Watson

---

From: "Dieter Sibold" <[email-masked]>
Date: Tue, 23 Jul 2019 11:37:08 -0400

Dieter Sibold
[email-masked]

> (even UTC if properly understood).

I agree. Using NTS-KE is a great mean to provide information about the 
NTP server that cannot be transmitted via the basic NTP header, 
especially for static information. For information that change 
dynamically on the server side the use of extension fields seems more 
appropriate to me.

> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 23 Jul 2019 15:40:26 +0000

> new features are gated on TLS support to spur adoption.

Strong +1

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 23 Jul 2019 17:52:35 +0200

> (even UTC if properly understood).

What if someone wants to support a new extension field, but doesn't
want to support NTS(-KE)? Should TCP and TLS be requirements of
unrelated NTP extensions?

-- 
Miroslav Lichvar