**Session Date/Time:** 17 Mar 2026 01:00

**Zahed Uz Zaman:** Okay, it's top of the hour and welcome to Shenzhen. Welcome to IETF 125 TIPTOP session. Here I am your chair, Zahed, and on the remote, I have Padma. In the room, we are around like seven people, eight people here, and on remote we have a good participation. So Padma, please take us forward.

**Padma Pillay-Esnault:** Yes. Hi everyone. Welcome to the TIPTOP working group session. So, before we get started, please there's a couple of things. Please be- make sure that if you're in the room to actually sign the blue sheets. I don't know whether we have any volunteers for note takers.

**Zahed Uz Zaman:** Yeah, we need we need a note taker for the for the meeting. Do we have any volunteer in the room? You don't need to like do the narratives, you just can just write the high-level points that was discussed or decided in the meeting. That would be great. Do we have any volunteer? Anybody?

**Padma Pillay-Esnault:** Okay, Marc saying that he can do a bit of note-taking, but it would be good if somebody else can also do some note-taking. I can do some as well but...

**Zahed Uz Zaman:** Thanks Mark. I think we chairs will be mending. Mark, you want to try to help?

**Padma Pillay-Esnault:** Okay, great. Thanks Adam.

**Zahed Uz Zaman:** Yeah, I'm Adam. Not sure.

**Padma Pillay-Esnault:** Yeah. Thank you to both of you. And just before we get started, there is also, as you know, the blue sheets. If you're in the room, make sure that you are actually connected. And for remote people, you should be already signed up. So, now let's go through this part. The note well. As everybody hopefully knows by now, by participating in the IETF, you agree to follow the IETF processes and policies. The note well is a reminder of some of the behavior we expect to be professional and extend respect and courtesy to all your colleagues at the same time. If you have any concerns, please do contact the ombudsman team. And if you are aware of any contribution that is covered by patents, please speak up and let us know. And for the detail process, I will let you read the rest.

Okay. Next. The session is recorded. There was a note if you- make sure that if you're talking to- remotely, to make sure that you keep your video and audio off if you're not using it. And for remote people- for participants as well, please for all the note takers, please state your name each time you start beginning to speak in the queue or at the mic. That makes their life much easier as well. So the resources for Shenzhen, you know them already. There is a Zulip channel as well for this IETF 125.

And here it is. Today, we're just going to go over the working group status, the document status, rather, by both- I'll be doing this and Zahed might have his comments as well. And then we're going to go look at the details of some delta that has been introduced in the key characteristics use case requirements since our last meeting. The big piece of the meeting is going to be by Marc Blanchet on the TIPTOP IP architecture, and he will be addressing the comments that were sent during the adoption call. And the last one is optimization of QUIC in deep- for deep space transmission. So let's go next directly to the working group status. So, the first one is thanks to all the co-authors who have updated their drafts. The TIPTOP use case will be- we'll be looking at the delta today. The draft-many-tiptop-ip-architecture has gone for an adoption call, and there were quite a lot of comments. I've actually noticed as well there was an IPR that was flagged during that call, but no one actually filed it. So I- I will request the person who actually said this to actually file the IPR. And then the other documents have been updated but not presented today. So we'll be actually going through the next slides. Zahed, do you have any other comments? It's a pretty simple agenda today.

**Zahed Uz Zaman:** No, no. I think you covered it well. Thank you.

**Padma Pillay-Esnault:** All right. So the first one, Wesley, that's going to be yours.

**Wesley Eddy:** I still see the slides are trying to come up here. Have they come up for everyone else?

**Padma Pillay-Esnault:** Okay. Can you request that again or else I can share it? Do you want me to share it? I can.

**Wesley Eddy:** I'm seeing a new deck is being shared. Yeah, I see them. Okay, great. I'll just let you do it. All right. Great. So this will probably be a fairly boring presentation, but let's see. Mark, myself, and Marshall have been editing this use cases document. And you can go to the next chart.

We have had this as an adopted working group draft for a little while. There's a GitHub page that you might want to look at in addition to the Data Tracker. That's where we're keeping track of open issues and taking merge requests from people. This particular presentation today, I'll cover some updates we've made since the last meeting and some of those open issues and pull requests that are on the GitHub. Next chart.

So this has been around for a while. The history here actually is only tracking the TIPTOP version of it, but we've been working on this since the Deep Space BoF prior to the TIPTOP naming convention. So it- we've been working on this a long time. It's fairly stable at the moment. And since the last working group meeting, in particular, we only made some minor changes that I've got about two slides to detail here. We made only one update since the last IETF meeting.

So the next chart should mention some acknowledgments. We added content based on comments from these six people. And we added your names because you said something on the list or at a meeting or otherwise that made at least some small impact to the document. So we've added these folks to the acknowledgments. Next chart.

These are the real updates since the last revision. So there were some comments that certain terminologies we had used weren't clear to everyone who didn't have all the same background. So we put in some more definitions about Lagrange points and what the Lunar Gateway is. Beyond that, we also added two new requirements. Oh, go back. We added two new requirements. We added one on location. The thing motivating that was noticing that there are some IETF protocols that actually embed location information, carrying some representation of latitude and longitude coordinates, for instance. And the the draft now notes that any of these protocols that are adapted to run for deep space use cases would need to be modified to carry coordinate information that works for other planets or areas as well. We also added a requirement on energy, although it's fairly general, but conservation of energy and low power modes should be a consideration for any protocols that are tailored for use in a deep space environment. And then finally, I think the thing that bears further discussion is we did make some additions to the security considerations based on comments. First of all, we added citation for the CCSDS book that describes the threat model a bit better. We had comments from the prior meeting that it would be good to understand more about what the envisioned threats to space missions are that need to be defended against. And so we thought that was a good existing document that we could refer to. We also added some generic text noting the need for efficient key agreement and we have a note as well on post-quantum crypto. Though, I would say among the editors, we think we could state something more strongly there than the current text does. We were thinking it should probably say something like crypto in deep space protocols should align with IETF recommendations for post-quantum cryptography or something like that. So we may propose and discuss a stronger stronger statement about post-quantum crypto through the list or maybe in this meeting discuss. Next chart.

**Zahed Uz Zaman:** Are we taking questions at the end or what?

**Wesley Eddy:** That one, feel free to discuss here if you want, Zahed.

