[Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Tue, 06 September 2022 06:23 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 43681C1522D8 for <ntp@ietfa.amsl.com>; Mon, 5 Sep 2022 23:23:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id abeHCx6o00-T for <ntp@ietfa.amsl.com>; Mon, 5 Sep 2022 23:23:24 -0700 (PDT)
Received: from mx3.uni-regensburg.de (mx3.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:4:4e79]) (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 5EBEBC1524C7 for <ntp@ietf.org>; Mon, 5 Sep 2022 23:23:23 -0700 (PDT)
Received: from mx3.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 712F26000050 for <ntp@ietf.org>; Tue, 6 Sep 2022 08:23:19 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx3.uni-regensburg.de (Postfix) with ESMTP id B58D36000049 for <ntp@ietf.org>; Tue, 6 Sep 2022 08:23:17 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 06 Sep 2022 08:23:18 +0200
Message-Id: <6316E754020000A10004D6D4@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.1
Date: Tue, 06 Sep 2022 08:23:16 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: mayer@pdmconsulting.net, halmurray@sonic.net
Cc: "ntp@ietf.org" <ntp@ietf.org>
References: <17AED21F020000EA86EDC2A6@gwsmtp.uni-regensburg.de> <6305BCFE020000A10004CA27@gwsmtp.uni-regensburg.de> <17BF83080200007D5AEBDC6A@gwsmtp.uni-regensburg.de> <630E0EFC020000A10004D2F0@gwsmtp.uni-regensburg.de> <C492F298020000C2AB59E961@gwsmtp.uni-regensburg.de> <F347640002000095FDA5B133@gwsmtp.uni-regensburg.de> <8F7E1DA8020000866A6A8CFC@gwsmtp.uni-regensburg.de> <3510EFC5020000235AEBDC6A@gwsmtp.uni-regensburg.de> <BAEB6CF0020000ABFDA5B133@gwsmtp.uni-regensburg.de>
In-Reply-To: <BAEB6CF0020000ABFDA5B133@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/PC38t9r8EhcC5-6E3KwF1akW-x8>
Subject: [Ntp] Antw: Re: Antw: Re: Antw: [EXT] NTPv5 Loop Detection without Stratum
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.39
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: Tue, 06 Sep 2022 06:23:28 -0000

>>> Hal Murray <halmurray@sonic.net> schrieb am 05.09.2022 um 23:52 in
Nachricht
<20220905215236.ED4D728C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net>:

> mayer@pdmconsulting.net said:
>> SNTP is defined in RFC5905 Section 14. You don't need anything more than
>> that. 
> 
> There is also RFC 4330 and a lot of crappy code out there in firmware that 
> will never get updated.
> 
> RFC 5905 is over 100 pages.  Section 14 is less than a page.  How many of 
> those other pages would somebody have to read and understand in order to 
> implement a SNTP client?
> 
> If you were a junior programmer assigned to implement a SNTP client, would 
> you 
> go throgh RFC 5905 or google around and find some code to copy and ship it 
> when it worked?

Actually I think, the programmer will first write some code, and when that
does not seem to work, he'll add code from elsewhere.

> 
> 
> I think we should have a separate document for SNTP clients.  So far, I 
> haven't convinced (m)any other people.  There are two goals:
> 
> One is to have a clear and simple document so we can point people at it when

> 
> their current code is sending ancient format packets.  Some of those ancient

> 
> packets are not using a format described in any RFC and they worked just 
> because of the undocumented details in the ntpd implementation.
> 
> Another is to make us think and document a packet format that we will 
> support for a long time.

Yes, but a "packet format" does not mean a fixed-length packet IMHO; instead
if should contain a mechanism for a variable number of optional fields that can
have a variable length and should be parseable even if it's only to ignore
them.
I think that is what the e tension fields had in mind, but somewhat
short-sighted.

> 
> We should setup servers that don't support old format packets so SNTP 
> implementors can test their code.

Would it be advantageous if a server can recognize an SNTP request?


Regards,
Ulrich

> 
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp