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

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Mon, 26 September 2022 06:47 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
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 636E8C1522D5; Sun, 25 Sep 2022 23:47:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.908
X-Spam-Level:
X-Spam-Status: No, score=-1.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 h_rHBkaKxGSx; Sun, 25 Sep 2022 23:47:00 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf8]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3A34C1524BF; Sun, 25 Sep 2022 23:46:58 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 684106000050; Mon, 26 Sep 2022 08:46:54 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id 7D31E600004D; Mon, 26 Sep 2022 08:46:52 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 26 Sep 2022 08:46:52 +0200
Message-Id: <63314ADA020000A10004E283@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.1
Date: Mon, 26 Sep 2022 08:46:50 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: jrmii@isc.org, jack.burbank@jhuapl.edu, william.kasch@jhuapl.edu, takashi.nakamoto@nao.ac.jp, rfc-editor@rfc-editor.org, mills@udel.edu
Cc: ek.ietf@gmail.com, The IESG <iesg@ietf.org>, "ntp@ietf.org" <ntp@ietf.org>
References: <20220926002359.A68EE4C956@rfcpa.amsl.com>
In-Reply-To: <20220926002359.A68EE4C956@rfcpa.amsl.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/WGwOJIamLgD0peZ-a8U2MuZWkJc>
Subject: [Ntp] Antw: [EXT] [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 06:47:05 -0000

Hi!

I just wonder whether "If we assume that the offset value follows the uniform
distribution" is a valid assumption; if it's not, then factor 5 can mean a
quite different thing.

Regards,
Ulrich

>>> RFC Errata System <rfc-editor@rfc-editor.org> schrieb am 26.09.2022 um
02:23 in
Nachricht <20220926002359.A68EE4C956@rfcpa.amsl.com>:
> 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
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp