Archives

.
RIPE 86
Address Policy Working Group session
24 May 2023
10:30 a.m.
Detection
.


JAMES KENNEDY: It's 10:30, time to start the show. Welcome everyone to the Address Policy Working Group sessions here at the RIPE 86 in Rotterdam. Eye name is James Kennedy, and along with Mr. Leo Vegoda and Mr. Erik Bais we will be co‑chairing the sessions, thank you in advance to our stenographer and the scribes from the RIPE NCC.
So, we're having a hybrid meeting this time as we have for the last couple of meetings as well as you know. As well as being on the premises we have remote participation via th MeetechoE application so encourage everyone also in thee room to ope up your unique Meetecho linking. You have an e‑mail, just to keep abreast of the of the chat conversations thereadvance to Those of you who are remote, if you want to contribute and have questions asked out at the end of any gems, please write them in the questions section and one of the co‑chairs will read them out. Otherwise I think you also have a mic icon that you can click and you can read out your questions yourself to the room.

We want to make this as interactive as possible, today's sessions. We encourage everyone to share their opinions, thoughts, don't be shy, a healthy discussion and debate is a sign of a healthy Working Group.

A generally reminder, we do have a Code of Conduct that is essentially designed to make everyone feel welcome, have a safe space for everyone. In a nutshell, please be polite to others and treat everyone with respect, and I have included a link to the official Code of Conduct document.

So, a bit of housekeeping. Leo posted in November the minutes for our last session at RIPE 85, and we didn't receive any comments on the mailing list, so I'll give everyone an opportunity in the room and also online to flag any changes that you think are needed. Otherwise, we'll get some thumbs up or nods to accept that we have? Okay, we'll take it as that.

.
So the agenda, I shared that agenda two weeks ago on the mailing list. We didn't receive any feedback. I'll run through the agenda shortly, and if there is anything we missed, overlooked, please do flag it before we start.

The agenda itself:
So after this introduction. Erik will give us agenda item on the Chair selection. Followed by three familiar items to those who are regulars to the meeting. So first up is ASO AC update by Herve, followed by Marco who will give us a registry service update and there will be time for a Q&A at the end of his update. Then we have Angela who will have some updates on the policies that are ongoing. We will also have time for Q&A, and at the end of our first session, we have an outcome of the last meeting, his policy proposal as put forward, there was further discussion that was continued on the mailing list and there was a suggestion for an aggregated by LIR status for IPv4 assignments. I did receive some positive feedback on the mailing list back in October, November, and yes, you're Union will give us an update on what he and Tor have been collaborating on in the meantime.

Then we have 30 minutes for a coffee break, or whatever beverages you prefer. Then we'll come back at noon, we'll have an update from the authors of ongoing policy proposals. So first you up a Matthias, he will give us a review of 2023‑01, reducing IXP IPv4 assignment default size to a /26. Followed by Edwin, 2023‑02, minimum size for IPv4 temporary assignments.
And then Leo will lead us through a discussion on IPv6 policy review. This activity has been ongoing for the past year, so Leo is going to share some good updates and progress that suggestion.
And then at the end we'll have five minutes, estimated, for an AOB open mic. So if there is any topics that you'd like to share, any thoughts any ideas that you'd like to share with the community, with the Working Group, while we're all here together, that's the ideal opportunity to do so.

And that is it for the opening. So, if we're ready to proceed, Erik.

ERIK BAIS: Good morning everyone. We have a Chair selection to do. I do not have any slides for this, but that should be okay.

I have sent an e‑mail about this last week. As, you know, we have certain terms and when James Leo joined we went from two Chairs like we had before, Gert and myself, we suddenly had three Chairs, and I would like to suggest to the Working Group, if you all agree, to make a small change in the term that the new Chairs might do, and that has to do with the fact that we want to have a bit more stability and a rotation scheme for new Chairs to step down or reply.

So currently we have two years, and we would like to change that to three, and I would like to put that forward here today Working Group so that we can have each year have one Chair step down and somebody else or the same Chair to reply. And if there are any questions or objections on that, then please let us know.

So, that would mean that next year, my term will end, and we can have a new Chair selection. Then in the year after that, we can have either Leo or James step down and reply or somebody else, and after that, and by that we have a more stable system.

.
So, we have James, Leo stepping down, and they have both applied again to run for an additional term for either one we can do two years and the other one for three years. For me, any preferences, James? No. Leo? Then, James you can have the two years Leo you can have the three years and I would like to thank you for stepping up again, and if there are any objections or questions from the mic, from the room?

