NTP Working Group @ IETF 124

Tuesday, 4 November 2025
9:30 - 11:00 am EST (UTC -5)
Notre Dame

Notes: https://notes.ietf.org/notes-ietf-124-ntp

Please check https://datatracker.ietf.org/meeting/124/agenda for an
updated link to the meetecho session.

Draft Agenda

1. Administrative and Agenda Bashing (Chairs, 2 min)

• Note well
• Minutes: DS
• Agenda: No bashing

2. NTP WG Document Status Review/Update (Chairs, 5 min)

Roughtime
https://datatracker.ietf.org/doc/draft-ietf-ntp-roughtime/
Submitted to IESG

NTP over PTP
https://datatracker.ietf.org/doc/draft-ietf-ntp-over-ptp/

• The document has gone through IETF last call and IESG tele chat
• There is still one discuss on it which requires same text for
  registry expert guidelines

NTS for PTP
https://datatracker.ietf.org/doc/draft-langer-ntp-nts-for-ptp/
Before proceeding with this document, the IEEE 1588 security
subcommittee has to resolve same basic open issues. To this end, a
face-to-face meeting is scheduled for December.

3. NTPv5 (Tal Mizrahi, 10 min)

https://datatracker.ietf.org/doc/draft-ietf-ntp-ntpv5/

Presentation:
https://datatracker.ietf.org/meeting/124/materials/slides-124-ntp-ntpv5-update-01

Discussion

• David: Open work regarding greasing of extension fields before WGLC.
• Karen: Please review the document. There is also a Github repro
  where you can send pull requests to.

4. NTS for NTP pools (David Venhoek (remote), 10 min)

https://datatracker.ietf.org/doc/draft-venhoek-nts-pool/

• We have a fully functional experimental pool running.
• The address: experimental.ntspooltest.org
• The draft is updated to match with that implementation
• On major change. Moved away from using TLS certificates for
  authentication in favor for pre-shared tokens due to simpler setup
  and deployment.
• Interested people may add servers to the pool.
• The working group should consider to adopt the document for early
  allocation of extension field types.

Discussion

• David: The working group should consider to adopt the document for
  early allocation of extension field types.
• Karen: Still interested in publishing as experimental?
• David: Yes
• Karen: We will do a call for adoption f on the mailing list.

5. Time Synchronization over QUIC (Garrett McCollum (remote), 10 min)

https://datatracker.ietf.org/doc/draft-mccollum-ntp-tsq/

Presentation:
https://datatracker.ietf.org/meeting/124/materials/slides-124-ntp-time-synchronization-over-quic-tsq-00

Discussion

• Tal: He ask if the resources required for this approach compared of
  using NTP and NTS as been investigated? How does this impact
  scalability and accuracy of clients and servers?
• Garrett: This question has not yet been examined in detail.
• Tal: Port 443. Is your intend to run time sync over port number 443?
• Garrett: Yes. No inference with https thanks to ALPN.
• David: is skeptical about the working group pursuing the project due
  to limited capacity and the time-consuming nature of NTPV5. He
  suggests prioritizing prototype testing to evaluate the feasibility
  and scalability of the project before making a significant time
  investment. He expresses concerns about the scalability of the
  project, particularly in handling a large number of time requests
  per second.
• Miroslav: He ask if it was considered simply to use NTP over QUIC.
• Mark Blanchet: He questioned the premise of "UDP is a problem" as
  QUIC itself uses UDP. The draft should clarify that port 443 is
  generally less filtered than port 123.
• Jeff Houston: He raised concerns about potential added
  latency/jitter from QUIC's user-space processing compared to
  kernel-level NTP.
• Karen: encourage the working group to follow the progress of
  prototype implementation and testing. The working group may decide
  later to specify an experimental RFC.

6. NTPv5 Algorithms (Sarah Grant (remote), 10 min)

https://datatracker.ietf.org/doc/draft-grant-ntp-ntpv5-algorithms/

Presentation:
https://datatracker.ietf.org/meeting/124/materials/slides-124-ntp-ntpv5-algorithms-00

Question for the WG

• Q1. Do algorithms need to be specified, or is referring to RFC 5905
  enough?
• Q2. Is normative text required at all? Is an informative document
  sufficient?
• Q3. Are there any topics not yet included which are needed for
  adoption?

Discussion

• David: Regarding Q2: Decision to separate protocol and algorithm was
  deliberate. We should be careful with normative text on algorithms.
  Implementors should be allowed to make their own choice around
  algorithms. Focus on specifying behavior rather than how to get to
  that behavior.
• Karen: The other question of Sarah is do we want to point to RFC
  5905.
• David: Regarding Q1. No intentions of NTPv5 was to have the
  algorithms implementation specific.
• Karen: The original discussion was about separating algorithms from
  the protocol, not that there would be no algorithms.
• Sarah: The current NTPv5 draft already points to RFC 5905. Do we
  want to elaborate on that and e.g. consider also the errata which
  exist for algorithms in NTPv4?
• David: First: the algorithm in NTPv4 is not specified completely in
  RFC 5905. Second: Is a specified algorithm needed for implementors?
  There is no discussion about algorithms in IEEE 1588, and they are
  doing well. Maybe it is better to cite scientific references.
• Karen: But IEEE specifies most of the behavior of 1588 in various
  profiles.
• Karen: Next step for Sarah: Take this questions to the mailing list.

7. Timestamp extension field (Dr. Ir. Siyu Tang (remote), 10 min)

https://datatracker.ietf.org/doc/draft-tang-ntp-ntpv5-extension-field/

Presentation:
https://datatracker.ietf.org/meeting/124/materials/slides-124-ntp-ntpv5-timestamp-extension-fields-01

Discussion

• Karen: The draft is already online.
• David: What is the advantage of having something separate for the
  raw clock?
• Siyu: It is more stable than clock monotonic. The draft encourages
  using clock monotonic raw if available.
• David: My experience is that clock monotonic raw clock is not a
  stable source of frequency.
• Miroslav: Linux monotonic clock is the POSIX monotonic clock. It is
  impacted by phase correction. Therefore, it is not a good clock to
  be used for this monotonic time stamp in NTPv5.
• Siyu: In our experience, the Linux monotonic clock is quite stable
  and is not impacted by slews of stepping.
• Miroslav: The Linux monotonic clock is not impacted by phase
  corrections, but its frequency is not stable because it is impacted
  by temperature changes.
• Siyu: I agree. If the frequency from the crystal is somehow
  impacted, it must be corrected by some algorithm. This is not yet
  considered in the draft.
• Karen: We move this discussion to the mailing list. @All: please
  provide comments.

8. Are NTP Clients Always Right? (Shreyas Konjerla (remote), 20 min)

Invited presentation from RIPE 91.

Presentation:
https://datatracker.ietf.org/meeting/124/materials/slides-124-ntp-understand-ntp-clients-shreyas-konjerla-00

Discussion

• Miroslav: In the test of how much traffic the client generates. Was
  that over the LAN or Internet?
• Shreyas: It was within a LAN.
• Miroslav: I suppose that may have impacted the results. Over the
  Internet there are larger delays. the results should be adjusted.
• Shreyas: LAN was considered as the best case for the Internet. The
  results would be different but I'm unsure about the significance.
• Karen: Further question please to Shreyas.

9. IEEE 1588 Update (Karen O'Donoghue, 10 min)

Presentation:
https://datatracker.ietf.org/meeting/124/materials/slides-124-ntp-ieee-1588-update-00

10. AOB (5 min)

• Adjourned: 16:56