Address Policy Working Group ‑‑ session 2
18 November 2015
11 a.m.

GERT DÖRING: Welcome back. Stopping reading e‑mail now.

As we have published an agenda, I decided to basically stick to the agenda, do the next two items in the sequence they've been published and then return to the discussion on the Open Policy proposal, because there is time left, but you want to software like avoid having to rush the other items later on. So...

This is, what's coming up is not so much a discussion item and not actually policy discussion. It's giving background information that I personally found very interesting, and I think everybody who monitors transfers has been wondering why Romania all of a sudden could transfer out so many IP addresses, what was happening behind the scenes and Ciprian offered this talk for the Plenary around Plenary couldn't take it due to too many good talks and I said it really fits Address Policy, so, welcome Ciprian and thanks for explaining backgrounds.

CIPRIAN NICA: Thank you, good morning. I am with IP broker, but before starting the brokers business I have been working in the telecom field in Romania for about 15 years, so I have a very long background in this field, I know almost everyone. So, I can give you ‑‑ I hope I can give you some answers, because every time I am asked why Romania has been such a big exporter of IPv4 resources.

So, here is the summary. First of all, I'll present you the talk of exporting countries, IPv4 exporting countries. The situation before the exhaustion in the RIPE region in Romania and the confusions between PA, PI, even today many people don't understand, what's PA, what's PI, what's legacy addresses, what does the actual usage of IPv4 resources for telecom business? I have called them honest Internet services. You'll see later why. Then I make analysis of the transferred IP addresses, and maybe a few thoughts on IPv6 expectations.

So as you can see, I have only put in the information relating to PA, provider allocated, allocations, transferred from one country to another, because if they were inside the country, it can not be clearly defined as a sale or ‑‑ I don't know, maybe it was a merger, maybe it was a rearrangement of the telecom market in that country, so the important thing is the exports.

As you can see, Romania has exported over 66% of the total IPv4 resources that they got out of a country. So, that's 5 million IP addresses, over 5 million IP addresses. Considering the fact that before the exhaustion, Romania had 13.1, something like 13 .5 million IP addresses, so that's about a third, more than a third of the total allocated IPs. So, for a country that doesn't have so many IP addresses per inhabitants, which is still in the deployment of broadband Internet and the Internet services is still growing, so is not, the country is not fully covered, we are still growing in this business, and this is an strange situation for most of the people I think.

So, the next country, the next exporter of IPv4 resources is Germany which sold below 2% of their resources, and Russia with 1.5%. So, over a third is something totally unexpected.

So what was happening before the exhaustion in 2012? The market in Romania was growing. We had many small ISPs, they were so‑called neighbourhood networks which many of them now are working together in Interlan, the host of this conference, and during that time there was, the deployment, the development of Internet was really growing very fast, so everybody needed IP addresses.

So, since many were small companies, they couldn't afford becoming an LIR due to the taxes, and many of them chose to rent IP addresses from another LIR. And I even had some discussion at that time because nobody would understand why should they get PI and not PA. So almost every small network in Romania got the PA assignment from another LIR instead of requesting a PI from RIPE.

So, now PI is provider independent and it should have been taken for those that wanted to have their own network, operate their own network, but couldn't become an LIR for any reason, and PA was meant to be assigned to customers of a specific LIR, and so given to down stream networks, it was supposed to be that. And, also, I don't know if many of you know what legacy IP addresses because we don't have so many in the RIPE region, but those are IP addresses which were given out to companies before RIPE existed. So, now they are registered in the RIPE database, like any other RIPE addresses, they are similar to PI, but they have no restrictions, you don't need to find a sponsor, you can, but it's not mandatory, and you can use them just like any PI provider independent IP address.

Also one other problem that I noticed in Romania, there was low interest for RIPE policies, RIPE ‑‑ attending the RIPE conferences, information, finding out what's RIPE. So everybody was thinking, RIPE they are just giving IP addresses, we don't care, we can get them somehow. Everything else is not important.

I think one of the most important things that happened which led to this export of IPv4 resources was the business that reached Romania which is called snow shoe spam, so world wild spamers were renting IP addresses from various ranges, large blocks, so they could distribute through mainly IPs and they would not get detected. So a few guys came to Romania with this business and it was very profitable, so, many started to grow this getting IP addresses, saying that they will use it for customers for regular services while they were actually renting to mailers.

So, as I mentioned before, the misunderstanding between PA and PI was the second factor that led to this exceeding resources that were available in Romania. So, all the small neighbourhood networks wouldn't pay the RIPE fees and they preferred to pay very, very low rental costs for leasing the IPs from other LIRs.

Now, what was the actual usage? Because I wanted to understand what was the actual usage of legit business of IP addresses, so I took some statistics from the national regulation authority for the top five providers, top three broadband, and I have added the other two mobile operators, and I have added a number of allocations they have, PA allocations that they hold. So that's about 4 million IP addresses. And according to the national operating regulatory authority, we have over 90% market share. These top five companies, three from broadband and the other two mobile from the three broadband they are also providing mobile services, all of these five companies have only 4 million IP addresses allocated, even today.

So, how is it possible that 30% of IP addresses that were allocated to Romanian LIRs were covering almost 95% of the customers? This was clearly a sign that there is an excess of IP addresses which were actually not used for providing services to customers. These are mostly residential services, but I don't think that the other 70% of the IP addresses would cover the business sector which is much smaller than the residential sector.

So, when the ‑‑ it was close to the exertion, during that time it was a coincidence that many smaller networks, smaller ISPs were bought by larger ISPs, and the companies that bought them had enough resources at that time and they decided they would not need the IP addresses, just the customers. So, the smaller ISPs that were selling their business returned the IP addresses to the LIRs that were renting them to the ISPs.

And after leasing the IP addresses, some of the businesses were leasing the IP addresses to mailing, they have decided to sell them because it was a much profitable business in the rental.

So, today, we have over one third of the IP addresses of the total allocations that were given to Romania that are already sold to LIRs from other countries.

So, I have made some statistics, I gather some data about all the exports, all the transfers. I am collecting each data transfers from the RIPE database, and since I know almost everybody what was doing, you know, if they were an ISP business or just behind some spam related business, I was able to make an estimation, an analysis which I cannot say it's a hundred percent accurate, but according to my knowledge, from all the ISPs that were exported, over 68% were IP addresses that were not used for providing Internet services to customers, to legit customers before, they were taken by companies which I know almost for sure that they were just taking them for spam business.