Then, a big round of applause for the new Chairs.

.
And then where is Herve?

HERVE CLEMENT: So, good morning everyone. So it's, I would say, the normal presentations regarding the ASO AC, so it's dedicated to the ASO one of the organisations of the ICANN, so it's the one dedicating to our addressing resources. The addressing supporting organisation is composed of two groups, so there is a group of the four current COs of the Internet registries so it's for the regional registry organisation part, and there is ASO AC address council, which is composed of people from the community, so it represents the community part of the council.
.
And so to be even a more complex, the AC ASO is also called the NL ON C, so knowing that so the group of the CO of the registry registries is called the NRO AC. So soen you are succeeding in having that so the ASO AC is composed evidence 15 people, so three from the different regions. Two are elected by the community and one by the Executive Board of the dedicated regional registry. The term of the office is different from one region to another. From the RIPE originally three years term, and what does it do, this ASO AC? It has a specific function, not a function of dealing with regional policies of course because it's something which is done in every region. But advise the ICANN Board because we could have questions to the numbering aspect, and I add colours to the last one because perhaps I can go to the next slide and I can go back to this one. So, you have the list of the current members of the ASO AC and the one you can see first that there is only one currently for the AFRINIC because you know that currently we have some governance issues because of the decision of the court of Mauritius and there's no possibility for AFRINIC to add any election until we have only one member, Solstein, and his term ends in 2023, so if the situation remains the same ‑‑ so after 2023, so we will have no AFRINIC representative and so there will be a problem, it could be a problem etc.
.
So the reason why, if I go there. So, I added some colours to the other functions. So we have the ASO AC transferses the global policy and development process. So global policy you know is a policy common to all the regions and dealing with the interaction between the IANA and the rest of the regions.
So, we have this role. And the composition and the number of people can have an impact to they say function and we have the role also to appoint two members of the executive, the Board of Directors of the ICANN and one member of the NomCom, and to have this election valid, we need to have a quorum around that's the reason why we have reading currently our operational procedures to be sure we can continue to fulfil best functions.
And then, so we meet remotely every month and we have normally one face‑to‑face meeting one year, so normally during an ICANN meeting.

So, yes, that's the current composition of the ASO AC. So you have with the start with the guy elected by the Executive Board of the different region. So, you have the Chair and the Vice‑Chair, there is somebody from the RIPE region is the Chair and we have, so Riccardo from LACNIC is Vice‑Chair and Nicole chain from the APNIC as well.

And to have a personal thing, so we have our, so a face‑to‑face meeting during the last ICANN meeting, ICANN 76 in Cancun and we were there and we have active work on the review of operational procedures as I mentioned just before.

So, as I said, so we have a role in over viewing the process of the global policy development. So, we added there the link to the process and to what are the current global policy, the last one was accepted in 2012 and it was about the fact that the IANA registry distributed every six months resources to its each. And so as it's our function to track if there is potentially a global policy proposal in the region, so we have people from the Council specifically tracking that. So you have here the name of the people. And so we have James for the RIPE NCC performing this job.

As in every community, as in like the RIPE NCC, the RIPE community etc., we pay a lot of attention about transparency. So all our conferences, meetings, etc. Are open to the public so you can completely attend remotely or physically if there is a physical meeting. There are archives of course, and there could be a closed session but the closed sessions are only dedicated to decision regarding the nominations, elections, etc.
.
And so we have every year, what is called a document which is called the Transparency Review, when we recall all the action that is we have performed during the year.

.
So, I talked about appointments. So here is current appointees. So we have ‑‑ so we elected the seat 9 ‑‑ seat 10, sorry for the ICANN Board of Directors, so it's Alan Barrett from the AFRINIC region, was this position, and it's Christian Kaufmann, know the representative for the seat 10. And his term will end in ICANN 78, if I am correct. It was on branch he shall Jane from the APNIC region and we are currently appointing the new member, a new member of the NomCom and the result will be public perhaps in one or two days so you will know who will be the next NomCom representative from the ASO AC.

.
Okay. And as I told, so we have a great and tough work regarding our review of operating procedures, specifically about the voting process, specifically of the definition of the quorum, so to be sure we can have the right to say, so we have chosen, so these people are the one etc., so we have made this job and stated that. So last year it was in Belgrade, we have continued that in conKuhne as well. There will be a proposal in June. There will be, after a discussion with the NRO AC and there will be a ‑‑ so it will be the first year it will be a face‑to‑face meeting ‑ it will by in Kyoto ‑‑ when we will complete this job. And there is a task force around that, so you have a name of the member. So from the RIPE region, so we are all part of this task force, so James, Sander and I and Riccardo from the LACNIC region shape the specific work.

