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

"Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de> Wed, 28 August 2019 08:20 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 5E54C120876 for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 01:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mZTZgKnqngmQ for <ntp@ietfa.amsl.com>; Wed, 28 Aug 2019 01:20:02 -0700 (PDT)
Received: from mx2.uni-regensburg.de (mx2.uni-regensburg.de [IPv6:2001:638:a05:137:165:0:3:bdf8]) (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 2C1AA1200A4 for <ntp@ietf.org>; Wed, 28 Aug 2019 01:20:02 -0700 (PDT)
Received: from mx2.uni-regensburg.de (localhost [127.0.0.1]) by localhost (Postfix) with SMTP id 630B5600004E for <ntp@ietf.org>; Wed, 28 Aug 2019 10:19:59 +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 4334E600004D for <ntp@ietf.org>; Wed, 28 Aug 2019 10:19:58 +0200 (CEST)
Received: from uni-regensburg-smtp1-MTA by gwsmtp.uni-regensburg.de with Novell_GroupWise; Wed, 28 Aug 2019 10:19:58 +0200
Message-Id: <5D66392D020000A100033273@gwsmtp.uni-regensburg.de>
X-Mailer: Novell GroupWise Internet Agent 18.1.1
Date: Wed, 28 Aug 2019 10:19:57 +0200
From: "Ulrich Windl" <Ulrich.Windl@rz.uni-regensburg.de>
To: "ntp@ietf.org" <ntp@ietf.org>,<odonoghue@isoc.org>, "Heiko Gerstung" <heiko.gerstung@meinberg.de>
References: <1B4A56E7-16A6-4767-9268-BCF4BEB9A247@isoc.org> <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de>
In-Reply-To: <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.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/Z5WPMHQx-okEb2lunqytaTS2xF8>
Subject: [Ntp] Antw: Re: Calls for Adoption -- NTP Extension Field drafts -- Four separate drafts
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <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: Wed, 28 Aug 2019 08:20:05 -0000

>>> Heiko Gerstung <heiko.gerstung@meinberg.de> schrieb am 28.08.2019 um 08:54
in
Nachricht <BCA949D7-7D92-43A9-9766-573559A9FC70@meinberg.de>de>:
> Hi,
> 
> 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. 

Hi!

Still I guess with a REFID as extension field could provide a solution
"sooner" as NTPv5, and it could be available in selected NTPv4 servers in the
near future.

> 
> 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). 

Just a random thought: Would it make sense for NTPv5 to create a completely
new packet format, or should NTPv5 be based on extension fields? Some old
clients could still try to interpret a new format with old rules (inoring the
version number). With extension fields the old clients could use NTPv5
"somewhat" (ignoring all true v5 additions), while with a new format those
clients will have a problem.

Regards,
Ulrich

> 
> 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
> 
> 
> -- 
> 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
> 
> Email:
>  heiko.gerstung@meinberg.de 
> Web:
>  Deutsch   https://www.meinberg.de 
>  English    https://www.meinbergglobal.com 
> 
> Do not miss our Time Synchronization Blog:
>  https://blog.meinbergglobal.com 
> 
> Connect via LinkedIn: 
> https://www.linkedin.com/in/heikogerstung 
>  
>  
> 
> On 28.08.19, 05:38 "ntp im Auftrag von Karen O'Donoghue" 
> <ntp-bounces@ietf.org im Auftrag von odonoghue@isoc.org> wrote:
> 
>     Folks,
>     
>     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. 
>     
>     Thanks!
>     Karen and Dieter
>     
>     1.  Network Time Protocol Extended Information Extension Field
>     https://datatracker.ietf.org/doc/draft-stenn-ntp-extended-information/ 
>     
>     2.  Network Time Protocol I-Do Extension Field
>     https://datatracker.ietf.org/doc/draft-stenn-ntp-i-do/ 
>     
>     3.  Network Time Protocol MAC/Last Extension Fields
>     https://datatracker.ietf.org/doc/draft-stenn-ntp-mac-last-ef/ 
>     
>     4.  Network Time Protocol Suggested REFID Extension Field
>     https://datatracker.ietf.org/doc/draft-stenn-ntp-suggest-refid/ 
>     
>     _______________________________________________
>     ntp mailing list
>     ntp@ietf.org 
>     https://www.ietf.org/mailman/listinfo/ntp 
>     
> 
> 
> _______________________________________________
> ntp mailing list
> ntp@ietf.org 
> https://www.ietf.org/mailman/listinfo/ntp