RIPE NCC Services Transcript

RIPE 92

Main hall

20 May 2026

RIPE NCC Services

2 p.m.

.

ROB EVANS: Hello. Good afternoon. Welcome to your favourite Working Group, the RIPE NCC Services. My name is Rob Evans and I am one of the co‑chairs of the group, along with Janos and Stefan who are in the front here. And we shall be shepherding you through the next 93 minutes.

I have got a few announcements to make.

There is no official social event tonight, so you can explore the city or join the Board games BoF that's happening at 6:30 in the other room.

The venue closes at 9, so that will have to finish promptly.

The RIPE NCC General Meeting will be held at four o'clock today. I'll mention that later on. You need to have registered and picked up the distinguishing for your badge. I saw that the registration is until four o'clock today because there is an issue with logging onto the GM website earlier. But if you are on site, you must have registered and you must pick up your sticker for your badge to get into the General Meeting.

So, inspired by Sascha's talk on Monday I thought I'd try and hack a little bit of our agenda into something or other. Maybe a traceroute. I got it working a little bit. I think I have left the marquee tag in. So, this is the agenda for today.

After I have finished withering on, we'll have Hans Petter talking about the RIPE NCC strategy from 2027 to 2031 and he will then go straight on to talking about the NCC's technical infrastructure. After that, we have Hisham talking about the, a phrase I thought I'd never be on stage talking about again and that's ENUM. Then Gabor is going to talk about multiple LIRs and PI and legacy.

Before we get started I should of course acknowledge Mary who is doing the steno today, thank you very much. And we also have notes being taken and we'll be keeping and eye on the chat.

I will just ask we have quite a lot of stuff to get through, I have already asked the speakers to make sure that they are aware of the time. There is a clock on the stage here. We need to finish promptly so that the room can be cleared ready for the General Meeting that needs to start at four o'clock. So as well as the speakers doing their bit, I ask that if you are asking questions to the speakers, please make sure that you state your name and affiliation and then ask your question concisely to allow an answer for others, and to allow others to ask their questions. There is always the mailing list and speakers are likely to be around for one‑on‑one, and Athina, I was not expecting a question on the agenda.

ATHINA FRAGKOULI: I am the Chief Legal Officer of the RIPE NCC. Just a clarification, the GM indeed starts at four, the registration remains open until three o'clock.

ROB EVANS: My apologies, thanks for clarifying that. In which case I shall get off the stage and I shall ask Hans Petter to take the stage.

HANS PETTER HOLEN: So, thank you very much. And it's been an exciting lunch because some of you have noticed the access.ripe.net has had some problems. I have been told they are fixed now and we have extended the registration deadline before the meeting, all that has been announced and in due course we will publish a report on what happened. But right now the issue has been mitigated and engineers are busy doing route course analysis but the most important right now is to continue and run this meeting.

So, I'm here and as Mirjam said in the opening in 1998 I was appointed Chair of the LIR Working Group, that's later split into Address Policy, which I continued to Chair, and then Services Working Group, your favourite Working Group. And now I am here as Managing Director of the RIPE NCC to present you the next five year strategy for the RIPE NCC.

The first significant strategy document was produced five years ago, and before that there was some strategy work with the Board but this is really our second or our third maybe strategic document that we are publishing now.

So, we published a draft before RIPE 91. We received good input and we have discussed this internally and with the Board. We have also gone one level down in the organisation to look at the service level objectives, that's not going to be part of the strategic document as such but will form the basis for the activity plans for the coming year. So we will continue to work on that after the Board approves the strategy in June and then present more elaborately in the autumn meeting on how we see the next activity plans fitting into this strategy.

And then, feel free to give feedback on the mailing lists or the directly to strategy@ripe.net after this meeting. Don't wait too long because the Board meeting is in a month's time, we then have to write it up and get the Board to sign off on this.

So, taking a step back from the RIPE NCC alone, thinking about, you know, why are we here and what are we doing? The Internet as such is built on some core and underlying principles for the operation. One side is open standards, there was a BoF here on Monday with IETF and how we collaborate with that. And this ensures that devices could communicate seamlessly across networks with different underlying technologies worldwide to guarantee interoperability. I started my career before the Internet was in here and it was really interesting to send e‑mail from Norway to University of York and backwards because you basically had to know which machines to send it through. The Internet has taken away all that abstract on all levels.

.

Then for this to work we need to register global Internet identifiers, names, numbers and ports, and coordinate this openly without commercial control to guarantee global uniqueness. These numbers there, are there to make the network work, Not to be property, right. They are a technical parameter in the protocols which we need, we, together, need to make sure are used in the appropriate way.

So, our enduring responsibilities as a Regional Internet Registry, we support these core principles by guaranteeing uniqueness. You register something and we guarantee you that we will not register the same to somebody else. We provide responsible stewardship. We want to be a source of authoritative data. And we engage members and we need to renew the community.

When I was here in 1998 I was one of the young guys, I am not quite any more, I had some grey hair back then but I can't really hide it anymore, but it's really important that we, you know, are here also in 25 years' time. But then with a renewed community.

So, the RIPE NCC's responsibilities is supporting scaleability, allocating, registering, promoting the adoption of IPv6, vastly expanding the available address space as demand grows. We need to strength the resilience by allocating and registering autonomous system numbers so that each and one of you and your customers to the extent they need to be able to have their own routing policies. Enabling redundancy through multihoming, peering and robust interconnection. This resilience is further reinforced by operating K‑root, one of the 13 route server letters. One the Internet routes DNS services.

So I usually say we don't do names but that's not quite true, we do a tiny bit of names in the route server services.

Enhance routing security by operating RPKI, and you'll hear more about that development there in the Routing Working Group.

So that you can sign your routing announcement, the statements of which AS will, can announce your address space, and also now with ASPA, signing which AS paths you allow to be used to reach you.

Improve transparency and operations through measurement and data services that provide insight into Internet performance.

I had a meeting with one of our members earlier this week and I said that you have this data that described the root cause of this incident in your measurements from Atlas, but it's kind of like the needle in the haystack, how can we find those golden nuggets in these vast amount of data that can tell us why something happened. That's one the interesting challenges in the measurements and turning data into insights going forward.

Implement policies developed by the RIPE community. We don't decide how we allocate the IP addresses and what we do. That's decided by community policy. And that's established by consensus, the Working Group Address Policy, that will be tomorrow, is open to everybody, not only members, and anybody can propose and take part in discussions for policy.

And as you will see a couple of presentations later, there are a couple of elements in our policies that maybe, or not maybe, that clearly needs to be discussed to see if there may be needs some changes there to be fit for purpose going forward.

Maintain accurate and up‑to‑date registry data. You want the registry to be trustworthy, it needs to be up to date.

We need to engage with our members and the wider community to keep you informed and involved through transparent communication, events and collaborative initiatives.

That's sort of our responsibilities in a page.

So, what's our focus areas going to be? Next five years, registry accuracy, we have started on that journey and it's going to be increasingly important.

Internet resilience, scaleability and routing security. That's also an area that we worked on and it's going to be continuing to be important.

Data and insights. We are elevating that from, you know, a sub‑goal so to speak in our previous strategy to one of the top areas here.

Community partnership and trust.

Really important to us. We need governance of the RIPE NCC. We are a membership organisation. I am hired by an Executive Board that's elected by the members. There is a General Meeting later today, and there are three Board members that are up for election. So you can use your voting power to decide who is going to oversee me and the organisation.

Agility and execution culture. It's important that we execute and deliver in a more agile way than we have been doing, you know. I think it's a great place to work and we are doing great stuff. I think we can do it even better, right, I think that's something that we need to focus ongoing forward.

So, key areas here:

