Address Policy Working Group
18 May 2022
10:30 a.m.
JAMES KENNEDY: Hi everyone, welcome to the second half of the Address Policy Working Group session this morning. After a quick coffee break, over the next hour we will cover the following agenda items. So, Marco will give us an update from the RIPE NCC's Registry Services, followed by a Q&A. Then we have a concept policy proposal, extra emphasis on the word "Concept" and that's from Jurune and then we'll have a discussion on the IPv4 waiting list, which Erik will moderate and then we'll have some time left over for Q&A ‑‑ sorry, AOB, open mic, so if there is any topics we haven't covered at any stage this morning, that will be the ideal time to raise it and we can have a discussion. So, without further ado, I'll welcome Marco to the stage.
MARCO SCHMIDT: Good morning everyone. For the ones who don't know me, my name is Marco Schmidt, I am one the assistant administrators of the RIPE NCC Services. I am really glad to be back and it's a long time, good to see all of you and I am also happy to give you the latest feedback from the Registry Services and hopefully some useful input for your ongoing discussions about policies and other topics.
I have quite a long list and not so much time, so I rather keep it short. So I want to talk about the IPv4 waiting list. And if you remember the agenda that James just showed, there is a separate agenda item, G, that will be discussed later, and I hope I can provide you some useful data for this discussion.
A quick update on IPv6 stockpiling, Gert just mentioned it as a sub‑part of his presentation and it was presented at the last RIPE meeting. Then I want to talk a bit about observation that is we have for temporary assignments, and another last item is observations that we see about updates of provider independent resources, IPv4 in particular.
But, without further ado I want to talk a bit about IPv4 waiting list. There is a policy in place actually since 2019 that only new LIRs can get one /24 from the RIPE NCC if they never have got any other IPv4 address space from us, but until November last year actually, there was more supply than demand, so actually LIRs, except for a very short period, we had to wait. But this changed during 2021, we saw a sky rocketing amount of requests, and then in November it happened that basically we had nothing in our pool immediately available. So LIRs had to wait up and you'll see it kept on growing since then. We have now more than 800 LIRs in the waiting queue and also the time that the LIRs have been waiting already keeps on increasing. These two datasets you can find our our website and what you cannot find on our website is the last graph, it's very weak pulse at the bottom, this is the amount of IPv4 we were handing out over time. So you see one bigger peak that was in middle of January. This was six months after we deregistered quite some space due to non‑payment of members, but besides that you see now and then some little bumps of maybe 10 or 20 allocations, and some else just for a long time nothing and maybe just some days we just give out a single /24 to the next one on the waiting list.
But still, all in all, since mid‑November, we handed out more than 650 IPv4 allocations, and to give a bit more details on that one. It took us about one month just so satisfy the needs or the requests that came on on the first day that LIRs had to wait and it took us another five months to satisfy all the requests that came in in the first 30 days. And right now, at this moment, the first LIRs in line, so that we'll get the next /24s that become free, waiting there since the end of December.
Now, looking a bit forward, in the next six months, we will hand out around 260 /24 allocations and that's basically all the recycled pool that we have right now. If you are a new LIR and you are on the wasting list and your no, ma'am is lower than 260, then congratulations you can start planning you will get some address space. And a bit more details where this space came from. It came from 27 allocations and actually the bigger amount came from PI assignments, because we have an ongoing project where we follow up to improve the registration details on independent resources and in this process we discovered well a couple of end user that went out of business that abandoned their resources so we deregistered them.
And if you are on the waiting list and your number is higher than 260, then at this moment, we don't have your future allocation yet. So we are still depending on address space that we deregister.
And at this moment, we deregister on average the equivalent of 40 allocations per month, but this number is decreasing. And of course the big question for somebody who wants to join the waiting list is how long they have to wait. And factor everything into account, currently it's realistic that you will have to wait for 18 months ‑‑ one‑and‑a‑half years.
One of the reasons for this waiting list is an issue that we said at the last RIPE meeting in our region, the organisation can open multiple LIR accounts and as per policy each LIR is entitled to go to the waiting list. In December, 2021, I presented some numbers to the mailing list of the Address Policy and back then only one quarter of the people on the waiting list were, let's say, real newcomers so one organisation with one LIR will get one /24 and the fast amount were organisations that were multiple times at the waiting list. Now, it has changed a little bit, so we might notice about half of the people are real newcomers, LIRs and the others are still multiple times on the waiting list. The changes mostly related that in December there was still the leftovers of the multiple LIRs rushing to get IPv4 while it was still available before the waiting list, so we still have this situation that real newcomers have to wait longer because there are so many multiple LIR accounts in front of them. And why they do that, just a simple question of cost basically. If you look right now at the market, to get a /24 and compare it with the annual fees at this moment that you have to pay for the RIPE NCC, you actually can afford to wait a significant time and it's still cheaper, assuming the prices for IPv4 will not go down, than getting it on the market. Actually there is a conflict with the waiting list policy, because this was clearly identified as something that should give the opportunity for real newcomers to get a bit of IPv4.
So, at the end of my presentation, there is always a possibility for questions and answers. However, I would suggest, as this is a separate agenda item, G, if you have any comments to this topic, keep it for now and once we will discuss about the waiting list at agenda item G, you can bring it up.
Another topic that I wanted to bring and I actually will keep it very short for the time and also Gert actually talked about it is a quick update about IPv6 and some effects we see there about stockpiling that we, like Gert said, is easier for some organisations to just open multiple accounts and get a /29 allocation instead of justifying larger blocks, which is quite cumbersome at this moment.
This is an overview of how the development went over the last two years about, and you see there was quite a peak of requests, by the end of last year, and you'll see the different colours indicate if it's for an organisation with one account or with multiple. And you see the blue one, one account that's pretty stable, with around 100 per month, and there was a huge peak at the end of last year which was related to the same rush of IPv4, and it has now gone down, but still about 20% of IPv6 allocation requests we get go to organisations that hold already allocations before. So all these little issues that we raised still exist, but also I want to ‑‑ don't go too much into detail at this moment because I understand there is some plans to look and can we make it easier to get bigger blocks or some other ways.
Which brings me to the next topic that I want to present to you. It's about temporary assignments. There has been discussion at the beginning of this year, at the mailing list, to point out some limitations, but also some weakness in the current temporary assignment policy. So just as a reminder for the ones that might not know this policy, if you have a need, a temporary need for an experiment, you can request address space, IPv4, IPv6 and AS numbers from the RIPE NCC. And a limitation there is that you need to show utilisation of at least 50% for IPv4, which in some experiments it's difficult because you might just need a few IPs but you need to have them from a routable prefix, and the weakness is that if you read the text in the policy, which I'm not doing right now, but basically it says there is no limitation, almost no limitation for what it can be used for.
I was looking a little bit at the numbers, and asked my team to dig them out to compare how many requests we have received for temporary assignments in the last three years, and actually how many we have been able to approve, and you see quite a big discrepancy there, so almost 200 requests have been received but only a bit more than 40 were approvable.
You also see quite ‑‑ well, quite logically, that in 2019, there were more temporary assignments than in the last two years, which is related to Covid, because temporary assignments are partially given for conferences and as you know in the last two years there were not so many conferences.
.
You also might be wondering what are those requests that can't be approved or couldn't be succeeded. A couple of them have been cancelled, simply, also again due to Covid, but also a significant amount of requests that people who want to have address space for the maximum time of 12 months but they couldn't fulfil requirements, for example, the policy asked them then the aim of their experiment of their research must be published before, and also the results must be published afterwards, but those requests are sometimes to re‑number a network for 12 months, or to give address space to broadband customers for 12 months to see how they behave in the Internet, so not something that is an experiment, but maybe just a way to see if they can get some IPv4 via this way.
A bit more details on the resources that you have provided. So, the amount of resources equals between conferences and research purposes, quite some IPv4, usually smaller block /24s, shareholder 23, but also a couple of big ones. And if we look at the duration of those assignments, you quite clearly see there is something popular one month which is often a conference, an event, and/or even 12 months, which longer term experiments research purposes.
So, what can we conclude from it and also, we have a few questions for you. So, overall, the policy seems to be working, but it creates a bit of extra work for the RIPE NCC, because you saw three quarters of the requests don't succeed. We would like also to know from you, are we doing a good job the way how we are handling right now those requests? Or is there maybe a policy specification needed to be more strict or to give more guidance to the RIPE NCC?
And is there, maybe, the need for a minimum assignment size for IPv4? Because, again, we get quite some requests, a few IPs they need a /24 and that conflicts with the utilisation requirement that the policy has right now, so far we always managed with some flexibility to give this address space, but it didn't feel fully right and, yeah, there might be some improvement needed.
Moving on, that is the last update, or the last topic that I want to talk about, and it's a bit complex, so I tried to visualise it with a little, a little animation which does not work I see right now because normally it should build up one by one, so I will try to talk you through and maybe I can use this pointer now.
Okay, just imagine we are here at one point in time and we have an IPv4 PI holder A, and they sell, or they sub‑sign the whole or part of their PI assignment to a company C. And we are not informed about it. So we don't know about it. Later in time, this organisation ceases to exist, it's liquidated, goes out of business, it's been taken over, there is a legal successor. Still, the RIPE NCC doesn't know about it. But later, we find out because we have the duty for correct registration, and we have been informed and/or we find out our self and then what we have to do is to update the resource holder to the correct legal successor of A, which is in this example, B.
However, in the current policy, if there is a change of holdership, it triggers for IPv4 a 24 months holding period, which means for 24 months, the address space cannot be really transferred to the actual user that has used this address space for all the time. And so there is quite a conflict with registration requirements, how we process them, what is needed, policy limitations of 24 months holding period, and for PI, you actually can't sub‑assign it, you can't give it to somebody else, you must use it yourself.
So, there are a couple of solutions on the table, or to be considered.
One is the current user is forced to stop using the address space because they are not the rightful resource holder, according to us, but that's not really desired because it's a live network, there are customers behind it.
Another option of course is that we ask that this PI assignment is converted to a PA allocation, that's possible. We do this all the time on request and then from PA you can make sub‑assignments. However, it means you need to be a member, and some of those PI holders, or most of them, are not.
In these two first options, they are possible right now, so they are in line with the current policies and procedures. However, none of them are really nice. Something to be considered is, would it be maybe make sense to look a bit more at the responsibilities of the sponsoring LIRs? Because actually, because they didn't inform us on time, we are in this, in this problem, or also the PI holder and the PI users in this problem. The current policy actually requires them to stay in touch and also to inform us, but some do it quite well, but other LIRs don't fulfil their duties, so maybe there is some enforcement. Also, earlier, for IPv6 it was also mentioned maybe the whole concept of pouring LIR being reviewed because not all of them do what they should do.
Another option would be to review the sub‑assignment ban that is currently on IPv4 PI. Is it really needed? Is it really what speaks against it or pro? And another option, and there is actually no preference and no ranking here, would be even to look at the 24 months holding period for IPv4 PI and 16‑bit AS numbers.
And that's the end of my presentation. Are there any questions or comments?
ERIK BAIS: Thank you Marco. Before we go to the questions. Can you go back one side? So, one of the topics that you have stated here is the sub‑assignment ban for v4 PI. It's interesting as an option. I think it will break‑even more with what we're doing currently for v6 and what we're trying to get there and, you know, try to make a third colour, not thinking that is going to be the option here.
If you go back to the animation which doesn't animate. In this case, do you have any merger and acquisitions here or is it just, you know, a company that goes from one legal entity type to another or purchased, whatever?
MARCO SCHMIDT: It's basically here, so here is a change of organisation structure.
ERIK BAIS: So change of organisation structure but the same company?
MARCO SCHMIDT: No. That would be ‑‑ really different organisation takeover, merger, yeah.
ERIK BAIS: Because the transfer policy does allow for merger and acquisitions, but still, the NCC needs to be updated and the question is: When will the NCC take the date for, you know, the 24 holding period? Because, that also resets the holding period with 24 months but that's the date of the M&A but not the date the NCC was informed and I believe that what you're stating here is that you have a different view on how that's being implemented, am I correct?
MARCO SCHMIDT: Yeah, to we take the date that we process that merger, because yeah, it's when we have been informed, yeah.
ERIK BAIS: I would have a different reading on that. I understand your position, but I would have a different reading because the M&A was actually done in the past. I have seen this before. I have had difficult discussions with customers on this. But this definitely needs some review. Questions? I see Gert at the mic.
GERT DOERING: Gert Döring. Sponsoring LIR for a couple of PI blocks.
I actually agree with Erik on the date. What we want to do with the holding period is to dampen certain effects but that is when the company is merged, not when the paperwork is done. So maybe this needs discussion.
This is my point. I have one question and that is about the PI space coming back to the waiting list. So, this is basically companies that disappear.
MARCO SCHMIDT: Yeah.
GERT DOERING: Because, I have been wondering where the addresses come from, and I assumed that nobody would be willing to just freely return space if they can have thousands of euros by selling them. But if they just disappear and you cannot reach them for, like, a year, then ‑‑
MARCO SCHMIDT: Exactly, so when we find out that a company ceased to exist, we actually do some effort to find out is there a legal successor, we describe to get contacts. If nothing is successful, we don't have indication that they just disappear and they abandon their resources, we take it back.
GERT DOERING: I thank you for that effort because that's what a registry does, but I'm sure this can be a real nightmare, lots of work and then somebody shows up and says yeah, but it's all mine and you are stealing it.
MARCO SCHMIDT: Yes.
GERT DOERING: On your last slide with the ‑‑ speaking as a sponsoring LIR, this is not actually that easy, because I have the LIR hat, we send a yearly invoice out to the customer. So at some point that invoice will come back with a letter that says oh we are not company A any more, we are now company B. Our accounting people will then do the paperwork and all future invoices will go to company B. I might want to actually see that. So, even on a very small company that does their LIR business seriously, that sort of information gets lost, so this is complicated.
I have no good suggestions how to address that, because even if you were sending me a mail every year that says "Is this still your customer?" I would just check the customer data and if it says yes and they are participating the invoices then I would return to you, yes. I'm not sure if I would remember to actually check the company names because companies get renamed all the time. So this is ‑‑ I have no good suggestion, but it's complicated.
MARCO SCHMIDT: It certainly S and I think ‑‑ I believe the original idea was indeed that an LIR would act like a registry and does quite some efforts, but it's not within the regular business of ‑‑
ERIK BAIS: I fully agree with Gert on this. We have the same thing as a sponsoring LIR for quite some resources, and it's not always clear at some points, or, you know, we also get the abuse‑c validation that, you know, we get an e‑mail, the e‑mail bounces, oh that's interesting, that was my contacts. You know, that kind of stuff. So, it's ‑‑ it's good that we have those checks in place, and, you know, it's definitely not an easy answer.
We have Peter at the mic.
PETER HESSLER: If you can go back to the temporary assignment slides. So, we're involved with a number of the KS computer clubs events and meetings that are being held, and we do request temporary assignments for I think ‑‑ one more back, there is a discussion somewhere ‑‑. And so we're ‑‑ we have gotten several temporary assignments in the past for various events that we hold. We are one of those that request and get a /16 because demonstrate usage because we have a lot of people showing up. I think one of the things that we have run into when requesting address space is the utilisation question, because we do separate quite a few users into VLANs and to different prefixes. But because there is a lot of end users, you cannot predict how many people will sit at the table and you can't predict how many people will be in that particular VLAN. So, we interpret it as 50% of the prefixes are, like, properly utilised and we have a reasonable, which is something that we take seriously but it's something we ourselves determine, of when we should allocate those, and we believe this is compliant with the requirements, is a slightly different interpretation than the one you are representing. And I think that this can also answer your question of a minimum assignment size. Assignment of smaller /24 is not useful. You can't announce it.
MARCO SCHMIDT: Exactly. But currently in the policy there is no minimum. Somebody needs one IP, strictly speaking as per policy they should get a/31.
ERIK BAIS: Let's table this for the mailing list for further discussion. Thank you Peter.
We do not have any questions online, so, thank you Marco.
(Applause)
JEROEN LAUWERS: Hello, my name is Jeroen Lauwers, I work for BGP network engineer. I want to present today a policy proposal that we are thinking to make. It's a pathologist proposal before we want to make an official proposal I think it's nice to share with the community to see what they think about it and to see what kind of feedback they have to give to make it better.
The policy proposal itself is about removing the mandatory IPv4 PA assignment.
The RIPE Database task force did not research last year, we did research to make some conclusions, one of them are since the existing LIRs are not eligible to request additional IPv4 prefixes, the requirement PA assignments in the RIPE Database are partly obsolete. The application of the IPv4 assignment registration policies in the RIPE Database are inconsistent.
Over half a million /32 assignments and over 16,000 PA assignments without any child PA assignments.
So the recommendation that the database requirement task force did from its research was to stop making mandatory IPv4 PA assignment for own usage. But keep it possible to assign it for the people or the LIRs that want to do that. And it strongly recommends, when you one step allocate, the resources to an another entity, to still do that.
So the main goal of this proposal is to minimalise the rules for the LIRs to what is needed. And don't obligate LIRs for rules that are not have a real purpose.
So the change that we want to make for it is to change the IPv4 PA assignment requirement from "Must" to "May" for the assignments for your own network.
It stays possible and it's also recommended to keep doing it, but it's just changing from must to may so if you want to think about it, then you don't have to do it.
It's still stays obligated for the sub‑allocated IPv4 resources when you want to do it to other entities. Legacy space, which is changed, is out of scope.
So the arguments that are supporting the proposal are that to justify additional IPv4 allocations to the RIPE NCC is obsolete now.
The application of IPv4 assignment registration policy is also inconsistent.
And resource holders that want to have a /24 have to ‑‑ are required to make at least two sub‑allocations of like /25 or smaller.
It's in line with the data consistency and minimisation principles and also for the LIR it gives more flexibility to choose what they want.
Arguments that are opposing this parole is that exceptions don't make the general policy more understandable. And it's a question of the public tracking arguments are weak enough for the policy to change.
So, the current policy text is "all assignments and allocations must be registered in the RIPE Database. This is necessary to ensure uniqueness and to support network operations.
Only allocations and assignments registered in the RIPE Database are considered valid. Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact, information, status, etc.) Must be correct at all times (i.e. they have to be maintained)."
.
We would like to thing this to the following:
"Allocations and assignments to the third parties must be registered in the RIPE Database to be considered valid. For IPv4 PA assignments used for the LIR's own network infrastructure, registration is recommended but not mandatory. This is necessary to ensure uniqueness and to support network operations.
Registration of objects in the database is the final step in making an allocation or assignment. Registration data (range, contact information, status, etc.) Which filled in the database, must be correct at all times."
.
So I want to thank you all for being here. Also for the people that helped me to make this proposal. And now it's time for people who have questions or feedback about it.
LEO VEGODA: Thank you very much for stepping forward and handling this recommendation that came out of the Database Requirements Task Force, and you volunteered to turn it into a concept for a policy proposal. It's a really simple question for people in the Working Group: Are there reasons that we need could keep what we have now or should we be considering a change? So, I can see that Gert is at the microphone. Would you like to speak?
GERT DOERING: Now you have a face for the e‑mails that you have been getting. First thing a disclaimer: I really appreciate that new people coming up and standing there and bringing forward the ideas, even if I don't like the actual idea, I really appreciate that you are entering the community. This is important.
That said, I still think the proposal is not the way to go, because basically, I don't agree with the problem statement and I don't agree with the solution. I don't think there is ‑‑ this is me speaking, not ex Working Group Chair, whatever ‑‑ I think whoever uses the address space needs to be documented. So there is no difference in that between some part of the same company is using this for their network, or another company is using it for their network, or service or whatever. It's I am the LIR and somebody is using my space and it might be the same company or not, so why should there be a difference in the policy requirements?
.
I see all the difficult bits like having a /24 that needs two 25s, but that is no different from me, as an LIR, getting a 24 from the waiting list and get IRR giving that to a customer and having to do two 25s. So, this is a database that you need to fix, not a policy issue. And changing the requirements for old space and customer space to have different strings attached makes things complicated without fixing the problem. And this is the main reason why I'm objecting because I don't think it's going to do good. I am not objecting to making assignments optional under certain conditions, that we do agree on, but I don't think the differentation is going to do go between own space and other space.
So if the proposal is, basically, stop registering personal data for admin context because they don't serve any useful purpose any more for all assignments I am all in. Just this specific one is not making me feel happy.
SPEAKER: Yes, because that's why I asked also the input for it to see what the rest of thinking, lifecycle I am also not good, so it's always good to hear extra information from it. Thank you.
SPEAKER: Maximilian. I fully support the proposal because as you described, I think that with small sub‑allocation just don't describe reality any more. So to the IPv4 shortage, we are implementing some very flexible assignments and basically our whole assignments in a single pool to be used anyway on the network at any time, so, having two device with two different rules doesn't reflect reality. So, thank you for the work.
PETER HESSLER: Peter Hessler from DENIC ‑‑ my concern here is that it feels like we are conflating two different problems and trying to solve a problem that is somewhere else in a policy, and what I see the underlying problem is that you cannot make an assignment of the same size as your allocation. And this is very obvious in a /24 case, because splitting up into two /25s is not appropriate. That is not what I am using this address space for, but this could also apply to larger allocation you got in the past, for example if you received a /19, that could simply be your backbone infrastructure assignment, and splitting that up into some, two/20s is an artificial restriction that is not reflective of what you have actually using this address space for and I think using a policy in this Working Group is the wrong way to solve that issue. So, I do agree with Gert's objections and I am against this proposal, but also as Gert said, thank you very much for bringing it to us and it's great to see, you know, new people coming to the mic and it is great.
DENIS WALKER: The issue of making an assignment the same size as an allocation is an issue on the radar of the Database Task Force ‑‑ Database Working Group. We have a solution on the table. It's ‑‑ some people support it, some people don't. But this is a technical issue rather than a policy issue.
Another issue I have with this particular proposal is I think you said yourself, you question whether there was still a need to document assignments. This is where, you know, I still have an issue with the Database Task Force, that they didn't look at the purposes of the RIPE Database in 2022. So, the question is still open about whether there is any need to document assignments. I accept fully that the Address Policy that currently says you need to document assignments in order to get further allocations is no longer a valid point, but is there a wider issue about why we have assignments documented in the RIPE Database? And until we answer that question, I find it difficult to consider whether we should remove certain elements of the assignments or not. So, I am still open on what the purposes of the RIPE Database is. I was heavily criticised at the last RIPE meeting for daring to suggest that we consider what the purposes of the database is. But until we answer these questions, you know, we can't answer deeper questions.
LEO VEGODA: Okay. Do we have any questions in the online question queue? We don't. In that case, thank you so much. We really appreciate you picking up the baton from the Database Task Force and volunteering and contributing.
(Applause)
I am now going to turn the microphone over to Erik who is going to lead the next discussion on the waiting list.
ERIK BAIS: Thank you. This is going to be an interesting one. IPv4, I don't have any slides by the way, so, sorry for that. I planned to have an open discussion here about the past discussion that we already had partly on the mailing list, also on the last meeting. We have had a couple of updates from the NCC about, and a short recap, you know, what kind of possible options we may see forward, what's going on.
So, when Sander wrote the policy for the waiting list, the intent of the policy was, as an LIR, as a new LIR, you can request one single /24, because that was the minimum allocation size at that point reduced from a 22, when it was just changed, and you can wait in line and get a /24, you know, when it's available. Currently we're seeing there were some other changes that were done to policy, Jordi and I had a policy change at some time where there was one LIR for ‑‑ was basically changed in the policy for organisation, and that had an effect on v6 requests. So, all that together, I would like to have the following, you know, part of the session have a discussion on, you know, can we fix the v6 part on that, the stockpiling discussion that Marco had, and what do we find as a working group about the multiple LIRs, and we have seen the stats, on do we want to make a change to the current policy? And I do not ‑‑ Menno ‑‑ can you put up the slide from Marco about the current waiting list policy page. Thank you.
Because, you know, that says how the current policy is ‑‑ that's it.
So, if we go to the intent of the waiting list. And we have seen the stats here with organisations opening multiple LIRs. And the waiting list implementation, the policy says to keep providing newcomers a minimum amount of v4 space as long as possible.
Now, so there is an option in this whole discussion that was also on the mailing list: How can we change this? Do we need to make changes to the holding time? So, you know, space that, you know, should, instead of 24 months, you need to keep it for five years. Do we need to exclude multiple LIR requesters to the waiting list. Do we strap the current waiting list to multiple LIR requesters, there are several options where there was not a real consensus that I could see, but it was obvious from my perspective, at least, that the Working Group had some ideas about, you know, where do we need to go on this.
There are still multiple LIR requests on the waiting list. We have seen already the predictions from our self, but also from Marco, that if you start today you might get some in one‑and‑a‑half years, because 18 months is currently the time that we project in waiting. So, for newcomers, you know, that's ages. If you want to start up and you want to start up next week, you know, there is no other recourse than go to the market. And, you know, that might not be ideal and we need to see do we need to fix this?
.
So this is basically where I would expect people on the mic, and ask them their opinion and have a discussion on this.
PETER HESSLER: Peter Hessler, formerly employed and so I joined the RIPE community as a brand new LIR quite a few years ago and we were a newcomer into the Internet space. It was a new‑ish company that needed to have some address space, so, we benefitted from the original last /8 policy and we are very grateful that we had the opportunity to do so. And I feel pretty strongly that the goal of providing newcomers, and I emphasise newcomers, is a critical part of this policy. I have had quite a bit of thought on this subject, and one, I haven't worked out how to phrase it exactly, and part of my motivation here is a deep inviting hatred of the transfers of address space from the last /8 policy. I find this offensive. I find it quite disgusting. And so, one of my ideas is to forbid transfers of waiting list allocations out from that LIR. That LIR will have to continue in perpetuity and you can transfer the LIR to another company if you need to, you know, businesses change and that's reasonable, but that allocation will need to pay the LIR fee for eternity, or until the address space is returned. And I think that is one mechanism that can be used to fight it because it's economically beneficial to just pay the fee for two years and transfer it.
ELVIS VELEA: What I was thinking to do is the proposal said that we should keep the last block for newcomers, so why not create a (something) system where if a company doesn't have LIRs, we get at the top of the list, if they have already one LIR, then they get a second spot. If they have two LIRs, they get lower and lower on the list based on how many LIRs they have. And therefore, they'll have to stay longer on the list with those LIRs.
ERIK BAIS: Yeah, so, if you look at the a system like this it makes things pretty difficult, complicated really quickly. We could also argue, so look at, you know, since the RIPE NCC is doing a lot of work on sanctions already and they do vet every single one of us, that means that there are tools in place to check who is the ultimate beneficial owner. And why not scrap everybody on the waiting list that is already in the LIR and you can see by (something) doing that. So I understand the option that you are providing Elvis, but I think it's going to be extremely complicated real soon.
ELVIS VELEA: Possibly.
ERIK BAIS: All right. Thanks.
KURT KAYSER: I would like to suggest to consider to strictly avoid competition with other RIRs on that topic, because I can see the potential that communicating a competitive situation with them they are having a more easy ways to provide waiting list options on a global scale, I think it has quite some danger if this is, let's say, more attractive on one RIR than on the others, or if it's not coordinated in some way, I think it is quite difficult.
ERIK BAIS: Are you saying we're too lenient or too strict at this point?
KURT KAYSER: I think it is good to see the developments are against the intent of the policy right now, but the solution should be in a way coordinated between the RIRs in the hope, because if this gets too loose, then it's like the wild west and it has high business impacts.
ERIK BAIS: Yeah, so if if we look at policy shopping, basically, as, you know, how we call it, there is always been a difference between the various RIRs. Some policies make it easier to do it in ARIN or, you know, when APNIC was running out initially, you know, but there are still the service regions and the amount of over spill between the RIRs is not so much. I don't think competition between RIRs is going to be a big issue, especially if we're looking here to strengthen the policy, to actually, you know, see if we can put something in place that makes it more into the intent of the initial policy author, then I think it's going to be more in line, and, you know, with the current status of v4, you know, we're scraping the barrel, it's not like people can get loads of space, that will be behind us.
HANS PETTER HOLEN: Managing director of the RIPE NCC. I was RIPE Chair when we discussed this the last time and maybe the times before as well, and the Board asked just recently for a recap of what happened then and what the discussion was and so on. So I think without speaking in favour of or against it, maybe it's actually useful to get the policy proposal on the table so that we can do an Impact Analysis of that, because I think there are ‑‑ your idea of using the same engine that we use for sanctions and so on, yes, nice theoretical ones, but there may be manual work loads assess with that that we have learned from sanctions and we'll hear from Athina on that, there is a mechanical problematic flag but there are a significant number of hours of legal work afterwards to determine whether something is significant control or whatever.
So, having a policy proposal on the table so that the RIPE NCC can come in and do an Impact Analysis may be a way forward to get all of these aspects on the table for a discussion or the Working Group asking us to do an impact assessment of multiple options can also be a way forward. Because I think it's an important discussion to have what you bring up now.
ERIK BAIS: I think it was, for us, as Chairs, it was important enough for us to have this discussion, especially thins we can all be here in the room for most of us at least, and I think it was important enough to take it from the list back to the meeting and be able to discuss it here and also outside. What you are saying, if if I want to recap that is maybe we should ask the NCC on the various options and see if we can do, you know, a light Impact Analysis on that, and then based on that, decide, go back with the mailing list and have a discussion on it. Interesting.
HANS PETTER HOLEN: I think that's an interesting thought because from last time, shell companies, leasing, I mean there are all these kinds of aspects that touches on this, and I think that needs to be on the table when you decide on a new policy.
ERIK BAIS: Obviously. Yes, definitely, yes. Thank you.
SPEAKER: Wolfgang. Some generic comments on the policy. I think as long as we have a policy that makes it possible to make a profit by applying to the mailing list or whatever we put in place instead, there will be people gaining in the system. And our policy development process is much slower and the movement in prices for IPv4 addresses. So, we will not be able to set a policy that builds a ‑‑ in a way that ‑‑ it's very difficult to set a policy that makes it impossible to make a profit. So...
ERIK BAIS: I understand. But if we're looking at the waiting list time, which is now 18 months, then the allocation gets allocated to the LIR, then there is two years of waiting. So, it is not just the 24 months that we're already waiting. The thing that is cost causing the most friction is that there are organisations requesting multiple LIRs, and with the current status of the reserve pool, they out run, basically, the pool, and the actual newcomers, what the intended policy was for, do not have any options, and if we want to fix that, then that's where I think should be the focus, because the waiting list itself will still have waiting time as well, and yes, you know, there is always, you know, when there is money to be made, then there is people to be found.
SPEAKER: That's true, well since the last ‑‑ the last time we had a RIPE meeting, a physical RIPE meeting, the going price for an IPv4 was about $20, today it's about $50. So, at the moment you can still make a profit by setting up a new company that's one just LIR and get the mailing list list even if you have to wait for three and a half years.
ERIK BAIS: Exactly. That's I didn't said maybe we need to have a look at.
* Ubel's who is the actual ultimately beneficial owner. So who is behind the company in stayed of just which company can is it. And that's where the tools might come in place. So, thanks.
SPEAKER: Jordi Palet asks, it should be much easier only for real newcomers like in other regions having already got any IP version 4 this allows any choices to opt for space through the waiting list.
SPEAKER: Harry Cross. I'd like to propose a sort of what Elvis said where instead of setting the priority in the queue based on how many allocations you already had, we instead think about splitting the queue and almost have a top priority queue full of people who have never had a byte of the cherry and then they can ‑‑ they get their space first and then whatever is left we can potentially think about allocating to those who have already had a go almost. And that would link into also the UBM checking to ensure that only verified newcomers almost get to go first.
ERIK BAIS: Yeah, so, by making two queues, basically, we need to do the first bit first and actually do a good vetting who is the actual Ubel * on a company requesting, you know, and joining the waiting list.
SPEAKER: I was just thinking ‑‑
ERIK BAIS: And the other solution is probably more elegant, but we need to have talk and see how that would work out.
SPEAKER: I know Hans was saying it's a bit complicated so I was just wondering was this the way to kind of cut through it.
ERIK BAIS: A bit of the mechanics. We'll definitely have a look at that. Okay. Thanks.
DENIS WALKER: Basically you're too late. The horse has bolted. There is no point locking the door now. Over the last two or three years, there have been several members across this region who have each set up dozens of shell companies, each with 10, 20, 30, 40 LIRs, who have swept up literally hundreds of /24s. There is no address space left now. So I think it's pretty pointless having to ‑‑ trying to create such a tight restrictive policy now when there is no address space left. It should have been done three years ago.
ERIK BAIS: Thank you.
JAMES KENNEDY: We have another contribution from Elvis.
ERIK BAIS: Can we get audio for Elvis.
ELVIS VELEA: So, the problem is the moment we start doing something in policy, the people that will profit from IP addresses will have already found a way around it. So, indeed finding the UBN would be a tremendous task, and they would create just new companies and try to fake their way into the top. And that was the only thing I wanted to say.
ERIK BAIS: Okay. Thank you. Any other remarks? I see Peter running to the mic.
PETER HESSLER: I just want to comment that just because it's hard doesn't mean we shouldn't do it. And just because people could abuse the system doesn't mean we shouldn't do it. If they are going to be malicious and fraudulent, then we should make them act malicious and fraudulent and catch them and then potentially ban them from other activities.
ERIK BAIS: I fully agree with that because, you know, as you said, if it's hard, that's not a reason for not writing the right policy and I think that the operations that we do should be well in line with the intent of the policy and the Working Group here.
SPEAKER: Denish. I'll say something that I have said in other Working Group sessions. Simplify. Just keep it simple. And we talk about how long these things take. Why? Why can we not speed things up? I know that there are processes in place, but should we not be looking at a radical change here and maybe looking at speeding up the process?
ERIK BAIS: Yeah, so interesting enough, a couple of years ago during a GM, we saw the process of multiple LIRs coming up at some point, and I was ramping up ‑‑ that was right after the initial final /8 policy came in play, there was a decision at that time by the GM, or by the Board actually, to stop processing multiple LIR requests, and that was voted on on the meeting next to it. It was very effective. But, the reasoning behind it at that time was the setting up of multiple shell companies, and then, you know, it's harder to track who is doing what. Current circulation, with all this action being in place and things like that and the RIPE NCC already needing to have those kind of tools, we may need to ‑‑ we may be able to use those tools and the information we get out of it for similar purposes. So I think it's time to actually revisit if this is something, you know, that we're going to try, in a year or now, or half a year, you know, it's probably sooner than later that we have got to do this, and, you know, looking at the reserve pool, there is still stuff deregistering. So, there is stuff still coming back, it may not be enough for everybody, but definitely, you know, if you are waiting on the waiting list and we can cut it shorter to nine months instead of 18 or 24 in a couple of times, you know, that would be good. That's at least what I'm thinking on it.
PETER HESSLER: I actually have a clarification question for Dinesh. You said that the processes are taking too long. Could you clarify what you mean by that? Like which processes? Is it like the amount of time v4 deregistration, the amount of time of clean‑up.
SPEAKER: I mean the policy process.
ERIK BAIS: Well one benefit of that, there is currently a new PDP process under review. I would definitely provide some feedback on that.
.
All right. Then I think we're going to close this session. We're slightly over time. Then, is there any other topic that we want to go, we're going to do this pretty quickly. One, two ‑‑ no?
Then, I would like to thank the stenographer, I didn't do that yet today, but thank you very much, and I would like to thank you all for attending and see you on the mailing list and see you next time in Belgrade. Thanks.
(Applause)
.
(Coffee break)
LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.
