Network Time Protocols
charter-ietf-ntp-04

Basically fine. Some nits and suggestions below, take ‘em or leave ‘em.

1. Regarding Éric’s comment about “most widely used”, another option would be to change it to say “it is a widely-used time synchronization protocol”, which I think is indisputable and still gets the job done.

2. I agree with Ben that the references to “quality time” in the first ¶ is a bit jarringly un-idiomatic. The rest of the ¶ implies that what’s meant is that time synchronization must be “reliable” and “accurate”. 

3. Is the “shall” in the ¶ about NTPv5 actually intended to be read as an insistent directive to the WG (as one might express it if the writer were unsure if the WG would actually do the work, and therefore wanted to demand that they have to)? Or is it just used as a synonym for the “will” that appears elsewhere? I’d stick with “will” unless the intention really is to communicate insistence. (Compare to the way we use RFC 2119 “SHALL”, for example — would this ¶ scan well if “shall” were replaced with “must”?)

4. s/Finally, the working group, will address/Finally, the working group will address/ (lose the second comma)

Since the charter specifically calls out security as an ongoing concern, would it be prudent to add a Security AD as a technical advisor?

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.

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Paragraph 2, nit:
- (NTP), and specifying new network time related protocols or extensions for
-                                  ^    ^
- purposes which the existing protocols are not well suited to address.
-          ^ ^^^
+ (NTP), and specifying new network-time-related protocols or extensions for
+                                  ^    ^
+ purposes that the existing protocols are not well suited to address.
+          ^ ^^

"NTP ", paragraph 1, nit:
- in 2010. Today it is the most widely used time synchronization protocol for
+ in 2010. Today, it is the most widely used time synchronization protocol for
+               +

"NTP ", paragraph 1, nit:
- success it has become apparent that it needs further development in order
+ success, it has become apparent that it needs further development in order
+        +

"NTP ", paragraph 1, nit:
- protocols and to meet the increasing security threats of the Internet.
-                                                        ^
+ protocols and to meet the increasing security threats on the Internet.
+                                                        ^

"NTP ", paragraph 2, nit:
- The working group will continue to to address the maintenance of NTPv4
-                                ---
- including extensions and corrections. This includes the introduction of a
+ The working group will continue to address the maintenance of NTPv4,
+                                                                    +
+ including extensions and corrections. This includes the introduction of an
+                                                                          +

"NTP ", paragraph 3, nit:
- attacks. Therefore, in 2020 the working group published Network Time
+ attacks. Therefore, in 2020, the working group published Network Time
+                            +

"NTP ", paragraph 4, nit:
- weaknesses. The new specification shall comprise of a set of documents, in
-                                           ^^^  ^                       ---
- order to distinguish between the on-wire protocol engine and the timing
+ weaknesses. The new specification shall consist of a set of documents,
+                                           ^^  ^
+ separating the on-wire protocol engine from the timing

"NTP ", paragraph 5, nit:
- Finally, the working group, will address other network time related
-                           -                           ^    ^
- protocols in the IETF (e.g. roughtime) as well as work on items brought to
-                                                                -----------
- the group from other standards bodies (e.g. IEEE 1588), with the
- acknowledged request to do so from that body.
+ Finally, the working group will address other network-time-related
+                                                      ^    ^
+ protocols in the IETF (e.g., roughtime) as well as work on items
+                            +
+ explicitly and formally requested by other standards bodies (e.g., IEEE 1588).

"NTP ", paragraph 7, nit:
-   * NTPv5 specificaition(s)
-                    -
+   * NTPv5 specification(s)

"NTP ", paragraph 8, nit:
- [1] PTP is the Precision Time Protocol as defined by the IEEE 1588. The
-     latest version is IEEE 1588-2019 - IEEE Standard for a Precision Clock
-     Synchronization Protocol for Networked Measurement and Control Systems.
- Milestones
-
+ [1] "IEEE Standard for a Precision Clock Synchronization Protocol for Networked
+     Measurement and Control Systems," in IEEE Std 1588-2019 (Revision of IEEE
+     Std 1588-2008) , vol., no., pp.1-499, 16 June 2020, doi:
+     10.1109/IEEESTD.2020.9120376.