You may have heard us talk about already that we need to have a serious look at our IT infrastructure, and that's going to be my next talk, so I'm not going to dive too much into that.

Guarantee the uniqueness and integrity of Internet number resources. That's important, promote adoption of technology such as IPv6. Then the big question for me here is, what can we do to do that? Because it's really all of you that needs to help doing that, not only for yourself, that's not the difficult thing, it's for your customers and for your, for peers and so on.

Continue to support an open and collaborative community. Provide information that helps network operators, policy makers and the broader Internet community to understand how the Internet is evolving.

Strengthen relationships with governments, standardisation bodies and competent authorities across our service regions.

We had some very interesting presentations on what's going on in this space in the Cooperation Working Group just before lunch, and it's quite clear that governments need expert input to make sure that the legislations that they are shaping is not causing damage. I think the first speaker said that the hammer is a brilliant tool if you use it right and hit the nails but if you don't use it right you will hit your fingers and that really hurts.

And then, yes, we have heard focus on cost efficiency and prioritisation. That's also going to be a theme going forward.

How do we translate this into actions?

.

For each of these areas we have identified several service delivery strategies. On registry and member services, technical resilience and security, Internet measurement services, research and insights. Community engagement and coordinations, capacity building and learning and public policy and external relations. We have three programmes within the community partnership on trust, in RIPE NCC governance to have a good governance and membership models and for agility and execution culture, we have initiatives for service experience and integration, communications and marketing and people and internal governance.

So, that's kind of going to be the main themes in the strategic documents.

And then if you want to dive more into this and this is just to give you a very high level of some much these.

For the tree and member services, for instance safeguard trust through accuracy, neutrality and consistency, focus on service quality and customer experience. Increase automation and operational resilience. This is where we constantly need to look at all our proceedings not only in the registry but specifically here to see can we do things smarter than we have done in the past. Strengthen external confidence and understanding.

I will not spend much time on technical resilience and security because that's my next talk.

Public policy and external relations. Hisham presented in the collaboration Cooperation Working Group what we have been doing there, and the themes are still going to be protect the neutrality and legitimacy of the RIPE NCC. Standardise external engagement, improve mutual understanding and expectations, Increase organisational readiness and resilience and strengthen coordination within the Internet governance system.

Then for Internet measurements services, we have similar goals for community and engagement and coordination. We have similar goals to be a super connector that enables communities. We are not only building the RIPE community as you see here, but we also build regional community and we support NOGs to build local communities also in countries. And you can also look at the roundtables that we do with governments as a way of building community of government and regulators also some government don't like to be called communities, they want to be called governments because they are special.

Oh, yes, I almost forget here, events, Organising cost efficient and valid events. I mean events like this are great, I think we're having record high, at least in my short‑term memory, participation at this event, which also stretches the budget right. The more people that come the more it costs. Now you are say the more people pay as well, but this week meetings are cheap compared to industry conferences. So it's going to be a balance between do we want to have meetings like this in prime cities like Edinburgh, or do we want to go to areas that are more affordable. So far we're trying to do a balance but then, you know, how much money do we have available for this and with the increase in prices in the hotels and venues and so on, this is not an easy task going forward.

Advancing the Internet. Well the Internet is not a stable thing, there are new technologies emerging and we need to monitor that and support adoption of these for the scaleability, security and resilience of the Internet.

Capacity building around large. High quality, scaleability, and relevant.

We basically want to enable you and also you who are not here to do better in your jobs, when it's being in LIR operating your registry, deploying IPv6, deploying routing security and so on.

Good governance, strengthen the RIPE NCC governance. I will say that we have the best RIR governance in the world. Well of course other RIRs will disagree on that but we can at least say that we have a good governance system. It needs to evolve and improve going forward.

But it's really important to base this on an inclusive membership model. We are here for the members and it should be a member driven organisation.

Which means that we need to continue to enhance the membership participation, so that remains meaningful. And part of the challenge also is to support long term planning just as well as we manage to deliver on the next week and next quarter.

Service experience and integration. We need to develop a connected service ecosystem, improve the user experience and enable high quality delivery and strengthen organisational alignment.

Communications and marketing and then people and internal governance.

And rather than spending too much time on that I want to save the last four and a half minutes for questions. I see Rob is running up to moderate the queues.

ROB EVANS: Thank you. Questions? I am guessing the next step is that this goes to the Board for approval next month and then it's final...

HANS PETTER HOLEN: Yes. It's always an interesting discussion of why a five year strategy, that's such a long term. But, you know, we make annual plans, we make quarterly priorities, so having something that where do we want to be in five years, that's really important. If something dramatic happens then of course we can change it, but if you look at the strategy now, compare it with last time, it's not radically different. It's improving, it's focusing in some areas, but most of what we're doing is still the same. Now I have been able to get one person to the microphone.

AUDIENCE SPEAKER: Brian Nisbet. Thank you for the strategy, I have two questions. One, is there an inbuilt review point in that five years? And two, will there be any specific KPIs or measurable goals that come out of the various projects and focus points that will be published?

HANS PETTER HOLEN: The whole idea that all of those objectives listed in the service level strategies, we have KPIs for those, but haven't published them here but I will make sure that they get in the annual plans and in the annual report. So that's the whole idea. And most of these we have already so that we can know we can measure this. That's been part of the last couple of months is to say, oh let's not invent too much new measurements here, let's use what we have.

As for, you know, reviewing, well, to some extent we review it every year when we make the planning to see, you know, is this still relevant, and which pieces do we focus on for the next year.

We could, in theory, do a sort of halfway through review, but in four years time we have to start the next one as well. So that's also part of the thing here. So, yeah.

ROB EVANS: Thank you very much, Hans Petter, and welcome Hans Petter to the stage.

HANS PETTER HOLEN: Are okay, so next topic is for those of you who know me I didn't used to wear a tie at the RIPE meeting, I was workings as a network manager or technical manager, operational manager or before that actually, doing the stuff on the routers, so technology is close to my heart.

One of the things that is kind of a bit painful to be on stage is to say that, you know, when it came to Cloud, we were maybe wrong, right? We presented ‑‑ I said maybe.

Before I started in 2019, there was a Cloud‑First initiative that was started in the RIPE NCC and we published a Cloud strategy and a service criticality framework in 2021. I think that work was really good, Because the service criticality frameworks makes us, you know, gives us a tool, a method to better prioritise the services and see where we need to go and where we need to focus.

What has changed? When I was be interviewed for this job I was asked what's the biggest challenge going to be? And I said the geopolitical situation. And little did I know that three months later I would sit in a meeting in the Ministry of Foreign Affairs discussing sanctions. And six years later we have full scale innovation in Ukraine going on for years. We now have the war in Iran, and the war in Lebanon, the war in Palestine and there are ‑‑ I shouldn't really mention them by name because I am missing half of them that's been going on and we have just forgotten about them, right.

And it feels when I talk to my colleagues in other service regions that we kind of got all the trouble in our region. It's not quite that, but it's not really looking good around us. This affects us.

So that means that the RIPE NCC is not any company with 180 employees and a 40 million revenue that can just have, you know, a force majeure clause in our contracts and say that, you know, in this case it's kind of of the government's responsibility to protect the country against war and commercial contracts have no point anymore . We all together operate the Internet and the society today depends on the Internet. So the security requirements on us collectively, if you are running a network, we saw a talk from, in the Cooperation Working Group, regarding the policies, regulations on network operators in Ukraine, that's really put more and more requirements on both the technical, but also on the human part of operating a network. Taking that into account, and looking at the geopolitical risks, who are our allies today? That's also shifting and who would have thought ten years ago?

