Re: [Ntp] Consensus call: NTPv5 and leap second smearing

[Paul Gear <[e-mail]>]

On 29/6/23 05:55, Dieter Sibold wrote:
> Dear all,
>
> at IETF 116 we decided to have two consensus calls regarding the content of the NTPv5 requirement draft. These are consensus calls that we would like to conduct to help progress the NTPv5 requirements document (https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5-requirements/). Both consensus calls will run until July 21st 2023 and will be discussed at the next NTP wg meeting at IETF 117 in San Francisco.
>
> The second consensus call:
>
> Regarding leap second smearing:
>
> Currently, the NTPv5 requirement draft states that NTP servers should not apply leap second smearing to transmitted timestamps. Shall NTPv5 support leap second smearing? If yes, shall the NTP server apply leap smearing to the transmitted timestamps or otherwise shall the client perform leap second smearing?


The reason smearing gets used under current NTP versions is because the 
people using it have large-scale issues with timestamp-sensitive 
software, and it's more efficient to implement the smearing on the 
servers than on the clients, which can be orders of magnitude greater in 
terms of scale.  If we prevent this, we will only hinder the adoption of 
newer versions.

So, yes, NTPv5 should support leap second smearing, and yes, it should 
be possible to apply that smearing to the transmitted timestamps so that 
clients don't have to be configured for it.

My suggestion in terms of BCP 14 (RFC 2119/8174) terminology is that NTPv5:

  * MUST support sending non-leap-smeared timestamps
  * MAY support sending leap-smeared timestamps
  * SHOULD send non-leap-smeared timestamps by default
  * if it sends leap-smeared timestamps MUST provide indication (via a
    flag or extension) that they are in use
  * if it sends leap-smeared timestamps, SHOULD send indication (via an
    extension?) of the current UTC-to-smeared-time offset

Regards,
Paul