Minutes IETF114: ntp
minutes-114-ntp-00
Meeting Minutes | Network Time Protocols (ntp) WG Snapshot | |
---|---|---|
Date and time | 2022-07-27 14:00 | |
Title | Minutes IETF114: ntp | |
State | Active | |
Other versions | markdown | |
Last updated | 2022-08-10 |
NTP WG Meeting @ IETF 114
Wednesday, 27 July 2022,1000-1200 (1400-1600 UTC)
Independence C
-
Administrative and Agenda Bashing
- Karen: Note Well and IETF 114 Meeting Tips
- Minutes: Dieter
- No agenda bashing -
NTP/TICTOC WG Document Status Review/Update (Chairs)
-
YANG Data Model for NTP has been published as RFC 9249. Thanks to the authors, especially to Dhruv who really persisted through the entire process.
-
Two documents in IESG process
- Interleave Modes
- Mode 6 cmds
-
WGLC for the Chronos document has been issued. Please review and comment on the mailing list.
-
Two documents waiting for shepherd write-up
-
Update registries. In the last interim we agreed that the document is ready to be passed to the IESG. During shepherd write-up review it was decided to change it from informational to standards track because it updates several standard tracks documents. We will do a very short WGLC on this specific issue. There was no opposition with this plan of action.
-
PTP Enterprise profile. We've gotten approval from the IEEE to share the underlying specification (IEEE 1588) for the purpose of reviewing this document. There is going to be a terminology issue with this document as we pass it through the IESG. Its terminology is based on the 1588 specification which uses the concept of master and slave clocks. This probably will be problematic during review. The 1588 working group has an active PAR that is addressing this issue and is making progress. For the purpose of moving this document forward we will reference the IEEE PAR with the understanding that this IETF document is a profile of the 1588 specification. We will be using the language that is in the current 1588 specification with the understanding that the 1588 working group is updating the language. This document can be updated at a later date to reflect the updated language.
- Denis: (also member of the 1588 working group). The current text still uses the old language, and we will note in the write-up that if the alternative terminology amendment gets approved, we will change it?
- Karen: We are not committing to go back and update the document. We are just saying that we apply the current language used and that we understand that this language is going to be updated. We advise implementors to refer to the work of 1588 wg to see what the updated language would be.
- Karen: If the 1588 wg publishes new terminology before this document goes forward, we can update the terminology of this document. It is even possible to update is later as a new RFC if someone is willing to do the work.
-
-
-
NTP v5 use cases and requirements
- James: New version published as working group document. Some editorial changes and nits. Please provide comments on the mailing list.
- Dieter: Did you consider the thread model of RFC 7384 "Security Requirements of Time Protocols in Packet Switched Networks" for the section 5 of this document?
- James: I wasn't aware of it. I will consider it.
- Karen: That was the requirements document that was done prior to NTS. Would be worth to look at.
-
NTP Registry update draft
This topic was already considered in topic 3 (WG Document Status Review/Update)
-
Work with no updates:
-
Roughtime
- Originally wanted to have a hackathon effort on this document.
- No further comments or questions
- Karen: Interested to get implementations experience on it. It would be possible to plan a hackathon effort during IETF 115.
-
NTP v5
- Karen: The requirements draft is adopted as wg document. We could consider this document for adoption call.
- Mirsolav: There have been some discussions about conformity between this draft and the requirements draft. There have been some issues I already forgot.
- James: I did some analysis of what Doug has been provided. There were only two or three things where the draft didn't meet the requirements. That was against the previous version. I will re-evaluate that against the current version. We can talk about that on the mailing list.
- Karen: Do you think it is worth to have an adoption call now or do you want to wait longer?
- Miroslav: Not sure.
- Karen: I think we should go ahead and do a call for adoption. Then we have both documents side-by-side.
- James: According to Doug's spread sheet there are five things that are outstanding. With that I think the document is suitable for adoption. These issues can be worked out later.
- Karen: will proceed with an adoption call for the NTPv5 document
-
NTP Over PTP
- Karen: Next steps?
- Mirsolav: It is ready for adoption. There is work needed for some issues with the PTP sequence id.
- Karen: Adoption call will be issued.
-
NTS for PTP
- There have been two proposals on the table. These shall be merged into a single document. That has not been done yet. We are waiting for the primary authors.
-
-
AOB
-
Miroslav: NTPv5 - Local timescale
- Does it make sense to support local timescale for NTPv5? Request from some users.
- Karen: Any comments?
- James: Put it on a list as a topic to be considered.
- Denis: It is worth discussing. We need to understand the different use case involved. I can understand the motivation behind that. There is more than one way to do that. Do we want to transfer different time scales over the wire or will it be sufficient to have a field on the client side that provides the translation?
- Karen: This topic shall be discussed on the mailing list
-
Karen: Virtual interims
- We plan to have a virtual interim monthly.
- We need to look for a hackathon effort in November (IETF 115)
-
Karen: Based on the next few virtual interims we will need to decide if we request meeting time at IETF 115
- Erik: do want people to meet on IETF 115
- Karen: A number of regular participants are not here. Difficult to answer this question.
- Karen: This will be decided in the next month or so.
- It would be good to ask for some implementor or operator reports for NTS at a future meeting.
-