So, we have also seen the last year emerging vulnerabilities arising from our current data centre setup. Cloud ‑‑ increasing Cloud tariffs creating uncertainty about long term cost, and yes I know you told us. And to some extent I knew that because the recent move to Cloud isn't to reduce the cost, it's to get flexibility. It's to get ‑‑ reduce the time to deployment when you develop software services, right, you get a platform as a service, you get scaleability, you get redundancy across service regions and so on, that's all built in. And the bet is that the Cloud vendor can do this better than you. That would have been great, but would you remember kind of basic infrastructure and even the Cloud vendors rely on our services. So we would have a chicken and egg if we put everything in one or more of the Cloud services.

We also, following this we need to minimise our dependence on external parties. We can't do everything ourselves. We will not have our own proper plans and we will not build our own data centres and we will not build our own networks, so we need to depend on other vendors, and our strategy as I just talked about emphasise as modern scalable infrastructure that is highly resilience and secure. So therefore, as requested by you, by members, a much greater emphasis on running core services on our own technical infrastructure moving forward.

So, last year, we presented challenges we have with the measurements services, and it's not really, you know, part of the critical part of our infrastructure, but I put in link here if you want to go back and review the whole presentation. But really, what we saw was that the back‑end, based on Hadoop technology, had come of significant age, and needed renewal and one of the drivers to do this was also then to save cost through reducing the data centre footprint. And I am happy to say that the work that we did in 2024, although it was a bit delayed, so we didn't see the effect until end of Q1, 2025, that's now been completed, so we have reduced the footprint from the left picture to the middle one and we are almost there with the right step in order to reduce it further.

In the middle of this, we have also changed one the data centre providers because when the RIPE NCC many many years ago decided on two data centres in Amsterdam, they selected independent vendors, now through acquisitions they are now owned by the same company so we have now unmoved one the data centres, significantly out of Amsterdam and above sea level, which is also a thing in the Netherlands.

So, the question then, when it was presented last year, was how much will we save on that? That's always difficult to predict upfront. We have taken some of the high level cost lines in the annual reports here and analysed the trends here. And you can see the bottom blue one here, that's the IT housing, that's the data centre costs, and the increase that you are seeing there from '20 to '24 that's increased power cost. It's not that we have increased the footprint but electricity got more expensive so we had to pay more for that.

.

The top Orange one. You can guess AWS, you can find that on our trust portal. It's not big surprise. In 2020 that was in early stages internally, and then you can see it grew the usage in 2021 and 2022. And we have worked on getting cost control over that in '23, '24 and '25. So while the cost in '24, '25 is a bit higher that's because part of the data migrated from Hadoop into long term storage in AWS, which is more cost efficient.

An then of course, you can see here in '25 that we have cut the data centre costs significantly. But then the dark blue line, that's leasing infrastructure as a service, leasing servers from European Cloud provider to the extent that you can call infrastructure as a service Cloud, but, you know, it's not in our own data centre in Amsterdam, it's outsourced so we have much more agility in that. It's not quite shaving half a million by spending 50k because there are some other costs there as well but it's a significant spend on that. Then there will be more savings in '26 and '27, because we won't have the full effect of the data centre reduction in '26, but this is kind of optimising the back‑end of the measurement services.

.

Activity plan and budget 2026. I put in there text that in order to deliver on what we are going to do we need to remain in full control of the information and services we provide on behalf of our members. That doesn't exclude us from using companies to do that, but we need to do this with trusted and independent partners to I avoid single points of failure four critical services and be resilient beyond national borders, so we can't keep everything in the Netherlands and rely only on the Dutch providers. We need to have something outside the Netherlands. Maybe we even need to have something outside the EU, but I think that will be Phase 2 or 3 here.

And it also means that we can't rely on the US hyper‑scalers because they are all US and they all are serving at the mercy of one government. So we need resilience there also. It doesn't necessarily prevent us from using them all together, but we need to be very mindful that in the you think thinkable event that there would be a presidential order preventing the US to provide service to say a Dutch organisation, we are able to continue to operate, right.

It's a scenario that didn't exist in any risk register ten years ago.

So, that means that we have already started to reassess our current architecture around develop our next kind of ahead of strategy, and started to look into this.

So, from the strategy, we had service level objectives on the technical resilience and security. Resilience really important, independence, security, maintainability and modernisation. All of these are important, but the thing with building an operating an IT infrastructure is that the plan you make now to replace hardware and upgrade, in five years you have to do that again because that's the end of life of equipment. And yeah, some equipment may last seven years or ten years, but not much beyond that.

.

And then also, we had some incidents last year. And not everybody was that happy that I would put this up here but, you know, if you look at status.net all of you would see this. We had two significant incidents in July and November, and they were the same ‑‑ both listened to the fact that we moved the data centres further away, and we had, you know, challenges with the optical layer in the network that affected performance in the storage system and there you go. So it's like when you look at route course here, it's a chain of events. It's a lot of different things, a lot of things that could have prevented this, it's not just one thing so this led me to think that we need to have data centres that operate completely independent. We move things to the AWS, that still depends on what's in the data centre. So if the data centre completely disappears, does the thing that we move to the Cloud continue to work? If one of the data centres goes offline, will the other one carry the full line? So that's one of the main design criteria from the business side, from me, is that we need to have fully independent installations for our core services.

.

.

So we cannot really return to the way things were. The stakeholder expectations around security stability resilience have increased significantly since we started the Cloud project. Now many people moved to the Cloud because the bet is, and this was in my last job, our bet when we moved to the Cloud in the company I used to work for was that they are so much bigger than us so their security department is so much bigger than mine, so they will have a much better chance of actually withstanding any problems. So that was the bet. The consequence of that provider going down is much bigger but then on the other hand that means that they have much more skin in the game than I would have.

So, it's kind of a bet anyway, I remember that with my own tech team when we were growing, they, over five years, they, over five years, okay, we're learning things we're getting better at fixes incidents, at reducing the likelihood of something happening. Since the business was growing faster the consequence of the incidents got shall higher so the risk actually increased. They felt that it decreased over time because they got better, but in reality, the risk increased. That's part of the thing that we now need to look at. How can we do better than the major Cloud providers because that's really what we need to do, right.

New legislation, and we have had a lot of discussion on NIS 2 and EID As and so on. It doesn't really matter, we need to be on at least that level, right. Of course it matters, we need to follow the laws and regulations, that's not what I'm saying, but really, the subtle discussions on which services here and therefore, whatever, so this is why we have invested a lot in security compliance and now soon have an certification.

Then also, there is government documents coming from the community or from the multistakeholder space, the RIR governance document that will replace ICP 2, that will also put requirements on us such as having an emergency operator. So if the RIPE NCC governance totally failed, you know, think bankrupt or the Netherlands completely off the map or something, there needs to be a plan for how to continue the services. And if you wonder why we think about that, think about AFRINIC, right.

So, what are we going to do here? We need now to actually touch most of the layers, and my thinking here is that rather than trying to ‑‑ rather than trying to fix something on this layer and that layer, build something on the side and then migrate the services over to the side. So that may be more expensive as a one‑off now but in the long term, I'm quite confident that that gives us a better solution. So if somebody can fix the picture on the screen in front of me, that would be brilliant.

But then what will be discussed? That's, you know, the 5 million question, so to speak. Not that we know that this will cost us 5 million, but if you look at the budget and the spendings over the last 15 years or so, the budget was closer to 2 million than 1 million, but you can also see that the RIPE NCC spent way less than the budget consistently. Then you come into the period after the Cloud‑First initiative and we really have under invested, could you say, in those years, but that's because we were thinking of moving things to the Cloud. So it's a quite logical thing to do. But in order to then get into what I believe is a necessary infrastructure going forward, we need to do investment this year and this is something I will discuss with the Board in June when we will have more firm plans on decide architecture and a first proposal on what this will cost. Because this project is something we have already started on designing this.

.

Quick recap.