**Zahed Uz Zaman:** Yeah. So can you go back? So there are no IETF standards for post-quantum. And there's no IETF consensus on what should be there. So I don't think that doesn't necessarily answer the question of what it'd be here, but you can't just point- you can't just point outward. You know, I mean I guess I would say I would say that the, you know, the observed behavior of the IETF has been to drive towards hybrid key establishment mechanisms, that is some combination of elliptic curve and a post-quantum KEM, and to drag its feet on post-quantum authentication. And so, I'm not saying that's what you want to do. I mean obviously a situation where you have something in space and it's going to be there for, you know, for decades, maybe a little different. But I'm just saying that's the observed behavior of the IETF. And and to make matters worse, frankly, the observed behavior of the IETF in some respects is driven by the lousy bandwidth characteristics of post-quantum authentication mechanisms. Which of course are are more problematic in this case than perhaps in other cases. So, I think I don't know what to say about this. I think what- I think what might be helpful to say, I think perhaps what is required is actually some some requirements analysis here on, you know, that comes out of the comes out of the specific, you know, environment here, which is some- something-something, you know, these things are in use for a long time, something-something, it's really a problem, something-something, bandwidth, I don't know what, but like to try to actually analyze the situation based on the based on the characteristics of the system and the characteristics of the known technologies, rather than necessarily hand it off to the IETF as a whole. So I'm not sure that was very helpful, but but I think that's probably the work that has to get done.

**Wesley Eddy:** I think it was helpful. We know specifically what we shouldn't say now. But we'll probably- maybe we can run some text past you as we try to tighten this up.

**Zahed Uz Zaman:** Sure. I'd be happy to- I'd be happy to look at text. As I say, I think it's going to- I think it is going to have to like, you know, have something about, you know... I mean, I would say like, if you- my basic put is you really should do post-quantum key establishment. And at least, I don't think- I think there's like, you know, some question how often you have to do it, you know, maybe- you know. So like, I mean I know there's basically systems that really do like, you know, PQ like, you know, once, and then EC like all the time. And they're like, well, you know, what I guess we'll take the hit if- like if- you know, we'll take the forward secrecy, the PFS hit if like, you know, if if the EC is broken. Mumble-mumble. But I mean, like, I think- I think I think it would be probably not a good idea to not do any kind of post-quantum key establishment at all. I think the question of post-quantum, you know, authentication is a little more tricky given the performance properties. I think that also depend on the, you know, like the authentication architecture, I guess what I would say. So, again, I don't really know what you have in mind here, but, you know, like part of why- and chairs please stop me if I'm saying- if I'm going too far into the details, but um- but like part of the why that people in like the web PKI are not jazzed about post-quantum is they're not jazzed about having like a pile of big pile of signatures. And like when you add up like the, you know, like you add up like the, you know, the- the signature on the signature in the- in the handshake and the signature in the certificates and the signature maybe on some intermediate and the signature on the on the SCTs, and like you got like five or seven signatures, it's a lot. So maybe you don't do that. Maybe you- maybe you have a much simpler PKI and so the hit isn't as bad. So I think it'll have to be analyzed against that. But but I think I- my initial prior would be I think people would think it was very out of step to not do anything for key establishment. They would think it was less out of step for- to not do anything for authentication. And I see Sean is by the way here. So Sean may have an opinion on this topic too but... I see he can hear me because he's thumbs up. So... Anyway, but I'm happy to take a look at the text.

**Padma Pillay-Esnault:** Okay. Next.

**Wesley Eddy:** So we have three open pull requests on GitHub also that I wanted to mention because they've been open a while, and we did have on each of them, I think, a little bit of back and forth, but I don't think any of them have really come to consensus or even really as an editor, I can't look at them and say I know what to do. So the first is on group key support. And there was a good discussion. It's captured in the comments on that pull request. However, I don't think it the discussion really closed. So it seems to be the nexus of it is do we really need group key agreement? Does that- is that needing to be elevated to something that's called out as a requirement in this document? And it seems like we have a mixture of opinions at the moment. Go ahead.

**Zahed Uz Zaman:** Yeah. And I think one way- one way perhaps to think about this question is actually about the- I think it's- I think it's kind of a mistake to try to think about this in isolation, frankly. Namely that that like the protocols that I've seen flow- like bandied about here, QUIC, whatever, are not designed for groups. They're designed for point-to-point communication. And it is unknown what the properties- if- assuming you had a group key agreement protocol, it is unknown what the properties of that system would be if you had three parties all with the same shared keys. And so- and so I think that like the actual question is what is the communications topology and what are the properties you're intending to- intending to induce in that communications topology? And I think that like basically trying to like graft a group key agreement thing onto like something that was effectively a point-to-point protocol is an error. And if you- and if you want a thing that has like point-to-group properties, we ought to design that. That transport- that's a transport problem of what that thing looks like and then we- and then we design the security mechanisms around that transport. Rather than try- rather than taking the existing transport which is designed for one mechanism and grafting group key agreement onto it. And so I think that's the place I would start, is like what are the transport requirements of the thing you're trying to build? And then once we have that understood, we can talk about the key structure with the key structure. And so it may very well be the case that you need a thing that smells like a group- a group messaging system where you have like message sent to multiple people and you- and we have data resource authentication for them or whatever. And then you would need a group key management system. But then you have a- then you also have a group messaging system that goes along with that and what are the requirements of that? And does that smell in any way like- does it smell like a real- a classic messaging system? Does it smell more like a multicast transmission system? Does it smell like, you know, what kind of reliability mechanisms does it have, if any? Does it have, you know, re- you know- I mean, those are the kind of questions I think we ought to address first, and then after that we can talk about group keying. So I'm not saying it shouldn't or should be in there, I'm just saying I think it's subsequent to the to the architectural question.

**Wesley Eddy:** So, I agree with most of what Ecker said. The question, I think, is whether we have a requirement for MIKEY, which is IPsec group key management. If we're going to be using group keys at that layer, then we're going to need a solution that is in my opinion post-quantum because this is the key encapsulation stuff that Ecker was talking about in his previous rant. So that I think is the question. If we look at the bundle protocol, they felt that they had multiple recipient problem, but they dealt with it like we deal with email, not with group keying. So we do have to know which of those two problems we're trying to solve because we probably have a tool in the toolbox once we know.

