Re: [Ntp] Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts

" " <> Wed, 28 August 2019 09:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B41E120096 for <>; Wed, 28 Aug 2019 02:37:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.996
X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FILL_THIS_FORM=0.001, FROM_EXCESS_BASE64=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key); domainkeys=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id D-tCm1da-MNB for <>; Wed, 28 Aug 2019 02:37:29 -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 B83B1120019 for <>; Wed, 28 Aug 2019 02:37:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dk12062016; t=1566985049; bh=VtyMcq4ZK52u5BW6UqucrOGliRIrxecgzfYv MBmLg88=; h=Received:To:From:Subject:Date:MIME-Version:Content-Type: Message-ID:X-ELNK-Trace:X-Originating-IP; b=N9mLT6Rbr4NYyCd5TTN8qA BgCdh28G1ppvyelUpbZG5skQuB1FfoszDO3yEek1sw002Yrn2xTH1OHpxkm11vhHxZ5 OtW0w5JPhTX0vh3HrUH5MU5dnFLNshL5pJ+bgW24b6X71ZydS7ROIMjdroAHTtoKzxv zu7AltBFXch9ybGD/qD27JGi+a0nP0cCsNyxp8HfB26wAWRmmaem1v5ydsEfFhTYoos Pr7MHNr+P7Bxc6UUlg33rTmh4yGKJfDsPvsFtd/uIpmOT41lcNDa7pK6vy6xDhsViNZ fOA2TyRSzd6DUsyrhz6E5rdtQxfsvW9WJn8rHkNV9Zdg+EHf4i7A==
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk12062016;; b=DoDAkzBJpKQk0D4uIrTcIZdf4+Vp0CoEo5b2HA1Qgwn76l58IAY5U3h5vtTiDKoLokSG0jF7HgmNLzuPR0nVNE+CznOiTUdCkmuCBt5N5sTQa6gZ4ZYTBsmmAEvPnnr5rMX7RBJeycAQVA1X78isWXRr4aPc8OYfrMZT0GbqiP0F4NXepGdSmXSA/gcpwtweDeVXb+lGOy2KEXMLLbhQOMedmO5ST4uPhCGGPhC8lm5sJINOAuvHd23GxNa3if357dXLHSEUQv4zWNXekAJmfVtcw0W8PzGEEkdxYwik5nvPbo0tpf4WTCnRIqgif2RbckGxjXOBnYm+m5I7TZxdyA==; h=Received:To:From:Subject:Date:MIME-Version:Content-Type:Message-ID:X-ELNK-Trace:X-Originating-IP;
Received: from [] (helo=[]) by with esmtpa (Exim 4) (envelope-from <>) id 1i2uON-000GI1-Tr; Wed, 28 Aug 2019 05:37:28 -0400
To: "=?utf-8?B?SGVpa28gR2Vyc3R1bmc=?=" <>, "=?utf-8?B?S2FyZW4gTydEb25vZ2h1ZQ==?=" <>, "=?utf-8?B?bnRwQGlldGYub3Jn?=" <>
From: "=?utf-8?B?dGdsYXNzZXlAZWFydGhsaW5rLm5ldA==?=" <>
Date: Wed, 28 Aug 2019 12:37:26 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_Part_0_1566985046451"
Message-ID: <>
X-ELNK-Trace: 01b7a7e171bdf5911aa676d7e74259b7b3291a7d08dfec79d428bba067bb8320c2171ba8516b5d20350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c
Archived-At: <>
Subject: Re: [Ntp] =?utf-8?q?Calls_for_Adoption_--_NTP_Extension_Field_drafts?= =?utf-8?q?_--_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: Wed, 28 Aug 2019 09:37:35 -0000

Agreed. Fix all or build new version 

Sent from my HTC, so please excuse any typos.

----- Reply message -----
From: "Heiko Gerstung" <>
To: "Karen O'Donoghue" <>rg>, "" <>
Subject: [Ntp] Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
Date: Wed, Aug 28, 2019 09:54


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