Archives

ADDRESS POLICY WORKING GROUP
13 MAY 2015 ‑‑ 9:00 A.M.


GERT DÖRING: Good morning, Working Group. I'm quite happy to still see so many faces after the lovely party yesterday, so, these are the people that are interested and I welcome you.

I have been told to speak up. Good morning Working Group...

I'm Gert Döring and today I actually wear my badge.

Welcome, co‑chair, Sander Steffann, and let's go.

First of all, the administrative matters. As usual, going through the agenda quickly so you know what's coming.

We are right in the administrative matters, then we have the Working Group Chair selection, reselection, re‑election, whatever process, we will try to make this quick, and not waste too much time on it. Policy update from Marco from the NCC. And feedback from NCC registration services from Andrea, that's the useful stuff to sort of like get everybody on the same level, what's been going on, what the NCC has observed and so on. Then we will go into discussion of the open policy proposals, we try to cover these two before the break, and then there is coffee break. After the break there's more policy proposals, and before that, we will actually have something non‑typical for Address Policy which is a presentation not directly related to Address Policy but more to well sort of get you thinking about the effect that what we do might have on big networks that are not actually ISPs, very large enterprises. And then we have open policy hour with two new not yet formal proposals from Eric and Elvis, and AOB.

So, agenda bashing. Anything missing? Is there anything you want to see on the agenda? Okay, I didn't expect anything else, but it's formal to ask it.

Minutes: The minutes from the last Address Policy session in London have been circulated on the mailing lists, no comments have been received, so, I assume everything it fine and I have to thank the NCC again for the very, very impressive minutes, so, very detailed and everything in there. I have actually read through the long long long document.

So, any feedback on that? No...

That ought of the way, I now hand the microphone to Sander to explain what's happening.

SANDER STEFFANN: So, the RIPE Working Group decided sometime ago that we needed a process for rotating chairs for reelecting chairs, and on the mailing list, we circulated a proposal for this. We got consensus on that so this is basically the first implementation of that proposal.

What's going to happen now is that Gert steps down as a Chair, and we are going to select a new Chair. We had one candidate who announced himself on the list, he is called Gert Doring, and the selection process is by consensus. So, since we only have one candidate, does anybody object to Gert stepping up as Chair again?

(Applause)

SANDER STEFFANN: Then I think we have a new Chair. This is mainly

GERT DÖRING: I accept.

SANDER STEFFANN: This is mainly to give the opportunity for other people to step in to replace us if people think we're here too long and we're not doing things right any more, so it is important to have this, to open the possibility for a new Chair, but with your consensus, we will continue as a team. Thank you

GERT DÖRING: So, basically, I would have said about the same thing, it looks a bit ridiculous stepping down, stepping up again, but it's an opportunity for us to actually reconsider whether we still want to go on or just do it out of habit, and give somebody from the community a chance to step in if you want to. But I'm happy to go on, I said that on the list, and I will.

So, off to Marco, current policy topics. Marco is the good soul at the NCC if you don't know him who helps us getting all the formalities correct so he is the man to talk to if you have anything with a policy proposal.

MARCO SCHMIDT: Thank you the good morning everyone, my name is Marco submitted from the /TPHAOEUBG I worked as a policy development officer and I would also like to welcome everyone despite yesterday's good beers and cocktails made it early this /TPHORPBG in this room and also to the remote participants and I would like to give you the usual update of the current policy topics.

First I would like to tell you quickly what has happened since the last RIPE meeting, what has changed in the last few months, policy proposal wise, then I would like to give you an overview what's actually going on in the over regions, I will divide it a bit by topics. Finally I would also like to give a bit of an update from the policy development office, to know what else I'm doing besides sending announcements to the mailing list, because I do something else as well.

First, let's have a look what has changed since RIPE 69 in London. Maybe, to the one that have been at the last RIPE meeting or followed the mailing list, there were quite a long list of proposals under discussion around six months ago, and luckily, many of them have completed the PDP in the meantime, and most of them has been accepted. We have in total nine proposals accepted since then, eight of them happened that we accepted in March, which is an all time high, and first one was the 2014‑04, which removed the requirement that you do not longer need to request an IPv6 allocation when you want to get, when would you like to get a /22 pour allocation from the last /8.

Then we had proposals for long angle clarification where it was discovered that the term "Should" can be ambiguous and it's better to replace it with the term "Must" and this also was accepted that in four policy documents, this term was replaced, it was the IPv4 policy, it was the policy for contractual requirements for end user assignments, it was the policy for IPv6 for route servers, and the policy how to assign and allocate resources to the RIPE NCC.

Another proposal accepted in March was 2014‑06, the publication of the sponsoring LIR for legacy resources, this was the only proposal not discussed in this Working Group, it was discussed in the NCC Services Working Group, and basically it brought legacy resources in line with independent resource where if somebody decides to have a contractual relation with the RIPE NCC, via a sponsoring LIR, the database object shows Anna tribute sponsored org and this also police for regularly resource that is shows that way, so only the one that legacy resource holders that try to have, would have to have a sponsoring LIR will get the database object update that the this organisation, this LIR is mentioned.

And then we had some transfer proposals accepted to allow IPv6 and transfers and AS number transfers, and then in April finally, also the inter‑RIR transfer policy was accepted.

Of these long list of proposals, the proposals of the first three bullet points, they are already implemented. And the last three, so all the transfer proposals, the RIPE NCC is still in the process of implementation, because that sometimes a bit confusing for people that say oh it was accepted, the policy has changed, why the RIPE NCC is not immediately following the policy, but we need time to adjust our procedures, to adjust our software, to adjust our tools and we try to do it as fast as possible, and we also try to indicate how long it takes, so, on our website, we have now one page that mentions the policy implementation status and there you can get an indication when a proposal that is accepted but not yet implemented will be implemented, and to mention the free transfer proposals, we expect that in around July, we have IPv6 transfers possible and AS number transfer problems and if all goes fine and all goes, we will have the inter‑RIR transfer policy also implemented. That's still a lot of things needs to be done especially for the inter‑RIR, because it needs also coordination with the other RIRs, but current planning is August.

We also had, in the /HR*S few months, one proposal that was withdrawn. It was one of the language clarification proposals, where actually the commentator said no it is good that the terms stays for IPv6 for IXPs to leave some flexibility, to leave it that it's not a mandatory requirement that you only can use it for your, are Internet exchange point when you request IPv6.

Then we have four proposals in the RIPE now under discussion, I will not go into any detail of them because they all will be discussed in this session and in the second one. Just maybe to mention, these two are under discussion phase, 2015‑02 will end its discussion phase today, so if you haven't spoken up yet, today is your last chance, or else you wait till it moves probably to the review phase and then you can speak up again.

And in the review phase, we have already two proposals, 2014‑03 is the last proposal from 2014 that is still ongoing that has not finished the PDP yet; it's about removing the multihoming requirements for AS numbers. And the 2015‑01 the alignment of transfer requirements, it's also in review phase, maybe you'll find the time it started just on Monday with the Impact Analysis, so it's quite fresh in this phase.