The other third has been, represents the IP addresses that were leased by smaller ISPs, so that was really an excess that became available after the small businesses closed, sold the customers to larger ISPs and they were left with IPs that they would not need.

So everybody has seen that jump in Romania has made the most, the largest numbers of transfers. So, about half of all the transfers that are recorded by RIPE, I'm talking about PA allocations which were transferred, so about half is the number, half of the transfers were originated by jump, totally, exports and local transfers.

About 700,000 IP addresses were given ‑‑ most of them were given for free to the previous rentals, renting companies, so you know Jump has given about 700,000 IP addresses to the remain yen smaller ISPs, which still continued their business, still entered the IP resources and even after doing that, there was an excess of over 1.5 million IP addresses which were sold already.

So, why didn't the larger ISPs buy the IP addresses at that time before the exhaustion? Because I was working for a large ISP and I was all the time telling them, let's keep the IP addresses, maybe it will be good to have them in the future. Everybody was so confident in IPv6 deployment that Romania was for a while among in top 3 IPv6 deployment. It was one year before the exhaustion was announced that one of the largest ISPs in Romania has started to provide dual stack IPv6 to their residential customers. The problem is not that simple because it's very easy to have ‑‑ to give IPv6 to any customer and have about 30% deployment, but going from 30% to something like 80, 90% is the hard part and it's very difficult to achieve because for the problem with CPEs with computers and also there will be some technical issues, trainings that need to be done for the technical team, and even if Romania has deployed dual stack services, so for now it's about four years ago or something like that, we are not seeing very high IPv6 outreach. So today it's only 6.31% adoption rate in Romania, which has started it about four years ago, so, it's not such a promising percentage.

Now, the problem is who can drive the IPv6 adoption? In Romania, probably the largest ISP, has tried to ‑‑ has deployed IPv6, has tried to promote IPv6 deployment, did everything they could to move to IPv6. The problem is that here it's not enough. The top 1% LIRs in the RIPE region have a total PA allocations about 360 million IP addresses, so that's about two thirds of the total RIPE allocations. So if tomorrow the other 99% LIRs, ISPs in the RIPE region would decide to move to dual stack, to adopt IPv6, it would be still about 30%, 40% adoption rate globally, so in my opinion, the only way to move to IPv6 is to push somehow the top 1% LIRs to adopt IPv6 to implement dual stack.

So maybe some policies would be useful, but as it was discussed earlier, policies are hard to ‑‑ it's very difficult to create a policy that is perfect. Nothing can be created perfectly, so, in my opinion, the policies that were adopted in the past were good at that time, were what people have chosen, have reached consensus, and today it's hard to repair the mistakes that might have been made. So, the only solution is to go forward with the policies we have, try to promote IPv6 adoption, but I don't think some drastic changes could be done that ‑‑ cannot force anybody to do this. We can only explain, train, present the ones that have implemented IPv6, and they are satisfied with the solution, they have experience, they could share it with everybody and maybe this will be ‑‑ the adoption process will be sooner.

But, in my opinion, I don't think it will happen in ten years or something like that. So, even if IPv6 deployment is promoted, it will still take a lot of time, and so far, Romania has been the main supplier of IPv4 resources for the region, and now since it's closed to the limit of available exportable IP addresses, I think we are going to reach an unofficial exhaustion, so, probably be very soon Romania will not be an important exporter of IPv4 addresses.

So, that's why some measures need to be taken because Romania was one of the factors that kept prices at the reasonable rate, and it gave an important supply of IPv4 resources to the community.

So, now, regarding the earlier discussed policy, I think we should not hurry because even if today the RIPE has about the same size in the last /8 pool, maybe in the near future it will not be the same because there will be no other supplier like Romania that can give up to the community 5 million IP addresses, because if other countries would have had this amount available, exportable, probably they would have done it already.

So, I think the best thing would be to stick to the policies that we have, to keep IPv4 available for the next 20, 30 years to smaller LIRs, smaller ISPs, smaller businesses. But we also need to think about solutions to promote IPv6 adoption. And we need to do that for the top 1% LIRs, we need to, I don't know how, but we need to help them understand that they are the ones that can try this change, they are the ones that have the responsibility to help the community more move from IPv4 to dual stack and then to IPv6.

Now, I hope I gave you some basic information and some basic statistics and if you want to know any details, want to dig into some more info, have you any questions relating to accuracy of the data that I provided, please ask your questions

GERT DÖRING: Thank you. This was really good background info on what has been happening in this economy, because the economies develop at different speed, and depending on when you reach a certain point in these sort of the Internet evolution, circumstances are different. And they are quite unique here. So, thanks for explaining that. It was good.

So, any questions /remarks from the room? No. Okay. Thank you.


CIPRIAN NICA: It means that I provided satisfactory information, accurate, so I am glad. Thank you.

GERT DÖRING: So, now we jump sort of like back in the alphabet to letter D: Feedback from registration services. Usually done by Andrea Cima, this time Ingrid Wijte stepped in because he couldn't be here, and while this is a regular thing, telling the Working Group what effect the policies we decide on have on real day‑to‑day operations, so this is a very valuable thing. Please.

INGRID WIJTE: Thank you. As Gert said, Andrea apologises but he couldn't be here, he is taking care of his new baby boy, so also quite important to do.

Area we doing this update? What do we want to achieve? And our main purpose is to report back to the community on trends we see, issues we see, questions that are asked to us, and where applicable, ask for guidance on how to deal with these topics, and thirdly, also to provide input to you the community for policy discussions.

And I have got three topics on my agenda today.

And I'll start with the action point that we had from the previous meeting in Amsterdam. And the RIPE NCC was asked by the community to discuss if we need a policy in place in order to publish mergers and acquisitions, in a similar way as we publish the transfers that take place based on the policy.

So, we had that discussion and we concluded that yes, we can indeed publish without a policy after we make announcements so that the parties involved are aware that this will happen.

So, we would not be able to publish what has happened before the announcement but after providing information we would be able. However, in the meantime, the proposal to 2015‑04 was published which also proposes to publish mergers and acquisitions in a similar way.

So, what we're doing now, we're waiting for the outcome of that discussion and we do not want to interfere. So, depending on the outcome of that, we either publish because the policy tells us to do so. If the proposal does not reach consensus, we need to go back and see why it did not reach consensus and how the community feels about publishing these or not. We do not want to ‑‑ how to say ‑‑ go past the decision of the Working Group on this publication.

So, there will be more in the future.

