[Ntp] Antwort: Re: Re: Making summary comment Kristof

[[e-mail]]

Hey David,

many thanks for doing this.

Yes, your summary and ordering looks good.

I haven't checked what the comments said that you left out in the summary, everything essential looks to be there, thanks :) 

#2d is fine as non-blocking (the WG has seen it again so there is an opportunity to discuss, but that can be all).

Perhaps even #2c is debatable as being a blocking issue, but I've heard at least one person other than Martin or myself say that it should be clarified (also it seems very little work to clarify it). 

Besten Gruß / Kind regards,
Kristof Teichel

__________________________________________

Dr.-Ing. Kurt Kristof Teichel
Physikalisch-Technische Bundesanstalt (PTB)
Arbeitsgruppe 4.42 "Zeitübertragung"
Bundesallee 100
38116 Braunschweig (Germany)
Tel.: [phone]
E-Mail: [e-mail]
__________________________________________

-----"David Venhoek" <[e-mail]> schrieb: -----

An: [e-mail]
Von: "David Venhoek" <[e-mail]>
Datum: 17.12.2023 12:51
Kopie: "James" <[e-mail]>
Betreff: Re: Re: Making summary comment Kristof

Dear James, Kristof,

Below a summary of Kristof's emails AFTER his first set of comments.
This focuses primarily on the actionable issues. There is one point
where I have added a little bit of James reply in the mix just to make
this more clear, but for the rest it should all only reflect Kristof's
text. In a number of places I have copied directly from his original
emails, those are marked by text in  <<>>.  Apologies in advance for
the spelling and grammar mistakes, hope they aren't to distracting but
just don't have the time to go over my own mail another time right
now.

Kristof, I have the following specific questions left for you:

There were a number of comments around data minimization and resource
management that felt like they were more aimed already at the
discussions for how to actually do this, rather than what we want on
this front. I have left these out of the summary here if that is ok
with you?
Also, I have moved #2d to non-blocking due to your comments on the
previous consensus calls, please correct me if that is not what you
intended. I can also send the explanation I gave during the meeting in
a mail on the list if you would prefer to have that part more
documented?
Other than that, can you quickly check the summary to see if I missed
any points and if everything is classified correctly?

Also, feel free to repost this summary to the general mailing list if
you think it is useful for others to also have access to, Kristof.

Hope it will be useful.

Kind regards,
David Venhoek

Summary
=======

Blocking issues:
----------------

#1 Lack of clarity from the document on it's role in the process.
  - Does it regulate the spec (the document), the implementations (the
code), the userbase, or something else
  - Short statement stating which it is could go a long way.

#2a Use cases:
- Missing overal description, something along lines of "NTP used to
sync large amounts of computers via open (internet-like) networks"
- Potential to misread, especially around comments towards PTP and
being diminutive towards NTP.
Causes misread (quote):
<<"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)>
Suggestion:
- Different start to set different tone?
- More focus towards NTP is norm
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.">>
Then go into specific use cases after.

#2b Threat analysis
- RFC7384 reference rather than copy and summarize here

#2c Timescales
    - Missing clarity that UTC is not ok as linear, monotonic timescale

#3a Tensions in requirements
- Tension between requirements on resource management, data minimization
- Tension between requirements on resource management, security
proposed solution: something like <<"Realizing data minimization and
resource management at the same time might be difficult, as the ends
used to achieve them tend to work against each other">> and similar
for the other conflicts.

#3b Security, tension between upgradeability and ruling out downgrade
attacks. Quote:
<<
Maybe I'm just being dense, but I don't see how one can possibly allow
upgrading but also completely prevent downgrading (at least to the
specified 'baseline').
Perhaps this is another issue where I don't understand if the document
is intending to regulate the NTPv5 standards track RFC, or
implementations, or something else.
I would really like to understand this, as it seems like a blocking
issue with my current degree of (non-)understanding of it.
Currently, I'm afraid someone will sit there and be unable to check
all MUST requirements as fulfilled, because it might be impossible to
fulfill all at the same time.
>>