And that's all. So if you have any question or remarks or etc., I am open for questions. Sebastian?

AUDIENCE SPEAKER: Thank you very much, Herve. The one who is Chair, I wanted to thank you for your report and also for the great attention you take to our organisation and to end user participating to our round table, at each ICANN meeting it's really very useful for us and important. And also, I would like, really ‑‑ I was very impressed by the meeting you set up during the ICANN, last ICANN meeting, it was really very useful and interesting. I hope that next time more people will come to your session but thank you for setting all that up. Thank you.

HERVE CLEMENT: So the meeting you were talking about was a joint meeting between us, so the ASO globally and the Board of Directors of the ICANN and the CUI as well.

ERIK BAIS: I have a question online from.

ELVIS VELEA: Any idea, prediction, on when the AFRINIC will be able to appoint members again?

HERVE CLEMENT: If I had the answer and the solution, I could give you, but so there are current actions so we say, so regarding the Supreme Court of Mauritius so we don't know if there will be a decision from the court to allow an election there, etc. But it's something which is in discussion and so we have no idea of when it could happen F the decision would be positive or negative etc., so absolutely no idea if it could happen or not.

ERIK BAIS: Thanks Herve. We have no further questions. Then I would like to have ‑‑
.
(Applause)
.
Next on stage we have Marco providing an update for RS. Thank you.

MARCO SCHMIDT: Good morning everybody. I just mentioned my name is Marco Schmidt I am the manager of Registration Services at the RIPE NCC and in this regular update, I would like to give you some information about some observations, some concerns that my team encountered during their daily work.

I want to talk very briefly, because I don't have so much time, about what's going on on the IPv4 waiting list. And then I want to talk to you about two topics that I personally found rather interesting and I hope you will agree with me after I provide you more insight. One is about temporary transfers and the other is about out of region ASN requests.

But first, let's have a very quick look at IPv4 waiting list. This is the number of LIRs on the waiting list and you my might see that since the beginning of this year it seems to be stag Nating and we have currently 1500 currently waiting for their /24. If you look at the number of /24 that is we hand out at the same time, you'll see there is a constant flow of /24s that we give to people on the waiting list, and you'll see two big bumps there, or jumps basically, when we handed out address space that was six months due to non‑payment of members. And consequently also the waiting time keeps on increasing. It's now more than a year and something that you will see just at the end of those graphs, the blue one and also the orange one, it seems to be going down and ‑‑ not seems, it is going down and this is related to the decision of the RIPE NCC Board that was announced at the end of April to suspend applications to the waiting list temporarily and so no new LIRs are entering at this moment while the people on the waiting list is business as usual, they'll be handing out /24s to them.

This is basically just in summary what I just told you and if you are interested and want to get more datasets about this Board decision, I included the link in my slides.

.
Looking a bit forward, we have currently 300 /24s in our pool and we will release them in the next six months. And also interesting dataset, it's mostly coming from former PI assignments, we have an ongoing project where we validate end users and we find a couple of abandoned resources that we consequently deregister, but this project is coming to an end and this will contribute to the fact that I expect that we will deregister less and less IPv4 and consequently can hand out less to the waiting list and current estimation to the people currently last in line at the waiting list, they have to wait for around 24 months.

That was an overview. Now I want to talk about something that maybe not of you are aware. It's about transfers, and besides let's say the regular transfers that something goes from company A to B, there is also a policy permission to do non‑permanent or temporary transfers and they go back after a certain period to their original resource holder.
Look the at numbers, the current numbers are not actually that high, and even more interesting, it's a smaller amount of resources that is basically temporary transfer for several times, even often to the same receiving party and then back and forward.

At this moment we have around 40 of such transfers going on. So it's still a small number but we feel it is getting a bit more common and as we also observed some potential challenges we thought it's worth to bring it up now.

First off, some of you might ask okay why people want to have a temporary transfer. Maybe the organisation is just interested to have IPv4 usually resources for limited amount of time. Will he also cannot or don't want to pay for a complete permanent transfer just for a specific period, but then still want to have the resources under their own name, want to manage their own RPKI and so on. But actually, if you consider that somebody pays to use resources for certain amount of time, that's pretty much the definition of leasing, right. And that's the point that I want to bring out, while the policy is kind of easily combining these two transfer options, there are quite some differences.

