Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (4504)

From: Brian Haberman <[email-masked]>
Date: Thu, 15 Oct 2015 14:46:19 -0400

NTP'ers,
     Thoughts on this erratum?  I have always worked with the view that
the leap second is inserted at the end of a month.  If that is correct,
the correction should be in the figure and not in the text.

Thoughts?

Regards,
Brian

On 10/15/15 9:06 AM, RFC Errata System wrote:
> The following errata report has been submitted for RFC5905,
> "Network Time Protocol Version 4: Protocol and Algorithms Specification".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=5905&eid=4504
> 
> --------------------------------------
> Type: Technical
> Reported by: Miroslav Lichvar <[email-masked]>
> 
> Section: 7.2
> 
> Original Text
> -------------
>    LI Leap Indicator (leap): 2-bit integer warning of an impending leap
>    second to be inserted or deleted in the last minute of the current
>    month with values defined in Figure 9.
> 
>            +-------+----------------------------------------+
>            | Value | Meaning                                |
>            +-------+----------------------------------------+
>            | 0     | no warning                             |
>            | 1     | last minute of the day has 61 seconds  |
>            | 2     | last minute of the day has 59 seconds  |
> 
> 
> Corrected Text
> --------------
>    LI Leap Indicator (leap): 2-bit integer warning of an impending leap
>    second to be inserted or deleted in the last minute of the current
>    day with values defined in Figure 9.
> 
>            +-------+----------------------------------------+
>            | Value | Meaning                                |
>            +-------+----------------------------------------+
>            | 0     | no warning                             |
>            | 1     | last minute of the day has 61 seconds  |
>            | 2     | last minute of the day has 59 seconds  |
> 
> 
> Notes
> -----
> There is an inconsistency (day vs month) between the LI description and the description of values in the Figure 9.  Few paragraphs before that text there is: Except for a minor variation when using the IPv6 address family, these fields are backwards compatible with NTPv3.
> 
> If it was month instead of day it would not be compatible with RFC 1305 (NTPv3) and RFC 4330 (SNTPv4), which were obsoleted by RFC 5905.
> 
> Instructions:
> -------------
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party (IESG)
> can log in to change the status and edit the report, if necessary. 
> 
> --------------------------------------
> RFC5905 (draft-ietf-ntp-ntpv4-proto-13)
> --------------------------------------
> Title               : Network Time Protocol Version 4: Protocol and Algorithms Specification
> Publication Date    : June 2010
> Author(s)           : D. Mills, J. Martin, Ed., J. Burbank, W. Kasch
> Category            : PROPOSED STANDARD
> Source              : Network Time Protocol
> Area                : Internet
> Stream              : IETF
> Verifying Party     : IESG
> 

_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: RFC Errata System <[email-masked]>
Date: Thu, 15 Oct 2015 06:06:05 -0700 (PDT)

Section: 7.2

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------

---

From: Steve Allen <[email-masked]>
Date: Thu, 15 Oct 2015 15:46:43 -0700

> the correction should be in the figure and not in the text.

The specification for leap seconds in UTC is ITU-R Recommendation
TF.460-6 dated 2002.  The original form of that recommendation was
CCIR Recommendation 460 dated 1970, and in that original form there
were no rules for the application of leap seconds.

The first revision was CCIR Recommendation 460-1 which was produced
during 1974-07 and went into force as of 1975-01-01.  Starting from
this the text of the recommendation has included
    A positive or negative leap-second should be the last second of a
    UTC month, but first preference should be given to the end of
    December and June, and second preference to the end of March and
    September.
In practice the only months which have ever been used are June
and December.

NTP implementations which want to avoid spurious leap seconds may want
to restrict those months to June and December until further notice.

During the past couple of leap seconds some agencies have wished that
the rules might change to allow the application of leap seconds on
weekends rather than on a month boundary in the middle of a business
week, but no such proposal has been seen from the ITU-R.
The ITU-R will be considering other proposals for this issue as part
of Agenda Item 1.14 for the WRC-15 which will happen next month.

