Session Date/Time: 24 Sep 2026 14:00
[00:02:44] Danny Mayer: Hi, Dieter.
[00:02:46] Kristof Teichel: Hi, Danny.
[00:02:48] Danny Mayer: How are you doing?
[00:02:49] Kristof Teichel: Fine. Thanks. To all, Karen is just booting her computer. She will join in one or two minutes, then we will start.
[00:03:00] Miroslav Lichvar: Mhmm.
[00:04:07] Karen O'Donoghue: Okay. Welcome, everybody. Sorry about the delay. I apparently needed to reboot my laptop. So with that, we will go ahead and get started. The alright. So this is a a rescheduled virtual interim of the n t p working group. The note well are the is the policy and procedures by which the IETF operates. You have agreed to abide by all of these whenever you sign in to Datatracker or join any of our meetings. Dieter will be taking notes in the notepad that's on the meeting page. And look, he's already got a link up there. And we will be leveraging Ekca's excellent tool as well. Anybody who wants to ensure that their stuff is well represented, please feel free to add, augment what is going on in the notes. We have a fairly full agenda today. This has not changed since the second announcement. Is there any additions or comments on the agenda? Let's see. All of the folks I'm expecting are here. Danny, did you Yeah.
[00:05:53] Danny Mayer: I would like to add twenty thirty six, twenty thirty eight rollovers.
[00:05:58] Karen O'Donoghue: Okay. That's very convenient because that's basically what the ITU liaison update is also about. So we'll add it in in conjunction with that. So the so with that, any other additions? Excellent. Thank you for your patience with the scheduling issue. I learned some Datatracker things, and I think that some of the things I learned will hopefully not need to be known any longer. Or at some point in the future, they're gonna fix the issue, I think. But with that, we will go ahead and get started. The second agenda item is the n t p working group documents that we have beyond the working group. First of all, I would like to I you saw the announcement that came out on the mailing list that the draft-ietf-ntp-nts-for-ptp document has been published. It was published last month. I'd like to thank Miroslav for all of the work that he put into that, and also the 1588 working group who also commented on it. And so we appreciate everybody's efforts there. The Roughtime document is close. It is in final review, so it should be coming out sometime shortly. I think it's currently waiting on some action from the authors and myself. So but that that's bubbling along. It is in final review, which is the final stage of the RFC Editor, which is excellent. If you haven't looked, I think I mentioned this on on a previous meeting. The RFC Editor has updated a status page that is really quite helpful in seeing what the different stages of RFC of being an RFC Editor and what the status of each document is. And it's a it's a very nice update to the tooling, I think. So the next item on the agenda is NTPv5. I know that Miroslav and Tal have been working on that. We had a, like, editor's meeting to discuss some of the open issues in August, and the draft is moving forward. Miroslav, did you want to make any updates on that? Do you know when the next revision might come out?
[00:08:26] Miroslav Lichvar: Yes. I'm hoping for the next meeting, we will have an updated draft. At the meeting with David and Tal, they have reached some agreement on how to move forward with the open issues, and the issue with Flux has been resolved. The pull request was accepted as it is, I think. And the issue with the Bloom filter, the replacement with a list of reference IDs that was included as well with some changes suggested by David. Basically, this should prevent false positives and allow false negatives with the idea that loops over many nodes don't matter, really. And with this change, we have lost the possibility to observe reference clocks in the Bloom filter. This new list contains only reference IDs of m t p v five nodes. So this is one remaining thing I think will need to be addressed. And David, in one of his pull requests, there is a new extension proposed for the primary reference IDs, and that includes the reference clocks and also e p e P I P v 4 and I p v six addresses. And I think we'll need to discuss that a bit if we want to allow multiple reference IDs to be exchanged over this optional extension field or if we want to make it mandatory and include only reference clocks with the basically, duplicating the idea of the list of the reference IDs, but this one only tracking the primary time sources like GPS and other sources of time outside of n t p. And after that, I think we will need, like, I think the technical issues will be resolved at least from those I'm aware of. And then there is the question if we want to rearrange the document to separate the optional parts or not, and that will be just a bitter work, I think.
[00:12:03] Karen O'Donoghue: Yeah. I I thought we had discussed the reorganization and decided that that would cause too much confusion. Is that for reviewing from version to version. Did we not agree to that, or is that did I misunderstand that?
[00:12:30] Miroslav Lichvar: I'm not sure, actually. I think we agreed that it would be some work and that it might not really be helpful in making the document more readable, but maybe easier to follow for implementers who don't care about the optional parts. I don't know. I I think this is, like, not that important.
[00:13:00] Karen O'Donoghue: Okay.
[00:13:01] Miroslav Lichvar: We can still decide later.
[00:13:03] Karen O'Donoghue: Yeah. We can we can decide later. I I was I I recall being a little bit hesitant to do a big reorg at this stage because I was afraid it would make it harder for people to review and see what had actually changed. And we are a very small working group, and so getting people to review things is always quite the challenge. But anyway so we expect we at the end of the call, can discuss I was we weren't currently we're about two months out from that the IETF 121 in Dublin, IETF 121. We could do a virtual interim. But think about this and then join the call, and then we can come back to it at the end. But we could do a virtual interim, like, the week of, you know, October 19, or we could just wait for the face to face or face to remote, whatever. I don't I don't know which would be more productive. For everybody else, anybody who has not been reviewing this document, I think it's a really good time to start reviewing it. So please take a look. So any other questions on the status of the NTPv5 document? Okay. Next thing that we have is Sarah is gonna talk about NTPv5 interrupt status. Do you want me to pull the slides, or do you want to do that?
[00:15:16] Sarah Grant: There's only two slides, so you can control it. Okay. Yeah. I'll just keep it really brief. So at the 120 hackathon at Vienna, I took the Roughtime into ntp-aparnos and made it shimmed it in for NTPv5. We at the end of the weekend, we sorta had a few packets being exchanged and a few errors. In the meanwhile, since then, I have done some more interrupt testing and cleaned things up. This is the current state of this spreadsheet. The URL is in the slides on Datatracker if you want them. Some of these things look like failures. They are not. They are things such as draft version mismatch or failures related to the Bloom filter or other stratum failures because the ntp-aparnos is acting with sort of a local stratum one thing and not in, like, an actual deployment. This is probably fixable. There have been some other interesting quirks observed with upgrading and stuff, but that's largely been sorted. Yeah. Next slide, please. In terms of what I've got to do next, what I think I need to do next is sort of get get the things that I've patched into implementations back into the projects themselves to to make it work better and have a look at the extension fields. There is a lot of mismatch in what implementations do and don't support, and that's the optional versus the mandatory. And if we wanna do NTS testing, it's not clear for a lot of implementations how to get out both the TLS keys through SSL key log file or the NTS server to client, client to server keys. So if implementers could document that or enable it, I would be really appreciative. That's about it. If there's any questions or a question that I have for the chairs is is do we wanna put this on the working group GitHub repository like we did for Roughtime?
[00:17:48] Karen O'Donoghue: Yeah. I I think putting it on the GitHub repo would be good. Does anybody have any questions on this? I know David has has was I got a last minute message from David who was unable to attend this morning for a personal reason. So I know a lot of this work was supported with David and Ruben and you at at the Vienna hackathon. So I think it's very useful. Okay. Alrighty. Oops. Sorry. I just slide I shared the wrong ones. Hold on one sec. Alright. So the next item is NTS for PTP, and I was expecting Martin on the call. Dieter, do you know if he's planning to be here? Oh, wait. Kristof?
[00:19:26] Kristof Teichel: Yeah. I can I can say that he's not going to be there? If he isn't now, then he's not going to make it. Okay. And he wanted me to tell all of you that nothing reporting worthy has happened since the last update either. So if he were here, he would just say that probably.
[00:19:41] Karen O'Donoghue: Yeah. I I would say that not much has happened in the IETF document, but I would like to point out a lot has happened in the IEEE companion document. So as as a reminder to everybody, the NTS for PTP document is going to be the extensions to NTS required to support the PTP document and how to use NTS with PTP is being done in IEEE. And I think we are pretty close to being ready to go to working group ballot with that, at which point we'll be able to progress this one a little bit more quickly in this working group. So I would pause on looking at that too much because of that. But I would expect to make quicker progress on that after the next month or two. Our goal right now is for it to go to working group ballot, hopefully, in October, but November at the latest so that by the end of the year, we should have completed our first working group ballot in 1588. Anybody who as per the agreement that we have with IEEE 1588, obviously, the IETF and the IEEE have different, models for operating, and, the IEEE working documents are not publicly available like the IETF ones are. However, we do have the permission of the IEEE 1588 chair to share those documents with people that are working on the standards for us. So anybody who would like a copy of that document, we we're not allowed to post it publicly, but we are allowed to give it to anybody that asks for it that wants to review it in conjunction with this work. So anybody that's interested in either the the NTS for PTP. And then I'll talk about it a little bit in the 1588 document, but there there's also an NTS for CSPTP, we'll get to later. So as a reminder, and this is gonna become more important when we start going through the official publication cycles in IEEE and IETF, we do have access to that document. You just have to ask for it. And you can ask me or ask Dieter, and one of us will get it to you. Alright. Any questions on NTS for PTP? Nope. Alright. The next document is the NTS-KEM Pool. As I mentioned, David has contacted me and is not able to be here. I don't know, Ruben, if he sent you with instructions on an update for this or if you had anything you'd like to contribute.
[00:22:32] Ruben Nijveld: Not really. No. I think there's not much to update here. The pool is still running. So we're still experimenting.
[00:22:42] Karen O'Donoghue: Excellent. Experiments are good. As a reminder, the NTS this document is an experimental RFC. It's planned to be an experimental RFC, and we are testing different ways that NTS pools can be constructed. The next item on the agenda, I asked Dieter and I asked Kristof to come and give us an update on the leap second resolution issue that's going through ITU and BIPM. It's not final yet, but Dieter not Dieter. Right? Kristof can give you a status of where we are with that.
[00:23:21] Kristof Teichel: Yeah. I haven't been using Meetecho too much. Do I request screen share? I haven't sent you slides, so that's the only way to
[00:23:30] Sarah Grant: send can my Yeah.
[00:23:32] Karen O'Donoghue: Request to to just share your screen.
[00:23:36] Kristof Teichel: Okay. It's a covered together set of three slides. It's not great,
[00:23:39] Miroslav Lichvar: but I
[00:23:40] Kristof Teichel: would like to show it.
[00:23:41] Karen O'Donoghue: Yes.
[00:23:45] Kristof Teichel: So people seeing my screen? Is it working?
[00:23:49] Karen O'Donoghue: I think we're still seeing my screen, so let me do oh, no. Nope. Sorry. I haven't done screen share in a while.
[00:24:04] Kristof Teichel: You repeat marked as, like, a raised hand for me or something like that.
[00:24:08] Karen O'Donoghue: Oh, wait. There we go. Grant screen. Check mark. Green check.
[00:24:12] Kristof Teichel: All the slots for the requested media are already taken. Are seeing people seeing my screen?
[00:24:20] Karen O'Donoghue: No. We're seeing my we're seeing hold on one second. One second.
[00:24:33] Kristof Teichel: Yes.
[00:24:33] Karen O'Donoghue: Alright. So try again.
[00:24:37] Kristof Teichel: I stopped my screen share. I requested again.
[00:24:40] Karen O'Donoghue: I don't it tells me that you have asked to share it. There we go. Grant screen.
[00:24:45] Kristof Teichel: Do you want to share screen? That's a yes on my part. Oh. Just the whole screen, I guess. It's the easiest. And then we do this so it's not infinite. Okay. Is it working now?
[00:25:01] Karen O'Donoghue: Yes. It is. Thank
[00:25:02] Kristof Teichel: you. Okay. Great. Yeah. This is covered together. I've I've done it today since Dieter has asked me yesterday. And it's not pretty, I think. It might even be very small and hard to read on the left side. Really, the important thing is the right side, I think. But the thing is that you mentioned, Karen, the BIPM, which stands for Bureau International des Poids et Mesures, so the International Bureau of Weights and Measures. And there might be different terms thrown around instead of BIPM. BIPM is apparently used for the whole thing, but the whole thing includes a treaty, the Metre Convention, and importantly, the CGPM, so the General Conference of Weights and Measures. Because this is a conference that happens every four years that actually makes decisions related to anything BIPM. And there might also be the CCTF thrown around that's down there in the corner, The Consultative Committee for Time and Frequency specifically who advise on time and frequency things for the BIPM. So all of this, it's not interchangeable, but any of those acronyms might be thrown at you. And then there's actually shared responsibility with UTC which is important for the status update. And so far as BIPM holds the definition of the length of the second. Currently, that's like the nine billionth factor of frequency that's important to cesium atom transitions. And the BIPM is also responsible for the realization, if you can call it that, of UTC as a weighted average of the participating laboratories. UTC isn't shown on any clock anywhere in the world really. What you get is UTC(k) realizations. So actual realizations at PTB or at NIST somewhere. And of those, you get a weighted average and that's UTC in the end. And that's something that BIPM is doing. And so they also kind of hold the definition of much of UTC. But they don't hold one part. They don't apparently have the text with the definition of what happens with leap seconds. If you recall, a leap second is what's supposed to happen when the atomic time scale of all atomic clocks in the world deviates from what solar time is doing because the atomic clocks the conglomerate of all atomic clocks is a lot more accurate and precise than solar time. So it will deviate. But when that happens currently, when it threatens to deviate by more than one second, UTC is corrected to match what the sun is doing. And there you get the shared responsibility because you get here in the middle. You get the International Earth Rotation and Reference Systems Service, or IERS for short, who observe the deviation of solar time in UTC. And they measure it and they report on it. And then you get more shared responsibility with the ITU, specifically the International Telecommunications Union. The ITU has two major parts to it. It's the ITU-T. So for telecom, that's what T is for. And that's where I think most of our contact in this group is because like PTP is discussed in ITU-T a lot. But it also has the ITU-R for radio communications. And typically, leap second announcements had first been done via radio communication and somehow the definition then ended up in an ITU-R standard. So ITU-R is responsible for communicating leap second information over radio signals such as our DCF77 broadcast tower. And in that way, they also hold the definition of what the threshold is currently. That's it shouldn't exceed one second, so the threshold is, I think, point nine seconds of when it is that you have to put up a leap second and communicate a leap second. And everyone in the world has to apply a leap second to their UTC. And so with this shared responsibility, you can imagine maybe that a project like we currently have now where it was kind of aimed at to abolish the practice of leap seconds or increase the tolerance that shared responsibility comes back to bite you. And so the final slide that I have is the timeline of who decides what and when, in some cases decided. It's really past tense. So in 2022, the BIPM side of things decided at this general conference that the tolerance should be increased to something more than one second in or before 2035. At that point, it was left pretty open. If that was going to mean like ten seconds, fifteen seconds, fifteen minutes, an hour, a day, or infinite. And then the ITU or ITU-R side of things, the people decided at the World Radio Conference in 2023 to make the new threshold an hour. So three thousand six hundred seconds hard coded of when you would have to actually touch UTC and change UTC to account for deviations with solar time. And the the update, really, the current status is that now this has been pretty much proposed as the threshold because of the shared responsibility, if I understand correctly. The BIPM side of things at CGPM will have to confirm this. They will have to say yes whether or not to accept this. This general conference is going to be held in October 13 to the fifteenth, so pretty soon, all things considered. And if they decide to accept, which I think requires a unanimous vote, I think, it would come into effect pretty soon in May 2027. And by then, we would have, for all intents and purposes, have almost abolished the practice of of leap second click. When it reaches one hour, that's a lot of grand grand grand that you have to put before grandkids to determine who has to actually deal with that when it happens. Yeah. But this is not quite clear. There has been resistance. I'm gonna stop sharing the slides here because they're finished. There has been resistance to to this and specifically from Russia in the last years. And if I understand correctly, it might have to be a unanimous vote. They've stopped actively resisting in the ITU-R recently, but this would be the opportunity to say no again, so we don't actually know if this is going to happen or not. But if so, that's the time frame that we have. If it's not going to happen now, then I really cannot tell you if or when it's going to happen.
[00:32:53] Karen O'Donoghue: Okay. Miroslav, do you have a question?
[00:32:57] Miroslav Lichvar: So if this resolution was accepted, do we drop support for deep seconds from NTPv5, or do we make make it configurable to support deep hours? Or do we not care at all at this point?
[00:33:20] Kristof Teichel: That's an interesting question. I never thought that the timeline would end up like this, that it might actually be in effect before we publish NTPv5. I'm not sure what to do. Probably I would no, I'm not sure. I would probably try to keep a field that keeps it compatible with NTP v4. But in the long run, we would have to make it configurable for larger offsets. All of these are formulated pretty vaguely out of the proposition so far, so I don't know just because you increase the threshold of tolerance to an hour doesn't mean that you do nothing before that. I don't think it says anywhere that you cannot change it before an hour or by how much. Only says that you have to change it when the threat is true. You have to change it before it reaches one hour, I think is the aim. Currently, for one second, we do it at point nine seconds. So if we do it at point nine hours, then that's thousands of years into the future probably. But it might be that smaller corrections of a minute or something will be aimed at. This is all very vague, and people don't want to define a lot because we haven't actually made the resolution. So I think it's a little bit unclear what actually happens if we increase the threshold in the way that's imagined.
[00:34:55] Miroslav Lichvar: Okay. Thank you.
[00:35:02] Karen O'Donoghue: When I I guess when I was asking Kristof or when I wanted Kristof to come, give us an update, I wasn't thinking that we would need to make any changes to NTPv5. I just wanted everybody to be aware that this was happening. I guess we should go ahead.
[00:35:32] Kristof Teichel: I don't know. I think you probably don't need to do it for NTPv5 because it's so far into the future that anything is likely to happen. It might be the the wisest course of action to keep it backwards compatible and just to expect that it's not going to be used as long as you call the thing NTPv5. Literally, before you reach an hour, it's like thousands of years into the future by what we're currently seeing. And the main goal of this is to avoid a negative leap second overall, I think. So that that tolerance is basically intended as a software of abolishing it without without calling it abolishing the practice.
[00:36:11] Karen O'Donoghue: Yeah. I I didn't I haven't recently done the math, but I I had heard it was gonna be several hundred years into the future. And I'm like, well, that's that's great.
[00:36:20] Kristof Teichel: Yeah. And that that might still have been on the fifteen minute threshold that was also proposed or the one minute threshold that would also was also proposed. I I think by what we have now, it's been like fifteen or seventeen seconds that have actually been introduced since 1970. So it's not one a year. And by that logic, it will be more like ten thousand years before we reach that threshold. So, basically
[00:36:49] Karen O'Donoghue: Yeah. I I think there was a period where they were concerned that they were gonna start becoming more frequent. But then things changed again, and I don't think they've been as frequent as they were expecting several years ago. But anyway, thank you. Kristof, you would be willing to come and tell us what the final decision is after the October meeting. Right?
[00:37:10] Kristof Teichel: Yeah. I think I will hear about it for sure. I will not be there. So
[00:37:15] Karen O'Donoghue: you're not going? Okay. No. Yeah. Just as as a I I always find this this this topic interesting because in the mid nineties, I actually wrote a position paper about why they should get rid of late seconds for the applications that I was concerned about. And that was thirty years ago Yep. When the I ITU-R was talking about getting rid of them then. So that's a a long time.
[00:37:45] Kristof Teichel: So Seems like it might finally be happening. But yeah.
[00:37:50] Karen O'Donoghue: I I think that it needs to get through this stage before people figure out what it actually means for how, you know, changes to protocols and things. But
[00:38:00] Kristof Teichel: Yeah. It it seems to be a little bit at the whim of the Russian delegates at this point, which is not ideal. They they might actually be using or want to use the fact that we don't have a good proposition for what it's how it's going to be as an argument against the whole idea. I'm I'm not sure.
[00:38:21] Karen O'Donoghue: I didn't realize it was the the Russians. I remember years ago, it was the the British astronomers who didn't wanna get rid of leap seconds.
[00:38:30] Kristof Teichel: Yeah. Yeah. Yeah. The people in Greenwich are going to be the most affected by the deviation from solar time. No, yes, it used to be that, but they stopped resisting the proposition, I think, years ago and recently
[00:38:45] Karen O'Donoghue: Yeah, mean, this is ongoing.
[00:38:47] Kristof Teichel: Yeah. Specifically for the GLONASS satellite system.
[00:38:52] Karen O'Donoghue: Alright. Alright. Any more questions, Dieter?
[00:38:56] Kristof Teichel: Yeah. Kristof, can you send me the presentation? Of course.
[00:39:03] Karen O'Donoghue: Yeah. Thank you. Alright. So our next topic and I think I have so I have two versions of slides, Marc. I have one that says time sync profile and one that says time sync. And they both say revision 00.
[00:39:30] Marc Blanchet: Yeah. Sorry. I
[00:39:33] Karen O'Donoghue: No worries.
[00:39:33] Marc Blanchet: Added one slide. So the latest one is the right, which is time sync for Deep Space. Sorry.
[00:39:43] Karen O'Donoghue: Oh, you know, I guess I could have let you share them. But, anyway, would you like control, or do you want me to control them?
[00:39:53] Marc Blanchet: There's just a few slides. So let let's you control so we're, you know, going faster.
[00:40:00] Karen O'Donoghue: Okay. Perfect. Alright.
[00:40:03] Marc Blanchet: Okay. So, hello, everybody from, not from Mars, but I'm not an NTP expert. I'm a NTP tourist. So bear with me. But I did actually with my team in early two thousand, modified the NTP code to and deployed the first NTP server on I p v six, and we did com you know, essentially did a a way to compress the v six address and the reference ID of the 32 bits. And we actually wrote a draft, sent it to David Mills, and he didn't like it. Anyway, that's my foray into time NTP and time sync. Next slide. So the purpose of this presentation is to make you aware that, we have working on IP, in Deep Space, the whole IP stack, and, and that's inside the TIPTOP working group. And just wanna give you a summary of, you know, the use case and the architecture. So use cases, delays are, you know, way over, standard Internet delays. For example, you know, four to twenty two minutes, one way delay to Mars depending on the positions of planets, couple of seconds to moon. And we have intermittent because, deploying orbiters cost a lot, so we should not think that there will be a constellation like Starlink over, well, moon will be, earlier, but over Mars will take some time. So in between, as we have right now, they are orbiters, but they are passing every, you know, x minutes or hours around the around this celestial body. Therefore, there are intermittent of connections. So as you can see, those two key characteristics have, do not work well with the the our current protocols. So in the second document, IP Architecture, we describe out to actually, you know, the architecture of IP for Deep Space. And one of the key component to manage the intermittence is we do IP packet buffering or store in intermediate nodes, for example, orbiters. In the graphics on the right, you see the orbiter, and, you know, when it doesn't see the asset because the asset is on the other side of Mars, for example, or any celestial body, it will, you know, keep the packet, stored until it sees the asset. So this is, you know, pretty it's just, you know, deeper, buffering for for orders since IP doesn't as you know, IP an IP packet doesn't have any time in it. For transport, we could use, obviously, a UDP because UDP doesn't have a time in it. TCP doesn't work well because of the handshake. And given that most of the, our current protocols also add TLS over TCP, there's more handshakes there. So multiple handshakes, three or four handshakes back and forth to Mars will will just not work. So we instead use QUIC as a transport, which has one RTT for handshake for both the connection itself and the security TLS, but we need to be profiled it. So, you know, a few timers and things like that, there's a draft that describes that. And you need to profile application and protocols because the the all out of timers and handshake in them. So and the part of next slide. So part of the the work we're doing in TIPTOP is to actually look at the next slide, please, is to actually look at the different, network services and application protocols. One of these is time sync. So the use case so there's a draft that I wrote and started to send to some people for review. So the use case here is to deliver UTC based time sync for generic purpose computers in space. So, we may you may all know already that, obviously, time is very important in space, and there's already some mechanisms to for for this and roughly identified as P and T, position navigation and timing. So we're not trying to replace that, but instead deliver, you know, standard time sync to any kind of computer, which is maybe computers within payloads of a spacecraft or, you know, computers in in on the surface of the moon or the Mars or anything any computer anywhere. The typical P and T is often not, you know, you know, used for navigation itself, but not necessarily available to every computer on a spacecraft. We're not dealing with relativity, and we're not dealing with the time references like, lunar time reference or others. Next slide. So the the current draft has, we've done multiple simulations multiple scenarios, including delay of 24 RTT. The simulations of for all cases, except the next one, the next bullet, all cases, essentially as a as a, resolved clock error around, one hundred milliseconds for any kind of delay. So that's gonna show it seems to be working. For standard implementations, ntpdig, ntp.org, and chrony. And we actually removed the, you know, the NTP, the time sync, within the VMs, the OS. So we're we're making sure that we we're using the right the actual NTP client and server. Delay has to be, the key finding. Actually, some of one of you, we had a chat, like, two years ago, and he told me exactly that, and we confirmed that. So the delay to to be to be good, the delay has to be the same in both directions. Because if not, then it's even worse because the client doesn't even know that the delay was different in both actions. Therefore, it syncs badly. You know? Essentially, half of the difference. So this is, therefore, a key recommendation for space missions. If you do NTP sync, you know, make make sure that the delay is the same in both directions, which means that, for example, you could only, schedule NTP sync when there's a full path communication, back and forth within the the time window, the contact window, so for example. Celestial body surface networks, you may have heard of, you know, multiple countries that are planning to have surface networks and and, you know, moon land based, for example. So moon based. So these were are going to be normal Internets because we the plan is to use standard protocols such as 3GPP and and Wi-Fi and IEEE, you know, eight zero two networking. So we can use standard n NTP, but point to a local NTP server. N t NTS was not great given that it actually uses initial TCP, TLS, and shake. So we're kind of not proposing to use NTS for that reason. There was a I I remember seeing a proposal for NTP over QUIC, and that actually we would be a good use case for NTP over QUIC for for the reason I just described. Next slide. So this is the this is it. Draft has is written, not yet published, and I'm looking for reviewers and co authors. And I've sent it to a few people. Got some response, you know, iterated in it, but I'm really looking for essentially, especially coauthors because I cannot really pretend to be, in any way an NTP expert or and really a tourist. And when published, would intend to present in both NTP and type of working group for, for, you know, review and making sure that it's, you know, the right spec. And that's it for me. Thank you very much for and looking for question.
[00:50:04] Karen O'Donoghue: Go ahead, Miroslav.
[00:50:09] Miroslav Lichvar: This, road delay field that is in the NTP packet, that's only up to sixty five thousand seconds. So that twenty four hour delay you mentioned, you you had to modify the NTP field, or how did you represent this delay?
[00:50:32] Marc Blanchet: Okay. Good question. I didn't get the the the actual number you said, but we did twenty four hour RTT, so twelve hours delay. How many seconds is the the field? Or
[00:50:54] Miroslav Lichvar: It's a it's a fixed point 32 bit field. That's 16 bits for seconds. So sixty five five three five seconds is the largest value.
[00:51:10] Marc Blanchet: Okay.
[00:51:11] Miroslav Lichvar: And in a degree five, we are decreasing like, we are improving the resolution, and the maximum value is only sixteen seconds. So if you need larger rule delays in the packet, I think you would need to specify an extension field.
[00:51:31] Marc Blanchet: Uh-huh. Okay. Yeah. Okay. Thank you very much. That I didn't know. That so maybe that explains that the the actual resolution was not as good as we could have on the Internet. Or again, I'm tourists, so maybe I'm just out of the
[00:51:50] Miroslav Lichvar: I don't know. Like like, a standard CLIA would refuse to accept measurements with with delays larger than sixteen seconds or so.
[00:52:00] Marc Blanchet: So Okay. Then the simulations were you know, I tried it. You could actually tried it yourself easily, but you just set the time out, and it it works pretty easily if you do we we use the netem for for introducing delay in in networks.
[00:52:22] Miroslav Lichvar: Uh-huh.
[00:52:23] Marc Blanchet: So I'm kinda I'm kind of surprised of what you're saying that more than sixteen seconds delay would be would not work.
[00:52:33] Miroslav Lichvar: In default configurations, I think, like, most of the well, no implementations have a configuration option to allow longer delays, but usually, it's just a few seconds.
[00:52:50] Marc Blanchet: Okay. I would like to I don't remember having changed the config of of this, but, you know, I'll check. Thank you for for the comment. I'll double check.
[00:53:10] Karen O'Donoghue: Do you know what what implementation NTP implementation your simulation is based on, or did it write its own implementation? Like, I'm not sure what your simulation framework is.
[00:53:23] Marc Blanchet: Yeah. Simulation framework was VMs with the NTP sync or the time sync removed and Ubuntu, and then we used Chrony. It's a you know, we're doing this. We have a couple of colleagues that work with that together. So NTP Chrony, said there was Chrony and ntpdig were the three we we tried. Okay.
[00:53:56] Karen O'Donoghue: I also Ruben has put a comment in the chat that you might wanna take a look at.
[00:54:01] Marc Blanchet: Yeah. Could you also consider the arbitrary new route in which case the route to the position is not relevant? Yeah. Good point, Ruben. I think I I will write it down because I think we we discussed it in the current draft, but, obviously, you haven't seen it. But I I'll make sure that this is this is clearly written. Thank you.
[00:54:44] Karen O'Donoghue: Alright. Are there any more questions? So you're looking for reviewers, and you, do you expect to have a draft published by IETF 121? Is that your target, or have you do you have a timeline?
[00:54:59] Marc Blanchet: Yeah. Yeah. Yeah. I I wanna, you know, release it in in the next, you know, weeks, essentially. You know?
[00:55:06] Karen O'Donoghue: Okay.
[00:55:09] Danny Mayer: But
[00:55:13] Karen O'Donoghue: Alright. Alright. Anything else for, Mark? Excellent. Thank you very much, Mark.
[00:55:28] Marc Blanchet: Thank you. And, hopefully, someone will raise his hand for being a bit more involved.
[00:55:42] Karen O'Donoghue: Alright. So the next item on the agenda is the IT liaison update. The short version of that update is while I've had some conversations with folks in the IAB related to this, I have not written a draft yet. The essence of the draft that we were planning to write, we'll have to see what direction Danny's discussion goes in. But let's say, to remind folks, this liaison was the 90 some page document that is, addressing, different types of time rollovers that are coming up, the Unix one and the one in NTP. The one that's relevant to us is obviously the one in in NTP, and the response to that was basically going to be, you know, you know, we're interested, we're supportive, and we are NTPv5 addresses this issue. So but I don't have text for that yet. Anybody who's willing to help me work on that text, raise your hand at some point. Danny, I'm assuming that you're not raising your hand to help with the text. So I'll let you know again.
[00:57:06] Danny Mayer: Not not yet. The actually, we should be also worried about the Unix rollover as well.
[00:57:18] Karen O'Donoghue: Okay.
[00:57:19] Danny Mayer: Just because it's coming from your system doesn't mean to say we don't have to worry about it.
[00:57:26] Karen O'Donoghue: Yeah. I guess I I wouldn't say we don't have to worry about it, but it doesn't I guess I was thinking in terms of impacting our documents.
[00:57:37] Danny Mayer: Yeah. As far as I know, Dave Mills tested the NTP rollover, the area rollover, but I don't know of any experimental papers on that, and it probably needs to be retested. And then the Unix rollover most has to be done. But my the bigger problem that I see is that systems need to be updated to make sure that they validate the time stamps, to make sure that they're sane. It's not just looking at the the packet and and and making sure that the it's well formed. You also have to say, does this look like it's something that you can you can use? Because at at the rollover, you'll have some time stamps coming in, which will be rolled over to to the epoch or the the n t p zero time. So you you really need to be looking closely at what you're getting. So this is at both ends, the client end and the server end, and you can't just let it go. Yeah. And that this actually should be baked into NTPv5 as a requirement.
[00:59:15] Karen O'Donoghue: Okay. So beyond being baked into v five, do you think it there's any additional, like, best practice or guidance that needs to be developed in the context of this working group?
[00:59:30] Danny Mayer: Yes.
[00:59:31] Karen O'Donoghue: Or is this
[00:59:31] Danny Mayer: I think so.
[00:59:33] Karen O'Donoghue: Alright. Sarah, do you have sent me one?
[00:59:38] Sarah Grant: Yeah. Is this just looking at the NTP protocol, or are we also looking at NTP time stamp usage in other protocols? Because I'm I'm just thinking of a few off the top of my head. I think SSTP and a couple of others have taken NTP timestamps, but I'm fairly certain they're not transmitting error. The error number or any other sort of thing that would indicate a boundary. Should there be something done about that as well? Or
[01:00:17] Karen O'Donoghue: That's a good question.
[01:00:20] Danny Mayer: The short answer is yes. I mean, if if you look at it, anything which uses NTP or or your system clock needs to be looked at. This is a huge problem everywhere. And beyond that, a lot of these systems are running 32 bit hardware, and they may very well cause problems.
[01:01:01] Karen O'Donoghue: Okay. So my simple answer to the liaison and my expectation for future work for this working group was a little bit optimistic, I guess. At this stage go ahead, Ruben.
[01:01:34] Ruben Nijveld: Yeah. I'm I'm just thinking that maybe this is also something that that should be a sort of addition to Entity v four as well, specifically because of existing implementations in the wild. It's not just an NTPv5 change that needs to be made. It's specifically, like, to worry about existing usages of NTPv4 and older. I think we should worry about those as well.
[01:02:07] Karen O'Donoghue: Okay. Danny?
[01:02:09] Danny Mayer: Yeah. I agree with him. We need to worry about NTPv4. Given the the length of time it took for to go from NTPv3 to NTPv4, you expect that there'll be a lot of NTPv4 systems out there by the time 2036 comes around.
[01:02:30] Karen O'Donoghue: Yeah. I expect there to be a very long tail on transition.
[01:02:34] Danny Mayer: Yep.
[01:02:37] Karen O'Donoghue: Okay. So I I guess that the the IT liaison piece is oh, sorry. Go ahead, Miroslav.
[01:02:56] Miroslav Lichvar: I think this is a problem on the implementation side. NTPv4 is written is written it's ready for the next error. I don't see a problem with the protocol.
[01:03:14] Karen O'Donoghue: So from your opinion, the protocol is already structured in a way that addresses the issue?
[01:03:19] Miroslav Lichvar: Yes. I think so. Danny?
[01:03:24] Danny Mayer: Yeah. I it it may be true, but that needs to be validated. That's the other part of it.
[01:03:40] Karen O'Donoghue: Ruben or Miroslav? I don't know who's Miroslav? Oh, he's out. Okay. Ruben?
[01:03:48] Ruben Nijveld: I think the the one thing where, at least from my understanding, where NTPv4 falls short is if the local clock isn't set. So it's it's set to some some notion of zero in in Unix time stamp, then I don't I'm not entirely convinced that NTPv4 is prepared for that on the protocol level to handle era jumps as the text stands right now. So I I would still want to at least look at it.
[01:04:26] Karen O'Donoghue: Okay. Miroslav?
[01:04:32] Miroslav Lichvar: There are few different ways how this problem can be addressed on the implementation side, and I think this could be a document. Like, recommended practices, one common approach is to embed a build time in the in the program pivot the time around it. Like, assume that everything all time stamps are after that build date and assuming you can rebuild the software at least once in hundred years, then it should work.
[01:05:21] Ruben Nijveld: I I would agree with that. Yeah. That would be one way. But at least we should then provide this guidance so it's it's used the same everywhere.
[01:05:36] Karen O'Donoghue: Alright. Danny?
[01:05:38] Danny Mayer: Yeah. The bigger problem is gonna be people who don't update their NTP versions. And that is gonna be a problem because there are a lot of obsolete equipment out there. And that's a much bigger issue. And we're talking in the millions.
[01:06:03] Karen O'Donoghue: Yeah. I'm just not sure what what we can do beyond publishing a best practices or some operational guidance perhaps in conjunction with the ops area. But I I think that I guess the next step for us is for anybody who if people could start, I don't know, you could either do an email or a short draft on what you think the issues are, best ways to proceed with solving the issue, or if you are eager to try publishing your first Internet draft. If you haven't done that, maybe this is an excellent opportunity for an issue to dig into. I think we're gonna need some contributions at some level to figure out what we wanna do beyond the liaison update. So but this has been a helpful conversation. Any other questions or comments on this topic? Okay. So the last agenda item prior to any other business is an IEEE 1588 update. I wanted to basically remind folks that currently, the NTS document that is was the NTS specification that we have in this working group is being leveraged in two different ways in I triple a 1588. The first way is the NTS for PTP that we talked about earlier. The second way is there is a new effort, relatively new at this stage, called 1588 dot one, and it's CSPTP. And it's basically client server PTP. In a simplification of, you know, a slight simplification. It's basically an NTP like version of PTP. So it it is intended to be more like NTP. And as a result, the idea is that the NTS protocol can be used exact the same way that it's used for NTP. It can be used in this in that way for PTP. These are both documents that are under development. If you feel like you need access to either of those the drafts of either of those documents, please feel free to reach out to me because they do impact some of the work that we're doing here. And as I mentioned earlier, the 1588 group is happy to share those documents for the purposes of standards development in a collaborative manner. The CSPTP document, the security is we have a separate draft for that, and it is pretty stable. It hasn't changed a lot. But the underlying CSPTP is is not quite as stable. So we can give you access to the NTS first for CSPTP document pretty easily. The it's a little bit difficult to review, but the amendment where the NTS for PTP material is discussed is a in IEEE, it's a IEEE amendment to a previous document. So it it doesn't read as a stand alone document. You really need to have both documents to read them together. But that will be coming back to us here probably in three or four months. So I'd like people to keep that in mind. And if anybody wants to get a head start on understanding what PTP is and how it interacts with the work we've done here, please reach out, and I can get you access to those documents. Any questions or comments? Okay. This is the any other business portion of the agenda, which I think which primarily we is what we use for next meetings and to discuss whether we're going to do any hackathon projects or not. At this stage, I'm not aware of how many people are planning to come in person to Dublin. I know some of our key hackathon participants are European based, and so that's a nine hour time difference. It's a little bit inconvenient. However, if some of you who have been regular participants in our small but mighty hackathon team want to have time to work on the weekend, if you could reach out to Dieter and I, then we'll we'll add it as a project. But otherwise, the the next face to face opportunity for IATf is is in Kuala Lumpur in March. So that that's a bit more challenging unless we do something outside the context of an IETF. So I I would for those of you who are working on implementations or implementation testing, if you can give a a thought to what you think you might want to do for for future types of activities for hackathon or interoperability testing. If you could just give me a a heads up, that'd be great. And if I don't hear from anybody, I think we will not plan to do a project in Dublin unless there is a request. Also, I mentioned at the beginning of the call to ask people to think about it before we got to the end of the call, and that was our whether or not we wanted to have a second virtual interim. My primary motivation for that was to help move the NTPv5 spec along. I'm not sure. So, Miroslav, I'll I'll go back to you and say it's really do you think that would be useful, or do you think sticking to the November time frame for the resolution of issues would be useful?
[01:13:07] Miroslav Lichvar: Which issues?
[01:13:10] Karen O'Donoghue: So we have the we need an updated document, and then we had the a couple issues that you brought up in this call that we're gonna require a little bit more discussion. So we can try to do those over the mailing list and just plan to meet in the context of IETF 121, or we could do a virtual interim in the mid October time frame. Do you have a preference?
[01:13:35] Miroslav Lichvar: I think we can do this on mailing list.
[01:13:38] Karen O'Donoghue: Mailing list. Perfect. Alright. Any other business? Alright. Thank you all so much. Have a lovely day.