Infrastructure has evolved over a long time. A lot of technical depth. We need to rethink this and we need to get in internal expertise in order to execute this project quicker than we can do only with our own resources. We want to be in a position to operate it ourselves afterwards but designing and building is something that we can buy help to do Quicker.

One of the things that you may be shocked with the size of the investment here, all of you that's trying to buy computers or network equipment recently announced that the price is going through the roof because RAM prices and SSD prices really also go through the roof.

How will we finance this? Luckily the RIPE NCC has significant reserves so financing the cash out for such a project is easy, we do not have to go to the bank to loan, we do not have to do leasing or anything like that. We can basically ‑‑ the Board can approve spending from the clearing house.

And then how do we pay it back? Well increasing membership fees. That's not the most popular thing to do. And we can do, we can be more efficient internally. I think we need to do a bit of all three things here.

This is also where I think an updated charging scheme is really important because this means that in the category model that will be voted on today the burden for the smaller players will be significantly lowered by the bigger players that have the means, have the possibility to contribute more.

Next steps:

.

Project running from '26 to '28, will share more details once we have decided a path forward with the Executive Board. And you know, I'll share a blog post based on my speech here after this meeting, and share it on Services Working Group and please share your thoughts on this there. And the Board meeting is in a month's time.

With that, questions.

(Applause)

AUDIENCE SPEAKER: Just a great presentation. I am very happy that you have accepted that the Cloud strategy might not have been the best move, And that you are going back on that, So great job.

I would also just, I guess ‑‑ you answered one of my questions which was, have you considered having another data centre outside of the Netherlands? I think that's a great idea. And then I would be careful when it comes to I guess having an external party design your infrastructure because from experience, sometimes when you get an external party to do that, they don't sign it for maintainability. It looks great at the start and then you want to do an upgrade and it's awful.

HANS PETTER HOLEN: Thanks for that advice and I can assure that you all our engineers from all of our teams have been involved in this work, so while we have external help here as well, because we are not in the business of designing new architecture, right, we're in the position to operating and maintaining and to some extent developing so we need help on that but good point there.

Yeah, a number of data centres, yeah, I have said three, Ideally I would like five or more because once you do one and two and three, you tend to restrict yourself into manual things and so on. It really should be distributed in a much bigger way I think. But the cost of doing five plus, I'm not sure that ‑‑ that's not in the books right now.

AUDIENCE SPEAKER: Tina. AWS. I just wanted to say, for one thing, I don't mind what strategy you go with at all, That's not why I am up here, But I did want to make some clarifications.

I know AWS is based in the US. However, we have a European sovereign Cloud now. In fact we just opened a new RIPEorg, and all the IPs, everything used for that is hosted in RIPE. We have gone through great pains to make that happen. Another thing you mentioned the dependency on the Cloud is dependant on your data centre. That means it's poorly designed. I don't want to get into the Cloud ‑‑ hold on ‑‑ ‑‑ I just wanted to say that, but I did want to say the Cloud could still be there for some of your off storage and there are discount programmes that we are working on, the layoffs in January kind of put us off on that, but for external Cloud storage whether it's AWS, Google, whoever, I don't care, it could still consider that better, especially if you get non‑profit basically free storage, please use it.

.

My last comment was, you have a CTL position listed, which I didn't hear you talk about, but I am really, really excited about your hiring process there. Please hire somebody with really innovative thinking to really go back and go through the guts of your organisation, look for manual processes, look for old Excel spreadsheets, look for anything and everything that we could do to make this better and more resilient. Use Cloud, don't use Cloud, I don't care. I just wanted to let you know it's not completely dependent on the US at this stage.

HANS PETTER HOLEN: Thanks very much for that. And one of the not so recent legal analysis we did, that was not AWS but a different provider was that you cannot use this service to deliver services to and here comes a list of countries in my service region like Iran, Syria and so on. So those things are difficult, we have banks that don't want us to deal with members in those, so the further away we can come from any obstacles like that, the better. You are right we will not get rid of all Cloud services and I haven't talked about software as a service, we have several services that we're buying software as a service. We will look at them when it's time to evaluate them, but it will not be an avalanche of moving everything in‑house. But bringing the basic services, RIPE Database, RPKI, LIR portal registry, sort of from the skies to the rocks, or something like that, is kind of the primary goal here.

RANDY BUSH: As you can tell by my accent, I am currently living in an untrustworthy State. Tina, you may be unaware that in a untrustworthy State we have a law, I believe it's the Cloud Services Act, which specifically says that no matter where the Cloud service is operating, the US government can do whatever the hell it wants.

HANS PETTER HOLEN: I think without singling out a single government here, that's the thing, Governments can do whatever they want. That's a reality that we need to take into account, and that's also part of if you think about why would you say five plus data centres? Well, it's getting increasingly complicated to have data for members outside of the EU in EU just as it's complicated to move data from EU and outside. So if we look into that you may also think that we may need radical re‑architecture of our software. And then I know that all my software development team screams at me afterwards because that's completely unthinkable. But I think we need to start to think about that. So thank you, Tina, for the insight here and especially on what kind of CTO I need to hire. You are quite right, there is a CTO position open and application deadline is at the end of the month. We have a lot of interest in that position, I will say, so I am really excited to go through that.

ROB EVANS: Thank you very much Hans Petter.

(Applause)

.

Now, Hisham.

HISHAM IBRAHIM: Hello everyone. I am Hisham. Bob started by saying he did not expect an ENUM presentation at this point. I never expected to be making an ENUM presentation but here we are, let's see how this goes.

This presentation covers the 2026 operational review that the RIPE NCC conducted on one of the registry services that it runs, which is ENUM, we are very well known for distribution Internet number resources, the IP addresses, ASNs, but some of you may or may not that we also run a registry called ENUM under e164.arpa, which I am going to talk about a little bit.

Now the purpose of this presentation here is not to resurrect any Working Group or anything like that. The purpose here is just to share the findings that the RIPE NCC has found as part of that operational review.

I present the actions that the RIPE NCC has taken, clarifying why, the logic behind that. But also solicit feedback from the community, and we have had some so far, but also I am more than happy to get comments, feedback and critiques on how we have approached this.

Now, a little bit of an intro to what public ENUM is. So public ENUM maps numbers from E.164 which is the country codes that we use, the plus 44s, plus 31s, plus 971s and such. The international numbering plan onto the public DNS tree under e164.arpa. It was meant to design to be a global interoperability mechanism. RFC 3245 talks about this in more detail, also explaining the different roles, and identifying e164.arpa as the single public tree for ENUM lookups.

Now to clarify, because this is also a question that was mentioned on one of the mailing lists. We are in this review we only looked at public ENUM under e164.arpa so this does not could have any federated carrier ENUM that could be privately used which we would have not have any visibility into.

Roles and responsibilities. This is important here, the next couple of slides, because part of the criticism that we have heard from some people that we have been speaking to was about who did we approach and how did we approach them. I think clarifying the roles here might help a little bit to explain the allocate that we had.

Looking at the roles as they are defined. There are two sides to this, so ENUM sits between the two worlds. The public telephony world and the Internet world. From the telephony side of things, E.164 is the international public telephone numbering plan, Plus 44s of the world. So, there is, the role there is who the ITUT and the TSB there, to coordinate that ENUM process.

Member states, administrators, national authorities, are involved in this because well the numbering side of this obviously.

That's the telephony side of this.

Then you look at the Internet side of this, well the usual suspects that we would know. The IETF, develop the protocol, IEB set the instructions of how to operate it. IANA administers the dot arpa infrastructure. RIPE NCC was tasked to operate the zone. And the delegation holder, the DNS operators would be operating the delegated zones themselves.