That's so far about our region and now I would like to tell you a little bit about what happens in the other RIR regions. And I divide this a bit by topic, and first one is IPv4 depletion. There was in AFNIC, is a proposal still under discussion. This one plans to reserve a pool for Internet exchange points once in AfriNIC IPv4 would be depleted so that's a bit like we have it in our region, we also have a /16 reserved for Internet Exchange points. And in ARIN, a proposal has been withdrawn that was recalled remove needs attestation for some IPv4 transfers where the proposers thought you in the light of upcoming IPv4 depletion, why have so many requirements for transfers of small blocks up to a /20, but end of April it has been withdrawn because the Advisory Council in ARIN thought there was not much support or feedback on this proposal during the last ARIN meeting.

Another important topic of course is Internet resource transfers, and right now this is discussed mainly in the LACNIC region. There is one proposal that says it shall trigger section 2.3.2.18. What does the section says? It says that transfers inside the LACNIC region, so intraRIR transfers will be possible once LACNIC is not able to provide any more IPv4 address space to its members. And right now, LACNIC has reached a threshold of less than a /10 and their policy kicked in that members can get maximum /22 every six months as long as ‑‑ this will go on until they have a /11 left. The proposal says that's not enough, like in the past, you can get some IPv4, LACNIC's understanding is that we also have still able to provide IPv4 but the proposal says no, let's trigger it now because this little chunk is not help to some organisations.

Another proposal, also now in LACNIC there is an inter‑RIR transfer proposal under discussion ‑‑ by the way both proposals will be discussed next week in the LACNIC meeting inially may Peru and also there will be decided if there is consensus or if it has to be further discussed or logical be withdrawn. Of course opposite to the RIPE NCC region, to the RIPE community, where these discussions here in the room are for more information, but the actual discussion takes place on the mailing list. In LACNIC it's a bit the other way around, so if you would like to participate in that process, next week is your chance.

IPv6 deployment, quite some proposals, interestingly also quite some proposals that got withdrawn. In LACNIC there has been a proposal to create a pool, IPv4 pool that is reserved for IPv6 deployment, so somebody who wants to deploy IPv6 can get some IPv4 for it for transition mechanisms to have this connection, but it did not reach consensus. In ARIN, also the proposal got withdrawn that called remove of minimum in text 4.10, because ARIN actually has such a pool reserved for IPv6 deployment and there organisations can get between a /28 and a /24 for IPv6 deployment, IPv4, and the proposer said well, everything less than a /24 is not routable so it doesn't make sense so let's just make a /24, but the Advisory Council said, no, let's not do this, let's first make ARIN promote this pool is there and then let's see how it's going.

In AfriNIC, a proposal related to v6 deployment that is been accepted so there it's now possible that if you are an Anycast provider that you get dedicated IPv6 space for your Anycast services.

In APNIC, a proposal called "On demand expansion of IPv6 address allocation size in legacy IPv6 space" has been also withdrawn. Sounds a bit complicated but to give the background: In our region, it is possible to get up to a /29 IPv6 without any further justification. And there was a previous proposal, proposal 111 that tried to do the same in the APNIC region. However, it turned out the way how APNIC allocates IPv6, the use space allocation since 2006 around, they cannot guarantee that allocations can be handed out have already free bits reserved so that's why the previous proposal was withdrawn, and this proposal tried to at least allow the extension for all the IPv6 that were handed out before 2006, where it would be possible. But there was no consensus, people said no, let's everything back more than a /22 must be justified other people said if it should be extended let's do it by a bit boundary, /28, /24, so in the end in did not reach consensus during the last APNIC meeting.

And in ARIN also, IPv6 related proposal is modification to criteria for IPv6 initial end user assignments. So end user assignment, it's something like in our region they provide independent assignments, and ARIN has right now quite some requirements, specific requirements that you can justify for such assignment, PI assignment. You need to show that you will use 2000 IPv6 addresses or you will do at least 5 funded /64 sub‑netting assignments within 12 months and the proposal says they are business cases and organisation that is would need IPv6 PI but they would fail on those requirements so let's change them, let's modify them.

Then another topic is also discussed in two regions right now, or were discussed, it's out of region use. So to have a definition, if address space is provided by one RIR, how much can be used outside of this service region.

ARIN had one that was recently withdrawn, but the reason was that AC thought during the discussion this proposal had morphed a way quite a lot from the initial intention that the proposer had, but it was already the plan announced that the a new proposal will come soon in the ARIN region to define the out of reach use and take all the concerns, comments that were stated so far, into account.

And AfriNIC also has such a proposal ongoing since quite a while. It was discussed during the last AfriNIC meeting. The idea there is this proposal that only 40% of resources provided by AfriNIC could be used outside AfriNIC region, but the there are quite two parties or two big opinions in the region, some say yes that's good, it must be, others say no, it is not good, so that's why it's still under discussion.

And last topic that I want to be mention is about AS numbers, because we in our region have 2014‑03 ongoing since quite a while and also in the LACNIC region, such a proposal was discussed to modify the requirements to receive AS numbers and it has been accepted and in LACNIC right now, the requirement is that you need to interconnect with another network and then you justify for an AS number.

APNIC tried to do something quite similar, it's still under discussion, the initial version also had just that you need to be interconnecting, but based on a feedback during the last APNIC meeting it was currently modified that you rather still must be multi‑homed or that you have to intend to be multi‑homed which is already the intention ‑‑ that this would be enough. This is the change.

And last section of my presentation is a short update, what are my activities, what I'm doing also in my work, and it's mainly around to race the awareness about the PDP, about the importance. Also, that it's not rocket science, and also increase the participation. And one thing that I'm doing since a couple of months that I sent out some monthly newsletter to different mailing lists, to the RIPE list in English, to the ENOG mailing list for eastern Europe in Russian and MENOG Middle East in Arabic and the idea behind is it to reach out further than to the people that are subscribed to Address Policy mailing list, because there might be engineers, Internet citizens that have an opinion that might be impacted by a proposal but might not know about it, and it was very well received, the feedback that I got is always positive.

I'm also being part of the training team that the RIPE NCC has, so I'm joining training courses, I also use this opportunity to talk to new members about the PDP and how to be part of it. And whatever additional to facilitate the participation on the PDP, I try to do. If somebody wants to make a proposal but don't know all the formalities or the rules, I guide this person through. I also try to reach out to regions where there's not much participation, and related to that I would like to show you a little map, that's the participation on the Address Policy mailing list over 2014, and the colour, the stronger are the colours are more postings came from those different countries, and what I did, I went through the whole e‑mail list of 2014, and when there was a country domain, it was easy, I knew from which country that person came. If it was a domain like .org/.net, I tried to find in other public resources like the web database where that person is located, and in case you spot something that is not correct there, so let's say for example you are in Belgium and you knew that you said something last year on the mailing list, just let me know and I'm happy to adjust my parameters. And you can see actually, the participation is nicely spread, maybe with a bit more coming from central and western Europe, and especially let's say in the Middle East, central Asia and also the Balkan area, people I tried to reach out there and make people aware that you are missing an opportunity to participate, you are missing ‑‑ because your network requirements, your network environment might be different than in central Europe, so please speak up, but over all, it's, I think it's doing quite nice. It's an interactive map so if you go on this link below you click on each country you see how many participants were there and postings were there and I try to update this now on a yearly basis.