Until the ITU-R makes a change, if the NTP spec is intended to conform
with the recommendations for the radio broadcast time signals then the
leap second should only come at the end of a month.

--
Steve Allen                 <[email-masked]>               WGS-84 (GPS)
UCO/Lick Observatory--ISB   Natural Sciences II, Room 165   Lat  +36.99855
1156 High Street            Voice: +1 831 459 3046          Lng -122.06015
Santa Cruz, CA 95064        http://www.ucolick.org/~sla/    Hgt +250 m
_______________________________________________
ntpwg mailing list
[email-masked]
http://lists.ntp.org/listinfo/ntpwg

---

From: Greg Dowd <[email-masked]>
Date: Fri, 16 Oct 2015 01:38:31 +0000

I believe this suggested correction is wrong.  I know the expansion of the propagation time for leap indicator was intentional, originally driven by the modem reference clock drivers using poll intervals which could exceed 24 hours.  In mailing list discussions in the distant past, Mills indicated that the NTP protocol was simply there to relay the information as soon as it was available, with the end clocks responsible for gating the event.  In practice in the open source distro, I do see a lot of code for controlling leap info propagation windows, and I recognize that there are issues in propagating leap to other time distributions networks (IRIG, PTP, etc), but it seems useful to propagate the leap bits as soon as we know about them.  Sometimes, like with IRIG, it is only 10 minutes before the event.  Some, like GNSS, are months in advance.  

There is a significant amount of work being down with propagating leap second tables which will likely overlap with the NTP code in the near future.  Does the group feel that the code required to find the end of the current month is onerous?  That would probably be a strong motivator for restricting the propagation time window, even if the longer clock chains would have a limited time to settle.

On a slightly different note, I have never lost my belief that there is a gap in the current definition of the leap second event.  Because the leap second insertions cause the timescale to jump backwards in NTP timescale definitions (ignoring smear techniques), my original interpretation was that the leap second bits MUST be cleared at the boundary event to provide a non-ambiguous differentiation between the leap event and the following repeated NTP timescale second.  Dr. Mills disagreed due to the above mentioned logic, which was that NTP was merely a synch protocol and that timestamps could not be compared in this interval using this data.  His position was that the leap bits would simply be cleared by the next cycle of clock update following poll update of the selected reference clock (and cluster voters for stratum higher than 1).

I would vote to clarify the "up to a month" propagation window as appropriate.  

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On Behalf Of RFC Errata System
Sent: Thursday, October 15, 2015 6:06 AM
To: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [ntpwg] [Technical Errata Reported] RFC5905 (4504)

EXTERNAL EMAIL

The following errata report has been submitted for RFC5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification".

Section: 7.2

Original Text
-------------

Corrected Text
--------------

Notes
-----

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary.

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 16 Oct 2015 08:01:05 +0200

> the correction should be in the figure and not in the text.

Yes, leap seconds are inserted at the end of a month, but as Greg
explains, the question here is if servers should be allowed to set the
Leap Indicator sooner than on the last day and clients be required to
check what day it is.

While it would be definitely better if it was always month (or rather
maybe two weeks to avoid the old problem with leap bit getting stuck
after a leap second in a feedback loop), I think there are several
pointers that suggest the intention in the RFC was day and not month.

In RFC 1305 (and also RFC 4330) it was day and RFC 5905 says this
about compatibility of the fields:

  Except for a minor variation when using the IPv6 address
  family, these fields are backwards compatible with NTPv3.

If the interval was whole month, the LI field would not be compatible
and this text would need to warn about it. Clients that don't check
what day it is would need to be fixed.

The reference implementation sets the leap bit only on the last day
since 4.2.5p110, released on Jan 26 2008.

-- 
Miroslav Lichvar

---

From: Greg Dowd <[email-masked]>
Date: Fri, 16 Oct 2015 06:13:19 +0000

I think the last statement is not complete.  I think the open source implementation only sets the leap bits on the last day for lower strata but passes them through directly when received from a reference clock driver.

