NTP WG Meeting, IETF 111

IETF 111
Tuesday 27 July 2021, 23:00 UTC
Chairs: Karen O'Donoghue, Dieter Sibold
AD: Erik Kline
Presentation materials: https://datatracker.ietf.org/meeting/111/session/ntp
Jabber Log: https://jabber.ietf.org/jabber/logs/ntp/2021-07-27.html

Administrative and Agenda Bashing

• Note Well: Karen O'Donoghue
• No agenda bashing
• Minutes: Dieter

NTP/TICTOC WG Document Status Review/Update (Chairs)

RFC Editor Queue:

• Port Randomization in the Network Time Protocol Version 4

IESG

1. NTP Interleaved Modes

   • Various issues have been discussed on the mailing list
   • The shepherd write-up provided is for the wrong document
   • Erik: IPR issues with RFC 5905 (indicated by ID-Nit), has to be resolved
   • Erik: Early concerns about whether or not this is safely deployable. Therefore was deferred form the telechat.
   • Karen: Do we need to take this back to the WG or does the IESG need to have
     internal conversation first in order to provide us guidance so that we can take it back to address them.
   • Erik: I didn't had the sense that the feedback coming in had guidance in the form if you do x, y, and z it will be fixed. It seemed to be little more "I don't see how this possibly could work". Implied to me that we need to figure out to show more clearly that it is save.
   • Erik: Not sure if we need to take it back to the WG. It depends on what we decide to do. If we change something then we need to take it back. If we only add a clarifying paragraph then we don't.
   • Erik: We can bring it back to IESG and see what happens and deal with follows thereafter.
   • Karen: Perhaps, we do not pull all way back now but addressing the current comments.
   • Erik: Adding a clear section that explains why this is operational save to do.
   • Daniel: Logical course forward: WG should first address the feedback as far as consensus exists and then figure out whether it has enough no objections to pass and then determine the course from there.
   • Karen: Ok, we will circle back to Miroslav and see if we can do a better job addressing the comments in a coherent manner.

2. A YANG Data Model for NTP

   • The document is waiting for an update from the authors. This is coming as communicated.

3. Control Messages Protocol for Use with Network Time Protocol Version 4

   • That one is waiting on a conversion with Brian; that is also coming.

No further comments on these three documents.

WG calls

Out from the last interim meeting

1. Last call on Alternative Port document: need to be discussed in more detail with a updated document. Miroslav is not here. No questions or comments from the participants.

2. Adoption call for Registry Updates. No oppositions.

   • Rich: There are two or three issues which need to be discussed after adoption.
   • Daniel: I'm in favor to adopt this document.
   • Karen: I will send out a message this week that it will be adopted.

Update Roughtime

Presenter: Watson Ladd
Presentation: https://datatracker.ietf.org/meeting/111/materials/slides-111-ntp-roughtime-update-00
- draft-ietf-ntp-roughtime-05
- draft-ietf-ntp-roughtime-ecosystem-00

Authors believe draft-ietf-ntp-roughtime-05 is ready for WGLC.

Discussion

• Rich: How useful is this without the auditors in the ecosystem? Is it good enough for a first guess of the time is? How much beyond the on-wire protocol we have to establish to be a minimally viable product?
• Watson: A absolut minimum of 3 servers, a handful of auditors.
• Rich: That make a lot of sense.
• Karen: Is there anybody here who is interested in implementing?
• Erik: If no one else from Google steps up I'd like to see that someone from Google does it and it might be me.
• Karen: We could do the WGLC. Question for Erik. Before or after the re-chartering?
• Erik: We could do it this simultaneously.
• Karen: We will do WGLC on this document. Please review the draft on the ecosystem.

NTP Over PTP

• draft-mlichvar-ntp-over-ptp-00

Miroslav is not present. No comments

Update of NTP charter

• Karen: A draft of the new charter has been send to the mailing list. Did see very few comments. One suggested editing from Rich, which I've incorporated. If no further discussion on the charter I think it is ready to be moved forward. Erik, what is the process to use to get it moved forward.
• Erik: If the working group agrees I will give it a pass. Maybe some further quick edits and one more loop through the working group, then I will bring it to the IESG.
• Doug: Want to express that it is appropriately flexible and covers many timing related work. That is what is needed. We very much support it.
• Daniel: Do we want to keep the name NTP if probably a majority of the working group at this point is interested in other protocols? I suggest the name "Time Sync".
• Karen: I had discussion to name it "Network Time Protocols"; just add a "s" to the end in order to keep the same acronym. We did speak previously to change the name. I didn't know how much confusion that would cause. What do you think about the subtle change.
• Heiko. I'm not sure if it would be worth the hassle to change the name. I would be in favor of just keeping the old name. Leaving everything as it is: mailing list name, datatracker links, etc.
• Watson: Changing names is extraordinarily difficult. Just adding the "s" at the end is fine. But changing the abbreviation is going to cause all sort of issues with list names, old drafts.
• Rich: Tried to get the name changed for spasm mailing list since the group is lamps. Speaking with the tools people it is a no-go. You just cannot change the mailing list name.
• Karen: That's the reason I thought Erik's suggestion to just add only an "s" to the end of the name of the WG (not the acronym) would work.
• Karen: Will be updated with Eriks comments and send it to the working grup one more time and then hopefully send it forward.