That's my last slide. I would like to just give some useful links. This is the link where you can always see what proposals are currently under discussion. And if you want to know more about the PDP, about if you want to make a proposal, if you want to understand something better, you can catch me during the whole RIPE meeting or, yeah, send me an e‑mail, and if you like this presentation, if you like the content, I welcome you to follow me on Twitter because there are also keep you updated what's going on, what are the phases, the development of proposals in our region and also what's going on globally.

And that's the end of my presentation. I'm happy to take any questions...

GERT DÖRING: I see all questions are answered. So thanks for the presentation, and thanks for all the help in the last year of course, because policy making without somebody who keeps track of all the nitty gritty details wouldn't work out. Thanks.

(Applause)

If we have a policy that has rough edges, and makes their life hard, they bring it back, so we can do something about or decide yes this was intentional, sorry, but it's the way it is.

ANDREA CIMA: Thank you Gert. Good morning everyone, I am part the registration services team at the RIPE NCC.

Now, what is the goal of this update? Like, Gert just mentioned the goal of this update is to report back to you, to the community about the feedback that we receive from LIRs in our day to day business, and how lighting when we see that there may be a potential problem with an existing policy.

Furthermore, we ask you for guidance on how to interpret certain policies and we want to provide input to you for further discussion on policy proposals.

Now, I have two points on my agenda for today. First of all I want to give you an update about what we brought up during the last RIPE meeting, meaning the multiple /22s going to a single LIR, and we want to discuss about large IPv6 allocation requests.

Starting with the multiple /22 to single LIRs. According to the IPv4 allocation an assignment policy, the sum of all the allocations made to a single LIR by the RIPE NCC must be a maximum of a /22. This is in place since the exhaustion of the regular pool in September 2012.

Now, when this policy proposal was made, the RIPE NCC wrote down in the Impact Analysis that even though this would have been the text of the policy, policies right‑hand procedures would still allow organisations to open multiple LIRs, hence the request multiple /22s, one for each LIR. This was acknowledged by the authors that this was very hard to ensure complete compliance but the RIPE NCC was asked to be vigilent and to report back to the community if we were to see a trend in this direction.

So, during the last RIPE meeting, RIPE 69, rebrought this up to you, we brought up that they were seeing a new trend, meaning LIRs organisations opening multiple LIRs, receiving a /22, transferring this to another LIR and then closing the first LIR very quickly. This is technically possible, according to policies and procedures, but against the spirit of the policy.

We had about 70 confirmed cases at the time but we could see that this was a growing trend. Now, where do we stand today with this?

If we look at this table, we can see the number of LIRs that have one or more /22s, are acquired due to mergers or transfers. We see at the bottom of the table that there are many LIRs, the vast majority about five and a half thousand who have one /22, we about 160 LIRs who have two /22s, about 40 LIRs who hold three /22s and if we go to the top of the table, we see that there is an LIR that has for example 25 /22s, an LIR that has 13 and one that has 11.

Now, what does the trend look like? We reported on this during the last meeting that we saw an increase, the trend was growing, and I believe that these numbers confirm what we mentioned during the last meeting. We see a growing trend still of transfers according to the transfer policy, meaning LIR‑A receives a /22, decides to transfer it to LIR‑B. LIR‑B cannot retransfer the space for 24 months. Pure policy transfers. It's quite interesting to see that we have a big this month growing trend and also at the end of 2014, in December, and we believe this might have the case in order to avoid having a membership and paying the membership fee for the year after, 2015.

Now, if we look at how fast those /22s are being transferred. We can see that when LIR‑A receives a /22, it's usually transferred to LIR‑B within the first two months from receiving it. So, very quickly.

Now, this is as I just mentioned with regards to policy transfers, but there are also mergers and acquisitions which do not have to follow RIPE policies. What is the trend there? We see that resources from the last /8 have also been transferred due to mergers and acquisitions. Again a peak at the end of 2014 meaning closing the membership by the end of the year and we see that this trend is also growing even though not as fast.

Now, mergers and acquisitions are part of the business lifecycle, every company may get bought or sold, and so, is this just due to normal business cycle? It does not appear so. When we look how quickly these LIRs from receiving the /22 are being merged into another LIR. What we see is that most of the LIRs receive a /22 from the RIPE NCC and within two months they are being acquired or merged into another LIR. So, this trend is quite similar, the timeline is quite similar to the policy transfers.

So, this with regards to the /22s, the next topic I wanted to bring up is the large allocation requests for IPv6. As you can see from the IPv6 allocation, an assignment policy text, an LIR can contact us, ask for an IPv6 allocation of any size between a /32 and a /29 no questions asked, you receive your block. If you would like a block which is larger than a /29, you should submit documentation that justifies the request, and the allocation size that you will be receiving will be based on the number of existing users and the extent of the current organisation's infrastructure. So, it will be based on your current situation without allowing to you plan in advance.

Now, we see at the RIPE NCC an increase in larger IPv6 allocation requests over time. We believe that while we are gaining experience in evaluating this request, the LIRs are getting experience in IPv6, we see some good documented what we believe to be serious plans with regards to IPv6 deployment. The problem is that not always we can approve those requests because as I said if you want more than a /29 it must be based on your current status.

We could not approve about 20 of those large requests over the past year, and ten of those organisations at the end accepted a smaller block than what they initially wanted and about ten of those requests are still ongoing with these organisations trying to somehow justify the amount that they were requesting.

Now, the problem is that the IPv6 altercation policy does not consider, at the moment, extra address space for growth and most of the plans we have seen, organisations were planning for ten years ahead when deploying their IPv6 network, we even had one organisation planning ahead for 20 years, other for five years but mostly for ten years. And the policy does not consider extra space for multi‑level hierarchy address concept. Now, what do I mean by this? I have just one example here.

We have received many examples, this is just to show this to you. We have a multinational organisation in our region which may be present in many countries in the RIPE region, they would like a block for each country, and they would like to reserve some address space for each country for eventual growth. Also, they would like to reserve some space for countries in which they know they will enter in one or two years from now. Now, those reservations are currently not possible and then for the more even in every country they would like to assign allocate some address space to a certain region and they would like to reserve some space for that region to enable further growth and have a contiguous block and so on. City and it can go further a few levels down.

The point here is that once they reach the HD ratio they could request an additional allocation and receive an extra bit, and issue space from there. The problem is that for internal allegation, they ‑‑ this would not allow to ‑‑ this extra bit would not allow for aggregation on a country region or city level. And one last point I want to adhere, is that if those organisations would request a /29 for each country or each region or even each city, they could get so. But they would like to have one aggregated block, but we have to evaluate this as one request, hence the issue.

I think this was it for me. I do not know if you have any questions...

GERT DÖRING: Andrea, thanks for bringing them. As a matter of process, I would like to have questions, clarifications now, and the actual discussion when we discuss the policy proposals as we already have two proposals on the table to tackle these two issues. So...

AUDIENCE SPEAKER: Morning. Erik Bais. Andrea, I have a question about the cases about the abuse of the /22s. What I saw was there is a specific person, and it's actually the LIRs are actually in the name of a person, is requesting multiple LIRs, requesting multiple /22s, then merging them together all through an LIR which is also in his name and then transferring the /22s, /21s, 20s, that he received from consolidating all those /22s, is that correct?

ANDREA CIMA: We have seen many different cases. There are cases where we know that there is the same holder behind but it's company 1, company 2, company 3, company 4, and then the organisations are merged for example. So, there are different situations. So also the case that you mention, yeah.