My second point is purely for informational purposes. Over the recent year, almost two years, we're receiving an increasing number of e‑mails, complaints from end users that I am having some difficulties.

Now, Ciprian already mentioned a little bit about how things were in Romania, and Romania is not unique in that sense, but offer the region we have seen that some non ISP LIRs were handing out sort of independent assignments to end users. So they were not connecting their customers to their network but they were giving them addressing surfaces, now, in the recent years, we're getting e‑mails from a lot of these people, and their complaints, whether it's true or not, but this is what they are telling us, cannot judge what is real or not. They are saying, this space was given to me as PI and now it's not. The confusion between PA and PI that also Ciprian just mentioned. And now, if I want to keep using this space, my company is using it, my network depends on, it I need to buy it now. And if I don't, it will go to the highest bidder.

So, these are the e‑mails we're getting. The number is increasing. What to do with it? That's not our place, but we wanted to inform the community of what we're seeing here.

The point here is that these practices are, strictly speaking, not against current policies, although one could argue whether this was as intended or not. The policy is clear: LIRs can transfer their allocations, they are responsible for their blocks, so, as long as they don't break the policies, they are free to manage their blocks as they please.

So, that's for the PA assignments.

Moving on to my third topic which might raise some discussions, questions. We have been asked ‑‑

GERT DÖRING: Ingrid, sorry to interrupt. I think it might be useful to actually have a quick discussion on the previous one to sort of like keep things in focus, because I have a question on this. You say this is not against policy. If I'm a PA holder, split up my PA and transfer this to an end user, it's very much against policy.


GERT DÖRING: What's the model there sort of like ‑‑

INGRID WIJTE: The one that receives the PA assignments that they have been given need to become members in order to receive them as will allocated PA.

GERT DÖRING: That's sort of part of the model that ‑‑

INGRID WIJTE: Which keeps it within the policy.

GERT DÖRING: Understood. Just wanted to be sure I understand that right. Is this particular countries that you see this more often or ‑‑

INGRID WIJTE: Several countries.

GERT DÖRING: Spread over the region?


GERT DÖRING: I see Eric already coming up.

ERIK BAIS: Can you provide numbers on how often this is happening and LIRs actually strong arming customers into, you know, cancelling their contracts basically and telling them, well either you need to pay this ridiculous amount, and if not ‑‑ or you buy this space, basically they are moving out of the game. It's an exit strategy. Although, it should be seriously frowned upon, and probably even you know, although we as a community may actually you know, I would almost say, I'm not going to ‑‑ I'm not telling you to do this, but to actually say is there a name and shame wall for this? Because this is seriously frowned upon business. And it gives respectable companies that are actually doing normal business a really bad name, and we have been hearing this as well in the community, that this was happening. But, you know, I really couldn't believe that this was actually common practice in certain countries or by certain ISPs.

The question is: How often does this happen? And is this actually becoming a concern that if at all can we address it? Is it possible? I know that cannot interfere with businesses, you know, stopping their business or moving out those kind of things, and it's a slippery slope we're going into, but you know, what is the possible solution here? Because, on the other hand, you also need to be able to protect the people that are actually legitimately using this space already for X amount of time. So, I know it's ‑‑ there is not an easy solution here, but you know, I think a wall of shame would actually be helpful here to actually get, you know, is it the certain region? Is it the certain ISP or type of ISPs? You know, what are we talking about?

INGRID WIJTE: To begin with, the numbers have been increasing. I think at the moment we see two other weeks, five e‑mails a week regarding this. So that's a significant amount.

I have to mention, though, that these are e‑mails were end users. So, we have no ‑‑ I cannot say that this is indeed what is being ‑‑ this is with they tell us. So, again, what the LIRs that supposedly do this practices tell the customers, I cannot say for sure, because you know, that's ‑‑ it's in a way, it's hearsay. Although we do see that there is a lot of transfers taking place, so that's factual information on the basis of coercion or not, it's difficult to say. So, I do want to make that distinction.

What can be done? I think it's a difficult matter to solve with current practices and the market that has entered the Internet, the IP addressing industry. But, I suppose that this is in part a self regulating matter of ISPs wanting to do the proper thing and the best for their industry as a whole in their country, and a wall of shame, if we're told to do that, we can, but, again, this is ‑‑ this could have an implication as this is information that's provided by end users. So, before publishing names on a wall of shame, we would have to verify ‑‑

ERIK BAIS: It's probably the only way to actually you know get an insight in what is actually ‑‑ who are the parties behind it to actually do this. So... but I know that you know, it's unfair to ask or unfair to actually start doing this. But that's more the personal feeling I get out of it that might actually be the only way of getting some insight on this, and basically, you know, who are the actors on actually doing that. But perhaps Ciprian on the other side might be able to provide some more insight.

CIPRIAN NICA: I will have to totally disagree with Eric and I want to thank you for clarifying this because sometimes we receive requests from PA assignment holders that ask us to sell their IP addresses. And I have to explain that when you rent an apartment, you live in it for even ten years, that doesn't make you the owner of that apartment. So it's the same here. The PA assignment, the companies that have a PA assignment have a contract with that LIR, so what they should do what's written in that contract. If they are not happy with that, they can address the authorities if they think something is illegal, but I don't think it's the RIPE's ‑‑ RIPE can do anything about it. RIPE deals with LIRs, with PA allocations and now the PA assignments, that's the job of the LIR, and that's between the LIR and their end users. So, I don't think it can be a shame or something like that when you decide to get out of this business.

ERIK BAIS: I understand the emotion in that. It's not up to us as a community to dictate on how certain people do their business. And like I said, you know, it's changing contracts that are already in place and yes, it's an assignment, and basically the ‑‑ some of the LIRs are strong‑arming customers to get out of a contract and say, well, either you buy the space or you have to pay X amount or increasing the fees for that same allocation that they have been using for the last ten years for €200 a year and now saying well you need to pay 1,500 per month. You know, that kind of stories we have heard. And, so, yes, it's not something that we as a community can solve. But you know, it's seriously to get more insight in how often this is happening and what is happening might actually give some very good insight. And you know, because some ‑‑ is there a way to actually protect, you know, that kind of customers for their own LIR in that case. And I know it's a tricky situation. But you know, we have heard the stories as well.

GERT DÖRING: I go next.