-----Original Message-----
From: ntpwg [mailto:ntpwg-bounces+greg.dowd=[email-masked]] On Behalf Of Miroslav Lichvar
Sent: Thursday, October 15, 2015 11:01 PM
To: [email-masked]
Subject: Re: [ntpwg] [Technical Errata Reported] RFC5905 (4504)

EXTERNAL EMAIL

On Thu, Oct 15, 2015 at 02:46:19PM -0400, Brian Haberman wrote:
> NTP'ers,
>      Thoughts on this erratum?  I have always worked with the view 
> that the leap second is inserted at the end of a month.  If that is 
> correct, the correction should be in the figure and not in the text.

Yes, leap seconds are inserted at the end of a month, but as Greg explains, the question here is if servers should be allowed to set the Leap Indicator sooner than on the last day and clients be required to check what day it is.

While it would be definitely better if it was always month (or rather maybe two weeks to avoid the old problem with leap bit getting stuck after a leap second in a feedback loop), I think there are several pointers that suggest the intention in the RFC was day and not month.

In RFC 1305 (and also RFC 4330) it was day and RFC 5905 says this about compatibility of the fields:

If the interval was whole month, the LI field would not be compatible and this text would need to warn about it. Clients that don't check what day it is would need to be fixed.

The reference implementation sets the leap bit only on the last day since 4.2.5p110, released on Jan 26 2008.

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 16 Oct 2015 08:58:43 +0200

> I think the last statement is not complete.  I think the open source implementation only sets the leap bits on the last day for lower strata but passes them through directly when received from a re…

Any pointers?

I don't think that's the case, at least not with 4.2.6 and 4.2.8.

I remember some bugs with reference clocks and leap bits being set on
the last day of a wrong month, and also some bugs about leap not
being set from reference clocks at all, but nothing about setting leap
days before the end of the month.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 16 Oct 2015 09:32:14 +0200

>>> Brian Haberman <[email-masked]> schrieb am 15.10.2015 um 20:46 in
> the correction should be in the figure and not in the text.

Hi!

Well, up to now the end of the day was also the end of the month. Day seems to be the smallest possible granularity where the LI will work. I think part of the problem was to mix the semantics of what LI means (process leap second at the end of the day) and when the LI will/should be propagated. If the semantics is to process at the end of the current month, LI could be set days before; however if the semantics is to process at the end of the current day, the LI cannot be set earlier than on the current day. When talking about days, mabe emphasise that we are talking about "UTC (NTP) days".

I think in the past it was quite unclear when the LI should be set; you could set as early as you know, but then each client would have to know the rules when to process it. To take most "need to know" away from the client, the LI should be set on the correct UTC day only IMHO.

Regards,
Ulrich

>> There is an inconsistency (day vs month) between the LI description and the 
> description of values in the Figure 9.  Few paragraphs before that text there 
> is: Except for a minor variation when using the IPv6 address family, these 
> fields are backwards compatible with NTPv3.
>> 
>> If it was month instead of day it would not be compatible with RFC 1305 
> (NTPv3) and RFC 4330 (SNTPv4), which were obsoleted by RFC 5905.
>> 
>> Instructions:
>> -------------

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 16 Oct 2015 10:01:38 +0200

>>> "Ulrich Windl" <[email-masked]> schrieb am 16.10.2015 um
09:32 in Nachricht <[email-masked]>:
> Well, up to now the end of the day was also the end of the month. Day seems 
> to be the smallest possible granularity where the LI will work. I think part 
> of the problem was to mix the semantics of what LI means (process leap second 
> at the end of the day) and when the LI will/should be propagated. If the 
> semantics is to process at the end of the current month, LI could be set days 
> before; however if the semantics is to process at the end of the current day, 
> the LI cannot be set earlier than on the current day. When talking about 
> days, mabe emphasise that we are talking about "UTC (NTP) days".
> 
> I think in the past it was quite unclear when the LI should be set; you 
> could set as early as you know, but then each client would have to know the 
> rules when to process it. To take most "need to know" away from the client, 
> the LI should be set on the correct UTC day only IMHO.