ERIK BAIS: So, also the case that I mention. From your perspective, and I'm not sure if you can actually comment on it but I'll ask anyway: Is it considered not in line what the intention of the actual policy which is currently already in place? And what is the view of the RIPE NCC on how it should act basically looking at did RIPE actually try to stop this behaviour?

ANDREA CIMA: What I can say is that at the time that the policy proposal for the last /8 was made, in the Impact Analysis, we informed the community about this potential issue and we were asked as a secretariat to keep an eye on it and to report back if this was happening and that is what we did during the last RIPE meeting. And all because this was not considered also in the policy proposal to be in the spirit of the last /8 policy. And this was really clear in the policy proposal and that's why we reported this back to the community. So, it's up to you, as a community, to decide do we want to do something about this? Do we find this fair and just or not? We brought it up because it does not seem to be in line with the spirit of the policy, and the policy proposal was really clear about that.

AUDIENCE SPEAKER: Andrew Dell a, RIPE NCC, one additional comment, On Erik's question actually. We did contact this person in case, and we explained to him that it was not in the intent of the policy actually what he was doing. Nevertheless, it's continuing.

AUDIENCE SPEAKER: Morning, at that Shaw, consultant for german Government. I have a question concerning the IPv6 issue of the rejected address requests. Are all rejected requests are initial allocations? And do you have similar problems with subsequent allocations?

ANDREA CIMA: The cases I brought up were all linked, the once that I brought up were linked to first allocations, and because the subsequent allocation policy is quite clear with regards to the HD ratio, so these cases were mostly about first allocations.

GERT DÖRING: Do you actually see subsequent allocation requests in significant numbers?

ANDREA CIMA: I think that formally we have maybe received one additional allocation request for IPv6 ever. There have been other cases in which of course we have discussed with certain organisations what they would have to do in order to justify for an additional allocation, so there has been information exchanges but a formal request for additional allocation, maybe once I think.

GERT DÖRING: I think the policy is actually working because the intention was to have them not come back.

AUDIENCE SPEAKER: Hello, I have one more question about this opening LIR for a /22, can you give us a rough number of percentage how many new LIRs are only made for this intention? Is it 10% of all new LIRs, 20 or even more?

ANDREA CIMA: The number of transfers of /22s, let's say it's about 10%, I think you are actually right. We published an article on our RIPE Labs in our Impact Analysis for the policy proposal that was made with regards to this, we brought up the number being 9 or 10% about, and that is only for policy transfers and does not include the mergers and acquisitions.

AUDIENCE SPEAKER: Much too much.

AUDIENCE SPEAKER: Hi, Elvis Velea, and the author for policy proposal 2015‑01. We have already ‑‑ I have already said on the mailing list that the first step in trying to close the gaps is to come up with the 2015‑01 policy proposal that will basically restrict any new allocations made by the RIPE NCC. It the not restrict them. It will bring them in line with every allocation that has ever been made or reallocated, transferred, whatever, so it will add the two years not transfer block, let's say. And we have already ‑‑ I have already mentioned there on the mailing list that this does not affect mergers and acquisitions. This does not affect the possibility of opening multiple LIRs. Do you see any solution to actually close that gap as well? I mean, I'm thinking would it be possible for the RIPE NCC to reject registration of two LIRs by the same company? Because if that's not possible, because we already have hundreds of organisations that have one or more LIRs, then there's not actually much that we can do. We could request the NCC to come up with some procedural arbitrary number saying you can open two or five or ten or 1,000, but not more, or we could say you are not allowed to open a second LIR on the same company name, therefore actually asking all the current organisations that have more than one LIR to merge together, but do you see any solution, any possible solution for prohibiting companies to open multiple LIRs and get multiple /22s.

ANDREA CIMA: I think there are a lot of smart people in this room that could come up with some ideas. With regards to your last point about providing the same company to open multiple LIRs. What we have seen in the past, was there there were some very legitimate businesses, large organisations that have different divisions, different departments or in different countries and they had for administrative reasons, separate LIRs, and those have always been very legitimate cases. So, you would impact those as well. So, yeah, but just to let, you know, that's one point to take into consideration there.

GERT DÖRING: And actually opening new shelf companies to have, depending on what country you are in. We might take this to the AGM because this is not so much an Address Policy matter but a membership matter but I do hear you, and I'm sure the NCC is hearing you as well.



AUDIENCE SPEAKER: Regarding the merger and acquisitions, transfers by mergers and acquisitions, is it possible to have a little more transparency because a lot of things stand for mergers and acquisitions are just slipping under the radar of the community. You have the information but we don't. For example, one case that was presented with regard to multiple /22s, we couldn't find it on the list you are publishing because the list you are publishing with approved transfers only concerned transfers between different LIRs not mergers and acquisitions.

ANDREA CIMA: Yes, you are correct. The transfer page only shows statistics for transfers according to transfer policy, because it was part of the transfer policy itself that the RIPE NCC was asked by the community to publish all the transfers made according to this, and there was no such policy for mergers and acquisitions, but indeed that could be an idea if the community wants more transparency on statistics for mergers and acquisitions.

GERT DÖRING: Would you need a formal policy proposal asking you or would it be sufficient if this room says yes please do so?

ANDREA CIMA: I'm looking at my colleagues over there... yeah, we will ‑‑

AUDIENCE SPEAKER: And one other thing is...

SPEAKER: We have to discuss this internally and come back on that one.

AUDIENCE SPEAKER: One other thing would be could we just envision of introducing the term of organisation instead of LIR, define the term organisation to whatever it means in order to make things clear? Now you can have multiple layers in one organisation, there are policies who is spirits think about LIR equals organisation or company. So, it may be one idea to start speaking about organisation, not LIR. Or depending which one we want to do

GERT DÖRING: The thing is that very LIR is very precisely and easily defined term. An LIR is one entity that has a contract with the NCC, is paying a yearly membership fee, so we know what an LIR is, we don't know what an organisation might be. An organisation might be an multinational with tens of thousands of sub ‑‑ not tens of thousands ‑‑ hundreds of suborganisations in it, so an organisation is very poorly defined term. LIR is very price, one membership, one 22, and so on.

AUDIENCE SPEAKER: We can try to define

GERT DÖRING: We can, of course. So if you have something specific in mind, I think to be able to discuss that point, we would need to see text. Like change this text to "organisation," and "define organisation as follows"... and work on that. But I think it's hard to discuss this out of the blue without a specific proposal.

I think that's it. Thank you very much.

(Applause)

GERT DÖRING: So, we now enter discussion of the open policy proposals. Just a reminder, all of you know this anyway, formally no decisions are ever made in this room, or any RIPE meeting. Discussions are made on the mailing list, so, it's open and transparent and archived publicly. What we do here is very useful to get a quick feedback to see which direction a proposal should be moving, but the final decision is on the mailing list. If you speak up, please state your name, if it's relevant, the affiliation, if not, not. Because that helps the scribes that helps remote participants. The session is webcast, but you already know that. And if you are listening to us remotely, feedback can be provided by chat, IRC and Jabber. Max is monitoring the Jabber, so he will relay your questions.