NTPv5 (no ID updates)

• Karen: We had very productive interim meeting. We had conversation on NTPv5 but we have no new drafts since then. We put it on the agenda without new drafts to specifically to discuss. Is there anything particular people want to talk about related to NTPv5.
• Doug: One of the non-trivial topic that has to be worked on to move NTPv5 forward is security. Is there a notion that security is mandatory? Do we want to define a default security in the draft or should we point to other documents?
• James: Clarifying question. Doug, which draft are you talking about?
• Doug: Miroslav's proposal.
• James: The reason I mention that is because one of the things on my todo list for the requirements draft is to describe a rudimentary threat model to define what to worry about. That would define the boundaries of which technical implementation would be needed.
• Doug: Agree, would be very helpful.
• Karen: Beyond the conversations in the mailing list we have the two drafts: James's requirements draft and Miroslav's contribution. Daniel has also written something.
• Daniel: Yes, but it was not in the form of an I-D.
• Karen: That is the reason I remember but couldn't find it.
• Karen: Will continue to discuss this on the next interim meeting.

NTS for PTP (no ID updates)

• Karen: Current situation: no updates IDs on that topic. We have the contributions of Martin and Heiko. Martin, you are planning on an update in one month time?
• Martin: Yes, I plan to provide an update next month. It will consist of many small changes.
• Doug: How we get a sense of what the consensus is? Do we want to pursue one of these two proposals or something else? It would be nice to get everybody behind one direction.
• Karen: I'm not sure how to organize that either; happy to get suggestions.
• Watson: One of the difficulties is the many ways PTP can be deployed. Some of which map less cleanly onto the structure of NTS some of which map more cleanly. We might identify the cases that we are going to start with.

• Heiko: There was a suggestion that Martin might split his documents into multiple parts

  1. a security mechanism for unicast and
  2. a security mechanism for multicast.
  3. a protocol that specifies how NTS/KE servers talk to NTP and PTP servers if they operate in a distributed model.

  I would support that. Martin already indicated to do that. That would make it easier to discuss those three topics. I'm in favor of splitting this into multiple documents and forward each topic on its own.

• Karen: One of the lessons learned in NTS: we tried to treat all NTP modes in one document and we were not successful. Splitting up is fine. The risk is that you don't get back to the modes of service that have less attraction. E.g. when we decided split Client-Server mode in NTS we expected to get back to the other later. But we never gotten any contributions and those other modes.

• Watson: I think that is feature of such an approach not a bug. If the other modes are causing problems of standardizing, there isn't the impetus to move them forward in terms of the need. Then, chopping them out is the right thing to do.
• Karen: Agree, this help to narrow the field when you are unable to make a decision.
• Doug: Did, we answer your initial question? Heiko outlined the three documents which he felt are helpful in moving forward. Martin indicated to provide an update.
• Doug: might be a good time for Martin to chime in and say whether this is an task he is interested in. Otherwise we would need another volunteer.
• Martin: Yes, I already discussed that with Rainer Bermbach. Maybe, we should discuss this together. But I think it is possible.
• Karen: This is something that should thought about.

AOB

• Karen: Plan for interim meetings. Next full IETF (IETF 112) week of Nov. 8th.
• Doug: Propose to do a Doodle poll for the next interims in order to avoid conflicts with other meetings or conferences.
• Karen: Do we think we want one or two virtual interim meetings?
• Heiko: Two interims might be better. Regarding the draft NTS4UPTP: I'm not sure what the future of the draft will be. I did't see any comments or any significant comments that discuss the technial aspects of the draft. The last discussions were mainly circle around whether this is worthwhile or not. There is not many stuff that can be addressed in an update for the draft. I assume that is more or less the same for Martin's draft.
• Karen: Next step would be a call for adoption. We could do a consensus call on the plan to pull apart the whole space into three three peaces. Then we would be able to provide a document for the unicast solution for example.
• Doug: I think that does make sense. Another general question: Is it important when it comes to unicast PTP security that it is clean and most appropriate for PTP or is it more important to have PTP and NTP unicast security as similar as possible? Because these are the two starting assumptions in the two drafts. If we had consensus on those we would know which approach to follow up.

• Karen: We could do a couple of high-level consensus calls. Basically two questions.

  • Should we partition it into three peaces?
  • Should it as close as possible to NTP?

  Doug, in your presentation at the last meeting, didn't you have a concise way of stating that?

• Doug: I will take that as an action item. I will try to phrase it in a way that can be put out to the working group.

• Karen: If you could provide it to us Dieter and I will try to have a couple of high-level consensus calls on that and to provide guidance to Martin and Heiko.
• Doug: I will include Martin and Heiko in that discussion.
• Karen. Daniel did provide a pointer to his proposal for NTPv5
  (https://gist.github.com/dfoxfranke/4ca0443b6ff6e0473578cf3827b9ea7f).
• Karen: We will provide a Doodle poll for two virtual interims between now and November.
• Karen: There is still one remaining document from the TICTOC working group, which is the Enterprise Profile. Hopefully we will get it done soon.
• Doug: Is there anything you need from us (the authors)?
• Karen: I need to write the shepared writeup. Help would be appreciated.
• Doug: I can help with that.
• Karen: Thanks. Maybe we schedule a meeting in a couple of weeks to get together and work on that.

_Session closed at 23:55 UTC.__