When reading my own thoughts, I became aware that leap seconds actually required each client to convert the NTP timescale to a calender timescale (is there any other part except certificate checking that needs it?). Wouldn't it be much easier to have an extension field that says at what NTP time a leap second should be processed? Then the question "end of the day or end of the month?" would be gone.

---

From: Miroslav Lichvar <[email-masked]>
Date: Fri, 16 Oct 2015 08:15:20 +0200

On Fri, Oct 16, 2015 at 01:38:31AM +0000, Greg Dowd wrote:
> I believe this suggested correction is wrong.  I know the expansion of the propagation time for leap indicator was intentional, originally driven by the modem reference clock drivers using poll intervals which could exceed 24 hours.  In mailing list discussions in the distant past, Mills indicated that the NTP protocol was simply there to relay the information as soon as it was available, with the end clocks responsible for gating the event.  

I agree it would be useful if it was set sooner than the last day, but
it would be an incompatible change in the protocol. It seems it was
David Mills himself who fixed the reference implementation to set the
leap bits only on last day.

See the diff here:
https://github.com/ntp-project/ntp/commit/b8f6fecf06b35fe85329f98ee69528c61c0008b2#diff-dec475a75e026ddd7b34a642d99ead81L344

The sys_leap variable was set up to 28 days before the end of the
month, but after that change it's now just one day.

> There is a significant amount of work being down with propagating leap second tables which will likely overlap with the NTP code in the near future.  Does the group feel that the code required to f…

To determine the day of the month on a normal OS is just a matter of
calling gmtime() or similar. On some 8-bit controller with very
limited memory that could be a problem I guess.

Anyway, there is at least one implementation that I know that supports
leap seconds, but does not check what day it is and would be need to
be fixed if servers were allowed to set the bit earlier.

---

From: "Ulrich Windl" <[email-masked]>
Date: Fri, 16 Oct 2015 09:54:26 +0200

>>> Greg Dowd <[email-masked]> schrieb am 16.10.2015 um 03:38 in Nachricht
<[email-masked]>:
> I believe this suggested correction is wrong.  I know the expansion of the 
> propagation time for leap indicator was intentional, originally driven by the 
> modem reference clock drivers using poll intervals which could exceed 24 
> hours.  In mailing list discussions in the distant past, Mills indicated that 
> the NTP protocol was simply there to relay the information as soon as it was 
> available, with the end clocks responsible for gating the event.  In practice 
> in the open source distro, I do see a lot of code for controlling leap info 
> propagation windows, and I recognize that there are issues in propagating 
> leap to other time distributions networks (IRIG, PTP, etc), but it seems 
> useful to propagate the leap bits as soon as we know about them.  Sometimes, 
> like with IRIG, it is only 10 minutes before the event.  Some, like GNSS, are 
> months in advance.  

For NTP, a necessary condition seems to be this one:
The LI has to announced at least "maxpoll * max_startum_difference" seconds before the event takes place.
That is if you poll once a day, and you are at stratum 3, it may need three polling cycles (not counting package loss) for the LI to get propagated from statum-0 to statum-3 (ignoring the fact that refclocks are polled rather rapidly in practice).

> 
> There is a significant amount of work being down with propagating leap 
> second tables which will likely overlap with the NTP code in the near future. 
>  Does the group feel that the code required to find the end of the current 
> month is onerous?  That would probably be a strong motivator for restricting 
> the propagation time window, even if the longer clock chains would have a 
> limited time to settle.

Another problem is the "Majority treatment" of LI: Will a new LI state be accepted if one server reports it, it a majority agrees on the new LI state, or if all servers agree?