#3c Require a single security mechanism to be supported by all clients.
    - Suggestion: <<"The specification MUST settle on a defined set of
supported security schemes so that it is guaranteed that any two
implementations have a way to established secured exchanges.">>

Non-blocking issues:
--------------------

Use of normative language is inconsistent.
Reply (james):
 - Use of normative vs non-normative is intentional. Let's not remove
all or make all normative
 - Use of SHOULD is intentional, reflects potential for circumstances
Re-reply (kristof):
 - Perhaps replace non-normative should with ought or similar so as
not to cause confusion.
 - Non-capitalized must also occur, are those really intentional?

Confusion about requirements applying to protocol implementation:
Perhaps somewhat pedantic, but examples:
4.1 "Clients SHOULD periodically re-establish connections with servers"
"Servers SHOULD be able to migrate and change  any identifier used"
4.6 "Servers that support multiple versions of NTP MUST send a
response in  the same version as the request"


Algorithm separation text seems an allusion to working group actions,
suggest doing this through an explicit statement of scope. Quote: <<If
we can agree to add a sentence earlier to the effect of 'this document
is supposed to be an orientation for how the upcoming NTPv5 standards
track RFC is to be written', then we can for the current point just
add one line
"The NTPv5 RFC should/SHOULD cover the on-wire protocol only;
processing algorithms and clock disciplining techniques can be covered
in separate documents.">>

Section use cases: Some of the text appears to be setting up things
that are never referenced in the document again. Examples:
    - different kinds of ntp servers
    - kinds of deployments

Section leap seconds: 24 hours before explanation is clunky, add one
sentence clarification?
suggestion: <<"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.">>

#2d Leap seconds
- Disagree with statement around leap smearing SHOULD be supported and
MUST be dealt with. Potential issue with clients having to
indefinitely carrying support.
- Is the result of concensus call, so maybe not reopen

Requirements section:
    - Some confusion around "basic time information"
    - Source: unclarity about intent to sue NTPv5 protocol for
non-synchronization <<(e.g. just for asking "what time is it", or
something)>>
    - If not above, maybe remove the 'both' just before "basic time
information".
    - No concrete suggestions or need for changes

Non-requirements section seems prone to misunderstanding:
  - Would expect the document to refer to WG consensus
  - Like having the section though.

On Fri, Dec 15, 2023 at 11:35 AM <[e-mail]> wrote:
>
> Hey,
>
> definitely no issues from my side.
> I can be available for a webcall sometime between Monday and Wednesday next week.
>
>
> Besten Gruß / Kind regards,
> Kristof Teichel
>
> __________________________________________
>
> Dr.-Ing. Kurt Kristof Teichel
> Physikalisch-Technische Bundesanstalt (PTB)
> Arbeitsgruppe 4.42 "Zeitübertragung"
> Bundesallee 100
> 38116 Braunschweig (Germany)
> Tel.: [phone]
> E-Mail: [e-mail]
> __________________________________________
>
>
> -----"James" <[e-mail]> schrieb: -----
> An: "David Venhoek" <[e-mail]>
> Von: "James" <[e-mail]>
> Datum: 15.12.2023 10:30
> Kopie: [e-mail]
> Betreff: Re: Making summary comment Kristof
>
> Sure, I would greatly appreciate it. I can be available to talk if need be.
>
> Alvast Bedankt,
>
> - J
>
> > On 15 Dec 2023, at 10:21, David Venhoek <[e-mail]> wrote:
> >
> > Dear James, Kristof,
> >
> > Since we didn't really reach a yes or no on this during the meeting
> > yesterday: Would it help you and would you like me to try to make a
> > summary of all Kristof's comments and make an actionable list for
> > them? I will have some time for this today till 12:30 and then some
> > more on Sunday.
> >
> > Kind regards,
> > David Venhoek
>