RIPE 93.
Main hall.
Friday 30th October 2026.
9.30am. Plenary
AMEDEO BECK PECCOZ: So. Hello everybody. Good morning. Before we start off with our first session, I have to two small announcements to make, the first one, it's Friday!
(APPLAUSE.)
And the second one we are going to have now first sessions, the first one is a full session, half an hour and three lightning talks, after lightning talks and before you rush why are your coffee, we are going to have the results from the elections. Please hold on a few seconds. Now, I call on the stage Eric please. The stage is yours, thank you.
ERIC ANDREI BALEANU: Thank you very much. Good morning, I am Eric Baleanu from Interlan Internet Exchange, an internet exchange in Romania and today, this morning, I will tell you our story, how we started from local area networks to distributed internet exchange platform.
So in late 1990s and early 2000s many networks in Romania were built by users themselves, people were connecting computers between apartments and buildings and we have only computers, we did not have routers at the time or mobile phones, so we connected our computers in order to have access to local chats, gaming, play together and to share files, music and movies.
At that time we were not, these networks were not used for internet access but they were simply local communities building their own networks to in order to communicate and to exchange their content.
Internet access was limited and very expensive. We had only some dial‑up connections, some very old telephone lines and of course they were very bad and typically the permanent connections were available only to companies and they were very expensive. So in this context the users who built these legal networks started to share some permanent connections over their local networks and also in this way this permanent connections were distributed among tens or even hundreds of users.
So these networks became platforms for internet access so not for just for the local communication as they were built in the first place.
During the time these networks grew so many of them became small internet service providers and we realised that most of our traffic could be exchanged directly instead of going through our upstream providers, maybe outside Romania who we needed to have high speed connections in order to exchange the content. So we began to connect the networks to each other.
These early interconnections were informal and built on practical needs, not on a formal design. And actually we started to build an internet exchange without knowing what an internet exchange is at that time.
So how we started:
In the early 2000s, around 20 operators in Bucharest decided to meet and to establish how to interconnect in a more organised way. We met ‑‑ this is a picture from one of our first meetings in Bucharest, we had a map on the table and we started to find solutions for interconnections and this initiative became InterLAN, the name comes from interconnecting local area networks, which is reflecting exactly how we started.
At that time we had very small understanding of how internet exchanges should operate so the system has evolved step by step based on our experience.
(Can I get some water please. Thank you).
So between 2002 and 2006, the number of internet service providers grew reaching more than 1,000. And many of these operators were very small across Romania, regional or local and they usually were originating from the same community built infrastructures. So this created a very dynamic market and very fragmented with many, many independent local players.
As you can see this is some of the data from the Romanian national regulator. So the peak was in 2006 when we had more than 1,400 internet service providers in Romania. But today the number of internet service providers is less than 300 so the market is highly concentrated. The first three top operators in Romania, they control approximately 99% of the internet connections.
So now we have a very concentrated market.
So this shift changed the role and position of smaller operators and forced us to better understand how interconnection should work.
So let's go back to the early stages and when we started to understand how an IX would operate, so we built an exchange based on our needs on the practical needs and the association was the InterLAN association was founded in 2005 in Bucharest with around 20 members and later in 2008, we joined EURO‑IX association, EURO‑IX is on organisation of European internet exchanges but it also have members from around the world.
So we joined Euro‑IX and started to learn how to build and how to run an internet exchange platform and later we started to attend RIPE meetings and other community events and we became connected to, more connected to the broader internet community.
My first RIPE meeting I think it was RIPE 78 in Amsterdam in 2008, if I remember correctly.
So what's our model?
InterLAN association is an association of network operators, only local and small operators can become members and they can access the internet exchange platform based on their membership.
Larger operators cannot become members but they can connect to the internet exchange platform based on commercial agreements.
So we started to expand beyond Bucharest because we started in Bucharest and many of the players and the local operators were there. So more operators outside Bucharest started to join our internet exchange platform, both members and non‑members, so this made it clear for us that not all networks could be physically present in the capital. Because some of them were very far away.
So for these operators who were not close to Bucharest, we had to have a different approach.
Romania is the biggest country in south eastern Europe, its size is the same as United Kingdom so we had some geographic constraints because our major cities are spread across long distances, many cases there are hundreds of kilometres between the cities and we have also the Carpathian Mountains, so for the operators outside Bucharest to participate in the main interconnection system required to build long distance connections.
Operators from outside Bucharest had limited options, they could either build their own connections to the capital for hundreds of kilometres or to rely on their upstream providers to access the internet exchange platform in Bucharest, in the capital city.
So both options were expensive and they reduced the benefits of interconnection.
So we started to think about building regional exchange points but in practice this was not a strong option because in many places there were just a few operators and the traffic was too small to justify a separate internet exchange for just three or four players.
So instead of building small local exchanges, we chose to extend the internet exchange platform and so we created additional point of presence in other cities so we could allow operators to connect locally while they remain part of the same peering VLAN on the same exchange platform.
So the goal was to provide access to the existing ecosystem, not to fragment it.
We operate distributed exchange layer 2 platform across multiple points of presence in Romania, as you can see we have now nine points of presence across Romania and we have a maximum number of five participants in each of these points of presence.
So participants can connect locally and establish peering with networks at other locations to the same exchange platform.
The results was, where the growth and regional reach over time, this approach allowed the internet exchange to expand beyond its initial presence in Bucharest and today we have more than 150 networks connected: Internet service provider, content delivery networks and the participants are not only from Romania but also from our neighbouring countries, Moldova, Bulgaria, Hungary, Serbia and Ukraine.
We started to think, to extend the outside the Romania borders, so we built two points of presence outside Romania, one is in Frankfurt and the other one is in Sofia. So Frankfurt was built I think ten years ago or more maybe in Equinix FR 5 we have a point of presence. It provides a connection point for international content delivery networks so this extended InterLAN into one of the major, Europe's major interconnection hubs here in south eastern Europe. So this content delivery networks who has not presence in Romania, they can reach the Romanian and regional operators to the same internet exchange platform without the need to deploy infrastructure in Bucharest and also for smaller operators connected in the regional pops across Romania, this creates access to additional international peering opportunities through the same distributed exchange.
Sofia, we open the pop ‑‑ the point of presence in Sofia last year was opened in Telepoint, so we could provide a connection point for content delivery networks but also for operators in south eastern Europe so Sofia's strengthens the regional interconnection between Romania and Bulgaria networks and also for other south eastern European networks through the same distributed platform.
And Sofia also serves as the secondary point of interconnection for international CDNs complimenting Frankfurt, I have to say that if you connect in Bucharest, Frankfurt or Sofia, you have the same conditions so the same prices for the ports.
Extending shared layer 2 peering platform across these cities, across the cities across Romania. So this introduces additional transport and operational complexity because for the internlink, for the inter‑POP links, we must provide enough capacity for traffic and also redundancy is essential to minimise the impact of transport failures so we have to ensure that we have enough capacity and resilience for this point of presence so we have a lot of costs with this but this expansion improves access to peering and of course it doesn't reduce automatically the latency and both depend on network toplogy and operational design.
What was the impact.
The goal was to support smaller operators, so this platform helps smaller and regional operators to remain part of the same interconnection system. And also, it lowers the barrier to participation and allows more networks to exchange traffic directly.
At the same time, having internet exchange platform with many local players, this is interesting for the content delivery networks, who can access all the local players in Romania and not only in Bucharest but also in the other cities around the country, across the country.
So what was the effect.
This model allows a large number of smaller networks to remain active on the market, so we wanted to help the small local operators. The exchange is owned by the association as I told you before and the association wants to protect their members and to help them in their daily business, so in the same time this distributed exchange platform in Romania created the relevant interconnection system for larger operators, for transit operators and for content delivering networks. And this combination increases the overall value of our internet exchange platform.
What are the lessons we learned from this: The internet exchange model was shaped by the specific conditions of the Romanian market, so how we started with the local players, long distances between the cities, the interconnection in Bucharest, the main point of interconnection of Romania, so it reflects a large country with big distances and strong concentration of interconnection in the capital. And in this context, extending one single exchange proved more effective than building multiple smaller ones. And in summary InterLAN started as a group of local networks solving practical problems. And this interconnection platform emerged later as the structured form of that community. And its distributed infrastructure architecture was not the result of a single design decision but of continuous adaptation to the way the network evolved.
That was my presentation. Thank you very much.
(APPLAUSE.)
AMEDEO BECK PECCOZ: So do we have any questions in the room? Yes, please.
AUDIENCE SPEAKER: Marco. Marco d'Itri: Is there some way to arrange for the cost sharing of the geographical links or is just everybody pays one quote for, same quote for everybody?
ERIC ANDREI BALEANU: Yes, the conditions are the same so if you connect in Bucharest or in a different city or in Frankfurt or Sofia, you have the same conditions, you have the same prices, because we wanted to build an interconnection ecosystem which should be equal for everybody so everybody can access in the same conditions.
AUDIENCE SPEAKER: Martin Pels, RIPE NCC: On your route server do you offer options to not exchanged routes with the locations that are outside of Romania?
ERIC ANDREI BALEANU: Yes, we have, I am asking my colleague to come to the mic, Andre, can you explain better than me? Yes, the answer is yes but my colleague can provide further details.
AUDIENCE SPEAKER: Andrei from InterLAN. Yes, we have a lunch of communities and you can control traffic as like outside Bucharest, outside Romania, CDNs stuff like that so we group peers based on location ROAs.
AMEDEO BECK PECCOZ: OK, I see no more questions so thank you so much, Eric.
(APPLAUSE.)
And what we are going to speak about DNS, DNSSEC, Robert, please.
AUDIENCE SPEAKER:
JOAO DAMAS: This is a quick talk about observations during the roll of the KSK, the NSsec key further route which rolled recently on October 11th.
So who are we, APNIC labs you have seen several talks here usually it's Geoff presenting rather than me, together the both of us make APNIC labs. There is the url for all our measurements if you want.
This is the DNSSEC validation how it looks globally, some, this is a variety of levels of the option. Since 2014 it has been growing steady, it sits at around 40% these days, 40% of the user population.
And this is the KSK roll I was talking on October 11, UTC, the key in the root zone was rolled to a new key which had been announced for more than a year, there's a single mechanism up there to track the introduction and exit the keys in the root zone, normally you just install the software and don't have to worry about it but normally is a strange word for the internet.
So anyway. The date was approaching, we asked ourselves can we measure any of these before and after, there are two signalling mechanisms that have been standardised, initially the one described on RFC 8145 which had its own issues, it didn't quite work, the first time around. So three of us, Geoff war risk and myself wrote 8509 which is introduced a mechanism called the KSK caught nerve fail.
Brian from Verisign was obtaining at the route serves using the first signalling mechanism, but we decided to use the second one has it has an evolution of the initial mechanism.
This is how many of the users were behind resolvers that reported the signal on KSK Sentinel, so there was a gap there in the summer but it doesn't matter, the actual level of support by resolvers is sitting at around 40% of the internet users which is quite OK.
As these things go.
This is a plot of the DNSSEC validation rate through the days around the roll. The Y acquisition is zoomed, the variation is not as big as it might seem from the graph. What you get from as a first impression is that there wasn't a big change which is good I guess.
But if you look, start looking in details, you see more. Before the roll, we had about 14,000 networks that were giving a signal that corresponding to not really trusting the new key as the traits approached. Those networks translated into a few million users. So we decided perhaps we it wouldn't be a bad thing to go and reach out and to on some mails to either the affected networks or people who we thought could reach them so that's what we did.
We assembled this list of 50 networks that we saw would be at risk and had significant numbers of users and sent out mails. Some people reacted and some did not. In these kind of success case where they actually reacted before, the day where the key was rolled and you will see more results about this and Brazil was one where things started failing and they decided to shut it off.
Not the whole country of course but some networks.
So this is a graph of, for each of these 50 networks that were on the table I showed a moment ago, which ones took action. You can see it looks like a messy graph but I can see the band in the middle which is people who did nothing, which is kind of the expected human behaviour, if you haven't been paying attention for the last few years, why would you the day before but there is hope. Like starting on the 8th, you see lines that go from the very bottom to the very top. These are people who actually got, we got in touch with and reacted and fixed things before. So it might seem that trying to reach out to operators is an affair that is desperate and will not have an impact but it actually does. Of course there are things that, there are networks that don't reacted on the 13th, which is basically when the cache expired, two days after in the ROA but most of them actually did react two or three days before which is good to see.
So at the end of the roll, what we saw, we saw 842 networks that were still not trusting the new key, well good luck to them.
And these are represented by 3 million users in the grand scheme of things is not a lot.
Apart from whether they trusted the network or not, we observed some shifts on the number of people that started sitting behind the DNSSEC validators, people who as a side effect of this actually turned on validation and the champions here are clearly India which added some 45 million people additionally that now sit behind validating resolvers which I guess is good and there are a bunch of other countries as you see there. On the no so bright side of things, as we saw in the previous graph, Brazil dropped a few networks, hopefully Nick Brazil will reach out to them and get things figured.
Since we are in Bulgaria, we looked at Bulgaria itself. And we were surprised because there was a significant drop. When you looked at things closer, turns out there was one ISP I don't know if there's anyone in the room here that works for tell nor BG, perhaps when you go backs to the office, you could... it was an example of an ISP doing all the right things sitting at 100% dance validation forever that went back down to zero. So if you could have a look, that would probably be appreciated by the internet and the users. That sit behind your service.
Is there room for improvement? Certainly, one thing we observed earlier after the roll is that the signal provided by the Sentinel mechanism kind of falls into the... right after the transition so perhaps it's time to do a plus plus of the RFC, look how it behaved and what the signal and how it can be improved but overall I think the mechanism does provide a good signal with a certain coverage which depends on the software support for the deployed software. It's clear and more trustworthy than the previous available mechanism and overall I think there is hope and normally some days you wake up and you go to work on internet infrastructure things and you have this sense that nothing you do really matters but then you come across things like this where you actually reach out to people and they react and they fix things.
So kind of a bit of a back tap to yourself and a good sense of there is still a good internet operator community out there.
And basically we keep working on this, supposedly the next key roll won't take as long as the last one did, it's scheduled for three years time and it will involve an algorithm roll as well, it's a bit more complex, we'll have to see and that's it from me and in case you want to see where the old KSK is, there is a manhole in the ground in Amsterdam where they store these things.
(APPLAUSE.)
PAULIUS JUDICUS: Any questions in the room?
AUDIENCE SPEAKER: Wolfgang Tremmel: Did you have any idea what what happens in the German health care system, it failed in the key rollover, the German health care system, it failed completely.
JAOA LUIS SILVA DAMAS: I don't, because I didn't look for that specifically because the graphs are available now if you go to Germany and then you go to the AS of that network, you will be able to see it there.
AUDIENCE SPEAKER: Hello, Sergei Masojedov: As far as I get from your slides that you have been reaching the operators who showed not enough validation with a correct key. Could you give some more specifics how those operators were reached out.
JAOA LUIS SILVA DAMAS: Email, email either directly to the operator if we had that or to the local community like for instance with the Czech Republic the mail we sent was picked up by Ondrej Philip and he actually ‑‑
AUDIENCE SPEAKER: So not on BoF of IANA or.
JAOA LUIS SILVA DAMAS: No, no and that's something that I would encourage IANA to do next time. Sure, they did their part correctly but I think it's worthwhile spending a bit of an effort because people will actually notice. So it wasn't IANA, it was ourselves.
AUDIENCE SPEAKER: Great, thanks.
AUDIENCE SPEAKER: David Lawrence: Could you comment more than the anticipated increasing frequency of KSK rolls, you know, what you expect from operational experience, maybe a bit more what you would hope out of IANA as far as reaching people and so on?
JAOA LUIS SILVA DAMAS: I think rolling keys is frequently a good thing in general because if you do things seldomly, you lose practice, the chance that perhaps that the person in charge at the time of the last roll is still the same person next time if ten years have gone by is small so that increases the chance forever, having experience not only documentation which of course you need but having the experience, the people who went through the pain last time around is always a positive thing so I am all for frequent rolls.
PAULIUS JUDICUS: I know no online questions. Thank you, Jaoa. Next up on stage we have James who will present his objections of borderless internet.
JAMES COWIE: OK. I am Jim Cowie from the internet history initialive and I am also a fellow at the Berkman Klein centre at Harvard, they have nothing to do with this.
This is a project that Emile and I took a look at about a week ago, about a month ago rather. It's I, call this a simple question, it really doesn't have a simple answer, even though it seems like it should.
So here's the this will be a quick lightning talk to just to get the idea out there, I think it could be evolve into something larger later. But the thing that we were looking at was geography and it's not to say geolocation, it's not a talk about that. This is an observation that geography is encoded in a couple of different ways in the registry and through that in how we look at routing, but the connections are often very hard to make.
So here's the observation that we made, there's very little ground truth in the NRO stats file about where things there. There is some certainty, right. One of the things is that ever since I guess it was codified in December 2020 in NWI 10, this community asked the NCC to copy the country code of the registrant into the record when they made an allocation and that's supposed to be the legal seat, not the operational seat, not where you do business, it's not where you route, it's where the entity lives, its legal jurisdiction.
This kind of codified existing RIR practice worldwide, when you look at the stats file and you can take any prefix that you might see on a routing table and get a best match and find out at least what country it is legally allocated in originally. And on last transfer.
You can do the same thing if you go to the origination country of the AS. So the origination country here is well we looked in RIS, we saw this prefix IPv4 or V6, who originated it, go and look in the same file, find out, what country code is there for the AS.
Should those be the same. There's absolutely no reason they should be the same. We have pointed this out over and over, these country codes are a terrible place to start if you want to do geolocation because legal home and operational home have no reason to be the same on the internet.
None at all. Nonetheless, they do kind of align much of the time, if you take a look at them, about 88% of the time they will be the same.
But you know that's not 100%. So this is the simple question. What's the difference?
And it doesn't have a simple answer. So concrete example, I think I just described this to you again here's a /16, you go off, you look RR C21 and you find out it's been originated by 12 4‑79, you look. It's French French when it was born and Spanish when it's operating and they are not the same. But that's not surprising, right.
So the question was what's the sort of most compact model we could make that would explain most of the difference in a reasonable way.
So this 11.9% residual would be what's left over if you want to get beyond the null model which probably is operated where it was born. So we built some models, when I looked at this and emeal and I were chewing on this a little bit, it looks like something we have seen before, it looks like trade models, when economists talk about trade between countries, they will build elaborate gravity models to try to figure out what causes two countries to trade with each other at a certain volume.
And it will be in part dependent on who they are, right, big exporting countries tend to export to everybody. And then there will also be some die add digital effects, these two particular countries have some special relationships that causes them to send sneakers and foot balls and things to each other.
And so we wanted to apply the same thing here.
Throw all these variables in for the countries themselves and for the country relations and we ran something like an economist gravity model to trying to try to figure out what would the flows look like if the disagreement between legal home and operational home were explained by some of these variables.
We used distance obviously as you would if you were modelling trade because it's kind of an export relationship. We said maybe they have a land border, maybe they have the same RIR which basically means they are the same continent, obviously not orthogonal, you want to find out which are most important.
So sure enough, as you might expect if you are close neighbours there's a higher likelihood that you will have space allocated in one place and used in the other place. And being sibling territories, so two offshore possessions of the same former colony for example or colonial power, is pretty strong. Same RIR, shared border, one or the other being the former colonial home or vice versa has an effect. And as you you'd expect, distance has an inverse effect, the further you get away, the less likely it is that allocated space will show up in the other place.
So that was cool. But it doesn't explain enough of it because when you look at it, if you just assume that was the case, there's still a lot of cases that are stronger than they should be under that corrected model. So for example there's an awful lot of stuff that has its legal home in the Seychelles with an LIR there and it's routed in Hong Kong.
Or Singapore stuff that shows up in China or old US space that shows up in Romania. And you are chuckling because we all know what this is, right, there are things going on here in the real world that have nothing to do with what's observable in internet measurement.
And so, could we make another model?
All right, but we kind of know. So let's go ahead and build the next model. And figure out maybe there are single country variables, maybe there's something about the specific countries that makes them be either a hub for hosting, there's a lot of other people's address space showing up in my country or the opposite, that I have a lot of LIRs registering space that doesn't end up running in my country. So we took a look. Threw in a whole pile of single country variables and we got creative and started looking at things like there's a variety of democracy index that classifies every government on earth in terms of its place on the spectrum from liberal democracy to autocracy, maybe that has a bearing on it, maybe it's that you have been subject to US sanctions. Maybe it's that you have an NIR, maybe as simple as GDP or the count of RIPE members that you have in the region.
Any number of these things it could be.
So here's what fell out. So ultimately there are about six mechanisms that if you accept these would be sufficient to kind of describe most of what's going on here. With just a few remaining exceptions. The biggest one of course is just the one that we started with, the null hypothesis that things should be operated where they get registered.
But if you worked that down, here we have the six categories, these are constructed categories, part of the reason of doing this is as a lightning talk, I would rather dodo it as a more extended talk later with community feedback. Number 6 is the big one, the 88%, the countries that announce at least 95% of their own space.
You don't ever see things that are legally hosted there offshore. The other ones are things you are thinking about, right, about 7% is category S1, there is an address market, cloud and hosting infrastructure offshore and US great Britain, Netherlands, Germany, Hong Kong, Singapore are places where lots of diverse address space naturally goes to operate operate. Number two is registration seat only, a lot of countries tend to be places where companies get formed easily and address space tends to start its life there and then goes somewhere else to actually run.
And there's also and with the internet history prong, there is a fingerprint here in the record of the period where you could get a 22 if you were a new LIR during the pre‑exhaustion run out. In the interests of time, I will move on. There are regional effects here, one carrier who serves a group of countries, they will have their LIR in one place and they will be using an AS from the other country to route, these are well understood.
Briefly in this sphere of things you can see kind of regional ways that this works out and I encourage you to go to the slides after. So what's the basic take away. There's nothing in error here, everything here is done correctly legally, it's not even in violation of norms, this is how the internet is supposed to work, the idea of countries on the internet is in some sense a bit bogus. There is no specific reason that you would want to use this for geolocation, no reason to expect the legal registry in the country of use to agree. But it is kind of cool that when you dig in and try to group them into groups and figure out what the primary patterns are, you can see things coming from the real world in this system, you can see aspects of the political economy affecting how people move address space around and use it in the real world, it's a hidden geography of the internet.
So thank you very much, I will stop.
(APPLAUSE.)
PAULIUS JUDICUS: Any questions at the mic? Online? No. Thank you, James.
(APPLAUSE.)
The last lightning talk on stage in the session, please applause for Jen and she's going to tell us about the importance of IETF.
JEN LINKOVA: Good morning. Yeah, I know people probably are tired to hear about IETF this week. I promise this is the last time you hear from me until the next RIPE. Raise your hand if you did go to the BoF on Monday. OK, plenty of people did not.
OK. Let's start. OK just to wake you up, raise your hand if you operate a network configure protocol troubleshoot them? No? What do you do guys? OK, anyway. Even if you don't do that, probably you sometimes wonder why, why BGP is so complicated, why it was designed that way, could they have done something much more reasonable, the question is who are they. Surprise, surprise, protocols are not given to us by some supreme beings, set in stone. And I am actually saying that because I have, I am on the number of like telegram chats like for network operators and sometimes I see oh why did Cisco design IXP that way, I want to do something completely different. So actually I am going to tell you that those protocols I thought you operate and configuring actually designed and developed by IETF, and I tend to have good intentions, and I think people should do this, and the goal is to make the internet better. And everyone could participate and make the internet better to very definitions of better firstly and I just like to remind you, we said it on Monday and I would like to repeat it again, anyone could participate, there's no like official membership, there is no such thing as a member of IETF, you signed up to the mailing list, you acknowledg the note well, you come to the meeting if you could, and voila, you an actually an IETF participant. So why I am actually here is because I am speaking from experience.
I have been doing this travelling for ten years and I managed to publish a number of documents, yes I tend to focus on IPv6 but there are other fun things going on.
So we have been talking on Monday and actually a few previous RIPE meetings about why don't operator coming to IETF with many interesting things going on, let me try a different perspective and tell you a few stories how I had a problem and managed to get it solved there because sometimes yes it's not just a bunch of strange people having their heads in the cloud, sometimes you can have a problem and come here and get it solved.
So, to summarise, just to give you, yeah, one slide to take out of this. There are a few reasons you might want, you might have to participate. First of all you might have a completely different perspective from the other people in the given working group, I remember my first IETF in 2013 I was a very excited and very scared at the same time to see so many smart people around me in the room but I walked into one of the working groups just in time to see a discussion about people talking about deprecating something I had been using almost every day and said whoah, hold on, you are going to break my stuff and people said such an interesting use case, we did not think about. So your use case might be completely different from someone else so you might want to share how you use those protocols.
And indeed, IETF is one of the places where industry best practices are defined, so if you have opinions on what is best, you might want to say something and if you don't, why do you complain later.
And what I'm going to actually focus on in the remaining five minutes and 55 seconds is you might have a problem to solve. So, 2019 I migrated our guest wi‑fi network in our offices to V6 only and my manager came saying look, look, seven seconds it takes for my phone to connect to wi‑fi, completely unacceptable. And he wasn't the only unhappy person. So I, and a few other people spent sometime troubleshooting and we realised the root cause is a kind of a design flaw in the neighbour discovery state machine, that use case we received was not actually accounted for in the neighbouring discovery. So a few months later I went to another IETF meeting, I suggested a draft which was adopted, and Android and a view vendors actually implemented what was proposed, and two years later, not because IETF was slow but because I was slow in this particular case, we got a document published which apparently people are implementing and Android implementation was done much faster and as a result my manager stopped seeing seven seconds delay and he was very happy and other users were harp, the question is why did I go to IETF, I probably could have just talked to Android people and I could have go to our people in the vendors and ask them to implement this for me. However my proposal was to slightly change the neighbouring discovery state machine and it was very very helpful to have extended review from industry experts on are those changes actually safe because sometimes I could do something which helps me but breaks other scenarios which again I might not be aware of. Also I actually as some people might have noticed would like other people to deploy the V6 only and V6 mostly stuff and I want to make sure their network as well, by doing this without a document that over people could refer and to make sure the network support is.
Again another V6 related stuff, we did this pilot and realised it did not work as well as I wanted it to because it's really hard to have two networks V6 only and a full back one, I wanted to have a single network when I could just have V6 only clients, dual stack clients and V4 only clients together. So again a few months later I talked to smart people in IETF hallways, run my idea by them and they are like oh, that might actually work so on my basically in the airport on the way back, I wrote a document. I got a call first and actually 14 months later and four months of them I was doing some other stuff so I didn't pay attention, we got an RFC and IANA code and everything and even implementations in Android and quite soon after that in Apple and actually, the first deployment of this was not even us, it was RIPE people deploying it ‑‑ thank you Ondrej ‑‑ deploying it and RIPE meeting in October '22. So next year it will be five years of this first deployment of the V6 mostly. Again I could go to my vendors and say "please do this", "yes" but first of all, I had calls from different perspective and host developer, DHCP server developer and so on and again it was a document which people could read and implement and some implementations I wasn't even aware of, someone relative saying oh great idea, cool, basically it allows us to have a kind of industry wide impart by proposing something other people can do and IETF is a nice place to do this.
So, what could you do, why I am here. The next one is in a couple of weeks. San Francisco I know probably not the dream travel destination now but you don't need to be there in person, there is remote participation, some sessions even run in the morning so people from Europe could enjoy it. And again as I say, there is a lot of work has been in emailing list so you don't even be here and it hasn't been fully confirmed yet, what we are going to do next time, we'd like to give you a first dose of IETF for free so the plan is to organise an interim meeting for the V60 operating group, please pay attention for the RIPE 94, it's just in the middle between two IETFs, the previous one will be in March in Kuala Lumpur and next one in July in Berlin, having an interim just in the middle which is very helpful. We already have some ideas of agenda, please pay attention to V6 ops, and if you have any other ideas what we can do, I would like to hear and I have 17 seconds to spare.
(APPLAUSE.)
Questions? Comments, suggestions? You know where to find me, right?
AUDIENCE SPEAKER: Jen, thank you very much for your work at IETF because I have seen it in my troubleshooting of meeting New York mostly, every time there's ICP related issue, there's already a draft written by Jen.
JEN LINKOVA: It's all my fault, yes I know, thank you.
(APPLAUSE.) No?
PAULIUS JUDICUS: Any other questions, online? Jen, before we move on to General Meeting results, you would like to remind all of you attending live or listen to the sessions online, to go to the agenda page and rate the talks, your feedback is very valuable for our Programme Committee, we value this a lot and now Ondrej Philip will present General Meeting results for all of us.