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

[[e-mail]]

Hey James, hey all,

here my 2 cents regarding point #2

>> 2 Use Cases and Existing Deployments of NTP

>> - We are missing the overall description of NTP being used to sync
>large numbers of computer clocks via open (internet-like) networks;
>we are unsure how helpful the specific example use cases (data
>centers, NTP pool?) are
>
>(#2a) Could you please clarify what you mean here as I do not
>understand - reference to the NTP Pool is just an example of a very
>large deployment of the protocol.
>
>> - The whole implied context of "NTP is what you use when PTP isn't
>available" gives a confusing impression; perhaps add (or replace
>with) a mention of the large numbers (billions of users, probably
>tens of billions of devices) that NTP has;
>
>(#2a) Could you give an example of where you interpret this implied
>context, as I don't interpret my own text in that manner. PTP is
>mentioned as one example, and its name is not used in slander.

I think I might have misread this section.

To be clear: I never thought you the document was slandering PTP, I though it was diminutive towards NTP.

Still, I can tell you why I might have misread here, and maybe we change it lest others have the same problem?

"used to synchronise devices such as customer-premises equipment where reduced accuracy may be tolerable" (Reduced relative to what? Sounded like 'better protocols' such as PTP to me... did you mean the 'publicly accessible NTP services' from earlier?)

"NTP services both for internal use and for customers, particularly where the network is unable to offer or does not require other protocols e.g. PTP" (primary example of where it feels almost diminutive to NTP - I get now that this is probably still meant in the specific context of data centers, where that perspective is a lot more valid)

"and where there may already be familiarity with NTP" (makes it feel IMO like NTP is definitely not the default, but same as above)

Maybe start differently overall, to set the tone?

Because currently, the text still feels like it sees a need to explain under what circumstances one would use NTP - whereas I think NTP use is the norm rather than the exception.
Just about any computing device using most OS's (Windows, MacOS, many Linux distributions, iOS and I'm unsure about Android) is highly likely to have some form of NTP running.

Text suggestion: "If someone is trying to keep the clock in their computing device synchronized, then they are likely using NTP for it. As such, NTP has billions of users and is used on even more devices." And only then go into specific use cases? (Honestly, keeping the current text with something like my suggestion added in front would probably be good enough for me. Or even a comment that the given listing of use cases is not at all exhaustive.)

>> - It feels like half the text in this section is about possible
>issues and/or PTP - without any transition to us wanting to solve the
>issues, or why NTP might ever be preferable. This should be improved
>(Martin and I could help with appropriate text on this).
>
>(#2a) I'm not sure I understand - the document is not intending to be
>a critique of PTP or any issues it may have. What do you suggest the
>text change to?

See directly above for the suggestion.

I would add that I still feel like some of the text appears to be setting things up that are never referenced in the document again (namely the differences between different kinds of NTP servers in §1 and the distinction between kinds of deployments of §1 vs §2). I don't think the text is wrong, I just don't see what it's doing for us, I guess. (Not at all a blocking issue, though)

>> 4.4 Timescales

>> - It seems we should make explicit that "a linear, monotonic

>timescale" cannot be UTC itself.

>

>(#2c) I don't disagree with this, but I don't think this is a deal

>breaker and can address later if need be.

True, but it's also a one-sentence clarification at most, and we could do it sooner (still not a deal breaker for me by any means).

>> 4.5 Leap Seconds

>> - The 24 hour explanation seems clunky. How about "ideally 24 hours

>in advance, otherwise as soon as possible"?

>

>(#2d) There should be normative text here, one of the earlier

>requirements was also around transmitting the LI much earlier than 24

>hours. Could you please propose something with normative language, or

>if you disagree state why?

"The specification MUST require that servers transmit upcoming leap seconds greater than 24 hours in linear timescale in advance if known in time, otherwise as soon as possible."

(This really is just intended to shorten it, though. It's not important to me.)

>> - We don't agree with the statement that leap smearing "SHOULD be

>supported [and MUST be dealt with]" in the specification and the

>implementations and "the protocol".

>> This (specifally the hard requirement for clients to completely

>deal with all aspects of server side smearing) seems to require a

>great amount of work and effort by specification editors and all

>future implementors for supporting a hack that will be opbsolete in a

>few years. At the very least, this seems like a controversial point

>that needs more discussion... We would probably suggest relegating

>this to a separate document (and then more along the lines of 'if

>you're going to smear, do it like X').

>

>(#2d) Leap second smearing and the resulting text was the result of

>an extensive series of discussions spanning years resulting in a

>working group consensus call being made. I disagree that, after we

>have achieved that consensus call, any more discussion needs to take

>place unless others in the working group feel that the consensus call

>and/or subsequent text is a concern. There was discussion at IETF 118

>and suggestion to create an informational document which describes

>smearing algorithms in some detail but this is separate work and I

>don't believe that need be specified in the requirements draft.

That absolutely is a fair point about consensus calls.

I would still like to remind everyone that
"Behaviours for both client and server in handling leap seconds MUST be part of the specification; in particular how clients handle multiple servers where some may use leap seconds and others smearing, that servers should not apply both leap seconds and smearing, as well as details around smearing timescales."

reads like it might come back to bite us.

My interpretation was that both the spec and every NTPv5 implementation ever always needs to carry a bunch of baggage around:

- the communication about possible leap smearing

- the server behavior for leap smearing

- the client behavior for dealing with mixed server pools of smearing & non-smearing servers

... until long after leap seconds (and thus smearing) are a thing of the past (currently scheduled for around 2035, but might be sooner if there threatens to be a negative leap second, which it kinda looks like).

All this for something that one could rightly call a hack in the first place. 

And as Steven pointed out, it is unlikely that the people who do smearing now will respect the new spec in time to adjust their smearing practices.

So the current text might be the WG consensus, but I believe it will be lots of work for everyone involved on our side, while yielding little or possibly no value and I'm unsure if it accurately reflects what we want even now (and semi-sure that we will regret it later if we keep and respect it).

Still not a blocking issue, because you're right - it seems this was WG consensus and re-opening it carries its own problems.

Best regards,

Kristof