**Padma Pillay-Esnault:** Hey. I've got a question about this where this is coming from. The use case would be that we want to do some kind of broadcast of something, right? I'm guessing about scale. One thing is I would caution a little bit is that I think we should crawl, walk, and then run. And right now, we're still in the crawling stage. I think it's good to have it as a- as something we're thinking about for the future, but to put as a requirement, I think is a little bit strong at this point. Other people may have different opinions about that, but I'm just wondering exactly what is the use case- exact use case where we will be using that? The only one that I can think of that might be interesting would be trying to actually send a message to- for everybody to, you know, update or something. But knowing that we have a limited bandwidth, those kind of use cases become harder. So I am conflicted on that. Whether this is really something we need right away.

**Wesley Eddy:** No, that's helpful input. As far as the use case, in the comments on that pull request, we were noting some of the point-to-multipoint sort of messaging that's in the LunaNet architecture. And that could be a potential... there are some- there are some usages there for different message types that you'd want to send in a sort of broadcast or point-to-multipoint fashion. But certainly like you say, we could do a lot without solving that problem at first. And also, that initially might be solved in other ways. So...

**Padma Pillay-Esnault:** Yeah. I just don't want us to be mired in something where we might actually have a easier immediate solution. And it looks more like a scaling thing for me, and you know it would be good to have a good base solution. That's just my two cents. But thanks.

**Wesley Eddy:** Right. So the next one we have is on FS and PCS considerations. And again, I don't think the conversation really came to a conclusion. The suggestion was to separate consideration of these two things and not tie them together and it looked like there's just no agreement. So I don't know what to do about that necessarily other than maybe bring it to the mailing list and try to expand the conversation there because there's probably more people on the mailing list than are checking the GitHub pull request. I think same thing on the next one, on the asynchronous rekeying support. Again, it didn't really come to a consensus in the comments on GitHub. So my thought was to try to bring it to the mailing list and figure out whether it's a requirement or just a nice to have thing. But in any case, seems like we could mention it. It's just how strongly we want to do so.

**Padma Pillay-Esnault:** May I suggest something is that for these two to bring it back to the list and that there is a consensus of these look- you know, some of them look nice to have for me. Let's, like I said, let's crawl first and walk. I understand it would be good, but is it a requirement? I'm not sure. But let's open this discussion. Thanks.

**Zahed Uz Zaman:** Yeah, I think for these, if you- I mean I would prefer to have this discussion in the GitHub. And if- and but if there is no like traffic on GitHub, then definitely start separate like mailing thread on these things to decide on that one. I think for the group support, we got a very good comments here, so we can work on that one. But the others, I think, you- I mean just start three mailing threads on this one and try to discuss and conclude. And maybe you should be also clear like we are talking about requirements or considerations in the mailing.

**Wesley Eddy:** Okay. Next chart is on one more open issue that we're tracking in GitHub. We plan to make a change to mention that there are impacts due to conjunctions between the sun and different planetary bodies that will cause fairly long duration limits in connectivity sometimes. And I just put in a figure and table from a reference you can find at the bottom there that describes that a little bit more, but it's just trying to motivate that there may be spans of multiple days in some places where there won't be connectivity. So something worth mentioning in the document. This is pretty unique to solar system networking, I guess, being offline for multiple days. So we thought we should add something to mention it, but we haven't crafted specific text or put it into the document yet. Next chart.

So what we have planned left to do is close out the discussions on security topics that we were talking about previously today, add that text on the conjunctions impact, and then if anything else comes in from the working group, it's more than welcome, but we don't as the editors have any more lists of pending changes planned at the moment. That's all I've got.

**Zahed Uz Zaman:** Okay, I- I mean I see Tony on the queue. So.

**Tony Li:** Hi, Tony Li. Um, Wes, how far are we from adoption on this?

**Wesley Eddy:** We're past adoption. It is adopted.

**Tony Li:** Adopted. Okay. So then, how far till we are closed here?

**Wesley Eddy:** It feels like we're close, but I think those few security things we just talking about will require some real work and thought. I mean- I'm optimistic we can get that before the next meeting. But I don't think there's a need to rush it either.

**Zahed Uz Zaman:** Right. So so my suggestion to the authors, like whether some people actually create an issue on the GitHub or in the mailing list, there is some- I think the authors, if you just start to create the issues on the GitHub, then we can see like when you have no issues, I think we're ready- we can say that we're ready for like go the next step. So that would be a good marker on where we are. Just a suggestion for you, Wes.

**Padma Pillay-Esnault:** Mark.

**Marc Blanchet:** Um, yeah, hello. Um, I would like to respond to Tony about how far are we for publication request and um- I- I- I would sense of having that document lying around a little bit more and taking the wisdom of Sean at some meeting before, I don't remember which one, but um- given that I don't think we have- we may find additional requirements as we go over, you know, the other protocols of our stack. So um- I would- I'd keep it on the side for some time before moving to the next, you know, publication. Not- not, you know, years away, but um- you know, sometime.

**Padma Pillay-Esnault:** Hey, it's me again. Um, there is something that um I have been thinking for some time, but I- I wanted to let the- the discussion progress on that is- um, you mentioned energy earlier, and you mentioned a number of things. There are a number of limitations due to the space vehicle. And I think one of them that we really need to think of as well is about traffic priorities because we will have network management and management of the vehicle itself. And that cannot, you know, the actual customer traffic or whatever payload traffic cannot actually impede on that. We haven't written anything about that and um I can definitely, you know, give you more more details on that, but I think this is something we need to add because that's going to influence also the storage, store and forward, and all these other things that comes into play. So- so definitely I would like to see something like this come up.

**Wesley Eddy:** That makes sense. Leveraging existing IETF mechanisms for priority and precedence... Yeah, sure.

**Padma Pillay-Esnault:** Yeah. I don't think we need to invent anything, but we need to be aware that these things should be there for things to work well.

**Wesley Eddy:** Yeah, that makes sense.

**Padma Pillay-Esnault:** Okay.

**Zahed Uz Zaman:** Okay, I see the- nobody is in the queue. So, thanks Wes. I think we can move to the next presentation and you have some work to do.

**Padma Pillay-Esnault:** Yeah, the next person is actually Marc. Marc, do you want to take the hand on the slides?

**Marc Blanchet:** Uh, sure. How do I do this?

**Padma Pillay-Esnault:** You have to go um- um you have to request- okay, just give me one second, I'll try to see if I can actually... Do you want me to share it? I can.

**Marc Blanchet:** I- I think I have it.

