RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 13 records.

Status: Verified (4)

RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010

Source of RFC: ntp (int)

Errata ID: 3007
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Danny Mayer
Date Reported: 2011-10-28
Verifier Name: Brian Haberman
Date Verified: 2012-04-27

Section 7.4 says:

b.  For kiss code RATE, the client MUST immediately reduce its
       polling interval to that server and continue to reduce it each
       time it receives a RATE kiss code.

It should say:

b.  For kiss code RATE, the client MUST immediately increase its
       polling interval to that server and continue to increase it each
       time it receives a RATE kiss code.

Notes:

The client needs to poll the server for new timestamps less often

Errata ID: 3627
Status: Verified
Type: Technical
Publication Format(s) : TEXT

Reported By: Tal Mizrahi
Date Reported: 2013-05-17
Verifier Name: Brian Haberman
Date Verified: 2014-05-16

Section 7.5 says:

In NTPv4, one or more extension fields can be inserted after the 
header and before the MAC, which is always present when an extension 
field is present.

It should say:

In NTPv4, one or more extension fields can be inserted after the 
header and before the MAC, if a MAC is present. If a MAC is not 
present, one or more extension fields can be inserted after the 
header, according to the following rules:
o If the packet includes a single extension field, the length of the 
  extension  field MUST be at least 7 words, i.e., at least 28 octets.
o If the packet includes more than one extension field, the length of 
  the last extension field MUST be at least 28 octets. The length of 
  the other extension fields in this case MUST be at least 16 octets 
  each.

Notes:

The usage of NTP extension fields without authentication is aligned with Section 10 of RFC 5906:

The extension field parser initializes a pointer to the first octet beyond the NTP packet header and calculates the number of octets remaining to the end of the packet If the remaining length is 20 (128-bit digest plus 4-octet key ID) or 22 (160-bit digest plus 4-octet key ID), the remaining data are the MAC and parsing is complete. If the remaining length is greater than 22, an extension field is present. If the remaining length is less than 8 or not a multiple of 4, a format error has occurred and the packet is discarded; otherwise, the parser increments the pointer by the extension field length and then uses the same rules as above to determine whether a MAC is present or another extension field.

Errata ID: 4019
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Teruaki Kitasuka
Date Reported: 2014-06-20
Verifier Name: Brian Haberman
Date Verified: 2014-06-20

Section 11.2.1 says:

   An
   example of this calculation is shown by the rootdist() routine in
   Appendix A.5.1.1.

It should say:

   An
   example of this calculation is shown by the root_dist() routine in
   Appendix A.5.5.2.

Notes:

No rootdist() routine is in Appendix. root_dist() appears in Appendix A.5.5.2.

Errata ID: 4121
Status: Verified
Type: Editorial
Publication Format(s) : TEXT

Reported By: Marina Gertsvolf
Date Reported: 2014-09-23
Verifier Name: Brian Haberman
Date Verified: 2014-10-21

Section 8 says:

In the exchange above, a packet is duplicate or
   replay if the transmit timestamp t3 in the packet matches the org
   state variable T3. 

It should say:

In the exchange above, a packet is duplicate or
   replay if the transmit timestamp t3 in the packet matches the org
   state variable. 

Notes:

The org state variable for peer A has not yet been assigned the value T3.

Status: Reported (9)

RFC 5905, "Network Time Protocol Version 4: Protocol and Algorithms Specification", June 2010

Source of RFC: ntp (int)

Errata ID: 4504
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Miroslav Lichvar
Date Reported: 2015-10-15

Section 7.2 says:

   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  |

It should say:

   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.

Errata ID: 5020
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Ferenc Wágner
Date Reported: 2017-05-15

Section 8 says:

theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T3-T4)]

It should say:

theta = T(B) - T(A) = 1/2 * [(T2-T1) + (T4-T3)]

Notes:

The corresponding code line in A.5.1.1. agrees with this correction:

offset = (LFP2D(r->rec - r->org) + LFP2D(r->dst - r->xmt)) / 2;

taking Figure 7 into account:

| org | T1 | origin timestamp |
| rec | T2 | receive timestamp |
| xmt | T3 | transmit timestamp |
| dst | T4 | destination timestamp |

Errata ID: 5600
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Takashi Nakamoto
Date Reported: 2019-01-15

Section 10. says:

   Let the first stage offset in the sorted list be theta_0; then, for
   the other stages in any order, the jitter is the RMS average

                          +-----                 -----+^1/2
                          |  n-1                      |
                          |  ---                      |
                  1       |  \                     2  |
      psi   =  -------- * |  /    (theta_0-theta_j)   |
                (n-1)     |  ---                      |
                          |  j=1                      |
                          +-----                 -----+

It should say:

   Let the first stage offset in the sorted list be theta_0; then, for
   the other stages in any order, the jitter is the RMS average

               +-----                             -----+^1/2
               |              n-1                      |
               |              ---                      |
               |    1         \                     2  |
      psi   =  | -------- *   /    (theta_0-theta_j)   |
               |  (n-1)       ---                      |
               |              j=1                      |
               +-----                             -----+

Notes:

The formula to calculate jitter "psi" in section "10. Clock Filter Algorithm" is incorrect, and also inconsistent with the formulate to calculate "psi_s" in section "11.2.2. Cluster Algorithm".

"psi" is defined as RMS average, so the term 1/(n-1) should be within [ ]^1/2 block.

Errata ID: 5601
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Takashi Nakamoto
Date Reported: 2019-01-15

