Re: [Ntp] Antw: I-D Action: draft-stenn-ntp-leap-smear-refid-02.txt

[Martin Burnicki <[e-mail]>]

Ulrich Windl wrote:
>>>> <[e-mail]> schrieb am 26.03.2019 um 01:41 in Nachricht
> <[e-mail]>:
> 
>> A New Internet‑Draft is available from the on‑line Internet‑Drafts
> directories.
>> This draft is a work item of the Network Time Protocol WG of the IETF.
>>
>>         Title           : Network Time Protocol Leap Smear REFID
>>         Author          : Harlan Stenn
>> 	Filename        : draft‑stenn‑ntp‑leap‑smear‑refid‑02.txt
>> 	Pages           : 5
>> 	Date            : 2019‑03‑25
>>
>> Abstract:
>>    Leap Seconds are part of UTC.  NTP timestamps are based on POSIX
>>    timestamps, which require each day to have exactly 86,400 seconds per
>>    day.  Some applications and environments choose to "smear" leap
>>    second corrections over a period that can last up to 24 hours' time,
>>    and implement NTP servers that offer smeared time to clients asking
>>    them for the time.
>>
>>    Both NTP clients and operators have no current way to tell if an NTP
>>    server is offering leap‑smeared time or not.  This is a problem.
> 
> What about "...eared time or not, causing problems."?
> Does it make sense to distinquish between clients and operators? I mean most
> RFCs do not deal with problems humans may have: If the client (software) is
> fixed, the operator should be happy, too ;-)

The basic idea with leap second smearing was to hide the leap second
from the clients, so that the clients are spoofed and don't even notice
when a leap second occurs.

In my opinion it's totally up to the operators to select smearing
servers for clients that are to be spoofed because they can't handle a
leap second correctly, or run applications that are confused if the
system time steps back by 1 s because a leap second is inserted, or
select "normal" servers for clients that can handle a leap second properly


>>
>>    Similarly, an NTP server may choose to offer leap‑smeared time to
>>    clients that do not appear to know that a leap event is in‑process.
>>    This is a problem.
> 
> Maybe add the kind of problem to the abstract: The frequency correction may
> get confused, and an additional leap second might be applied in non-smear-aware
> clients.
> 
>>
>>    This proposal offers a mechanism that provides a simple and clean
>>    solution to problems, by giving a way that clients (and operators)
>>    can trivially ask for leap‑smeared time and detect a server that is
>>    offering leap‑smeared time.
> 
> The more often I read about that, the less is like the "smear" term. Is
> another maybe more technical term possible?

I think smearing is the word that is used in most cases. If you choose a
different word here then folks who are less familiar with this kind of
stuff may not easily associate the RFC with leap second smearing.


Martin
-- 
Martin Burnicki

Senior Software Engineer

MEINBERG Funkuhren GmbH & Co. KG
Email: [e-mail]
Phone: [phone]
Linkedin: https://www.linkedin.com/in/martinburnicki/

Lange Wand 9, 31812 Bad Pyrmont, Germany
Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Managing Directors: Günter Meinberg, Werner Meinberg,
Andre Hartmann, Heiko Gerstung
Websites: https://www.meinberg.de  https://www.meinbergglobal.com
Training: https://www.meinberg.academy