**Padma Pillay-Esnault:** Yeah, exactly. Thank you. Okay. Um- good morning, afternoon, evening, good night for maybe some. Um- this is an update on the draft-many-tiptop-ip-architecture, which is not yet working group document, and that's the purpose of this presentation is to go through all the comments that were done during the call for adoption. Okay, so- the working group call for adoption was for version 02 that was done by the co-chairs on December 14th. Um- the outcome summarized by the co-chairs was sent on 12th of January. Um- in- I'm quoting the email: we received responses from 22 participants, a clear majority expressed support for adoption. Several participants did not support adoption at this stage and raised points requiring further work, and a few provided comments without stating an explicit position. Um- it is important to restate the purpose of the working group adoption call. Support for adoption reflects the working group interest in the topic and in progressing the work within the working group. It doesn't imply agreement with the current text solution approaches or conclusions, nor does it represent approval of the final document. And I- I know I'm repeating, but I think that's an important thing to- to know and, you know, say. Um- the email sent by the co-chairs had a summary including a table of content of comments, and I will take that- I'm going to show the content of the table in the next slides. Um- the co-chairs request the editors to update the document and we made a new version 03 that we posted on March 2nd. Um- and at the same time of the new version posted, we replied to the co-chairs email with the kind of a- our um- our response to each of the comment. Um- so this presentation is really the same content as the reply. Um- in the summary in in the table of comments from the co-chair, there were 10 people listed supporting the adoption with no additional requests or comments. So this is not shown in this presentation. Um- caveat. While we try to resolve the comments, the outcome is not necessarily document ready, it's not a document ready for publication, but hopefully ready for adoption. So we still have work to do on it.

So let's go into each, and the order here is just the order of the table of comments. So- comments from Carles, he supports the adoption. He was suggesting something about the fact that the table of content on- especially the applications and HTTP and stuff were not structured properly. We already had a pull request on this by the editors, so we agreed and we created a new application section where HTTP is one of the section and we added generic text at the beginning of the application section. Um- I'm not going to read all the text here, but um- this is- the screen here is showing the diff tool of the IETF between the 02 and 03 versions. Um- the other comment...

**Zahed Uz Zaman:** Hi. So I'm actually reading this text now and I'm not sure what it says. Can you go back? So when you say it's pre-cached and replicated at planetary orbital gateways, like who are those gateways associated with? Associated with the origin?

**Marc Blanchet:** Oh, okay, I see where you're referring to. Okay, so- no, it's not the origin, it's- so for example you could see that some HTTP content are cached on the celestial body where to avoid having, you know, back and forth on the deep space links. So it's really, you know, normal, you know, it's like a CDN in some ways but on the- on the celestial bodies network. And you may remember that the typical, the current plan for deployment is where the the celestial body network would be very well connected in the sense of using, you know, our terrestrial technologies and with essentially no- you know, high bandwidth, very well connected environment and no delay. So while the deep space network- you know, links will have heavily limited bandwidth, long delays and disruptions and stuff. So that's the kind of the- the architecture or the- so I don't know if I'm clear.

**Zahed Uz Zaman:** Yeah, I fear it's not. I guess- I guess my- so in the case of a CDN, right? The CDN is the origin as far as the client is concerned. And maybe the CDN happens to like go back to the origin, but that's not the client's business.

**Marc Blanchet:** Well, yeah right. Okay. Well, I guess we probably need to work a bit that the text actually.

**Zahed Uz Zaman:** Well, I- I think I- I worry it's not a text issue, I guess. Which is like conventional non-encrypted HTTP caching depends on on endpoints which are effectively trusted by the which are effectively trusted by the client but do not present the origin's identity, right? Because it only works without TLS. And TLS basically breaks like all conventional HTTP caching. Um- and so and that would be true for QUIC or whatever. Right. And so I guess my question is is that the model you have in mind here? Like what are- like I guess my question is like how is this supposed to work?

**Marc Blanchet:** Um- it's a good question. I don't have a good answer right now in terms of how I guess that that the HTTP part is probably, you know, not enough specified for the moment.

**Zahed Uz Zaman:** Right. I think what's important to understand is the trust relationship between those endpoints. Um- so that's the thing I think we probably need to sort out. Um- but- in any case I'm not sure it's meant to be done now but I- I flag that because that's actually quite important and actually goes to whether or not it's acceptable to have like- I mean, like some of the things I hear in this working group like what people are trying to do is like adapt conventional transport protocols that are designed for like very high- ultra-low latency and then make the transport work better. And then sometimes I hear things that sound like actually we need a different like- a conceptually conceptually different design. Um- and I worry that this is in the second category rather than the first. Um- but anyway, I'm happy to sit down but that- I flagged that as a potential issue.

**Marc Blanchet:** Thank you very much. I think it's very appropriate and um unfinished text, let's say that way. Um- I guess we'll see how it goes, but we do have between all the comments some overlap, so we may end up answering questions where, you know, they are already answered somewhere else or things like that during the presentation. So we'll see. So another one, let me see how can I change the screen. Okay, so Mr. Chen, support for adoption yes, co-chairs ask their summary which was a bit more meta than the actual comment. Clear end-to-end architecture view, classification protocols, expanded security discussion, store and forward mechanisms without protocol modification. So the way we handle this and actually this one is actually handled for- is actually our response to multiple comments. Um- so we had a whole new section on architecture overview, that one of the thing is that it defines different node types and then, you know, small picture that describes a bit what we're talking about and Mr. Chen was also suggesting drawing. We have a completely new rewritten security section and we also enhance the introduction. So again, that's kind of what you see in green on the screen is actually all new text. So- I guess I'm moving ahead. Comments from Brita Hale, it was no support for adoption, raised concern- so co-chairs resume by saying there was concern about architectural scope, protocol specificity, and treatment of security consideration. So one of the outcome- this is also a change that we did for multiple comments- was that there was a complaint- a specific complaint that QUIC was kind of a- even if the editors were not intending to, it was seen as a requirement of you need to use QUIC, where there was no intent for that. So we revised the text and we kind of removed QUIC as an implicit default and write it as just an example and we actually added other transports to the transport section. The other complaint was that the 0-RTT that is, for example, implemented in QUIC was- was- how can I say- not enough characterized, especially about the replay attacks. And- and so we kind of write that explicitly that 0-RTT was subject to replay attacks and should be disabled depending on the security policy of the organization that is um- where the application or whatever. We rewrote text on the key establishment at launch. Again, a similar way in the sense that it was interpreted as a something you should do, and we really change it to something which is, you know, you could but be careful about the security considerations about it. And again, for like the previous one, we rewritten the security section. I'm seeing on the side some comments on the chat but I can't really now...