So, 2014‑03. "Remove multihoming requirement forecast number assignments." That is a complicated one. Basically the policy proposal initially was totally simple. We have the AS number policy that says you have to be multihomed to receive an AS number. Now, what is multihomed? Multihomed is not that easily defined, and how can the NCC check you're multihomed if you have one upstream and one local peering. But the NCC night not be able to see the local peering. So people can just claim anything, get an AS number, we don't encourage lying to the NCC. And it got in the way of legitimate deployments. So the proposer came up with a lightweight proposal that said yeah, get rid of the multihoming requirements at least for 32 AS bit numbers. Then there was the concern was that some certain Irish person could just go and request AS numbers that the NCC has run it dry. So, limitless abuse. We used to have a 50 euro per AS charge in the membership fee, which sort of like a natural boundary for abuse, because if you request 4 billion AS numbers, well, with the money, we don't need to run the Internet any more, we can just all retire. But the NCC ‑‑ the board, or the AGM, actually took that charge away, so AS numbers are free right now.

So the proposers went back and said okay we'll put in a new mechanism to sort of like slow down abuse, a single organisation can only have 1,000 AS numbers, and if you want more you get to open another organisation, based on the current maximum of ASs in a single organisation, so that that is plenty. But then people again didn't like it. And there is an item on the AGM agenda today to actually decide on bringing back the AS number charge. So, at the formal end of the review phase for this proposal, the chairs decided that we will just extend the review phase until end of this week so after the AGM, and then sit down with the proposers to decide how to proceed based on the decision of the AGM. So, actually I propose not to discuss this today as the way forward depends on the decision of other people, and we don't have that decision yet.

I'm happy to answer questions, but the actual discussion on the merits of this proposal is not really helpful. So, questions welcome.

ERIK BAIS: So, we actually have the possibility that after this week we'll come to a point where we're not going to charge for AS numbers, we're stuck with a proposal which is basically you know have something in there where not everybody is happy with, like the arbitrary limitations of number of ASs per organisation. So basically we're going back to version 1 of the proposal which basically didn't have those limitations or, what was...

GERT DÖRING: I'm not telling you what I'm going to do at the end of the week because it depends on what the AGM does, and depending on the outcome of the AGM I think I will go through the mailing list archive again, look at people's comments and then try to see whether we ‑‑ sort of like go forward with the text we have or have a new version of the text and re‑enter for review period. I can't say yet because it really depends on what the outcome of the AGM is.

Basically, the mechanism here is an anti‑abuse mechanism or sort of like a garbage collection mechanism, if we have it elsewhere we don't need it here, but if we don't have it elsewhere, the community asked us to have something in here. So, we will have to see what happens.

ERIK BAIS: So, the possible abuse, although I will not say which person actually would like to have that...

GERT DÖRING: I do understand.

ERIK BAIS: But the, let's say... because it was an arbitrary thing that was put on the mailing list, well, let's say, like say I would do this, currently AS numbers do not have such ‑‑ not a charge. It is possible to request a lot of AS numbers even with multihoming requirement in there, so, you know, the actual need for having this kind of additional limitations in the policy looks a bit silly to me, and if it actually comes to point, you know, we'll face it similar as what we're doing with the /22s currently is something I would assume. But...

GERT DÖRING: I think it's useful to have some sort of anti stockpiling mechanism. I would prefer to have some sort of ‑‑ it's inconvenient to keep an AS you don't need any more mechanism so people return it because it's just inconvenient to have to pay €10 a year, whatever, something that requires manual business process. But, this particular decision isn't on us, so ‑‑ and we will take what we see, and bring it back to the list of course.

ERIK BAIS: Okay. So, if the goal here is garbage collection isn't there a process that we can actually come up with that instead of doing this kind of stuff, actually require Simms with 2007‑01 say well, you need to actively reach out in order to keep your AS number or something like that.

SANDER STEFFANN: 2007‑01 actually does cover AS numbers, only the NCC and the AGM decided to set the fee at zero at some point. There's some...

ERIK BAIS: What I'm trying to get at. If garbage collection is what you're after, or you know, somebody in the room is after, is there something that we can do in a process way of basically saying you know, you need to actively reach out to the NCC in order to keep using your AS numbers, similar as what we're doing with RPKI and a certificate, it actually has an end point.

GERT DÖRING: Well, we thought 2007‑01 actually intended to do that but it wasn't exactly clear about it, so, there is no formal mandate for the NCC to install a garbage collection mechanism. Yeah, oversight. Or at least that's the way ‑‑ Nick, don't start arguing ‑‑ it's interpreted that way, it's not very explicit, the intention was ‑‑ we thought the intention was clear that it was supposed to be a garbage collection mechanism but it was never written down, let's phrase it that way. We could actually transform this one into something that says the NCC is tasked to installing a garbage collection mechanism, whatever mechanism they come up with, either by charge or by phoning the AS holder once a year and requiring them to fill out a form. Whatever. I think this depends on what the AGM decides.

So going to specific mechanisms right now, we have been thinking about it and I think we will find something that we can work with, let's phrase it that way. I think Hans Petter was first and then Elvis, then Nick.

HANS PETTER: Hans Petter speaking as long time Address Policy working with Visma, I think it's very important here to try to look at the goal, what we want to do, and when we started to look at this proposal I was very much in favour of taking away unnecessary bureaucracy, I'm all for that as a principle. This room needs to be clear that the fee structure for the RIPE NCC is not set in this room. But I think that it is a mistake if any policy mentions anything about payment that's outside the scope of this policy. If we have any policies that does that, those should be changed, that's a matter of principle I think. Yes, garbage collection and claiming back resources is important but then we need to look at what are the good ways of doing this, like, is this resource in use? Is there a technical way which is neutral and sensible that be used for that? I don't know. I have lost track of all the works in these discussions so maybe it's time to go back to the drawing board and see how this is. I mean why do we need v4 addresses or AS numbers out there if they are not used on the global Internet? Well yes there may be reasons for that, but maybe we need to go back to the drawing board and think about that because if we want to keep this working for as long as possible, well v4 may not be a point we can move to IPv6, but AS numbers we need to have even nor v6, so how do we make sure that that resource it done in a fair way? If there is anyway to do that technical, neutral criteria to hand out and get back, I think that would be the best for RIPE NCC and not any (any way) justification based on some documentation or some wishy‑washy criteria, let's make simple proposals which are concrete, I think that would be my preference

GERT DÖRING: And unfortunately, I think we discovered that actually checking from the outside how an AS number is used, is about as possible from checking from the outside how an IP address is used. There might be good reasons to actually need a global unique number which is not visible to the world, or at least not visible in a multihoming role, so, that's what got this rolling, the multihoming requirement.

SANDER STEFFANN: I do agree with your remark, when we did 2007‑01, like Gert said, we intended it to be a garbage collection mechanism. We weren't very explicit in it; we were trying force the NCC to implement this through the charging scheme. And I think we were going too much into the implementation details by forcing the NCC to charge for it basically to be used as a garbage collection mechanism. So I fully agree with you that this is something we need to keep in mind when making new policies.

GERT DÖRING: Elvis next, be short you are taking away your own time.