If you think about a terms transfer, while we update the registry, we publish the data transfer. If it's a scarce resource it's held for 24 months before after those 24 months the resource holder it transfer if they want. In the case of a rederegistration it goes to the RIPE NCC pool. Temporary it was are also updated in the registry and in the database. It is published and by the way it currently is not published that it is a temporary transfer. It's just published as a transfer which is one the issues that we noticed. There is no holding period, because it doesn't fit with the concept of a temporary transfer. It's also not transferrable for the party that holds it temporarily because after a certain amount of time and even if this is a longer period they have to give it back to the original resource holder.

Here I give a bit of an overview of leasing periods that are common right now and you'll see there is a good amount that is transfer periods of less than a year, or up to a year. The shortest was even five days. But if you look to the right side of the graph, there is also a good amount, around 30 percent, that is transferred for more than two years and even a quarter for more than four years. And this is something where we getting more and more concerned because as longer those periods are, it's more complications can be expected, and already happened partially. Because what have, for example, if there is a merger and acquisition. Maybe not so much an issue on the receiving side but what have the offering party merges? Normally, all the resources that they hold in their account, if they are IPv4 or circumstances numbers would be looked for two years, what about those resources that are temporary somewhere else, should they there also be a holding period? What is the offering party is being liquidated? Should the RIPE NCC take it back to their own pool or should we start searching for potential successors of those rights and put some efforts there?
Similar to a termination, that's say the offering party terminated its membership and then there is no member to give it back to but the still exists, should we contact them and ask them to open the membership again? But if even they have been closed for policy violation and kind of blocked? Even more fun, sanctions: Do you know that currently the rule is if one of our members or end user is sanctioned, we freeze the resources, we freeze the account. Nothing gets in, nothing gets out. But what have then this period of a temporary transfer expires?
.
Fraud. Also a pension one, it's a bit related to the fact that currently it's not publicly visible that's a temporary transfer. So imagine the fact that you are offered to take over a company and one of the assets is a /16. You pay accordingly and a year later the RIPE tells that you this /16 actually goes away now because it was a temporary transfer. And one of my favourites: A court order, because again also a court might not know that a certain resource is just leased, and they might issue something to the RIPE NCC that we have to give it to a third party. And if there is something that I learn from my colleagues from legal is a court order always wins. So, better not.

.
And I am presenting all this not to basically get feedback from you on all these different cases, I just want to make you aware that there are quite some things that are currently happening already. We had some issues with mergers and terminations and others might happen and will happen sooner other later so I want to raise the question to you: What could be a solution? Could there be a better policy definition about temporary transfers, to really call it what is it is a leasing? Maybe introduce time limits. Publish better that it's a leased resource and so on.

Or, alternatively and that might be a bit controversial here because some people have a business model there. Do we actually need this concept of a temporary transfer? Because, our region is the only one who has it written down in policy and actually if you need resources for a certain amount of time, there are already existing concepts, PA assignments, sub‑allocation, and even with RPKI, you can issue ROAs with the help of the LIR of course, for certain block that is a sub‑allocated or assigned. I am curious for your ideas on that one.

But first, I want to share with you another interesting topic.

.
End of last year my team noticed something interesting. So in the morning we saw that a member suddenly submitted 10, 15, 20 ASN requests for end users. And those end users were a natural person in Indonesia, a tiny company in Mexico, somebody in New Zealand, Japan all around the world. So we looked a bit deeper into it, if there is some trend to be discovered. So here is received an amount of ASN numbers that we handed out in chunks of six months. The green number or the green part is for resource holders that are based or living in our service region, and the blue one is that they are living or legally based anywhere else in the world. And you'll see it is increasing in the last six months actually more than 20% of the ASN requests came from somebody not from the RIPE NCC Services region.

.
And why is that? Well, we have a couple of providers out there that actually promote quite strongly that they can get the customers the RIPE ASN number. On the promotion there is no mention of observation you have to be in the RIPE service region or anything, it's just we get it for you. And they do provide some minimal proof that apparently it will be used in our region. The reason, of course, is we are not currently charging for AS numbers and also in other regions especially for natural persons it is difficult or sometimes even not allowed to get resources from this RIR. That's why more than half of those requests are coming from natural persons. By the way the youngest age of a requester was one year recently, so we have very young network engineers apparently, and also we got some requests from people that are way into the their pension age, so quite interesting.

