Re: [Ntp] NTPv5: big picture

[Magnus Danielson <[e-mail]>]

Hi Hal,

On 2021-01-02 07:02, Hal Murray wrote:
>>> I'd like the basic document not to include the words "leap second", except 
>>> possibly for a chunk that says we-don't-do-that, look-over-there.
>> I think that might be a mistake, even if I can understand the ambition. I
>> think carrying the leap-second difference TAI-UTC is mandatory, and as such,
>> the reference to that other document, if indeed handled as separate
>> documents, needs to say so. 
> I think this is exposing an interesting area we need to work on.
>
> Both TAI-UTC and security have been nominated as requirements.  Yet a TAI 
> based protocol makes perfect sense without either.

I agree. Using a core time-stamp being TAI-related makes immense sense
for all processing. It will not be "the" TAI though, it will be some
form of engineered time-scale that can be related to TAI. TAI is a very
specific product out of BIPM and we never actually get access to that.
We can however produce technical manifistations that has defined
relation to TAI. The PTP and GPS time-scales does this, both with their
different set of technical gears to fit their technical needs. This is
what I think NTPv5 should do.

Using the well-defined relationship to TAI, we can then use other well
defined relationships to other time-scales, and the requirement to
represent UTC when falls out of TAI from NTPv5 translation, TAI-UTC
information and then UTC from TAI translation. Since the TAI-UTC
relationship is not static, we need to transport that to support it. The
NTPv5 and TAI relationship we just make through definition with only
static relationships, so no additional information will be needed.

However, the continuously increasting monotonic behavior of TAI is
perfect for simple processing of core handling.

>
> I think it will be inappropriate to just drop a MUST in the description.  We 
> need a way to say that most of today's implementations will need them but 
> there are reasonable use cases today and things may change.  I don't want the 
> baggage of a MUST to complicate or distort future work.

It can be discussed where different parts is required. There is many
ways to play the game. I want to make sure that the protocol can
transport all that is needed, and that in the end, for several uses,
those mechanisms will be in place. Notice that the requirement we put on
what a full protocol solution is required to have can be more than what
will require all nodes to support.

Cheers,
Magnus