Re: [Ntp] Consensus call: NTPv5 and leap second smearing (vote to support clearly defined and UNAMBIGUOUSLY implemented smearing procedure)

I concur mostly with Daniel's view here.

I do believe that we need to include "official" support for leap smearing, 
since prohibiting it is probably futile anyway.
But it is not enough to set a flag to notify a client that a server is 
using smearing - not if we don't know how exactly it implements that 
smearing.
What we need (if smearing is used) is a way to unambiguously convert and 
compare smeared time to non-smeared time.

I like option 3 of Daniel's suggestions: encode UTC as TAI plus smearing 
event information and offset information - but I think a duration for the 
event might be necessary, I'm afraid not everyone might see noon-to-noon 
as the only acceptable interval.

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        +49 (531) 592-4471
E-Mail:   kristof.teichel@ptb.de
__________________________________________

Von:    "Daniel Franke" <dfoxfranke@gmail.com>
An:     "Dieter Sibold" <dsibold.ietf@gmail.com>
Kopie:  "NTP WG" <ntp@ietf.org>
Datum:  02.07.2023 21:22
Betreff:        Re: [Ntp] Consensus call: NTPv5 and leap second smearing
Gesendet von:   "ntp" <ntp-bounces@ietf.org>

There are two things I care about:

1. The timestamp on the wire must be something that can be
unambiguously converted to UTC.
2. The packet must contain sufficient information for the client to be
able to apply a noon-to-noon smear if desired.

The NTPv4 behavior of repeating during a leap second insertion is
unacceptable, because this creates ambiguity. Any of the following
would be equally acceptable to me:

1. Timestamps are UTC, represented using two fields: a day number, and
time since midnight. Leap indicator bits MUST be set during precisely
noon to noon .
2. Timestamps MUST be smeared linearly noon-to-noon in proximity to a
leap event. The leap indicator MUST be set when and only when smearing
is in progress.
3. Timestamps are TAI, and information elsewhere in the packet provides:
    a. The TAI time at which the last-announced leap event begins (may
be past, present, or future)
    b. The direction of the event (insertion or deletion)
    c. The TAI-UTC offset at the completion of this event

1 and 2 are perfectly equivalent in what information they provide. 3
is more informative, and therefore nicer for the client but harder for
the server, because it has to have the extra information available.

On Wed, Jun 28, 2023 at 3:56?PM Dieter Sibold <dsibold.ietf@gmail.com> 
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?
>
>
>
> Greetings
> Karen and Dieter_______________________________________________
> 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