.
Putting it a little bit on the map. So from where those people are actually based. You can see a quite clear clustering, so quite something in the ARIN region and another clustering in the APNIC region and it makes kind of sense because there it's quite give to get AS numbers.

Is this a problem or why is this a problem? Well I mean, the ASN policy has a quite clear statement that it is for AS numbers or for the policy is for something within the RIPE NCC Services region. And of course you might ask or you might say well these companies might be registered anywhere in the world but maybe they have business here in our region so we looked actually what is the usage of those AS numbers? And this is a picture of at least the ones we handed out in the last six months but I can tell you the proportions are pretty much the same even if you look back in time. Indeed around 20% using it to announce resources from our region, around one third, doesn't seem to have been used, at least though don't announce anything, and around a half is using, announcing resources that were issued from all the other RIRs.

Again, putting this on a map. You see there's a strong attendance that they are using it in the ARIN region and of course some of these really in those countries mostly in the Asia Pacific region.

Is it an issue? Well, I think it's worth to bring it to your attention because the whole service region concept is being challenged, I believe. It's right now more where it's the easiest and the cheapest to get an AS number. It does create considerably examine work for my team. That's why I bring it up here. And also actually it is a rather inefficient resource management because I showed you about one third of those AS numbers are not being used, and this is this is applying are older AS numbers, we see AS numbers are being abandoned quite easily and just left to be dieing somewhere.

So, my question that I want to pose to you is: Should we be more strict? Should we already doing the request ask for nor documentation? Should we do some audits and eventually go behind the resources that are clearly used anywhere else in the world? Or is this too much work basically? Should maybe the RIPE ASN policy be updated? Or, are there other ways to promote at least a more considered usage of resources and the last one is maybe not so much for this Working Group, more for the GM because I am referring to an ASN fee that might certainly help to give some kind of incentive to responsibly manage your resources.

That was the end of my presentation and I'm looking forward for questions and suggestions.

ERIK BAIS: I have one online question, or remark from Sergei from Netar Group. Temp transfers perfectly fit our business model. We'll welcome a separate policy or policy clarification. I may contribute into policy proposal.

Before we're going that, the temp transfers is something that I have been using temp transfers just to understand the process. There are some things that are not working correctly operational with the temp transfers. For instance, you cannot extend the time that a temp transfer is working. So, if you are about to end the process or you come to the end of the lease time, you cannot tell the RIPE NCC can you extend the temp transfer because, you know, with two additional years. It has to go back, which breaks RPKI, and then you have to restart the whole process again. So it's quite cumbersome to actually use temp transfers.

.
That is something, if we are going to allow temp transfers, definitely something that needs more clarification from my point of view at least, because operationally it breaks things at the end of the temp transfer. And a lot of the temp transfers that I would assume will actually be extended at some point by basically just adds work for the NCC.

The other thing is, with leasing, if you have a /24 and want to assign that to somebody, and this is more a database thing, and I will bring this up again in the Database Working Group as well, there is a work item there, NW4, which does not allow you to assign the exact size of the allocation and write that in the database. And that's where the temp transfer will actually fix that, because now you have to complete /24 in the LIR of the customer that leases the IP space and they can actually create a route objects, ROAs, whatever, as a /24. Otherwise you have to create two /24s. So that is something that as clarification what we found in our business model.

We have a couple of people on the mic. Sascha.

AUDIENCE SPEAKER: Sascha. Long term adviser of German government but speaking for my own here. The issue with the ASNs. My question is: From my perspective, the RIPE is suffering from the more strict regulations in the other RIRs, so perhaps we should try to fix this that it's more harmonised. Because then this is the motivation where they do this, you know. And is there any activity to talk to them and to negotiate how to deal with the AS numbers?

MARCO SCHMIDT: Well, I mean, you're right, it's a natural effect if you need something you go where it's the easiest and the cheapest, and of course with the other RIRs, you have two aspects like over here one is the policy, who can get it, the other might also be the membership based, how much it's being charged and so on. So far there is nothing ‑‑ and these are all, every region is responsible for itself, so that is actually one the challenges of the service region concept. So indeed. So there are no plans yet to. It should brought up in a different community.

AUDIENCE SPEAKER: Then you have always a run, not only with the AS number policy but every ‑‑ then they are cherry‑picking where is the easiest policy for something to get, you know.

