Archives
Address Policy Working Group
18 November 2015
9 a.m.
GERT DÖRING: Good morning dear Working Group, or at least what's left of it. That's the issue with having a great party the day before. But then now I know that you are really interested in this and not just here to read your e‑mail. And now everybody is awake. Thanks.
So, this is Address Policy. If you half expected something else, you are in the wrong room. There is nothing else right now.
I'm your session Chair, Gert Döring, welcome. My co‑chair Sander Steffann is hiding. So, the usual administrative bits first.
Use hears the agenda for the first slot, administrative matters. Then current policy topic overview and then we have sort of three open policy proposals that we want to discuss.
In the second time slot after the coffee break, we have a presentation from Cipriana Nica, about the background, why Romania a was all of a sudden exporter number 1 of IP addresses, which I have been always wondering about and since we are here, this is sort of like, fairly interesting in understanding what happened instead of just wondering and doing speculations.
Then we have one of the regular items, the feedback from registration services. As you can see in the letters, it usually goes before F. The reason why it's in the second time slot is that the second slot is in parallel to the connect Working Group and people from there have asked us to have the discussions in the first time slot so they don't have conflicts. So we shovelled stuff a bit. If you don't want to discuss policy proposals, we might actually put it to the first time slot, but we will see.
And if we need more time to discuss the open policy proposals, it can go there and if something else comes up, it will also be there.
So, agenda bashing. Anything that should be there? Anything that needs to be shovelled around? Any additions, corrections? No, so we do this.
Minutes: The minutes from Amsterdam from been sent to the mailing list. All the delays in getting them published were purely my fault, the NCC did a wonderful job in doing really great minutes in short time, and then they were sitting in my review queue for far too long. So thanks to the NCC for doing this, it's not easy work, it's important work.
Any comments on the minutes? No. So I declare the minutes to be final.
And with that, we go to the first presentation from Marco Schmidt, PDO. I'm not sure I really really to introduce Marco, but still Marco is the good soul at the RIPE NCC who helps us not miss any deadlines, not make any sort of like process mistakes and so on. And reminds us about stuff. So, without him, policy making would be much more complicated for the Chair. Thank you.
MARCO SCHMIDT: Good morning everyone. As Gert said, my name is Marco Schmidt, I am the policy development officer of the RIPE NCC, and I'm also very proud to see you here so early in the morning after yesterday's social. And as a little revolt, I would like to tell you a little bit about the current policy topics.
First, I would like to give you a little overview what is going on in the other regions. Then I want to give a pre‑summary what has happened in our regions since the last RIPE meeting in Amsterdam and I want to close with a little update from the policy development office.
But first, what is going on in the other areas, in the other regions? AfriNIC, I will start with AfriNIC. They have since a few weeks also a transfer policy proposal. It's a resource transfers for it's for inter and intra, so it covers both ways of transfers inside the AfriNIC region and also to other RIRs. The first reactions on the mailing list were rather sceptical, I have to say, because people had the concern that it might increase the risks that resource resource running out of the AfriNIC region.
Another proposal that is under discussion for quite a while it the out of reach use. It would require that 60% of the resources handed out by AfriNIC must be used in the AfriNIC region. It was discussed several times doing during AfriNIC meetings and next AfriNIC meeting in Congo, it will be discussed again. There were some proposals accepted in AfriNIC at the last meeting, first one is Anycast assignments, it is now possible to get IPv6 Anycast in AfriNIC and also special reservations was created for internet exchange points. So there is now a pool of IPv4, a bit similar like in our region, and also a pool of 16‑bit AS numbers for IXPs.
APNIC: They had two proposals accepted, the last APNIC meeting in gentleman Jakarta a couple of weeks ago, and they both changed and eased a bit the requirements for IPv4 and AS numbers, it mainly removed the multi‑homing requirement and replaced it as an optional possibility.
And one proposal, it's still under discussion there, there's an idea to add a lot of additional information to the database, regarding assignments that even port numbers and so on, must be mentioned. But there's not much support for it and right now it's speculative proposal for future work.
ARIN: As usual, they have quite a lot of discussion ongoing. And I just picked a few ones that might be of interest also for our region.
First one is 2015‑2. That would change a bit the requirements for inter‑RIR transfers, because right now if you get the transfer inside ARIN region, you are not allowed to transfer it for 12 months outside of the region, and that proposal suggests to remove that 12 months holding period.
ARIN also has an out of region proposal again, they had one, it was discussed for a long time and then it was withdrawn. This is a new attempt now. It would allow that resources handed out by ARIN can be used everywhere in the world except of a clearly defined small amount that must be used in ARIN region, and that proposal is pretty precise; it says how much of IPv4 and IPv6 must be used in the ARIN region and also how even ARIN will verify that it's really used there.
And there are a couple of proposals under discussion regarding simplifying or even removing the need assessment, because now that ARIN has no IPv4 left to hand out any more, there are a lot of discussions similar like it was in our region for 2013, why do we need all this need assessment and they are under discussions.
And there are many more. If you are interested in all this ARIN proposals, you can find me in the coffee break or you can have a look at the ARIN website.
And last but not least, of the other four RIRs, LACNIC, also recently quite some discussions, quite some policy proposals. First one an inter‑RIR transfer proposal that has been withdrawn. Because it seems that LACNIC community was not convinced that it's such a good requested for their region to have inter‑RIR transfers.
A couple of proposals have been ‑‑ have reached consensus at the last LACNIC meeting. The first one is an intraRIR transfers, that was already in the policy manual but it said there that it only will be activated once LACNIC cannot hand out address space any more. And right now they do hand out small chance, up to a /22 every six months, so there is no intraRIR possible transfers. But, the proposal said that's not enough so let's trigger it now and it has reached consensus at the last LACNIC meeting and it's right now with the board, the LACNIC board, to assess if it can be ratified.
Same starter for proposal 2015‑4, that's resource recovery timeline. In LACNIC, it is possible that resources that are not in use, that they can be recovered, deregistered by LACNIC and right now it's after six months, and this proposal suggests that we even make it after three months possible and it also has reached consensus and it is under the review by the board right now.
Same goes for 2015‑5, which increased a holding period for a transfer to three years. Right now the policy says one year, that if you receive a resource, you cannot transfer for one year. This will now extend it to three years.
And last one that was a bit interesting, this made it a bit late for the last LACNIC meeting, that's why right now there is a call of consensus ongoing on the mailing list because just to explain, opposite to our region, in LACNIC, consensus decision are made during the LACNIC meetings, usually, but for this proposal has to be discussed long enough before LACNIC meeting on the mailing list, and this one, to explain a bit of background. LACNIC does not have one /8 pool like we have, they rather from some phases with different pools. They have one /11 for Phase 2, where everyone, every member can get every six months up to a /22. And then they have a final /11 reserved only for new members, or only for organisations that have not got any IPv4. And that proposal suggests to move that /11 that was reserved for only new members without IPv4, to that pool in Phase 2, so that also existing or current LIRs can get every six months more IPv4. And then for new members only address space that was given back from IANA will be set aside for this final pool. And it's on the mail list right now and it has received mainly support.
And I want to close this session, or this section with a little overview about transfers, because you saw that that's a topic in every region basically, and sometimes good to know what is actually possible in which region. IPv4 can be transferred inside ARIN, APNIC and the RIPE NCC. And probably soon also in LACNIC. And its proposal AfriNIC.
Inter‑RIR transfers of IPv4 are possible right now between ARIN, APNIC and our region. It is proposed in AfriNIC and it's not possible at this stage in LACNIC.
AS numbers, similar, ARIN, APNIC and LACNIC allow ‑‑ sorry, not LACNIC ‑‑ RIPE NCC, allows it and it's not possible in AfriNIC and in LACNIC.
Inter‑RIR: Only APNIC and we allow AS number transfers. On IPv6 we are the only one that have a policy for IPv6 transfers.
So this was a bit of global overview and now I would like just briefly talk about what has happened in the last months since May, since the RIPE 70 in Amsterdam.
A couple of proposals have finished the PDP. Three of them have been accepted. First one 2015‑01, probably many of you will remember that one. Since then also resources that were handed out by the RIPE NCC cannot be transferred for two years.
2015‑02: Now, LIRs can keep the IPv6 PI, even if they request an IPv6 allocation with the same routing requirements. It will make it a bit more easy.
And 2015‑03 added some additional criteria that the RIPE NCC can consider from organisations asking for a large IPv6 allocation.
There is one proposal that has been withdrawn just last week basically, the removing of the multihoming requirements for AS numbers, but seeing the discussion on the mailing list, I sense there's a good chance that there will be a fuller proposal soon for that one.
And we have right now two proposals under discussion, Gert just mentioned them, so I will not go much in detail in them, it's 2015‑05 and here I just want to add one clarification to something that was mentioned on the last, during the last RIPE meeting, because there the proposals was mentioned, or raised the idea, there was some questions or some ideas on, in the room how much actually or for how long the IPv4 pool of the RIPE NCC will last. And there were numbers like ten years, or even more. What the RIPE NCC calculated, it's probably enough for five to five and a half years. And here you can see a little bit why we came up with this calculation. The blue bar is the actual last /8. So that's 1885 /8. It's going down constantly. If you look the speed of the decreasing is a bit picking up. At the same time, in the last months and years since 2012, we also got some address space back, mainly because of IANA, they hand out every six months some address space to the five RIRs, and also related to the 2007‑01 project, the registration of independent resources, and the resource that is ‑‑ that shall not registered to a resource holder were deregistered. That's why you see always this bumps that it's going up again and that's why we still have around the /8 in our pool. However, this ‑‑ we don't expect much more to come in right now. The IANA pool is now very small. The next chunks will hand out are rather small the 2007‑01 project has finished, so we see that the speed of the decrease in the last /8 will continue, but we don't really expect it much more address spaces coming to us.
If you want to know more about this, I included a link in my presentation to an article on RIPE Labs from my colleague and there's a bit more explained the whole calculation.
And another proposal 2015‑04: It's in review phase since yesterday evening. I don't know if you had time already to read it. It was a bit short. It was a little bit of work to be done before it could be published, but just on time for this session, we made it. And I'm curious what will be discussed about this later.
And last section, a bit of some numbers, a bit of some overview about the PDO. So far, we have more than ‑‑ I have seen more than 1,400 posts on the address space mailing list, which is the highest number ever. Mainly related to the controversial discussion around 2015‑01. So far, 175 participants from 18 countries have joined the discussion which is also an increase to the last years, but it always can be better. Of course as more people participate it might create a bit of extra work for the Working Group Chairs but it is good for the whole PDP.
And that's why we are working and working together with my colleagues on increasing the awareness and the participation, sending out newsletters to different mailing lists and monthly PDP update, giving presentations, giving training, helping proposers, approaching people that have a problem that might be possible to tackle with a policy proposal, and we are continuing to work on that and here what I just mentioned about the participation, a bit of traffic visualised so that's the biggest part of our service region and you see different countries in different colours and the darker the colour, the more participants have been joined the discussion, and you'll see like for example, the dark red spot in the middle, Germany, Netherlands, England, the UK, and Russia, there's quite high participation. Others a bit less. And if as we're here now in Romania, let's have a look, a bit more here, so, the yellow, orange country in the middle that's Romania and that's also actually quite good participation. But if you look around, there is still some empty spots like Moldavia, Bulgaria, Serbia and other countries, former Yugoslavia, and that's why also we want to use this opportunity to the people here in the room and on the webcast, if you have not spoken up yet on the mailing list and there's a proposal that concerns you that you have an opinion about, so don't hesitate to do so and to speak up because the decisions are made on the mailing list and if you don't participate, the decisions will be made without you. So, please don't be shy, it's not difficult, if you are here, many people that you read on the mailing list are also available, you can talk to them, they don't bite and they can also help you a little bit.
And that brings me to the end of my presentation. I just want to add some useful links. The current policy proposals. There is a link. If you like the map that I showed there is also an online version that's interactive, you can hover over different countries and you get different informations how many participants are there and how many posts per country. On my Twitter account, if you want to follow, I try to send out updates about policy developments in our region from other regions and even outside of the RIR system, so you might like to follow me there.
And that's the end. I'm happy to take any questions. I don't se anyone. Then thank you very much.
(Applause)
GERT DÖRING: Thanks Marco. So, everybody is on the same level of information now.
Now, we enter the discussions on the Open Policy proposals. I just want to remind you of this. You all know this anyway, you have seen the slides often enough.
Marco already said it, unlike LACNIC we don't do decisions here. This is useful to get quick feedback on whether something should go this way or that way, but the actual decision is made on the mailing list, so after the end of a phase in the PDP, the chairs go out and look what has been said and try to well sort of like figure out whether we have consensus or not. The reason to do this is that it's really all transparent, open and you don't have to come to meetings to influence policy making.
On the other hand, as I said, meetings are good to get a quick feedback from the room to see how feelings are, which direction something should take. If you speak up, please use a microphone, because this is webcast and people are listening remotely. Speak your name, so the scribes can properly attribute who said what and people on the other end of the web stream also know who said something. And you can provide feedback by RFC and Jabber of course as always.
So, 2014‑03:
Remove multihoming requirements for AS numbers. That policy proposal formerly is no longer in the system because the proposers withdraw it last week, mainly because it wasn't really going forward. There were arguments that were sort of incompatible to solve about how open the policy should be. People wanted it to be open but at the same time, not abusable by somebody registering for billing AS numbers for free. There was hope that maybe the AGM would just solve this for us by reintroducing a charge for AS numbers which would have sort of like an immediate effect on if somebody really wants to register 4 billion AS numbers, fine, we could all use the money and be happy about it. But the AGM decided not to do this. Then it sort of got stuck in limbo again for six months and the proposers withdraw it last week.
Immediately after that the discussion started that we really must have something like that, and so, in parallel, somebody volunteered to actually drive this forward again with a new policy proposal, that's Nick Hilliard, I think I have seen him over there, and since it basically continues the work here, I'd ask him to present his ideas right away. Nick, will you come? Thanks for volunteering.
NICK HILLIARD: Good morning everybody. So, the current policy actually dates from 1996. It goes right back to RIPE 141 and that's actually pretty amazing. It's 19 years old. This is one of the oldest policies we have on record. And it's actually turned out that it's worked reasonably well, because we haven't actually seen a need to change this policy in the last 19 years. I mean, we have talked about it occasionally, but it's more or less intact in that period.
It's not perfect. It has a couple of problems. Some people need ASNs, even if they don't multihome. There are plenty of examples of this. We had some discussion about this on the Address Policy Working Group mailing list where people single upstreams, but yet there was a requirement for them to use BGP.
Also, in a couple of years time we are going to run out of ASNs 16s. There is a finite pool of them, 65,000. The RIPE NCC has a couple of thousand left. They are being depleted slowly and one day they are going to be all gone, and we might need to think about what we're going to do here.
I think the most important thing right now is let's not panic. We actually don't need to fix either of these problems. Because, it turns out that neither of these problems were actually massively important. We don't want people to lie about the whole multihoming problem. We don't want people to tell lies to the RIPE NCC in order to be able to justify an assignment. But people have kind of been doing it and there is a quite an implicit acceptance it's going to happen from time to time. Personally I'd prefer if this didn't happen. The RIPE NCC is a registry and it's got a duty to register resources based on accurate information.
So, some people have a requirement for an ASN where there is no requirement for multihoming so the policy is a little bit broken but not massively.
ASN 16 runout: Now, this is a kind of a more difficult one, because we have lots of ASN 32s and they are more or less the same, but they are not quite the same. They have some technical differences, in particular if you are trying to run transit networks, they have issues associated with BGP communities. And these communities are ‑‑ they are a problem on quite a bit of older software, there is some support for newer software for some of these systems but in the wild west of the Internet this is a difficult problem right now, and in particular, there's no support for 32‑bit: 32‑bit communities and that's not possible in the current community framework. There is a draft which is not got beyond chatter stage at the IDR Working Group in the IETF to open up communities and to make them, you know, all whizz bang with free text and numbers and all sorts of things. But, it hasn't been codified yet, there are no implementations. It's not been worked on terribly hard at the IETF who seem to think that there isn't a real problem here.
So, should we panic? I really like red buttons, I just want to press this button.
Okay, should we change the policy? Well, we probably should. It's not necessary, and if we do, we probably want to fix these problems.
So the first thing is multihoming. This is slightly arbitrary, it turns out. And I went through all of the old RIPE policies about how to deal with this. And it turns out that a much better definition for requiring an ASN comes from RIPE 81 which dates from 1993. "An AS is only required when exchanging routing information with other ASs." It's really succinct, it's really simple and it happens to be completely the reason why you need an AS. I think that this qualifies for what we would traditionally call a needs‑based requirement.
Okay. ASN 32s:
I had a look through the figures. It turns out that 80% of assignees only have a single ASN. And if there was some way of optimising this to say look, if you want an ASN 32, and you don't have another ASN already, the RIPE NCC should just give it to you. Okay. And that would actually solve 80% of all the ASN assignments. That would just put them off in a basket and they would be sorted. No particular reason to justify it. You know, you just go to the RIPE NCC, ask you them can I have an ASN 32? And they say yeah. Okay.
Subsequent ASN 32s, there's no reason ‑‑ I mean, people are going to need ASN, multiple ASNs in many situations, about 15% of organisations have a requirement for more than one ASN, so, yeah, sure, give them an ASN. If there's a requirement, and what we have at the moment is we have a needs‑based requirement which is hinged on this idea called multihoming, so if we change that to a needs‑based requirement based on needing to connect to exchange routing information with another ASN, that's pretty good as well.
ASN 16s:
An ASN 16, at this stage, we kind of should be looking at a situation where it can be assigned if the end user has a requirement which can't be satisfied by an ASN 32. I am kind of a bit mixed about this. Maybe we should just put in something like it should be up to the choice of the end user.
And the more important part of this is do we actually want to runout pool for ASN 32s? I think this would be a good idea and I think it would be a good idea for a couple of reasons. There are technical differences. There are situations where having ASN 16 is quite important from the point of view of sensible BGP policy management, and therefore, in the longer term, it would be a really good idea in order to be able to facilitate new entrants into the market, to have some sort of pool to allow existing organisations access to it in the same way we have existing organisations have access to the IPv4 runout pool, we have something similar for ASN 16s. So the proposal here is that if an organisation needs an ASN 16 from the pool, they can get one from the pool, but they can't get any subsequent ones from the runout pool.
So, in summary: The proposal that hasn't been put in yet but it goes to be put in. The needs‑based assessment goes from multihoming to exchange routing information with another ASN.
The first ASN 32 is assigned on the basis of entitlement. Any end user is entitled to an ASN 32. There are lots of them there.
Next ASN 32s and ASN 16s before runout are assigned on this needs‑based policy, which is to say exchanging routes with other ASNs, but after runout, any end user is assigned an ASN based on need but they can only get a single assignment.
Okay. So that's the outline of the proposal. If anybody has any questions, I'd be glad to take them.
AUDIENCE SPEAKER: Good morning. David Huberman from Microsoft. First and importantly thank you very much for stepping up and helping us here, we appreciate it. I would like to ask you to please consider two policy proposals. You have two very different issues that you have discussed with us today, and I don't wish them to be conflated. I say that because I agree with one of them and I disagree with the other. They are not related. One is about do you need an AS number to run your network, to run your project? Yeah. And one has to do with RIPE NCC's management of two ASN pools which, the situation on the ground is going to change over time, and I think these two things are very different. Just my input.
NICK HILLIARD: Okay. Thanks for the suggestion. That creates a lot more work for people unfortunately, it creates twice the amount of work. It turns out that policy proposals scale the nearly. We should probably chat about this off line rather than discussing it at the mike here. I can see where you're coming from. I'm not sure if I agree with you, but I think it's a good point and I think it's something that should be thrashed out.
AUDIENCE SPEAKER: Brian Nisbet, HEAnet. One question, which I expect I already know the answer to, but is there any danger that putting things in place which continue the ASN 16 as a resource, as a pool there, with a runout with a long tail, will delay the work that the IETF and others are doing to actually deal with the ASN? There's two problems they haven't dealt with so far.
NICK HILLIARD: The IETF is largely in denial that there is a problem. And this is slightly inexplicable. I have tried on many occasions to say that there is a problem, and it's difficult to get this through. I can't really explain it. But there are community assignments for 16‑bit:32 and 32:16, and it's actually turned into a bit of a rats nest in terms of BGP community mechanisms to the extent that there's actually now a BGP community mechanism XML page on the IANA website where you can actually look down and check and see, you know, what BGP community mechanisms are in place, they are all slightly different and they all have slightly different semantics and meanings, so it's a real mess, and I don't know, I don't think this is going to have any effect on the IETF whatsoever. The wide BGP community proposal that I mentioned earlier, it was proposed several years ago, it's very complicated. There's no running code. It does things that are going to be difficult for router vendors to implement such as being able to you know, for example, create free text, BGP communities using UTF 8. I don't know. It's ‑‑ I don't see this happening any time soon and even if it is standardised, it's going to take several years before there's any main line implementation of the standard.
AUDIENCE SPEAKER: Chat from Elvis. As to what David said, I agree with him. We have two problems this future policy proposal will address. Two policy proposals will be better than one.
SANDER STEFFANN: I just want to make a short comment on that. If we are starting two policy proposals on the same text, how good it works when you have a version in system and you have two patches. We are going to get merge conflicts depending on which one passes first, so if we are going to have two proposals we are going to have to serialise them. We really have to think if that's what we want.
NICK HILLIARD: It's difficult. We had ‑‑ this problem has been dealt with before and it's a bit of a pain to deal with. But yeah, let's take the discussion off line and we can talk about this.
AUDIENCE SPEAKER: Andrew Dail, ARIN AC, speaking for myself. I have a question of how you define runout for 16‑bit ASNs. When ‑‑ have we already run out?
NICK HILLIARD: Okay. If the RIPE NCC pool of ASN 16s drops below thresholds, at that date runout is declared to have happened.
AUDIENCE SPEAKER: How do we define a threshold?
NICK HILLIARD: You pluck a number of the of the air based on what seems sensible.
AUDIENCE SPEAKER: Ingrid white, Registration Services, we currently have approximately 2,900 16‑bit ASNs left and current assignment rates this represents 36 months of supply. So, the threshold should be somewhere below that number and relatively soon.
NICK HILLIARD: Thank you very much.
(Applause)
GERT DÖRING: Thanks for taking this. I think I see you discuss with people in the coffee break and then send us text. Thank you.
SANDER STEFFANN: So, one other thing I just noticed, the IETF thing with the 32‑bit communities. There seems to be something where the IETF needs some input from the operators. I just want to get a show of hands to see how many of you think we as chairs should make a statement towards the IETF that this really needs some work. So who would be in favour of that? Anybody thinks it's a bad idea? Thank you. I think we as chairs can now go and tell the IETF. Thank you
GERT DÖRING: So, tech support already put up my next slide. Thank you. The next proposal on our agenda is 2015‑04. It's the proposal from Erik Bais to unify all the transfer policies into one common document that basically whenever you want to do a transfer you just go there, a single stop document. It was on the list in discussion phase. It sort of got some support. It got some critical questions about some actual changes to the transfer policy like introducing holding periods for resource that did not have them yet. It's not like they are trying to be sneaked in. Eric announced he was going to do that. If we decide we are not going to do that, it can be taken out again.
The discussion phase ended and we had enough support to go forward, asked the NCC for an Impact Analysis, the Impact Analysis brought up an interesting oversight in the wording. Go read it yourself. But in the end, the intention of the text was very clear, but the wording was so that an outsider could actually read in that you could all of a sudden transfer PA blocks to any end user out in the world, which definitely was not the intention but the text was not clear here. So, the current text certainly cannot become policy. But that doesn't have to stop us from actually discussing the merits of this, and finding new text that has the same intention but also clearer wording to ensure that it's absolutely clear what we want.
And basically, with this, I hand over to Eric, I'm not seeing him right now. There he is. Thanks for taking this on.
ERIK BAIS: Thanks Gert. Morning everybody. This was an interesting week to say, specifically with all the work that needed to be done, so specifically on the RIPE side, to get the Impact Analysis done in time, and as you will see during the presentation, now this is basically what happens in the end and why we actually have to take our time in doing the Impact Analysis and actually trying to give the NCC as much time as possible to do this properly and I'm glad they actually got here where we are at this point.
So, the proposal itself currently is in the review phase since yesterday evening. So, that also is probably the reason why most of you were yesterday evening at the social and didn't read the Impact Analysis yet. Don't worry, you know, it will be there for a while. But, it will actually, because of the timing, it will actually you know, need some more time for you as the audience to actually look at the Impact Analysis, see what was going on and will actually basically need to skip for a lot of things that were in there. Even for myself, I didn't have time exactly to process everything in the Impact Analysis. We did have sometime yesterday and the day before to actually see you know what will happen, you know, leading up to this presentation. So... and that's also how the presentation will actually come to be as it is currently.
So, in short, the actual presentation is to get a single policy document with all relevant policy text, basically meaning this is a functional policy proposal that is not related to just IPv4, just IPv6 or just ASN allocation. So, this is actually a question for later that I will post and I actually ask to the audience. This is a document that will change how we actually look at what do you want if you go to the RIPE NCC.
Because, historically, the policies were well, what do you want? I want IPv4, you know, PI space, an ASN number, you want IPv6 and it was basically clear where you need to have, you know, where you can find the various things in the policy. And this is different, because this basically talks about transfers. And everything about transfers, because we basically took out everything everything from all the other policies that you know I'm guilty, we actually put in there myself. And so this is basically a different approach and this generalisation document is also on the the work that we did, the reason why we maybe generalise add bit too much.
So, the goal is to remove all the transfer related text, including the inter‑RIR documents, and basically get one document and basically clean up everything from you know v4, v6, PI, AS numbers, everything.
So, that was basically the idea. That was the feeling that we got from, you know, creating three different policies basically all talking about transfers last year and basically everybody said, well, they all look the same, you know, you're trying to do this here for AS numbers, that's for v6 and that's for PI, you know, we get duplicate text basically in all documents, it we just do this differently? And yes we can, and this is basically what came out of it. And the thinking was actually logic, but you know, this is definitely something that we need to have, I would like a show of hands later on for.
So, where are we currently? If you look at the ‑‑ this is something I took from the RIPE NCC site. The PDP process. And this is basically in timing where we are currently. It's actually now the big arrow on the right was taken one step now because they are actually in comment and review. But when I actually made the presentation two days ago, this was basically the status where we are, and so, the time in here was basically the reason, and we actually squeezed it specifically for time for creation for the Impact Analysis. And the timeline for the publication of the Impact Analysis was actually quite aggressive because we wanted to have the community to have time upfront to be able to do this.
But, you know, the review actually has impacts on several departments. It needs to have legal review. And then Marco also needs to, you know, gather all the information from everybody and say you know, we need to publish this prior to the RIPE meeting. And we at the RIPE agenda, that needed to be done, preparation for the RIPE thing, IETF last week, so... and then you have Marco trying to say, things are running out. You know, we need to get this done.
And then fortunately we had somebody that had a nice catch, and I want to thank Remco, I'm sure he is not here, I hadn't seen him, he actually did catch the thing that was in there, so well done for him. But, you know, there was an issue in the text in the draft, and that basically said you know, we can ‑‑ if you look at the text itself, it's the last paragraph of point 2, it actually says that if you look at the text from the context in which it was written, it's actually perfectly clear and it will say, you know, either you have to have a contract with an LIR or a contract with the RIPE NCC or with an LIR or you know as an end user. But it didn't ‑‑ because of the generalisation, it missed the specification there where you need to have, as PA holder, as an LIR, cannot transfer PA space to an end user. And that the type of contract that was needed was also not specified. So, basically, Gert and I could basically have a contract saying that, you know, we deliver certain services and I basically, you know, transfer PA space to him in his personal name, and not mentioning the NCC in there anywhere at all. So, although there is discussion already in IP space is IP, you know, we need to get rid of all the different colours and flavours and those kinds of things. This was a bit too much. This was not intentional and we need to fix this.
So, on this stuff, specifically for the functional document, the functional policy document, and this is something clearly different than the other transfer documents, is this the way where we want to go? Because, it will not have ‑‑ having a transfer document means that we have several places where we might have IPv6, IPv4, ASN related policy text in two different places, and that is different, really different than what we had in the past. So, that is something that we need to have a good idea about. Is this, you know, the type of documents and the type of new functionality and new policies that we would like in the future? Do we want to have documents based on functionality? And the transfer documents, as, you know, basically the inter‑RIR document was the first of its kind. The transfer policy basically is the umbrella where that now falls under, but there might be ‑‑ there is a real difference in here compared to you know, the strict IPv6 policy or the IPv4 AS number policies. So this is something I would like to get a feel from the audience from. If somebody has an opinion about this, because, we're actually changing something here which is you know, potentially could be fundamental, because in the past, we said I want v6, v4, AS number, what do you want? And now we're saying, you know, it's not about numbers any more, what you want, it's now, oh, what do you want to do? You want a transfer? Which might actually have you know a different look into it. And with that, there comes an implication, but we need to be aware that this is something that is different.
Any opinions on this?
GERT DÖRING: Well actually, do I have an opinion and I think this is a worthwhile exercise. Because, duplication of nearly identical text in four different documents, and then having the separate inter‑RIR document which sort of like stands on its own and duplicates functionality from the other documents just different receivers is not that good either. I can see the historic background of having IPv4 in the IPv4 document and so on, but the way people interact with the NCC has also changed. So... if they come here for a transfer, they want to find out about transfers and not go through all the documents. But, I hope this is going to start an interesting discussion. Peter please.
AUDIENCE SPEAKER: Peter Koch, I was wondering what we are going to do here the objecting tag knell view on options of transactions, so I'm glad you brought it up yourself. Of course, I have to disagree with somebody, and since Jim isn't in the room I'm going to disagree with Gert here. Well, he already disagrees by sheer presence, that's cool. So, seriously, I think I understand where you are coming from and people come with certain motivations and the certain motivations might not be the object but something to do with the object, that's going to be assigned to allocated, to first of all, the exercise that you went through and that the group also went through probably shows that, well, what looked similar was same, same but different, and therefore, these like editorial changes are kind of risky and seem to have a trap.
To address the needs of those people who come here for a particular purpose, there might be another way that is not as strong as a policy document, and that brings its own risk but that could be an explanation re Tuite Tor yell like document that says here is a summary of what's going on and so on and so forth but in the end the policy document is what rules, and since if you come here to discuss policy, you sooner or later have to go back to some document anyway, and I would probably feel a bit more comfortable with sticking where here especially if the intent is not to change anything but then invest the effort in explaining the things that are there like the road map to transfers or something like that. So, changing essentially it is changing the policy just to make things more accessible is ‑‑ doesn't really convince me.
GERT DÖRING: We have done document cleanups in the policy documents in the past and it was usually painful but worth the exercise. The thing is cannot just do nothing here. If we decide that we do not want a joint transfer document, we should ask ourselves the question: What to do with inter‑RIR transfer document, which is a separate document. Should we split that up and integrate it into the other documents? So just doing nothing means we stick to the inconsistent mess we currently have.
PETER KOCH: I doubt that the presence of an inter‑RIR document is inconsistent, because policy is said intraRIR, so having the policy defined in documents per to be assigned or allocated object is fine, but then something that is regulating or defining the external relations that is crossing the boundary is necessary anyway.
GERT DÖRING: But actually if you want to transfer to another RIPE region LIR, you go to document A. If you want to transfer to an ARIN LIR you go to document B. Is that what we want? I don't think so. I could see just keeping it in the IPv4, IPv6, AS numbers policies but I think we need to do some cleanup somewhere. Either this way or that way.
PETER KOCH: I guess you could construct this inconsistency both ways, if I'm interested in v6 objects I need to go to two documents, if you suggest what becomes reality because for like an allocation slash assignment I need to look in this document for a transfer, I need to look in this document.
GERT DÖRING: True. The question is which way do we want to clean this up? Do we merge the inter‑RIR transfer into the object policies, or do we move the transfer bits out into the process document? The point is, I don't think cannot just do nothing. Because the documents are not good right now. But that's just me. People, speak up.
AUDIENCE SPEAKER: At this moment, RIPE NCC, I have a comment on chat from Elvis. I think the best option is to first do a cleanup of all the policy documents and move all the transfer parts in one document. Then do additional changes using further proposals, merging all documents together and adding other things in there, at the risk of rejecting the proposal although the intention of merging everything in one policy is a problem.
SANDER STEFFANN: That's actually a slightly different discussion. So, let's keep that for later.
AUDIENCE SPEAKER: Jano from Hungary. Actually I don't actually necessarily agree with the assessment you made with the policy inter‑RIR transfer issues and intraRIR issues, because I have the impression that the policy documents currently specify how normal transfer within the region can be performed, and if there is an inter‑RIR transfer, then it is supplemented by special rules, so it overrule the rules which are in the regional transfer, rather complement them, so that's my impression at least. So I'm not sure that this is different and should be necessarily either integrated or everything should be redesigned as is currently proposed.
ERIK BAIS: I tend to agree with you there. Specifically recollect the inter‑RIR policy is different by its own. However, going through this whole cleanup of all the current policies and enclosing the inter‑RIR document will actually have, in fact, a ‑‑ we'll call it a functional policy document, and that's going to be a first. And that is a really different approach than what we have done in the past. That's the only comment I make here. And the question to the audience and the membership is basically, are we aware that what I'm doing here? And is this really what we want? Because, I don't mind doing it either way. I just want the community to be aware that this is different. So that's the only thing I'm saying here. And I'm fine either way. So, either ‑‑ but for when we made the decision we need to do a cleanup and basically, you know, put everything in a single document, it was a logical idea and I think it still is, and I think it makes sense to actually have everything in a single document. It will make life easier for everybody, specifically if you look at how many transfers we're doing and specifically in the future where transfers are actually seriously ‑‑ a serious topic why people will actually start looking in policy and start looking at the RIPE NCC website. So, making it as clear as possible and as easy as possible for people to find the relevant information is definitely worthwhile. The only thing that I'm saying here is, we can do it either way. And I like the other suggestion as well, you know, maybe on the website. However, it needs to be done. There needs to be some cleanup. The question is do we want to have it in this process or not? But that's something to ponder on.
SANDER STEFFANN: One of the other reasons actually, put them in one document, was that having multiple copies of the same text in different policies will, in the long run, might actually to them slightly diverging in weird ways. So having them in one text makes ‑‑ is easier to keep it consistent. But that's an editorial problem.
AUDIENCE SPEAKER: Andrew Dail, ARIN AC. I don't have an opinion on how you manage your documents here, but I will point out that in the ARIN region, about ten years ago now we merged all of our documents into a single policy document that is edited in revision controlled. That has worked for us. It has some issues in terms of how you change certain sections during times, but you can just point to one policy document and that is the policy document at the time.
AUDIENCE SPEAKER: Ingrid whit, RIPE NCC, you commented on whether we should do this on the website on the policy. I would like to mention that on the website we have already created a section that describes resource transfers, within that section we have outlined lots, what the procedure and the policy is for each type of resource. So that part we have taken care of. So I think a discussion is, do we want it together in one policy document or separate? The documentation, we can go either way.
GERT DÖRING: I'd like to hear a few more voices from actual members from the region, please, anyone having an opinion on this? It's a bit hard to make policy if you just tell us don't go there and nobody is challenging the single statement. Okay. No party for you next time.
Well, technically, we need to take it to the mailing list anyway because it's on ‑‑ it's in the review phase right now and what happens happens on the list.
ERIK BAIS: Yes, so there are some things in the current policy document, in the current version, that is basically, you know, changing some things, specifically around merging acquisitions, the holding periods, and also the way ‑‑ how we look at the transparency reporting, so, basically the NCC in the Impact Analysis has, you know, pointed out their view on what do we do with the unsuccessful transfers? Do we need to keep posting those, because the number is not going to increase and basically it was there. Do we need to provide more information in the way as we are currently doing? But, also, the change of holdership after merger and acquisitions, there has been ‑‑ I think the NCC did a very good job in the Impact Analysis on that, you know, specifying their view on that, and that really is something that we would like to have some ‑‑ read that information, give some comment on that on the mailing list.
So for us, we need to stay calm, you know, go back to the drawing board, specifically with the minor glitch that we need to fix here, as you know, for both myself and for Marco, who assisted me on this, we basically ‑‑ for me as a non‑native English speaker, really looked it over and with me, gladly, a lot of other people, and so I'm not alone here on the wall of shame, but we definitely need to fix this.
AUDIENCE SPEAKER: At this moment from the RIPE NCC, another comment from Elvis Vilea, a bit delayed in answer to Gert's question. I think we should move all in one document, he is saying.
AUDIENCE SPEAKER: Randy Bush, IIJ. I am a member of an LIR in this region. I actually have a real job. I don't just represent some RIR. And consolidation and less policy, I will admit to having introduced unsuccessfully a policy in the APNIC region of which we also are a real LIR to be the last policy proposal. No more policies. We don't need them. This works. Enough
GERT DÖRING: Thanks for this. I think we can do with one time slot next meeting. That was on my router anyway since we sort of keep winding‑up the loose bits and pieces and then everything it perfect and we just close down the Working Group ‑‑
SANDER STEFFANN: We have said that for the last three or four meetings I think so.
GERT DORING: But we succeed in actually winding down the number of policy proposals.
SANDER STEFFANN: What I want to suggest for your proposal, it is currently a proposal to put it in one text. It's in review phase. Unless ‑‑ and people are not jumping up and down like this is wrong, so, unless on the mailing list something comes up that says we really need to have them in separate documents, I suggest we just keep it as it is.
ERIK BAIS: That was the intention for me as well. However, if somebody ‑‑ because, it was actually pointed out to me and somebody said, well, maybe we need to emphasise a bit more on this, so that because this is an actual change, and that was also the reason why I wanted to put it in the presentation because I couldn't, you know, discuss on the other stuff yet because I didn't know what was actually in the Impact Analysis yet when I made the presentation. So, from that point, it was a good point to actually get the feedback here in the room, basically address the point, and with that, having that addressed and if there's no strong objection, we'll move forward but we'll ask the mailing list as well.
GERT DÖRING: Yes, but that's what we have to do anyway. Take it to the list, point out ‑‑ well, we already pointed out the glitch. Basically, ask the community for the direction to go forward. We will need a new text anyway, and that new text will either just fix the glitch or take out the actual changes that's introduced with the holding periods and so on. There has been comments that people ‑‑ some like this, some don't, so we need to agree on what we want. And this will have to be done on the mailing list anyway. So, thanks for presenting, giving us a reminder what this is about and what the key items are.
And with that we jump to the last policy proposal on our agenda today. There we go, it's the revision of the last /8 allocation criteria. Radu‑Adrian is here to present his proposals, has been on the list for a while. It has been a fairly heated discussion, if you may say, and I'm not sure whether we can actually reach consensus on that but I'll leave the presentation to you first and then discussion later.
RADU‑ADRIAN FEURDEAN: Hello. I'm from France. I propose this proposal together with Elvis who, unfortunately, is not able to be here personally, as I understand he is present remotely. So, let's start a little bit with the origins of the proposal, why did I start ‑‑ why did I initiate this?
Okay, so sometime ago we did a policy for IPv4 runout. It was almost five years ago. It started being applied about three years ago. And, well everything was supposed to be okay, except that the allocation size was reduced and at the time when the applications started, there was no policy to attribute new PI address space and the proposal for PI was finally rejected sometime later. So, as the time passed, we passed a little number of other proposals, one of them was that "no need policy." I have the date of application of each policy. There was no minimum size which doesn't directly has an implication on allocation but has an implication on some of the arguments which have been presented, such as aggregation. That one completely breaks the aggregation because as we seen on the transfer market, there is plenty of /26, /24.
Then we had transfers which have been greatly facilitated including the fact that we can transfer PI address space which, well, depending on how you see it, it may or it may not be the best thing.
We started to see scavengers that just take space out of the last /8 pool and use it for other reasons than the intended ones. Then in 2014, we started getting back address space from the IANA. It was the reallocated ‑‑ recovered in the reallocated address space. And some small complications like multiple LIRs /company, mergers and acquisitions, which both of them are pretty much out of the scope of the policy. They cannot be ‑‑ there are things that cannot be regulated by the policy. This is my understanding and this is other people's understanding too.
So, in this situation, this year we reached for three months a point where the available address space was more than a /8s, almost three years after the policy known as the last /8 policy, so...
We had the biggest pool, we still have the biggest pool after AfriNIC, so, AfriNIC doesn't have any issue. We are the next on the list, and there's the other RIRs. We still have the most restrictive allocation policy, and still, we are the only RIR which does not apply a needs‑based policy any more. I saw that there are other RIRs which start thinking about removing the needs policy. We are already there for sometime already.
There is the multiple LIRs per company. Again, this is something not regulated by the policy and this is being used by some, this is being abused by others, and, well, even if they can't agree to the fact that this can be, let's say, a wanted loophole, most people don't know about it. The ones that do it, they use it and as I said, some of them abuse it.
Other things: IPv6, it's working yes and no. You can have web access and stuff like this. There are a number of other things that just don't work, game consoles, not all of them are working over IPv6, and on small enterprise market, IPv6 is pretty much nowhere.
1024 addresses is far from enough, and well everybody says use CGN. No, there are things that break.
And other consequences are that the fact that previously bigger customers, the one that had the /24 or even PI, since they're using a lot of addresses, some LIRs, smaller LIRs can no longer cope with the situation so they push them becoming LIR. So, what was previously a customer, now it's an LIR. And they are using one /22 which is usually more than they need. It's not really the best thing, the best way of managing addresses, in my opinion, and obviously there is a desperate need for more than 1,000 addresses.
So, the basics: In version 1, the proposal was quite short, issue periodically another /22. And for the second, for further /22s, just add the one extra condition. You can get extra /22 if you didn't transfer out of your LIR, out of your LIR because there's the distinction between LIR and organisation, whatever organisation does mean.
Well, the feedback was not very good, as Gert mentioned, at the beginning we had a lot of no, things are good the way they are. There were a few okay. And there were some okay, but we'd like to see some changes.
So, now the main question is: Are we happy with the current policy? Is this really ‑‑ are the things the way they are happening, are they the things that we expected several years ago, especially before starting implementing the last /8? I'm not sure about this. But this is subject to discussion. And, well... the policy as it is, it's being abused more or less by some people. Can we do something about it? We can't do everything as I told you, there are the issues that can not be done with policy, and if you want to do something, within the policy, how do we need to fix the policy?
Questions please...
GERT DÖRING: First of all, thanks for bringing up the topic. As one could see from the discussion, it's necessary to have the discussion. Even if the outcome is we don't have consensus to go forward to actually have the discussion and the arguments on the table is important. So definitely thanks for taking this up.
ERIK BAIS: Thanks for the nice summary on how the reactions were on the mailing list. What I'd like to stress here specifically around this policy and on the topic itself, the reason why we actually stated that we need to have a /8 ‑‑ the final /8 policy is to actually help people implement v6 and actually be able to do this in CGN so that they can basically connect for their current customers or future customers into, and still have the connectivity to the v4 world; that people are not using that /22 for that reason is not a reason to change the policy. Because, a /21 will not solve that issue either if they are not intending to use it for why the /22 was intended for. If they start using v4 that they were being given for other reasons than actually using the v4 to overcome the issue and actually implement v6, then it doesn't matter how much we throw at them because they will always run out; that's the thing why we actually run out.
So, there is no solution or metric that we can put up here and basically say this is the reason for actually, you know, increasing the /22s to a /21 or a /20 or whatever, because we will run out.
RADU‑ADRIAN FEURDEAN: Well, the issue is we will run out. We didn't run out yet, as seen by most people, we did not run out. And if you say that the last /22 is supposed to be used to implement IPv6 related stuff like can I remember grade NAT or whatever, I think we can modify the policy not the way I proposed it but in a way that says explicitly this is why you get the last /22, not for everything else. Pretty much what ARIN did, we all say that ARIN run out dry. They didn't. They still have a last /10, which they are using exactly this way. You get maximum /24 and it is for implementing IPv6. We can do the same thing, if this is what we want to do. But right now, the policy is not clear that this is what we want to do.
ERIK BAIS: That was the reason how the policy actually coming in existence. That was the reason for the policy as it was. You can look it up in the archives ‑‑
RADU‑ADRIAN FEURDEAN: Yes, but the policy does not state it.
ERIK BAIS: Then maybe that is what you need to change in the policy, but changing the actual /22 into something else will basically prevent future newcomers in actually participating into the community. And that is basically why this policy was created. You know, to have the possible ‑‑ to give you know the future Twitter, what's app, whatever company, the opportunity to participate.
RADU‑ADRIAN FEURDEAN: Well, seeing this way, I'd say there is another counter argument is the fact that when you want to start Internet based services, most Internet based services did not start with let's say independent resources, whether PI space or as LIRs. They started by taking transit with IP space from somebody else. We never required something like this in the RIPE region, and my understanding is, for example, ARIN did require something similar. Either you have to justify a lot of what you receive, or you are changing address space from somebody else with, let's say, somehow independent address space. Because everything ends up in being independent. This is why traditionally people became LIRs; they want to longer depend on a transit provider or stuff like that. They wanted to, let's say, be dependent on an independent organisation which was RIPE, and besides RIPE being a membership‑based organisation, just makes things better for them.
And concerning the new entrants, I hear a lot of people saying that well we want to last until 2020, or ten years after the application of last /8. We won't.
I saw what was the interpretation of RIPE NCC. I only partially agree with them. I have my data collection. I have a spread sheet that was published on the mailing list which is in free access where I get all the, all the address allocations and have a graph on them, and with that data, we will not get in May 2020. For the first RIPE meeting in 2020, we will be out, out, completely out of IP address space with current policy, with no change.
So my idea is okay, I have ‑‑ I propose something. It will probably split in so the as fast as some people appreciate but there are also other things to do. So, I think my proposal should be a first step. The other steps would be to clear not on policy level the other issues.
ERIK BAIS: Okay. So ‑‑
RADU‑ADRIAN FEURDEAN: Mergers and axe significances and multiple LIRs
GERT DÖRING: While, I did enjoy that discussion, we are actually running a bit short on time and I want to give the microphone to the other people in the list. Sorry Eric for kicking you...
AUDIENCE SPEAKER: Tim from RIPE NCC, a comment from Elvis Vilea on chat. Considering the heat the discussion, it is my opinion that the policy proposal in its current version will not be able to reach consensus. If Radu decides to do a second version and changes the proposed text, I will no longer be part of the proposers' team. I had a lengthy discussion with Radu previous to the Ripe meeting and we tried to see if there are any ways to change this proposal in order to get to a Version 2 that would be approved by the community. However, I do not think that by adding more restrictions on who could receive additional /22s could reach consensus.
RADU‑ADRIAN FEURDEAN: I am aware of this point of view. I was actually expecting it, given the feedback.
On the contrary, there are other people like Ricardo who are able to take over the work. So, just for the principle, I will propose at least one version.
AUDIENCE SPEAKER: Hans Petter hole an, RIPE Chair. As your Chair, I have had the pleasure of travelling to a lot of regional meetings in this region and meeting new members, and I think it's a couple of things that we should be aware of when we discuss proposals like this.
First of all, there are a couple of thousand new members since this /8 policy was put in place.
Secondly, it's a very diverse region. Not only are there old players and new players, it's also players with a lot of money and players with not that much money.
So, what I hear from the newcomers is that yes, anybody can get a /22 and you can actually get as many as you want by just setting up new companies and new LIRs if you have the cash.
So, the voice I'm hearing from the new comers is that well you have given me the first thought for money, I want a bit more so I can sustain my business and maybe some day I will be able to deploy v6 as well because today that's too expensive and it doesn't serve my business need in my country, my region.
So I think we need to think a bit about we actually in the situation that we have more address space left than when we put the last /8 policy in place. It's running out fairly slowly compared to the other regions, and we are kind of just giving address space to those with cash. So, is that really what we want as a community?
RADU‑ADRIAN FEURDEAN: Thank you for explaining the situation in a different way. Thanks.
AUDIENCE SPEAKER:
JIM REID: I want to agree wholeheartedly with what Eric said a few minutes ago. I think he expressed certainly my opinion much more succinctly and much more politely than I would have done. So thanks for that. I think you are making one or two mistaken assumptions that the situation we're in now with address space allocation is very different nowadays than what it was five years ago, ten years ago, and trying to base things around the models and practices of five or ten years ago and say that's how we did it back then, we should do something similar now. I don't think that's going to work. Yes, Hans Petter is quite correct, we have got a situation where the current policy could begin by the people who have got the money so spend to set up lots of brass plate LIRs, if we find evidence of that obviously we have to do something to finetune the policy. If we can continue with the existing policy as is. I think that's probably good enough. I think we should recognise as well that the current policy punishes everybody equally. It's certainly unfair, it's not nice but everybody is sharing the same pain, you are getting one /20 and that's T get over T I think that's the best way forward and I don't think there's any sense in saying this guy is more deserving if he could get an extra allocation or this person is not using their address space to do an IPv6 migration, therefore we should take their address space away from them or not give them another allocation or whatever. I think that is mad and I think the idea of trying to say to people that if you get this allocation of your final ‑‑ your final allocation, you must only use that for IPv6, I think that's also wrong. It's up to the LIR holder to decide how best to use the addresses ares and it might be for v6 but it might now but that's their choice and I doubt we could police that or the NCC could police that. We have to let the LIRs do with the what they can with the address space they have, just as what people do with the address space in the past.
RADU‑ADRIAN FEURDEAN: I don't agree with the fact that the pain is the same when you have a /10, you can scavenge just customers that have cancelled their contract and you can potentially get the amount of a /22 just out of that, when you have a /22 obviously you can. If you have a /21 or 20, it's very, very difficult.
JIM REID: Yeah, but come on, the people who were getting /10s with bigger allocations ten, 15 years ago, we were in the a different world then. It's a different world we're in today. We have to deal with the practicality of the situation we are in just now and try to preserve what we have got the address space for as long as it's reasonable and practically possible.
RADU‑ADRIAN FEURDEAN: What is reasonable?
JIM REID: I think we have got something now with the existing policy mechanism. Whether that will last to 2015 or 2050, I frankly don't care, but the policy as currently structured is everybody shares the pain equally given where we are right now. If someone was an early mover in the Internet space and was able to get large amounts of address space because they were an early adopter, fine, yes, they are in a better position than a newcomer. That's life. Get over it. We have got Legacy holders before the RIR system that are sitting in huge chunks of spaces, /8s for example. We can't do anything about that. We can't do anything about what's been done with the space that was allocated ten years ago or more. Get over it.
GERT DÖRING: Purely practical matter. We are now five minutes into the coffee break. Our agenda for the second time slot is actually light, so I expect us to have at least 20 minutes left to spend on this.
So I would say two more comments then close the line for now. Coffee break ‑‑
AUDIENCE SPEAKER: Should we move ‑‑ should we continue the discussion after the coffee break?
GERT DÖRING: Yes, that was the intention, to sort of like close down the line now and re‑open ‑‑
AUDIENCE SPEAKER: Wilfried Woeber one of the early adopters of the model of local Internet registries. First of all, my personal perception is that the last /8 policy is exactly working as many of us intended it to work when it was agreed on. Just a basic statement. There is always the chance to finetune something, although you have to ‑‑
Secondly, I hear Hans Petter with regard to the financial implications, but the situation that we have right now is actually well defined, it is predictable, and if you want to start a business, you actually have got something to plan with. And that's sort of the thing like this is the structure, this is the policy, this is how we are using it. So, you get a planning horizon of more than maybe a year. I think this is essential for any business coming into the field or trying to offer new services. When it comes to the question like should an LIR that is created or should the method to obtain an initial or an additional /22 cause cost a certain amount of money, that's in my books not a policy issue, that's an AGM charging issue.
So if we think that this is too expensive, then we can take that to the sideline and have the discussion what the price tag should be.
But, if we go ahead and burn the remaining IPv4 addresses on a much faster rate, for the new entrants and even for the existing ones it's not going to become cheaper because they have to buy the addresses on the free market. And I don't see any indication in short or the mid‑term that buying addresses is going to be much cheaper than getting the addresses within the regular predictable mechanism.
So, the third and last one, it's a short one, when I was listening to your comment about you disagree with the prediction about the lifetime of the existing IPv4 address pool, I think you are contradicting yourself with the line of your argument. Because either you want to have a long tail or you want to burn it. But you can't have it both at the same time.
RADU‑ADRIAN FEURDEAN: I know.
GERT DÖRING: Okay. Final comment from Jabber and then ‑‑ feel free to discuss in the coffee break, of course, and then we are back here at ‑‑ final comment and then coffee.
AUDIENCE SPEAKER: One last comment by Elvis Vilea. If we do decide to move forward with v2, my previous comment does not apply I will be against the policy. I will still support a Version 2 as long as it makes sense. It's just that I will not be able to continue the work on this proposal and I'm happy that other people, for example, Ricardo, will pick up my proposer's seat.
GERT DÖRING: Thanks.
Okay. Coffee break now. Please be back at 11 to continue this.
(Coffee break)
