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

Miroslav Lichvar <> Thu, 08 April 2021 15:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B1B93A0B5A for <>; Thu, 8 Apr 2021 08:45:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.821
X-Spam-Status: No, score=-2.821 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 57YnAOvYOVlm for <>; Thu, 8 Apr 2021 08:45:20 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 954043A0B3F for <>; Thu, 8 Apr 2021 08:45:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1617896719; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=fupLjbBcD/SqYYJxP2LA5B7VV1zmOzdlzKK+gre3e0Q=; b=bQPyoIxDFsIMaPEOKQLljBW1sHlPLiwc1GcyTZziL66YAtRLNJrHE7CaDNSqJNS+LrT6Rn piN4znNiJZcQddGw6XUFhLsBKbHPWJ1LmlDNbHZgqjKj1aEa0L5H0krQD32W88vCL+bZXa /sEiyuUiwa/nL076EIMt6U9mL5rZWRg=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-558-VNfBTAALOG2QFyyw7E0zSA-1; Thu, 08 Apr 2021 11:44:11 -0400
X-MC-Unique: VNfBTAALOG2QFyyw7E0zSA-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34706801814; Thu, 8 Apr 2021 15:44:10 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 14EA460C25; Thu, 8 Apr 2021 15:44:08 +0000 (UTC)
Date: Thu, 08 Apr 2021 17:44:07 +0200
From: Miroslav Lichvar <>
To: Theresa Enghardt <>
Message-ID: <YG8kx+y6yVQ+0oQK@localhost>
References: <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.79 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
Archived-At: <>
Subject: Re: [Ntp] Genart last call review of draft-ietf-ntp-interleaved-modes-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Apr 2021 15:45:22 -0000

On Tue, Apr 06, 2021 at 06:43:12PM -0700, 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.

Thank you for the review.

I tried to address all issues that you pointed out, with one exception
noted below. A new version of the draft is available (-05). It also
has a few smaller changes suggested by Erik Kline earlier.

> 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.

The description you quoted from RFC 5905 seems to be from the server's
point of view, i.e. the response has a copy of the transmit timestamp
from the request. The section "8. On-Wire Protocol" has more details
and an example of the fields in an exchange.

I added a new paragraph briefly explaining the purpose of the origin

> 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.)

This should be covered by the list of conditions after "When the
server receives a request from a client, it SHOULD respond in the
interleaved mode if the following conditions are met:"

I added "(i.e. the request is not detected to conform to the
interleaved mode)" to the paragraph starting with "If the conditions
are not met" to make this more clear. 

> "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.

I'm not sure what exactly is missing in that section. The server
has to check those two conditions for each packet, before sending a
response in interleaved mode. The client has an extended test for
bogus packets, starting with "The check for bogus packets SHOULD
compare the origin timestamp". It needs to be performed for each

> 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.

Symmetric interleaved mode is supposed to be enabled with an option to
prevent an interoperability issue with peers that don't support
the interleaved mode. I added a new paragraph to explain that.


Miroslav Lichvar