ERIK BAIS: Welcome to the global world. Policy shopping will be here. So, you know, let's hope that we get an ASN charge, and let's see if that helps. Gert.

GERT DÖRING: Good morning, speaking for myself as an interested RIPE citizen.

Thank you very much for bringing this up. People have been complaining why the NCC is so expensive so it's good to see what weird stuff you are spending these resources on.
On fixing the global policy things, I think I have exactly the right person to send out to the other four regions to fix their AS number policies but that might take a while. Fix them, not us.

I still think that our policy being as liberal as it is, is good, because we do not need obstacles in the way of people wanting to deploy things in their network. Just for the sake of having said it, I think we need a reclaim policy, and I still think ‑‑ and I am absolutely convinced of this that having the NCC go out and spend resources on are you really using this any more? Can we have it back? Can we have it back please? Can we have it back next week please? Is not a good way to spend your resources. So, we need then some other incentive to make people give back AS numbers they don't really need any more, and I maintain that a €50 charge is a good thing for that. But this is the wrong forum for it, so if you agree with me, vote for it this afternoon. Thank you.

AUDIENCE SPEAKER: Harry Cross speaking with my own hat on. I was just thinking about the temporary transfers process and has there been any consideration of just looking at the graph, the average lease is about sort of eight months, let's call T has there been a thought of adding a check process at the end of say every eight months to check that the status quo is still going and that there's no liquidation, there's no court order, there is no M&A. I know this happens with ASN calculations because as an LIR I have received a few myself where the NCC as gone oh we have detected this person is no longer in the register, what do you want to do here? So I wonder whether it's worth doing the same for temporary transfers and going something has changed here, what do we do with this resource now?

MARCO SCHMIDT: At this moment this is not actively done by registration service because it's also would cause extra work, reaching out and waiting for feedback but for example, some guidance from the Working Group or even a policy adjustment like with time limits or some check inlimits would for example help if that way, yes.

AUDIENCE SPEAKER: Thank you.

SANDER STEFFANN: Hi, I was thinking about the temporary transfer stuff, and I realised that I have no idea how people people using this. I know it's about in there since forever. I guess Erik was the one who actually put it in so I have no idea what people do with t it might be a nice idea to find people to present how they are using the policy at the next RIPE meeting.

MARCO SCHMIDT: Good idea and also maybe if Erik or other people have experience ‑‑

ERIK BAIS: I have extensive knowledge on this. So no problem.

AUDIENCE SPEAKER: Peter Hessler from global ways. You're talking about the concerns about out of region use of ASNs. Do you have any comparison with out of region use of for example IPv6 PI assignments? And if there is any comparison between the two policies or the activity that you're seeing that we can use to possibly bring those into harmony?

MARCO SCHMIDT: I don't have the exact numbers yet but just looking about I way what kind of requests we get it's mostly AS numbers, so because for IPv6 PI for example, there is a little fee and that probably already helps for some people to consider. So the issue is mostly with ASNs.

AUDIENCE SPEAKER: Right, but also is it just the fee or is there also a policy difference? I apologise I'm not that familiar with these topics.

MARCO SCHMIDT: Well I mean we probably would have to dig deeper and ask but I think it's an mix. It's the price and it's also the convenience to get it easier than in other region, like I can talk about APNIC, you can't get it as a natural person, as a one‑man network engineer that just wants to play around, you can't get it there. You have to create a company basically.

AUDIENCE SPEAKER: Okay. I think as a suggestion to the Working Group, it would be nice to synchronise at least the policies for IP address assignments and ASN assignments. I think that would help your process and also simplify our process of when we're trying to apply for these.

MARCO SCHMIDT: Thank you.

ERIK BAIS: Then I have questions from, online from Elvis.

"Temp transfers should be tagged as such in the statistics." And I do agree on that. Because it's actually gives a better insight into the community which temp transfers are permanent are temporary. Currently it says policy, and that obviously it's according to policy. But it would be nice if we can see if it's a temp or a permanent transfer.

And in the RIPE Database. This is something the NCC should be able to do so.

MARCO SCHMIDT: If I just can respond to that. Actually, the transfer, the publishing of transfers is one of the things that are quite specific to find in the transfer policy. So, it might need an adjustment to the policy because if we publish additional things, then the policy describes it can get a bit messy, so it would be better to have that defined.

