[ntpwg] Further to the timestamping issue

[TSG]

All you need is a leap-second listener protocol to make this work. EIRS 
would support that I bet too.

Todd

----- Original Message ----- 
From: "David L. Mills" <mills at udel.edu>
To: "NTP Working Group" <ntpwg at lists.ntp.org>
Sent: Thursday, June 19, 2008 10:16 AM
Subject: Re: [ntpwg] Further to the timestamping issue


> Rob,
>
> I don't understand your comment. The IERS can surely announce any future
> leap epoch, but from the current draft of the relevant ITU-T and NIST
> recommendation, there are no provisions with public dissemination means
> to announce other than in June or December. The WWV/H/B and ACTS leap
> warning indicators apply at the end of the current month, which is how
> the leap warning bits are interpreted in NTP. From past experience,
> server leap warning bits have had less than perfect reliability and
> represent a possible vulnerability. This is why the upstratum servers
> vote on the leap warning bits and are  reluctant to set their own leap
> warning bits other than on the day of the leap.
>
> Dave
>
> Rob Seaman wrote:
>
>> On Jun 19, 2008, at 8:04 AM, TSG wrote:
>>
>>>> My fundamental point is that UTC permits much more flexible leap
>>>> second scheduling than has been demonstrated to date. NTP might have
>>>> to adapt to this in the future.
>>>
>>> Not if its used in proper auditing of IT operations. Leap Seconds
>>> are a nightmare for logging systems because they require special
>>> handling and integration across an entire entitie's operations.
>>
>>
>> I don't discount auditing requirements, although it isn't clear that
>> NTP's requirements are the same as your company's. That the Earth
>> orbits the Sun and has a large nearby Moon are a bit more fundamental
>> than either. We can disagree about the implications of all sorts of
>> requirements. Basing a discussion on requirements is generally more
>> productive, however, than jumping directly into each other's nightmares.
>>
>> NTP already provides special handling and integration for the case of
>> leap seconds. That being the case, it certainly would be appropriate
>> to update the system should the underlying UTC leap second
>> implementation ever change. This is not imminent, but seems
>> ultimately more likely than the current fad for advocating the
>> elimination of leap seconds in a fruitless attempt to abandon mean
>> solar time.
>>
>> In any event, NTP either supports UTC or it doesn't. This is also a
>> requirement, whatever complications that causes elsewhere. Required
>> complexity is another name for "design".
>>
>> In short, UTC *already* permits multiple leap seconds to be announced
>> in advance. with an arbitrarily longer horizon than six months. NTP
>> systems *already* fail to implement the full complexity implicit in UTC.
>>
>> Rob Seaman
>> NOAO
>>
>> _______________________________________________
>> ntpwg mailing list
>> ntpwg at lists.ntp.org
>> https://lists.ntp.org/mailman/listinfo/ntpwg
>
>
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg