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

On Sun, Jul 23, 2023, 6:08 PM Steven Sommars <stevesommarsntp@gmail.com>
wrote:

> 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.
>

That's too restricted. What about UT1 or GPS time.

I rather like nothing and muddle. Next best is extensions to report
timescale and offset.

But UTC-LS is too vague. There are a dozen ways to smear

Warner

Warner

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
>>
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
>