Re: [Ntp] Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts Fri, 30 August 2019 12:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B9E96120841 for <>; Fri, 30 Aug 2019 05:33:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.888
X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wZ7tprtI4AqV for <>; Fri, 30 Aug 2019 05:33:55 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A9743120086 for <>; Fri, 30 Aug 2019 05:33:54 -0700 (PDT)
Received: from ( []) by with ESMTP id x7UCXrO2020947-x7UCXrO4020947 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for <>; Fri, 30 Aug 2019 14:33:53 +0200
Received: from ( []) by (Postfix) with ESMTPS id 0782F83A8A3 for <>; Fri, 30 Aug 2019 14:33:52 +0200 (CEST)
In-Reply-To: <>
References: <> <>
To: "NTP WG" <>
MIME-Version: 1.0
Message-ID: <>
Date: Fri, 30 Aug 2019 14:34:43 +0200
Content-Type: multipart/alternative; boundary="=_alternative 0045045BC1258466_="
Archived-At: <>
Subject: Re: [Ntp] Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 30 Aug 2019 12:33:58 -0000

Hello all,

I also oppose adoption of the four draft as documents intended for use 
with NTPv4.

I broadly agree with Heiko's assessment insofar as I think most of the 
individual content in the four drafts is relevant, but should be treated 
in a different context: 
not as an attempt to repair the holes that are opening up in NTPv4, but as 
a set of principles going into the next revision of NTP ("NTPv5", likely).

Best regards,


This is especially drastic for the I-DO proposal, where I do not see how 
it makes sense to try to catch implementation that are too old to 
understand certain newer EFs by forcing them to understand another new EF 
with which they can talk about which EFs they do understand.
It does seem important to do something akin to this, but I really think it 
only makes sense if you can assume ALL implementations to a) understand 
the I-DO-inspired EF and b) be able to use crypto methods to provide 
authentication for whatever is in the I-DO-inspired EF.

Semi-related, I really believe NTPv5 should enable behavior that splits 
messages (especially server responses) into two parts, the first as small 
as possible, basically only an identifier saying that it is an NTP packet 
and providing an ID for the association/exchange it belongs to, the second 
carrying all the timestamps and meta information.
This would enable an almost completely free choice of information that a 
client could request, each piece of it in its own extension field, without 
it endangering speed or accuracy.
But it is another feature you can only have if you can expect all 
participants to understand it.

Von:    "Heiko Gerstung" <>
An:     "Karen O'Donoghue" <>rg>, "" 
Datum:  28.08.2019 08:55
Betreff:        Re: [Ntp] Calls for Adoption -- NTP Extension Field drafts 
-- Four separate drafts
Gesendet von:   "ntp" <>


I do not support adopting all four drafts, I believe that we should either 
integrate them into a new revision of NTP ("NTPv5") or fix them 
problems/issues they address in that new "NTPv5" RFC. Most of the issues 
addressed by those drafts can be easily solved by changing/expanding the 
NTP packet format for "NTPv5". 

The "REFID" draft would be obsolete if an NTPv5 packet header for a server 
mode packet by definition includes  a "MY_ID" field. 

The "MAC/last extension field" draft would be obsolete if we define that 
NTPv5 does only support Extension Fields as allowed additional data and a 
MAC in v5 is always transported inside an extension field (the "MAC-EF" 
approach as described in the draft, for example). 

The "I-DO extension field" draft would be something I would integrate into 
a "NTPv5" RFC as a mandatory requirement for NTP servers. 

The "Extended Information Extension Field" draft would be obsolete if we 
introduce either additional packet header fields in v5 or just defined a 
new EF for information that we think should be available from the server. 
That EF could be sent or not, based on whether the client wants it or not 
(indicated by an EF sent by that client in its request, for example). 

Best Regards,

Heiko Gerstung 
Managing Director

MEINBERG® Funkuhren GmbH & Co. KG
Lange Wand 9
D-31812 Bad Pyrmont, Germany
Phone:    +49 (0)5281 9309-404
Fax:        +49 (0)5281 9309-9404

Amtsgericht Hannover 17HRA 100322
Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
Hartmann, Heiko Gerstung


Do not miss our Time Synchronization Blog: 

Connect via LinkedIn:

On 28.08.19, 05:38 "ntp im Auftrag von Karen O'Donoghue" 
< im Auftrag von> wrote:

    The following four drafts are four different proposals for new 
extension fields. Please review each draft and indicate whether these 
should be adopted by the working group. I am sending them all as one set 
because they are all extension fields, but we need a response for each 
draft listed below. 
    Karen and Dieter
    1.  Network Time Protocol Extended Information Extension Field
    2.  Network Time Protocol I-Do Extension Field
    3.  Network Time Protocol MAC/Last Extension Fields
    4.  Network Time Protocol Suggested REFID Extension Field
    ntp mailing list

ntp mailing list