IETF Logo Mail Archive

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

Harlan Stenn <stenn@nwtime.org> Tue, 06 September 2022 06:23 UTC

Return-Path: <stenn@nwtime.org>
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 E7B98C1524C7 for <ntp@ietfa.amsl.com>; Mon, 5 Sep 2022 23:23:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.114
X-Spam-Level:
X-Spam-Status: No, score=-1.114 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, RDNS_NONE=0.793, 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=no 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 P78uRbsXUiu6 for <ntp@ietfa.amsl.com>; Mon, 5 Sep 2022 23:23:11 -0700 (PDT)
Received: from chessie.everett.org (unknown [IPv6:2001:470:1:205::234]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6298AC1522D8 for <ntp@ietf.org>; Mon, 5 Sep 2022 23:23:11 -0700 (PDT)
Received: from [10.208.75.149] (071-084-168-128.res.spectrum.com [71.84.168.128]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by chessie.everett.org (Postfix) with ESMTPSA id 4MMFgd3X5rzMQ1K; Tue, 6 Sep 2022 06:23:09 +0000 (UTC)
Message-ID: <d5800f08-d5ad-1d0e-04af-46a525621a14@nwtime.org>
Date: Mon, 05 Sep 2022 23:23:07 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.13.0
Content-Language: en-US
To: ntp@ietf.org
References: <david@venhoek.nl> <CAPz_-SVPE-Fd1vFWnbu+GAPc=y2bkJMW4pyu98bBwDfcm+R2rg@mail.gmail.com> <20220830205143.DFDC328C1D8@107-137-68-211.lightspeed.sntcca.sbcglobal.net> <Yw8NBX6ATjRr0/A4@localhost> <b52ceff2-28a4-ef4e-2d63-ce2a0f519adb@pdmconsulting.net> <F347640002000095FDA5B133@gwsmtp.uni-regensburg.de> <8F7E1DA8020000866A6A8CFC@gwsmtp.uni-regensburg.de> <3510EFC5020000235AEBDC6A@gwsmtp.uni-regensburg.de> <6316E53E020000A10004D6C6@gwsmtp.uni-regensburg.de>
From: Harlan Stenn <stenn@nwtime.org>
In-Reply-To: <6316E53E020000A10004D6C6@gwsmtp.uni-regensburg.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/0QPcKgs0s-3HJe4UJbbxyBZPqmk>
Subject: Re: [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:17 -0000

On 9/5/2022 11:14 PM, Ulrich Windl wrote:
>>>> Danny Mayer <mayer@pdmconsulting.net> schrieb am 05.09.2022 um 21:56 in
> Nachricht <b52ceff2-28a4-ef4e-2d63-ce2a0f519adb@pdmconsulting.net>:
> 
>> On 8/31/22 3:25 AM, Miroslav Lichvar wrote:
>>> On Tue, Aug 30, 2022 at 01:51:43PM -0700, Hal Murray wrote:
>>> Or maybe even 2 separate RFCs. The idea being that SNTP will be much
>>> easier
>>>> to understand and we can target it for a longer lifetime.  In particular, it
>>>> wouldn't have to say anything about loop detection.
>>> I don't like duplicating text or code. We just need to make sure the
>>> document is clear on what parts are not required for client-only
>>> implementations.
>>>
>>> I think SNTP vs NTP is more about algorithms, not the protocol.
>>> Without the symmetric mode, NTPv5 will be very easy to implement.
>>>
>> SNTP is defined in RFC5905 Section 14. You don't need anything more than
>> that.
> 
> Amazingly it talks about using SNTP in the server:
> "SNTP is intended for primary servers equipped
> with a single reference clock, as well as for clients with a single
> upstream server and no dependent clients."

Why is that "Amazing"?

A refclock is expected to be a reliable source of time.  SNTP is a 
perfectly good vehicle for serving time in this way.  It may not be 
GREAT because it isn't a full ntpd, but what functional difference is 
there between an sntp instance getting its time from a refclock and a 
"full" ntpd instance that ONLY gets its time from a refclock?

> It also says: "(...), NTP and SNTP servers and clients are
> completely interoperable and can be intermixed in NTP subnets."

Yes.  This is true.

> In addition Figure 31 says: "x.digest <-- md5 digest" (probably fixed via errata (is MD5 really required?), but I'm using the original here).

No idea.  But 'md5' is mentioned 21 times in RFC 5905.

> I thinnk for NTPv5 we should specify an example SNTP request packet; what is written in section 14 leaves a lot of interpretation unanswered (e.g. are unused fields all set to zero?)
> 
> Regards,
> Ulrich
> 
> 
>>
>> Danny
> 
> 
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org
> https://www.ietf.org/mailman/listinfo/ntp
> 

-- 
Harlan Stenn <stenn@nwtime.org>
http://networktimefoundation.org - be a member!

v2.23.0 | Report a Bug | By Email