Now, in the instructions that we were given by the IEB, which I must say are very well thought out that covered all the scenarios that could have happened. In the 2019 instructions that we have, it made it very clear that RIPE NCC can access the delegations, see if they are working or not, if they are broken, the state of them, operate the 164.arpa zone, maintain the registry, contact delegated ‑‑ the list of delegated contacts. However, because of the delegations are based on the E.164 country codes, any changes to the registry needed to be coordinated and approved by the relevant E.164 country code holders via the ITU and the TSB. That's part of the instructions that we were given.

There is an article that I put out last week that goes into a lot more detail, if anybody is interested in reading up on that. I know that there are people in the room here that were part of this and can lecture me on this better.

Operating ‑‑ so the operational review and what we found.

The RIPE NCC was looking at this for a bunch of different reasons. You have heard Hans Petter go ahead of me talking about accuracy of the registry that we're doing and all the sub‑net we're taking and doing that. All the compliance measures that we're looking into, all the service that is we are running and trying to make sure it's there. When it came to ENUM, this was one of these things that unfortunately we were seeing the quality of the data in there deprecating over time. It's something that we have been trying to raise and flag, but we didn't really have a straightforward way of actually doing that because of the different roles and responsibilities and how it was distributed and documented at the time.

So, the review here was never meant to preempt any outcome or make any decision. It was mainly as part of the instructions which we were given by the IEB to conduct periodical reviews and check the health of this. And then report back to the TSB if we find any brokenness.

Again, part of the instructions.

So, here is some of the findings that we have had.

So, my colleagues from the registry, Marco and Mike, they dug up ‑‑ we had them published on the website, we have 50 approved ENUM zones that were delegated. Two of them were they'll abandoned and never created. Two of them were later deleted from the database which leaves us today with 46 current delegated zones in the RIPE Database.

Now out of those 46, 32 of them have no observed DNS issues but half of them have some kind of DNS problem.

To now, that already shrinks down the numbers. Now, as part of our review, as part of the process as it's been documented my colleagues in the registry would notify the TSB indicating that, then there is a process there that I am going to be talking again about soon.

Then we asked other colleagues, on the DNS side of things we asked them to look into is there the amount of queries and traffic that we're seeing towards these different delegations, as you can see I won't go into the numbers, for the sake of time, as you can see, from the different vantage points that we were looking at, the amount of queries were quite minimum.

Now that doesn't mean that there is no use of, there is no purpose of having it, that doesn't mean they are not maintained. From our vantage point we weren't seeing much traffic goes towards this. A lot of the traffic that you are seeing here even though it's marginal, a lot of us was our stuff ping it go to make sure it's still working. DNSMON checking it we were seeing some junk queries that are not necessarily related to ENOM there.

Database queries, my colleague Ed looked at this, from the beginning of the year from 28th April we were seeing an average of the 34 queries in the database per day. Again suggests slow visibility and low demand. It doesn't say that there is nothing, right.

In case, in several cases, we knew that there were broken delegations, we tried to reach out to the contacts. They ended up bouncing back. We tried calling members, the phones were disconnected, and as part of the process and the review, if I remember the numbers correctly, I think when we sent out to all the contacts that we had, at least 20 plus percent of them bounced back immediately, and the others, some of them indicated that they have no active use for this and others were still waiting on responses from.

Now, again, this is what the evidence suggests here. The picture is not even. The question is not as simple as is a public ENUM dead or alive? Again what we were looking for which delegations are still maintained, who is accountable for them? What level of support are we seeing? In recent years the tickets that my colleagues were getting from the TSB were mostly about hijacks or delegations that had issues or deletions rather than actually creating a new delegation. I believe the last one was for Ukraine in 2020. That was the last one that was created. A couple were filed but never followed up for.

Engaging with the ITU and study group 2 on this. As I was saying, the i.e. about had instructions of how we deal with this. The instructions were very well written and covered all the define aspects. The issue that we had wasn't on the IEB side of the instructions. The issue that we faced after we reached out to the TSB and the TSB will reach out to the member states if they didn't hear back there was no procedure for them to move from there moving forward. Which is something that they had to fix on their side. Not on the IEB or the IETF. It wasn't a protocol issue it wasn't an instruction issue, it was a procedural bit within the ITU.

we reached out to study group 2 earlier this year I need to acknowledge something that again having discussed with a few community mens which I appreciate their feedback and their thoughts, we do acknowledge that maybe some of the wording could have been a lot more precise, or the submission that we have put forward.

When we talked about ‑‑ the idea there was always to solicit guidance and solicit feedback on the ‑‑ how the member states saw this service. That was run based on the numbers rather than us necessarily like I said jumping to any conclusions here.

And then since then, what happened was the TSB actually circulated revised interim procedures that helped fix the issue that we have. So they set a timer for if they reach out to a member state and the member state does not reply back within a period of time. When the NCC can proceed to removing that delegation. Now, again this is still an interim procedure. This will take effect after study group 2 meeting in September. But this fixes the issue that we had which, like I said, was a procedural bit on the ITU side not on the IEB side of things.

Then talking about the IEB. This lives between the both world so both parties needed to be notified about all the actions that we we were taking which we ended up doing.

The RIPE NCC has engaged with the IEB earlier this year on this topic. We had some formal and informal chats about this but also well at the last IETF in China, we also met up and discussed, I believe that, they had a meeting, this was discussed and minuted in one of their meetings about them waiting on feedback from the community for more input to see how this looks for next steps.

Operational input matters here. So as you can see, the picture is uneven. Measurements alone don't really give you the indication of what is really happening there. We only have our vantage points. So actually hearing back which was one the main reasons why we reached out, was actually hearing back if the rightful holders still see active purpose for them to continue to do this. Are they still maintain it go or are they still running this? This was a big part of the process for us.

At least we got one comment publicly. We got some internally but at least the public one that I am mentioning here on the slide if any of you are subscribed to the cooperation mailing list you will have seen Internet Society Netherlands reply back confirming that their delegation is operationally maintained, they have DNSSEC in place and the current contacts are in place there.

We have had more than one country reply to us saying something like this. Like I said there is others that indicated that they don't have any active use for this and there are a few that we found were misused or hijacked, some of them acknowledged some of them were surprised to hear from us.

Closing message to allow for more time, as I promised Rob at the beginning. The idea here is some people said you should have let lying dogs lay. You shouldn't have touched this. It's highly sensitive. Let it be. That's fine. We run the registry. And we run this registry at the specs that you expect us to run the registry by, right. Having seen the numbers here this does not meet or standards. I am pretty sure it doesn't meet the community standards. This is about stewardship. It's not about leaving something running because nobody has complained about it. The we should not continue this, and we should not assume that any changes should happen. We should be talking about this. And addressing this with the people that are actually using this or know the history better than us or help guide us on this to see how we can actually get some things changed. Like I said, part of the positive outcome of this is that interim procedures that the ITU and TSB has put out that helps us make sure that we can maintain a more accurate registry moving forward.

Next steps, we will have a discussion with the community here, so I am just kind of leaving it at this. Are there any operational fact, contacts, risks or anything that we should be aware of. I am going to stop talking at this point. Allowing for people to go to the mic. Thank you very much. Ed

ROB EVANS: A question came in from Maximilian, wasn't there an incident where a private individual hijacked an entire country zone via an expired domain?

HISHAM IBRAHIM: I would say there are a few, not just one. As I say some of them that we saw and the countries will confirm that they know that had that happened. Some much them were surprised but yes it has happened on more than one occasion.

AUDIENCE SPEAKER: You I feel like in a way I partially kicked this off by asking about RDAP support for e164.arpa back in July of last year. This was not quite the outcome I expected. But, I agree, that there needs to be things done in order to improve the situation, such as having RDAP support to have it on the same level as everything else. I also think that it's great the process is to clear up broken delegations when you don't have the members responding but I think there is a difference in a way in the discussion of like we should clear up delegations that are broken and get hijacked. Should we really keep this thing at all even for the countries that do think they have a reason to keep it and have, have like a proper delegations with contact details. My phone ecosystem, I have a delegation for, under the Swedish country code. So, is clearly there are a number of countries that still maintain their systems or their delegations and I don't think we should inter mingle the overall system too much with these broken delegations or other such smaller issues in a way.

HISHAM IBRAHIM: To your point about RDAP, while it was maybe the last straw that kind of broke the camel's back as they say it was really about the operations of the registry and the fact that in the last review that we did in 2020 I believe, my colleague that was working at the RIPE NCC at the time, had informed the TSB about all these issues and for the past five years unfortunately there was no solution for this and we were seeing the deprecation of the quality of the data going down year‑on‑year. So, that's kind of the situation. And the IEB instructions do talk about a periodical review which we felt five years later was just due.

ROB EVANS: In the interests of time I am going to close the mics now.

AUDIENCE SPEAKER: Following up the idea said by Cynthia, we can make the service a little bit more valuable to we already have the procedures of registry data for the IP addresses, well IP resources. Shall we cover also the contact verification and DNS status verification for the ENUMs registry and ENUM zones.

HISHAM IBRAHIM: The process is different ‑‑ we need to get instructions from the IEB that would cover something like this, like that, we cannot do this ourselves.

AUDIENCE SPEAKER: Could you refer to some documents?

HISHAM IBRAHIM: Yes, sure, in the article that is linked here, all the linking are hyperlinked in that document. But I am happy to point to you as well.

JIM REID: Come and talk to me afterwards. I have got and awful lot to say about this Hisham to thank you for your report.

But there are a whole bunch of things here which I am sorry to say the NTT has got very, very wrong. I think one the most telling things from your presentation is having discussion about this report on the status of what's happening with ENUM registry in the RIPE NCC. But you submitted a contribution to study group 2 of ITUT before having that discussion here that simply should not have happened. It's wrong do have done this beforehand and the contribution that was submitted to study group 2 does not have any kind of community mandate or support, and that again is wrong. And in saying this is just a question of wording. No no, it's far more serious than that and some of the things that are in the wording of that document are fundamentally problematical, because amongst other things that's in that document is the subtext of it is NCC can't run this registry anymore, ITU can you please help. That's not a good luck. Especially when you present a document like that in an ITU setting.

Now if you had concerns around things like the contact information for the Tier 1 holders, that could have been done with a private letter to the TSB, the secretariat, not something that goes into the study group 2 meeting which creates a whole new world of problem space and the work I have got just now with those documents there is also another one with the circular that came out, those documents see things which are fundamentally incorrect and they will be exploited, particularly in other venues, by countries that are hostile to the multistakeholder world of Internet governance. You are going to say things look at those stupid Internet people, they cannot run this stuff properly, bring this back to the trust because you know the ITU, we do this stuff, you can trust us. Those arguments are definitely going to happen and you have made that a possibility for them, opened the door to that, not you personally, but others in the NCC have done that and I think that's extremely damaging and very, very eye I had no and upset about this and I am worried about the consequences of it. These documents are going to sit there and live forever are and they will be exploited and they will be dragged up at things and IGF and all sorts of other foray and they will be using the excuse to beat people over the head saying the multistakeholder. The multistakeholder model of Internet governance doesn't work anymore and that's a very, very damaging thing to have those kind of arguments being made. It's also very significant that there was no communication with the IEB before that submission was submitted to the ITU and you said yourself that you had a discussion with somebody from the IEB at the IETF meeting, that took place after the study group 2 meeting. That was after the event. I spoke to several of the members, one of them is right behind me, the first they got to hear about it is when I told them this circular is going to come your way, you need to start thinking about a response. I am unhappy about this and I think we have to figure out a way forward.

Another thick I want to say, it's perfectly reasonable to say let's shut down this register, maybe the NCC should get out of that business and hand over to somebody else. That's a perfectly reasonable thing to have a conversation about but we have had not had a conversation and if we have a community consensus on that, then and only then is it time to start talking to the ITU and also to the IEB about what the next steps would be and I am very, very very disappointed that that never happened.

HISHAM IBRAHIM: Thanks for your comments. And your critiques and also the fact that you raised this to us even before the meeting. Not to add all address points. I do look forward to working with you and other Member States that we have reached out to and have been discussing with to see the best way forward on this. Will and again, there seems to be always this going back to the NCC wants to close running this service. That's not something the NCC has stated at any point in time. It was part of their, of the questions that were asked if this is still something relevant or did they see that, but the NCC never indicated that it wanted to close it.

JIM REID: With respect that's a little bit misleading. The contribution that went to study group 2, we are thinking about closing it down, what do you think?

HISHAM IBRAHIM: Fair enough.

AUDIENCE SPEAKER: Marco, can you hear us. Good afternoon colleagues, from the Netherlands, my name is Marco, and apologies for the length ever my intervention. I work for the Ministry of Affairs and Climate in the Netherlands where I currently serve as the ITU focal point. If you think hey he looks familiar or sounds familiar, I am also the representative for the governmental advisory committee. I currently serve as one of its Vice‑Chairs. And just to remove any doubt I am speaking here strictly in my capacity representing the Netherlands as the holder of the plus 31 country codes and the negotiated E1 364 domain name, which as you mentioned is currently operated by our national ISOC chapter. And as you mentioned, yes, full disclosure, I have dabbled with instruction sets, between 2017 and 2019, spent an awful lot of time with the IEB and other stakeholders and I dare to claim that significant portion of the current text came from my pen, as I mentioned in chats, feel free to blame me. I am safely tucked away here in the Netherlands at the moment.

I have a few questions of my own, and I am not going to challenge your observations that the registry is in a very poor state, that was actually why we started the exercise in 2017, and added some additional clauses to remove I think as you explained sort of the intended effect would be like if we mention, if we notice brokenness, if you fail to fix it or in response is, if we consider it a removal request and act subsequently. Jim already touched upon some points, I am not going to go into details, but I am still trying to understand if that process has actually been fully tried, including sending liaison to SG2, as it is mentioned, I certainly don't recall seeing anyone. But as I said, I am still trying to understand where this process is failing, if it was my mistake in drawing it up, my sincere apologies for getting us all into the hole we're at.

Secondly, and you mentioned around hosted delegations are functional, and yes I appreciate you have been in touch with the Dutch operator, but my understanding that that engagement came rather late, and I think also Jim already referred to that in the run‑up of your assessment and considerations on what to do next, did you actually ask the 23 currently operating registries, the ones that are actually sort of functional and responsive, I would love to hear what they had to say about their future plans with they are delegations.

So jump to your question and apologies for taking a bit of time, but Jim already talked a bit about ITU but let me quickly try to explain the ITU process here. I am not going to go into what has happened or what went wrong here, but as Jim mentioned as an ITU member state, I have been asked to provide an answer to what the ITU called a circular and that question was very straightforward. Should we stop e.164.arpa services? Yes, that's a very binary, yes/no, very simple. The difficulty and that's why I am bringing this up also probably for people who are not an ITU member is the misrepresenting the term "Question" here leads to. What has happened is the study group already made the decision, what we now see as a member state in front of us, is what Internet people would say is the last call. So, just to emphasise, we are asked to confirm the decision to stop and the default decision for ITU will now be to stop the service.

.

So, if we don't want to do that, if you want to revert that, you actually need quite a substantial number of ITU Member States to now actually write back into ITU and say no, and provide a the rationale. You actually have to also say why you can't stop this, why the answer is no. And that brings it back to the study group to say like, hey, make a different decision, we don't agree here.

