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

[Harlan Stenn <[e-mail]>]

On 3/26/2019 12:16 AM, 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."?

I don't understand your question.

> 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 ;-)

I think so.  An NTP instance may care very much about the time it wants
to follow during a leap second.  And operators separately want to be
able to quickly and clearly see what systems are offering correct or
leap-smeared time.

>>    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.

Perhaps to the Introduction.  I just spent a lot of time and effort
making the Abstracts much shorter, as people complained that there was
too much information in there.
>>
>>    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?

It's the only term I've ever seen used.

Thanks for your comments.

H
--
> Regards,
> Ulrich
> 
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft‑stenn‑ntp‑leap‑smear‑refid/ 
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft‑stenn‑ntp‑leap‑smear‑refid‑02 
>> https://datatracker.ietf.org/doc/html/draft‑stenn‑ntp‑leap‑smear‑refid‑02 
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft‑stenn‑ntp‑leap‑smear‑refid‑02 
>>
>>
>> Please note that it may take a couple of minutes from the time of
> submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet‑Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet‑drafts/ 
>>
>> _______________________________________________
>> ntp mailing list
>> [e-mail] 
>> https://www.ietf.org/mailman/listinfo/ntp 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn, Network Time Foundation
http://nwtime.org - be a Member!