ERIK BAIS: His second remark "an assignment or a sub‑allocation is a lease as well, we should just clarify the temp transfers as are similar services but not clearly defined."
.
So, as suggested by Sander, I think it's good to have some additional time at the next RIPE meeting to talk about temporary transfers and it and how they are use and how leasing is done. I'd be more than happy to put some slides on that. Then last for the mic?

SANDER STEFFANN: Address Policy person again. I was just giving a bit more thought to the discussion about the ASNs and that we are apparently the easiest region to get one. I'd like to keep it that way. I think that's a feature. We even sometime talked about lowering the requirement even further because now you have to have at least two AS that is you are going to peer with to get an ASN. And I know many cases where a network is starting up and they start with one transit with the plan to expand. So, at the beginning, they don't have two ASNs yet. So, they have to jump through hoops to make that work because in six months they will have multiple ASNs and if they start without an ASN now then they have to redo everything when they do get their second peer and it all gets a bit complicated. So especially when the charging scheme changes so that ASNs are actually charged, I would like to come back to the Working Group and see if we can make the ASN policy more liberal.

ERIK BAIS: Okay. Thank you. Thank you Marco.

(Applause)

ERIK BAIS: Then up next is Angela with a policy update our policy officer.

ANGELA DALL'ARA: So, good morning everybody. I see we are a bit short of time. So I'm going to try to be as fast as possible, I don't want to be responsible for you missing a coffee.

So, traditionally I'd give you the update about the policy development that we had since the last RIPE meeting. Then I tell you which are the other topics under discussion related to policies, and then I give you an overview of what is going on in the other regions.

.
So starting with our region. Since October, we can have a look at what happened in the policy development process, and as usual for who is new to this process, all the information is to be found in the RIPE‑781, that is the document for the PDP and it's also good to read the Code of Conduct that James referred to before. Also when you want to participate in the discussion of policies in the policy development process, you know that it is happening in Working Groups and to participate you need to subscribe to the mailing list. Here you have all the links that you might need to find the Working Group of your interest.

So, since last October, we had two policies, policy proposals that were withdrawn. One was about personal data in the RIPE Database. And it's possible that we see some a sequel of that proposal dividing that proposal in multiple smaller proposals because the scope was a bit too wide in the feelings of the proposer, so it's possible we will see something in the future.

.
And also, proposal to remove mandatory IPv4 PA assignment registration in the RIPE Database, we know that there is now, announced by James before, a concept that might become a new proposal, keeping in consideration the feedback that was received in the discussion:
.
So what do we have now active? You saw it in the agenda of this Working Group. We have two policy proposals, one to reduce the IPv4 assignment default size to a /26 from a /24. And it's in discussion phase until the 29th May. And the second one is proposing to assign at least a /24 for temporary assignments and also allow routing needs to justify the request.

And also, this one is in the review phase until the 29th May.

.
Then, this afternoon, in the RIPE NCC Services Working Group we have the voluntary transfer lock proposal is in discussion phase until the 2nd June, and this is to offer the option for, to prevent transfers of selected specific allocations or PI assignments for a certain period of time. So I invite you to participate in the discussion.

.
Here is the page where you can find all the current policy proposals and the status in the PDP. I just want to remind you that in the review phase you have to restate your support or your objections that you made during the discussion phase, because that is the phase where the Working Group Chairs at the end that have phase they have to determine if consensus has been reached or not, so I know somebody can find it a bit odd but please, even if you participated in the discussion with a certain opinion, you have to restate it in the review phase.

.
And then you will see later there is a moment to discuss the picks policy review. There were two interim sessions held in February and April to discuss some points Leo will expand much more later about a review, about seeing if there is the need to update the policies and make them more suitable with the needs of today because these policies are made a some time ago.

.
So looking at other regions. What has been implemented in RIPE 85. You see a long list. I tried to go a bit faster through it because in APNIC, they just made a correction in the language because there were some heading contrasting with the content of the paragraph and nothing changed in the requirements for requesting addresses and so on.

The same thing is for ARIN. The first two are two clarifications, nothing changes. And the last ones are only editorial clean‑up.

ARIN has been busy already for a while to update the policy manual, and the work is going on. There were many policies, so mostly is let's say a clarification, a correction of the language and editorial changes.

What instead is interesting I think, is the first one in LACNIC, because now the holders of sub‑assignment and sub‑allocation can also create ROAs. You heard some references before Erik was talking about this need to divide the sub‑allocation in two parts and not being able to create ROAs and so on. And also for the transfer, the temporary transfers. So this is now possible in LACNIC.
And also they updated the procedure to elect the PDP Chair.