CIPRIAN NICA: I will give a short reply. I give the same example with the apartment. If the rental prices are growing, you are not going to say to the owner, I have been renting this apartment for €100 a year and now I want to keep this for the rest of my life. So it's something that is between the LIR and their customers, and it's ‑‑ I don't think any LIR would do something against the contract. So, they sign the contract, it's something between two businesses which can be dealt only between that two businesses, in my opinion.

GERT DÖRING: Turning around my badge and speaking as just somebody from the community who has sort of like frowned at Eric on LIRs that don't run a network but really just lease out addresses. In the end, it really is down to what's in the contract, and if these contracts are 10 or 15 years old, most likely there is nothing in the contract that really protects the end user, because end users didn't know, we didn't know so, yeah, it's a bad situation, but I'm not sure it's actually ‑‑ if the LIR now decides that basically they want to get out of the business, as you say, exit strategy, and just split up their allocation and sell it, this is contractual issue between them and their customers. It might not be a nice thing to do and companies usually aren't nice on purpose, and it might not be the way I personally envisioned the way LIRs would do business, but I'm not sure we can actually make this into a wall of shame by even agreeing everybody that this is a bad thing to do. It might not be a customer friendly thing.

But if the contract says the contract has to be renewed every year, otherwise it will just end. They say we're not renewing this contract. That is perfectly fine. And then giving the customer the option to either return the space or buy, it it might be strong arming at the ‑‑ I wouldn't definitely like it when I'm the customer, but... that is contracts.

AUDIENCE SPEAKER: Hi. Sandra Browse RIPE NCC on the chat monitor and I am going to read a comment from Elvis Vilea. Elvis is making a comment to what Eric is saying and I'll read it.

"Even the RIPE NCC template for the end user independent assignment contract says that the LIR can change the terms of the contract by updating them on their own website. So Eric is talking about stuff that he has heard from some very upset customers and maybe not really the truth."

AUDIENCE SPEAKER: I am Christian. I am from Jump Management and probably I am the most person that know this situation very well. We have done this rental to the neighbourhood, probably we have done the rental for the, I don't know, maybe 90% of the neighbourhood networks, so, now we have this, we'll say this problem, this issue. We know for sure that many of them are not using the IP ranges in the percentage that it's right. So, basically, they have a lot of free spaces. So, we should take some actions to somehow solve this one. We have found a few, let's say, methods to do that.

First of all we offer them initially an allocation fee, just like the RIPE setup fee, and initially we say okay, you will not pay any fee if the RIPE policy will not change in time. Somehow, the IPv4 space was ended. So basically, cannot receive any more IPv4 from RIPE. Basically, at that time we have put an annual fee which was about, I don't know, €30 per year, lower fee for a /24, which is a lower fee for any RIPE region for any ISP. Then in time we ‑‑ you start to making possible the IPv4 transfers. So, at that point, we say okay, let's see how many IPs are in use. Let's see how many IPs are used for not so legitimate business and something like that. At that point we have cancelled, I don't know, let's say many, many contracts with the customers that we feel they are doing some wrong actions. At that point everyone was not happy. But also we have the most rate them, for part of them, we have rate them by having logs and notification for spam and abuse and something like that.

So that's a clear situation. The registered contracts have been closed. First.

Second, we have tried to see which IPv4 addresses were not used, not even announced. And we have cancelled those ones because also your policy say if a range is not used for a specific period of time, let's say 30 days, then it's clear that you are not using it, so it can ‑‑

INGRID WIJTE: I don't think there's anything in the policy saying that ‑‑

AUDIENCE SPEAKER: No, no, it's not saying the days, but it's a reasonable period of time.

INGRID WIJTE: "Used" is not the same as announced. That's basically the point I want to make.

AUDIENCE SPEAKER: So, they are not using the IPv4 addresses. So, we also cancel that IPv4 addresses. At a certain point we say okay, cannot get no longer IPv4. Okay. Let's have somehow a reasonable, not €200 per year like our previous speaker say, let's say €125 per year, which is also a reasonable fee for /24 for a year, not for a month or something like that. At that point, we have many of our customers say we are a small business, how can we do that? And we know that they are not using the whole space. We say okay, if you want to do that, let's have something like that. You should release the unused space which you announced, but you do not use it, and have the other ones, half let's say, transfer it to your LIR. You can become an LIR, you can move it to an existing LIR. So basically, we can given them from the rental to become, let's say, somehow the owner if they become an LIR or they can move to another LIR where they can sign a new contract and give them the possibility, let's say, after two years to move to another LIR, so they become somehow independent of jump, of any LIR.

At that point, many of customers wants to do that. Some of them didn't want. Okay, you don't want to do that, okay, you want to buy the range, and move it and secure your business. That's the right thing to do. If you didn't do it in the past when you, let's say, you are happy with the fact that you pay a small amount and you get IPs and rent them and don't have an annual fee, probably now is the better thing to secure your business, become an LIR, and pay some fee and have your business. That's the right thing to do. Okay.

Some of the compliance didn't want not even that. And didn't want also to pay the fee. So, for those clients it's clearly that we will no longer keep it.

INGRID WIJTE: I think that's a good explanation from the other side. Like I said, we only hear one side of the story, so thank you for at least telling your side, your story.

AUDIENCE SPEAKER: That's the real thing and probably many of the new LIRs from Romania that become the new LIRs in the last period of time know that and they have done that with us, with the help of us, us to helping them to become an LIR, filling the form and something like that. Thank you.

CIPRIAN NICA: What I want to point out again is that everybody knows here in Romania, Jump has given out for free over half million IP addresses to the small businesses here, so besides the complaints, you should also hear the good things that are done.

GERT DÖRING: I think that's actually something ‑‑

CIPRIAN NICA: LIR has given out for free IP address to say their customers, after renting them for a very small fee.

GERT DÖRING: I noticed that in your presentation, and positively noted it, so, yeah, I think that was a good thing, because ‑‑ well, this economy is not that strong, so, having the IP addresses without major fees is a good thing. And that's in the spirit so to say.

Anyway, I think what we're hearing is that it's a fact of life. It might not be to everyone's liking. I think you are keeping an eye on this anyway, but this is something I want to ask you to sort of, if the patterns change or if it's sort of like seriously goes before the lawyers and courts and so on, keep us informed. We might want to know. We might not be able to do anything or might not be willing to do anything. But it's good to know what's going on.

INGRID WIJTE: Okay. Will do.

GERT DÖRING: And with that, please go ahead.

INGRID WIJTE: The last topic on my list, this is something that we wanted to talk about, we received some requests to talk about, and it's about the allocated PI and allocated unspecified that's held by LIRs. So I want to give some background to that, some numbers, and what is happening currently with these blocks.

