Re: [Ntp] CLOCK_TAI (was NTPv5: big picture)

[FUSTE Emmanuel <[e-mail]>]

I clearly don't understand the resistance to go to a linear TAI like 
form for the core time-stamping format as long as the TAI-UTC offset is 
part of the core protocol frame. It could not be an option.
- it is cleaner, doing timekeeping math full of time steeping corner 
cases is a mess and ask for always buggy implementations
- it map directly to hadware time-stamping clock and which are not able 
to step and which are already used with TAI epoch by PTP control plane 
opening the opportunity to be able to share the clock and time-stamping  
hardware between PTP and NTP.
- all future stratum 1 NTPv5 servers will have one way ore another the 
TAI-UTC offset available, in the TZ database or given by the GPS clock 
or by any other mean. As long as it is a day 1 requirement, the 
requirement will be fulfilled automatically (GPS, PTP, new methods) or 
manually as a maintenance procedure (update of the TZ database manually 
or by OS updates, update of the leap file )
- all clients and upper stratum ones will no longer have to care about 
how to get the offset, it is there. All arguments for iot/never updated 
clients will be moot. All NTPv5 clients will be self containing.

You will have to do some conversions and adaptations in the OS 
adaptation layer, as today for all NTP implementations, and this layer 
will not be messier as the core is today. No need to wait that operating 
systems fully support a non-leaping timescale, or TAI-UTC offset natively.
It will open the opportunity for some of us to do work on the OS 
interfaces and time keeping code to extend it on Linux or BSD to be able 
to discipline the CLOCK_TAI directly for example, and the opportunity to 
have a complete cleaner and better system some days.

As long as the core protocol include the TAI-UTC offset, and 
good/unambiguous leap announcement, I consider TAI-like form of time for 
timestamps a great improvement on all fronts.

But if TAI-UTC offset is envisioned as an extension only, it does not 
work. This extension could be great for NTPv4 but sub-optimal for a new 
v5 specification.

Emmanuel.