[Ntp] Benjamin Kaduk's No Objection on draft-ietf-ntp-packet-timestamps-08: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 05 March 2020 00:12 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ntp@ietf.org
Delivered-To: ntp@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id B98A73A0CA9; Wed, 4 Mar 2020 16:12:35 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ntp-packet-timestamps@ietf.org, ntp-chairs@ietf.org, ntp@ietf.org, Karen O'Donoghue <odonoghue@isoc.org>, odonoghue@isoc.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.119.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <158336715573.29467.14533625937371493247@ietfa.amsl.com>
Date: Wed, 04 Mar 2020 16:12:35 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/B5U28rqVq_nAtmdliNpvKzk7Viw>
Subject: [Ntp] Benjamin Kaduk's No Objection on draft-ietf-ntp-packet-timestamps-08: (with COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
List-Id: <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: Thu, 05 Mar 2020 00:12:36 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-ntp-packet-timestamps-08: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ntp-packet-timestamps/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Could this go for BCP instead of Informational? (That would avoid a need in the future to get it added to the downref registry.) When we discuss the NTP timestamp formats, we say that "during and possibly after the occurrence of a leap second, the value of the timestamp may temporarily be ambiguous, as further discussed in Section 5." But in Section 5 we discuss the possibility of behavior where "[t]he clock is slowed down during the leap second and adjacent time intervals until the new time value catches up." These statements seem incompatible unless "adjacent time intervals" occur only after the leap second, which is not my understanding of how leap-second smearing is performed in practice. Section 1.1 Timestamps are widely used in network protocols for various purposes: timestamps are used for logging or reporting the time of an event, delay measurement and clock synchronization protocols both make use of timestamped messages, and in security protocols a timestamp is often used as a value that is unlikely to repeat (nonce). Some security protocols also use timestamps directly for security functionality, e.g., using a replay cache for messages within a certain time window of the past and discarding older ones. That usage is mostly unrelated to what is discussed in this document, and I don't really see a need to mention it in the document, but will mention it here in case opinions differ. Section 3 When multiple fields are used (with different units), what needs to be said about how the two fields are combined and/or any restrctions on the allowed range of the fields? (E.g., for the "joke" timestamp format that has a seconds plus centiseconds representation, are values greater than or equal to 100 centiseconds forbidden? Do we envision applications other than "convert values to a common unit and add them" for multiple fields, such as explicit fields to convey timestamp accuracy and/or precision?) Section 4 This document defines a set of recommended timestamp formats. Defining a relatively small set of recommended formats enables significant reuse; for example, a network protocol may reuse the NTP or PTP timestamp format, allowing a straightforward integration with an NTP or a PTP-based timer. Moreover, since accurate timestamping mechanisms are often implemented in hardware, a new network protocol that reuses an existing timestamp format can be quickly deployed using existing hardware timestamping capabilities. This text feels very familiar by this point in the document... Section 4.2.1 Just to check: we assume by definition that no leap seconds occurred prior to the creation of UTC when we say that 2272060800 is the number of seconds between 1 Jan 1900 and 1 Jan 1972, right? Section 7 I assume the WG considered whether this content could be spun off into a separate document, e.g., one that defines specific timestamp control fields, but decided that it is important enough to publish now. Section 9 Is it in scope to discuss considerations relating to applications that have an inaccurate sense of the current time, or network packets that contain timestamps intended to be synchronized to a reference but in fact are not? (I see a decent argument that it is not in scope, but want to check.) Section 11.2 I assume the self-reference will get removed by the RFC Editor.
- [Ntp] Benjamin Kaduk's No Objection on draft-ietf… Benjamin Kaduk via Datatracker
- Re: [Ntp] Benjamin Kaduk's No Objection on draft-… Tal Mizrahi
- Re: [Ntp] Benjamin Kaduk's No Objection on draft-… Benjamin Kaduk