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

Also acceptable IMHO (+1)

-----Original Message-----
From: ntp <ntp-bounces@ietf.org> On Behalf Of David Venhoek
Sent: Friday, June 30, 2023 11:09 AM
To: Paul Gear <ntp=40libertysys.com.au@dmarc.ietf.org>
Cc: ntp@ietf.org
Subject: [EXT] Re: [Ntp] Consensus call: NTPv5 and leap second smearing

I wholly concur with Paul's view on this.

Kind regards,
David Venhoek

On Thu, Jun 29, 2023 at 2:54 AM Paul Gear
<ntp=40libertysys.com.au@dmarc.ietf.org> wrote:
>
> 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
>
> _______________________________________________
> 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