RIPE 91
Main room
23 October 2025
Address Policy
11 a.m.
LEO VEGODA: Hello everybody. This is the Address Policy Working Group. If you were hoping for DNS, it's in the other room. I'd like to welcome you. We have some new stuff today. We have some policy discussion in the second session, and I should introduce Alex, Franziska and me, and Leo, we're your co‑chairs, Alex cannot join us in person, but will be watching from afar.
This is a hybrid session, as Alex is demonstrating. If you want, you can participate over Meetecho as well as in person. When you speak in this session, please give your name and affiliation. We have a Code of Conduct. And it's designed to make everyone feel welcome. It can be distilled down to please treat everyone else with respect, be polite.
We'd like to thank our scribes AUP our stenographers, scribe from the RIPE NCC and our stenographer, Mary, thank you very much, we really appreciate your work, it definitely makes life easier when we go and look back at when things happened and what exactly was said.
Mentioning the scribes. Minutes RIPE 90, they were published in June. There haven't been any comments, so he unless anyone comes to the microphone or puts their hand up on Meetecho, I move that we accept them as final. No one is moving to the microphone, so let's say that they are final.
We have two sessions today. We are in a different slot, as you probably noticed, we have historically taken the 9 a.m. Wednesday slot, and it's now it's after the coffee break on Thursday. We are coming back after lunch on Thursday, that's when the policy discussion will be happening. In this session, session 1, we have an update from the ASO AC. Policy update from Angela. Ilke will be giving us some history of policy discussion. And then Marco will talk about Registration Services and update us on that.
After lunch, when we come back, we will be having discussions about increasing the side of IPv6 allocations, or the default IPv6 allocations up to /28 without needing justification. Revising the criteria for assigning ASNs, making it a little bit easier to get them. And revising the criteria for IPv6 PI. Then there will be an Open Mic slot. One of the things we would like to hear from you is what do you think about this new session time being before and after lunch? That is just as important as all of the policy discussions because of course, if people are more or less available, that makes a difference.
So, I think that's it. Franziska will be moderating the discussions in the room, I will be reading stuff out from Meetecho, and we can move on with our first agenda item, which is the ASO AC update. So Herve, thank you.
HERVE CLEMENT: Good morning everyone. So, we are last speakers normally, this session is on Wednesday morning, so it was decided to have a little revolution regarding the agenda of this meeting, which is good, and at eleven o'clock we have more people in the room, which is good also.
It's our usual presentation regarding the activity of the NRO NC, so the people coming from the community of the different regions to fulfil the responsibility of the addressing supporting organisation Address Council.
You have a lot of presentations from the ASO currently because of the ICP 2 work we are currently performing. There has the BoF on Monday, there was a lot of discussion on that. This afternoon, during the Plenary, it will be the presentation about the outputs of this BoF. And this presentation is more about the current activities of the ASO AC, but I will speak just a little about the ICP 2 as well. And with that, of course, I am not alone within the group, there is also Constanze Buerger and Andrei Robachevsky, so if you can stand, so people from the RIPE community.
So the NRO is here, as I said, a number of Council who serve as the ASO AC, so the ASO AC one more time is one of the organisation of the ICANN, two parts, first the NRO EC, executive committee, which composed of four Comm directors and the NRO NC.
You know very well, as you attend in every meeting, you attend every years meeting, every RIPE meeting, it was established by the ICANN, to advise of the issue related to Internet number resource policy. We are normally 15 members, and you know also that AFRINIC have met issues who made it impossible to select somebody in the Council. Good news, there has been an election in Africa, members were able to vote for a new members to the Executive Board of the AFRINIC, now the AFRINIC Board is complete. And we hope that first the Executive Board will be able to appoint at least one member to the ASO AC, will be good, because we could have an entire representation for the discussion into ICP 2 of course.
And in each region, we are three, one is appointed by the Executive Board of the Internet registry and two of us by the communities.
What we do. We advise the ICANN Board of this matter, along with the NRO NC. There is the overseeing of the global policy development process, that's a policy common to every region, and dealing with the link between the IANA, so managing IP resource addresses for the whole system. So between the IANA and the regional internet registries. There are around 20 directors of both within the ICANN and the addressing organisation is responsible to appoint two of them for the seat 9 and 10. Seat 9 is filled by Alan Barrett, was a CEO of the AFRINIC before, and seat 10, everybody knows is Christian Kaufmann, who was a Chair of the RIPE NCC Executive Board also.
We meet each month, and the one important thing is that our meetings are open, so you can go to the ASO AC website and to see when is the offers month. And we try to meet on site once a year, generally during the first ICANN meeting of the year but because of the ICP 2 work we meet more often than that.
They are the people, nice people, who composed the NRO NC currently.
In 2025, so we had this work about the elections for the seat ten and we appointed Christian Kaufmann for this function. There is an ongoing work to follow the discussion within the different communities to see if there will be potentially a global policy, and of course we conduct the ICP 2 review process.
Seat ten elections, I won't go back because it was during the first semester. And Christian will start his new term next week during the ICANN meeting which is the General Meeting ICANN style.
You have the link to the process.
It's important for us, the work, and for every organisation within the community, the global system is transparency. As I said, we try to have most of our meetings open and transparent, with minutes of course. And even the annual meeting at the ICANN is open to observers, except the closed session. We have a mailing list. As I said our monthly meetings is open to observers as well. The meeting calendar is available there. And so ICP 2, so we report about the ICP 2 work. We have closed meeting out there to conduct something which will be at the end public.
And we are in consultation about the current version of the document. This consultation will end November 7th, and we will meet, which is a LACNIC place, we will meet in November of this year to review the consultation and it will be this one, a closed one.
So, I won't go into the details in the ICP 2 review because we had, in every region, a lot of presentations about that and we presented that in the BoF, but just background information, timeline on operational information about that.
First, what is ICP 2? So ICP is for Internet coordination policy. It was a document created and accepted and in the beginning of this century, and it was a list of the criteria for establishing new regional internet registries, for example recognising the regional internet registry as to be sufficiently large, it has to support the local numbering community, it has to be capable in terms of technical stuff. You have the link to this original document there.
The timeline, so you know all that the RIPE NCC was established in 1992, followed by the APNIC from Australia, India, Japan, etc. In 1993, then the ARIN for the American region, in 1997. And then in 1998, it was the ICANN, who was created. The ICANN adopted this famous ICP 2 in 2001, and the ICP 2, two additional regions have been created so the LACNIC first in 2002 for middle and South America, and in 2005, AFRINIC for Africa.
Why did we ask to revisit ICP 2? Because, as you can calculate, the ICP 2 is now 25 years old. It's a quarter of a century. Of course you can imagine that the Internet has changed since then. And the relationship between the region and the ICANN has changed also since then.
And the other aspect that the current document, the 2001 one, was not very explicit, it was just criteria to establish, but there was no mention about to use this criteria for the current life of a regional internet registry and in extreme situations, there could be used for the de‑recognition of a regional internet registry, so it's important to have all the aspects specified in a document.
Okay. Because of these questions, the NRO NC, so the group of directors of the regions asked us in October 2023, two years ago, to review this document. First we have a short work consisting in reviewing the draft procedure of validating addressing on the ongoing RIR compliance. It was done and the most important part of the work is to to update this ICP 2 and the idea is to strength generally the global system and to make the regional internet registry system more accountable to the Internet community. That's the reason why, so we need to have a lot of discussion within the group and with the communities to have something acceptable globally.
After this request, so, we need finally one year to publish a first document, which was a set of principle which could be in the current document we are now in. This document which was called the principle document was put in public consultation, regional consultation and ICANN consultation at the same time, to have the most communities as possible. These documents was under consultation between October and December 2024. Then, the group of reviews the community feedback and was able to draft a document which is called ICP 2 principles consultation report, and there was another round of consultation between February and April 2025. No, it was ‑‑ so we published in April. This document, sorry, there was a consultation, and then we published another document in August 2025, and it's this document, the second draft document which is under consultation currently till the beginning of November.
Okay. So, to be more explicit, because when I was saying that only it can be a little messy, the wording, but you can see that we are now on the blue, under that blue square, which is the second public comments on draft, we think that, we hope a final review will be after that to be potentially have an approval of adoption of the document but of course there is steps have to be taken to be confirmed because of the output if there are a lot of outputs we will see how to proceed. It's not definite.
So there are very easy ways to go to the document and for us the community to read them. So there is a QR code to read the document. Normally this slide should be before the other document. You have the document to be read, which is under be consultation, but to enable the community to understand the document we have added, with the help of the communication team of the different region also, we have added a document which explains the changes between the two versions of the document. We have added a document which is called a summary of changes of rationale, because regarding all the outputs we had from the different consultations, there are comments we have incorporated in the document, others we have not incorporated because it was out of scope, and in the rationale document we explain why we have not included that.
There is, like every discussion in other topics, FAQ, you can see, and very recently, two years ago, there is now a preliminary assessment document just to explain more how things can be implemented. So it's a new document. You can read also.
Now I will go back to the presentation. So of course everybody knows what is a red line document, so it's a document to explain with colours what has changed or not. The rationale in the new document, for example we speak more about recognition, so with the improvements we explain the background, we explain the changes, so what's the type. It's an extract from the principle document.
And so to go to the consultation, you can go there via the QR code and so you can add command very easy for the RIPE community so you go to the RIPE list, it's a mailing list you know very well, and I think it okay, and I have 15 seconds for the questions.
(Applause)
FRANZISKA LICHTBLAU: Actually, we have way enough time for questions, so, everyone who has questions, please come up to the microphone or come to us on Meetecho. Comments, questions...
RANDY BUSH: Randy Bush. RGnet, IIJ and Arrcus. Brilliantly done, you folks have made significant progress since Lisbon, and I think the three of you deserve our deep thanks. Thank you very much.
(Applause)
AUDIENCE SPEAKER: No question but a comment. My name is Dan, I was with ICANN until October. So, a couple of comments from that side.
I think from the ICANN perspective, the work of ASO council is important. ICANN is kind of the route of majority of our whole ecosystem and the addresses are hugely important part of that. There are a number of things there, not least of them that ASO is sending two Board members, and we have Ron here who is a Board member serving with me, and now we have two extremely capable Board members coming from this environment, I think this is very important for ICANN. I just wanted to say not anymore in the ICANN role but I know that ICANN and the Board is grateful. But also, the teams that are related to IP addresses are sometimes less, have a less bandwidth than the whole ICANN system discussions even though they are so important. I think ICP 2 is a good example of something that could and should be used by this community and the other RIR communities to bring more attention in the ICANN environment. I think this is something that we need to recognise, but also for ‑‑ because of the importance of this document and what is happening, to bring those discussions not only here but as you mentioned, also to discussions within ICANN to strengthen the message from this side. One more thing, there is also ‑‑ I am a little bill surprised not to see more discussions about the current discussion on the governance of the route server system, because RIPE is obviously route server operator and all of us take the route server system often for granted. There were very good technical discussions here about the software and things but the governance of the whole system is not less important than the ICP 2 discussions and I just want to invite this community to take a more active approach in this because it will be important and there are geopolitical issues in the route server system. Thank you.
FRANZISKA LICHTBLAU: Okay. Do we have anything online?
.
Okay. Then I think the NRO NC can be met at the Meet and Greet table today.
HERVE CLEMENT: We are meeting ‑‑ normally we are around, so if you have any questions, so don't hesitate. Or Constanze or Andrei or me to ask questions first, so one more time, so it will be short presentation this afternoon. And for information, a few of us will be present next week in ICANN in Dublin, so it will be the opportunity to discuss with other communities.
FRANZISKA LICHTBLAU: Thank you.
(Applause)
.
So the next talk is from Angela.
ANGELA DALL'ARA: So good morning also from me to everybody, and I am here for the traditional update that I hope can help you catch up with what happened in the policy world in our region and in our regions.
And also to follow‑up on the policy documentation review we spoke about during RIPE 90.
So, happened in the RIPE region? I am happy to tell you that we have a new policy. This policy was discussed in the Routing Working Group. It's giving the RIPE NCC the mandate to revocate persistently non‑functional delegated RPKI CAs. And is already published, this new policy, the RIPE document is 847, and it's not listed in the implemented policies, but when you look at the policy proposals that originated this policy, you can see that's under implementation. I suggest you to follow the suggestion in the Routing Working Group because I expect that my colleague Tim is going to deal with the Working Group in some details before the implementation and something is going to also of course be published on our website.
And also, the same proposal you will see also later has been accepted in the APNIC region, and so it looks like is going to be a new service provided by multiple RIRs.
Then, as Leo said before, we have the policy proposals, and we will hear later on in the second session from the proposers what they are about and regarding IPv6 address distribution and usage, both allocations and PIs, and one is regarding the criteria for the assignment of AS numbers.
I must say that unfortunately we didn't manage to publish the proposal regarding the API assignments, but thanks to the proposer this is already been shared for comments, feedback, by Clara in the mailing list, so you can have a look in detail at the full proposed text; that will be published and we'll start the PDP after the RIPE meeting.
The other two are already in discussion phase. So, I repeat my traditional appeal to you: Please read the proposal and share the feedback on the mailing list because the proposer in that way can understand if this is, these proposals are responding to your needs or not, and if they have to change something.
So, the discussion phase for who is not familiar with our PDP, is the moment in which the feedback can help to change the tech, to make modifications, make questions and so on. So I invite you to participate.
Then there will be a review phase, and that review phase will require you to even repeat your comments, because those comments are the ones that are going to be taken into consideration by the Working Group Chairs to decide if there is consensus or not on the proposal.
So, I hope to see many comments on the mailing list.
So, what happened in other regions? So let's start with AFRINIC. As you know the Board has been reconstituted. There were some proposals already accepted, and one was under implementation. I have heard from my colleague in AFRINIC that the testing of these RPKI ROAs for unallocated and unassigned AFRINIC address space is in the end phase of testing, and probably we will see it implemented very soon.
For what is regarding the other policy proposers that were waiting for rectification, we will see what the Board will decide to do. And they will call soon for the election of, or selection better to say, of Working Group Chairs for the policy discussions.
And we will see if people will be invited to resubmit the policies, and of course they will be invited to submit new ones if needed.
The transfer policy, the policy compliance dashboard that is informing members if they are compliant with the policies in their portal, and new validation and verification rules for abuse contact.
In APNIC, as I said, there is this policy that we just accepted, that is also awaiting implementation.
Then there is a policy that has been accepted that is removing some contact details from bulk access. So ‑‑ and is also requesting, let's say, to specify who has access to this bulk access. It's not removing, let's say, the current contacts for the normal access to the Whois.
And then this might be interesting for you: Publish statistics on directory service usage. This is going to publish the activity that has been done in querying the Whois service. It's providing some details about who is accessing, how often and with which methodology. So it's going to, let's say, be more transparent about the usage of the service.
Then in ARIN, the Advisory Council is always very active and they have two recommended draft policies. Recommended draft policies have already been promoted to be discussed as last call in the upcoming ARIN 56 in Arlington, it's going to be in a couple of weeks. One is clarifying when a member that is receiving or an entity that is receiving a transfer needs a new registration service agreement. And the second one is clarifying, let's say, that the requirement for IXPs, because this 4.4 micro allocation section is regarding reserve the pool of resources for critical infrastructure. So, there are some clarifications about how to use this pool.
Then, the draft policies that are, that it's possible to discuss them much further. I think the most interesting ones for who has resources there in the region and might be interesting to participate in the discussion is going to change the minimum size of resources used outside of the region from, let's say changing it from /22 to /24, also because some organisations now have smaller allocation size.
And then to specify, the last one is to reserve the space that was testing it for the transition to IPv6 for use within the ARIN region.
The other two fix formula, don't ask me to understand the formula, it was super complicated, I managed, but I found out that there was some inconsistencies and there is another, let's say, amendment to match examples in another section of the manual.
There was ‑‑ there is also discussion about clarifying ISP and LIR as a definition term in the policy manual. I see that one has some difficulties to find an agreement in the mailing list.
I added the link to a very nice blog that is giving a sort of summary of what the policies wanted to achieve and give a very short summary about what is the current situation and the change that is proposed.
In LACNIC, we have two policies that are ‑‑ that have been been presented at the last meeting and are waiting for the decision about the consensus by the Working Group Chairs. One is about temporary transfers, and the other one is regarding the distribution of resources to natural persons. In our region, this is possible, and natural persons can receive resources. This proposal was also presented in ARIN, but didn't receive, let's say, the consensus from the community and it has been abandoned. So it should be declared in this space that the consensus or not on these proposals.
Then under discussion, there are two proposals to give priority in the IPv4 waiting list to organisations that have deployed IPv6. And another proposal is regarding IPv4 sub‑assignments to third parties. It could be also seen as a sort of connection with temporary transfers. Let's see how the discussion goes.
As usual, you can find all the information on the websites of other RIRs, and I remind you that there is a document that is not exhaustive but can be useful to compare the policies in different RIRs on the NRO website.
And then I have beautiful news, I hope you like it. We have a new page, for me it's nice, because the discussion ‑‑ I was asking during RIPE 90, what would you like to do, because we received some feedback it's difficult to find the policies, I want to know which policy applies to my requests, where do I find it? And we had in that time the policies listed by numbers. So, by update date. So the last one that was updated was on top, but the topics were a bit mixed.
The slide is really small so you can't read it because I want you to go to the page and check it, because otherwise it was not fitting in the slide, so you can imagine. Now there is a division between regional policies and global policies. I remind you that even connecting to the ASO AC global policies are the policies that are defining how IANA is distributing resources so RIRs, so they are not updated very often, as you can imagine. But now we have, let's say, we are grouping the policies per topic. So you can see that for example for all your resources, you have a collection of policies, and I hope this is useful to navigate a bit more easy the page and find your policy.
Of course if you have questions, if you have feedback, I am happy to receive it, here or in the corridors or via e‑mail, you can write to me.
FRANZISKA LICHTBLAU: Thank you Angela.
(Applause)
First of all, thank you for putting in the work and helping us making policy more accessible because we keep having these discussions always, so I think that is already a good step in the right direction. We have questions. I know we have Jordi on Meetecho, let's start with the remote participant.
JORDI PALET MARTINEZ: Hello Angela. Just one small clarification. There is one policy in LACNIC that you are missing, it's LAC 2025‑2. It's very, very close to the one for allocation resources to critical persons, natural persons. The only change is that the actual policy manual in LACNIC is only allowing to allocate resources to organisations, so even not natural persons with economical activity in theory should get resources. So LACNIC of course is doing that, but somehow against the literal reading of the manual. So I put a proposal to resolve that. So it's no change in the actual, let's say, behaviour of LACNIC, but just to clarify the situation. I just wanted to make sure that that's clear but it's too close to the other policy proposal and sometimes it gets confusing. Thank you.
ANGELA DALL'ARA: Thank you, Jordi, thank you very much. So my fault I missed it.
AUDIENCE SPEAKER: Dave from APNIC. I just want to highlight something about prop 161 that reached consensus, because it will affect people in this room. One of the things that we're doing with implementing this policy is we're going to be revoking everybody's bulk Whois access. What that means for you is you are going to have to resign an updated AUA for access to bulk Whois, we're not doing this tomorrow. There'll be plenty of notice, but that's what we'll be doing and it will be regular resignings of this agreement.
ANGELA DALL'ARA: Thank you, Dave.
FRANZISKA LICHTBLAU: Do we have more online? I don't see anyone raising their hand. Do we have something in the Q and A? No. Okay, then thank you very much.
And now we don't only have a new time slot, we also have a new agenda item in the first session. Our next speaker is Ilke from the RIPE NCC and our community is documented by ‑‑ is governed by documents and she took the time to have a look on RIPE document history and the development of this community in connection with those documents. So, we are curious what she found.
ILKE ILHAN: Thank you. Hi, I am Ilke, I am a business data analyst at RIPE NCC and I have a talk on RIPE docs. And more specifically how the RIPE docs represent the evolution of our community as well as the NCC.
RIPE docs clearly keep the history of the thing of ours that has been going on for several decades. For those of you who have been been around for a good portion of that this might come as some sort of a nostalgia trip. And for those of you who are fresher in the community, I think this is going to be some kind of a nice fun intro to the many many docs that we have.
Either way, I think I have some different interesting perspectives I can share you on the RIPE docs with the help of some data visualisation.
A quick intro to the RIPE docs. They are the documentation we have on what we do, how we do things. We have different types of docs, depending on the purpose of the doc. Currently we have 847 RIPE docs. Two of them were published last week and they are missing in the rest of my slides, so whenever you see 845, just keep in mind that we actually have 847 as of last week. And if you are curious, you can find them all in the RIPE document store. I have been spending most of my time online lately, so I totally recommend it.
Before I move onto the more recent docs we have, I want to mention a few of the earlier docs to remind you all where we come from. RIPE 001, definitely deserves a mention. The first RIPE document written in 1989. It's the RIPE terms of reference. Simply laying out what RIPE is, what RIPE does, what RIPE is for.
Two years later, we have RIPE 35, it's the first RIPE NCC activity plan written by Rob Blokzijl, and here I want to share a screenshot from this doc with you, this is the section where he talks about the activities the NCC should support. At number one we have keeping the RIPE document store, which is the first mention of the doc store in the RIPE docs. And on number 3 it reads "RIPE meeting attendance is expected to be in the order of 40 persons in the near future."
Yeah, I also find that amusing. When you are already far in the future, it's nice to read this kind of stuff.
One more doc I want to share comes from two years later, it's RIPE 80, entitled "Hotel List Amsterdam". You can expect that it's a list of hotels in Amsterdam. So, clearly things have changed and understandably so, all of these docs were written more than 30 years ago, but it's not just us that changed, it's also the docs that have changed, what institutes the doc and how we write the docs have also changed quite a bit in the more than 30 years that has passed.
All of that is an anecdotal intro, but as a data person I want to confuse you with lots of data points. So, here we go.
Here, you see all of the docs. Again missing the two that were published last week. Each box represents one RIPE document. We have all the way from RIPE‑001 to 845, and they are coloured by the type of document they are. They look very independent and separate from each other, but they are actually pretty connected as one doc updates the other they have these like relationships. So you can imagine like a lot of lines connecting them. But you can't see them here.
Now, clearly there is history in these boxes, but I'm also going to argue that there is history outside of these boxes. Either way, it's a quite complex history when you consider there are so many boxes. So, let's focus on the active policies that we have.
Currently we have 17 active policies but one of them was published last week so 16 active policies on the screen now. I plotted them on a timeline. So each of these rectangles is one policy. They all reach the right side of the slide because that's where we are today. Some of them are longer, those are the policies that were published earlier, and the shorter ones are more recent policies. But most of these policies are actually updated earlier versions of themselves, which I see as like doc relationships. They have predecessors, successors, there is like branching ins and outs, which I see as families, and when we plot those docs, it reaches all the way back like this, and creates this view. So all of the docs that they are related to on the timeline.
It's still kind of complex, so, we can focus on the family at the top, which I will very unofficially call the most important family in this group. So, here we have the family, a family of docs. Again on the same timeline. Each of these rectangles is a RIPE doc. They start in the when they were published, and go all the way until they were obsoleted unless of course they are active documents in which case they reach to the right side of the slide.
I want to walk you through the timeline. We have RIPE‑065, it's the oldest doc in this family. It's laying out the Internet number registration procedures. Later on it evolves, merges with another line and creates RIPE‑185, it's a pretty comprehensive document covering multiple topics which must be why you decided to branch it out into four lines of documents and created these lines that reach until today. The three lines on the top are policy lines which eventually created the three of the active policies that we have today. And the line in the bottom is a procedure line for changes in the registry.
This is Address Policy, so, I want to focus on the IPv4 Address Policy line. As you can see there are a lot of white lines. Those are the borders of the docs, it shows that you were busy and updating this policy quite a lot. If we focus on several of them, you can remember that we had some noteworthy docs here. We had 509 when we introduced a /22 per LIR policy. 604 came with a lot of discussion, the no need policy, removing the need base allocations. Later on 649, it's the 24‑month wait period before you can transfer resources. 725, where we introduced the waiting list and the /24 per LIR after the waiting list.
That's what I see when you are close and focusing on threes docs separately. When I take a step back, I see kind of a different picture, a big picture, that makes me think this family of docs are kind of representative of our evolution. In the beginning, we have documents that are laying out things, how we do things, establishing all the things that we're doing. Later on things get more complex, more detailed, we branch out documents, we refine them again and again. And more recently, things have been getting calmer, so it's another box in this view. This is a view looking at one family of RIPE documents.
Documents are not the only thing that we have. We also have Working Groups and mailing lists. Here, I want to focus on three of them. Again, they are plotted on a timeline. Each stroke here corresponds to one e‑mail that was sent to one of these mailing lists. So, if you see more orange, there are closer together, it means there is more traffic around that time in that mailing list, and if you see a more white scattered around view, it means it is a relatively quieter time for that mailing list at the time.
So, what happens here is in 2003, LIR Working Group was split into Address Policy and NCC Services. Before it was split, you can observe that it was getting quite busy, and this is probably the reason you decided to split it into two different Working Groups. This was also around the time when we have RIPE 185, the comprehensive doc that was split into four branches.
After the split, we also see that Address Policy has stayed busy for quite some time, as you were refining the policy. And again, we can see a similar kind of eras or evolution, similar to when we were looking at the family of docs plotted on the timeline as well as now when we look at the traffic on the mailing lists plotted on a timeline.
More on Address Policy. Again this is a timeline for the traffic in Address Policy mailing lists. The orange line is the number of e‑mails that were sent to the mailing list over time. It's irregular. We have several peaks, four of which I identified to be caused by policy proposals that you discussed here. So, some people author docs, but more of you are actually discussing them on the mailing lists.
And for these four, two of them were actually accepted and became policies. Two policy that I mentioned earlier. And the other two were withdrawn. So, we say that there is history in the RIPE documents. But people on the mailing lists also shape this history by discussing these policy proposals and also rejecting them.
After these peaks, again we can observe a calm period in the traffic here as well.
Although it's not all calm, because remember all of the policies and their families plotted together, all the way in the bottom, there is a voluntary transfer log that was published in 2023. It suggests that you act when you see a need to do so. It's not always calm.
And that was just the policies any ways, there are different types of docs and they are going on. We have all these colours of boxes, and I want to highlight several of them for you.
For example, these are all the informational RIPE docs that we have. As you can see, they are mostly on the top. It's mostly more in the beginning of the community as we were laying things out and explaining. If we focus on the policies, you'll see that they are mostly in the middle scattered around, probably also with the contributions of this Working Group.
And lately, we have more governance docs, and here I want to remind you once again the first RIPE NCC activity plan where Rob expected a participation of 40 people at the RIPE meetings, and here we are now, so clearly we have grown quite a bit and it comes with more responsibility in a way, we probably cannot rely on mutual understandings of what we do, how we do things as easily as we could 30 years ago. So, we need strong governance docs to clear things up, to avoid misunderstandings, make it easier for newcomers and overall look more professional. It all looks, it all suggests some kind of a maturity as a community, and even more meaningful when you think that they are mostly approved by the community.
But again, docs are not all of the story, because between the docs you are creating peaks on the mailing lists like we saw, coming up to the mic, rejecting policy proposals, and overall adapting to changes as a community.
So, I want you to leave with you some of these thoughts. From this presentation I would say along with the mailing lists, RIPE docs represents the evolution and history of our community. We see a certain trend in different types of documents, more informational as we were establishing, more policies as we were refining how we do things, and lately more governance as we are clearing things up a bit more.
Speaking of policies seems we reached somewhat of a plateau, which is also due to the IPv4 run‑out, but we have proposals on IPv6 and ASN, so, things are going on.
Understandably, there is more traffic when we were setting things up and less so when we stabilised, although that comes with exceptions because it seems like you act when you see a need to do so by writing docs, discussing docs and even rejecting docs.
Before I welcome your questions and comments, I want to say that I am intending to keep going on with this analysis. Overall on the docs not necessarily about policy, so please tell me what you find interesting about this topic, what you would like to see in an analysis, and maybe you have things that you can share with me that I wouldn't know that you can tell me with your experience. So, please let me know I'll be around and also my e‑mail address. Thank you.
(Applause)
FRANZISKA LICHTBLAU: Thank you very much. That is excellent work. I already got comments in the chat from the room that you are really ‑‑ that your analysis reflects what people actually felt back then. And I think Gert found themselves in these slides, but let's open the floor for questions.
BRIAN NISBET: Brian Nisbet. As a lapsed historian, this is wonderful, thank you for this. I think that as you mentioned yourself, this is exactly the kind of thing that is a great introduction to the state we are in now as a community, as work, and I think something that would be great to see shown to newcomers really clearly and obviously, and I know I will be sharing this piece. And I think, you know, it is a fair reflection there, I think the piece around also the fact that we don't throw documents away, we update them, we keep them, I know that was being talked around ICP 2 and that document store as well, I think it's a fantastic example of archiving, which is of huge use to not just to us but to people who will look in times in the future and go "Why the hell did they do that?" So thank you very, very much.
TOM STRICKX: This is amazing work. I love it. It's the best thing. I think it's amazing that we're able to kind of just look back at things and acknowledge what has come before what has come before. It's amazing that you are doing this. Thank you.
I would love to see as a follow‑up that we do this every year, at least once. I think that would be awesome to just kind of hey, this is a thing that has been happening. Maybe a suggestion to kind of look at is look at Members Discuss and see how conversations how conversations go from initiating at Members Discuss and then eventually moving into either the individual Working Group mailing lists or conversations at RIPE meetings or policy documents that come out of that I think would be really interesting analysis to come out of this. Either way this is amazing work and I appreciate it, thank you very much.
PETER HESSLER: Peter Hessler, I am the co‑chair of the Database Working Group, and I want to comment that while we don't publish policies per se, a lot of the work in the Database Working Group is based on what we call NWIs, numbered work items. So, I wondered if you (1) included that in your current analysis and (2) could you include that in your future analysis?
ILKE ILHAN: I could look into that, I cannot answer right now, but thank you for the idea.
SANDER STEFFANN: Sander Steffann, ex Address Policy co‑chair. When looking at that timeline I suddenly realised that that period with all those changes exactly overlaps with my period as a Chair, and I just want to leave it to the room whether that's a correlation or causation.
AUDIENCE SPEAKER: Will. I am just wondering ‑‑ so I see that in our way to do things in the community we have a really good way to archive all those documents, which is really great and really good. I was wondering if at large in other communities, maybe we should have a way to be sure that we do keep track of those documents and we don't lose it, because it's part of our history, and I think we need it to keep that on the long run. And I am wondering if you had ideas or views on how we could think about a good archiving method for all those documents, which are not in place anymore also in our community.
ILKE ILHAN: It is in the document store, even the obsoleted docs, so you can find them there, but...
AUDIENCE SPEAKER: Hisham, RIPE NCC. Thank you, Ilke, this was useful. You asked about future work that you can do here and ideas, and I am pitching this not just to you but also to the room. Jan and I have been talking about a BCOP about how we do decision‑making and consensus in the RIPE community. I think with this work, we can actually put out something really useful which, with my public policy hat on, is very, very useful, not just within this community but externally as well.
FRANZISKA LICHTBLAU: Do we have questions online? No. Again, thank you very much also for the very polite way you described the current phase as calm, because I mean this makes our life so much easier compared to what you have been going through, declaring consensus about, around a couple of e‑mails makes our life easier, but for me this was very reflective to see that we may actually want to see what we do about engagement and getting people back to policy discussions, not necessarily randomly proposing things but at least for the things we have actually really engaged with people and I think this work well shows us a little bit where we came from, where we are, it's highly appreciated. Thank you.
(Applause)
.
Now, the next talk. We have Marco.
MARCO SCHMIDT: Good afternoon. This is Marco Schmidt, I am the manager of the Registration Services, exactly twelve o'clock, and I have to get used to this new slot, but I give you the regular update.
One maybe down side of this new slot is I am aware that I am standing between you and the potential empty stomach that you want to fill at lunch break, so I will keep is concise, because I really actually would like to get your feedback on the topics that I want to talk about at the end of my presentation. I want to talk first about IPv6 assignments. Then about legacy without contract, it's a follow‑up from the last RIPE meeting. Another idea how we can improve resource holder information. And want to close with a new request that is coming soon.
One advantage actually of this new slot is that we are just after the IPv6 Working Group, and actually if you were here in this room in the morning, Jen gave a presentation exactly about this new deployment mechanism that existed in IPv6ing that seems to gain traction. So I don't have to worry to try to explain something technical, where I'm definitely not as good add Jen, so if you are more interested in the technical background, please look up her slides. In a nutshell there is an IPv6 deployment mechanism taking traction where devices will get a /64 sub‑net, each device. And why this is probably good for IPv6 deployment, it's something that could potentially conflict or should be considered for the v6 policies.
First off, so far there is a general understanding that a /48 is large enough for basically almost every end site because you can grow there a lot. However, if you think about a university and they are looked up here in the University of Bucharest, there were around 30 thousand students, if this university wanted to roll out this prefix delegation, and they have 30 thousand students and they have a laptop, they have a mobile, they have a tablet, it would be easily a hundred thousand /64s, which is already 47. That's in itself not really an issue. It's possible to give large assignments a /48, but currently there are additional justification requirements implemented in the RIPE policies for larger assignments.
The more serious impact is actually for IPv6 PI holders, because you cannot do sub‑assignments in IPv6 PI, and on the top you'll see the current wording in the policy that states really clearly it's okay to give a single IP address to a client, to a guest and so on, but you cannot give prefixes. So basically, if an IPv6 PI holder would want to deploy prefix delegation per client, they would violate the current IPv6 policy.
For PA users, it's ‑‑ there is a solution, there is this AGGREGATED‑BY‑LIR, so, the named university to create such an inet6num object and then indicate that everybody gets a /64. Again, I think that is not just limited to a few universities. You can think about an airport with a guest net, a shopping mall, also large companies, so it's really something to be considered, and if you think that that is something that a protocol and normally there is a bit of separation between the RIPE community and the protocol community, I want to say, but if this is something that should be considered, because if there is a feeling well the policy is fine, we keep the current rules, it basically prohibits IPv6 PI holders to use this new deployment method, which is quite some interference with network design. Of course we then also have to be clear what guidance, for example, our training department, also you, give to enterprises that want to, might want to deploy this mechanism.
On the other hand, if there is a sensation, a feeling that yes we should allow it, there is of course the risk that in Internet service providers think that's perfect I connect all my customers with a /64 to the Internet which goes quite against a lot of recommendations how to give broadband customers Internet connection via IPv6, and also, in the IPv4 we have a similar story in the past before the run‑out, we had quite some ISPs saying it's much cheaper to use PI to connect all my customers with it. There could be a similar challenge coming up here.
And if you feel there is a change needed, how to do it. So, policy proposal to maybe review the sub‑assignment definition. Or should be the, yeah, Registration Services just a bit more relaxed or do looking at the wording of the policy that would mean we have to turn a blind eye.
So, I'm really curious for your opinions about that .
.
I am also curious for your feedback on the following topic, which is about legacy. From IPv6 we go way back into the past because IPv4 and the AS numbers interest been handed out before the RIPE NCC exist, before the current RIR system exists and this is usually referred to as legacy resources. And in 2014 a policy was accepted, reached consensus, what service does the RIPE NCC provide to such legacy resource holder and what contractual relationships they can have. They can have a direct one, sign a contract with the RIPE NCC, they can have an indirect one, sign a contract with the member that sponsors them and they also have the option for no contract, AUP I want to focus on this last group right now. So we currently have around 2,400 IPv4 ranges. And in our internal records we see it, there are used by 1,600 holders around putting this in the bigger perspective, this represents around 5 percent of all IPv4 space that we have in our region.
And the most important challenges there, we don't really have, at least in the public, verified data. There is nothing verified in the RIPE Database. I am putting here an example, a real example. So if you look at it, you don't see much. You probably, if you are a bit experienced in the RIPE Database, you can get out some contact information but you really don't know who is the resource holder of this legacy block.
This is ‑‑ during the last RIPE meeting in Lisbon I explained it creates some challenges. First of all, the accuracy is really not there, so basically in one of 20 IPs that are searched in the RIPE Database, you don't get verified information.
It impacts a lot the RIPE NCC operations, not just in my team that have to deal with some of these resource holders want to make and update or transfer we have to go back in time to get the documentation, but also for or software engineers that have to develop a lot of additional steps to for example just publish the country code for the entire transfer for legacy resources. I presented at the last RIPE meeting and there was a general feedback that yes, that is something that should be looked into, please come up with some potential solutions, but please also keep it for now in the current framework.
And so, that was a challenge, and we tried to keep the balance. And I want to propose right now here initial concepts. I want to really stress that. There will be corner cases, we also really don't have plotted the timeline so on. We want to involve you at this early stage if you think we are going in the right direction and get guidance from you.
So the idea that we are having is that we would contact all those had 1,600 resource holders of legacy without contract and ask them to verify if the data that we have in our internal records are correct, or if they can document that the current holder or user of this legacy resources actually got it from the resource holder that we have in our records.
And we will get some responses that will confirm that and of course we will get people that might not respond or that they cannot document the changes to the current user.
After a certain period, we would then add to every, after each of those legacy objects, resource objects, and organisation object. And so‑called co‑maintained object like we do already now for all other Internet number resources. Co‑maintain means that certain attributes are maintained by the RIPE NCC, and for the ones that we could verify we would show who is the verified legacy resource holder. We also probably would ask that it has been verified. And then of of course you have all the regular contact information maintained by the resource holder. Like basically all the organisation objects that we have right now. Of course we will have the ones that did not respond or couldn't verify, there we cannot publish an organisation name because it's not verified. We would make that clear, we would also make a comment there that it's not verified, and also maybe give some information for the resource holder how to verify it. And then also see what will be the reactions from them. And somehow, this would work like a, I want to say quality mark, because we even get occasionally contacted by some legacy resource holders and ask us, can you please confirm to this potential buyer that I am the right resource holder. And currently that is not really possible.
I see a couple, actually quite a lot of pros, but also a couple of cons on that one. In this way we would really show to the public the most recently verified legacy resource holders. It helps to clearly identify them. It also protects those resource holders, because its clear that they are not just somebody who gets access to the maintainer can change all the information.
It would ensure consistency with all the other Internet number resources that we are maintaining, which also helps, by the way, a lot with our software development and it also would help with processing requests from these legacy resource holders.
The downside would be that in this approach, we will not manage to clear all 2,400 resources of them because they simply don't respond and the remaining ones still would be vulnerable as of today, and some legacy or resource holders might be a bit reluctant to change because we all are sometimes a bit conservative.
So, also on this one, I am looking for feedback.
As I do, for another idea that we are having a bit, it was boiling in our minds for a while and recent discussions on the RIPE list brought it up again.
How can we improve information of all the resource holders? I put up here the organisation object of the RIPE NCC, Because I know we will not object to publish that one. And you see here what I circled as some areas in light blue, which are attributes, values that the RIPE NCC manges. So, this must be verified by us, and then we show it in that way, so we show what is the legal organisation name, we show what is the country of legal registration, also the organisation type. And the white part is maintained by the resource holder, which already sometimes causes confusion because a company might be registered for whatever reason in the Seychelles, but of course their postal address might be in the UK.
But even the blue part is not always as uniquely identifiable as somebody might think. Because in a couple of countries it is possible that there are several companies who have the same or very similar organisation names. Usually ones that have countries with different local business registries. I looked it up, for example, over the years we had 5 members from Russia with the same Star Telecom. They were partially related but partially completely in different areas, so just knowing a name and a country might not always help. Also, sometimes names are very similar. I am from Germany, we love compound words, and this can be confusing. For example, a very typical company name in Germany is (in German) which is company for data processing. But then it also it be (German phrase) and so on. It easily can get confusing.
And on top of what I mentioned before, that the difference between information managed by the resource holder and information managed by us sometimes seem to be conflicting why they are not. I have now one idea, I mentioned a proposal, but I don't really necessarily mean in the term of a policy proposal, and this ‑‑ basically for all legal organisations, we have for more than 99 percent, we have unique publicly available company registration numbers. I want to be clear, natural persons are completely out of scope of this because there is a GDPR, I'm talking here only about legal organisations. And a little bit to the 100%, there are some corner cases, Ministries, some universities, but for almost all we have company registration numbers. Should we maybe publish them as RIPE NCC managed value? Which would then help anybody, everybody that is maybe not so familiar with the RIPE Database to more more clearly identify who is the resource holder.
If you think that is a good idea, what is the right way forward, should it be a full blown policy proposal? Should it be, like, what Hans Petter referred to as a numbered work item, because it would likely need a new attribute in the RIPE Database? Or should it even be something else?
Now, moving on to my last topic. I am conscious of time, I'll keep it short. Taking about end users, you know we have many resource holders, and you don't have to be a member to be a resource holder, you can get some independent resources, and you need for that a member that sponsors your relationship with ‑‑ so you have a relationship with a member, and then they keep us updated. And overall we have 20,000 such contracts between members and end users.
And our members can end these relationships at any time and inform us that it has ended either because the resource is not needed anymore or because the end user went out of business or simply the contract has ended.
And I put up here a graph of how this information that sponsorships have stopped relate to the RIPE NCC. You see the orange line, how it went last year. So, also related to the fact that the fees for such independent resources went up, I guess much more members looked into their records, and informed us to stop certain sponsorships and it increase towards the end of the year dramatically, so basically in the last two months, 60% of this sponsorship stop sponsorship requests were submitted. And the blue line is how it's going to far, it's a bit below average, below last year, if you look at October we are already on par, so I do expect again a huge peak by the end of the year. Looking back what happened this year, with this peak it created a huge workload for my team. There was still a lot of manually work included, they had to get the contact information the end user, they had to create a ticket to reach out to the end user, and also what happened were quite some copy and paste errors. Some members sent us a list of 15 end users, they stopped sponsoring, they copied the wrong one, we unsponsored the wrong one, also sometimes in my team somebody maybe similar looking AS numbers, they unsponsored the wrong ones. And all this was sorted in quite some delays for this requests and other requests and also quite some frustration on the members side but also on my team.
I will now get very quickly what we will do now n a few weeks, probably we will introduce a new stop sponsorship and I have here some screenshots how it will look like, I will now jump over this because we are a bit over time. But it basically will allow you to select the end user, even the resources, you can give additional contact information to us, a new ticket will be created and what is new is that at the moment you sent us the request, the resources will be unsponsored. So, you don't have to wait for any of the view by an analyst because there is nothing to evaluate. You have the right to unsponsor, do you it, so this way we are the first registry self service that we offer you. You may remember yesterday, Hans Petter said we are looking in more self‑service opportunities options. This will be ‑‑ the first one, it will greatly reduce the risk of copy and paste errors and other oversights, it would reduce the workload in my team, which is highly appreciated by them.
And what I want to ask you, I will send an extra announcement, then please only use this online form, give us the latest contact information that you have. We will use the one from the RIPE Database, but if you have something newer, that's always welcome, and also please spread the word about this new request form in your group, in your peers and so on.
That's the end of my presentation, now I really would like to hear some comments, feedback, and I am happy to see people going to the mics. I list here the different topics, and
.
(Applause)
FRANZISKA LICHTBLAU: We have ten minutes. We have a remote question.
JORDI PALET MARTINEZ: Hello Marco. Regarding RFC 9663, I think the question for large enough justification, I don't see a problem, because when you make the request to the NCC, you mention that you are allowing errors in your network and you are done, so that should be not be resolved.
Now, regarding the PI, flash back time, in 2018, I already sent the policy proposal to fix that because at that time we already had another RFC that is still current that allows this, instead of DHCP using... it was was mentioned also this morning in the IPv6 session, this is RFC 8273.
Basically, what happened is I had two versions I think in discussion and I was, let's say, heavily boosted by the Chairs at that time to withdraw it. I should not have done that, because clearly I was right at that time and surprised we are here back with the same problem. Meanwhile, probably, as you already mentioned in your presentation, some folks are either relating the current policy or even worse avoiding IPv6 deployment because they cannot do it right. So, clearly I have already a draft for a policy proposal to fix that. I will circulate it probably later on today in the list, and we should learn a lesson from that, is that, we cannot be in the middle of facilitating IPv6. We as a community must ensure that we are upfront any possibility which policies, not late, we cannot solve the problems later on, we need to fix the problems when we already perceive that they are going to come. Thank you.
AUDIENCE SPEAKER: I have two questions and two comments. One is about legacy. 5 percent seems a lot to me, so to not understand who is behind the resource, 5 percent is really a lot and it can cause a really a lot of harm, because I don't know who can comit crimes with those IPs how they are used. So I would like the community to start a technical assessment to see how this can be addressed, how these people can be, just with a normal contract, even if they are given for free in the past, these resources, at least to know who is the holder of these resources.
Second one I really like the part about improving the resource holder information. I already talked about a similar path, like adding this idea of the company to the database, maybe could be copied directly from the registry, if this is okay. So I would want to join about it in this discussion. I have some ideas how a list of benefits about this, especially for law enforcement and for agencies and governments. So not just for the community but also for us, this is a really good step forward. So if you want to speak with me on this I can give you a lot of reasons why this is a good thing. So, for me, thank you for this.
MARCO SCHMIDT: Just to clarify I definitely with regard to those 5 percent, we agree it's a lot. As the RIPE NCC we have a pretty good idea who is the resource holders of academics and so on, but indeed to the public it's not visible yet.
GERT D÷RING: Gert Dˆring. Somewhat involved in policy in the past. This is the first time I took my laptop with me because you had so many different things. So, first thing is on the legacy resource holder, I think it's a good proposal, because it's balanced, not too much work, not too much impact, but if they are willing to help, it will improve things if they are refusing to cooperate. We are not worse than before, so there is an improvement in this and it's low effort. Contacting 1,600 people is still not low effort but I think it's worth it. On the organisational data, I think that's reasonable. I would like to have sort of like an impact analysis if there is like legal consequences of that but my gut feeling says this is a good thing. And the last one is the stop sponsoring request form. I am in the middle of a discussion with a former ex customer that has resources, and there is tickets open with the NCC and all that. So when it goes live and you click on "I want to have these resources deregistered", please make sure that the system can see that that is listen open ticket for these resources, because I am fairly sure that there is lots of ongoing tickets where at some point it will just deregister and then making sure that the other ticket gets notified. That would be useful. Besides that, good plan.
MARCO SCHMIDT: Thank you. Just to clarify, what will happen automatically is only the unsponsoring, the deregistration will be ‑‑ also, thank you for your other feedback, definitely when we would decide to move ahead with the two proposals, we will publish for details and so on. Indeed we want to involve you at this early stage to get your input.
GERT D÷RING: I was meaning to make deregister but unsponsor, so cut the ties to the LIR, the resource is there still, it's owned by the holder, and if they cannot find a new sponsoring LIR that's their problem but not, my problem. Buff it's not deregistered.
FRANZISKA LICHTBLAU: Thanks for the clarification.
PETER HESSLER: Peter Hessler, resource holder and LIR maintainer. As far as improving resource holder information, we, as a company, need to register our ID number within the leader portal and it's clarified with the NCC. Instead of publishing this within the database, potentially this could be published from the member page. Because we have both the database available via Whois and art app, but also the NCC publishes a list of all the members with their certified information, and that could be published there as alternative to purely the database. It also makes it incredibly clear who is responsible for updating the information, who has validated it. Whereas with Whois, if you are using third party clients, it is unclear and can be very non‑obvious of who is responsible for this data.
MARCO SCHMIDT: Thank you.
JEN LINKOVA: Jen Linkova, someone who doesn't come here often. Thank you very much for being proactive, I really didn't expect that because people did raise concerns about oh we cannot deploy per host because policy doesn't allow that. I am a simple networking engineer, there is a difference between multiple /128 and one /64 confuses me. So, if I can do anything to help I am happy obviously to do this. I would love to hear from people who actually want to deploy it, would like to deploy this but could not because of the policy, and simply if people have an operational model for this, I personally think the policy should reflect operational reality practices, so ‑‑ but I'm I am obviously biased.
CLARA WADE: Clara Wade, speaking for myself. Thank you Marco, great proposals. I am in favour, and echo the sentiment verifying the details, especially if you are doing it as an option, should solve a lot of problems there.
During ‑‑ as part of the charging scheme task force, we also saw a lot of data and we are aware of kind of a situation in the industry where legacy status can be inherited in RIPE and therefore that is a loophole that certain actors are using to avoid paying fees, avoid the 24 month lock, that prevents encrypting and speculation. Also inter‑RIR needs space policy, that might be a bit of misinterpretation. But we have been, Peter and I have been working on a draft proposal to put an end to that, so we'll be posted on the mailing list probably after the meeting. But if you have any thoughts or questions, happy to chat.
GERT D÷RING: I on purpose did not talk, but now with Jen's comments, what's the difference between 128 and a 64? The PI policy did not come without quite a bit of discussion, long discussions, and it was ‑‑ there was worry in the room that having a cheap way to get addresses would encourage ISPs to run their network on PI and only give their customers too little space, so, it was the PI policy was written in a way that discourage or disallows giving addresses to third parties. And at some point it was clear that if somebody comes to your wi‑fi and gets an address, this is not really a third party in the sense that you don't want, and it was tied to basically a prefix or an address. So, the policy says you should not give people a prefix to discourage these stuff like deployments using PI space. This wasn't envisioned. Life changes, so this is the scope of the discussions we are going to have, how to make a good PI policy without encouraging things that we don't want, and that would be an ISP running on PI giving all their customers only a 64.
FRANZISKA LICHTBLAU: I highly encourage you to have this discussion in the open mic session, but honestly thank you for the clarification, because I think context is highly relevant here.
With that, we'll close this session, thank you, Marco, and we'll see you back at two o'clock.
As usual, I have the usual reminder, you can vote for the Programme Committee until 5 o'clock tonight. If you are registered for the NRO NC election, please vote until 9. And you can meet the NRO NC representatives at 1:30 in the meet and greet desk. So enjoy your lunch.
(Lunch break)