.
Wednesday Address Policy session
.
28th October 2020
.
10 a.m.
GERT DÖRING: Good morning, dear Working Group. I hope you can hear me. I can see that you can see me, because I am checking via the webstream that everything is visible and fine, but of course I cannot hear that.
This is the Address Policy Working Group at the virtual RIPE 81 meeting, and your Working Group chairs are Gert Döring and Erik Bais.
Next slide...
.
The time is wrong. It's not 11 to 11:45 but 10 to 10:45, we have a single slot today and a few administrative matters, and then basically three short presentations from RIPE NCC people about current policy topics, feedback from the NCC registry service and something very interesting that happened since the last meeting about the seizure of the right to registration of IPv4 addresses in a court case. Which we thought definitely interesting enough to let you hear about it.
As you might be aware, this is a virtual meeting. We do Meetecho. The steno is on the main website, as is the webstream, so if Meetecho isn't working right for you, they are streamed with audio and video and steno.
If you have any questions or feedback, there is a question and answer in Meetecho, there is the general chat in Meetecho, and there is a request to speak in Meetecho. That signals to us that you want to say something and we can then turn on your mic. So this is much better than Zoom last time where you could only write questions.
.
The questions is, of course, recorded, and, given the time constraints and the virtual format, we don't do real discussions today, but just have presentations and Q&A for that.
.
Anything that needs a proper discussion, proper policy‑making, will happen on the mailing list afterwards.
.
Well, the agenda bashing is sort of like the standard slides, but I'm just skipping it because it's not a very useful exercise if we have no things to discuss anyway.
.
Minutes from the RIPE meeting in May have been circulated on the mailing list in June, thanks very much to the RIPE NCC for doing the minutes and doing a great job on it.
.
We haven't received any comments. Please, if you feel like ‑‑ read the minutes, if there is anything missing or not correct, let us know. And we will declare them final in four weeks, with corrections or without.
.
A two‑Working‑Group‑Chair selection. This is something sort of a regular exercise, but it's getting a bit more relevant this time and the next time. We have a process that says the Working Group Chairs take turn in stepping down from the Working Group Chair role. Every second meeting, one of us frees his seat and you volunteers are welcome to apply for the job.
.
At the May meeting, it's my job to give up the seat and I think I will not candidate again. We have, at the last meeting, asked for volunteers that want to sort of like be trainees and have a look into the job. We had two volunteers, Leo Vegoda and James Kennedy, both seasoned old hats in policy‑making, regional registry BIS and all that. The actual Chair selection will of course happen on the mailing list four weeks before the next meeting. This is not exclusive list, so we just are happy that we found two, that if more people show up, even better. Maybe if some more diversity is also welcome because it's still all old white men. But, having available candidates for a change is definitely a good step, a good first step.
I have seen Leo online, so if he wants, he can just switch on his video briefly and wave to the room. Erik is of course also online and could use this to wave.
.
I haven't seen James yet, but he will make himself known on the list undoubtedly.
.
There is Erik. I'm seeing that the delayed video on the web.
Let's go on, we are a bit short on time and we have quite interesting content.
The next agenda item is the regular current policy topics overview from Petrit Hasani. He used to be the NCC policy development officer but it's fancy to change your title regularly so that job is now called policy officer, it's just the policy development office, but anyway, I am stopping my sharing and Petrit can take over.
PETRIT HASANI: Good morning everyone. So, I'll just try to share my screen ‑‑ we do see the screen but there is nothing on it yet.
So, I hope there will not be any issues this time around.
So, my name is Petrit Hasani, as Gert mentioned I am the policy officer at the RIPE NCC, and I'll be talking to you briefly today about the current policy topics.
.
So, in this talk, I will quickly have a look what's going on currently in the RIPE NCC service region and then what has happened since the last RIPE meeting, and move from there to the other four service regions, what's going on there, and we will finalise the presentation with an update from the policy development office.
So, what is going on in our own service region?
.
What are the current policy discussions?
.
Actually, there are no policy discussions at the moment and I just found out that we showed this little page when we have no discussions. It has been a while that we haven't had any active policy proposals, so I did not know that this page existed. However, I'd like to mention that there are a couple of proposals in the backlog that were submitted and are currently being reviewed so hopefully we should have something up soon.
There were two proposals which finished the PDP cycle since the last RIPE meeting. Both of them were withdrawn. The first one was 2019‑08, the SLURM file for unallocated and unassigned RIPE NCC address space.
.
This proposal aimed for the RIPE NCC to publish a SLURM file containing assertion with a zero for the address space which is unallocated and unassigned, and I'd like to mention that that proposal was initially called A zero ROAs for unallocated RIPE NCC address space.
The reason for withdrawal was that the Working Group Chairs felt that there was stronger position against this appropriately in the community.
.
The second proposal is 2019‑04, validation of abuse mailbox. This proposal aimed to have the RIPE NCC validate abuse information for often, and wanted to introduce a new validation process. The reason for withdrawal for this proposal was it did not reach consensus and the Working Group Chairs felt that any further redrafting of this proposal would not be available to reach a consensus either.
.
As you see, there is a small asterisk next to it. And that's because we had our first appeal in the RIPE Policy Development Process. The author of the proposal 2019‑04 submitted an appeal against a decision of the Anti‑Abuse Working Group chairs. This was the first time it happened in the RIPE Policy Development Process, to it was quite interesting.
.
The outcome of the appeal was published on Monday, and the Working Group Chair collective decided to uphold the decision that the Anti‑Abuse Working Group chairs made.
.
So, let's move away from our service region and see what's going on in the other four service regions.
.
As it can be seen from the graph, similar to our region, APNIC doesn't have any active policy proposals. Leading is AFRINIC with 12 policy proposals, LACNIC follows with 10 and ARIN has nine active policy proposals.
.
I am not going to talk about all of these proposals, because I already mentioned some of them in my last presentation, at the last RIPE meeting. However, I have chosen two topics to talk about today. The first one is transfers.
.
The first proposal is from LACNIC at IPv6 operational as a requirement for IPv4 transfers.
.
As you can deduce from the title most probably, this proposal states that before receiving a party can get an IPv4 transfer they need to have an IPv6 address from LACNIC and they need to have documented the network deployments in IPv6 for a significant part of their network.
.
The second one is from ARIN, clarify holding period for resources received via 4.1.8 waiting list.
.
And this proposal would allow an organisation that received address space via a waiting list to be able to transfer this address space as a merger and acquisition without having to wait for the holding period. However, the holding period, the remaining holding period remains with the address space once it is transferred. So it cannot be retransferred again before the holding period finishes.
.
And AFRINIC inter‑RIR resources transfers, I did not bring one proposal here, there are multiple proposals under discussion, and it was a very hot topic in the recent weeks. AFRINIC remains the only RIRs which does not have an inter‑RIR policy yet. So, there is quite heavy discussion going on with some proposals almost reaching consensus, and I would recommend to follow up on the discussion.
.
And the second topic I wanted to bring to your attention is the policy development process. I notice that there is a lot of discussion in two regions, in LACNIC and AFRINIC. And there are 13 proposals to update or change the policy development process. I will not go through all of them. However, I just wanted to bring it to your attention because I thought it would be interesting and it may ‑‑ you might want to see it.
.
And this brings me to the last part of my presentation, an update from the policy development office, and I will start first with a feature that we're planning to introduce. I notice that when a policy proposal is accepted, we make it abundantly clear what the policy document is. As you can see here, we mention it twice and I like it quite well. However, once the RIPE policy document is created, Thislink seems to be broken. There is no reference at all how this document was created, where did it come from, and I notice that the ‑‑ especially for some documents which have been updated a lot of times, it's a bit hard to understand why changes were introduced and what was the motivation for them.
So we're planning to add a new field called "update reason". So in this case, it would be Policy Proposal 2019‑06, and I believe that introducing this field would increase transparency and it will allow for a better understanding of RIPE policy documents.
.
And the final part of my presentation is some changes to the policy development office. I was introduced as the RIPE policy officer during the RIPE 79 in Rotterdam. Unfortunately, we did not have any physical meeting since; I'm not sure they are related. I deeply enjoyed my year as a policy officer. However, I have decided to take a new role within the RIPE NCC. I would like to say that I am ‑‑ it was a pleasure and an honour to have assisted the RIPE Policy Development Process.
.
However, it's not all bad news. We have already a new policy officer appointed. She has been with the RIPE NCC for more than six years. She has already presented in a few RIPE meetings, and her name is Angela Dall'Ara. I am sure that I'm leaving you in good hands with her,
.
And to finish, some useful information, links to the active proposals, and if you have any questions at all, this is the e‑mail, Angela will be able to assist you
GERT DÖRING: Thank you very much, Petrit, thank you for the presentation, and of course thanks for the year you dedicated to helping us. Well done. Much, much luck and success and everything with your new role, and welcome, Angela, we'll see if we can drive you as crazy as we did with your predecessors.
.
So any questions for Petrit? We have a few minutes for one or two questions. I don't see any raised hands. We don't need any ‑‑ Erik?
ERIK BAIS: Yeah, there is a question from Daniel Karrenberg. I'll just read it out.
.
From Daniel Karrenberg, RIPE NCC: Patrik, thank you for the presentation. You mentioned that the Working Group Chairs' decision to only appeal was published on Monday. I have trouble finding it on the NCC website, neither in this Working Group nor at the Working Group Chairs; where is it?
PETRIT HASANI: The appeal was published on "Policy Announced", it was mailing list, it was announced on the anti‑abuse mailing list. It is on the policy proposal itself, and if you go to the archive policy proposals, you should be able to see it there as well, the appeal and the outcome of the appeal.
GERT DÖRING: Okay. Thank you. With that, I thank you again, and there is the audio queue, supposedly there is ‑‑ why am I not seeing the audio queue? I got a chat message that there is audio queue requests, but I cannot find it. Erik, can you see it?
ERIK BAIS: There is no one in the actual audio queue at this moment.
GERT DÖRING: They have stopped requesting it. Okay, let's go on.
.
Any other questions can be sent to the mailing list and discussed there as always.
.
Now, we introduce Nikolas from the RIPE NCC Registry Department, who will give us an update on what they see in the daily work with policy implementation, people asking questions, looking at numbers and everything. Nikolas, the floor is yours. We turn off our video again.
NIKOLAS PEDIADITIS: Good morning. I'll try to share my screen as well.
.
Hello everyone, Nikolas, I am part of the Registry Services Department at the RIPE NCC, and since we have quite a lot of newcomers for yet another RIPE meeting, it's good to mention what the aim of this update is.
In short, it's our platform for ‑‑ to report back to the community ‑ Feedback, basically, from LIRs highlighting potential problem areas. So, we want to bring these issues forward to the Address Policy Working Group, ask for your guidance and in general provide input to the community to stimulate the policy discussions.
The first topic that we would like to discuss today is the status hierarchies in the RIPE database. This is something that we started reviewing quite some time ago with the RIPE NCC, grasping the needs of our members, and it's something that we raised at the Address Policy Working Group during the last summer.
The reason that we're bringing this forward is that we have seen that there is a misalignment between the way that some of our members wished to register the al supply allocations and assignments in the RIPE database and their need to be compliant with RIPE policies.
For this topic we mainly focus on the suballocations, so on objects in a more generic term that would basically point into delegation of responsibility to handle allocations further, whether that's within the organisation of an LIR or outside of it.
So mostly we're focussing in IPv4 with objects that start with you sub‑allocated PA. We also have LIR partition PA in IPv4, and in IPv6 in objects with status aggregated by LIR or allocated by LIR.
If we look at this issue from the policy perspective, we observe that multiple, let's say multiple objects, one inside another with the same status, strictly speaking, is not allowed. So, at the IPv4 policy, for example, section 5.3, sub‑allocations, it says that sub‑allocations are intended to aid the goal of routing aggregation and can only be made from allocations with status allocated PA.
And at the definition of what sub‑allocated PA space is, the policy says that this address space has been sub‑allocated by an LIR, the downstream network operator that will make assignments from it.
It's quite clear according to policy text, only the LIRs are supposed to create objects with status of allocated PA, and those need to come from objects with status allocated PA.
If we look at IPv6, there is no specific wording in the policy. However, if you look at the naming of the objects of the status attributes on these objects, is allocated by LIR aggregated by LIR. So, again, it implies that it's only the LIR that is supposed to be creating those objects.
At the same time, neither of the two policies specify a minimum size of allocations and there is no limit in the RIPE database either. However, this raise a question: Does sub‑allocations smaller than a /24 in the IPv4 or smaller than a /48 in IPv6 make any sense?
.
Now if we look from the RIPE Anti‑Abuse perspective, we will see that there are no real limitations for creating a netnum with status sub‑allocated PA sum allocated PA and so on, the statuses I just mentioned. So what happens is that this results often in chains of netnum and net 6nums which have the same status. So we have a sub‑allocation into a sub‑allocation into a sub‑allocation and so on.
At the same time, we hear our members and some of them say that multiple layers of sub‑allocations might be useful.
.
What we did in order to make this discussion more tangible, in order to make this issue more tangible for you and hopefully stimulate a discussion, is to look at the numbers, And what has actually happened in the RIPE database.
If we look at IPv4, so netnums representing IPv4 allocations, underneath we will find more than 4,000 objects with status sub‑allocated PA, and a bit short than 6,000 objects are status LIR partition PA. Now under those objects, we can find up to three levels more specific to sub‑allocated PA and up to five layers more specific to LIR partition PA. And the objects that are involved in those additional levels combined with approximately one‑and‑a‑half thousand. If we look at IPv6, things are actually worse. If we look at objects with status allocated by LIR, they are about 7,500 and the ones aggregated by LIR a bit above 7,000.
With 7 in 3 maximum number of levels respectively and we are talking about, in totality, 3,500 objects.
A number that actually maybe makes the picture a bit more clear of the confusion that might be there for some of our members, is that we have almost 3,000 objects in the RIPE database with a sub‑allocated PA without any specifics, without any more specifics underneath. And above 3,000 objects with status, LIR partition PA without any more specifics underneath.
So, potentially, these were meant to be assignments and our LIRs register them as assignments, they choose different status values.
And in total, there is a huge mix between aggregated by LIR and allocated by LIR being inside one another, and that concerns about 33,000 objects. So if we look at those numbers, I think it's quite clear that things are a bit confusing for our members in terms of coming how they use their IP space in the RIPE database.
However, as we said before, there are user stories, there are use cases where it is quite useful for our members to be able to apply multiple players of sub‑allocations, just examples that we picked up, imagine multinational company that makes sub‑allocations to the national branches, and they want to make some sub‑allocations to the multiple daughter companies and then these daughter companies can create and maintain assignments for the networks.
In IPv6 specifically, and that is the focus maybe I should be more in IPv6, imagine a government with a big IPv6 block that wants to make, wants to sub‑allocate to this big IPv6 block on the state level and then each state to be able to make sub‑allocations to the counties and municipalities and then each one of them to be able to make assignments to schools, libraries, police stations and so on that would be actually used by those networks.
So in those cases, the desired hierarchy would look like this: Theblue bar would be the allocation of the LIR, followed by sub‑allocation, given downstream customer, then it could be a second layer of a supply allocation or a third, and then, underneath, members can register their assignments.
Now, this is something that we raised here in the summer, we asked for your feedback, we were hoping for more feedback than what we received. We received three responses so far and we see that there is some support for this, especially for IPv6.
So, we would like to state the same questions to you again:
.
Should netnums and net6nums with this status be used to allow created inside one another.
.
Should there be a limit on a minimum size of sub‑allocation and do we need a policy update?
.
A couple of people have indicated, yes, we do need a policy update. So if this is the case, we kindly ask you in the policy Working Group mailing list to discuss this issue and provide us with your feedback.
.
Moving on to a different subject. You may have noticed that it's been almost one year after the IPv4 run‑out. Well, 11 months to be exact. And a lot of things have happened during this one year, so we'd like to give you an update of some things that we have observed and some trends that we see happening.
First of all what is happening nowadays in the world of IPv4?
.
As, you know, the RIPE NCC only distributes recycled IPv4 these days, so IPv4 space that has been reclaimed from LIRs that go out of business or being closed for other reasons, I would put it in our free pool which is called a puddle, apparently, these days, we keep it in quarantine for some time and then distribute it to our members.
So over the past one year we gave out a bit more than 1,000 allocations. Then we currently issue around 80 allocations on average per month. We saw that there was a big impact following the whole Coronavirus situation. As the rate was approximately double before Covid‑19.
Currently, we have approximately 1,300 /24s in our pool and we expect to release another, a bit less than 1,000 that we have in quarantine.
Over the past one year, it has been a good area in terms of returning, returns of IPv4 space and, for this reason, we are able to give all these allocations out now to our members.
.
However, we don't expect this to last for much longer but it's not something we can definitely predict. It always depends on how much space we have returned.
So to give you an idea about the flow of IPv4, what comes in our pools and what we give out. You can see that up to the run‑out date, which you can spot easily by the big yellow line, there was a lot more going out than being released from quarantine. And as of that point, we had quite a few returns in the first months of 2020, but that's not the case any more. So, now it's a bit much balanced between what we get from returned IPv4 space and what we give out to our members. So, it's quite a balanced situation right now.
However, I think it's clear that especially from this blue ‑‑ this yellow line, that should the policy hadn't changed last year, there wouldn't be ‑‑ there would be a big waiting queue right now, and basically our pools, even with all the returns space we received this year, wouldn't have lasted for more than a week.
Now, we did something interesting, we tried to look in what is happening between the trend of giving out allocations and multiple LIRs. We did a graph to show it. So with blue colour, you can see how many IPv4 allocations are going to members that have one LIR. This is with red it's between 24 and with yellow it's five plus LIRs. As you know, the whole multiple LIR phenomenon did have a big impact in our pools and what is clear from this graph, if you follow the thin line, is that with the IPv4 run‑out, the trend of members opening multiple LIRs dropped significantly. So, these days, most of the IPv4 allocations that we give out go out to members with only one LIR.
With did the same for IPv6. The trend is similar but not exactly the same. So although the numbers went down for IPv6 we do see a continuing trend and with certain spikes at the same time of LIRs basically accumulating IPv6 allocations, either because they consolidate multiple LIRs or because they prefer the transfers with each other.
And this is the good introduction to the next topic ‑ stockpiling of IPv6.
.
This is something that we raised at least a couple of times in the past. You have asked us to monitor the trend and to report back to you, and so we did. And I would like to start this by showing you some numbers.
.
Currently, we have approximately one‑and‑a‑half thousand LIRs that hold more than 2 locations. As you know, multiple LIRs can freely transfer IPv4 allocations between their accounts, so, it is happening that we end up with, let's say, one LIR having a lot of allocations. In some cases, there are LIRs with as many as 91 allocations. There are four LIRs in total that hold between 30 to 91 allocations, And there are approximately 300 LIRs that hold between 4 and 91 allocations.
.
Now, this is a growing trend. We kept monitoring, as you guys asked us to do, and we do see that the numbers are increasing quite a bit. And while we can say that, okay, how much is that of a problem since we don't have that many LIRs operating right now, we do see some worrying things happening and we do have some reports from our members that can be concerning for the future.
.
For example, something that this ‑‑ a question that this creates is: Is it okay if ‑‑ for an LIR that has a huge network or for a government of a country that requires a lot of IPv6 space going through the policy, through the requirements of the policy in order to acquire a big IPv6 block, while, at the same time, there are LIRs that have quite a lot more than that.
.
So, for example, there are LIRs with more than a /23. Now if you look ‑‑ I'm trying not to mention any names here ‑‑ but if you look at the, if you consider what are the biggest networks, what are the companies running the biggest networks out there and a you make your top five, most probably you will realise that most of them don't really have, or need that much IPv6 space.
.
So, it is a growing trend. It's still there. And if we look at the pie‑chart that we kind of discussed a few years ago as well, we see that ‑‑
ERIK BAIS: Nikolas, we need to cut you short, Otherwise we're going to run way out of time.
NIKOLAS PEDIADITIS: Okay.
ERIK BAIS: Can you finish in 30 seconds?
NIKOLAS PEDIADITIS: Okay, I will wrap up.
.
Basically, we are just reporting on this, we want your feedback. If you'd like at the mailing list, if you consider this is an issue, if you consider that this is within the intent of IPv6 policy. There was a policy update a couple of years ago where the organisation LIR clarification took place, so we would like you to consider whether this was as intended, whether it did work as intended, and whether we need to make changes to the IPv6 policy, and whether there should be any restrictions to IPv6 transfers following this trend that we observed.
.
Erik, I have a short topic to mention about ‑‑ it's up to you, I can skip it and move it to the next one.
GERT DÖRING: You need to skip it, you over‑ran five minutes already. I put a timer on the status bar in Meetecho but it seems that when sharing you do not see the timer. So, you are at about 19 minutes now. You had ‑‑ sorry, that just didn't work out as well as as I thought it would.
NIKOLAS PEDIADITIS: No problem.
GERT DÖRING: Well, just send the questions to the list and discuss it there. It's very important stuff you bring up, but we are so out of time. Sorry for that. Sorry to the audience. The coordination stuff in Meetecho is a bit tricky.
.
So we have one last presentation, which is important and needs time. It's from Ciaran Byrne. Sorry for any mispronunciation on that. Please just go ahead.
ERIK BAIS: Ciaran, we can't hear you yet.
GERT DÖRING: I can see the slides, I cannot hear Ciaran and I cannot see anything. How do we do this?
CIARAN BYRNE: My name is Ciaran and I work in the legal department of the RIPE NCC. And this presentation is about a case that we had last year, and it recently finished up. It was about the series user of the rights of the registration of IPv4 addresses and it was for the recovery of money.
.
The case actually didn't involve the RIPE NCC at all. It was two German entities, one was a RIPE NCC member and the other was a third party in liquidation. The RIPE NCC member in this case owed the third party in liquidation a sum of money and so the liquidator took the RIPE NCC member to court. And in this case the Court ruled in favour of this third party and they granted them the right to recover money through the auction of the IPv4 addresses.
.
Since we're in the Netherlands and this was a German decision, they had to bring it to the Dutch courts and they got what's called a pre‑judgment at that, Which is a type of court order. This was delivered to the RIPE NCC around mid‑December last year. Basically, what they said was that it obligated the RIPE NCC to prevent any transfers from the member's account to provide a statement outlining the resources allocated to the member, and then eventually when it became a fully executed order, it would require the RIPE NCC to transfer any resources mentioned to the winner of an auction.
.
We never dealt with this before so we went to a local law firm that specialised in IT law and they advised us that the ‑‑ that so long as the registration of IPv4 addresses had economic value and that they could be transferred, that they could also be seized like this, and they said that if we didn't have any room to dispute this, this case, because the way that the third party that initiated proceedings had gone about it was in line with the existing legal principles in the Netherlands and they had correctly followed those principles.
.
In this case, it was up to the member if they wanted to contest the order, and they contested that based on the fact of the case. We couldn't do so because we weren't a party to the case in any way.
.
So, what we did after that, we contacted the legal representative of the third party that initiated proceedings, This party that was in liquidation. We advised them that the IP addresses were not property, in our view, and of the article in the SSA, and they understood this, and they understood that any rights of registrations would also come with obligations and so that they would have to volume the RIPE policies and the RIPE NCC procedures and they agreed to do this.
.
At no point then was the order ever contested by the member and so eventually the IP addresses were auctioned off by the bailiff in the Netherlands and they were sold to another RIPE NCC member, and then at that point we had no choice but to then transfer the IPv4 addresses to this member that won the auction.
.
Essentially what we'd be looking for then in the future would be that any orders that would come in, that they would be recognisable and enforceable by the Dutch courts; that they would be served to the RIPE NCC by a bailiff in the form of an enforceable document such as this court order; that the order must specifically mention the RIPE NCC and create an obligation for the RIPE NCC to perform the transfer, and it's important that we doesn't mean that we need to mention that it's a defendant. It just means that, in the order, it needs to mention the RIPE NCC, And, very importantly, it needs to mention the specific resources so the actual IP addresses, the blocks, not just anything general.
As each order from different jurisdictions may be slightly different, cases might be different, we will review each one on a case‑by‑case basis. The important thing to note is, if we don't believe that they follow the RIPE policies or the RIPE NCC procedures, we do reserve the right not to comply with the order.
.
What we believe then here is that this is a new precedent for the RIPE NCC. We do expect to see more of these in the future as generally once people realise this can be done, then they will do it again.
.
But we don't believe that there is any need to change our existing procedures. We think that they are robust enough and that they ‑‑ as long as the order is in line with those procedures, everything will go according to plan.
.
And that it's also important to note that this was not actually a criminal law seizure, it was a civil law seizure, so there was no authorities involved; it was just between two private individuals. And if you want more information about this, there is a RIPE Labs article, you can see the link there in the slides, and it goes by the same name as these slides.
.
So, if you have any questions, you can ask them now or you can e‑mail me productively or post it on the Members Discuss list and we can get back to you.
ERIK BAIS: Excellent. Thank you very much for this information. I thought it was interesting to hear, and both Gert and I thought it was information that the Working Group should be aware of, that this has now happened. For all transparency, I was involved in this particular auction. A question that I have for you on this is: What if the seized IP addresses are under transfer restrictions, what would actually be preference, the RIPE policy or the Court order?
CIARAN BYRNE: We would ‑‑ it would be the RIPE policy, So we would dispute it then that ‑‑ this is the registration of IP addresses, those rights come with obligations and the obligations that we wouldn't be transferring between that period. So we would dispute it at that point.
ERIK BAIS: Okay. Interesting, good to hear. Any questions from the audience?
GERT DÖRING: I see Remco in the microphone queue.
REMCO VAN MOOK: Good morning everyone. I would like to briefly chip in on this. Of course this has been brought to the attention of the RIPE NCC Board as well, that we have discussed this at quite some length and I'd like ‑‑ just like to reiterate the point that, even though this may be new for RIPE NCC, there is absolutely nothing new or exciting about the legal part of this process. This is a well‑established process, it has been happening around Europe for literally decades. So, in that sense, I mean, I find the latest statement by Ciaran interesting, probably something that we need to have a closer look at, but, yeah, I just wanted to point that out, that this has our attention, we see nothing new or exciting about this.
ERIK BAIS: I noticed Raymond in the queue as well, but he is gone now. Let me see, there is a question from Harry Cross, representing himself, indicates: If there was a transfer restriction, would the claimed IP space then be transferred once the restriction has expired?
CIARAN BYRNE: That could be a possibility. It's not something we actually thought about, but yeah, it would depend if the order had some sort of expiry before you needed to collect it. In this case, it was a liquidation so the liquidator definitely probably wanted to close the company at some point. But if it was in line with RIPE policies, then a RIPE policies and procedures, I don't see an issue with that. Then it would also depend on how long the Dutch courts would hold the pre‑judgment at that, Which prevented any transfers out of the account. So, you know, would they keep ‑‑ would they be happy to keep that in place? That would be up to the individual case.
ERIK BAIS: Okay. Any additional questions? No. All right. Thanks. If you have any additional ‑‑
CIARAN BYRNE: There was someone there who said I spoke a little fast. I am sorry about that. You can send me an e‑mail there if you have any questions. Sorry if I did speed up a little
GERT DÖRING: Thanks for speeding up a little because we were running short on time and we didn't want to run too much into the coffee breaks for people. So, yeah, thank you very much. Thank you to all the three speakers. Sorry again, Nikolas, to cut you short.
.
Should we do another virtual meeting, we will definitely ask for two slots and have more time for discussion. This Meetecho thing works much better for discussions than Zoom did, but we didn't plan enough time for actual discussions.
.
So, yeah, thanks everybody for being here, being ‑‑ for listening, and see you on the mailing list of course. Bye‑Bye.
ERIK BAIS: Thanks.
(Coffee break)
.