.
Then awaiting implementation, there is this RPKI ROAs for unallocated and unassigned AFRINIC address space. This is related to what is called AS zero let's say, and I don't know exactly how is the status of the work on the implementation because last year AFRINIC asked for some cooperation to, for the implementation, and I think they are working on it.

Then in APNIC, the first one is a proposal that would add all the definitions in one document for all the policies. So that there are no repetitions between the policies.

The second one is probably interesting for who has the legacy resources in the APNIC region because from the 1st January 2023 holder of legacy resources must have a contract with APNIC as member or new member, and otherwise, they lose the services of the registration in the Whois.

Also, they go into reserve the space, and if there is no claiming of these resources within 12 months, these resources are going to go into the free pool and they can be allocated.

So, it's an interesting new policy.

.
Then, the creation of ROAs with origin ASN that is an ASN that is private reserved or unallocated is not going to be possible any more once this policy is implemented. Also, APNIC is going to inform the creators of this ROAs that they have such a situation. And these ROAs are not going to be automatically renewed.

And the last one is restricting on hierarchical AS‑set, and this is similar to what has been implemented with NYI 19 Working Group our region, so the non‑hierarchical AS‑set cannot be created any more.

Then awaiting ratification, there are piece policies whenever the Board will be reconstituted in AFRINIC, it's there already for a while, and in ARIN, we have this list, as you see the last three policies are just a clean‑up of the policy manual. And the first one is deprecating an optional attribute for each sub‑net was indicating which autonomous system was possibly originating the announcement. Then they changed the text to, how can I say, expand the possibility to receive an ASN also when not BGP is used but just when it's needed for multiple discrete networks and particular observation at the requirement was removed. That was actually confirming that the documents were valid.

Under discussion, we have in APNIC, still a proposal that tries to make leasing of resources not acceptable. And one that is trying to offer more space to all the members that have less than a /21 already in their registry. Assigning to them an extra /23, and at the moment there is not a discussion going on but let's see very active one, let's see how it's going to go.

And in ARIN, there are still some clean‑up going on. The first one is just deleting part of the policy manual that is actually not applicable any more because it's related to requests of IPv4 space based upon need. And this is not applicable any more.

And in LACNIC, there are also ‑‑ there is some ‑‑ the first one is trying to include for the creation of DNS, reverse DNS objects, also the part related to IPv6, and then they are trying to review the PDP with clarifying the definition of consensus in case of minor updates, editorial updates, and making the impact analysis mandatory in case in all cases, but LACNIC is already creating the impact analysis in all cases.

Here I give you all the beautiful links that you can use for finding more information on each RIR, but I want to add this one and thank Sander Steffann for this beautiful overview that he shared with the community so actually I could have presented mostly this slide because here you can find everything about all the RIRs, all the proposals that are active, their stages and the direct link to those proposals. So thank you very much Sander for that.

And I think the questions is can we go for a coffee now?
.
(Applause)

ERIK BAIS: Yeah, coffee sounds really good. But however, Sander, can you provide a half minute update on the transfer, voluntarily transfer lock, why it was not here but in services, and give a bit of insight on that?

SANDER STEFFANN: Between people and coffee, dangerous spot.

So, this time as one of the proposers of the voluntary transfer lock policy.
It's a policy just a little back, it's a policy that allows LIRs to say I will not transfer these addresses for the next X period. And this is especially requested currently by people in Ukraine who are afraid that when an invasion happens they will be forced to give away their valuable addresses.
So, the reason that the policy proposal is in NCC services is because the content of the proposal doesn't actually touch on transfers that much. It's mostly about the constraints on the NCC, what should the NCC do, what should the NCC not do. So because of that we decided to actually put it in NCC Services. However, it does of course affect transfers.

So, I have talked to several people, mostly Denis, who said like it should be in Address Policy. So, we had a chat yesterday, we still don't completely agree, but Denis was like, you know, if we actually adapt the transfer policy because now it says everybody has the right to transfer addresses, and then there would be a policy in NCC service that is says you can give up this right, we should make sure that all the documents are in sync on that.

But, yeah, so there was some discussion where this policy discussions should take place. My personal feeling is keep it in NCC Services, but do a slight update to the transfer policy document to make sure it's all in sync.

ERIK BAIS: Thank you for that update. Thank you Angela.

The proposal for Jeroen, we're going to move that after the coffee, so we'll see you back after the break.

.
(Coffee break)
.