Re: [Ntp] [EXT] NTPv5 -- drop leaps

Two alternate proposals instead.

The existing leap smearing mechanism(s) has worked well enough and can be
used if needed in the future.  There's no need to force-fit special-case
signalling into NTPv5.
A BCP for deploying leap-smearing (and for avoiding it) would benefit
operators of both NTP servers and clients.  E.g., understand exactly which
devices will perform the smearing, ensure that all utilized NTP servers use
the same smearing algorithm, recognize that your client's notion of current
time may differ from other clients, log the use of leap-smearing, and leap
smearing may not be compatible with FINRA and other requirements.

The second alternative is more radical.  Smeared time defines a new time
scale(s); call it UTC-LS.   NTPv5 continues the current UTC focus, but adds
a uniform mechanism for additional time scales.
TAI, UT1, UTC-LS.    Leap smearing is no longer a special case.

Steve Sommars

On Tue, Jul 18, 2023 at 3:08 AM Windl, Ulrich <u.windl@ukr.de> wrote:

> Hi!
>
> Considering that NTPv5 should be good for another 10 years or so, I think
> the leap seconds logic should be kept, because politics changes its mind
> much more frequently.
>
> Regards,
> Ulrich
>
> -----Original Message-----
> From: ntp <ntp-bounces@ietf.org> On Behalf Of Hal Murray
> Sent: Tuesday, July 18, 2023 4:52 AM
> To: ntp@ietf.org
> Cc: Hal Murray <halmurray@sonic.net>
> Subject: [EXT] [Ntp] NTPv5 -- drop leaps
>
>
> Leap seconds are on the way out.
>
> I think we should drop all mention of leaping or smearing from NTPv5.  The
> idea is to simplify RFCs, making it easier for us to create documents that
> are
> easy to understand and more likely that implementors will find what they
> need.
>
> It will also save time and clutter on this mailing list.
>
> There is a good chance there won't be any more leap seconds.  If there
> are, we
> can muddle through, just like we would do if we didn't have NTPv5.
>
> If we aren't cleaning up leaping and smearing, do we need a new version?
>
> We will have to support NTPv3 and NTPv4 for a long long time.  (And
> NTPv1/0)
> What do we need to fix that will be worth the effort of switching to a new
> version and running 2 versions in parallel?
>
> ----------
>
> Assuming we decide that we should work on a new version...
>
> I think we should split NTP RFCs into smaller documents.
>
> I'd like to see a clean/simple document for basic server-server traffic.
> Just
> time.  If we were going to keep leaping, TAI would be the obvious choice.
> Without leaps, UTC will work fine and we don't need anything about what
> time
> scale is being used.
>
> What is needed in a basic NTP packet?
>
> We need an RFC describing an extension for shared keys.
>
> I think an extension for UT1 or DUT1 would keep the astronomers happy.
> Would
> any of them use it?
>
> Multicast and symmetric may be appropriate for their own modes rather than
> using extensions.  I think we should leave room in the mode assignments
> for
> them and others.
>
> Does Multicast need a separate mode?  I expect it would have a multicast
> dest
> address.  Would anything else be sent to that address?
>
> Are there any fields that we might want to add to the basic packet that
> seem
> more appropriate for the packet rather than an extension?
>
> What about interleaving?  Maybe we should have a slot with room for
> various
> flags, like interleaving and symmetric mode.
>
> --------
>
> I think we need a BCP for SNTP -- specfically targeted at code that will
> go
> into ROM and won't get updated.
>
> That means we have to figure out what we will support in the long term.
>
> --------
>
> I think we should make it clear that software that looks at packets should
> check the version field first, then the mode field.  That gives us the
> opportunity to move the mode field and/or make it bigger.
>
> --------
>
> The leap-seconds file is now included with the time-zone data.  (They have
> promised to push out a release with new leap info even if there are no
> changes
> in the time zone data.)  This is now included with Debian and Fedora.
>   /usr/share/zoneinfo/leap-seconds.list
>
> It would be easy to setup a utility to tell the kernel the TAI offset and
> any
> pending leap info without help from NTP.
>
>
>
>
>
> --
> These are my opinions.  I hate spam.
>
>
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>