%% You should probably cite draft-stenn-ntp-leap-smear-refid-02 instead of this revision. @techreport{stenn-ntp-leap-smear-refid-00, number = {draft-stenn-ntp-leap-smear-refid-00}, type = {Internet-Draft}, institution = {Internet Engineering Task Force}, publisher = {Internet Engineering Task Force}, note = {Work in Progress}, url = {https://datatracker.ietf.org/doc/draft-stenn-ntp-leap-smear-refid/00/}, author = {Harlan Stenn}, title = {{Network Time Protocol Leap Smear REFID}}, pagetotal = 5, year = 2016, month = mar, day = 15, abstract = {RFC 5905 {[}RFC5905{]} and earlier versions of NTP are the overwhelming method of distributing time on networks. Leap Seconds will continue to exist for a good number of years' time, and since the timescale mandated by POSIX effectively ignores any instances where there are not 86,400 seconds' time in a day, something must be done to reliably synchronize clocks during the application of leap second corrections. One mechanism for dealing with the application that has recently become visible is to apply the leap second using a "smear", where the time reported by leap-second aware servers is gradually adjusted so there is no major disruption to time synchronization when processing a leap second. While leap second processing can be expected to be properly handled by up-to-date software and by time servers, there are large numbers of out-of-date software installations and client systems that are just not able to properly handle a leap second correction. This proposal offers a way for a system to generate a REFID that indicates that the time being supplied in the NTP packet already contains an amount of leap smear correction, and what that amount is.}, }