> 
> On a slightly different note, I have never lost my belief that there is a 
> gap in the current definition of the leap second event.  Because the leap 
> second insertions cause the timescale to jump backwards in NTP timescale 
> definitions (ignoring smear techniques), my original interpretation was that 
> the leap second bits MUST be cleared at the boundary event to provide a 
> non-ambiguous differentiation between the leap event and the following 
> repeated NTP timescale second.  Dr. Mills disagreed due to the above 
> mentioned logic, which was that NTP was merely a synch protocol and that 
> timestamps could not be compared in this interval using this data.  His 
> position was that the leap bits would simply be cleared by the next cycle of 
> clock update following poll update of the selected reference clock (and 
> cluster voters for stratum higher than 1).

It seems the LI state will not be canged before the next polling interval, so clients may have some obsolete LI flag. I think clients must know whether they applied the correction on the proper day or not, and if they implied it, they should ignore the obsolete LI state. Unfortunately leap second processing is not idempotent unless you apply the current offset to TAI.

Regards,
Ulrich

> To: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; [email-masked] 
> The following errata report has been submitted for RFC5905, "Network Time 
> Protocol Version 4: Protocol and Algorithms Specification".
> 
> This erratum is currently posted as "Reported". If necessary, please use 
> "Reply All" to discuss whether it should be verified or rejected. When a 
> decision is reached, the verifying party (IESG) can log in to change the 
> status and edit the report, if necessary.
>

---

From: Danny Mayer <[email-masked]>
Date: Fri, 16 Oct 2015 10:26:25 -0400

I agree with Greg. If there is a clarification/correction to be made it
should be the last minute of the current *UTC* month. The leap second is
inserted/deleted based on UTC time and not local time.

Danny
On 10/15/2015 9:38 PM, Greg Dowd wrote:
> I believe this suggested correction is wrong. I know the expansion
> of
the propagation time for leap indicator was intentional, originally
driven by the modem reference clock drivers using poll intervals which
could exceed 24 hours. In mailing list discussions in the distant past,
Mills indicated that the NTP protocol was simply there to relay the
information as soon as it was available, with the end clocks responsible
for gating the event. In practice in the open source distro, I do see a
lot of code for controlling leap info propagation windows, and I
recognize that there are issues in propagating leap to other time
distributions networks (IRIG, PTP, etc), but it seems useful to
propagate the leap bits as soon as we know about them. Sometimes, like
with IRIG, it is only 10 minutes before the event. Some, like GNSS, are
months in advance.
> There is a significant amount of work being down with propagating
second tables which will likely overlap with the NTP code in the near
future. Does the group feel that the code required to find the end of
the current month is onerous? That would probably be a strong motivator
for restricting the propagation time window, even if the longer clock
chains would have a limited time to settle.
> 
> On a slightly different note, I have never lost my belief that there
is a gap in the current definition of the leap second event. Because the
leap second insertions cause the timescale to jump backwards in NTP
timescale definitions (ignoring smear techniques), my original
interpretation was that the leap second bits MUST be cleared at the
boundary event to provide a non-ambiguous differentiation between the
leap event and the following repeated NTP timescale second. Dr. Mills
disagreed due to the above mentioned logic, which was that NTP was
merely a synch protocol and that timestamps could not be compared in
this interval using this data. His position was that the leap bits would
simply be cleared by the next cycle of clock update following poll
update of the selected reference clock (and cluster voters for stratum
higher than 1).

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 20 Oct 2015 11:28:17 +0200

> That is if you poll once a day, and you are at stratum 3, it may need three polling cycles (not counting package loss) for the LI to get propagated from statum-0 to statum-3 (ignoring the fact that…

The reference implementation may delay the clock and leap updates
quite a bit (up to 7 samples skipped in the clock filter), so the time
needed in advance to distribute the leap status to all nodes may be
actually 8 times longer than that. If the leap status was updated
independently from clock updates, it would probably spread much
faster.

---

From: Miroslav Lichvar <[email-masked]>
Date: Tue, 20 Oct 2015 11:29:41 +0200

> inserted/deleted based on UTC time and not local time.

Clarification that leap seconds are inserted in the last UTC minute of
the month and not local time could be helpful.

As for extending the interval covered by the Leap Indicator in NTP
packets, I think it should wait until NTPv5 to not break
compatibility.