AUDIENCE SPEAKER: Elvis Versa. I wanted to say almost, some of the things that Hans said, one of them is that when I first looked at it, looked at the proposal, I was not very sure whether would like to support it or not. After the discussions on the mailing list and at the RIPE meetings, I thought okay that's actually a very good idea, so, I'm supporting it. There are multiple ways of doing garbage collections. I don't agree with actually leaving it to the AGM because the AGM can change their mind next year again, or whatever. I think we should actually do the garbage collection in the policy. I think there is ‑‑ there are many ways that the NCC can do garbage collection and we should look at all the options there, maybe ask the NCC which options they think would be feasible, so we don't actually put something in the NCC as hands they can't do anything with, and then decide on one of them and then put in a policy and then get on with it. Because this is a good policy proposal. It's aiming to reduce the lies that are given to the NCC for requesting an I AS number, either the planned multihomed with two AS numbers or the reasons why someone with need a second or a third or 1,000 one. So, I really think this is a good one. However, we need to find a matter to do garbage collection and I actually have one in mind, which is just a second, I think that the NCC has done two things in the past, which were maybe not very approved by the community, one of them was the multihoming check that pissed a few people off. Maybe they could do that in a different way, not necessarily multihoming because we were removing multihoming, but do a ping or a check whether an AS number is still in use in one way or another, e‑mail LIR portal, requesting the sponsoring LIR to confirm every year that the AS number is still needed, requesting the end user every year to confirm that it's still needed and only when those guys don't confirm...

GERT DÖRING: I'm actually hearing you and bouncing the ball to Andrea and Marco. If you could spend some brain cycles on whether you think it's feasible if we just put moot policy proposal a sentence like "We task the NCC with regularly checking that the AS number is still in use, and it will be encouraged to be returned like sort of a soft reclaiming, not a hard thing, because that usually leads to a hard feeling. Like we task you to make sure it's still in good use and then sort of like bring it back on the mailing list to see whether this is something you could work with or this is basically not feasible for you.

ANDREA CIMA: Yes, this is an operational, I would be considered as an operational detail, we could take care of that.

Just one thing, if I look back at the text on the screen, I will say that someone should then be encouraged in that direction, it would be preferable to have something a bit more specific in the sense if it is not in use, what we should do. Should we ask them to hand it back? But with regards on how to do that, I believe that we can spend sometime looking into it and ‑‑

GERT DÖRING: I think I see us go back to the drawing board with us and come up with new text based on your input then.

SANDER STEFFANN: We're trying to find the balance between just saying like oh NCC solve this and then got /TPHEUFG you any guidelines, and (giving) but avoid trying to be too specific and forcing you in a certain direction.

ANDREA CIMA: Thank you.

GERT DÖRING: Nick, Brian and then the next one.

AUDIENCE SPEAKER: Nick Hilliard, I'm going to try to be brief. The reason that we're having a discussion about this is not because we like charging for resources or anything. It's because we have imminent depletion of a finite resource, and we have two types of ASN numbers, ASN 16 and ASN 32s and we have a problem with ASN 32s, we have got an almost unlimited supply of them. So if we can fix the the route cause of the problem that we're having here, which is the technical limitations of ASN 32s, this entire discussion would not be an issue, and unfortunately, we have to depend on a third party, the IETF for this. I brought this up, suggested that we do something which, of course, means me do something more, and that thing didn't happen which is to say to talk to the IETF about fixing the technical problems with ASN 32s. But essentially, from a global picture, we have a perceived need at the moment to create a slow down policy for assignment of ASN 16s, and this is the reason for the contention that we're having here. I'm not going to make any prescription about how people should treat the vote in the AGM later on, I think people should read the proposals and make their own decisions about that, and I think everybody is confident that the AGM will come up with the right decision for the RIPE NCC.

But, the route cause of the issue here is an IETF problem and I think we need to talk to the IETF seriously about this and get them to fix the route cause of the problem so that we don't have to worry about this at this forum

GERT DÖRING: I do want to point out that this is actually only loosening up 32‑bit AS numbers right now. The homing requirement for 16‑bit AS numbers is not touched. And some person brought up on the mailing list the claim that you could just register 4 billion of ASs numbers which would be 32‑bit numbers, so you brought in the desire to have a slow down for 32‑bit numbers. So make up your mind whether you want slow down for 16‑bit or 32‑bit numbers.

NICK HILLIARD: The current policy that we are which is based on the predication that we have an imminent resource depletion for one type of ASN combined with a sort of a requirement for making things easier to get other types of ASNs is, it just doesn't really work as a proposal. The RIPE NCC requirement to record a justification but not to evaluate it, it doesn't really work, but I think we have a root, we need to look at the root causes of what we're doing here and try a make a sensible decision which is going to last us another 25 years. The existing policy has brought us 25 years years so far, if we're going to make a new policy, we should make something that is going to last another 25 years and not put in crazy limitations about this slash or the other, 16 pit ASNs are going to be gone I don't know in a couple of years.

AUDIENCE SPEAKER: Brian Nisbet, HEAnet. Just one, I suppose almost signing a note of caution with talking about putting in the policy and we want the NCC to go and check every year that multihoming is still happening or whatever words are put in there. That's ‑‑ it starts to wedge open a door, it may be a good door, it may not be, but there's things like a PC for instance, which is they will going, well, the NCC are checking with homing and ASN usage, why don't we just add something on to that about verification of say Abuse‑C or things like that.

So I'm not saying don't do it or otherwise, but just be aware that if that mechanism starts going into place and the registration team are beginning to do that then other people may add more things on top of that.

GERT DÖRING: Thanks for that. Erik, last word.

ERIK BAIS: Before Brian actually walks away, the RIPE NCC is actually doing audits and there might be an additional question to be asked during an audit, basically what the RIPE NCC is already doing in reaching out to the LIRs, that might be an option, just to consider.

BRIAN NISBET: I mean, I'm not advocating or otherwise, I am just kind of saying that there's a big difference between an audit and something that goes out to every single LIR every single year recollect that's my distinction there and that's one of the things that's come up in the discussions around verification of Abuse‑C, is that very big difference between an occasional audit and something which is done to every LIR every single year. So that's all I'm saying, and I'm putting no value judgement on whether it's a good or a bad thing at all, just a comment.

GERT DÖRING: Thanks again. We were doing, we were quite ahead of schedule. This took way longer than I expected so now we are slightly behind schedule, but we are still doing well. But it was definitely a good use of our time, so, thanks for the feedback.

So, now we are back into /22 transfer land, and I ask Elvis to ‑‑ Elvis will now just briefly present his proposal to limit abuse here and...

Elvis: So, this started first as a discussion brought up by Andrea to the community basically saying that the RIPE NCC observes some people actually using the last /22 policy as it was not intended. So, we had an open policy hour at the previous RIPE meeting, and came up with the brilliant idea that I would be making a policy proposal to tackle at least a bit, a tiny bit of the things that were noticed not to be okay.

And this policy proposal is only tackling the transfers using the transfer mechanism of the /22s from the last /8. And what the intent was, we currently have a two years cool down for any allocations that have been made by the RIPE NCC before the last /8 kicked in. And that means basically that any allocation that has been made by the RIPE NCC except the last /8 have already been made until September 2012, more than two years have passed. Any reallocation, or any transfer is covered already by the policy, and it's required that any transfer gets the two years cool down. I think mainly to avoid speculative actions on transfers and kind of avoid people making money from buying and immediately selling IP addresses and stuff like that.

