Address Policy Working Group
Wednesday, 26th October 2022 at 9 a.m:
ERIK BAIS: Good morning, Working Group. It's a bit early, but we have a lot to process today, so let's get started. I have James Kennedy here on site and Leo is going to be online today. This is going to be a hybrid meeting, we have online chat and questions through Meetecho and obviously here in the room with the microphones for the session and also on the mailing list the code of conduct is designed to make everybody feel welcome. Please be polite in questions and answers and treat everybody with respect.
So on the agenda:
I am sure everybody have seen the agenda and did we miss anything? There is obviously at the end of the session there's the open mic and anything else, so ‑‑
The minutes from RIPE 84 were posted on August 5 and I did not hear or see any comments, any questions, any changes that are needed, otherwise we will accept them as final.
So, before starting I would like to thank the scribes here and the RIPE NCC for taking the minutes. We will start with the ASO‑AC update, have the policy update followed by Q&A with Angela, we will have a session 2022‑O2 for remove mandatory IPv4 PA assignment registration in the RIPE database. The author of the policy cannot be here so on his behalf James will take his stand and do a short presentation and a short recap. After that we will have registry services update from Marco, followed with some coffee. After that, we will definitely need ‑‑ we will definitely need that after that. Then we will have the IPv6 policy goals review process and Leo will do that, where are we, what are going to be the next steps, then we will have an open discussion about temporary IPv4 assignments, minimum assignment size, whether we need some inputs and whether we need to change what we currently have. After that, we have open mic and some time for discussion.
So, anything missing? No.
All right. That was a quick session. James.
JAMES KENNEDY: Good morning everyone. I have got the ASO‑AC update report for you.
So first a quick look at who is the ASO‑AC and what we do and how so it is the numbers NRO Numbers Council, essentially the advisory body for the ICANN and it is a group of 15 members, three representatives from each of the regional Internet registries, RIR regions, two are elected by the communities and the RIR associated company and one is appointed by the board of that RIR.
The process is observed by the RIRs and ICANN.
The term of office is different for each of the regions members, you can see that on the website and in the next slide a bit more detail and importantly, what are those responsibilities?
So the AC, the oversees global PDP, global policy development process, advises the ICANN board on Internet number resource matters, provides expert input about ongoing discussions, existing policies, what may be coming around the corner.
The AC also appoints board members to ‑‑ sorry, individuals to ICANN bodies such as the ICANN board, seats 9 and 10 and also the ICANN Nomcom and if that doesn't keep us busy enough, we have a lot of due diligence to do with our procedures to make sure we can conduct our business accordingly meetings with usually the first Wednesday of every month and also face‑to‑face annually, pandemic permitting, and I have to say this week has been a very productive when the whole AC got together for the first time since 2019 or something.
A quick look at the members, the current members, I won't go through them all individually. I have a list here of the members and their associated regions and their terms. Quick mention Kevin Blumberg was elected as the Chair of the AC, he represents the ARIN region and he selected Herve Clement from the RIPE NCC as his Vice Chair. So recent election or announcements so Gurav Cansal (phonetic) for APNIC has been elected to replace ‑‑ you will see a TBC in AFRINIC where our colleague Waffa stepped down in 2022 and that seat is pending appointment from the AFRINIC board.
So, the global PDP, there is a full process defined and available on the website, and I have included a link to that. Anyone within any of the RIRs can propose a global Internet policy and that needs to go through some guard‑rails that we oversee and, yeah, obviously the AC members are keeping abreast of policy discussions to see if there's any such topics being proposed or discussed and, yeah, if something does land, if a global policy proposal does land we have a team in place, which is Nicole, Martin, Sander, Saul and and George and I have included a list to the current list of global policies. There has not been a new policy in quite some years but it's good to review.
So transparent is very important to us, of course, and we take it seriously, so our annual face‑to‑face is open to observers so we got together this week on Monday and Tuesday 9:00 to 12:00 both days and lucky enough we had some people join as well, some observers, which is nice to see, always welcome, I am telling you after the event now it's a bit too late, the next meeting is the upcoming ICANN in March but I am not too sure, that's yet to be decided.
We have a mailing list archive and it's open to the public as well of course so minutes ‑‑ meeting minutes, open discussions are held there and anyone can access them. The monthly teleconferences as I said previously is usually the first Wednesday of every month at 12 p.m. UTC time, they are open to observers, anyone can come along and the website there is a published meeting calendar so you can see what's planned. At the end of every year the AC performs a review of our transparency to make sure we have provided enough visibility on our work and see if there's any improvements that can be made going forward.
So to the ICANN body appointments, so this year was the turn of seat 10, that entire process started in September last year when the call for nominations and conclude in May of this year. The entire process is available and published on‑line and the link that I have included, and big congratulations to Mr. Kaufmann, who you might recognise from the RIPE region. Seat number 9 is occupied by Alain Barrett from the AFRINIC region. His term started in 2021 and goes to 2024 and Brajesh Jain was reappointed to the ICANN Nomcom for next year, he also occupies that seat this year.
So, we are also conducting quite heavy workload at the moment which is reviewing the operating procedures so that's the guidelines, the guard‑rails of how we perform our work, you know, so that's something we have gone through quite a bit over the past couple of days in person and it kicked off that entire piece of work back in June of this year. We are targeting mid‑next year to complete, I think due to other timelines it will be March next year hopefully so we have assigned Working Group to carry out that work and it's led by Herve, myself, Ricardo, Mike and Sander.
Other upcoming activities include as I said earlier the annual transparency review, that will be performed and published at the end of this year. Yeah, there's an ASO independent review that's occasionally carried out, it needs to be done every few years, so it hasn't been carried out since 2017 and as we don't have any board elections to perform next year, this could be a good opportunity, might be an opportunity to perform that work but it's just a heads‑up, it's not confirmed at all, so if that does the green light we will go ahead with that and we will announce it.
And along with our other BAU responsibilities, overseeing the global PDP, keeping the ICANN board abreast of Internet number policy issues and appoint 2024 ICANN Nomcom delegate.
Thank you for your time. Any questions? Thank you.
(Applause)
ANGELA DALL'ARA: Good morning also from me, I know you are all excited for my presentation and I hope you got enough coffee, so from the global policy development we go a bit closer to us, to the regional policy development and today in the next 15 minutes I am going to give you an update a bit about what happened in the last months in our region, as a policy proposals, what happened in other regions and also a couple of information about similar topics that were common in multiple regions.
So, starting from our region, first I show you that after a couple of years of very, how can I say, low participation, 2021 I think it was mostly due to the pandemic. Now we are getting a bit up with the numbers, I am very happy to say that we have now two policy proposals under discussion in our region. So let's hope that we get more motivated and we get more energy, more time, to be part of discussions.
So, now at the moment what we have open is new policy proposal in this Working Group, just presented is in the discussion phase. As you see from the title of the proposal, is about making the registration of IPv4 assignments optional and of course later on is going to be presented more in detail by James because unfortunately the author of the policy couldn't be with us and we greet him and wish him well. And so discussion phase, just to remind you is like any phase in the PDP, is a moment in which the proposal can be changed, keeping in consideration the feedback received.
And this is the second policy proposal we have this year, the first one is already in the review phase and the discussion phase for the first one is ending on the 4th November.
The second one is in the review phase, so this means that we have already a draft for the policy and we have already the impact analysis prepared for the RIPE NCC that has been published. This is under discussion in the Database Working Group and I think the session is tomorrow afternoon at 2 o'clock, if I am not wrong, in the main room. So I invite you also to participate because this is regarding the registration of personal data in the RIPE database, with, let's say, a different look at the privacy and also with let's say a suggestion for the RIPE NCC to verify that the new requirement for the registration are respected by everybody. So, considering that this is affecting every user of the database, I warmly invite you to participate in the discussion.
And also in the review phase the policy can still be changed in all the phases of the PDP, so it is important to express your opinion.
This is the page where you can find the summary of our policy proposals and, again, you can see how is the ‑‑ how is the proposal advancing in the PDP.
Again, the consensus is determined by the Working Group Chairs at the end of the review phase, so again, participate, express your opinions so the Working Group Chairs can have a good idea whether consensus is achieved or not.
For who is new to the PDP and doesn't have a lot of experience I think these are a couple of good basic documents in the sense that are providing the whole process for the PDP in our region. The code of conduct, we heard about it in ‑‑ during this meeting, it is important to communicate in a correct way with each other so please have a look if you didn't do it yet.
And a link to the Working Group mailing list. This is the only one region where discussions are happening in Working Groups so subscribe to the Working Group of your interest and here you can find all the links.
Let's have a look now what happened in the last months in our region. So, our colleague implemented some new policies in APNIC, in ARIN and in LACNIC. Having a look at APNIC, I changed the colour because what you see in white is mostly related to documentation, so let's say streamlining or simplifying the text of existing policy manuals. What is affecting a bit the usage of the resources, so new requirements, and in green is what is regarding the management of the resources by the RIR. So, you can see that ARIN was mostly busy with reviewing all the policy manual. And probably the ‑‑ I start from APNIC, so AS to customers in APNIC it means that even if the end user is changing the connectivity provider it can keep his ASN, also when he is becoming a member of APNIC, and this you can imagine in our region could be comparable when it's changing sponsoring LIR or something like that, and proposal 144 instead is reserving a pool, a /21 for experimental allocations for five years, so until ‑‑ because it's been accepted and implemented this year until 2027.
The first one in ARIN can be interesting because they are specifying much better, much clearly the requirements to qualify for a public ASN, the other one are really editorial changes.
And then in LACNIC, this is actually a specification saying when a transfer is failing, the offering party doesn't have to return the space to LACNIC, in practice this was already happening, so it is not a new procedure but it is much more clearly stated in the policy.
Awaiting implementation are two proposals about RPKI, ROAs, in AFRINIC and LACNIC, the first one is really the AS 0 for unallocated and unassigned AFRINIC address space. And AFRINIC is asking just at the end of September, asked for experts that want to cooperate, helping with implementation. So if you are up to it, please do.
And in LACNIC also the recipients, so the holders of delegated blocks, so some allocation are now able to ‑‑ should be able, after implementation, to sign ROAs. This is something that in our region is not happening because you need to be the holder of the allocation or of the PI.
Then we have a couple of policies that have been accepted but are waiting for authentication for the boards and this was already in ‑‑ it's going to happen when the board in AFRINIC is going to be reconstituted, I assume, and in APNIC these are mostly ‑‑ they are making a document with all the definitions as one allocation for all the definitions and the second one was some conflicting words. I don't read you all the policies because I think you want to get out alive from here.
So, under discussion there are really many, many, many subjects, so I just made a summary here because, as I said, ARIN is very busy cleaning up its documentation, you can see about transfer, leasing, registration of objects, documentation and so on so they have more than 12 or 14 policy proposals under discussion.
Then we have LACNIC, that is having a couple of proposals under discussion about these subjects, leasing, PDP, a review also of the documentation and the management of resources. Specifically, I saw that, yesterday, there was the first consensus declared on the return of resources dedicated to critical infrastructure, to the same reserved pool. This was not specified so this is a policy that is...
And then we have ARIN that has some policies that you saw before still under discussion, and APNIC at the moment doesn't have ‑‑ they just implemented the last policies
Going to the similar topics we saw in different regions, I stole the title from somebody that posted that this is Spanish in the LACNIC mailing list, I hope it doesn't ‑‑ he is not getting offended, I liked it, we had the same policy proposal presented in three regions, and ARIN and LACNIC is still under discussion and in APNIC it's possible to present a new version because the first one didn't receive yet consensus.
So, actually, what these proposals are saying is that if there is no direct connectivity, the sub‑assignment or sub‑allocation of addresses is not supposed to be allowed. Of course there are different opinions and Marco is going to go ‑‑ is going to tell us more later about the situation also, how we handle the subject in our region.
And another subject is about unused legacy resources, there was not a policy proposal in this ‑‑ on this topic in ARIN but it was discussed very intense civil, so the ‑‑ APNIC there was a policy proposal again let's see if a new version is going to be presented. To give the RIR the possibility to retrieve leg resources that are not used. Of course, you know, all which can be ‑‑ not you know all, the discussion is which are the constraints for the RIR and which can be ‑‑ what can be done, and of course not everybody agrees on the idea to retrieve them.
In APNIC, I just want to tell you if somebody is a member there or somebody has resources there, that from January, 1st January '23, holders of legacy resources must become ‑‑ must go under contract, put these resources under contract with APNIC as member or no member, in order ‑‑ if they want to keep the registration services open. So, after a certain amount of time, the ‑‑ this legacy resources are going to be ‑‑ are not going to be present in the Whois any more and they are also going to be put in IS 0 as reserve space.
I leave you with useful links, now, I am going to start regarding them all one letter by letter, I am joking. And the first one is the RIR comparative policy review, is updated every three months. So this is giving the main differences between policies in all RIRs. Of course, for details, I suggest you to contact each RIR and have better information. This is just a main guideline.
And then you have the policy proceedings and the policy manual for each RIR.
And with this, I am at the end of my presentation, I wonder if you have any questions? No. So, thank you very much.
(Applause)
ERIK BAIS: Not so fast, not so fast.
ANGELA DALL'ARA: Oh.
ERIK BAIS: We do not have a question online from but a suggestion: Angela, yes, all the APNIC proposals will get a new version soon.
ANGELA DALL'ARA: Okay. I didn't see anything so thank you, Jordi, for this additional information.
ERIK BAIS: Thank you. No further questions.
ANGELA DALL'ARA: Okay.
ERIK BAIS: And James again.
JAMES KENNEDY: So the author unfortunately as I said, cannot be here, so I have ‑‑ for full transparency, so I am as co‑chair going to not be involved in the evaluating of this policy proposal when it comes to consensus, and analysis, things like this, so I am hats off for that. And I can speak on behalf of the author as such but we have been in contact over the past couple of years of course and I have thrown some slides together on what my interpretation of where things are and, yeah, the goal being just to give a good introduction and open the floor to discussion on the topics.
So, just to let you know what stage of the policy development process the proposal is actually in at the moment, so it's in Phase 2 of 4, the discussion phase, that's a four‑week window where the community discusses the policy proposal. We are now in week 3, so actually I think it's Wednesday next week it will be the final day for, yeah, for this discussion phase. According to the policies ‑‑ the policy development process, if significant comment and there has been in this one, the author can create a new version and start a new discussion phase. And if it does get to a stage of general support, the author will ‑‑ would draft a RIPE document of how it would look in policy and if in agreement with the evaluating chair or chairs, it will go to the review phase. The RIPE NCC will perform an impact analysis.
So, again, my interpretation of the intent of the proposal as such is to allow LIRs to document only information that is needed for operational and administrative purposes in the RIPE database.
And that any other information should be optional to register.
To not force LIRs to create and maintain duplicate data in the RIPE database.
And to reduce administrative overhead for LIRs to manage duplicate data and reduce RIPE NCC workload through audits and whatnot.
So the policy proposal text itself is pretty long, I have included a link at the end, but in essence, the key sentence is the first one "registering sub‑allocations and assignments in the RIPE database is strongly recommended but not mandatory."
So it's a change from must be registered to not mandatory.
And yeah, an observation from last week as well, so in the RIPE database as of 18th October, contained, yeah, just over 60,000 top level IP version PA allocations. Of those allocations, 42,000 contained an assignment, as you would expect, about 3 ‑‑ or two‑thirds; 3 .5 thousand create ‑‑ contain no assignment or route objects, so, you know, maybe they were allocated recently, maybe they are not yet in use, that's fine, that's normal; but interestingly enough, in orange, which occupies almost a quarter of all of the allocations in the RIPE database, contain no assignment but are covered by a route object which would like you to interpret that are they in use? They seem to be in use. So current policy would require those LIRs, those holding LIRs to register at least 14.7 thousand additional assignments in the RIPE database, just open facts.
Community feedback so far:
So let's acknowledge those, it's important to see what the community thinks. So assignments are necessary to document who is operating a block of IP addresses and to document the contact for administrative and technical issues relating to that IP space such as abuse handling.
More feedback was that more information is required to support the argument of actually alleviating administrative burden.
LIRs are obliged to register or should be obliged to register assignments if visible out the LIR's network or if used by a customer, otherwise assignments registration should be at the LIR's discretion.
The proposal does not adequately describe data consistency, data minimisation and accuracy principles as in reference to in the RIPE database requirement Task Force.
And another was to explain to LIRs what the community really expects them to register in RIPE database in a best common practices document. So obviously the full discussion is available on the mailing list but there's some ‑‑ just some of the feedback so far.
And it's pretty much it. Now, at this stage it's ‑‑ let's continue the discussion. You know, is there support towards the author's intent? Can the current situation or policy and/or policy be improved? If so, what would be your suggestions? What is your observations, what is your opinions, how are you feeling? Over to you guys.
ERIK BAIS: Not all at once. We will start with Sander and then I have two comments on the Q&A.
SANDER STEFFANN: Thank you for the presentation, what I really agree with at the moment you said it was like yes, is when you said ‑‑ when you said that everything visible externally should be documented in RIPE database, I think that's ‑‑ that is an absolute minimum. However, I think we already have that, because if it's externally visible there's probably the route object for it and if there's object for it there ‑‑
JAMES KENNEDY: We are focusing on IPv4.
SANDER STEFFANN: In general, if there's a route object there must be an inetnum object?
JAMES KENNEDY: No the allocation is enough.
SANDER STEFFANN: I would definitely put that in as a minimum requirement ‑‑ it's complex database, so if something goes wrong people can see who to contact, who is responsible, if the LIR is ‑‑ knowingly, willingly, taking full responsibility to the single contact point for all its customers, I think that's a business decision so I think we should at least allow for that but externally visible must be documented is I think the minimum.
ERIK BAIS: I have two remarks from ‑‑ online, one is from Kurt Kaiser: Is the logic correct, if routed equals used, if not assigned, is not shown as used? So, this also plays into the question from Sander Steffann, when are we going to say this address space is used, is that ‑‑ there is a valid route object or is it going to be on assignment? Then we have ‑‑ this is the ‑‑
JAMES KENNEDY: On that point as well, maybe the auth object was created before being announced but a quarter of all allocations, it's an interesting number.
ELVIS VELEA: Assignment should be registered only if required by the end user or if the LIR wants to delegate some administrative abuse or decision to a third party. So, that's it.
PETER KOCH: This is Peter Koch I was a member of the new dissolved Task Force, it doesn't give me any more wisdom but fading memory permitting I might have some perspective or additional information. So I am not going to answer the question about the author's intent because I don't know, I am missing a couple of things here, the Task Force report made a subtle or a not so subtle distinction between the database and the registry and I think that difference and the commonalities aren't reflected in the proposal in a way that would help making a decision.
Second, while the author points to the database Task Force report and the recommendations it is not my perception that the proposal itself reflects the recommendation, that is fine because it doesn't have to, but I want to avoid the impression that this is now a proposal to implement what the database Task Force recommended. We did make a recommendation to the ‑‑ on the assignments and following the observation of an symmetry, and please don't say inconsistency, that means something different in a database context, so asymmetry in depth and volume of usage by various LIRs and as someone has said already in the mailing list discussion maybe a policy proposal isn't the right way to go there.
A different remark based on the process may be the ‑‑ in the recent month, the Chair team has, with community support and after long community consultation, issued a, say, clarification to the PDP and that clarification very strongly suggested that the policy proposal be the result of already in‑depth discussion. This proposal seems to come a bit out of the blue and then put things together that might not belong together so I would urge the Chairs to think about their gate keeping and steering function in this regard.
Finally, I don't think this proposal is going anywhere, and, unfortunately, the process is biased towards stumbling forward so I would suggest putting an end to this and think about the problems identified in the subsequent discussion. Thank you.
ERIK BAIS: Thanks, Peter. The policy proposal itself or the intent for creating a policy proposal was discussed during the last RIPE meeting in Berlin. It was not a policy proposal as such at that time. That came later.
PETER KOCH: Fair enough, but since Berlin, there's only been very little discussion on the list that would support the general direction of the proposal and the problem statement that needs to be faced. A couple of people have mentioned their own surprise about the proposal and also I think two or three people said this is not ‑‑ this is not addressing the problem it seems to identify. And ‑‑ enough said.
JAMES KENNEDY: I can't speak on behalf of the author but from my view, I believe that he used Berlin to get as much feedback as possible. Again, yeah, that could have been progressed on the mailing list since then before actually making a proposal but he did take into account the feedback and yeah, here we are, and also to confirm as well, so I was also on the database requirements Task Force with Peter and yeah, our recommendation is, as we say, inspired this proposal but definitely is not directly one for ‑‑ like for like, one‑to‑one.
ERIK BAIS: So we have an additional question online from Brian story: To clarify, is the proposal to no longer require the registration of any downstream end user enterprise or PA assignments?
JAMES KENNEDY: We can give our own interpretation but we can't speak on behalf ‑‑ the policy text is for any assignments, should be mandatory ‑‑ or sorry, should be not mandatory, should be optional. But yeah, from the feedback that he has received in the past few weeks and from my discussions with him, he has taken that into account so whether that specific ‑‑ the proposed policy text is one he wants to take on board but the intent seems to have changed since then. I don't know if we have got him online that can actually comment.
ERIK BAIS: We did did ‑‑ look at all the comments on the mailing list and the feedback that we received and if this is moving forward, we will definitely have to have a discussion with him, whether all assignments are not going to be mandatory or just the assignments for the resource holder for the allocation, which, in that case, would make probably more sense. That's also what we are feeling in the feedback that we are getting. But that's something that we need to discuss.
I have a question from Kurt, also online, Kurt Kaiser: I would like to split the main purpose of the documentation between customer data mainly assignments and network operated related data such as abuse‑c, admin‑c, RIPE NCC needs both data sets before but now, the very sensitive GDPR data to purpose may allow a different handling.
Yes, so for the ‑‑ this is not a GDPR topic. Yes, we are trying to minimise duplication of data, you know, and if the assignments are exactly the same in the amount of information as the information from the resource holder, it doesn't make any sense to actually duplicate the exact same information in an assignment as you would see for an allocation. That was at least my reading out of it.
But if you are adding different information and assigning two third parties and have different contacts, that kind of stuff, that information should at least to my knowledge, in how I read it, still be in the database: Any comments from you?
JAMES KENNEDY: No further comment. Anyone in the room?
ERIK BAIS: So we will definitely need to take this back to the mailing list. This is not going to be a done deal or something that is going to be proposed next week or get consensus on.
JAMES KENNEDY: We have got one more week for the discussion phase for feedback so, you know, please do contribute if you have any thoughts to, for, against, even if indifferent, it would be great to hear your opinion. Thank you.
ERIK BAIS: Yes. So please do voice your opinion also on the mailing list.
(Applause)
MARCO SCHMIDT: Good morning, everybody. I am the manager of registration services at the RIPE NCC, and in this feedback I would like to give you some information about observations that my team saw in the last couple of months and I want to ask for your feedback on those observations and potential suggestions.
I plan to talk about these three topics: The IPv4 waiting list, the IPv4 IXP pool and definition of assignment. There were a couple of more topics that have been discussed on the mailing list, for example, about temporary assignments and IPv6, but you saw earlier on the agenda there will be separate items in the second session of this Working Group so I decided to focus on those three topics.
First one is the IPv4 waiting list. And probably most of you know that end of last year, the request for IPv4 from new LIRs that can get a /24 from the RIPE NCC exceeded the supply that we had, so it means those LIRs had to go to the waiting list until some recycled address space becomes available to them and if you look at this graph which you also can find on our website, this waiting list keeps on growing. There was a steep increase at the beginning, end of last year, shortly interrupted by a bit of bigger release of address space in January and since then it's kept growing. There was some slow slow down during the summer period but it appears to be picking up again and we have LIRs to get /24 from the RIPE NCC.
As a result of course also the time that the LIRs have to wait keeps on constantly increasing, so the Orange line shows how many days the number 1 on the waiting list has been already waiting and it's now approaching almost 300 days.
Information that we are not showing on our website but I want to share with you is actually the amount of allocations we did hand out in the last eleven months and you will see it's quite significant. So constantly we usually counting time of around six months and consider it recycled and to be available to be handed out again, and so far we handed out 934 such allocations since November last year. And to put a bit of perspective, right now we are giving out allocations to LIRs that joined the waiting list at the end of January, and also to document a bit more the challenge of demand and supply, it took us five months to satisfy requests that have been received within one month so it just keeps on growing.
Now, looking forward, at this moment we have 426 /24 allocations in our pool, which looks not so bad but I want to point out this is related to a one time effect of deregistration because of non‑payment; every year, we have a couple of members that don't pay their bill and subsequently their membership is terminated and we take back resources.
If I try to show this in a bit graphic way how to ‑‑ how is our recycle pool composed you will see more than half at this moment is coming from non‑payment and a bit more than 200 for ‑‑ have deregistered for other reasons. Two‑thirds coming from previous IPv4 allocations and around one‑third from IPv4 PI assignments, because we have an ongoing project where we validate independent resource holder data and during this project we do find a couple of abandoned resources where ‑‑ which no resource holder exists without any successor.
Looking more forward, what to expect, in short we estimate there will be less and less IPv4 address space to be deregistered, I mentioned this IPv4 PI project where we validate accuracy. This comes to an end soon. Right now, we deregister 30 /24s every month but this is continue to go down and if you happen to join now the waiting list, it can be ‑‑ you can estimate that in around two years you might get a /24 from us. Quite a long time, right?
One reason for this long waiting time is the fact that every new LIR can join the waiting list, and members or organisations can open multiple LIR accounts and with each of those accounts join the waiting list. We reported on that one earlier a couple of times so in December last year so when the waiting list just start kicking up it was even three‑quarters that actually were on the waiting list but not really newcomers but rather an organisation that has already several accounts and eventually is on the waiting list or got address space before.
Right now, in percentage, it has changed a bit so around two‑thirds are now real newcomers, one organisation, one LIR and one‑third multiple LIR accounts. However if you look at total numbers it has not changed much because looking at the 10 plus LIRs we are right now at 12% which is 12% of 1,000 is around the same number like 50% of 300 so it is still significant and it does result in a delay for real newcomers because every multiple LIR account that is waiting on the waiting list means an additional one to two days more waiting for normal LIRs, so to call.
We have presented on this earlier. There was a wider sense oh this is not the intent of the policy because this /24s are for new LIRs only. However, not much happened on that one and I think I have an idea why and for this actually I want to ask here in the room for a show of hands: Who here in the room right now is at the waiting list and waiting to get a /24? One person, I think we had a proposer there. I think the problem that I see here, the people on the waiting list are newcomers, they are new to the IR system, they don't know much probably about the RIPE community, you see at least one person is here, they don't know much about the PDP so this problem is with people that are not familiar with the PDP. So, I just want to, again, pose the question here to the room: Do you want to accept the current situation, to say well, tough luck, IPv6 is the future and IPv4 is history or does somebody want to propose a change?
Moving on to the next topic, it's about IPv4 IXP pool and that's actually a nice success story because in 2019, we reported to the RIPE community that the original IXP pool which is a /16 as the dedicated pool for this critical infrastructure, will be depleted in 2022. The Working Group took action, there was a policy proposal discussed and consensus was reached and implemented to add another /16 to the pool for IXPs. And then here you can see how basically the pool has developed since so it is beautiful jump in 2019 you can see was due to this policy change and it was really good because if you forecast what would happen would you tell /16 quite punctual to this RIPE meeting we would have to announce there is no resources left for IXPs so it was a success story, I would say.
The vast amount of IXPs currently hold /24 assignments, there are a handful, 12, that get a /23 and one /22, and we do estimate at this moment that the pool will last until 2029.
We do see a slight increase in requests over the last few years which is also related to uptake of virtual IXPs. And overall, this is fine, we have seven years but we still thought it is good to bring this to your attention and just to have your consideration, is this current estimated lifetime acceptable? And if you would think okay no, they should be available for a longer time, is there the need for a policy change to somehow extend the lifetime?
And that brings me to the ‑‑ would you like ‑‑
SHANE KERR: I have a question about the IXP policy, so the IXP policy was originally created so that IXPs wouldn't have to go to an LIR, but so we are basically out of space so why don't they just buy space like everyone else? Why is there a special IXP policy any more?
MARCO SCHMIDT: I think that is something for the Working Group. I think it was always considered as a critical infrastructure there should be something available.
SHANE KERR: Everybody's infrastructure is critical to them. Okay, okay.
SANDER STEFFANN: Do you want to take questions now or should I save them for later?
MARCO SCHMIDT: Maybe let me talk about the last point and I am happy to get some feedback and I will hurry up because I know I am between you and the coffee break.
So the last topic that I want to discuss is something that Angela already informed you about, we have right now in three other regions discussions about leasing and that is not ‑‑ that is not allowed or should be not allowed and this is based on the proposer's understanding that an LIR making an assignment is only really an assignment if there is ‑‑ this is related to a direct connectivity service and if this is not the case, it would be leasing.
However, on the other side, it is our, RIPE NCC's, long term understanding that we don't have any definition of leasing so whatever relation there is between end user this qualifies to make an assignment and has worked well over the last 20 plus years. Because of those discussions in the other regions, let's have a look at the policies, what does our policy say and the IPv6 policy and IPv4 and IPv6 policy is short and sweet and basically say yeah, end user get an assignment from end user or LIR. The IPv4 policy on the other hand is a little bit ambiguous if you look down through the letters and I marked interesting parts in bold, so we have one sentence that states that an LIR assigns to downstream networks, so which could be seen as oh, indeed, there must be a connectivity. However, already in the next sentence there's a new term added, the end user so it can downstream network or end user and just only to later say, yeah, that LIRs assigned to end users and with services provided by the issuing LIR but not really a definition what kind of services are referred to that one.
And basically the questions that I want to pose here to the room is: Do you think that these services that an LIR is providing needs a further definition? Further clarification? Do ‑‑ does the RIPE Address Policy Working Group actually still support the RIPE NCC's long term understanding that that's just be flexible there? And either way, should there be some clarification made to the IPv4 policy?
And that's the end of my presentation and I am happy to take questions and feedback.
SANDER STEFFANN: 6 Connect. But also ex Working Group Chair. So let's start with the v4 policy that you talked about, I have been involved since the whole beginning of the soft landing, run‑out, whatever people want to call it, policies and I must say the fact that we still have some v4 to hand out, even if the waiting time is two years, is pretty amazing to me. I think our intent was not that ambitious so I think the policies have worked really well. I'm really getting to the point where I am like okay, you know, we extended the lifetime of v4 for so many years and we gave people so many opportunities that at some point the deck chairs have been properly rearranged.
So, I'm not saying we should not do anything there but I don't have a very strong feeling that we should either.
To go from there to ‑‑ to the IXP pool, I do think IXPs have an important role, so that ‑‑ I am still in favour of having a separate pool for that. Would it help, would it be possible to change the policy to ‑‑ in such a way that the RIPE NCC would just tell the RIPE NCC keep the pool at this minimum level and if it goes below that, use some of the returned resources to fill up the IXP pool? Because then we don't need to have discussions about adding stuff to IXP pool, we just had a minimum level and allow the NCC to do what it needs to do because I don't think we need to micro‑manage that and we can give the NCC some freedom here.
MARCO SCHMIDT: It would mean a policy change ‑‑
SANDER STEFFANN: It definitely would, let's do a policy change that explicitly allows the NCC to solve this without needing our intervention every time.
ERIK BAIS: I would like to make a short comment here.
SANDER STEFFANN: Am I being volunteered?
ERIK BAIS: Obviously, obviously. But every discussion that we want to make on the IXP pool we need to connect with the connect people because the majority of them are not here and the majority of the people that are involved in that specific receiving end of that policy are in the Connect Working Group so we need to volunteer, get their information, how do they see this moving up for a seven‑year period or is the consensus there, it is enough ‑‑
SANDER STEFFANN: When is their session, do you know?
ERIK BAIS: Probably today.
AUDIENCE SPEAKER: Right before lunch.
SANDER STEFFANN: I will go there and say the same thing there.
ERIK BAIS: Yes. So please refer to the slide there and at least have the discussion with the Working Group there also on the mailing list so that we can get their input and we can decide whether we need to make a change in there. All right. Last comment from you, we have others waiting as well.
SANDER STEFFANN: Last slide.
MARCO SCHMIDT: Definition of assignments.
SANDER STEFFANN: I vaguely remember a long, long time ago this was discussed at some point and I think it was intentional at the time to leave it a bit vague because there are so many different ways of providing a service to a customer. You have MPLS networks, these types, SRV 6, that's v6 but you get the point so there's so many different ways of providing a service and back in the day I kind of remember we intentionally didn't go into what that service then would be because then we would always be chasing reality.
We did put in that there has to be some service relation so I think the NCC according to the current wording could be a little bit stricter but I think ‑‑ if we want to ‑‑ if we want to tell the NCC to be a bit stricter we are going to have a really long policy development process in defining what that means so ‑‑
ERIK BAIS: It depends. Currently at least there's an invoicing service.
SANDER STEFFANN: Okay. That seems to qualify.
JAMES KENNEDY: We are four minutes into the coffee break.
SANDER STEFFANN: Sorry.
JAMES KENNEDY: It's great to have the discussion of course but we could go for five more minutes or have a break ‑‑ five more minutes? On the mailing list into the leasing discussion, since... ‑‑
AUDIENCE SPEAKER: And colours of the IPs have not really married.
DENIS WALKER: Denis Walker, co‑chair of the Database Working Group. I have a comment on leasing, first of all, I have no view on whether it should be allowed or not, that's not my interest, but what we have now is a situation where somebody with spare address space is asking third party companies to lease it out on their behalf, which may go to an LIR who sees it more as an allocation and then assigns it to some end user. None of this can be reflected in the RIPE database because you have a whole structure here that we simply is hidden out of view, so if we are going to allow it, that's fine, but then we should document it properly.
ERIK BAIS: Good comment, thank you, Denis.
AUDIENCE SPEAKER: Ricardo: I wanted to comment about the LIR definition. I interpreted it as local Internet registry like RIR is regional Internet registry, so basically, going deeper in this definition I don't find a strict relation between LIR and the services who is operated, very often the resources are associated to access offered by an operator to an Internet search provider or data centre so I don't see the needing of going deeper in the definition of an LIR because should reflect the fact that as the comment before said, give the right description on the database where the resources are in use and who is using the resource. So if this is consistent and correct, in my opinion it is ‑‑ is done.
ERIK BAIS: Thank you for your comment.
SANDER STEFFANN: I am sorry, I actually promised Erik I would bring this up during AOB which we don't have. I will be in a different room then.
ERIK BAIS: I know what you want ‑‑ okay. Thanks.
MARCO SCHMIDT: Thank you very much. I got what I need and now it's time for coffee I would say.
ERIK BAIS: Time for coffee, sorry.
(Applause)