So, what is the situation? We have 36 LIRs that currently hold 95 allocations, both PI and unspecified. And these LIRs ended up these blocks because they used to be last resort registries and decided to become LIRs and to keep the administration of these blocks. And other last resort registries decided not to become members of the RIPE NCC and they handed over the administration of these blocks to the RIPE NCC who has cleaned them up and managed them since then.

So, the policy, IPv4 policy has some statements about these blocks. And one is that these allocations are de facto aggregated but not formally PA, because at the time, these assignments were made, there were no clear contractual arrangements made where there was not a habit for termination of the assignments, things that we were talking about just now, what happens if you move LIRs and what happens with the address space.

The IPv4 policy also says what is the recommended practice for these blocks. And it says that where possible, they should be converted to allocated PA. When customers leave, they are asked voluntarily release the address space, and where possible the LIRs should work towards converting the blocks in time to allocated PA.

So, this creates a little bit of a different approach between the different blocks. So, the RIPE NCC has allocated PI and we assign via, or assigned, we currently no longer do that, but we assigned via the LIRs directly to the end users of this PI space. And as such, all the v4 policies for PI assignments apply. So if the end user changes LIR, they keep the address space with them because it's assigned directly to them. 2007‑01 applies to these assignments and when they go out of business they return it, the block goes back to the RIPE NCC who holds the less specific allocation.

So we can reassign it to new customers.

In the case of the LIRs holding the PI or unspecified allocations, the situation is slightly different because there is much more uncertainty on the nature of the situation. So, the end user can have either assigned PI or assigned PA from within these allocations. And as I mentioned before, these are de facto aggregated but not formalised as PA or as PI in following that same statement.

So, we are, as the RIPE NCC is for its allocated PIs, is responsible for the allocations that they administer. And the LIR and the end user have made agreements, or not, on ‑‑ an account of those agreements is not something that we, as RIPE NCC, are a part of. We are not aware of what's in those agreements. And in this case, as I quoted earlier, when the customer leaves, the address space by default returns to the less specific block, which is the allocation held by the LIR, if they terminate the service, depending on the agreements that they have made.

So, what numbers are we talking about currently? We have, like I said, 95 blocks out of which 66 are unspecified. And within those 66 we have 28 which are purely assigned PA. There is no assigned PI in those allocations. The larger part, 38, have a mixture of PA and PI. So, it's neither. And for allocated PI, the situation looks a little bit better. It's 29 blocks and they are almost all purely assigned PI. I believe there's only one that has a very small mixture.

So, how do we treat those blocks? What do we recommend? Well, we encourage for LIRs to strive to convert them and we have done so over at least the last 15 years, and we encourage not to create new assigned PIs, especially on the mixed blocks, and where possible, in time, move to allocated PA as currently described in the policy document.

So, that is what's happening now. This is like 15 years of recommendations and we still see 95 blocks. So, a lot of LIRs have told us that they are not always fully aware of what agreements were made at the time. They don't know either. So, rather than creating a lot of problems and confusion, a lot of them decided to leave the status quo at it is, just let's not create a lot of movement there and keep an eye and as time goes by, we will, you know, follow the proper proceedings.

Should this change? Should something be done? I don't know. But should the community feel that this needs to be cleaned up, we have brainstormed a bit and have some options that could be considered.

So the first one, quite dramatic, convert them all to allocated PA. Just in one go, no more allocated PI, no more allocated unspecified. In one big transformation, we change it, both allocations and assignments. That has some problematic effects.

Another option could be, like the last resort registries did in the past, hand over the blocks to the RIPE NCC. We will clean it up in the same way as we did with 2007‑01, we will contact the end users and follow‑up with them in time and spend the resources on doing that.

Well, 2007‑01, we know how to do that now. We have learned from that.

Another option that we are encouraging is, when one of these LIRs splits up, one of these blocks, transfers it to convert it to allocated PA. As the policy states, where possible it should be converted, so we encourage that trend.

And another option is to do nothing. Just keep it as it is and let time solve the issue, if it needs to be solved. And there might be other ideas that we haven't come up with yet. But... with this, I think I'll hand over to the room to talk about what should be or should not be done.

ERIK BAIS: I have a question: The majority of the space, was that actually handed out through RIPE or before RIPE? So was it actually originally legacy space?

INGRID WIJTE: These were ‑‑ the last resort registries that received it from Internic and when RIPE was founded, that those options were given to those last resorts to either keep them as allocations in the system or hand them over to the RIPE NCC. And in a transition phase a lot of these last resorts also had to forward their requests again to the RIPE NCC to further process. So that's a mixture of things.

GERT DÖRING: And some of these blocks actually came from the RIPE NCC.

INGRID WIJTE: Exactly, yeah.

ERIK BAIS: Because, if those companies actually you know received their prefixes prior ‑‑ directly from IANA, then I think it's not good to state well let's, you know, convert them to allocated PA. I would rather say you may want to give them the option, do you want to go back to legacy or allocated PA and then we'll manage it for you or you actually get your legacy status on it and basically deal with it that way. I would prefer to see that option, and I think then at least we know how to proceed moving forward, either it's going to be legacy or it's actually you know, they make the decision to convert and resolve the issue here.

INGRID WIJTE: Well, to clarify. They got it from Internic, not directly from IANA, so there is a slight difference. Internic was the predecessor of the RIPE NCC and the RIPE NCC took over all the responsibilities from Internic. So, it's a little bit more complex than some of the legacy /8s that were indeed directly from IANA to the resource holder.

And at the time, when that transition was made, agreements were made with these parties to what happened to these blocks. So that definition of legacy or not legacy was made at that time in certain agreements. So, I'm not sure if we could override the agreements that were made in those days, I think that's something that would have to be looked at if so asked.

AUDIENCE SPEAKER: One comment from Elvis: "As a customer I could not see a difference between the signed PI made by the RIPE NCC via an LIR and assigned PI made by the LIR. I would think that end users would have a signed PI and want to move from another sponsoring LIR they should be able to do it just like with PI from the RIPE NCC."

INGRID WIJTE: I would like to respond to that because that depends again on the agreements that that LIR has made with that end user on the basis of assigned PI. The RIPE NCC is not aware of these ‑‑ the content of these agreements, so for us to make that decision for an LIR, to move that ‑‑ to split up their block to make a hole in their allocation and move it to another LIR, that decision has to be, as the situation is right now, be made by the LIR who is holding the parent block.

