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

[[e-mail]]

I recommend starting by identifying the top level subsystems and defining the interfaces among them, as Kristoff has suggested.

I would propose as a next step to define implementations of each subsystem which meet the needs of the most common NTP applications, for example, synchronizing server and router clocks for log file entry timestamps.  This default implementation needs to be simple to configure, robust, and work over the public internet and typical enterprise networks.  It does not need to be super accurate or work over some specialized network, like a high frequency trading system.

Specialized use cases can have different implementations for one or more of the subsystems, although I would expect that we want to keep a few things consistent, such the over the wire packet format, and message sequence to collect 4 timestamps at a client or a higher stratum number server.

Doug


________________________________
From: ntp <[e-mail]> on behalf of Harlan Stenn <[e-mail]>
Sent: Friday, April 17, 2020 3:48 AM
To: [e-mail] <[e-mail]>
Subject: Re: [Ntp] The bump, or why NTP v5 must specify impulse response

On 4/16/2020 2:44 PM, Daniel Franke wrote:
> On Thu, Apr 16, 2020 at 5:13 PM Harlan Stenn <[e-mail]> wrote:
>> There are cases with regulatory requirements here.
>
> What regulations govern NTP's clock synchronization algorithm?

Who said the regulations govern NTP's clock synchronization algorithm?

>> There are liability risks.
>
> Who risks being liable to whom for what?

If there is a requirement that time be disciplined by NTP and the
governing NTP spec describes algorithms and behavior and you are running
something that behaves differently, then you are non-compliant, and liable.

If you KNOWINGLY run something that is non-compliant, this may escalate
the violation to the level of fraud.  This may trigger treble damages.

But that's not quite the point here.

More to the point, NTPv4 and all of its predecessors specified:

- the packet format
- the algorithms
- a set of behavioral limits and specifications

This means others were allowed to write specifications (regulations)
assuming and/or relying on "NTP" - the packet format, algorithms, and
behavior.

Removing or separating the algorithmic and behavioral specifications
from the NTP specification at best cost-shifts that discussion
elsewhere, and I submit it does this to groups that are likely
completely unaware that they can no longer rely on behavior that they
had no idea they previously relied on.

Are you planning to just do a protocol spec and "do the algorithms and
behavior spec later", or worse yet, let others do that if they think
it's important?

--
Harlan Stenn <[e-mail]>
http://networktimefoundation.org - be a member!

_______________________________________________
ntp mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ntp