[Ntp] Warren Kumari's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
Warren Kumari via Datatracker <noreply@ietf.org> Mon, 28 June 2021 15:21 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 A594A3A003C; Mon, 28 Jun 2021 08:21:15 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Warren Kumari via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ntp-interleaved-modes@ietf.org, ntp-chairs@ietf.org, ntp@ietf.org, odonoghue@isoc.org, odonoghue@isoc.org
X-Test-IDTracker: no
X-IETF-IDTracker: 7.33.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Warren Kumari <warren@kumari.net>
Message-ID: <162489367509.31114.17922898118876978467@ietfa.amsl.com>
Date: Mon, 28 Jun 2021 08:21:15 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/zHXBTk0qaO1Z4WPbEAJJ4MsmTOM>
Subject: [Ntp] Warren Kumari's Discuss on draft-ietf-ntp-interleaved-modes-05: (with DISCUSS and COMMENT)
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
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, 28 Jun 2021 15:21:16 -0000
Warren Kumari has entered the following ballot position for draft-ietf-ntp-interleaved-modes-05: Discuss 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 DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- I'm quite uncomfortable with the "we'll just change the meaning of some fields, and implementations will be fine with this" tone. The document says: "An explicit negotiation would require a new extension field, which would not work well with implementations that do not respond to requests with unknown extension fields.", and so this plays some tricks to encode information in existing fields. This feels incredibly hacky, but I figured that it's probably all fine if it has been shown to work well across a very very large set of implementations without causing backward issues. The Shepherd Writeup (https://datatracker.ietf.org/doc/draft-ietf-ntp-interleaved-modes/shepherdwriteup/ ) says: "There are multiple implementations of the document. They are discussed in Section 5, entitled "Implementation Status".", so I felt hopeful that there had been extensive testing, but I was not able to find a section entitled "Implementation Status" in any version of draft-mlichvar-ntp-interleaved-modes or draft-ietf-ntp-interleaved-modes. What I *did* find was: 5. Acknowledgements The interleaved modes described in this document are based on the implementation written by David Mills in the NTP project [1]. The specification of the broadcast mode is based purely on this implementation. The specification of the symmetric mode has some modifications. The client/server mode is specified as a new mode compatible with the symmetric mode, similarly to the basic symmetric and client/server modes. So, from what I understand, the broadcast mode is based in the linked implementation (a pointer to where in the codebase this is implemented would have been much more helpful than just a link to http://www.ntp.org), but the more complex, and (FWICT) likely to cause interoperability issues pars have "some modifications" and "a new mode compatible with the symmetric mode". So, are there in fact "multiple implementations of the document."? Has there been interoperability testing to confirm that there are no backwards compatibility issues? Much of the document feels somewhat hand-wavy regarding the compatibility with existing implementations, as well as in things like: "The client SHOULD limit the number of requests in the interleaved mode between server responses to prevent processing of very old timestamps in case a large number of consecutive requests is lost." -- SHOULD limit to what number? 1? 3? 17? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- When the document says things like: "A peer A SHOULD send a peer B a packet in the interleaved mode only when the following conditions are met:" I'm assuming that this means "only when the **all** following conditions are met:"? If so, it needs to be explicit. To be clear, when the document says: "1. The peer A has an active association with the peer B which was specified with the option enabling the interleaved mode, OR the peer A received at least one valid packet in the interleaved mode from the peer B." If "peer A has an active association with the peer B which was **not** specified with the option enabling the interleaved mode" and "peer A receive[s] at least one valid packet in the interleaved mode from the peer B." should it enable interleaved mode? How is an operator supposed to know if they should enable this mode when talking to a peer? As far as I can tell, this adds a significant amount of state keeping to server implementations. The document does somewhat mention this ("A server which supports the interleaved mode needs to save pairs of local receive and transmit timestamps. The server SHOULD discard old timestamps to limit the amount of memory needed to support clients using the interleaved mode."), but it seems like this is a fairly large change, and this bit of text doesn't really cover the state requirements.
- [Ntp] Warren Kumari's Discuss on draft-ietf-ntp-i… Warren Kumari via Datatracker
- Re: [Ntp] Warren Kumari's Discuss on draft-ietf-n… Miroslav Lichvar
- Re: [Ntp] Antw: Re: Antw: [EXT] Re: Robert Wilton… Miroslav Lichvar
- Re: [Ntp] Antw: Re: Antw: [EXT] Re: Robert Wilton… Ulrich Windl
- Re: [Ntp] Antw: [EXT] Re: Robert Wilton's Discuss… Miroslav Lichvar
- [Ntp] Antw: Re: Antw: [EXT] Re: Robert Wilton's D… Ulrich Windl