[Ntp] Going forward with NTP - v5, v4 and approach

kristof.teichel@ptb.de Thu, 18 August 2022 11:09 UTC

Return-Path: <kristof.teichel@ptb.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 B5356C1522A7 for <ntp@ietfa.amsl.com>; Thu, 18 Aug 2022 04:09:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.405
X-Spam-Level:
X-Spam-Status: No, score=-4.405 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ptb.de
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 hUAVOzhxkQp9 for <ntp@ietfa.amsl.com>; Thu, 18 Aug 2022 04:09:54 -0700 (PDT)
Received: from mx1.bs.ptb.de (mx1.bs.ptb.de [192.53.103.120]) (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 92679C14CF05 for <ntp@ietf.org>; Thu, 18 Aug 2022 04:09:53 -0700 (PDT)
Received: from smtp-hub.bs.ptb.de (smtpint01.bs.ptb.de [141.25.87.32]) by mx1.bs.ptb.de with ESMTP id 27IB9ore032392-27IB9org032392 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK) for <ntp@ietf.org>; Thu, 18 Aug 2022 13:09:50 +0200
To: NTP WG <ntp@ietf.org>
MIME-Version: 1.0
X-KeepSent: BAE2F5D9:2E42DB42-C12588A2:00362BE6; type=4; name=$KeepSent
From: kristof.teichel@ptb.de
Message-ID: <OFBAE2F5D9.2E42DB42-ONC12588A2.00362BE6-C12588A2.003D5155@ptb.de>
Date: Thu, 18 Aug 2022 13:09:32 +0200
X-MIMETrack: Serialize by Router on MAILGW01/PTB at 08/18/2022 01:09:50 PM, Serialize complete at 08/18/2022 01:09:50 PM
Content-Type: multipart/alternative; boundary="=_alternative 003D5153C12588A2_="
X-FE-Last-Public-Client-IP: 141.25.87.32
X-FE-Policy-ID: 5:5:5:SYSTEM
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; d=ptb.de; s=s1-ptbde; c=relaxed/relaxed; h=to:mime-version:subject:from:message-id:date:content-type; bh=CDdEfDQmtdhntBPTFAaYVxRHG/QiOHol2yKyy/YIwqg=; b=RO64L6bvhICV2jPUrHm/uFWYK8k6xAkd23tmC3XPluHgIdhdaz8SvuY9GuR8uUXHuL1NnYntOL4x Y44sLVopQMfepjprYpMR02fbyKui40OzQOxBQXN0UzxO+RkQokTQRKYtg67DmaZmwlizEDhpZ1XG VXBGpFWzeYzrCNC6te8W0FaHZQ25jo95tm1hp+qWywUpSP9ar9aGwdHCUzoPcAOzHE+OAt7IcW4B qf453ONzIhjalosr01J9O1/wem68d8H01uBbhI03ZuJjGY1E4NT6M9tYCwG9vnM3uAiCO6Cc3PaO Q4odMpK457pSCmxcwGgWTUXp4C4eZsHhd7dXpA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/plcSU3tT3AqxnbukITpYwxgSj3w>
Subject: [Ntp] Going forward with NTP - v5, v4 and approach
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: Thu, 18 Aug 2022 11:09:59 -0000

Everyone,

a bunch of the discussion that has occured recently with regards to 
draft-ietf-ntp-update-registries (and really to 
draft-mlichvar-ntp-ntpv5-04 as well) has touched on matters that were 
really a bit more foundational to the WG and its process.
Specifically, I'm talking about the following questions:

1) How do we approach NTPv5 (and further versions) regarding design?
One question raised is about the role of "...and working code" in relation 
to "rough consensus".
This seems closely related to the question of order: a) 
concept-specification-code versus b) concept-code-specification.

2) If there are conflicts between i) unwritten rule/tradition, ii) 
specification, and iii) an implementation (and iv), a different 
implementation!)... then what takes precedent?
I thought it obvious that a finished specification should be used as 
normative reference for what is "correct" over any implementation, but 
this seems to be a point of contention.
Same goes for my assumption that a memory of some once communicated 
intention (or an unwritten rule) should be disregarded if it is at odds 
with recent specifications, implementations, or both.

3) What is the/our stance on compatibility, and on versions overall? 
Specifically, do we require/strongly desire backward compatibility? 
What about forward compatibility?

4) Are mode 6 exchanges (any modes other than timing packets really) part 
of "the protocol"? Specifically, do they share a version number, or get 
their own?
Again, I would have assumed that obviously, one divides a protocol (with 
version number) into modes. I.e., there would be NTPv4, with one of its 
modes being NTPv4-mode6. 
But one could also say that NTP-mode6 is kinda its own protocol, and then 
say something like "we are currently up to v4 for NTP-mode2/3, but only up 
to v2 for NTP-mode6"; I find this is asking for trouble, but one could do 
it. There is a strong point to be made then that this way, the mode would 
be its own protocol and should have its own specification.

5) What do we do for identifiers for experimental features? 
Does anyone experimenting contact NTF for coordination? 
Do they register values at IANA for each new experiment? 
Do we register a range of values at IANA as "for experimental purposes", 
and then you use those until experiments are complete and potentially 
register different new values at IANA afterwards?


It seems a bit ridiculous, but I do at this point believe we are too open 
to goalpost-shifting without formal rough consensus on these points 
regarding our own process.
What can we do to clear them up, please?
Did I forget anything important in the same vein?



Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB) 
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.:        +49 (531) 592-4471
E-Mail:   kristof.teichel@ptb.de
__________________________________________