IETF Logo Mail Archive

[Ntp] Antw: Re: Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Mon, 02 September 2019 10:52 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 0F77F120131 for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 03:52:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-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 uTHQeZvFgzRR for <ntp@ietfa.amsl.com>; Mon, 2 Sep 2019 03:52:55 -0700 (PDT)
Received: from mx1.uni-regensburg.de (mx1.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf7]) (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 99AD8120108 for <ntp@ietf.org>; Mon, 2 Sep 2019 03:52:55 -0700 (PDT)
Received: from mx1.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id AE2156000051 for <ntp@ietf.org>; Mon, 2 Sep 2019 12:52:51 +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 9352B6000050 for <ntp@ietf.org>; Mon, 2 Sep 2019 12:52:51 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Mon, 02 Sep 2019 12:52:51 +0200
Message-Id: <5D6CF482020000A100033446@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Mon, 02 Sep 2019 12:52:50 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: "ntp@ietf.org" <ntp@ietf.org>, stenn@nwtime.org
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de> <5D66392D020000A100033273@gwsmtp.uni-regensburg.de> <8F6BAF5F-CC7B-47B9-90FD-BD20D6ABE845@meinberg.de> <20190828103752.GI24761@localhost> <3f4b55ca-02d9-a470-229b-40860866efbf@nwtime.org> <20190828111458.GJ24761@localhost> <e50112dd-f918-1135-74c8-a738ecb70b70@nwtime.org> <55867E75-9813-466B-8E57-0E157DE5AEB9@meinberg.de> <d308b5d4-3d6e-981b-3dfc-9d5938bad78d@rubidium.se> <5D6CB84E020000A100033405@gwsmtp.uni-regensburg.de> <43FFB9C5-8F9D-491C-8FC6-9DD292009E2A@meinberg.de> <26eeb953-301f-682e-47fe-cd34518d53e3@nwtime.org>
In-Reply-To: <26eeb953-301f-682e-47fe-cd34518d53e3@nwtime.org>
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/aIfNgCcL9-RJQKBHKwOTvYKJxYg>
Subject: [Ntp] Antw: Re: Antw: Re: Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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, 02 Sep 2019 10:52:57 -0000

>>> Harlan Stenn <stenn@nwtime.org> schrieb am 02.09.2019 um 12:21 in
Nachricht
<26eeb953-301f-682e-47fe-cd34518d53e3@nwtime.org>:
> The refid has meaning on the system that issues it.
> 
> The refid is a nonce to any system that receives it.
> 
> Any meaning of the refid outside of the issuing system relies on
> higher‑level knowledge that is not part of the protocol.

Actually this description holds for NTPv4. For NTPv3 the formal description
also is like that, but the specificvation of the clock update procedure (page
27 in the PDF version of RFC 1303) says:
sys.refid ˿ peer.peeraddr

Also on page 37:
peer.refid = peer.hostaddr

And, maybe most important, what's missing in RFC 5905 is a section "Chages
from the previous version": I guess many implementations just continued to
treat the REFID as some network address...

> 
> On 9/2/2019 1:00 AM, Heiko Gerstung wrote:
>> Hi Ulrich,
>> 
>> good point. That is why NTP would use that "ID" instead of the IP address
to 
> identify itself. That means ntpd could find out timing loops even if they
are 
> caused by a routing loop.
>> 
>> Regards,
>>    Heiko
>> 
>> 
> 
> ‑‑ 
> Harlan Stenn, Network Time Foundation
> http://nwtime.org ‑ be a Member!
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp

v2.23.0 | Report a Bug | By Email