Re: [Ntp] The bump, or why NTP v5 must specify impulse response

I second that. There are a gazillion use cases out there and a multitude of time sync requirements. A client that needs to time stamp legal documents would want to adjust its own clock very quickly (i.e. maybe stepping it) to be as close as possible to "true" time. Other devices and applications require that steps are avoided at any cost, even it that means the clock is wrong by x and the client nows it. For those clients, there are a lot of different limits in regards to the accepted adjustment rate for the clock, depending on what the clock is actually used for. Most do not want to jump backwards at all, a few may be fine with that as long as it is documented somewhere etc. etc. 

Making it modular would be very useful. It would be great if the protocol could allow to advertise the selected algorithms, which could be standardized on their own (as suggested, a standard/default algorithm that may resemble what NTPv4 does would be required) or at least documented by whoever introduces it. Maybe a registry could be set up or companies would be able to use their IANA OUI's plus a self-assigned ID. 

   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

Am 16.04.20, 19:29 schrieb "ntp im Auftrag von Dieter Sibold" <ntp-bounces@ietf.org im Auftrag von dsibold.ietf@gmail.com>:

    The problem with this combination is that we currently have no 
    implementation that conforms to RFC5905 completely.
    There are different use cases for potential clients. Some of them are 
    not well served with the current algorithm other are. A modular approach 
    would allow both: to apply an algorithm most suitable to the application 
    and to be compliant with the protocol spec.

    Dieter

    On 16 Apr 2020, at 11:58, Harlan Stenn wrote:

    > On 4/15/2020 6:38 AM, Salz, Rich wrote:
    >>>    We had the same discussion at the transition from ntpv3 to ntpv4.
    >>>    If you do this, please do not call it NTP.
    >>
    >> Can you explain why 3->4 could still be called NTP but 4->5 should 
    >> not?
    >
    > You didn't quote enough context.
    >
    > NTP is a combination of two parts:
    >
    > - the protocol/packet structure
    > - algorithmic and response behavior
    >
    > If you are only specifying the protocol in this new thing then it is
    > dangerous/misleading/irresponsible to call this v5 document "NTP".
    >
    > It is only slightly less dangerous/misleading/irresponsible to call it
    > "NTPv5 Protocol", regardless of whether or not there is also an "NTPv5
    > Algorithms and Response Behavior".
    >
    > -- 
    > Harlan Stenn <stenn@nwtime.org>
    > http://networktimefoundation.org - be a member!

    _______________________________________________
    ntp mailing list
    ntp@ietf.org
    https://www.ietf.org/mailman/listinfo/ntp