So, the policy proposal is quite simple. The text that changes only the fact that LIRs that receive a reallocation cannot reallocate. That's the current text. And it changes it to LIRs that receive an allocation from the RIPE NCC or a reallocation from another LIR cannot do that. So basically, it adds the /22s that are being allocated by the RIPE NCC to any of the transfers. So it adds it to the two years cool down period.

Now the current status of the policy proposal is open for discussion, /UTS the second round of discussion, it has started only this Monday, and the discussion ends on the 9th June. I would really appreciate if you can voice your opinion on it, either pro or con, it doesn't matter, it's good to have the discussion, and it's being discussed on the Address Policy Working Group.

Now the Impact Analysis from the RIPE NCC which was published on Monday shows something a bit worrying. We were talking at the beginning that the impact of these transfers of /22s would be somewhere around 3, maybe 4% of whatever the other transfers are, compared to. In the last few months, the transfers with this poll poles tries to discourage have grown up to about 10%. So about 10% of the total /22s handed out out by the NCC are being transferred, and shows a very ‑‑ a really growing trend. And I expected this. This is normal behaviour, because what we did is the NCC pointed out some issues that they could see. We came up with a policy proposal which basically told the whole world, hey, this is how you can abuse policy or the intent of the last /8 policy, this is how you can actually make money, because right now, /22 in the market might be costing somewhere at, let's say, maybe, 8 to 10,000 euros or more, while a /22 from the RIPE NCC is only a maximum of €3,600. So, it's a you can actually go, register as an LIR, request a /22, sell it, register with the money that you have made, three LIRs, and continue like that. So, as you can see, the Impact Analysis, it's also on the website, I have just copied and pasted it, what I thought was the most important bits of the Impact Analysis, and the pros of this policy proposal is that it is trying to close a loophole that allows companies to set up LIRs and immediately transfer the /22s received from the NCC. And actually the policy proposal allocations from the last /8 aim to ensure that actually no organisation lacks reroutable addresses and what's happening now it companies are opening multiple LIRs, are transferring those /22s and are basically depleting the last /8 pool. Although, at a very slow pace, I think that once we have highlighted this loophole, it will be used by more and more people, and it is visible and already pointed out by Andrea that the growth of this loophole users is quite visible.

Now the comments on the mailing list have been pretty funny. I have had personal attacks from various people, some actually from my own country. And one of the comments was that I'm an IPv4 broker and that's why I'm putting in this policy proposal to prevent other people to make money. And I have tried to explain it quite clearly on the e‑mail as well that this is not my intent, and my intent is this was signalled by the NCC as a problem, and I did the mistake to stand up and say, okay, let's try and fix it. And I was nominated to volunteer to make this proposal. So, my job has nothing to do with this. If anything, I'm losing money by making this proposal. So, please, stop with the personal attacks at me or my company, because this policy proposal has nothing to do with what I'm doing.

Some other cons were go away with IPv4, we have IPv6, we should no longer talk about IPv4. The ship is sinking, no need to arrange the chairs, let them abuse it, it will deplete the pool faster. I don't agree with any of these, because what is the signal is saying because we don't want to talk about it, we're going to allow anyone to abuse the intent of previous policy proposals, and actually that creates a really, really bad precedent. We really need to discuss this on the mailing list, we really need to come up with a solution, or a result.

Now, limiting the entry to /22s is anti‑competitive. There was already an answer to that what have we allow this to happen and we run down to zero, is that competitive or anti‑competitive? What's going to happen then? And that this policy proposal's implementation sets a dangerous precedent. That was the last topic discussed this week. And as I said, I think every policy proposal will change the policy text, does applying to every resources, every single resource, and I don't agree with the last point of the cons, but we can further discuss it, although I think it was just responded today by Sander, which actually made it quite clear. That there was another point for the policy proposal.

SANDER STEFFANN: There was some confusion on whether this was actively applying policy to old allocations, and Gert and I talked about it and when we introduced the whole transfer policy, we didn't say only allocations made after today are eligible for transfers. All of them became eligible for transfer. So, like this, we're talking about transfers made after the proposal is accepted. And transfers on that date have to apply to the rules of that date. So, I think it's very clear, we're not actively saying to people oh you did a transfer, it now turns out it was not allowed so we're going to turn it back. Things that have happened have happened. We're only talking about things that will happen in the future. And if this conflicts with the intention of people just opening a new LIR and then selling off the addresses, I think that's kind of the whole point of this policy. So...

GERT DÖRING: And to repeat again, Elvis didn't come up with this proposal because he wants it but because the group was looking for a volunteer and he stood up. Basically, having given the message that we might want to do something about this. So, personal attacks are completely uncalled for. But the people in this room ‑‑

(Applause)

But the people in this room are not the ones anyway, so I hope that the message gets across anyway.

We are running very close to the break. I think it would be good to have a few voices still. There has been, since we are in review phase, mostly positive comments on the mailing list except for the one that this is retroactively applied to stuff, well nobody else seems to agree to, so I consider that objection to be addressed, but still, comments are welcome. Erik.

ERIK BAIS: So, first of all, Elvis, thanks for writing the policy, and being the punchball in this. As I said on the mailing list, you did not deserve that, and it was actually frightening to see the tone of voice in this particular discussion, and I think if this is going to be the precedent for the mailing list going forward, that was actually an eye opener for me. It was really, really uncalled for.

So, let's leave it at that. I hope we have a good discussion on it moving forward.

Going into the policy itself, it says the LIRs that receive a reallocation from another LIR cannot reallocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the reallocation. That's from the IPv4 PA.

The question that I have to be able to maybe move it even further, and I'm not sure if you are going to do a rewrite of the policy, but it will actually fix not only the transfers, or retransfers, as a suggestion, a 24 month waiting period for depleted resources like, after receiving of the resource period... which basically would also include a domain name as a suggestion.

SANDER STEFFANN: What you're saying is after somebody receives a resource, no matter in what way they received it, they cannot transfer it in 24 months.

ERIK BAIS: Exactly.

SANDER STEFFANN: It sounds like a very simple and effective wording.

ERIK BAIS: It's actually very effective wording, very to the point and basically, it aims to what we want to get here. If you receive a resource, you have a 24 month waiting period. I don't care how you got it. Whether it was through MNA, through the NCC or through a transfer. And that only applies to depleted or close to depleted resources which is 16‑bit AS and IPv4.

ELVIS: We'll have to define that, what is depleted resources.

SPEAKER: We can't actually put it in the text, because this is changing the IPv4 policy and not the transfers policy that we're going to talk about very soon.

SANDER STEFFANN: In this case in 16‑bit ASs and IPv4 are close to depletion, and 32‑bit ASs and IPv6 are nowhere near depletion. I think we can safely just numerate them

GERT DÖRING: As a matter of process, I would say, if this gets enough positive feedback and know show stopers, we go through with the text as it is and with you're unified transfer policy, we take ‑‑

ERIK BAIS: Definitely, I'll wordsmith it in my policy.

GERT DÖRING: Basically, it really depends on how this goes. If this goes smooth we want to have it in place quickly to make it stop. If we have to do another round anyway, we can do additional wordsmithing.

ERIK BAIS: That was actually the next question. Is there a way ‑‑ so as soon as we declare consensus, is there a way for the NCC to actually start acting as if the policy was already implemented even though there might be some software that needs updating and other stuff? So that we can basically stop this shit whenever we ‑‑ as soon as we can.

