Re: [Ntp] Antw: Re: Antw: [EXT] Re: Robert Wilton's Discuss on draft‑ietf‑ntp‑interleaved‑modes‑05: (with DISCUSS and COMMENT)

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Thu, 22 July 2021 13:41 UTC

Return-Path: <Ulrich.Windl@rz.uni-regensburg.de>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B77B3A46EA for <ntp@ietfa.amsl.com>; Thu, 22 Jul 2021 06:41:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KGQCTxQAPE_U for <ntp@ietfa.amsl.com>; Thu, 22 Jul 2021 06:41:00 -0700 (PDT)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [194.94.157.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D4A7C3A46EB for <ntp@ietf.org>; Thu, 22 Jul 2021 06:40:59 -0700 (PDT)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id A00BB6000054 for <ntp@ietf.org>; Thu, 22 Jul 2021 15:40:55 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx1.uni-regensburg.de (Postfix) with ESMTP id 807F76000049 for <ntp@ietf.org>; Thu, 22 Jul 2021 15:40:53 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Thu, 22 Jul 2021 15:40:53 +0200
Message-Id: <60F97565020000A1000429CF@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.3.1
Date: Thu, 22 Jul 2021 15:40:53 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: <mlichvar@redhat.com>
Cc: <ek.ietf@gmail.com>,"ntp@ietf.org" <ntp@ietf.org>
References: <YNrbjCDF4/609dg/@localhost> <D999D237-5A25-4E84-99D0-EE5DB2B13411@cisco.com> <YN3ZzPN5LOsAjmz6@localhost> <DM4PR11MB5438D8450E7B90D363929640B5119@DM4PR11MB5438.namprd11.prod.outlook.com> <YPaunrczI/inrtMP@localhost> <60F6B70A020000A100042803@gwsmtp.uni-regensburg.de> <YPa9H7IV2wITWKrD@localhost> <CAMGpriWzV4--_Nw9hsNC01U7f1FzjZQ8sNdJz+25dxhFtuDUvg@mail.gmail.com> <YPkxqtpgzD7g8Anz@localhost> <60F9381E020000A1000429B7@gwsmtp.uni-regensburg.de> <YPlKdn+lfKkVgzKz@localhost> <2E2D498B020000166A6A8CFC@gwsmtp.uni-regensburg.de>
In-Reply-To: <2E2D498B020000166A6A8CFC@gwsmtp.uni-regensburg.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Content-Disposition: inline
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/dppOuh8RmdCnRrpz010RKUrklz8>
Subject: Re: [Ntp] =?utf-8?q?Antw=3A_Re=3A__Antw=3A_=5BEXT=5D_Re=3A_Robert_Wi?= =?utf-8?b?bHRvbidzIERpc2N1c3Mgb24gZHJhZnTigJFpZXRm4oCRbnRw4oCRaW50ZXJs?= =?utf-8?b?ZWF2ZWTigJFtb2Rlc+KAkTA1OiAod2l0aCBESVNDVVNTIGFuZCBDT01NRU5U?= =?utf-8?q?=29?=
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
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: Thu, 22 Jul 2021 13:41:05 -0000

>>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 22.07.2021 um 12:37 in
Nachricht <YPlKdn+lfKkVgzKz@localhost>:
> On Thu, Jul 22, 2021 at 11:19:26AM +0200, Ulrich Windl wrote:
>> >>> Miroslav Lichvar <mlichvar@redhat.com> schrieb am 22.07.2021 um 10:51
in
>> > My opinion still is that clients that set their origin timestamp to
>> > anything else than zero or the transmit timestamp from the received
>> > packet don't follow the NTP specification. It's not a subset of the
>> > protocol.
>> 
>> Your opinion is different from the RFC 5905:
>> "Origin Timestamp (org): Time at the client when the request departed
>> for the server, in NTP timestamp format." (page 23)
> 
> If you were implementing a client and read that description out of the
> context, what exactly would you put in the field? The client's
> transmit timestamp?

Yes.

> 
> When you read the text that follows that description:
> 
>    Receive Timestamp (rec): Time at the server when the request arrived
>    from the client, in NTP timestamp format.
> 
>    Transmit Timestamp (xmt): Time at the server when the response left
>    for the client, in NTP timestamp format.
> 
> what would you put in the transmit timestamp field?

Transmit time (current time), too.

> 
> That is obviously a description from the server's point of view.
> 
> To see how the timestamps are set in the client request, you need to
> look at the diagram in the "On wire protocol" section, or Figure 30 in
> the "Poll Process Operations" section, which has "x.org <‑‑ p.xmt".

I thought the first is a request, while the second is a response.


> 
> The document is quite confusing in some parts, but I don't see
> anything that could lead you to set the origin timestamp in the
> request to the server's receive timestamp (i.e. make a request in the
> interleaved mode).


Me neither.

> 
> ‑‑ 
> Miroslav Lichvar