Main room
9.am
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
RIPE 90,
14 May 2025
Main room
Address Policy Working Group
Ed
LEO VEGODA: Lights are on. I think that means that we are ready to start. I appreciate that people are still wandering in after last night's social, I hope everyone had a lovely time. We have a jam packed agenda for today. So, firstly, this is the Address Policy Working Group. This is the Working Group where we discuss the policies for the distribution of Internet number resources, IP addresses and AS numbers.
This is a hybrid session, that means that there are people here in the room, there are also people joining us online with Meetecho and also watching a live stream. You can participate over Meetecho or you can participate in the room. When you speak, please give your name and your affiliation, that will go into the record.
STENOGRAPHER: Only if I can understand it.
LEO VEGODA: Also when you speak, be polite to other people, street them with respect, have a he had Code of Conduct and the idea that we want everyone to be feeling welcome. It's fine to challenge ideas, but we should treat people with respect.
Today's session will be scribed by Mary, and we also have chat monitors and we will have formal minutes published shortly after the end of the RIPE meeting.
Talking of minutes, the minutes were RIPE 89 were published. We did not get any comments on them. Does you see that mean that everyone thinks they are will wonderful and we can accept them? Is there any sign online that people object to the minutes?
In that case, they are accepted, and we will get them marked as formal.
Thank you very much.
And now we have Chair selection. We have a nominee. And I think it's only right that we ask our nominee to introduce themselves. So that everyone knows who is nominated.
FRANZISKA LICHTBLAU: Hi. I am Franziska. I joined this community at this point more than ten years ago, I made my journey into the community while I was still doing Internet measurement research, so I have a routing 6, lightly security and analysis background. I left the research world but stayed in this community because it was just very welcome, it was an amazing time to grow up into a new field of work these days I work on Cloud infrastructure operations, and I have worked with in the community with in the Programme Committee, and the Code of Conduct team. Until now, I was mostly an actually active reader of this Working Group, because for me it was not really main part of my work, but I have been approached and people were asking if I could help out the Chair team, and I would be delighted to do so. Thank you.
(Applause)
LEO VEGODA: I think that means that we have selected Franziska by acclamation. Thank you very much and we will get the website updated.
So, this is our agenda for today. We have done the session opening. The Chair selection. When we sent out the agenda, we put agenda item C and D separately. We have merged them here, it's a single time slot, and all three of our ASO AC representatives will be speaking. We wanted to draw attention to ICP‑2 which is a very important piece of work that's being done and they will talk about later on. We also have our traditional updates on policy and what's happening in the world of Registration Services at the RIPE NCC.
After our morning coffee break, we will be talking about IPv6 PI policy, IPv6 initial allocations, and removing the ASN multihoming requirement potentially. So this is our agenda, and we will be returning to this at the start of the next session. But for now, I'm going to step off the stage and invite the ASO AC representatives from our region to give us an update on what's happening in the ASO AC and ICP‑2, this work, thank you.
HERVE CLEMENT: Good morning everyone. So I am waiting for my colleagues arriving. So, everybody knows Constanze, and Ondrej, elected by you the community to the ASO AC by the Executive Board, and the Chair of this organisation.
We have the tradition to present the ASO AC update to the Working Group and we have very important work to do currently which is called the ICP‑2, everybody knows about that, probably most of you have attended the BoF which takes place last Monday. During that, but it was a good opportunity to represent aunt briefly with ICP‑2 in case some people here in the assembly was not present last Monday.
The ASO AC is composed of the ASO AC it's a group of people elected by the community on the /KPEF Board and we will talk about the NRO AC which serves out the ASO AC and it's part of the ASO, is one of the organisations of the ICANN, and deals with the numbers, specifically IP addresses. What it is. This organisation was established by ICANN to advise on Internet number resource policies. Normally, it is comprised of 15 members, but you you know that within the AFRINIC currently we have no representative. There will be elections to recompose the executive in AFRINIC in June, so, we will wait for good news about that In the next month.
Members, to terms vary by regions, and our main activities is to advise the Kay an Board about this domain. To advise on the global policy process. This a policy common to each of the regions and deals with the resolution of the association from the IANA to the regions. We are appointing two members to the ICANN Board of Directors, seats nine and ten, I am talk about seat ten, and we appoint one member to the ICANN Nominating Committee, which is the committee in charge of appointing people to various positions within the ICANN. And we meet one month virtually, and normally we have in person meeting during the first meeting of the year.
There are photos to show you who are the people comprised of this meeting, and we have Nick here with a representative of the APNIC as well.
This year, a lot of work we have to do. We have conducted the election for seat 10 of the ICANN Board. We always monitor and support the global policy development process. So the idea is to see what is happening during the policy discussion and there will be a presentation about this policy discussion afterwards to see if potentially there could be a global policy. And of course, we conduct the ICP‑2 review process.
The seat 10 election, we say that we have elected christian Kaufmann to the seat 10 of the ICANN Board. His new term which starts in October 2025 during the General Meeting ICANN, there is the last meeting of the year, and will conclude three years after. And you can find the details of the selection process on this link.
NRO NC transparency, that's very important for us. Or annual face‑to‑face meetings where we meet is occupy to observers. The next one, so I say it's open but there will be discussions I have to say on that to be transparent on that how it will stand for some who are Internet work we have to do, there will be opposition as well but it's very dedicated, we try always to have an open session during this session.
The mailing lists are open with archives, and ASO monthly conference is open except the very short closed session at the end.
And I will talk very briefly about the context of the ICP‑2 review before giving the floor to Constanze.
ICP is an Internet coordination, there are currently 3 ICP, so they are dealing with the ICP‑2, which is the criteria for the recognition of a regional internet registry. You have example here of the criteria that are listed in this document, and there is a link to the document which was adopted in 2021
.
A bit of history. In 1992 the RIPE NCC established. After in 1993 it was APNIC. In 1997 the ARIN was established and then the ICANN and then there was this document to this which I have to recognise new regional internet registry and this document served to create first the LACNIC in 2002 and the AFRINIC in 2005.
Why revisit the ICP‑2 now? Because I said it was in 2001. We are in 2025 now, the ICP‑2 is nearly 25 years old. Of course the Internet has changed and the registration between the regional internet registry and the ICANN and between each other has changed as well. And it needs to be more explicit, this document, so as I said, it's used only for the recognition of regional internet registry and the idea is to use with documents and the criteria to conduct audit for example more the ongoing life of regional internet registry an in extreme cases to have the possibility to recognise ‑‑ to derecognise, sorry, origin.
The ICP‑2 review project, it was the task was requested by the NRO AC, as a group of the CEO of the different regions. We have two tasks. The first one is the ICP‑2 implementation procedures, so to advise NRO on the work was set off on the ongoing regional internet registry with ICP‑2, the implementation for the ongoing registration. And after the task, so we are dealing with, so you have the possibility to give you input currently, is to transfer the ICP‑2 and to consolidate the criteria because the world has changed since 2001.
There is a timeline. I will not comment on all that, but recently, on 14th April, the ASO published the draft which is called regional internet registry governance document, and the community consultation was launched in parallel with the ICANN consultation. And the public consultation will close very soon. So 27 May. So it's very important for us to present this document and have your input during this week also.
And there is a summary on where we are. So we are on the public comment on the draft. And with that, I will give the floor to Constanze.
CONSTANZE: Thank you, good morning everyone. Before I start, I see Sander in the first row. This parent of the principle drafting was ‑‑ we did it together, and Sander, before Sander stepped back to serve in the Board and I will thank you for your commitment and your work, thank you, Sander.
So what did we do? The ASO AC drafted proposed principles that would form the basis of updating ICP‑2. We started on the old ICP‑2 document. The principles were shared with the RIR and the ICANN, and we got feedback in the end of the last year.
ICANN have comments. We got 14 responses, and the RIR questionnaire in this, on this feedback, we got roundabout 300 responses.
We analysed this feedback and we pushed up a summary report of the RIR questionnaire, and this was published in February 2025. You see all the background, the papers and the reports under this link.
For instance, what we did. You can see here some summaries about our methodology. We have analysed some responses received by region, and we have a lot of analysis in this document. You can see the summary in this big report.
For instance, I can go through authority. We got many inputs to each principle, and these inputs are really relevant. So, we had, for instance, this comment, this is in need of a balance of authority between the NRO EC and ICANN, it's very important to have this input. Or multistakeholder involved of the RIR community is indispensable. So this we take over took this feedback. We clustered the comments in a table, and we looked at every comment, and we looked at every line and every column. You can trust me, this was a lot of work, he work this over in clusters, we categorised it and did ‑‑ we asked ask the comment pertain to the principle itself? The phrasing or the principle for the future implementation of the principle? Or the comments were clustered around the main issues. They addressed the role of the ICANN place, concerns about the process, the need of rehabilitation and air prior and so on. And these concerns were summarised and added to our new document, the RIR governance document. The NRO NC discussed the concerns raised, depending on the feedback, and we discussed a lot. And you can imagine we have is 12 people and 12 cultures in the NRO NC, and the discussions is very hot, but it's focussed on the topic. So, I'm really proud to be in this group.
How we use be community feedback in the draft. We clarified the role of the community. We addressed procedural concerns. We aligned requirements with common privacy and corporate governance. Or elaborate where necessary to address the question about principles.
So, now I hand over to Andrei and he is introducing to you the actual document.
ANDREI ROBACHEVSKY: Thank you. Good morning everyone. So indeed I'll very quickly introduce the RIR governance document. This is not at all a replacement from reading this document. Moreover, I hope I will incentivise you to actually go ahead and read this document. I hope the URL is here. The QR code is here. It's very important that you read this. The title as Herve said, it's provisional, it's a working title, but you see it doesn't, it's not called ICP anymore, because ICP was disit and, there was no specific process under which those series was produced. And also in the governance document we tried to highlight sort of distinguish this document from the policy document, Address Policy or even global area policy, because that's not, that's indeed a governance document that governance operation of the system as a whole and its components.
Again, the document has a slightly different structure from the ICP‑2. It also has a different structure from the principles that were sort or sort of consultation we conducted on before. This is not a next version of the principles. You will see reflection of all the principles, with added feedback that you provided in this document. But basically ‑‑ and it has significant changes from the ICP‑2. That's very important to highlight. The changes they fall into four main areas, and I will go quickly through them.
So, ICP‑2 really talked about how an area could be created. Because that was the sort of task of the day. There were two RIRs are sort of expected to emerge and we needed a process and criteria under which those RIRs could be adopted or recognised.
Now, it talks a little bit about how the area operates and of course there was an implication that the principles or the criteria that is used to recognise an RIR will be used for the operation but it's not explicit. So, this document makes its more explicit what are the requirement when the RIR operates and what sort of commitments they need to do and maintain. But also in any governance document when you talk about organisation, you need to talk about all the phases of this organisation, from the creation, operation and then winding down, right, so the recognition is another phase. That is outlined here, under what condition an RIR can be derecognised and maybe replaced.
We made the, some of the ones by the government structure more explicit. The document is very high level we tried to not impose something on what should be decided by regional community, what should be decided by the local governance process, or the RIR governance process. So it's really high level. And I think what also at the BoF we saw the comments, it's I think the focus of the document should, and we hope it still is, on ensuring on the system as a whole, ensuring that interoperability between the RIRs that constitute the system. So things like member control governance, things like corporate governance and best practices, and very important that we also highlighted that the governance mechanism should be robust, should be resistant from capture from one group or its affiliates or one organisation can get undue control over the RIR.
As I mentioned, we made operation requirements when the RIR operates more explicit, such as audit obligations so we can monitor performance of an RIR continuously, and get early warnings, not late.
Transparency: Nothing new. I think we all operate in transparency but we felt it's important to highlight as a principle. And very important. At any time plaque. At any time continuity planning was also reflected ‑‑ reflected the feedback that we got about the privacy requirements, for instance we are not prescribing that data should be shared among the RIRs but there should be procedures that should be facilities in place that allow business continuity when something bad happens to an RIR, that the system is not really affected.
Finally, we clarified some of the roles. We felt that some of the processes needed to be clarified better, especially in those phases when an RIR is going to be recognised a new RIR or an existing RIR is going to be deI go commissioned or redecked. What is the role of the decision, what is the role of the RIRs? What is the role of ICANN and what kind of high level procedures should be employed?
Also very important to highlight when we say RIR, we are not meaning the Managing Director or president, we mean the governance structure of this area, how decisions are made in ‑‑ under this particular governance structure. It might be /KPEF Board, it might be sort of voting by the community, General Meeting, we don't know. But we didn't specify that. So by RIR it's not just one person, it's really the organisation and the decision‑making process that is adopted in this organisation.
So, yes, with the publication of the document, we opened the consultation period, it will last till 27 May. There is still time to read this document and comment on this.
Guidance for feedback, window that's normal. That's how we sort of operate the mail list in a civilised way. Please be constructive. The more constructive you are, the more to the point you are, the easier for us to accept the feedback. Be specific to what particular article of the document you comment on. Some people said that the document is very dry. It doesn't have this kind of narrative thing. But I think at this stage, we take this feedback on board, but at this stage we try to make it as clear as possible, so you can see more clearly what is missing and maybe what is not correct from your point of view.
Follow the discussions. If you go to the web page you will see how the consultations processes are happening in all regions. We don't have one single mailing list for this discussion across all five RIRs, but we all regions have their own mailing lists serving their own community. It doesn't prevent you to subscribe to all of the mailing lists and it doesn't prevent you to provide feedback in different communities as you see fit, or follow the discussions.
Now in our community that's the way we invite you to participate. Please subscribe to the mailing list. On Thursday, we'll again you'll see us on the stage, you'll see a lot of us at this RIPE meeting. So, we will report on the BoF and discussions that happened there. So please come and listen.
There is also the ICANN process. So that's a sixth consultation process that again is aligned with RIPE and RIR consultation process. So, again you are invited to participate there as well.
And yes, once again, 27th May, keep in mind, is the deadline.
And that's it. Thank you.
(Applause)
LEO VEGODA: Does anyone have a question? We have a question.
SANDER STEFFANN: First of all, speaking as a former colleague, thank you for all the hard work, I know how much effort goes into something like this.
STENOGRAPHER: It's okay, I know who you are!
AUDIENCE SPEAKER: I am speaking in that capacity, I really encourage the community to speak up on this. Like, with silence, they cannot do their work to please give feedback, positive, negative, but let's your voice be heard.
And then, speaking in a personal capacity but a little bit as a Board member. Once this document so done, the leadership of the RIRs will have to implement it and when giving feedback, please don't assume, like although implement it this way. Like, if you want something done in a certain way, make sure it's in the document, because if it's too broad, we don't have the guidance to do it and we can't read your mind. So, think about what you expect from implementations, and make sure that everything that is necessary is actually in the document because, well like I said, I am speaking from a personal capacity here but I would love some guidance.
HERVE CLEMENT: Thank you Sander. Just to add something, I don't know if we said this. We are present at the Meet and Greet place between 22 and 2 everyday if you have any questions regarding ICP‑2.
SPEAKER: There is one online question. Are any NIRs in for this NAS Internet registries.
ANDREI ROBACHEVSKY: No.
CONSTANZE: It's also written in the question and answers ‑‑ it's also written in the FAQs online.
HERVE CLEMENT: I see Randy.
RANDY BUSH: This is a boring administrative tedious document and process. I know we all would love to ignore it, but it is the foundation for what we're going to live with for the next two decades. Do pay attention. To help them get it right. It is critical.
(Applause)
CONSTANZE: I can give it back to the audience, please take this in your mind. You are the community and we are thankful for your engagement, for your experience and for your issues. Thank you. )
ANDREI ROBACHEVSKY: Not to weaken the point that Randy made, but this document actually has the process on period Ilyich review and amendments. Hopefully not two decades, if system changes faster than in two decades, we can change things.
LEO VEGODA: Seeing no more people at the microphones, thank you very much.
Angela.
ANGELA DALL'ARA: Good morning everyone. I know you are all of thrilled and excited to go on with fascinating subjects, so I'm here to give you an update about the policy development in our region since RIPE 9, what happened in other regions, and at the end I really also would like to have some feedback from you about the review of the policy documentation, and I will tell you a little bit more later.
So, in our region, since RIPE 89, we didn't have any implementation, no new policies were implemented, but we are now dealing with three policy proposals. So we have two in the PDP. The first one in the PDP is 2024‑02, IPv6 initial allocations /28, and Jordan will tell us about the new version version 3, which was published yesterday and is in review phase for four weeks, an I stressed all the time that remember that only the comments in review phase are considered for consensus. So if you said something during discussion phase, if you said something when the whole idea was proposed, repeat it during the review phase.
Then we have a new policy proposal in discussion phase, ASN assignment criteria are being revisited. Actually there will be a talk about this which are the new criteria that they want to implement. And this is in discussion phase until the 4th June.
And then we have the policy proposal regarding review of the requirement for PI assignments, the usage and so on that Tobias will explain more about later in the second session.
So, to give you an idea again for who is new to the PDP, the timeline for the policy development process is articulated in multiple phases. First, the idea is suggested, then if it targets the PDP goes into discussion phase to see if there is another support to go ahead with a final version that can define a new policy draft. Then the RIPE NCC makes the impact analysis, so you have an extra element to evaluate for the review. Then there is last call, during last call, if you make no comments, a last call happens only if there is consensus declared by the Working Group Chairs. If there are no comment in last call, this means that consensus, rough consensus is confirmed. So you see now the two policies in the PDP in which phase they are, participate, they are your policies, to help the proposers to have a version that satisfies the most of you.
There are no perfect policies. Policies are meant to improve things or to fill gaps. Please keep in mind that a perfect policy does not exist.
So, what happened in other regions.
We have in AFRINIC already a situation that is still awaiting for the reconstitution of the Board, so there is a policy proposal that is waiting for implementation, already for a while and three policy proposals that are waiting for are clearly once the Board is constituted. They are a bit old, but let's see what is going to happen.
Then in APNIC, for who has resources there is important to know that two policy proposals were implemented, so they are already applied, and one is the resizing of the IPv4 IXP assignments. Very similar to what was implemented some time ago in RIPE NCC.
Now, IXPs are receiving by default a /26, up to /22, and to, let's say, give more longevity to the pool for these resources, and then they reserved that pool of resources for temporary assignments. If I'm not wrong, it should be /21 in IPv4, a /29 in IPv6 and eight ASNs. So if in the APNIC region you need to organise an event or you need temporary resources at the discretion of APNIC, this can be granted to you.
Then ARIN, he see here we have John Curran, so I hope I say everything correctly. I must say ARIN has a very active Advisory Council and they are reviewing the manual very thoroughly. So, what did they implement lately?
.
A change of the language to comply with the deprecation of assignments, let's say, now it's all, all are allocations, so the manual needed a refreshed language.
Then for multiple discrete networks, there is a new clarification of how you can, let's say, give different resources to dinner networks as a single holder, let's say.
And the third one is specific which data, which personal information must be recorded in Whois. And the last one is removing some outdated language.
What is under discussion now? What I love of ARIN are these very short titles of the proposals, so I tried to do my best, but I think the most important one is that there is one that is proposing to reduce the allocation to /24, and probably also the other one is the possibility to give small assignments to, for the transition to IPv6 to, how can I say, to sub‑assign a part of that assignment that is giving specifically for the transition to IPv6. At the moment it's not possible, but is seen efficient to do it. I am talking about 2024‑11.
The rest is more administrative. The registration service agreement is saying that if you have already service agreement, you might, it's not older than two years, you might avoid to sign a new one. But I think the last one can be interesting for who has resources there. This allows, let's say, to have an out of region usage of your resources. When you have a smaller amount, how can I say, when you have only /24 in region with ARIN. So if you already ‑‑ now you need to have at least an announcement, or anyway a network that holds a /22 in ARIN, to be allowed to have an out of region usage of your resources issued by ARIN. And this is reduced to /24 to give the possibility to of has last space to benefit from the possibility.
LACNIC, they implemented the possibility for operators of critical infrastructure from outside of the region to receive resources, and how can I say, the publication of a log of the usage of resources for critical infrastructure. So, all the micro allocation that was done, IXP allocation and so on, now they are published in a log. This is to prevent misuse of this pool.
They have under discussion the implementation of temporary transfers. The distribution of resources to natural persons, and the requirement for legacy holders to receive services from LACNIC. So, I suggest you to read this proposal,s because, also because they relate pretty good to our region policies.
The usual slide with all the links where you can find your information, and ‑‑ here, now you have to wake up and listen to me and I want all your feedback please.
So, we hear very often that our documentation of the policies is a bit complicated to navigate, because we have multiple documents, they are ordered in, let's say, by date of update. It is not easy which to recognise which is the policy that actually applies to your request, to the request that you want to submit and so on. So I made this beautiful unreadable slide so that you can have an idea of how many documents we have regarding policies. We have 16 regional policies and six global policies. Global policies are the policies that are regarding the distribution of resources from ICANN to ‑‑ from IANA, sorry, to the RIRs, and the same text has to be approved in all RIRs. So let's say that these are not happening very often and I would not like to touch them.
But again different colours, because if you look at the RIPE regional policies per topic, you see that we have some topics that have multiple documents. So, IPv6 has three documents, independent resources holders have two documents and the resource documents transfers have two documents. So my question so you is: Would you like to have a consolidation of these to start a review of our documents consolidating these documents into one so that we end up having one policy for IPv4, one policy for IPv6, one for transfers, and one for resource holder of PIs and ASN?
.
In my opinion, it would be a bit easier to find your information. In the past, it's not my brilliant idea, if you look in the archives of the address Working Group ‑‑ Address Policy Working Group, you see in April 2021, Kurt Kayser sent an e‑mail exactly about this document of IPv6 signalling the fact that we have different documents and proposing also a way to review it. You might say that my response is not one of the fastest because after four years... but it always stayed in the back of my mind, and I think also this started a bit the discussion on reviewing the policy for IPv6, for allocations and for assignments. That was sort of the the spark that started everything.
So, my question to you is if would like to consolidate them into a single policy document.
So, this, for example, is what could happen. Take the three documents. Make a new document, and then how? Because a one question for me is: Do you think it would be enough only to take the policy text, the abstract and the introduction for each topic and then just have a reference to the rationale, to the attribution, the acknowledgment with a footnote? Because you have to imagine that each policy has its own paragraphs at the moment, and they would not apply to the new document in total. So we could just refer to that for each paragraph.
And another question is: The IPv6 document, and many other policy documents, contain definitions, contain goals. Should we work on a definition and goals document that is valid as a reference for all the policies and just eventually update that one and always refer to that document? So, to understand a bit which is the method that you would prefer to apply, hoping that you don't mind that following up on this presentation, I am going to send a questionnaire, actually an e‑mail, please reply just to the e‑mail, with some questions to know which would be your preferred option, because of course, I don't want to override the group and the community saying: Okay, I am going to grab my colleagues, we do it together and then that's what you have to accept. Also because, believe me, it's not going to be an easy AATAC. So before setting up a group and finding the resources, the time and so on. I really want to know if we are doing the correct thing.
So, the options, the options that I thought is would you like to set up a sort of a task force to redact the document and have it eventually approved or would you like actually to have a normal policy proposal for the review of the document from somebody of the Working Group or anybody in the RIPE community, or would you like to have RIPE NCC to propose a new document to work on the review and then ask for eventually consensus on the new document?
And option 4 is also: Do you have any other idea? Is there something else that you would like? Are you happy how things are now? Because for example I have heard also somebody saying I would like instead to have a compendium or a summary or a little booklet with the policy. But then my thought was then what is going to be authoritative the summary or the policy? But, you know, I really would like to know what, what you would prefer in this sense.
So, I am going to send an e‑mail. I really hoped you find the time to of course have a look at the policy so you have more ideas about what the work is going to be, and let me know what you prefer to do.
If you have questions or comments, I think we have a couple of minutes.
AUDIENCE SPEAKER: Jordi Palet: Very quick on this. I will be very much in favour of doing this rearrangement of the policies. I have the feeling that because it's just a bit of work and we are not changing the policies, it should be fine, at least for me, I hope for the rest of the community, the NCC can do the work and we can provide inputs. I am not sure it fits in the current PDP. If not, I am happy either to take the work myself, together with other people, I proposed this already in other regions like in LACNIC, to do a complete review of all the policy manual, which is totally different topic, but I am also in favour of task force. So either way.
Preference: Probably let the NCC to do because it's a lot of work. I am sorry because we are giving you extra work, but I think it's doable. Thank you.
AUDIENCE SPEAKER: Tobias: I do think that whatever we do will be, I think it's professionally called a fucking shit show. Because ultimately these policies have grown over time and even if you just consolidate like in an editorial way as the NCC they are also like this little nooks and you are thinking if I read the policy I can simplify that little thing. All of a sudden you have a policy implication. I think that is the big challenge of making this change because from like an perspective it make is sense that this is done as an editorial aggregation by the NCC, but even unintentionally, there is a risk of there by introducing changes in the meaning of policy, which is difficult and like as I said unintentional and at the same time, I am personally not necessarily convinced that there would be sufficient engagement in this Working Group to support that process and support you in the provision of this document to spot all these things. So, I'm not saying that I have a solution, but I do admire that problem and I am really saying for you to take that.
AUDIENCE SPEAKER: Good morning everyone. I am Marco, speaking for myself. I have seen that new allocation for IPv6 will be /28.
ANGELA DALL'ARA: Well ‑‑
AUDIENCE SPEAKER: Just wait. I want only to ask if all this allocation /32 up to 28, 29, can be up to date up to /28.
ANGELA DALL'ARA: If you read the policy proposal, there is an option in the ‑‑ but I should leave it to Jordi to explain. The initial allocation, the larger size of the standard initial allocation is extended to 28, and then this version of the policy, but they are looking for feedback, is allowing each organisation, each member of the RIPE NCC to extend one of the existing allocations that they have to /28. So, assuming you received a the 29, that one could be extended to 28.
AUDIENCE SPEAKER: Thanks.
AUDIENCE SPEAKER: Thank you Angela for putting this together. I think some of the options that you have proposed can actually be applied to different purposes. For instance, when it comes to consolidating policy into a single manual, perhaps a task force is a good way to approach it, as you mention in option 1. But I do think it would be great if the Registry Services team would also be involved in policy development because you are closer to this than probably anybody else in the community.
ANGELA DALL'ARA: If I may. My approach would be very gradual, because we were thinking, you know, there are different outputs that you can get from such a procedure. So my first approach would be just to consolidate the content of the existing policies into one document without making any changes, without touching the content at all. So once we have everything in one document, then we can eventually work into a manual, but, you know, that, I see it as a sort of a later stage. And how can I say? There might be in each document something that is obsolete, something that is outdated and there are going to be corrections again in the editorial matter. But not in the content. This as a first phase, but I really would like to know what people would prefer to do.
AUDIENCE SPEAKER: I think a task force could be a step in the right direction as long as it also included NCC staff, and yeah, probably a diverse group from the community so it's not, you know, too focussed on one direction. But yeah, I appreciate it.
ANGELA DALL'ARA: Thank you.
HANS PETTER HOLEN: A former of a task force to revise and consolidate the IPv4 policy some 25 years ago or something like that.
You guys in the room, you are community, you have to live with these policies. I would really encourage you to think that, you know, be a member of a task force and be part of this. Please step forward and volunteer your time for that. Of course the RIPE NCC will provide secretariat support like Angela or other people from the Registration Services, we will help on this, but it's so great to have somebody outside that actually has to live with these policies to discuss this with along the way. So even with the task force, we can do a lot of the heavy lifting but we really need you in order to start building the consensus and understanding process early and not just at the end of the this process.
So, while I really appreciate that Angela is giving you all these options, I really urge you here in the room to please volunteer for a task force on this. Thank you.
LEO VEGODA: Do we have any online questions? In that case, Angela, thank you very much.
(Applause)
.
LEO VEGODA: Marco will now give the update on Registration Services.
MARCO SCHMIDT: Good morning everybody. My name is Marco Schmidt, I am the manager of Registration Services and in this regular segment of the Address Policy Working Group I want to share with you the latest observations over the last couple of months that were done by my team and myself.
I want to talk with you today about four different topics. The first topic is ASN and IPv6 will be mostly a quick update. Then I would like to get your feedback on the topic of legacy, in particular legacy without contract and I want to close on the topic of policy interpretation. It will even add a little bit to, from a different angle, what Angela just presented.
But first, let's talk about the development of AS numbers because many of you for sure know that last year, at RIPE 88, a new charging scheme was accepted and for the first time ever, an annual fee of €50 was introduced for every ASN that a member holds or sponsors, and back then there were also some concerns, there might be a tsunami of ASNs that would be returned or network engineers and small businesses might be impacted. Now twelve months have passed I think it's a good time to look at what actually happened.
You see here a graph with the amount of ASNs that have been issued over time over the last couple of years, that's the green line. And another line, the orange line, how many ASNs have been returned.
Be and you can see there is also this dotted vertical line for the moment that the charging scheme of accepted twelve months ago. And there is an impact. So you can see the amount of ASNs issues has dropped slightly. So 2 thousand ASNs over the last twelve months, which is like 15% less than the average over the last five years. And about returns, there are something more significant, so 2 thousand 5 hundred ASNs have been returned in the last 12 months which is 1,000 more than the average over the last five years. Yes, there is an impact but I would also say there is nothing dramatic happened.
Diving a bit more into it, so those ASNs that have been returned, they were actually all of them were unused, and most of them came from end users, and even many of those end users they didn't have any other resources, so around 500 of them, which also at the end once this AS number was unused and deregistered we also could remove in our internal records this end user record.
Additionally, more than 1,000 ASNs changed their sponsoring LIR. So basically, during the review of a member, or even by the end user themself, they say oh the current relation with our sponsoring LIR and end user is not working anymore but the ASN is still needed so we find another sponsoring LIR that will provide this contractual link to the RIPE NCC.
Which also basically improved the quality of the registry, the accuracy and also the responsible resource management.
Of course all these requests to change sponsorship, to do the deregistration, they had quite an impact on the the workload in my team, but it was for a good cause I would say. And I do expect that now every year we will have a similar cycle because now our members are more aware for looking before the next invoice is issued, do we need all these resources? Do we still have contact with our sponsored end users? And even a couple of members just noticed when they got their invoice, oh why do we have to pay for this ASN? They say actually I don't need it but now I have paid for it so I will seep it until the end of the year and give it back. That's fine.
We actually, together with our colleagues from the software engineering, we now working on a request form that will make it easier in the next time, well the next round, to request such a change of sponsorship.
Now, moving on to IPv6 allocations. Also there one year ago at RIPE 88 in this Working Group, we discussed and agreed that when somebody wants to make an IPv6 allocation transfer that the policy requirements should be prioritised. Meaning that the receiving party really must have a need for this additional IPv6 address space, which by the way also applies for LIR consolidation, so if the same member with multiple LIR account because the allocations are provided per LIR.
Here again I included a graph. The green line are the amount of IPv6 allocations being transferred. And the orange one is returned. Also there with the dotted line indicated the change in June last year was implemented and you see a clear drop of allocations but still allocations are being transferred and they are deployed and so on. 450 allocations have been transferred within the last twelve months and 5 hundred allocations have been returned because they were really not needed and that is lightly above the 5 year average.
.
So I also would conclude that the new approach has the intended effect to really don't look transfers of allocations that are really in use and needed but also as a good moment to make members aware that also IPv6, even if it's seems endless, should be used responsibly, it should be used in align with the policies, because sometimes we get some signs that for a single customer that even doesn't have a running business, has a complete /32 was being assigned, which is not policy aligned.
And it did cause some frustration by a few members because they could not demonstrate that need but overall this change has been accepted and I think it's a good example of a cooperation between this Working Group and the RIPE NCC. So thank you for that.
Now, I would like to talk to you about legacy and legacy without contract. And to the ones of you that might not know what is legacy, what is IPv4 legacy. That's basically address space, address ranges that were issued long long time being before the RIPE NCC and the current RIR system even existed. So, IANA and other early registries provided those resources to organisations, and this was outside of the current policy framework. That's important to keep in mind.
Actually 2014, a bit more than ten years ago, a policy was ‑‑ did reach consensus at the RIPE NCC Services Working Group that defined what services the RIPE NCC would provide to this legacy resource holders and also what kind of contractual relationship they can establish with the RIPE NCC. And in summary, they can have a regular membership with us, they can have sign a special contract directly with us for legacy resource holders. They can also like for independent resources, decide to make an agreement with a member and be sponsored with us and they can decide to not have any relationship. And especially for the last point it's important to keep in mind that because of the special nature of legacy resource, we have limited authority over those resources.
.
And now, as the implementation of this policy is ten years ago, I thought this was a good moment to look at what the current status is and what happened. I think before going into the details, we can already conclude policy is working. It's a success. But also to quote my colleague, Angela, there is never a perfect policy. So, while in a little while I will talk about something that can be improved, I think I want to also stress it is a successful and working policy. Because, if you look at the pie‑chart on the left‑hand side, this shows off the current legacy address space that is registered with the RIPE registry. Around 75% under contractual relations so it means of accounting IPs, in total we have 185 million IPs with address legacy registered in our registry and 135 of them are under contract.
Now, looking at the graph on the right‑hand side, which is a line chart, it tells a bit how the first moment a different story. You can see the green lines are under contract, either directly or indirectly. It is growing. And it is growing also mostly or one of the factors is RPKI. Because you need to have a contract directly or indirectly with the RIPE NCC to do RPKI. But you also see there is more than half of the ranges with address legacy are not under contract and it might at the first moment, look a bit confusing why 75 per cent of the IPs are under contract but more than half of the range is not, but it's because mostly smaller ranges, /24s, are still ‑‑ we don't have any relationship with those resource holders.
And diving a bit more deeper into this 25% of the whole space, so it's roughly 2400 ranges. When we took responsibility for them, we got some information from IANA, from SURFnet, from ARIN, then the project they were doing this, what kind of organisation name that he had in their records, and this is around 1,500 different organisations, and many of them have never engaged with us. So in the pie‑chart, you can see when we, as the RIPE NCC, did an update for those ranges, and more than three quarters basically updates 10 years ago never really had an update from us.
Also interestingly, these resources are being in use mostly, so about half of the ranges are being routed, and usually the bigger range is actually 80% of this 50 million IPs are happily being in use, but it's also shows something, they are used but we don't have much information about them.
Also sometimes resource holders to decide actively against the contractual relationship with us, that's possible, the policy allows it, so this pie‑chart, the green and yellow slices that are very tiny, but there is some update the new resource holders decide to stay out of contractual relationship.
And while in our internal records, we have some admittedly, very old information about how, these addresses were provided to some time ago, in the RIPE Database, it's a different topic. So if I take an example range, this is a legacy range of /24 without contract, you cannot really find out who is the rightful resource holder. You can check the Admin C to get the contact information and so on. But all other inetnum objects in the RIPE Database they have an organisation link to it, that applies for allocations, for PI assignments and also for legacy with a contract, or being sponsored, but not for the responsive contract. We were being contacted by somebody saying I think this is my resource but it's not really clear there, and yeah, that's the current status. And this indicates already one the challenges that I think is there with legacy without relationship.
There is a lot of challenges to the data accuracy which is one of our main goals, because the information that is in the RIPE Database, they are often outdated, not working, or unclear. Also, our registry records that we have internally, they can be 20 plus years old and for sure things have changed. And we also experienced and increasing pressure from different sides saying hey, there are ranges in your database, who is the holder of those ones? And by the way not only let's say law enforcement, even less from there but sometimes decide legacy resource contact us directly and say hey this is my range or not?
.
Then something that my team especially experience is a huge operational impact, because if such ranges are sob updated, somebody wants to give it formally to another organisation, we often have to go through 20 years of company development history, and all of you that are working in a company that is a bit older, you know there are name changes, mergers, splits, liquidation, legal successors and so on, and we need to trace from the data that we have on our records until somebody who claims that now need to have a clear line of holdership changes, and often that's a struggle. Sometimes they are even disputes because maybe there was a company split one time along the road and it was not really clearly defined which of the two or three new companies got this range.
And I know from my colleagues in the software engineering department, this special rules for legacy without contract has a huge impact on implementation any software updates because it's just delaying process and engineer time is needed to do that.
Of course, this specify non‑contract status also is being used. It can be ‑‑ have an advantage for certain people, and before going into that, I think still the majority of those resource holder legacy without contract they are using happily the ranges that their Internet that they deployed 20 years ago. But we also see transfers for example a lot of address space that is coming via an inter‑RIR transfer from ARIN is usually legacy, and sometimes the receiving party decides to don't enter any contract relationship, and that's fine, and just a bit later, then after a little while, then she said oh now actually I want to transfer to somebody else, and that's correct, to our policies. Although when the resources came to our region they provided a plan and then the plan is changing sometimes rapidly. Another risk, that is really an abuse, if somebody happened to know the maintainer password of such a range that I just showed you, they can get control over it and maybe it hand it over to, rent it to some other parties that are knowing that they might not be with the rightful resource holder and we don't have much insight on that.
That's my last slide. So while I said that we don't really have a clear mandate. Actually the current policy provide some mandate for us because it's clearly said there that we should strive for accuracy, and also for the part of non‑relationship that we can update the records to reflect the reality. And we are currently looking a bit further into what might be a possible solution into this situation, and actually my question to you will be: Do you agree or disagree that there is a problem? Do you maybe have some suggestion what could be a solution? ? Or is there even something needed on the policy side?
.
And be that brings me to my last short section. It's the policy interpretation. And as a summary about the policy development over the last decade or so, there is a trend, a good friend to make policies more general, more simplifying it. An example is we don't have much need evaluation for IPv4 anymore because there is not much IPv4. The transfer policies of all the different resource types, they have been combined into one policy. Make it clear not many details, not many exceptions, let's say.
And this approach is working actually, it offers a flexibility for some corner cases, but it always requires also careful interpretation. And sometimes we at the RIPE NCC feel we need some guidance because we want to be sure that our interpretation is in line with what the community, what this Working Group thinks, and I named here two examples. The IPv6 allocation transfers, I just talked about it earlier, and also there is about transfer statistics I asked this at RIPE 89, the policy gives some requirements what must be published in a transfer statistics, and we are currently following your guidance even working on providing more information in these transfer statistics. I think this cooperation, elaboration is helping to get the right balance between flexible, having a good framework, a good guidance by the policy, but not trying to cover every corner case in policy text.
The point that I try to make is it sometimes still of course happens that somebody in the community or a member is disagreeing with RIPE NCC's policy and interpretation, and then where we quick instinct is let's add something to the policy, let's add this specific case to a policy proposal, and the result is often a very lengthy process. There is a discussion if policies should be more specific, is the interpretation idea from a proposal, is it the right one? And it can be quite frustrating for the proposer, for the proposal mailing list discussion and also for the RIPE NCC, especially if Angela if she has to create an impact analysis on something complicated. So I think and want to suggest here that it might be often more effective if there is a different understanding how a policy should be read, how it should be understood, and to be also just mentioned it, it can happen very easily, to look first if a PDP, a former policy proposal, is the right approach or maybe should be in alignment with the RIPE NCC, a clarification call be made? And if you are in such consideration, I want to suggest whenever you have such a doubt or such disagreement, send an e‑mail to pdo [at] ripe [dot] net and Angela will be happy to assist you.
That was my last slide. I am happy to take any questions or comments.
LEO VEGODA: Thank you very much. I understand you have been having discussions with members this week to clarify implementation. Is that correct? You have been having discussions with members this week to clarify implementation questions, so this is something that you actively do already. It's not a new thing.
MARCO SCHMIDT: That's correct. It's an ongoing process but also I wanted to make it very specific here, yes.
LEO VEGODA: Excellent. Okay, we have four people at the microphones, we also have the opportunity for people to ask questions on Meetecho. We will inter leave between people who are here in the room and people on Meetecho if you want to ask questions on Meetecho. Do you want to go ahead?
AUDIENCE SPEAKER: Clara Wade, speaking for myself and really as a member of the charging scheme task force. Marco, thank you so much for this. One of the issues that we surfaced during the meetings was, in terms of legacy non‑contractual relationships, we learned that, as you mentioned they are very labour intensive in the event of legacy transfers where none the parties have a contractual relationship with the NCC, and it ultimately requires half of a full‑time employee's time.
MARCO SCHMIDT: Yes.
CLARA WADE: Which is not an ideal situation. And why we recommended charging for this. But aside from that, there were a number of issues that were outside of the scope for the task force, and that we thought this would be the venue to discuss, but part of the problem here is one of them is, for instance, the right to hold legacy resources was meant for those that received that allocation originally. Currently, that can be transferred to the recipient, and should that be a right that had a recipient must have? And I think perhaps that's a gap in the policy that we need to address. Set up.
MARCO SCHMIDT: I think what I can say to that is that indeed the RIPE region is the only region that knows the term of legacy resource, and the legacy resource can be passed on. In other regions there is the concept of the legacy resource holder which is the one that received it historically.
CLARA WADE: To add to that, this is something that's currently being portrayed as a business opportunity because it has less operational cost, and the case that you mentioned where they are directly making updates to the database without going through the registry, which is not where we want to be. Just bringing that to the room.
AUDIENCE SPEAKER: My question is more related to the legacy space as a whole. So, the active policy is more, is more than ten years. On your personal experience as a registration manager, do you think there are some tweaks that are needed, we need to revisit the policy, this specific policy or... let's focus on other stuff?
MARCO SCHMIDT: I mean there are several options, and I think at this moment I mostly wanted to bring the current situation to the awareness of the community, of this Working Group. The current policy gives already some guidance, and we are looking into it, it needs a bit more analysis, but yeah, I mean as a community, there is always the option for you, if there is a feeling its policy needs an adjustment, to do a policy proposal. So I don't really have a clear personal opinion yet, and it's just in this moment informative for you to look if there is something that should be done in which way or whatever.
AUDIENCE SPEAKER: Jordi Palet: Regarding legacy, as I think as Clara mentioned, I don't think the right of legacy holders should be transferred. In other regions, when they transfer, they need to sign a contract, or they lose the legacy status. I think we should consider the same here. That's one point.
The second point is, I am not sure if legacy resource should get any service without participating something for this. I think this is a coarse for the membership and also the community. So is should be covered. Finally something that has been done in APNIC, and I am working also on that in LACNIC, is checking if the legacy holders space is being announced, is really being used. I understood, if I'm not granted about 80% is being announced from your presentation, so there is still 20% that maybe some holders don't know that they have it, or they don't exist anymore and has not been transferred, so that's an important thing for abuse. So what it has been done in APNIC is contacting them or trying to contact them and if there is no contact or they don't sign a special contract or a regular contract, recover it and return it to the enable space for the membership.
I think we should do the same. And I don't know, if you are going to start somehow have a discussion in the list or we should probably take some of these points. I think it will be important.
MARCO SCHMIDT: I want to make it clear in LACNIC and APNIC are there are some initiatives but there is nothing right now planned here, this is first raising the awareness and I personally think it's good that the current policy gives the option for us to provide some services, also to people without contractual relationship, because it helps the accuracy, that indeed I tried to highlight the down falls.
RANDY BUSH: I am a legacy holder recovering or not recovering. What is our goal? Our goal is an accurate registry. We also have to be fiscally responsible. We'd like to get legacy registered and accurate, but to do so we have to ‑‑ or we don't have to but I suggest we make the barriers as reasonable as possible and not to do like APNIC and ARIN have, right? We don't gain anything by, for example, making transfer legacy remove its legaciness, especially if the legaciness really has no attributes other than a tag, right?
So I think lowering the barriers to become members or to buy services, etc., so that our data are accurate and so that we have contact and so that the network works operationally, and all address space by the way does not have to be in the global routing table, that's just one measure, right? People use it behind walls. So enough, I have talked enough. Thanks Marco by the way for the analysis, it's really good.
MARCO SCHMIDT: Thank you, Randy.
AUDIENCE SPEAKER: Tobias: I might be one or two years younger than Randy, but I am currently also using a sub‑allocation of legacy space, and I have to say I am loving it, mostly because I am a big fan of putting everything in the registry which documents my network to let people know this is an IP addresses I use for transfers, I like transfer networks, this is servers, this is like my client thingies and wi‑fi and like, really be detailed in what I can document. And legacy let's me do that. Legacy let's me be very specific in what is happening with that network. I also do have PI, and there is also used in another my ASes there is also transfer networks in there. I cannot say like this hundred, like this /28 from 192 to whatever is is being used for transfer, I cannot also say this is the link to the following AS which might be interesting information in the database. So if it I compare legacy with PI for example, it is a significant reduction in service you can get and utility you can get and also an registry of you can provide as a holder. I would encourage you to think about that also in the context of the Database Working Group if we are thinking about taking away legacy, because from that very specific prefix I am getting there legacy would be taking away the accuracy of the database would significantly drop, it would basically be just a /22 instead of a very detailed and specifically documented prefix where people can learn from the database what is used for what.
MARCO SCHMIDT: Thank you. Just to be clear, at least I am not trying to take away legacy, theres a very good reason it's there and used by you at oned to point out the challenges around accuracy.
HANS PETTER HOLEN: This problem has many dimensions. I just heard, you know, a feature mentioned I hasn't thought about in the RIPE Database that you can do something with legacy that you can't do with PI? Why? That can be easily be fixed by adding more features to the RIPE Database, it has nothing to do with legacy or not per se. We had things mentioned from the charging scheme task force, you know, how should they pay? Should they pay and how would they possibly pay without contract? What I'm curious to understand is that if you are a so‑called legacy holder, whatever that means, one definition is that you receive this space from IANA directly before the RIR system or you received this space from Internet before the RIPE NCC was set up, then how do you guarantee uniqueness today? What the RIPE NCC offers is a registration in a database under a contract. So it's a right to registration. So, if you don't have a contract with one of the RIRs, how do you ensure that that space isn't registered to somebody else? Right? And that's what the value proposition of having some kind of contract is, and then of course it's the funding side of that, are you willing to chip in to keep this system running? And you can say that I am biased because you know I need your money and I would like some order in my database. But I think those are kind of, to me, important elements that should be thought about for the future, and having address space in the database that don't link to an org object, that doesn't sound right to the computer scientist in me that is still there several layers down. Maybe there should be an org object there that says the identity of this organisation has not been identified, in 1978, they said they were X, right, that's the fact that we know but since then they have not been able to determine who they are. Maybe that should be out there transparently because that's what we know about it. For somebody to come with an e‑mail from John Postel from 1978 or whatever saying that okay, I have the rights to that today and there haven't been 17 mergers and acquisitions and name changes in between. That's a hell of a job to verify today that you have, you know, you should the ones that have the right to register that in the database. That is what we're tacking about. Marco said we had the successful tenure of legacy policy. No, we ever kind of failed to clean up this space in ten years, it's a quarter left. How do we clean up the rest, I am not talking about taking it away from everybody. I am talking about getting an accurate registry of who has the register right to use it.
LEO VEGODA: Hans Petter you were the last person to speak before the coffee break. We do have an Open Mic session scheduled at the end of the next session after the coffee break, so, if you weren't heard right now, that doesn't mean that you won't be heard today. So, you know, that all very much. Coffee and be back in half an hour.
(Applause)
.
Coffee break.
.