AUDIENCE SPEAKER: What if there is no contract between the contractor and the end user?

INGRID WIJTE: Again the LIR, as the current hierarchy in the registry system is the LIR has to be made responsible for that parent block.

AUDIENCE SPEAKER: Yes, but the end user requests to the LIR this PI assignment. You have approved it in a ticket number and there is no contract between the LIR and the end user. Practically the end user will think that it's a PI and RIPE have approved is because RIPE requested me some documents like registration papers and some other documents.

INGRID WIJTE: I would like to look at the tickets that you would have. But what we have have done like new assignments, the LIRs were asked indeed to send in request forms, ask for the allocated PA. These assignments were approved from a process matter in a similar way as we have done assigned PAs, so we have not created separate entries for these assignments. They have come out of that block from the LIR.

AUDIENCE SPEAKER: Yes, but at some point the end user will think that it's a thing between you and the LIR.

INGRID WIJTE: And that's exactly why we're bringing it up. We are referring them to the LIR, because they are the next in line, they have a business relationship with the LIR.

AUDIENCE SPEAKER: And the LIR will say no.

INGRID WIJTE: But that's I think a similar discussion we had earlier, cannot judge on the agreements that were made. We can, with assigned PI that was made from our allocated PI, because the lines were much clearer and the rules have been defined when we made those assignments. As for these cases, we don't know, and I agree that there is confusion there when we get the questions, but...

GERT DÖRING: I actually ‑‑ I'm in the same camp as this gentleman. I want to challenge the the interpretation by the NCC. The LIR has made the conscious decision to stamp this as assigned PI. So, I think, personally, turning around this. It should be Teredo as if it were assigned PI, and that means it's independent of any contracts. Or actually, you should go out and find the contracts, so, I think 2007‑01 applies to this space. But yeah that is actually speaking as me personally Internet citizen and so on, but you might want to revisit this whole matter also internally on your interpretation and talk to the affected LIRs.

INGRID WIJTE: I think that's why we're bringing it up is ‑‑

GERT DÖRING: It is good that you do.

SANDER STEFFANN: I think the letters PI actually stand for provider independent. So... it should mean that.

INGRID WIJTE: I think a lot of this also original it's a from the moment that those were introduced and people basically just picked and choosE. I'm not sure if there was a conscious decision made at that time to go for red or green or the IRPA. So, again, what that decision that was made at the time of giving that assignment is something that registration services, RIPE NCC, is not aware of. And in a lot of cases, as we have been informed by LIRs that hold those blocks, they are not aware of it either. So...

GERT DÖRING: In that case go by the database object. They have made a conscious decision to put that status in.

WILFRIED WOEBER: The manager of our local registry, since May 1993. I think if you ‑‑ first of all, could you maybe go back one or two slides with a list of options?

The reason why I'm at the microphone here is because of the feeling that you are mixing a couple of ‑‑ in particular with the status of an address block on one axis and the timeline on the other one, because like in our case, when we got the block to do assignments from the RIPE NCC and it was already distributed by way of the regular IANA RIPE NCC local registry, it was before the separation or the distinction was made between PI and PA. So, as we only distributed IP addresses for the customers of our operations, we, very early on then, agreed with the RIPE NCC to relabel from undefined to PA. That was easy. But, at the same time, in our little country there was the dot set registry, the last resort thingy, and on purpose, that big address block was managed by an entity which later became labelled as a local Internet registry, but it was managed inherently from the technical point of view as a PI block.

So, this is the reason why I think the option of converting all the 95 blocks is not going to fly, to relabel that to PA, because at least it would ‑‑ in my opinion, fail at least for those blocks or those registries which are still in place that have been last resort registries. That's one thing I wanted to point out.

And the other thing is my feeling is that we are oversimplifying a little bit because I do not agree ‑‑ well, go back a year or two ‑‑ even at the point in time when the RIPE NCC was in existence and we could obtain addresses by the relevant mechanism, there was still different paths to obtain addresses. In parallel, I was in the framework of a research project, of a big one that had a block directly from IANA, and there are other ways to get addresses, that eventually led to the early registration transfer mechanism and project. So, my feeling is that everything which has been allocated or given away for management outside of the regular RIPE NCC food chain actually has to be labelled legacy.

INGRID WIJTE: The number of blocks, and I don't have that number by heart, but at the beginning of the legacy policy implementation an analysis has been done of several blocks that were labelled as allocated PI or unspecified which have been relabelled as part of the implementation to legacy. Numbers I don't have.

WILIFRIED WOEBER: I'm not looking at the numbers, but just at the complexity of the whole thing and my suggestion would actually be to have some ‑‑ have some us old guys flock together with you and try to come up with some sort of chart like what was happening in the timeline, what was happening at the situation and labels at that point in time, what has been sorted out already, and that's the most part of the legacy stuff, but I still think there are quite a few loose ends and I don't think that splitting will be the the solution for all of the blocks, as I'm pretty sure that converting everything to PA is not going to fly. So I think it's a bit more complex than we are having in our head. Which

INGRID WIJTE: I have to say by, it was intentional to put quite a dramatic solution there. So... I see it's not as clear‑cut as it is.

AUDIENCE SPEAKER: Donas, we are running this sort of last resort in Sweden, and these blocks are very few, it's a very rare kind. When I asked at the general meeting about this, the executive board had no idea there was anything like allocated PI. Actually they said this must be wrong, you should change it because there can not be any such thing.

And as Eric said, earlier, and Wilfried, these addresses have a very special history. They are sort of legacy‑ish, have been used, sort of a PA‑ish way. They didn't have any status at the time and to say that well if they are assigned PI now, they should be treated as any PI. Well, it's not that simple. So I agreed with Wilfried that if we need sort of more order here, the people involved should actually talk to the NCC and see what they can do about it.

INGRID WIJTE: I think that's it also, if the owners of these blocks and the community at large think something should be done, another option is simply to keep it as it is you know for already quite a long time. So... there is multiple ways indeed to proceed and it's quite complex.

AUDIENCE SPEAKER: Well, almost everything I wanted to say has already been told by all the other speakers that were before me. Just, don't convert the superblocks to allocated PI. PA. There were blocks inside that were sold and labelled from the very beginning as allocated PI. When RIPE was existing, so there is really no reason ‑‑ it has been told, there was a conscious decision to label them as PI, not differently.

AUDIENCE SPEAKER: The continuation on Elvis comments before as a reply to your answer.