SANDER STEFFANN: As soon as we declare consensus on it the NCC can start acting on it; whether that is technically possible is something that they have to answer.

ERIK BAIS: But I would strongly ask the NCC to actually act on it. Because we want it avoid doing, you know, bank runs, those kind of things.

ANDREA CIMA: Like you mentioned, there may be sometimes software changes involved, in this case we have to give the time to our engineers to be able to plan and implement those changes but in this case we are talking more about procedure, it's about process and that is something that we as registration services department can take on ourselves, so, I do not see an issue with being able to implement this as soon as the policy reaches consensus.

GERT DÖRING: So it's now on us, you to actually give enough positive feedback to move forward. Right now what we have on the mailing list is good enough but we will see how the discussion will evolve. I'm not making promises on the future, I have ‑‑ we have had this discussion in the discussion phase, and I'm wary.

AUDIENCE SPEAKER: Chris Kruger from Basics. Just a personal side note to Elvis, as I was one of the ones actively asking on the last RIPE meeting for an RFC, I am really, really sorry that you got attacked for it. That's really bad behaviour and bad stuff.



AUDIENCE SPEAKER: Peter Hessler, I strongly support the new policy text. At a previous company we were small content provider, and we needed to get some IPv4 allocations for us and having the last policy allow us to get access to it really helped us keep our business running. And so, avoiding a bank run and another shady tricks to take a depleted resource, avoiding that would be very helpful for us smaller players in the market.

GERT DÖRING: Thanks for actually confirming that the last /8 policy does the job. This is important. Thank you.

AUDIENCE SPEAKER: Sebastian, speaking for myself mostly. Just a few things first, I remember sending here when this was actually discussed the first time and saying we have to hurry because I think it will get worse, and I had hoped that I was wrong, but I wasn't. So actually, I don't know if that's common knowledge but the executive board did something to make the merger and acquisition a bit more painful for these people by requiring a few years of payment of LIR fees before ‑‑

ELVIS: It's one year of payment. So any LIR that opens has to pay one year before they can do a merger and acquisition or a transfer of that /22.

AUDIENCE SPEAKER: I'm happy about that, which I just heard about a few days ago.

And the other thing is I actually asked the NCC for a few LIR closing statistics which are quite interesting, because this last year was the first time that the they are mentioned in the NRO report, and in 2014, we had closures requested by the member that were as high as the whole closures in the year before, so we have 100 more closures the last year than we had the years before, so that's something ‑‑ it's definitely going up, you'll see it everywhere in the numbers so we should act fast on this. That's almost all, because you know ‑‑ and one last thing about the comment it's a sinking ship. If you are in the other boat, it's easy to be relaxed when a ship is sinking, so if you have enough addresses you are fine okay, but I'm not a guy who wants to block new people that go into the market that will be IPv4 sent trick for years to come. So, thanks.

SANDER STEFFANN: I want to make one ‑‑ I see Nigel sitting there in the corner, thank you for the Board for actually enforcing that somebody has to be at least a member for one year because I think that's already a major improvement. So thank you for that.

GERT DÖRING: Okay. David, and then I'm no longer keeping you from coffee.

AUDIENCE SPEAKER: Hello, David Huberman from Microsoft. My concern about this policy is that you actually ‑‑ you may be encouraging those who stock up on /22s by opening new LIRs, to do so even more robustly today, because if you put a 24 month waiting period and hopes that stops it, in fact it can be the opposite. If I'm the bad actor, let me go get 20, or 30 or 40 of these, because in two years these are worth even more.

ELVIS: How do you know in two years they will be worth more?

AUDIENCE SPEAKER: 16 years in the addressing protocols tells me in two years we will be closer to 6 or 7% of IPv6 worldwide than 50 or 60.

ELVIS: We are at 6 to 7. However, I would love, if you would be right, because we try for the last 20 years, unfortunately this time I don't agree with you. I actually don't think that in two or three years the /22s will be worth more than now. What we're going to do with the two years holding period is actually discouraging this business of just getting the 22s to resell. I think it will work, indeed we might see actors that are just getting the /22s right now hoping that in two years, they will be worth more. But I don't think we'll see 30 or 40 of these kind of investments made by one individual because making 30 or 40 investments hoping for the better future is quite risky.

AUDIENCE SPEAKER: So real quickly. That's your opinion and that's possibly my opinion as well. But our opinions don't matter. It only matters the opinion of the actor. My point is that the policy text, if you actually want to soft problem, you have to empower the NCC to stop the actor. You have to write text that allows the NCC to say no, you open an LIR, you are trying to do this under a different company, the answer is no, until you can prove to us that this is actually real and not speculative. So my only comment is the Working Group should condition working on this and not just this will be the solution, and very, very quickly, this doesn't actually stop you from selling a 22 to someone who can use it because very few providers around the globe actually require ‑‑ do the check in the RIR WHOIS to see does this company, does this network actually ‑‑ are they the actually registrant and thus will I allow them to export this to me.

ELVIS: This can be done very simple. The question that reg verse the /22 can register two /32 assignments thus allow the company that is bought it use, it announce it, have it registered in their name.

AUDIENCE SPEAKER: Elvis, you don't need it in your name it RIPE DB to route it in most of this world. That's my point

GERT DÖRING: So, well, we are really into the coffee break now. This was a good argument, it's a bit hard to actually see where things are evolving to. I am sure the NCC board has heard what you said. It's partly our responsibility as address community, it's also partly the responsibility of the NCC board as they are the ones that control membership things. I'm not sure how much we can actually do about that, but the NCC is listening.

Two quick comments and then we really want to go for coffee because we have another session coming and without coffee you will all fall asleep. So please...

AUDIENCE SPEAKER: A quick question from me. Perhaps... I fear that this proposal will fail. I support it, but how would you prevent mergers from companies, because you can't prevent them from merging and they get the allocation.

ELVIS: This policy proposal does not cover mergers and acquisitions, this only covers the transfers of the /22s using the transfer mechanism, and for the mergers and acquisitions, there has already been a discussion just previous to this one opened by Andrea and I have already said at the beginning on the mailing list this will only cover transfers, we'll have to think about what we want to do about mergers and acquisitions so there's going to be an ongoing discussions because mergers and acquisitions are a process, they are not a policy, they are a RIPE NCC process. There is a document for it, but it's written by the RIPE NCC and updated by the RIPE NCC as a process, it's not as a policy. So, what Erik suggested earlier might actually be able to fix that even further, but we need to discuss further on his text proposal which might ‑‑ after coffee. Yeah.

GERT DÖRING: Last comment.

AUDIENCE SPEAKER: Amiana from Hungary. I would like to shortly comment on the previous comment received from Microsoft I think. Namely, I don't think this would be an incentive for stockpiling, so the implementation of this policy I think is a good move, so all kinds of abuses of the system should be stopped, but I fully agree with the other comment, namely that this doesn't stop here, so we have to be flexible and keep an eye on the processes and react as quickly as possible

GERT DÖRING: Okay. Thanks for your comments and your feedback. This is really helpful. And sorry for keeping you from coffee so long. You kept yourself from coffee for so long. So... please be back at 11, because we have a pretty full agenda for the second slot as well. Thank you.

(Coffee break)

LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE