Re: [Ntp] WGLC - draft-ietf-ntp-ntpv5-requirements

On Thu, Dec 14, 2023 at 2:29 AM James <james.ietf@gmail.com> wrote:

> My responses inline.
>
> > On 14 Dec 2023, at 01:45, Steven Sommars <stevesommarsntp@gmail.com>
> wrote:
> >
> > My interpretation of the draft NTPv5 requirements is that there are
> intentionally no NTPv4 compatibility requirements.
> > E.g., the base payload length may not be 48 bytes, the messages may
> differ from NTPv4.
> > If this is not the intention, the draft should be updated accordingly.
> If no consensus can be reached the NTPv5 requirements should state this
> clearly and work on the NTP protocol itself should be paused.
>
> There is no intention for any such compatibility

Thanks for the confirmation
I agree with Harlan: don't use the term NTPv5 in this document.  Perhaps
XTP for experimental time protocol, until a better term is coined.

> - Section 4.6 outlines what should be considered. Servers and clients
> should have defined behaviour based on the version number primarily. I'm
> not sure why payload length is of concern here - could you please elaborate
> as to why?
>
I was trying to stress the potential for incompatibility with NTPv4.

>
> > Section 3.  NTP is considered by some to be a hostile protocol. As a
> result there has been  intentional blockage on some paths.
> > NTP Filtering (Delay & Blockage) in the Internet
>
> Are you proposing text be added, removed, edited?
>
Suggestion:
A new port should be utilized for this protocol, not UDP 123.
UDP 123 has seen significant blockage/filtering in recent years.

>
> > 4.4 Timescales
> > UTC is neither linear nor monotonic.
> > NTPv4 has insufficient resolution  today for root dispersion and root
> distance.
>
> The requirements state both representation of UTC and TAI be supported - I
> see no reason that with a linear , monotonic timescale + offsets one could
> not generate. Is my understanding wrong, have I missed something here?
>
I'm not following. Section 4.4 leads off with the linear&monotonic
statement. UTC will not be monotonic until leap seconds are abolished.  If
the emphasis is that UTC is supported, then please rearrange the wording.

Please discard the statement about insufficient resolution.  That more
properly belongs in Miroslav's list.

>
> > 4.5 Leap seconds.
> >
> > Smeared leap seconds were and remain a workaround for various real-world
> implementation issues.
> > I believe that much of this mechanisms success comes from the ease of
> deployment (unmodified clients, changes are limited to the server).   This
> section suggests that the 2016-era leap second smearing would be
> incompatible with NTPv5.
> > If there is another leap second, it seems to me more likely that admins
> will use the 2016-style leap second smearing.
> >
> > The 2016-style smearing may result in less accurate time transfer.
> >
> https://kb.meinbergglobal.com/kb/time_sync/leap_seconds/leap_second_testing/leap_second_testing_-_introduction
>
> The inclusion of leap second smearing has been of considerable debate and
> working group consensus, the conclusion of which was to include their
> support. I believe the text as it stands will permit the use of full leap
> second adjustment, smearing, or neither. I do not understand how the text
> would be "incompatible" - can you please elaborate further?
>

In the 2016 google-style smear the client was isolated from knowledge of
the pending leap second.

The draft states;
   specification MUST require that servers transmit upcoming leap
   seconds greater than 24 hours in linear timescale in advance if that
   information is known by the server.

 These appear inconsistent.

> > Per Wikipedia
> > " in November 2022, at the 27th General Conference on Weights and
> Measures, it was decided to abandon the leap second by or before 2035"
>  It seems that by the time NTPV5 becomes final, plus client and server
> implementations are deployed, it will likely be too late for a new leap
> second smearing mechanism to be used.
>
> There are other important issues.    I should have pointed to the
important ITU article
https://www.itu.int/en/itunews/Documents/2023/2023-02/2023_ITUNews02-en.pdf

There is a proposal to replace leap seconds by leap minutes.

> 2035 is currently over a decade away. I hope NTPv5 sees deployment in the
> immediate years. I think supporting it is required. Should leap seconds
> never be added going forward, is there any specific issue with having them
> supported?
>
> There is a cost to adding capabilities that are never used. to
specifications and implementations.
It will slow the development of both.    [If leap seconds were deemed
inevitable this group should undertake some action.]

The current (2016) mechanism can be used if a leap second somehow sneaks in
before leap seconds are eliminated.    A "best practices for leap second
smearing" could be developed, possibly by this group.

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