Now, for transparency, my plan ‑‑

ROB EVANS: Marco, Marco ‑‑

MARCO HOGEWONING: I hope I can find enough momentum, especially from those countries that have been working delegation, to write into ITU, but those are very extensive processes, as you can understand, as a government seeking approval for that kind of thing that requires multiple layers and a lot of talks, so I am not too certain we will make that.

So to wrap up and to your questions, please can you help building that coalition of Member States, and I work with the 23 delegations that are operational to also help for them to help mobilise those government and actually come back to ITU and make sure that the answer is no and please provide these services. So ITU holds up to their end of the bargain.

Secondly, as I said, I am not too sure about the outcome of this, so, I would also greatly appreciate if you can provide a plan for contingency. What happens if ITU says yeah, okay, we'll stop our end of the deal, we'll stop our service, can you provide a save and soft landing? How does this work? What are we going to do as a community with the zone? We're no longer supporting this ‑‑

HISHAM IBRAHIM: I appreciate the points that you are making, I really appreciate the support that you have shown, we are running a bit late on time here and there are other speakers, but I do want to follow up with you on this, and I appreciate the help you have provided so far.

MARCO HOGEWONING: ...... in this arrangement...

ROB EVANS: We lost your audio, Marco, can somebody press stop!

.

I do want to comment very quickly. I appreciate the points that Marco is making and the work that he is trying to do to help us with this. It's very much appreciated from the RIPE NCC side.

ROB EVANS: If you could keep the comments very, very concise please.

AUDIENCE SPEAKER: Tobias, looking at some passive DNS data for the delegations. I see roundabout 100‑ish unique RL sets per month. So that that's less than my private /48 at home.

HISHAM IBRAHIM: Yes.

AUDIENCE SPEAKER: Peter Koch, DENIC, DENIC is a RIPE NCC member, it's also the operator of the plus 49 country code in ENUM. And we are not happy with what you did, For the reasons that both Jim and Marco have expanded on. This was a serious interference, and what I don't hear, or haven't heard here, but also missed in your presentation, is the Internet governance level aspect of this.

What happened by what you call is your choice of words, is essentially that on a silver plate, a question was posted to the Member States to decide on something that is essentially an Internet service. This has gone in the wrong way. You have done this by your sector membership in the ITU. The registry function doesn't have an access to the ITU, it would have had to use the liaison through the IEB. So by shortcutting this there is a significant political turmoil that's encompassing here and I am really seriously concerned about that having set a precedent for further conversations with the ITU or other issues that pop up at the end of the year. So one ask I have is, and other people have asked that before, since the circular that you submitted is not available to mere mortals, unless they have a ties account and a certain level of access, you should please publish that and make sure that whatever the follow‑up work is, is channelled through the appropriate part of the community. 46 delegations, 28 of which are still working. The vast majority of those operators sit within your service region, they haven't been consulted before, and I would like to ask you to improve on that seriously. Thank you.

HISHAM IBRAHIM: Thank you for that. Just very quickly, we did publish the submission that we put to the ITU as we do in all our consultations and submissions on the website. It is available. I think it's linked in the article that I pointed to.

ROB EVANS: Thank you very much. Thank you for standing up here and doing this. Please, there is a mailing list, we can continue this discussion and I am fairly sure the RIPE NCC have heard the points that have been made.

HISHAM IBRAHIM: Thank you very much.

Applause)

GABOR DE WIT: Happy to be on stage here after such a light discussion. So that's good. For those who missed it last year I am the new CRO since last year, so it's also good for me to be on stage and show some of the things that we have been seeping over the past weeks and months while working on our other favourite topic, the charging scheme.

So as many of you know and as you have seen in some of the text that we have been seeing today there is a lot of interest in the charging scheme over the past weeks and months and also there is of course the GM today. But there is another side effect of working on the charging scheme so far, it's also that we have seen additional efforts or possibilities for the RIPE NCC to actually improve the overall services that we're delivering and which some of the concepts that are now part of policies, part of the processes, part of procedures, are actually making it more difficult for us to operate the registry and that's what this presentation is going to be about today.

And be very mindful, I am going to be mindful after the session we have just had, this is a callout to work with everybody in the room here to get something going that works for all of us, this is really a public callout, we need help in fixing these solutions essentially.

I have three topics today, around multiple LIR accounts. I am going to be going into the history, why was it introduced and why do we stand today and what are the considerations that we have for today. This is the same for provider independent space and service and also in the legacy resources.

.

Being mindful of time I will race through the content a bit and leave time for questions. I hope Marco is not still talking, but let's see!

Clarification for today. So we want to raise some of the areas of complexity for your consideration, and do you agree that these domains are also up for simplification and is that a goal for us to pursue, together with you, of course?

.

So we start with multiple LIRs. So, initially the entire concept of multiple LIRs was introduced to actually simplify some of the account management for bigger members including members that were doing frequent MNAs. The way in which they were structured, multicountry, multioperating companies set up meaning that they wanted to have an ability to sort of split the operational responsibilities and also the account management and asset management.

In this RIPE NCC is diverging from the other RIRs, so we're special, we are always special but in this occasion it's hurting us a bit and actually what also happened after the run‑out is that we have seen that most of these multiLIR accounts were used to obtain a place in the waiting list. It's also some of the interesting numbers that you see on the screen here, so over the years 40% of IP allocations were done to members with multiple LIR accounts, which we're also seeing that in 2019 we had 5100 additional LIR accounts, which was back then 20% of the total amount. So that's quite interesting.

Now, zooming back into today, and the reason why we're bringing it up today is as you can see in the numbers is that the total amount of multiLIR accounts is relatively small. So, over the past two years, we're not seeing many of those accounts being created. While the total number of multiLIR accounts is actually also a fairly small amount of the total membership numbers that we have today.

Why is this relevant? This is why it's relevant. What we see is that in all the things that we're doing, which includes things like managing member data, but also managing member resources, we see that the multiple LIR model is actually introducing complexity and fragmentation. On top there is the increased administrative workload, instead of just sending one invoice to one member other sending multiple invoice even though behind the scenes it's actually the same company I go paying the bill. It's a bit of the accounting principles in which another department is actually taking care of some of the financial burden of that operating company.

So, the considerations that we're looking at today. Should the multiLIR mechanism actually continue to exist in its current form?

Looking at the policies and the procedures that we have today, should we align those? So, if you do a quick look‑up and check for LIR versus member versus all of the other things that we refer to having, let's say, a unique identity, which can be an LIR or a member, its the policies are not very consistent. We see that different wording is being used in different context. From the perspective it's very interesting to take a step back and to evaluate okay, are we doing the right things in the documents that we have today? The last one, that's also sort of call for action is: Should we now take the time to actually gracefully remove it? So think about freezing it for now, the creation of new multiLIR accounts and gradually phasing out the multiLIR concept in general. And the reason why we're bringing this up today as well is that we don't have a glass ball, we don't know what's going to happen this afternoon or in future charging schemes but actually by simplifying the entire concept of multiLIR we want to prevent that in the future the multiLIR concept is going to be used for stockpiling or for using to optimise the charging scheme as an example. And now, looking at the previous numbers that I shared, it's actually a good time to do this because the total amount of multiLIR accounts is actually quite small.

That's why we're bringing this up now.

Then I move on. Keeping a bit of a pace because of time and I think there is hamburgers that are very good. Provider independent resources. If you look at the graph that we have here today, Initially the entire concept of provider independent resources was is introduced smaller members you want to be able to be provider agnostic, move your resources around without having a need to continuously re‑number your entire state. That was the original intent. However, you already see fairly quickly already in the 2000s, is it actually some of these concepts were already been used in a different way. Already in the 2000 you see the first movements in which the PI space is actually used for connecting to actual customers as an example. And this is already moving beyond the original intent that was done.

