[Tsv-art] Antw: [EXT] Re: [Ntp] Tsvart last call review of draft-ietf-ntp-packet-timestamps-08

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Tue, 03 March 2020 08:11 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: tsv-art@ietfa.amsl.com
Delivered-To: tsv-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4463A1AD3; Tue, 3 Mar 2020 00:11:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfadCrYXv_7A; Tue, 3 Mar 2020 00:11:48 -0800 (PST)
Received: from mx3.uni-regensburg.de (mx3.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e79]) (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 B04013A1AD1; Tue, 3 Mar 2020 00:11:48 -0800 (PST)
Received: from mx3.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 41A0C600004D; Tue, 3 Mar 2020 09:11:46 +0100 (CET)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx3.uni-regensburg.de (Postfix) with ESMTP id 2F11D6000055; Tue, 3 Mar 2020 09:11:46 +0100 (CET)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 03 Mar 2020 09:11:46 +0100
Message-Id: <5E5E1140020000A100037815@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.2.0
Date: Tue, 03 Mar 2020 09:11:44 +0100
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: Tal Mizrahi <tal.mizrahi.phd@gmail.com>, ianswett@google.com
Cc: draft-ietf-ntp-packet-timestamps.all@ietf.org, last-call@ietf.org, "ntp@ietf.org" <ntp@ietf.org>, tsv-art@ietf.org
References: <158316762892.27374.16780761185123723332@ietfa.amsl.com> <11168_1583215605_5E5DF3F5_11168_1246_1_CABUE3X=nhuzy1UMEFr1tuJNw9hY_ewYHqoX4fCqp_ZXThNK82g@mail.gmail.com>
In-Reply-To: <11168_1583215605_5E5DF3F5_11168_1246_1_CABUE3X=nhuzy1UMEFr1tuJNw9hY_ewYHqoX4fCqp_ZXThNK82g@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/tsv-art/yU4skJTLphhRWByOy18hgHajMo8>
Subject: [Tsv-art] Antw: [EXT] Re: [Ntp] Tsvart last call review of draft-ietf-ntp-packet-timestamps-08
X-BeenThere: tsv-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsv-art/>
List-Post: <mailto:tsv-art@ietf.org>
List-Help: <mailto:tsv-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:tsv-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Mar 2020 08:11:50 -0000

>>> Tal Mizrahi <tal.mizrahi.phd@gmail.com> schrieb am 03.03.2020 um 07:05 in
Nachricht
<11168_1583215605_5E5DF3F5_11168_1246_1_CABUE3X=nhuzy1UMEFr1tuJNw9hY_ewYHqoX4fCq
_ZXThNK82g@mail.gmail.com>:

Hi!

I found another little issue while wondering what the document says about "precision":
In "5. Synchronization Aspects" the text claims "Further considerations may be discussed in this section, such as the required timestamp accuracy and precision". However "precision" is not mentioned there.

Basically I feel the definitions given there for precision and accuracy are quite vague.

Personally I feel the concept of precision (as opposed to resolution) should be handled.
Unfortunately POSIXC clock_getres() seems to return the precision for example:

       The  function  clock_getres()  finds  the resolution (precision) of the
       specified clock clk_id, and, if res  is  non-NULL,  stores  it  in  the
       struct timespec pointed to by res.  The resolution of clocks depends on
       the implementation and cannot be configured by  a  particular  process.
       If  the  time value pointed to by the argument tp of clock_settime() is
       not a multiple of res, then it is truncated to a multiple of res.

Regards,
Ulrich