**Zahed Uz Zaman:** Oh, so- so actually can you go back to the previous one?

**Marc Blanchet:** Yes.

**Zahed Uz Zaman:** Like, I think the way I would manage this actually would be like maybe just to make this make everything starting from transports more general and not talk really about 0-RTT and in particular not say 0-RTT should be disabled. It may well be the case that 0-RTT should be enabled, but why would you say it here? That's a question we should resolve later. Um- so I think like I would just sort of say like it's desirable that like, you know, it's desirable to like resume to like pick the connection up quickly is like the- is like the key point, right? That's the- that's the point this is making is whatever like we're designing, it would be good it'd be good to like to be able to like pick the connection up quickly. Um- so I- I just- I just think like towards... I agree.

**Marc Blanchet:** Uh, I think we- our current writing is almost like what we're talking now, you and I, but it may require additional, you know, text word-spinning. Um- one thing that we try to do is essentially change a document so that all the friction points go away for adoption, but we do not pretend that the text is final far- far from that, but we're proving based on the comments but um- so- yeah, I agree. There's probably some additional, you know... But it's anyway, I think we try to write the way you said it but maybe it's not yet there.

**Zahed Uz Zaman:** Yeah, I think I- I think what I- I mean yeah, I- I could send more comments if you want, but I think what I would do is I would just remove this statement the use of 0-RTT isn't recommended. I think that isn't getting us very far. Like maybe it should be discouraged, but like that can come later.

**Marc Blanchet:** Um, yeah. Okay.

I still have a big screen, but okay, let me- sorry, it's because I don't see my- it's too small for me. Uh- so- the other- there were a lot of comments from Brita and others about security. Um- I'm- I'm- you know, speaking for myself, I'm not a security expert. Uh- but and we- we wrote something. Uh- I'm sure there will be more to edit on it, but uh- it was obviously a very thin section at the beginning. I think it's better now, uh- but frankly it will be- it should be much better with, you know, contribution from- from people. Um- from Marshall, support for adoption yes. Um- there were- Marshall was talking about surface networking and around those, and we actually enhanced the section 1 and also referred to use case document, and the section 2 was added, so all this kind of clarify that surface networking is pretty important. There was a- I think a few email discussion about if this- is this in scope or not, given that surface networking will be high speed and and, you know, well connected and stuff like- almost like the normal internet we have, but in reality is we're talking- we're looking at the whole end-to-end architecture, not just the pieces. Um- so- Jimmy supporting yes and similar comments from that I just talk about the surface networking, so we kind of also take care of this comment too. That's why I'm not showing text on- on the screen, new text because I already presented. Sean was not supporting for adoption. Okay, so- suggested that the- the co-chairs was saying- were saying that he suggested that the draft would be more requirements and constraint focused and less solution centric. Um- I hope we did enough of this, I don't know if we did too much or not enough, but there is a, you know, completely new section 2 with the node types as described, the- with requirements, and the QUIC overview removed as implicit default and I'm seeing on my screen that Sean is kind of a- I'm expecting a question.

**Sean Turner:** No, hey, I just want to say, Mark, I think you're moving in the right direction and I think that Ecker's comments earlier about this draft and the things he wanted to change are basically on exactly along the same lines that I want. So I think that we're definitely getting there. Um- and I appreciate your effort. Thanks.

**Marc Blanchet:** Thank you.

From Eric, support for adoption no, suggested clarifying architectural intent, normative expectations, removing vague examples. We- similarly to others, so there was kind of a a trend of various commentators about similar, you know, things to change in the draft. So similarly, we add a new section 2 with node types and requirements. QUIC was removed as an implicit default. Uh, we removed Wasm and we have a new security section. Um- again, I already showed the text.

Johnson Yu, support for adoption, he suggested strengthening architectural function beyond conceptual description. That's the summary of the co-chairs. We added a new section on architectural review overview, section 2 as I showed before, and we added additional text regarding PCE. Um- so hopefully that take care of his comment.

Russ was not supporting adoption. Co-chairs summarized it, um- comments on requesting focus on architectural level requirements rather than solution section selection. We replied on the mailing list, there were kind of two comments essentially from Russ. The first one was about addressing and we kind of enhanced the text there. The second one was about the- um- well the second one was about the RIR, um- and the addressing. So we actually add text on addressing and the RIR person actually didn't require any change. So um- that's how we solved the Russ comment, hopefully.

Benjamin Dowling was not supporting adoption. Uh, similar- in similar vein than Brita Hale, requested clear architecture articulation of security goals for space networking. We rewrote the security section. Um- we didn't add new new requirements- security requirements, as the we feel that it should be first defined clearly in the use case requirements. Uh- so um- because part of his comment was kind of implying that we have some requirement, for example, what we discuss in the previous presentation. So our- our point here is we should first get consensus on the requirements that will be done in the use case requirement document and then depending on the outcome of this consensus, then we'll- we'll write the right text in the architecture.

Jed El-Cham, the RIR person. There was no position for adoption. He suggested that we are- we should be engaging the RIR community and to ensure realistic addressing proposal. The addressing section has been enhanced, we referenced to the other draft and I've seen a someone who actually started this discussion in some RIR mailing list, so I think we're- we're getting there.

Mr. Tien was not supporting adoption, again similarly about security, so again we remove QUIC as implicit default, just write it as an example, we added other transports, we rewrote the 0-RTT text, rewrote text on key establishment at launch and new rewritten security section.

So that's I think all the comments we received. So- editors believe we've addressed the working group adoption call comments. Um- frankly, this doesn't say the document is ready for publication and we already have very good comments during my short presentation, but we're really targeting it for adoption. So- I think the working group should be looking at the document. Is this the right kind of a frame for- for this milestone? So we're again requesting working group adoption of this new version of the document. That's it for me.

**Padma Pillay-Esnault:** Hi Mark, thank you so much for enormous amount of work and addressing all the comments and um and thank you for making the document much better as well as your co-authors. So um- Zahed, um there has been a number of discussion in the room and on the- on the Zulip channel as well, um about, you know, whether we have- I think the document has addressed a lot of the comments that were there. Um, do we want to- the authors are requesting the working group adoption so...