"As far as I know, with PI assignments made in the very old ages, the LIR would request an approval from the RIPE NCC for the PI assignments to the customer. The decision of whether the PI block would come from the RIPE NCC or the LIR was not transparent to the customer. The customer has received the PI and he should be able to move it anywhere. I do not think that the NCC's interpretation is correct."

AUDIENCE SPEAKER: Erik Bais: So, if ‑‑ looking at this whole process, if I look in our own system, we see around 29 entries of different companies that basically hold any kind of form from allocated unspecified, so it's a fairly small set of companies. I think the majority of the companies are actually present here. And for allocated PI, it's actually interesting, there are only nine different companies that are actually doing this. And one of them actually is the RIPE NCC itself.


ERIK BAIS: So, the impact on this is actually very small, is less than 40 entities that actually do this, and the majority actually are a member that are currently present here.

INGRID WIJTE: Yeah, they all are member ‑‑

ERIK BAIS: The question now is: How long are we going to debate this to actually get to a conclusion here? Because I think they are actually here in the room and we can basically get this solved and basically do this on a face‑to‑face. This should not take as long as 2007‑01.

INGRID WIJTE: I agree. I would definitely not propose a process that long.

AUDIENCE SPEAKER: So, still a continuation of Elvis's comment.

"The solution, as I see it, would be that PI assignment holders can sign a contract with the sponsoring LIR, could be the same LIR, and keep it as PI. Space that is not registered as a signed PI could be deaggregated and changed into allocated PA or assigned PI to the LIR."

INGRID WIJTE: I think that's one of the things that could be an option, but, again, that has to be agreed upon by that LIR. It has also needs support from the community, and I think that is a discussion and information that has to be provided, indeed. But not by the RIPE NCC on its own making that decision.

HANS PETTER HOLEN: The observation is that we have two different classes of addresses that have some different properties. Moving them around from ISPs portability is the one aspect. Being able to suballocate it to your customer is the other aspect. So, rather than us sitting here and making policies for those few that Eric said, would I strongly suggest that you gather them in a room and sort of ask them, what's your needs? I guess 80% of them will say the same, the remaining 20% may have to think about it and maybe that's also easy. Rather than have a long winding discussion here where 90% of us in this room it doesn't affect us, it's academic, try to involve those.

INGRID WIJTE: I think that's a valid option. We are willing to sit down with those block holders. I would, though, find it relevant that after those discussions, that there is a moment for reflection as well by the community at large, because the fact of the matter is that allocated PI currently is, could have a potential different value as well as the other one. So I would think it's important to report back before final decisions and conversions are made. But I think the discussion can indeed be held in smaller group. But final conclusions, I would recommend to keep that to a bigger group on what to do with those and whether everybody supports that choice, as was done with the legacy proposal, which was brought to not just legacy holders, but to the community, the RIPE community as a whole.

GERT DÖRING: And indeed I think these two are a good closing remarks on this. Maybe explain why I'm so interested in this, because the fact that there's two different things labelled PI is really confusing the holders. What rights do they have? What obligations do they have? Do they have to have a contract or not? And I think it's important to actually sort that out.

I am fully aware that this is a very complicated can of old contracts and old not contracts because everything was done sort of like just so, because that was the old Internet 15, 20 years ago. But the suggestion to actually round up these 14 or 29 affected entities and try to come up with a strategy and then sort of present the strategy here and say is that what you want sounds like a very good plan for me, and like an action item for you. So thank you.

That was clear from the start. It wouldn't be without work for you. Then we trust you to do the work right. So...


GERT DÖRING: Okay. I promised more time to discuss the last /8 proposal. We actually spent more time on this than I expected but we still have five minutes left, so Radu, if you want, it has been brought up that people sort of circumvent the last /8 policy by opening new LIRs and LIRs so the same person just opens five LIRs, this is actually not something we can solve. But there is the AGM this afternoon, and they can ‑‑ the members can decide if this is something the members want to see happen, because this affects money, this affects membership so it needs to be addressed, but not here, so all of you that go to the AGM, if this is relevant to you, voice your opinion there.

And now back to this, just maybe overrun five minutes into the lunch break, blame me for that. So, further comments...

SANDER STEFFANN: I just want to make one comment. I think one of the things that started this whole discussion is that people look at the graph that Marco made, but on the website you only see like oh you know the pool isn't shrinking, and can you please put the graph on the screen?

So I think the important thing to realise is that the blue bar is actually the final /8 and all the other bits on top are things that came back, but I think it's important to realise that those are mostly one‑off advantages. This is not something that will keep happening. We will not keep getting agrees addresses from IANA. The 2007‑01 process is being completed, so that will also stop so I think it's important to realise that although it looks like the pool is growing, that's just because of a one time advantage and not something permanent. So, we should keep that in mind during this discussion.

RADU‑ADRIAN FEURDEAN: I know this. Some people know it, but not all people know it, and then there is another issue is that while there are ways to BGP around voluntarily or not around the proposal, there are people that just don't know how it works. For example, when the proposal has been announced on the Address Policy mailing list I forwarded the e‑mail to the local network operator group and what I had was mostly private responses, a few public responses, but actually two people only subscribed to the mailing list to say what they have to say. And, well, one of them was a no and the other one was, well, I have something to say but I don't really care.

SANDER STEFFANN: Thank you for actually getting people to subscribe to the mailing list. I think that's important.

RADU‑ADRIAN FEURDEAN: Unfortunately, it didn't work.

LOUIS STERCHI: But there are two.

RADU‑ADRIAN FEURDEAN: Like the policy... I tried...

ERIK BAIS: I have a question. Earlier in the, before the break, you said that you expect somewhere around five years or so ‑‑


ERIK BAIS: Or slightly less, currently is the runout. So, looking at it ‑‑

SANDER STEFFANN: Eric, those numbers have been confirmed by the NCC by the way.

ERIK BAIS: Just in this line of thinking. Shouldn't we change the policy into a /23 instead of running out sooner and quicker?

RADU‑ADRIAN FEURDEAN: No, or later or now for later?

ERIK BAIS: Because it's actually to be able to extend the time, you know, you're here advocating you know we need to add it to a /21, so perhaps you know, knowing ‑‑ giving that time, five years, my expectation is we'll need v4 for longer than that in order to be able to provide for new entrants, maybe we should actually say reduce it to a /23 instead of a /20, or a /21.

