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

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