Network Time Protocol Leap Smear REFID
draft-stenn-ntp-leap-smear-refid-02
Document | Type |
Expired Internet-Draft
(ntp WG)
Expired & archived
|
|
---|---|---|---|
Author | Harlan Stenn | ||
Last updated | 2019-09-26 (Latest revision 2019-03-25) | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Intended RFC status | (None) | ||
Formats | |||
Additional resources | Mailing list discussion | ||
Stream | WG state | Candidate for WG Adoption | |
Document shepherd | (None) | ||
IESG | IESG state | Expired | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
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. 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. 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.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)