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

Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Tue, 06 September 2022 09:14 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 A8EF1C152715 for <ntp@ietfa.amsl.com>; Tue, 6 Sep 2022 02:14:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.909
X-Spam-Level:
X-Spam-Status: No, score=-6.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 ikehH_rUJaqb for <ntp@ietfa.amsl.com>; Tue, 6 Sep 2022 02:14:04 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [194.94.157.147]) (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 F2AD5C14CF13 for <ntp@ietf.org>; Tue, 6 Sep 2022 02:14:03 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id E49FA6000053 for <ntp@ietf.org>; Tue, 6 Sep 2022 11:14:00 +0200 (CEST)
Received: from gwsmtp.uni-regensburg.de (gwsmtp1.uni-regensburg.de [132.199.5.51]) by mx2.uni-regensburg.de (Postfix) with ESMTP id C490C600004D for <ntp@ietf.org>; Tue, 6 Sep 2022 11:14:00 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Tue, 06 Sep 2022 11:14:01 +0200
Message-Id: <63170F58020000A10004D6FC@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.4.1
Date: Tue, 06 Sep 2022 11:14:00 +0200
From: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
To: 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> <6316E754020000A10004D6D4@gwsmtp.uni-regensburg.de> <8A9B26A002000006FDA5B133@gwsmtp.uni-regensburg.de>
In-Reply-To: <8A9B26A002000006FDA5B133@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/9Fgqro4Vv6qzXf11FMXHeo1RqbA>
Subject: [Ntp] Antw: Re: 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 09:14:05 -0000

>>> Hal Murray <halmurray@sonic.net> schrieb am 06.09.2022 um 09:04 in
Nachricht
<20220906070439.08DEE28C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net>:

> Ulrich.Windl@rz.uni‑regensburg.de said:
>> 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. 
> 
> You are tangling 2 threads.  The chunk you are replying to is discussing 
> SNTP.
> 
> The S is for Simple.  I hope SNTP will work without extension fields.
> 
> 
>> Would it be advantageous if a server can recognize an SNTP request?
> 
> What would the server do differently if it figured out that a request came 
> from a SNTP client?

Maybe not sending extension fields, or maybe not filling the values of the
response that SNTP would ignore anyway.

> 
> It might make sense to have a separate packet format for SNTP 
> request/response.  That would make sense if the packet format could be a lot

> simpler than the NTP request/response format.  So far, it seems OK to ignore

> a few fields.
> 
> 
> ‑‑ 
> These are my opinions.  I hate spam.