[Ntp] [Errata Held for Document Update] RFC5905 (5604)

RFC Errata System <rfc-editor@rfc-editor.org> Mon, 26 September 2022 00:24 UTC

Return-Path: <wwwrun@rfcpa.amsl.com>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D545EC14CE2E; Sun, 25 Sep 2022 17:24:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.462
X-Spam-Level:
X-Spam-Status: No, score=-1.462 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, TO_NO_BRKTS_PCNT=2.497, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vP5wiNErOh5r; Sun, 25 Sep 2022 17:24:00 -0700 (PDT)
Received: from rfcpa.amsl.com (rfc-editor.org [50.223.129.200]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11123C14F744; Sun, 25 Sep 2022 17:23:59 -0700 (PDT)
Received: by rfcpa.amsl.com (Postfix, from userid 499) id A68EE4C956; Sun, 25 Sep 2022 17:23:59 -0700 (PDT)
To: takashi.nakamoto@nao.ac.jp, mills@udel.edu, jrmii@isc.org, jack.burbank@jhuapl.edu, william.kasch@jhuapl.edu
From: RFC Errata System <rfc-editor@rfc-editor.org>
Cc: ek.ietf@gmail.com, iesg@ietf.org, ntp@ietf.org, rfc-editor@rfc-editor.org
Content-Type: text/plain; charset="UTF-8"
Message-Id: <20220926002359.A68EE4C956@rfcpa.amsl.com>
Date: Sun, 25 Sep 2022 17:23:59 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/fEj2KsiSqJ-BMtas2dvN8X3HpGw>
Subject: [Ntp] [Errata Held for Document Update] RFC5905 (5604)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Network Time Protocol <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Sep 2022 00:24:04 -0000

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

--------------------------------------
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5604

--------------------------------------
Status: Held for Document Update
Type: Technical

Reported by: Takashi Nakamoto <takashi.nakamoto@nao.ac.jp>
Date Reported: 2019-01-15
Held by: Erik Kline (IESG)

Section: 11.2.3.

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

Corrected Text
--------------
                  | 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.

---

[INT AD notes]

See also https://mailarchive.ietf.org/arch/msg/ntp/Cbg3sOhChyfenYoj7UG5wCymFMU/ :

"""
...That makes some sense to me, but I'd say it really depends on the model of the clock and that's arbitrary...
"""


--------------------------------------
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 Protocols
Area                : Internet
Stream              : IETF
Verifying Party     : IESG