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

["Ulrich Windl" <[e-mail]>]

>>> Heiko Gerstung <[e-mail]> schrieb am 28.08.2019 um 08:54
in
Nachricht <[e-mail]>:
> 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:    [phone]
> Fax:        [phone]
> 
> Amtsgericht Hannover 17HRA 100322
> Geschäftsführer/Management: Günter Meinberg, Werner Meinberg, Andre 
> Hartmann, Heiko Gerstung
> 
> Email:
>  [e-mail] 
> 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" 
> <[e-mail] im Auftrag von [e-mail]> 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
>     [e-mail] 
>     https://www.ietf.org/mailman/listinfo/ntp 
>     
> 
> 
> _______________________________________________
> ntp mailing list
> [e-mail] 
> https://www.ietf.org/mailman/listinfo/ntp