Subject: [Ntp] Benjamin Kaduk's No Objection on charter-ietf-ntp-03-00: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 27 Oct 2021 21:26:08 -0700

Benjamin Kaduk has entered the following ballot position for
charter-ietf-ntp-03-00: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/charter-ietf-ntp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I don't see milestones (either existing or proposed) for interleaved mode
or alternative selection algorithms.

  Good quality time is a key component of all modern systems, devices, and
  applications. This quality time requires reliable and accurate network time
  synchronization over modern IP-based networks.

"[Good] quality time" is probably a term of art for the WG members,
but is also used in informal English to mean something completely
different.  I don't know if it's worth the effort of rephrasing to
be able to specify which of
accurate/precise/reliable/regular/stable/synchronized are the specific
relevant attributes.

  The working group will continue to to address the maintenance of NTPv4
  including extensions and corrections. This includes the introduction of a
  interleave mode in order to enhance the accuracy of the network time
  synchronization and the introduction of alternative selection algorithms
  in order to enhance robustness against delay attacks.

Are "selection algorithms" just "clock selection algorithms" or something
else?  It might be worth clarifying.

  Despite its increasing importance, NTP remains vulnerable to many types of
  attacks. [...]

(nit) This seems like a strained connection; a protocol's (in)vulnerability
is a function of the specification work it receives, not its importance.
The latter might drive some of the former, but it's not guaranteed.

  The working group will work on extending NTS to
  cover the remaining modes of service for NTP not covered by the initial
  version.

It looks like we would still be using the existing NTPv4 codepoint for this
NTS application, so maybe s/initial version/initial specification/ is
better.

  * NTPv5 specificaition(s)

Hmm, looks like https://www.rfc-editor.org/errata/eid6588 is catching.