RADU‑ADRIAN FEURDEAN: Personally I would be favourable in progressive reduction, this is something that we should have done five or even ten years ago, start limiting it to a /16, then /19 ‑‑ whatever, this is past what we can do from now it still say you can get every two or even three years you can get an extra whatever is the allocation at that time, and still reduce the size of the allocation depending on what's left. So when we reach a slash, I don't know, a /10 are we reduce to a /23 and we are at a /12, it's only /24, eventually introducing extra conditions, I don't know. This is something that I'm willing to do, but the idea is just say just one for a very long time, while other people can still get... nobody is doing this outside of Europe. So... is it the right thing that we're doing.

ERIK BAIS: That does not mean that we're wrong. So.

RADU‑ADRIAN FEURDEAN: This is a subject to debate.

ERIK BAIS: So the question is: Are you planning for more space handing out to the current members? Or, are we actually planning for a longer runout? Because, if the plan is a longer runout, then we need to reduce it. If it's a quicker runout, then we basically you know empty the barrel. My personal preference would be a longer runout. And I think the majority of the community would be as well. But, you know, given the fact that your own estimation is five years, I think that is already very short.

RADU‑ADRIAN FEURDEAN: Well, at some point we will run out in one way or another. And we can't just ‑‑ well ten years, even if it's ten years from September 2012, it's way too long. We won't last because all the other RIRs probably except AfriNIC will be running out hard by that time. We can also see that there are US registries, US LIRs, so, companies from the US, they are opening a subsidiary or they're just signing up, and they are getting their space from Europe, because they can no longer do it from the US.

ERIK BAIS: But the fact that ‑‑

RADU‑ADRIAN FEURDEAN: So we are still wasting address space instead of giving it to members

GERT DÖRING: We are making good use it have by giving it to members, please.

SANDER STEFFANN: He can interpret it different ways that other regions are coming here might actually be a sign that we're doing something good. But ‑‑ we are different from the other regions. The other regions have different policies. But, I don't think we should make a judgement call whether that's good or bad at this time.


GERT DÖRING: We have been known to do something right at times.

RADU‑ADRIAN FEURDEAN: It happens, yeah.

AUDIENCE SPEAKER: On behalf of Elvis:

"As a response to Wilfried, the price tag the RIPE Chair talked about the is not the price for being an LIR or anything that can be decided at the AGM. It's the price of the IPs in the market place that is slowing down or killing the business of the small LIRs that joined after 2012 and only have one /22. While I agree that it is not a bad idea to hold onto the IP space for as long as possible, by doing so we are actually creating a situation where for many years to come the incentive no more IPv4 to move to IPv6 will be ignored by meanwhile thousands of new members will have to struggle with only one /22. That is why I initially believe that allowing a second /22 would help with the risk of depleting the last /8 pool faster. Those new members unfortunately do not voice their opinion on the mailing list but I'm sure that the board and NCC staff have met them numerous times at meetings and trainings in the region. We as a broker also see them oncoming to us and running away when they found out what is the price per IP for a small IPv4 block. That is when we recommend them to request an extra /22 on a sister or brother company or just open an second LIR on the same company even though that's like cheating.

GERT DÖRING: I'm not sure if I buy that argument to be honest. 10,000 LIRs complaining that they have not enough space versus 5,000 LIRs still complaining they have not not enough and 5,000 LIRs not getting anything. I'm not sure if I buy the argument that a second option is better.

SANDER STEFFANN: One thing that I am noticing, it's coming back that people still see us as having space, and see this as address space just to be used as normal. I am getting the feeling we should be more explicit that this really is just intended to make it possible for newcomers to at least talk to the v4 world without having to go to the market and buy stuff. That was the intending of the policy, and I sometimes seems like people don't know that, or don't realise that. Maybe we should be a bit more explicit in communicating that.

RADU‑ADRIAN FEURDEAN: What would be nice would be to have the graph that Marco presented, to have that one on the RIPE website, not the one that is currently being presented. It's ‑‑ there are some things that are more clear from that one

GERT DÖRING: I see Marco nodding, so I think point taken.
That definitely helps. It shows the one‑off effects and not just the pool.

I think all the arguments have been voiced. Looking at this from a process point of view, I think we have about as many people opposing this as people speaking in favour of it. So, this is not consensus, this is not rough consensus, so I am afraid this is not going to work. But still I think it was a very important discussion to have, even if I have been yelled at for having all these mails on the mailing list and so on. I think it is really important to have this discussion, to see the different perspectives by people sort of like being in the small ‑‑ and looking forward like five years, to look at the other people that have no boat yet at all. It's a complicated situation and I don't think we can actually make everybody happy right now. We can try to make everybody equally unhappy and we might not even succeed with that. Well, a good compromise makes everybody unhappy. Equally unhappy. Nobody gets what they want on the cost of the others.

Anyway, thanks a lot for bringing this. And we can continue on the mailing list, but I'm afraid at least this version is not ‑‑

RADU‑ADRIAN FEURDEAN: This version is clear it's a no‑go the way it is today. So... we will try to see if we can put up a new version which may probably address more concerns than the current one.

SANDER STEFFANN: This topic has come up also unofficially over the last years, and you and Elvis have been the first ones brave enough to actually write a proposal and stand here and defend it, so thank you very much for that

GERT DÖRING: Thank you.


Turning around I thank you for being here. This is the end of the Address Policy Working Group, unless somebody else speaks up with business.

RADU‑ADRIAN FEURDEAN: A few minutes. I was just thinking, now we have transfer policy for IPv4, IPv6, AS numbers, so we can transfer pretty much everything. Everybody can see that the mergers and acquisitions is something that is subject to some abuse. Can't we just say that the mergers and acquisitions, which is ‑‑ well, this is probably something that has to be put to the Board or the General Meeting, but can we imagine to us that they deal only with renaming ‑‑ changing the name of an LIR and everything else, transferring resources from an LIR to another consolidation which implies transferring resources from an LIR to another are are just subject to policy, they just handle what is the name of the LIR.

SANDER STEFFANN: I think this is something that needs to be taken to NCC Services as well.

GERT DÖRING: But it is actually something ‑‑ I see people that should think about it a bit. The classical merger and acquisition is because we didn't have all the transfer policies in place yet so we needed something for legitimate business cases. Now that we have the transfers, it's debatable whether we can just apply transfers everywhere, so even just for mergers, I'm not sure, something for you to think about.

Thank you.

Thank you everybody for being here, for providing feedback, enjoy your lunch. See you next time.