Re: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-interleaved-modes-05: (with COMMENT)

Miroslav Lichvar <> Mon, 28 June 2021 14:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B329D3A094E for <>; Mon, 28 Jun 2021 07:12:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.996
X-Spam-Status: No, score=-2.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.198, 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.001, RCVD_IN_MSPIKE_WL=0.001, 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 TX3_a2XN3p1y for <>; Mon, 28 Jun 2021 07:12:05 -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 C56DF3A094A for <>; Mon, 28 Jun 2021 07:12:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mimecast20190719; t=1624889524; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=Dtokn6D7VQDspEy2vFNWLHCBO045oTyMPiTkRpsH6Mk=; b=cPizpBPOSVXlUBnJaS0VDB8++7O3VvbUMHEAoRS80CzFibXh2EsoCzvSMtNMFouDM2DKhm cusnViiLNO7Ltx2kjPYFFWDZzGIdd5imY+BZ0WZrz1NxTLpY++p8cFbOz3mEQoNd3d2IgO P8UhWCQjzH1WtlhrtzzG1DsPVRZih3w=
Received: from ( []) (Using TLS) by with ESMTP id us-mta-500-917ZXym9MLiJHMrJ78SYNQ-1; Mon, 28 Jun 2021 10:12:03 -0400
X-MC-Unique: 917ZXym9MLiJHMrJ78SYNQ-1
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C2E3C100CA89; Mon, 28 Jun 2021 14:12:01 +0000 (UTC)
Received: from localhost ( []) by (Postfix) with ESMTPS id 9CBE910027A5; Mon, 28 Jun 2021 14:11:59 +0000 (UTC)
Date: Mon, 28 Jun 2021 16:11:58 +0200
From: Miroslav Lichvar <>
To: Éric Vyncke <>
Cc: The IESG <>,,,,
Message-ID: <YNnYrhewhxxSK7RT@localhost>
References: <>
MIME-Version: 1.0
In-Reply-To: <>
X-Scanned-By: MIMEDefang 2.84 on
Authentication-Results:; auth=pass smtp.auth=CUSA124A263
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Ntp] Éric Vyncke's No Objection on draft-ietf-ntp-interleaved-modes-05: (with COMMENT)
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, 28 Jun 2021 14:12:11 -0000

On Mon, Jun 28, 2021 at 04:07:51AM -0700, Éric Vyncke via Datatracker wrote:
> Éric Vyncke has entered the following ballot position for
> draft-ietf-ntp-interleaved-modes-05: No Objection

Thanks for the review.

> -- Section 2 --
> "  The server MAY separate the timestamps
>    by IP addresses, but it SHOULD NOT separate them by port numbers,
>    i.e.  clients are allowed to change their source port between
>    requests."
> With draft-ietf-ntp-port-randomization in mind, please change the "clients are
> allowed" into "clients are recommended to"

If I didn't miss an update in the recent changes of the draft, the
port-randomization draft still leaves that per-request or
per-association decision to the implementation with no preference, so
I think they can but are not recommended to change the port between

> "  Both servers and clients that support the interleaved mode MUST NOT
>    send a packet that has a transmit timestamp equal to the receive
>    timestamp"
> Will it always be possible to comply with the above "MUST NOT" ?

I think it will. If the timestamps happen to be equal, one of the
timestamps can simply be adjusted by 1 before the transmission. That's
~1/4 of nanosecond, well hidden in the typical precision of an NTP

Miroslav Lichvar