**Zahed Uz Zaman:** So yes, I mean this the authors has been working on the um- like the comments they have got and they have shared their updates in the mailing list before this meeting. So we- we expect like whoever has issues actually could look- have a look at it and come back in the mailing list or today. So I think Padma, before calling for the pool, I would still like to ask the room and the remote, like if there are any outstanding concerns from the people who has already raised their concerns or there's new concerns, we- we should give some time like- if you have any comments, please come to the mic now otherwise I'll go and start the pool. Well, I don't see anybody coming to the room and I don't see anybody on the remote on the queue. So let's start the pool. It talks about is this document ready for working group adoption in its current state to start the working in in on this architecture. So I think that's the question. Please go ahead.

So, things are- okay, I just wanted to say things are settled down then there was one up. So let's wait a bit.

So now I don't see the numbers are changing, so it's stable. Um- so just for the record we have total participant is 63. We have yes, 14 yes, two nos, and seven no opinion. And I'm gonna terminate the show of hands. So- um- we have noticed two no. Um- and I think it would be great to know like why they think it's not ready. So those who have voted for no, could you please confirm now or maybe in the mailing list if you like to.

Okay, I don't see anybody coming up in the room or in the- in the remote. Um- so um- I think Padma, we can say like we have a rough consensus here to adopt this one but I would like to reconfirm that in the mailing list because there are some participants are not there in the- in the call so they can actually come back on the mailing list. So the current decision is like we have a rough consensus on adopting this document as it is now and we will reconfirm the adoption on the mailing list. Correct. And I can see our AD is nodding. So the process was okay. Okay, um thanks Mark for your presentations. I think we're right on time, actually, we're ahead of time actually. So Padma, what's our next? Okay, so you're- you're here.

**Speaker 1:** Good morning, everyone. I'm Yu Jianhao from Nanjing University. The title of my presentation today is Optimization of QUIC for Deep Space Transmission: An Architecture of Performance Enhancement and Security Extension. Traditional TCP and QUIC fail in deep space networks. Their congestion control and packet loss recovery rely heavily on low delay ACK feedback. However, deep space links have minute-level RTTs and high bit area rate. This strong couple recovery delay with RTT and cause severe head-of-line blocking. To solve this, we introduce part 1: QuickSpace extensions. Our core concept is to replace network probing with prior knowledge. Specifically, we use fixed congestion and flow control windows to handle extreme delay, proactive packet-level forward area corrections (FEC) to handle high area rates, and strict rate pacing to handle bandwidth asymmetry. To emulate the huge delay caused by retransmission, we adopt a adaptive packet-level FEC called streaming codes (SC). Unlike traditional block coding, it encodes unacknowledged packets through a sliding window. The receiver can incrementally decode and progressively recover data without waiting for block boundaries. Data is recovered immediately once enough repair packets- once enough repair symbol arrival. Those two diagrams compare the transmission process of standard QUIC and QuickSpace. In standard QUIC, packet loss trigger retransmissions and creating massive tail delay under minute-level RTTs. However, in QuickSpace, lost packets are instantly recovered locally by FEC with successful decoupled loss recovery from the RTT. To summarize part 1, QuickSpace achieves RTT independent recovery via streaming codes and eliminate probing overhead using fixed windows. Earth-moon simulation verify that it significantly outperforms standard QUIC in goodput, delay, and buffer occupy. However, end-to-end optimization alone is not enough in heterogeneous relay networks. Segment optimization is essential. This conflict is the end-to-end encrypted QUIC completely invalidates traditional transparent performance enhancement proxies like TCP PEP, because the proxies cannot inspect the encrypted transport layer state. This bring us to part 2: the non-transparent secure proxy (NTSP). We propose a novel proxy architecture featuring explicitly authorized splitting, segment optimization and payload encryption. Looking at the architecture on the left, our core design includes: one, explicitly authorized splitting. We use explicit signal to terminate the transport connection at the gateway. This securely split the end-to-end deep space link into two terrestrial TCP QUIC or QUIC segment and a QuickSpace tunnel with zero implicit hijacking. Number two is ALDE, application layer date encryption. The user date is completely opaque to the proxy, achieving zero date trust. The proxy can optimize the transport but can't decrypt the contact. Number three is flow control back pressure. The mechanism precisely match the- match the high speed terrestrial sender to the constrained space link, preventing proxy buffer overflow. This trust balance is achieved through ALDE. The proxy can optimize the connection but can't decrypt, tamper with, or replay user date. This is because the ALDE keys are explicitly derived from the end-to-end TLS handshake, which means we still need one RTT for handshake in the proxy architecture. Giving the proxy no access to the connection. The ALDE ensures the proxy security. The next challenge is stability. The huge bandwidth gap between the fast terrestrial link and the narrow deep space link cause severe proxy buffer bloat. We design a flow control back pressure mechanism by mathematically deriving the optimal flow control windows with strictly limit the access segment rate, guaranteeing goodput while eliminate buffer bloat. The architecture on the left is our- prototype system we call PPSpace. To summarize the three pairs of NTSP: the first one is explicitly authorized splitting, enable peer-hop optimization without breaking end-to-end date security. The number two is ALDE encryption, protect the payload to achieve zero date trust. And the number three is buffer is back pressure flow control element buffer bloat to guarantee stability. Oh, it may be a mistake. The number three is a back pressure flow control element buffer bloat to guarantee stability. We plan to consolidate explicitly authorized splitting, ALDE, QuickSpace optimization, and back pressure flow control into a unified deep space proxy architecture draft. Our ultimate goal is to provide a high security performance and deployable IP transport standard for deep space networks. Thank you. My presentation is over. Thank you.

**Eric Vyncke:** Eric Vyncke, being the responsibility for- for TIPTOP. Nice presentation. Um, I must say that the transport thing is not in my cup of tea, so it's more for Zahed. So it was a bit above my head. Uh, no, just to be clear, you most probably you know that TIPTOP cannot modify transport protocol, so it's not in our charter. So interesting presentation, but it will never be adopted within TIPTOP. Now, there are other groups that may be interested, I don't know later today there is the space research group. I don't know what you are presenting there as well.

**Speaker 1:** Oh, I- I think it- it is in deep space- it's in deep space for IP, so maybe I got it wrong, sorry.

**Eric Vyncke:** No, no, no need to be sorry, right? So I- I have not lost my time, it is interesting, and nobody in the room lost their time. Uh, but if you want to work more on this and make a draft that is adopted and finally publish an RFC, you will need to find the right working group. And all what I'm saying is that TIPTOP is not the place.

