Re: [Ntp] [Last-Call] Genart last call review of draft-ietf-ntp-interleaved-modes-04

Lars Eggert <> Mon, 12 July 2021 14:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 26E983A19C1; Mon, 12 Jul 2021 07:27:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0lMY48ul0EPh; Mon, 12 Jul 2021 07:27:40 -0700 (PDT)
Received: from ( [IPv6:2a00:ac00:4000:400:211:32ff:fe22:186f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E21B3A1A08; Mon, 12 Jul 2021 07:27:36 -0700 (PDT)
Received: from (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id CFDA460034E; Mon, 12 Jul 2021 17:27:29 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1626100050; bh=1hovcOHuO/U+1Dm0G5QeycfkduQd5xheIuk1AyFF+Gw=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=Y5KuTOIe0Db1SbAgD8znlBiyppUScAkZso3y/uGLeQPv5rPEGxNHThgdXKqbH1b+I j6w/DE4YfE40kG+VyY7lsNiUJ04Ih4H/8w4haGAVNNVORN1x+NXw91KVnsByH8UXkI N64imkWhSVtzhj6mSxy8C7WSM4UeMvsGG3v4ZpTQ=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_E9F943BD-4FEF-4873-AE44-223FFE622765"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Mon, 12 Jul 2021 17:27:29 +0300
In-Reply-To: <>
Cc: General Area Review Team <>,,,
To: Theresa Enghardt <>
References: <>
X-MailScanner-ID: CFDA460034E.A342E
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Ntp] [Last-Call] Genart last call review of draft-ietf-ntp-interleaved-modes-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Time Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 12 Jul 2021 14:27:45 -0000

Theresa, thank you for your review. I have entered a No Objection ballot for this document for now, but support Warren's Discuss and may eventually Abstain, depending on how the discussion goes.


> On 2021-4-7, at 4:43, Theresa Enghardt via Datatracker <> wrote:
> Reviewer: Theresa Enghardt
> Review result: Ready with Issues
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> For more information, please see the FAQ at
> <>.
> Document: draft-ietf-ntp-interleaved-modes-04
> Reviewer: Theresa Enghardt
> Review Date: 2021-04-06
> IETF LC End Date: 2021-04-14
> IESG Telechat date: Not scheduled for a telechat
> Summary: The draft is basically ready for publication as a Standards Track RFC,
> but it has some clarity issues that need to be addressed before publication.
> Major issues: None.
> Minor issues:
> Section 1:
> The introduction describes design considerations for changing the semantics of
> existing timestamps, rather than introducting additional packets. However, it
> does not mention negotiation. Please add ome text to the introduction clrifying
> how interleaved mode is negotiated, implicitly (if I understand correctly).
> Furthermore, the introduction should mention that clients, servers, and peers
> now have to infer whether a received packet is in basic mode or interleaved
> mode from the timestamps themselves and their cached knowledge (if I understand
> correctly). Has explicit negotiation been considered? What would be the
> consequence of a client, server, or peer failing to correctly determine whether
> a received packet is in basic or interleaved mode, perhaps due to an
> implementation error? Please consider adding a few sentences to discuss this
> scenario.
> The introduction also does not mention whether a client, server, or peer that
> supports interleaved mode has to operate in interleaved mode exclusively, or
> whether it can switch between interleaved mode and basic mode. The document
> later clarifies this, but please consider already clarifying here that an
> implementation must support both modes if it wants to use interleaved mode, and
> that a given sequence of messages can switch between both modes, to make the
> scope clearer and the subsequent sections easier to understand.
> Section 2:
> Here the document first mentions the origin timestamp, where previously the
> document has only talked about transmit and receive timestamps. I think it
> would be good to briefly explain what the origin timestamp is, how this
> document is changing its semantics, and why. Section 7.3 of RFC 5905 defines
> "Origin Timestamp (org): Time at the client when the request departed for the
> server", but this document says "A client request in the basic mode has an
> origin timestamp equal to the transmit timestamp from the previous server
> response, or is zero." If basic mode is RFC 5905, I would have expected these
> definitions to match. Has the definition of origin timestamp changed from RFC
> 5905 to what this document terms basic mode? Please clarify.
> Can a server only respond in interleaved mode if the client request was in
> interleaved mode? Please clarify. (Section 3 says that a peer "MUST NOT respond
> in the interleaved mode if the request was not in the interleaved mode", but I
> have not found a similar statement for client/server interleaved mode.)
> "Both servers and clients that support the interleaved mode MUST NOT send a
> packet that has a transmit timestamp equal to the receive timestamp in order to
> reliably detect whether received packets conform to the interleaved mode." I
> think the document should reiterate in this section that a server or client has
> to perform such detection (on each incoming packet?), and how to make this
> determination.
> Section 3:
> "The peer A has an active association with the peer B which was specified with
> an option enabling the interleaved mode" This sentence reads as if there is an
> option to explicitly enable the interleaved mode. Howeve, this document does
> not change the NTP packet format or add an option. Please clarify/rephrase.
> Nits/editorial comments:
> Section 1:
> "in the user space" -> "in user space"
> "would enable a traffic amplification" -> "would enable a traffic amplification
> attack"
> To make Section 2 easier to navigate, maybe it would help to add subsections,
> e.g., "Field semantics", "Protocol operation", and "Example".
> Section 3:
> "The peers SHOULD compute the offset and delay using one the two sets of
> timestamps specified in the client/server section" -> "[…] using one of the two
> sets of timestamps […]"
> --
> last-call mailing list