Section 11.2.3. says:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon + |
                  |                 p.psi + PHI * (s.t - p.t) |
                  |                 + |THETA|                 |
                  | s.refid     <-- p.refid                   |
                  | s.reftime   <-- p.reftime                 |
                  | s.t         <-- p.t                       |
                  +-------------------------------------------+

                    Figure 25: System Variables Update

   There is an important detail not shown.  The dispersion increment
   (p.epsilon + p.psi + PHI * (s.t - p.t) + |THETA|) is bounded from
   below by MINDISP.

It should say:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon + |
                  |                 p.psi + PHI * (t_s - p.t) |
                  |                 + |THETA|                 |
                  | s.refid     <-- p.refid                   |
                  | s.reftime   <-- p.reftime                 |
                  | s.t         <-- p.t                       |
                  +-------------------------------------------+

                    Figure 25: System Variables Update

   where t_s is the time when the system variables are updated.
   There is an important detail not shown.  The dispersion increment
   (p.epsilon + p.psi + PHI * (t_s - p.t) + |THETA|) is bounded from
   below by MINDISP.

Notes:

In the same section, it is said that "By rule, an update is discarded if its time of arrival p.t is not strictly later than the last update used s.t." This means that p.t > s.t when the system variable is updated. Hence, (s.t - p.t) is negative. It may lead to a negative dispersion, but, by definition, the dispersion cannot be negative. So, the original formula should be wrong.

Because the dispersion is defined as the value that grows at constant rate PHI, s.rootdisp should be

s.rootdisp <-- p.epsilon_r + p.epsilon + p.psi + PHI * (t_s - p.t) + |THETA|

where t_s is the time when the system variables are updated. The symbol t_s is arbitrary because it is not defined in other places.

Errata ID: 5604
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Takashi Nakamoto
Date Reported: 2019-01-15

Section 11.2.3. says:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon + |
                  |                 p.psi + PHI * (s.t - p.t) |
                  |                 + |THETA|                 |

It should say:

                  | s.rootdisp  <-- p.epsilon_r + p.epsilon   |
                  |                 + 5 * p.psi +             |
                  |                 + PHI * (s.t - p.t)       |
                  |                 + |THETA|                 |

Notes:

In addition to the correction proposed in Errata ID 5601, I think that the formula to calculate the dispersion should be revised. The term "p.psi" should be multiplied by not one, but a larger value.

This is because the dispersion is defined as the statistics that represent the maximum error, so when it is calculated, it should take into account the maximum errors in the offset estimation. However, the jitter p.psi is defined as the RMS average of the offset values theta_j relative to theta_0, so the term "p.psi" does not represent the maximum error caused by the distribution of the offset values.

If we assume that the offset value follows the uniform distribution, the error bound is represented as sqrt(3) * p.psi. So, at least, the term "p.psi" should be multiplied by sqrt(3). There is arbitrarity in choice of the distribution type, so depending on the distribution type the factor may change. For example, if the normal distribution is assumed, 5 * p.psi gives us 99.99994% confidence. Assuming that the system variable is updated every 16 seconds, the actual offset may be outside the range [theta_0 - 5 * p.psi, theta_0 + 5 * p.psi] approximately once a year. It should be sufficient for usual Internet applications, though someone may think that the factor "5" may not be sufficient depending on the application.

Errata ID: 5978
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: David Verbree
Date Reported: 2020-02-08

Section A.5.1.1. says:


    /*
        * Verify valid root distance.
        */
    if (r->rootdelay / 2 + r->rootdisp >= MAXDISP || p->reftime >
        r->xmt)
            return;                 /* invalid header values */

It should say:


    /*
        * Verify valid root distance.
        */
    if (p->rootdelay / 2 + p->rootdisp >= MAXDISP || p->reftime >
        r->xmt)
            return;                 /* invalid header values */

Notes:

The r->rootdelay and r->rootdisp are the received values not in double format and therefore, should not be compared against MAXDISP. Use the p->rootdelay and p->rootdisp instead which have already been converted to double via FP2D macro.

Errata ID: 4680
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Riccardo Brama
Date Reported: 2016-04-29

Section 6, Fig 3 says:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Offset                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                           Fraction                            |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              NTP Date Format

It should say:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Number                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           Era Offset                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                           Fraction                            +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                              NTP Date Format

Notes:

This allows to better appreciate only two 32b rows really form the Fraction part, leading to an overall type length of 128b instead of 160b as it could otherwise be misunderstood in the original figure.

Errata ID: 5104
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Denis Ovsienko
Date Reported: 2017-08-30

Section 7.3, Fig 8 says:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                            dgst (128)                         |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

It should say:

      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Key Identifier                       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                       Message Digest (128)                    |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Notes:

As the text before the figure explains, the last field is called "Message Digest", which is consistent with the rest of the document. In this document "dgst" and "mac" mean two protocol variables associated with this packet field.

Errata ID: 5189
Status: Reported
Type: Editorial
Publication Format(s) : TEXT

Reported By: Marcel Telka
Date Reported: 2017-11-28

Section 6 says:

   | 31 Dec 1999 | 51,543     | 0   | 3,155,587,200 | Last day 20th    |
   |             |            |     |               | Century          |

It should say:

   | 31 Dec 2000 | 51,909     | 0   | 3,187,209,600 | Last day 20th    |
   |             |            |     |               | Century          |

Notes:

20th Century was from 1901 to 2000.

Report New Errata