**Speaker 1:** Oh, thank you.

**Eric Vyncke:** Okay. And you may want to present it as well, there is research group later today, right? Uh, Jörg. Okay, or you can- okay. So you may want to come to the mic, if you don't mind to say just this. You are the chair of the research group, right?

**Jörg Ott:** He is thinking. Sorry. Yes, I'm Jörg Ott. Um, yeah, we are running our space research group later- later this afternoon, and discussions like this would certainly be welcome- welcome and in scope of what we are looking at. No, so we are research group, so this isn't about any kind of near-term standardization, but since you're doing research, that is certainly welcome- welcome input.

**Eric Vyncke:** I mean, I'll just add to what Eric said. Yeah, this was fascinating. Thank you very much for bringing it.

**Speaker 1:** Thank you. Thank you.

**Zahed Uz Zaman:** So Padma, you wanna say something?

**Padma Pillay-Esnault:** Hey, I- I just want to say my understanding also was this was interesting to TIPTOP to understand, but it would be actually carried in sister working groups, or research groups.

**Speaker 1:** Thank you. Thank you.

**Zahed Uz Zaman:** So, yeah, I mean the the the reason that we had this talk in this working group is just to inform everybody like, okay, there are some thinking going on on the proxy-based communication and- and we have this kind of like HTTP traffic kind of thing where we already have proxy. We have for QUIC, we have MASQUE and all these things. So it's good information for us, but as you rightly pointed out, like in TIPTOP working group, we are not supposed to change anything on a existing protocol, but we can work on the architecture, we can work on the use cases on this kind of thing. So if you have some use case input or like some architectural requirement that you'd like to discuss, you're more than welcome to come here. Otherwise, if you want to change something in the QUIC, you go to QUIC working group. You want to do QUIC plus proxy kind of thing, then MASQUE working group is like the right place to go. And of course, SPACE RG is something that if you would like to get the research community or research going on before you come to IETF to do some standardization. So that would be the case. And also like, I think you maybe something that when I saw this slide I was having like, okay, um, we don't propose um an IETF RFC. We start working with an working group individually working group drafts and then go find an working group where you can actually get this adopted. Like you had this discussion about adopting the architecture draft here, so we adopt and then the working group works on it and then we actually send it to IESG to public for publication as an RFC. So yeah, I think I think, yeah, I mean we are here. Grab anybody, grab the ADs to help you on understand the process, or talk to me, or any of the chairs or anybody who knows about it and then we can help you out. But thanks for the presentation. It was interesting. And I don't see anybody coming to the mic as well. So that was the last presentation in this meeting, and I guess...

**Speaker 1:** Thank you.

**Zahed Uz Zaman:** So with that, Padma, I don't know like if you have want to say anything. Otherwise, we are done for today.

**Padma Pillay-Esnault:** Well, no, I think from my end, I think there is nothing much more. Um, I see Tony on the list. Let me let him speak first and then for closing- before closing.

**Tony Li:** Hi, just to update people- as Mark said, I've been talking to the RIRs. Um- it's been interesting. I'm talking to both ARIN and RIPE. Um- so far it's me against two continents worth of policy wonks. Um- I'm not a policy wonk, so this is having the expected outcome. Um- I would appreciate help if anybody would like to pitch in and chime in on behalf of address space for space. Um- it would be very, very helpful, especially if you work for a space agency or if you work for an ISP. Either one. Thank you.

**Warren Kumari:** Warren Kumari. Um- specifically on this, I think that what might be a nicer approach is if we ask the IANA to please set aside a block and then they can hand bits out to each RIR. I think that will- that will avoid some of the policy and similar concerns. And the document kind of implies you could do that. But I think that that would avoid some of the policy and similar concerns. I also happen to participate relatively often in both ARIN and RIPE and so I think if we have some of this discussion there... Um- I think at least some of the thing that's driving some RIRs' twitchiness is the view that one of them might end up being the space RIR. Whereas if we set aside a large IPv6 block and say, "Dear ARIN, you know, please hand this out to all the RIRs for their use," and then we still get the benefits of aggregation. Each RIR could still do, you know, some space for different bodies. Um- yes, potentially that means at the end we have five different bits that, you know, all point at one planet or similar, in which case you can just do a little bit of, like, you know, this bit- you can't quite aggregate, but you can at least still have a large block for all of space. And I think that's the important bit because that way people know this is going to need slightly different processing when sending packets. Hopefully that was coherent.

**Zahed Uz Zaman:** So Warren, stay stay there. I was going to ask you anyway this question whether we'd have coming to mic or not because you know about it. So to do that, even or like, I don't think like we need to discuss that what exactly to do. But to do that, do we need to do anything from the working group point of view or IETF point of view to start the process? I think what would that be?

**Warren Kumari:** Yes. I think what that is is we write a document saying, you know, we the IETF think it would be really good for there to be a block for space. Dear IANA, please set aside a block for space of approximately this size. And then at the same time, we can start having separate discussions with the RIRs of like, oh, and say, you know, in the IANA consideration please set aside block this size and hopefully hand them out to all the RIRs as you see fit or as needed. Um- that way we have given an instruction or request to the IANA and then we can also start talking to the IANA and RIRs to be like, "If you guys get a block, here is what you should probably do with it."

**Zahed Uz Zaman:** And the we part is the working group or the IESG?

**Warren Kumari:** I think I think the working group should write a draft, basically finish this draft and say a larger block for all the RIRs. And then the working group will drive- hopefully publish it as RFC, and the IESG can start doing discussions as well. I can also like, next time I see folks at the IANA, like, just have a little chat as well. I'm assuming people have already. Oh dear, I triggered the Eric.

**Zahed Uz Zaman:** I think people started to do the discussion, but I think I was- I was trying to get the process true so that if we need to do that, we need to start from the working group. So that's an indication for us to take on something.

**Warren Kumari:** I think the working group should do it. I think the working group should do it because it adds a lot more transparency and, you know, the IESG can also start having the discussion in the meantime if they want, so when the draft lands, they could just be like, "chug-chug-chug." But I don't think it's reasonable for the IESG to say, "Dear IANA, please set aside a massive big block for this stuff." And I understand in the grand scheme of things, it's not a massive big block, but...

**Zahed Uz Zaman:** Yeah, yeah. I agree with that approach. Yes.