That is further amplified in 2012 when you see that is when the IP run‑out happened is that there were no assignments done anymore of IPv4 PI. While the existing PI range is still ‑‑ are in use today.

What we see today and that's also the reason why we're thinking well should we do something. Some of these PI holders are actually becoming members. So that's a bit of an interesting paradox that ‑‑ well the entire idea is you don't need to become a member, while in fact we now see that some of them are actually becoming a member to be able to receive IPv4 again. So that's an interesting paradox.

So where are we today? We see that around 10,000 sponsored end users, they hold around 13,000 IPv4 ranges totalling 12.4 million IPs. It is mostly small, but there are larger blocks in there. This is relevant for the next slide. But more importantly, operationally for us it actually means that even though we only charge €75 per range, the amount of work that we're doing is actually similar to what we're doing for member applications. So, verification, due diligence, permanent monitoring that we have in place. Updating etc., in which there is also now a small piece of additional overhead, which is the effort that we need to make mutations in the sponsoring LIR in this case.

This is sort of the part where you see the imbalance. So factually on the left and the right you see the 2025 income that the RIPE NCC has gained, on the one hand, the PI space on the left and on the other the member space on the right. In which there is what you can see of course the huge difference in funds being on the right versus the left. But also, I think it's also interesting, even though the right is paying a lot more money, the total allocations and the total IPv4 space is actually typically in smaller /24s, while for the PI space you'll see there is/23s or even bigger slots allocated.

So, the considerations here, should the assigned PI exist in its current form or has its role changed?

Should these changes be made so that the policy charging and operations are fully aligned? Is the difference in cost between assigned PI holders and RIPE NCC members fair? So that's also a bit of a question around fairness.

And then finally, should the assigned PI be treated more like allocated resources in terms of rights and obligations? So it's ‑‑ should this huge difference still exist today.

.

Finally, an interesting topic that we will be seeing coming by tomorrow as well. Legacy resources. So, also if you look at legacy as a concept, I think the RIPE NCC is one of the few RIRs in which the legacy label actually apply to the resource and not the resource holder, so that in general makes it an interesting concept while the entire idea initially was let's make all the legacy resources part of the RIR system to be able to increase overall accuracy and make sure that we know who they are and what they are doing, and let's see if we can get them to also use important services like RPKI.

So, if you look at it today, holders can go into a contributors but we are not obligating that. On top, we see that legacy as a resource concept is actually holding very special statuses. So that includes the special statuses in our software, in our systems, but also in our procedures, and it also applies to the work that we need to do to be able to work with the concept in general.

.

So if you look at the distribution. So you can see that one fifth of the total IP assigned in the RIPE NCC is actually of the status legacy. In which another 41 million, is actually not covered by contractual agreement. So that's quite, those are quite sizable numbers.

And this is better shown in a document previously released, a RIPE Labs article released fairly recently, by our colleague, which is really showing what is the state of legacy IP space in which you can really see is that there is quite a sizable amount of legacy not under contract for us.

That being said, there is a positive trend. So you see that more legacy resources are being brought on their contract. As you can see in the graphs that are coming together slowly. But, talking about efficiencies, that we saw earlier today also, is we do see is that the entire concept of legacy resource is actually all the updates that we need to do there is causing more over head. It has to do with finding out who is the original owner? Are they entitled to it? So there is a less of a paper trail that we can utilise to efficiently make a decision if mutations are allowed as an example.

Also here you see similar to what we have seen with PI is that in the end, €75 per range on a contract, but you can also decide to not do it and then you are not paying any fees.

If we compare to the other RIRs, of course we are also looking across the board, we can see that actually we are unique in the sense that also the transferring the resources themselves are actually keeping that special status. So that's completely different to what we see with our colleagues in which the status stays with the original holder or the successor. But as soon as you start transferring it the status is being lost, which makes a lot of sense. But also here, the RIPE NCC part is in the wording right, we apply legacy to the resource and not the resource holder, which makes it an interesting concept on its own.

Also the dynamic makes it, what you see is that we're actually, we have become a safe haven for legacy resources essentially. There is more legacy resources being transferred in than being transferred out of the region. But we are working and it's something that's going to be discussed tomorrow by my colleague Marco in Address Policy Working Group, so we are making efforts to actually gain more insights into who these legacy holders actually are. I think that's also very interesting there was already a discussion going on what should happen with the legacy resources when we talk about the transfers. So I know there is going to be a talk tomorrow by Clara also in the Address Policy Working Group to revive the policy discussion that we had on the mailing list before. So what should happen with the transfer.

So the concept of legacy resources to continue to exist if its current form? Should legacy status be lost when resources are transferred? Is the difference if cost between legacy resource and hike members fair and should legacy resources be treated more like allocated resources in terms of rights and obligations, similar to what we have seen with PI just now.

So, why are we having these conversations right now? As part of let's say new breed of CRO right now I am looking for ways to increase efficiency and reduce complexity, I think we have seen on a discussion in infrastructure we want simplify and be more robust, that's why we are reaching out to you today.

On top of this there is a lot of discussions and conversations going on in the charging scheme. So I think fairness was a very, very important aspect in there as well.

And what we see today actually is that by the concepts that we have shown today is that there is already a question on fairness and should one resource holder subsidize another and in which way, shape or form.

The last one is the due diligence part, that's for us, so, I think looking at our overall ways of working, due diligence become more and more important for us, think about sanction screening, think about knowing your customer. Of course we strife to have a one hundred perspective accurate registry it also means that we want to know who is behind everything and we want to be able to pinpoint that with 100% accuracy.

Coming to a closing, these are very complex issues. We need your input essentially and community input in which we hope to reach consensus on the best way forward and we start discussing in advancements of RIPE 93, with some of the discussions already ongoing on the mailing list and also some of the conversations that will be held tomorrow with more light being shed on there.

(Applause)

ROB EVANS: We are massively over time. And we need to clear this room for the General Meeting that starts in a little over 20 minutes. So, Gert has one point to make, unfortunately other points we're going to have to take to the mailing list. I am really sorry, but we just don't have time at the moment.

GERT DÖRING: Former Address Policy Working Group Chair, so I have an interest in this, and this is the wrong forum. Two thirds of the questions you are asking need to be asked in Address Policy because this is community policy and the NCC is going to act as a secretariat. You do what you are told to do. You are not turning around and tell us, ignore Address Policy because it's expensive.

HANS PETTER HOLEN: So thank you for coming with that argument, Gert, because I expected that to come. And these challenges have been raised multiple times over the last number of years, and that argument has always stopped discussing them at all. So, all of these challenges touches the services provider, they touched the charging scheme and it touched the policies. So we need to find a way forward to discuss both the address policy aspects and the effects of the charging. So that's why we figured out that okay we need to have it somewhere, let's put it here, and then of course policy discussion needs to go to Address Policy, and then whatever we identify of brokenness regarding policy versus charging scheme, let's note it down and bring that to the Board General Meeting Services Working Group. But let's have the discussion and find a better solution than what we have today. That's my intention of putting it on the agenda now and putting Gabor up there taking the flag for it.

ROB EVANS: We really are being ‑‑ we need to clear the room I am afraid for the General Meeting.

AUDIENCE SPEAKER: Five seconds. I want to contribute to that discussion. I note that four of the co‑authors of policy proposal 2012‑07 are still in the room. There were eight of us, four of us are here, we know the background to this. We can contribute. The problem needs to be solved. But it needs to be solved taking account of all the legitimate interests and that's challenging.

ROB EVANS: So, do take it to the list. I really hate having to cut the conversation short, but do take it to the list because we do have to clear the room now for the General Meeting. Thank you all.

(Coffee break)

(General Meeting to follow)