NTP Working Group @ IETF 122

Tuesday, 18 March 2025
15:30 - 16:30 ICT (UTC+7)
Boromphimarn 4

Draft Agenda

The shepherd’s writeup will soon be completed. It will contain a
note that this document has been coordinated with the IEEE 1588
Working Group.

We conducted a WGLC
No update for quite a while. It has expired.
The datatracker version is outdated compared to the Github version.
We currently are seeking for an additional editor. If you’re
interested in this role, please step forward and send me an email.

We need some additional review. Especially for the refid based on
Bloom filters. David has already provided suggestions for its
improvement.

Discussion:

David Lou: Are there any documents related to algorithms, adding
clocks, and different timestamp formats.
Karen: There are no specific documents rabout that with respect to
NTPv5.
David Lou: The reason I ask is that although the timestamp helps we
have rough ideas that other timestamps may improve the accuracy of
the time synchronization. The NTPv5 specification includes an
extension field for additional timestamps. I want to ask what kind
of algorithm are attached to that.
Karen: There are no algorithms to these timestamps at this stage.
David Lou: What is the justification of these timestamps EF. Can we
propose a different timestamp format?
Karen: This EF is not meant to change the timestamp format used by
NTP itself.
David Vanhoek: NTPv5 is only the on-wire protocol. It is doing the
transport only. It does not specify how to steer the clock. The
reference timestamp extension field reflects the NTPv4 reference
time stamp. It is not required.
David Lou: Our goal is to improve the accuracy of the time
synchronization. The reference timestamp EF may support this. We
intend to participate in the Hackathon in July and present our work
at the upcoming IETF meeting.
Karen: That would be excellent. I want to reinforce what David was
saying. It is our intention to separate the protocol from the
algorithms. The protocol does only do the time exchange. How this
information is used can be specified in further documents. That
allows us to define specific algorithms for specific use cases.

Uploaded a new version -01 last month
Editorial changes have been made, including the removal of
unnecessary language to reduce the total number of pages.
Replay protection has been added. How to transmit security data
between PTP nodes.
Its not finalized yet. There are some decisions outstanding from the
IEEE 1588 Security Subcommittee.
IANA and Security Considerations are still missing.
Need still some optimization. But is it pretty finalized.
We are working on a reference implementation. First test are planned
for July.
We received comments from Miroslav.

Discussion

Karen: time frame for the next update of the document.
Martin: Probably July. Time frame depends on decision made in IEEE.
David: The document contains a table of Mac algorithms and Ids. Will
bring it up in SAAG meeting later this week.
Karen: The plan is to have a hackathon project at the next IETF.

We are currently working on the specification and its
implementation.
Karen: WG Chair's hat off: Once you’re ready to try out an
experimental pool, I have some potential participants.

Karen presents work at P1588 wg

Rollup revision is starting.
Draft for a Enhanced Security for IEEE 1588 (Fixes to Authentication
TLV, extension to allow NTS for PTP)
IEEE 1588.1 Client-Server PTP (CSPTP). Simplified version of PTP
that looks more like NTP (Client-Server and unicast). Currently,
there are various proposals for CSPTP. If the baseline of CSPTP is
determined we immediately start to add NTS to it.

ITU-R is looking at the issues of leap seconds. BIPM is looking for
input from SDOs on how decisions about leap seconds are associated
with their work.
I've spoken with some IAB members on how to submit a statement of
our feelings on leap seconds.
IEEE 1588 is working on a statement. IETF's statement could be
similar. I will at least indicate that we as a SDO may be impacted
by any decision taken. Anybody is welcome to contribute.

Discussion:

Erik: is anything about that work public?
Karen: I'm not sure. I'm not in those meetings.
Martin: Kristof is currently at a ITU-R meeting. He wants to discuss
this topic on the mailing list.
Karen: Kristof did send a mail about these activities to Doug and
me. He provided some documents about ITU-R resolution 655. But I'm
not sure about the status of these documents. I hope Kristof might
provide additional information at the next interim.
Please contact me if you want to provide contributions.
David Venhoek: How does the ITU-R discussion relates to the decision
of the BIPM about leap seconds from last year?
Karen: Decision is an ITU-R decision. BIPM made recommendation. I
not followed closely though; this is not a new topic in ITU-R.