**Eric Vyncke:** Just a quick point, Eric again, Eric Vyncke because I see Eric Kline on the queue later. To reply to you, Warren, um, it's typically done by the working group and approved by the IESG and directly to the IANA. There may be different scheme whether you get a- like you have proposed, a big one chunk by- by continent, let's say, uh or big one single one, doesn't really change thing. Uh, we've done it, for instance, for the SRv6 block, right? Uh, it was a /16, then approved by the IESG and IANA reserved it. The only thing is to follow up with the RIR potential future RIR or whatever.

**Zahed Uz Zaman:** Great. Thank you.

**Tony Li:** Hi, Tony Li again. Um, Warren, the draft I wrote is exactly the draft you're asking for, I think. And you're asking for content change, that's fine. Um- however, um I originally said exactly what you asked for, which is request IANA to set things, and I was taken quite politely to school and said, "That is not how things work anymore." Um- so- apparently IANA has delegated numbers to the Number Resource Organization, NRO NC. And um- so we don't get to ask IANA for this, we have to go talk to the NRO NC. Yes, I've tried to open that discussion as well and it's- it's a mess, okay? We basically have to have a multi-party discussion across RIRs and the NRO NC. And yes, we can take the technical approach you propose if that makes them happy, but it's not clear that it will.

**Zahed Uz Zaman:** Yeah, we discussed some of the things in the previous meetings and that's why I was trying to get the process out of you guys so that- because I kind of know the process, like how to do that, this things, but I think this is something that we need to discuss. I mean maybe IESG would like to help here, Eric.

**Warren Kumari:** Yeah. I mean the NRO NC I think would be involved or the NRO, ditto. But I would have still thought that it would be the IANA would say that there is a block available for the RIRs to hand out, not that the NRO or RIRs would ask the IANA, "Please, can you do this?" because... I still think it's- anyway, we'll have more of a chat. And yeah, your document almost says what I was proposing just I think it wasn't clear a block that then can then be potentially further divided. But yeah, this needs more chatting.

**Tony Li:** All I can say is I was told different and, you know, I don't know what the reality is.

**Padma Pillay-Esnault:** So, um- we'll take an action item on this, um Zahed. You and me on this one to follow up on this one on the addressing.

**Eric Kline:** I just- um wanted to register a contrary point of view. I don't think we should be aggregating- um- requesting an aggregate for space just yet. I think um- from the perspective of somebody on Earth, everything not on Earth might look like a useful aggregate, but from the perspective of things that are in space, everything not Earth is still too big to be like just one aggregate. So I'm not sure that there's value there yet. And I also think if we go down this road, we're going to end up with a lot of code that says, "If prefix starts with foo, then do the space thing." Um- and I think that's probably going to get pretty bad in the long run. So... Just...

**Tony Li:** If- if you look at the draft, the prefix is- it's a prefix per celestial body, not all of space. Um- the address space block for all of space is just for allocation ease and- and not meant to aggregate that way. Um- there's a lot of space between celestial bodies, though.

**Eric Kline:** Well, so we can talk about what those- what those aggregates should be. I mean, that's the point of the draft is to spark that discussion. Um- there is nothing special cased about this address space. Uh- certainly I- I abhor all special cased address space. Um- this is just an allocation so we do get aggregation. Nothing more.

**Tony Li:** Um- I- I've the observation that it- it will result in a lot of specification inevitably. Like, I- I know it- it's- that the document may not call for that, but I think that's just where we're going to be in the end. If- if we don't have another mechanism to learn from the network- um- something about connectivity properties.

**Padma Pillay-Esnault:** Hi. Um- this is Padma, co-chair. Um- Tony, would it be something maybe possible to have just a range for experimental for now? And rather than go, you know, having something completely um- uh- say written in stone. So- I- I'm just wondering whether there is a way of just having an experimental range.

**Tony Li:** Uh- we can certainly experiment if you're willing to fund the expedition to go re-number things that have been deployed. Um- I've been told that's rather hard. Right now, we have an advantage is that we don't have the scale where this is going to be a problem yet. Um- that's why I'm trying to find a middle way. But um- you know, I'm- that's just my two cents. But...

**Padma Pillay-Esnault:** No, we've got agencies launching missions every day. Artemis is about to go up. Um- you know, the- this is an ongoing problem and it's started already.

**Zahed Uz Zaman:** Okay. So- so we can discuss this after. Yeah, I think you guys can discuss this offline perhaps. I think- I think the action point for the working group is to like really start to think about this documentation. Then we can have these discussion while we are creating this document. Um- right now we don't have any milestone or anything like that to adopt such a document. Um- woman then basically uh as a AD point of view do you have any concern if we- the working group wants to start working on that from the chartering point of view?

**Eric Vyncke:** So Eric Vyncke again. So obviously I think we need to talk- to work on this, right, point taken. And um- I would say writing the requirement for this is the first one, right? Getting the size and the details can be sorted later. It kinds of enter the charter in the sense of is it part of the architecture, and addressing is part of the architecture for me. So for me it fits the charter. Okay. Okay. Um- now if later in the process people say no, then we can still re-charter because I think it's a really important problem to be solved. Right.

**Zahed Uz Zaman:** Right. This is- this is something that we need to take care of and we can take care of like as you said like you mentioned two things, one is the requirement, one is architecture. So we can- we can actually formulate this part of the requirement and architecture and actually start working on it. Correct. Tony already has a document. I think that's- that could be a good start too. So Tony, will you be able to like- the com- like take all the discussions now and try to put it in something? Okay, I see Tony is nodding. So let's- let's try to go and perhaps in Vienna we can discuss it more about this in the next meeting, on Jia. But I think it's also important to keep this separate from the architecture document because architecture document is well progressed, right? This part is still beginning. So don't slow down the architecture document. Like keep the two documents separate.

**Tony Li:** Okay, with a pointer, right?

**Zahed Uz Zaman:** Yeah, I mean the the architecture will not be going for the details of it, but should mention it and then this document can take care of the rest of the things.

**Tony Li:** Yeah, we already took it out of the architecture document for exactly that reason.

**Zahed Uz Zaman:** Yeah, exactly. Okay. Thanks for the discussion. It was really good and useful. Um- Padma, you want to say something?

**Padma Pillay-Esnault:** No, I'm good. Um- thank you everyone for being here. I think it was interesting meeting. Thanks.

**Zahed Uz Zaman:** Okay. With that, see you in Vienna. Thanks for today. Meeting adjourned. Bye bye. Bye.