Address Policy Working Group
25 May 2016
9 a.m.
GERT DOERING: Good morning, dear Working Group. Again, good morning. This big room is a bit tricky because it's really hard to estimate how many are here because the room is so big, but I see more than I expected to be honest after a great party, so I'm happy to see you here.
In case you're wondering what this is, this is the Address Policy Working Group, and even though we don't have IPv4, we are going to discuss IPv4 today. IPv6 policy seems to be fine and AS number policy seems to be fine, so we focus on v4. This is my co‑chair, Sander Steffann. I am Gert Doering, I'm going to lead the session and Sander will steer the discussions.
So, this is the agenda for today. First, administrative matters, approving the minutes. Then we go into selecting a new Working Group Chair. We have this procedure of where one of us steps down every year, and can be reappointed or somebody else can take the job. More about this later on.
Then, Marco Schmidt from the NCC will give us an overview about current policy development topics around the world, all regions. And then we start entering discussion about our own Open Policy proposals.
After the coffee break we will have a presentation about market concentration on IPv4 space transfers, which is basically giving us feedback on what is happening in the outside world with IPv4 space these days.
Then, Andrea Cima from the RIPE NCC registration service also give us feedback, what they have observed in day‑to‑day business, rough edges of the policy, unclear text, discussions with the members, things we might want to do something about or at least be informed about.
If we don't manage to finish with the Open Policy proposals in the first slot, we then go on with the discussion here. And then we have Open Policy hour and AOB. So anything that is not yet formal but you want to bring up, it's welcome there.
So, agenda bashing. Is this good? Have I missed anything? Do we need to shuffle something around? Seems to be okay. So we follow this agenda today.
Minutes:
The minutes from the RIPE 71 Address Policy session in Bucharest have been sent to the mailing list. A big thank you to the people from the RIPE NCC who did a tremendous work on the minutes. It was really, really a big thing of work, and very good quality. The reason why they have been published so late was because I had no time to read and review them and because they were very detailed minutes, it was a long document and ‑‑ but ‑‑ yeah, all my fault.
I haven't seen any comments on the list, so, unless there are comments here, we declare the minutes final. Okay. Formal stuff. Nobody objects.
So I declare the minutes from Bucharest to be final and we go onto the Working Group Chair selection.
The process we have for those that have not been involved a couple of years before, is that every second year ‑‑ well, each of us serves for a two‑year term, and then steps down, and can be reappointed. We don't do elections. We do consensus‑based Working Group Chair selection because the usual aspects with elections is that who gets to vote is not so clear and, since we do everything consensus basis, it's also a good thing to have a Chair. So Sander, it's his turn to step down, so, now I'm the lone Working Group Chair. As for the new co‑chair position, we have one candidate who introduced himself on the list. And I think 21 people immediately expressed big support for him. Nobody said, yeah, but I want to be Chair as well. And nobody said, no, I do not want to have this bloke again. So, I think if I have ever seen strong consensus, this is it.
AUDIENCE SPEAKER: Randy Bush, IIJ. You made us go through months of BS on the mailing list about this process, and we're ending up with the same before and after. Of course I support Sander. But, you know, there's got to be some lesson taken from this. You know... this is not the IETF. We don't have to wrap endless process around doing nothing.
GERT DOERING: Actually, there is something behind it. There is the Chair that actually goes through the motion, gets to consider whether he actually wants to do this again. So, there is ‑‑ even if you feel like you have to put up with the two of us for yet another year, the self‑reflection, do I want to be with this crowd again for two years is sort of like worthwhile.
SANDER STEFFANN: Besides that, it's just nice to have a confirmation from the community. But we try to make this process as short as possible and I think we're spending more time ‑‑
RANDY BUSH: So we're going through all this to save you €90 for a psychiatrist hour?
GERT DOERING: Yes.
SANDER STEFFANN: Actually, standing up as a Chair costs much more for psychiatry.
AUDIENCE SPEAKER: Brian Nisbet. Just to say, Randy, I realise yes, too much process, but you have got two people up on the stage who are standing up on the stage, who are on the mailing list all the time, having this kind of process, at least makes it clear that other people can get involved, gives the options for other people to get involved and gives a way which doesn't involve standing up in front of a room full of people, and we're all recovering from the party the night before, to put yourself forward, and I think that, yes, we have spent too much time on it this morning, I realise, but I think it's a very good thing to have that option.
GERT DOERING: We will see what happens next year, if this IPv4 policy discussions go on, I might step down for good next year. So... it's good to have, and have exercised the process.
So... since I do not hear objections ‑‑
AUDIENCE SPEAKER: Good morning. Peter Koch, DENIC, so it isn't all wrong in the DBRK. The way this was driven, and while I agree with the end result, the way this was driven can probably be optimised. It wasn't so much only to make the Chair reconsider, but one of the drivers was to stipulate a bit of change. And if that's taken serious, then some things should be changed in that process, that doesn't mean that we need to revamp the process, just common sense would apply, which is don't make this a run through. Separate the role of the outgoing Chair from the person driving the process, and maybe the outgoing Chair, or the standing Chair is going to wait a moment for, to give other people a chance to step up. If we end up with the same situation, that's fine. But the way this happened... this is not the only Working Group where it has turned out to be that way with not achieving the initial goal. So maybe you want to reconsider that next time.
GERT DOERING: Well, our goal was not to have as much change as possible. The role for this Working Group is actually to give people the chance to speak up. But also have consistency, so we consciously decided to not force kick out the outgoing Chair after so many terms. And this is the reason why different Working Groups have different processes here.
PETER KOCH: No, maybe I didn't make myself understood quite well. I didn't say as much change as possible, that would be easy. But stipulating change or encouraging change would at least mean encouraging other volunteers, and with the elephant immediately standing up again, that's maybe a bit harder than it could be.
GERT DOERING: Right. We will take that into account next week.
So, anyway. I still haven't seen another candidate, and I have not seen anyone speak up against Sander, just against wasting time on the process, so I think we have a new Working Group Co‑Chair. A round of applause, please.
(Applause)
So, Marco...
In case you don't know him, which is unlikely, Marco Schmidt is sort of our counterpart at the RIPE NCC running the policy development office and helping us get everything right, formal timeline and so on. Thanks Marco.
MARCO SCHMIDT: Thank you, Gert, and good morning. And also, from my side first, my deep deep respect that so many of you managed to show up so early at this Address Policy Working Group session after yesterday's social, and as a little reward I would like to give you an update on the current policy topics.
First, I want to tell you a little bit what's going on in the other regions, what policy resource discussed there, what policy changes. Then I will give you a very, very brief update of proposals in our region. And I want to finish my presentation with an update from the policy development office to show you a little bit what else I'm doing besides sending your announcements to the mailing lists.
First, let's have a look what's going on somewhere else in the world. I will start with AfriNIC and I have a slide for each RIR and will show you some interesting proposals.
AfriNIC right now is discussing number resource transfer policy. This would be about IPv4 only and if it would reach consensus, IPv4 would be transferred inside the AfriNIC region but also to other RIR service regions.
A proposal that was discussed for quite a while in AfriNIC was the out‑of‑region use policy, and it has been recently withdrawn because the AfriNIC community could not find consensus on some limitation, how much address space can be used outside their region or not.
Then, quite interestingly, there are two proposals right now under discussion in AfriNIC that want to change the soft landing policy. So that's something similar like our /8 policy, the last /8 policy. Currently, the soft landing policy in AfriNIC says that once they will reach a threshold of a final /8, in the first phase only allocations with a maximum size of a /13 will be possible and once AfriNIC would be down to a / ‑‑ sorry, to a /11, only allocations of a /22 will be possible. The first of the two proposals, the soft landing BIS wants to make this even more strict, that it would limit the allocation size in the first phase to a /15, and it also would introduce the requirement of having IPv6 to receive such allocations.
The second proposal, the soft landing overhaul, suggests quite the opposite. There it is said that until AfriNIC will not reach the /11, business is as usual, so there will be no limitations, the allocation and assignment policy will go on like now and just wants to have a /11 only small allocations of /22 will be possible to their members.
And there was a proposal published just last week called the Internet number resource audit, by AfriNIC, and this proposal wants to mandate AfriNIC to perform regular audits to the members to check their address utilisation and how efficient they use the address space, and the first response is on the mailing lists were rather mixed, some people questioned how this could be put in practice, how AfriNIC can verify good utilisation, and also it was questioned why not the current AfriNIC procedures that contain already audits, why they are not sufficient?
Moving on to our colleagues from Asia Pacific, APNIC, they are the only ones that right now have no active policy proposal upped discussion. They have accepted and implemented recently two proposals that remove the multihoming requirement when requesting IPv4 and AS numbers, abd one proposal was withdrawn. One or two suggests to put very detailed assignment information in the APNIC database, but people didn't like it and it's from the table now.
Our colleagues in North America, usually there are many proposals under discussion, I just picked a few that might be a bit more relevant to our region. First one is a change to their inter‑RIR transfer policy. Right now it says if a member of ARIN gets an address space transfer to themselves, they cannot transfer address space for 12 months to another RIR. And that proposal suggests to remove that holding period.
Then we have one proposal that was in last call until last night and just in the night it was announced to be accepted. That's why the slides are not updated. This one removed the requirement for IPv4 assignments that 25% must be used within one month, which was considered as quite not so practical.
Then, a proposal it has been accepted in ARIN is that the out‑of‑region use. So now it's very defined in ARIN policies that Internet resources can be used out of the region except for a small amount that must be used inside, a /22 IPv4 and a /44 IPv6.
And another proposal that is regarding need justification, there is a proposal to simplify the justification for transfers, that only an LIR would show that 50% of their overall address space, or the one that they have plus the one that they would get into their registry, would be utilised by 50% within two years.
And one proposal that was published earlier this year is a change to the transfer policy, because ARIN has some specific pools for IPv6 transition and also for critical infrastructure, and right now, all IPv4 address space would be possible to be transferred, and people saying that that doesn't really make sense that such specific assignments, or address ranges from a special pool can be just put to the transfer.
And closing with our colleagues from LACNIC, they also have been very active recently. One proposal has reached consensus and is also implemented that changed also their soft landing policy. They had initially two pools of /11, one for existing members and a second /11 only for new members, this is proposal changed that, that this both were combined in one /10, that is open to all members. And for new members there was a second pool, a special pool created only containing addresses from the IANA recovered pool, and addresses that LACNIC has recovered in their own region. And once there's no address space left, new members will only get address from this smaller pool.
Something that is under discussion right now in LACNIC is to create a special pool for critical infrastructure, but it's right now not clear yet what would be counted as critical infrastructure. Critical Internet infrastructure, so it's still ongoing and will be discussed again next LACNIC meeting in Costa Rica.
Same goes for 2016‑5. This one wants to modify the IPv6 allocation policy, because right now members in LACNIC get a /32 by default, and if they want more, they have to justify this by customer numbers, and this one actually wants to introduce new criterias, and the text is almost identical to something that our community has accepted last year, 2015‑53, so it would introduce new criteria such as hierarchical and geographical segmentation, security requirements and so on.
And something ‑‑ two proposals that have been moved to last call. They are all both are around IPv6 assignments because it was considered that there is some text in the LACNIC policy that was taking over from IPv4 and doesn't really make sense for IPv6 assignments, so ‑‑ well, it should be removed and consensus is there and it's right now in last call.
This was the global overview, now very, very quickly, what's going on in our region, because most of the proposals will be discussed straight after my presentation.
No proposal has reached consensus or has been withdrawn since RIPE 71 so everything that was on the table in Bucharest is still to be discussed, plus a few new proposals.
In discussion phase we have right now 2015‑05, right now more about it after my presentation, then we have a proposal that is discussed in the Anti‑Abuse Working Group that wants to introduce a mandatory abuse contact for legacy Internet resources. The first version wanted to apply by default and people were to the sure how this could be implemented because legacy resources don't fall usually on the right policy and since Monday this week there's a new version that suggests that such abuse contact only would be mandatory if somebody wants to update a legacy resource in the RIPE database and if you are interested and if you have an opinion about that proposal, I invite you to go tomorrow at 11 o'clock to the Anti‑Abuse Working Group.
Another proposal that is not discussed here that is discussed in the RIPE NCC Services Working Group is 2016‑02 and this one wants to ask the RIPE NCC to create a service, a kind of certification that routing entries in third‑party routing databases can be verified against RIPE NCC registration information.
And 2016‑03, also don't need to say much. It will be discussed right after. And the same goes for the only proposal that is right now in the review phase, the transfer policies comes straight away. And this brings me already to my last section, a little update from the policy development office. First some numbers.
How active have you been? In 2015 we had around 1,500 posts on the address space mailing list, which is the highest number ever and it was mainly related to the rather heated discussions around 2015‑01 that introduced a holding period for allocations from the RIPE NCC. And also to 2015‑05. More interesting and quite positive, I think, is the number of participants. We had 175 people speaking up on the mailing list for proposals or for policy‑related questions, and they came from 29 different countries.
And this year, so far, we had 400 posts around, maybe a bit more now. Coming from 86 participants from 23 countries.
And I have put those numbers for 2015 also on a map. And you can see actually quite nicely, that as darker the colour of a country, there's more participants coming from that country. And it's actually a pretty nice spread all over the region that people participant and you notice people from other regions like the US or China that also chip in when there are policy discussions.
And as we're here in lovely Copenhagen, I wanted to highlight the participation of Denmark so far, and there was no participation unfortunately, and maybe the Danish RIPE community isn't bothered so much by RIPE policies, but if this is not the case, so if you think a policy change is impacting you, you have an opinion about, it I really want to use this opportunity to reach out to all the Danish RIPE community members to speak up on the mailing list because that's your chance to influence policy discussions.
Another topic that I quickly want to mention is an action point raised at the last RIPE meeting. Also, for example, about 2015‑05 the proposal, because people were wondering why the RIPE NCC still has a /8 in its pool more than three years after we have reached the final /8. And to make this more clear, we have put some additional information in this chart that we publish weekly on our website. You see now there is this dark grey area. This is the actual final /8, the 185 /8, and you'll see this is constantly going down because that's the address range from which we are right now handing out allocations to our members. Then in the top you have a light green block that is all address space that is also available for future allocations that is out of the 185 /8, that's for example, address spaces were coming from the recovered IANA pool. You can see this very significant jumps, and they are getting smaller because every time we get less address space from IANA, and also address space that has been returned to the RIPE NCC over the last years.
And on the top you see a little light blue part. That's reserved IPv4 address space. We have a reserved pool for temporary assignments and we have a reserved pool for ISP assignments. And also address space that is returned to the RIPE NCC goes first in a kind of quarantine period for six months and just later it is released to the available pool and that's why you see that this one has been growing, and, as we don't get so much address space back, it is currently getting less and less and over in the last months our pool size is going down.
And I want to finish my presentation with some upcoming new feature. It's called RIPE forum. Several times we have discussion on different mailing lists that people said yeah, I don't want to get so many e‑mails from so many mailing lists, is there another way to participate? And we have created a web‑based interface that would allow to participate on mailing lists discussions via this interface, so the subscription, everything will happen there so you don't get e‑mails any more. And the idea is to attract also new people to join policy discussions, for example, from Denmark. And important news for all of you that are subscribed to the mailing list, there is no change for you. You will notice nothing, because it's just an additional interface for anyone who doesn't like to get so many e‑mails into their account. And you see here, a screen‑shot, it's currently activated on the Atlas mailing list as a pilot and there is also a test mailing list, and currently the Working Group Chairs are looking into the numbers collected from that pilot phase and if everything goes fine, we might activate and roll out this interface already by the end of this week.
And that brings me to the end of my presentation. If you download my slides, you can click on those links, there are policy proposals, the map that I just showed, it's an interactive map that you can hover over the countries and see how many people participated. And the RIPE forum, if you want to try it out, there's a test forum where you can play around a little bit so you are welcome to do so. And, of course, if you have ‑‑ want to follow me on Twitter, you get the latest updates about policy developments in our region and also globally.
That's the end of my presentation and I'm happy to take questions.
RANDY BUSH: Marco, could I just get an official confirmation that if ARIN fixes its outbound AS number transfer policy, that RIPE region will accept the inbound AS transfer undercurrent policy and procedure?
MARCO SCHMIDT: Yes, I can confirm this. Because our transfer policy says that as soon another region has another transfer policy, a matching one, it will be possible. Yes.
AUDIENCE SPEAKER: Hello, Tahar Schaa, consultant for German Government. I have a question concerning the LACNIC proposals, and you mentioned there is a proposal for changing the criteria to get initial allocation of IPv6.
Did you see that they refer to the change in the RIPE region policy?
MARCO SCHMIDT: It was not specifically mentioned, but the proposal, yeah, was also active here, and it is clear from the text that it's ‑‑
GERT DOERING: Thank you, Marco, for that. Everybody knows what's going on worldwide now. Now we go into the discussing the open policy proposals. This is a short recap. All of you know this anyway. In this room, we don't make decisions, we discuss future direction and get a quick feedback on which direction we might want to go. There is remote participants on IRFC and they listen to the audio stream, so please use the microphones, but we all know that anyway.
So, first on my list is Erik with the resource transfer policy cleanup proposal, which you did not like so much ‑ well, half of you liked it, half of you did not like it, so that means no consensus in its current form, and he brought up new ideas.
ERIK BAIS: Good morning everybody. So, we're going to do a short recap on the RIPE resource transfer policies. My name is Erik Bais. This is I think the second or the third time we're actually discussing this ‑‑ third time ‑‑ we're discussing this here. This is ‑‑ I want to introduce for today a new queuing mechanism for all the discussions, so if you are at the mike and you want to skip the line, raise your thumb, bring your towel, you can go right to the front of the line.
So, for those not initiated, it's towel day today, so there we have it.
So, currently, the phase is awaiting decision from the Working Group Chair, and it's extended. So, we'll go through. There were some issues in the previous version, and we fixed that. In short, for the policy, we created a bit of a mess with all the various transfer policy changes, thinking about the AS number policy, the IPv6 policy, the policy for PI space, and that basically gave a lot of redundant text in all the other policy documents. So the goal was to remove all the redundant text and basically come up with a single document, and that's how we got here.
And that was basically this whole cleanup process is where we are currently. And this was all, you know, requested by the community, by the same room we're standing here, and it was actually quite ‑‑ you know, it made sense, and very logical, but is it? So, at some point, we needed to say all right, do we step back and we need to do some homework, and this is basically what we did also after the issue that we saw in RIPE 71, and we actually did our homework. So, we reviewed the policy that we have currently. There are no issues stopping or blocking currently the text we did quite some, you know, some thorough changes in the current version, and that basically you know, it's a sound document that we have currently. It's been reviewed. Athina, Marco helped to word the proper ‑‑ or made proper wording in the document and that's how we got through the version here.
So this is where we are currently in the whole PDP process.
So, the question so answer currently, as we're talking about form and not content, because the content in itself, there's you know, not a lot of things that are being discussed currently on the actual content, because the content is basically the same with some minor changes, but basically similar to what was actually already in the current policy. It basically is, are we planning to do similar documents? Is this a special for this one type of policy? How this policy has been written? Because this is not a v4 policy, it's not a v6 policy, it's basically a number resource policy. Which is a bit of a different approach. However, RIPE changed over the last number of years, and we may actually need to look at this differently.
So, this is basically the summary. Oh, my God, you have done something different, and as my towel explains here, don't panic, you know, this is not the end of the world yet. Although it is about transfer policy, this is not the end of the world. And basically we need to step back and say how do we get here and can we actually do something different.
So, there are actual ‑‑ so this whole discussion where I want to go through is, how do we want to do this? So, are we going to do this as we have always done it? You know, resulting in the same thing, because at least you know what you're getting. Are we going to do this per functional area? And this is basically how the current document has been been created. Or perhaps, do we need to look at something completely different? Perhaps, look at something like how ARIN is doing it in a single document, basically, smack everything in a policy document.
Now, there are various options. And that is currently a bit how I look at this. So, my preference would be, regardless of where we're going with form for policy, proceed with the text that we have currently, yes, it's okay to be different. It's not an issue. And if we actually decide we need to change form to match with the rest, then it may actually be better to actually have a fourth document as it is currently, and basically take it from there and present then to a task force the attacks and say, we may need to look at something different because this policy may not be the only issue, we actually need to review all documents. However, I don't want to delay this process here with this policy and keep this open into you know 2020 before all the documents are being reviewed and done.
So, having said that, that's basically where I'm currently looking at. A thumbs up, Remco...
REMCO VAN MOOK: I know where my towel is. Good morning everyone. I'm an ageing woodworker, I have no idea what I'm doing here. So the sustained opposition you have on your policy proposal, I am guessing that's me. I know that's me. And with that said, I absolutely recognise the work that you have done. I fully agree, even, with all of the stuff you are trying to fix. And I'm also willing to drop my opposition to your policy proposal because this is stuff that needs to be fixed in a wider structure, and there is absolutely no need to keep pacing over your policy proposal. So, with this, I would ‑‑ I mean and I will repeat this on the mailing list because that's the official place where I'm supposed to be doing this stuff, but I'm withdrawing my opposition. So... you're welcome.
ERIK BAIS: Thanks Remco.
GERT DOERING: That came somewhat as a surprise. But it seems our processes are actually working by discussing and talking about things. Opposition can be addressed and agreement reached.
AUDIENCE SPEAKER: Hi, good morning. Elvis Velea. We had an informal chat a couple, or maybe even yesterday, I don't remember any more from all the beers. While Remco is withdrawing his proposal, I still want to see the new version, because I had ‑‑ if there is a new version.
ERIK BAIS: It's been on the website for about six, seven weeks now.
ELVIS VELEA: Then I'll have another read of, it because I did express, I think also on the mailing list, but also in discussion, one concern about adding the mergers and acquisitions process into the transfer policy, which is basically bringing something new which is a RIPE NCC internal procedure into policy.
ERIK BAIS: Not entirely. The only difference that's been made in the ‑‑ because we're not talking about the actual mergers and acquisitions process. There is a merger and acquisition procedure, I'm not touching that, that's not up to me. The only thing that I'm saying in the document is that resource changes by holder will actually trigger a holding time. That happen means that everything with ‑‑ you know ‑‑ and that has to do with the abusive behaviour of the majority of the M&A process. So let's foresee in this room, we have good intent and we ‑‑ this is even a topic in the GM later ‑‑ we need to have policy that allows as little abusive behaviour as possible, and I think you and I can all agree on that.
Having this in the document will basically fix that specific goal by basically rephrasing that still implying, you know, resource changes of holdership changes, once they happen, whether it's been an allocation from RIPE to a member, or a change because of a mergers and acquisition, or a transfer, it basically triggers the same transfer holding periods, which basically makes it more equal for everybody.
ELVIS VELEA: While I understand your point, initially you said that you are going to do editorial changes, basically moving bits and pieces from various documents into one document.
ERIK BAIS: Yes.
ELVIS VELEA: This is not an editorial change. This is a major change.
ERIK BAIS: It's a minor changed added to it, yes.
ELVIS VELEA: It's a major change, basically, from my point of view. I think a two‑year holding period to mergers and acquisitions as well and this must be highlighted ‑‑
ERIK BAIS: It is. It's not ‑‑ it's been, since version 1, it's been said, you know, it's here, I'm not trying to hide anything. And if, at some point, a company is bought for legitimate reasons and at some other point you know that same company is bought again by somebody else within the same two years, you know, keeping that LIR open for maybe six, seven months, more, you know, because this policy is limiting them, that's cost of business. There is nothing ‑‑ you know, and it avoids a lot of abusive behaviour within the policy. So, if you actually have a specific reason why you are opposing here, I would like to hear that.
ELVIS VELEA: Well, you gave one example but there are multiple business reasons why someone would like to take over a company and then at some point within the two‑year period maybe, or maybe later, would like to transfer some of the IP addresses either to a someone else, etc., etc.
ERIK BAIS: That's true. Like I said, that's cost of business. So ‑‑
ELVIS VELEA: That's why I'm I'm opposing it because it's not just an internal change it's ‑‑
SANDER STEFFANN: Elvis, I agree with you that we shouldn't sneak in changes like, and try to make it hidden somewhere. On the other hand, I think this has been explicitly stated and we are discussing it now, so I think the part of we're sneaking in a change is not applicable any more at this point in time. So let's discuss the content and not the originally it was only meant to be this. Let's discuss the proposal as it's on the table today.
ELVIS VELEA: Sure, and that's what I'm saying, I'm actually opposing to adding the two years holding period to mergers and acquisitions because I can see various reasons why this would create problems.
ERIK BAIS: Okay. Duly noted.
PETER KOCH: Peter Koch, DENIC. My towel is already on a chair at the beach of course. So, Remco was not alone, I had made some comments and asked for clarifications that I do not yet see addressed, I fail to find an updated version of the proposal and I still can't find it, so, maybe we can receive a pointer there.
My main concern was that, by changing the directions of the writing style, or the target audience, there were updates necessary to a variety of documents where documents get new time stamps and look like their current, they have out dated references, so everything needs to go through another editing process and that's more than just an editorial change. I haven't seen that happen yet. If you have done that, I'm just maybe too tired to find that thing and we can send a pointer ‑‑
ERIK BAIS: You mean in the old policy, like the IPv4 policy and the v6 policy where you'd like to see you know for transfer policy move here or move there or...
PETER KOCH: That's the suggestion that Remco actually made, and that I supported of course, but there were other references in those documents that are today outdated. We can live with outdated references in documents that have old timestamps, but if you republish the documents, these references need to be reviewed, otherwise it is not comprehensible for anybody new reading this why do we do references to outdated documents. And I don't really ‑‑ it was some weird RFC number that had been updated. This is just a minor issue that I'm not going to pinpoint, but the general thing is that it's more than just change a piece of text. Give it a new timestamp after five years and then you're done. There's more work needed. That's the point I raised.
ERIK BAIS: Okay.
SANDER STEFFANN: We will work with the NCC and make sure we update everything that we need to update. I agree, that would be bad if we publish old stuff.
ERIK BAIS: Okay. Anybody else? Any other questions? Then I would like to close off and say so long and thanks for all the fish.
(Applause)
SANDER STEFFANN: I have the feeling this is going to be a theme today...
GERT DOERING: I'm not really sure where we are with this proposal now. But definitely, some progress has been made and we need to get back to the list and sort it out.
Going to the next one, this is the big discussion of this year so far, the 2015‑05 Version 2 revision of the last /8 allocation criteria. I haven't seen Rod or Adianne here but the other proposer who is not on this slide, Riccardo, volunteered to give us an update. What the intention of the proposal was, where it got stuck, from my point of view, steering the process it basically divided the mailing list nicely in two camps. We need to be conservative and preserve v4 for new entrants in five, six, seven years' time. And the other camp that said, the simultaneously LIRs are feeling major pain today, they should be able to get more v4. And these to are basically so far apart that finding a common ground is really not possible. So, there is no consensus for this to go forward but still it's worth discussing the underlying idea later on and see which direction we want to go.
So what we do now is basically just present the proposal, not discuss the proposal as itself, just answer questions. Then we have another proposal by Remco van Mook, which is going in the other direction, tying down the policy, and then we do a joint discussion on what do we think the future IPv4 should be. So, Riccardo, please.
RICCARDO GORI: Good morning. I wasn't able to change the presenter name and date, maybe because of the party last night. So, my name is Riccardo Gori, and today is 25 May. I'm one of the authors of this proposal, exactly one of the two authors of Version 2 because version 1 was revised by another author.
What's this 2015‑05 aims to be? This proposal aimed to fix a competitive disadvantage of LIR born after the triggering of section 5.1 of IPv4 address allocation policy.
This caused new members, LIR with very small space available, see competitive disadvantage in the market. It aims to address the trend of end customers signing up as a new LIR, you see from the stats that signing up of new members is very high. This can even be because of when an end customer ask for a small space as a /24, some LIR cannot provide this space, and advises the customer to sign up as a new member. This policy didn't receive consensus. The main objection is that it will speed up the IPv4 depletion, clearly because the proposal allowed requesting an additional /22 every 18 months for every LIR present.
So this kind of objection, we tried to revise the proposal and we did a Version 2. The changes tried to slow down the potential fast depletion of the pool. The additional /22 can be only provided from other space outside the 185 /8. Only LIRs with less than a /20 are eligible for qualifying themselves to receive additional allocations. And LIRs must document their IPv6 deployment.
Well, I want to comment about this, that someone in the list commented that this is a misunderstanding of section 5.3 of current allocation criteria, but when we vote it, we voted to preserve the last /8 spirit. So, this space should be used to deploy IPv6, we are aware that new members are experiencing difficulties, and if you need more space to grow up, you can get this space, but, remember, you should deploy IPv6, so show me that you are doing something. That was the spirit we tried to put on the policy.
Even like this, we didn't reach enough consensus, as Gert said, we have two main objections on the list. New members, and you know that a new member, after 2012 grew to about 6,000, so we have many members on the list saying yes, we need more space to be competitive. And the difference from old LIR and current LIR is becoming consistent, so we see it. But the main objection doesn't change. This kind of policy will speed up the depletion of the pool. Someone say last /8 is working well like as is. And, well, if you really need the space, you can gather it on the market. So, that's the main point.
So, we are pretty stuck at this point. And we think at the current state cannot go on on this way, at least with this kind of policy, because it's not accepted, and we are awaiting decision from the Chairs, but maybe the policy can be withdrawn soon. So...
If you have any questions. That's it.
GERT DOERING: So, this is really about technical questions and not discussing the proposal. Even while you didn't reach the goal with the proposal, thanks anyway for actually taking up the effort, because policy making is only possible if somebody goes out and tries to change things that need changing. Sometimes it can not be changed. But it's worth trying. So, thanks to, that you actually did this.
RICCARDO GORI: Thank you very much.
GERT DOERING: So now we go to the next proposal, which is Remco. And then we go to the joint discussion. Erik...
ERIK BAIS: Before Riccardo actually leaves the stage. So, on Riccardo's policy, I would like to thank him for indeed the work that he has done. I hope he doesn't have too many personal knives in his back in this whole process. It was interesting to see how this whole process worked. And it was definitely an interesting exercise. So, again from me as well, thanks for the work.
GERT DOERING: Well, I think sort of a consequence of this discussion, Remco introduced a new one to totally lockdown 22s. The feedback so far on the mailing list was this is a bit complex. It has too many rules in it. And I'm pretty sure that the way it's written write now it's not going to have consensus, but let's see what the room has to say about it.
REMCO VAN MOOK: Who knows. Good morning everyone. It's good to see all of you wide awake and not hiding behind your laptops at all.
So, before anything else, thank you, Erik, for this lovely entertaining video, and if you are sick and tired of Address Policy after the break, there is also the connect Working Group in the other room that I will be chairing, so, if you want to hide behind your laptop in another room than this one, you are welcome to do it in the other room after the coffee break.
With that said, yes, locking down the final /8. And I don't necessarily completely agree that this was only based on the policy proposal that was written. It was also instigated by creative users of current allocation policy, which is parts of which will also be discussed during the General Meeting of RIPE NCC tonight. There's even a resolution that's going to be voted on. And here we are trying to fix this on the policy side.
So, keeping with the theme for today. Don't panic. But organise. I'm not going to touch the policy text because, as Gert already said, it's a bit of a complicated beast and I'm fully aware of that. And I didn't even want it to be complicated. But this is as uncomplicated as I could get it while still hitting all the bits and pieces that I wanted.
So the purpose of the policy is, first of all, to make very clear that the current allocation policy applies to all the address space held by the RIPE NCC and not just 185 /8. It wants to limit the one of final /22s to one per LIR regardless of how you got it. Which should close quite a few loopholes that people are currently using. And in order to shut the door completely, we are going to ban transfers of these final /22 allocations and to make sure that you don't touch those rules, there is a whole bunch of evil bits to enforce points 2 and 3. And here is the thing, the intention is not to enforce this whole thing retroactively, so if you have already have a bunch count yourself lucky, but if you do come back for more, you might end up disappointed.
So, a word from our sponsor, because we are in these commercial evil times.
Can we have a word from our sponsor please...
Well, I think our sponsor is now... the sponsor has I think used up all of our time by now. I don't want to bore you looking at some low quality piece of YouTube. I'll just go on with the rest of it. And you can look this up on YouTube, which is a website for videos, I have been told.
And you can look at cats as well there, it's quite interesting.
So, let's go back to why do we have this /22 again, where did that come from? Well, that's a community decision where the community decided on a one‑size‑fits‑nobody approach is ever going to end up in this space and everybody gets a small block that's not quite entirely unusable, but it's not very good for a lot of things. And that was going to be regardless of type and age and size of the organisation, whether you are a telco with 50 million customers or a start‑up or just even doing some virtual hosts, it doesn't matter. And it really was meant as part of a transition to IPv6.
The objection I got immediately about all of this is, but I'm acquiring companies. Apparently that's a very hot item, we're buying and selling companies like mad people these days, I didn't know from the looks of you. But, really, you get half a year from the moment you decide to merge LIRs. Yes, it's a pain, but life isn't fair for anyone else either. And the question really is, why should M&A make you an exception to the one‑size‑fits‑nobody rule? I mean, we have two sizes also fit nobody. So, why this proposal?
Current policy doesn't really distinguish these final /22s from any regular allocation, but I do think they are special, they are unique, you are only going to get one of them. And the second one is not clear that the current policy applies to all the address space.
The way I look at it is this final /22 is a compatible layer to access IPv4 in the Internet in a post‑depletion, post‑depletion Internet that runs on IPv6. And really, that's ‑‑ I mean, you could potentially use it for other things, but that's really what it's good for and that's probably the only thing it's really good for. You get 60 million ports out of a /22 if you want to do CGNAT. And the Internet just works better if as many networks as possible for as far into the future as possible get this compatible layer. And finally, people, this is 2016. We have actually half‑way through 2016 almost. If you are currently deploying a network architecture that depends on the availability of public IPv4 address space, you really deserve everything that's coming to you, including brokers.
So let me repeat that.
It's 2016. If your architecture depends on the availability of public IPv4 space, you deserve everything that's coming to you. Or else...
And that's it. Elvis has entered the building...
GERT DOERING: Thank you. Right now, only technical questions to the proposal. Not discussion yet. We return to the discussion thing right after. Elvis. Make it quick.
ELVIS VELEA: We talked about this yesterday, I think. There is a bug in your proposal. You say you don't want it to apply retroactively, but we discussed about it, and if someone has, at this moment, two /22 from the last /8, and any time in the future would like to receive more space through a transfer, merger, acquisition, whatever, they will have to give back one of them.
REMCO VAN MOOK: Thank you for pointing that out, but, I mean, that's a feature, isn't it lovely?
ELVIS VELEA: So if that feature bug can get fixed, you are saying that if you have multiple /22s then you're lucky, as long as you don't ‑‑
REMCO VAN MOOK: Touch them. Don't touch anything you'll be fine.
ELVIS VELEA: Well, don't touch them is okay, but don't touch anything in the future, that's ‑‑
REMCO VAN MOOK: Don't touch anything in the future, you'll be fine.
ELVIS VELEA: Well...
REMCO VAN MOOK: The way I look at it I consider it to be a feature. I can see how people are currently holding a bunch of of those 185 blocks would consider it a problem. But, really... so, I see your point. But, that's ‑‑ of all the things I'm willing to take out of this proposal, this would be pretty low on the list.
SANDER STEFFANN: And there's a way around it, if you want to merge in something that already has a 185 block, give the 185 block back before you merge it in.
ELVIS VELEA: Or keep both LIRs open.
GERT DOERING: We are full into discussion land. These are not questions about the proposal. Raymond, I think you're next, and then Erik.
RAYMOND JETTEN: Could you go back to your first large text slide. It says "Policy applies to all IPv4 space held by the RIPE NCC." Does that mean also all the special address spaces?
REMCO VAN MOOK: No, because the sentence continues with "all the space that's not been reserved for marked to be returned to IANA."
RAYMOND JETTEN: Sorry, no problem.
ERIK BAIS: First of all, I have to say, you know, this was a bold one to make. I had a smile when I read it first. There are some questions, I will go into the discussion later. Specifically, how do you envision the new status? I have read something about allocation final status to be added to the long list of already current colours of IPv4 and IPv6. Can you provide insight into why yet another status that is unique to the RIPE region, and will this also have, as we're talking about status, have an impact on legacy space as legacy space ‑‑ will this have an impact there as well? I don't think so, but I would like to hear so.
REMCO VAN MOOK: As far as I can see, and as far as I have had feedback from the RIPE NCC as well, nobody has mentioned any impact on legacy space and I can't really see how this would have any impact on legacy space, and yes, I agree, we really have like seven or eight different categories for space, which is weird because they are all integers, but, yes, I do ‑‑ I did feel that the separate status was necessary especially to mark it out as something that's very visibly different from anything that's transferrable. Because if it stands out in the databases, this stuff you can transfer, it also removes the point of trying to sell it, and if somebody wants to sell it to you, you know, it's tainted. You know, you might end up in trouble. And ‑‑ so it specifically marks this address space as something that's different from all the pre‑depletion allocations. But that's really the goal is to flag it. Buys buys okay. Last question. Are you in the job market currently?
REMCO VAN MOOK: I couldn't possibly comment. But, I mean, do you really think this is helping me getting a new job? Don't answer that...
RICCARDO GORI: I oppose this proposal because I think it highlights the difference between old LIRs and new members, but I think also there's a big bug inside the proposal. It looks to me like the proposal has been thought first place not in use, because I don't get how if I acquire a company that is using, as example three /22, assigned to customers to return the address space. That address space is in use and assigned to customers.
REMCO VAN MOOK: So, I click forward to answer this slide because this is the way I look at that final /22. If you just do customer assignments out of it, that's fine as long as your customers are using it for v6 transitions, bits and pieces and if they are doing it it should be trivial for them to go to some other piece of address space to do that translation layer. This is the afterlife. You are getting a bit of address space for, as a compatible layer. If you just make assignments out of it so people can keep living in v4 land, as much as I appreciate the commercial pressure, especially on new LIRs to do so, I don't think that's very wise.
RICCARDO GORI: I don't think this is applicable in real life, because there is plenty of countries where cannot adopt IPv6 for some reason or in other countries, you must do that retention because if you use IPv6, IPv4 to deploy IPv6 and you use, it CGNAT Carrier‑Grade NAT, you need retention, and there's many LIRs cannot do that. So assign ‑‑
SANDER STEFFANN: Before we continue this part of the discussion, we're actually now going to the general discussion about which direction to move in, it feels. From the people at the microphone, can you raise your hand if you're specifically targeting your question towards Remco for this.
REMCO VAN MOOK: A technical question.
SANDER STEFFANN: So let's do those first.
HANS PETTER HOLEN: Not speaking with my RIPE Chair on but with my hat on, we're in the software business, somebody thinks, but really we're acquiring companies. We did 16 companies last year, so I want to understand what does this merger thing do? What restrictions are you doing when we acquire a new company that has address space? What restriction are you putting on that address space?
REMCO VAN MOOK: The only restriction that is putting on adding address space is any of the address space that has been allocated to the LIRs who acquired, that is one of the final /8, /22s, so address space that was issued by RIPE NCC after some date in September 2012. That will ‑‑ everything before then, all the other address space, all the allocated PA stuff before then, everything outside of 185, I don't want to touch.
HANS PETTER HOLEN: That's understood. But then I acquire a company which has orange block from this and after this new policy, and then I acquire a second company and a third company that has the same thing, so then I'm sitting with three of these assignments. What happens then?
GERT DOERING: You return two of them.
REMCO VAN MOOK: If you return two of them you decide which one to keep. There's absolutely nothing I think that I could write in policy that would stop people from doing so.
HANS PETTER HOLEN: So the policy ‑‑ this proposal doesn't do anything to me, in practice?
REMCO VAN MOOK: As long as you keep all the LIRs around, fine.
ELVIS VELEA: I really like how you have several hats and with one hat you do something and with the other hat ‑‑
GERT DOERING: Is this discussion or a question to the proposal?
ELVIS VELEA: It's a question to the proposal. So with one hat you are saying return all the /22s unless you keep the LIRs open and with the other hat you say we used to have an idea that blocking creation of multiple LIRs will fix something but now we're asking you not to block that, so allow that. So you're basically saying you're allowed to get as many /22s as you want as long as you keep one LIR open for each, which is not a fix.
REMCO VAN MOOK: I'm not sure whether this is a question for this proposal for for the General Meeting, to be honest with you.
ELVIS VELEA: It's for you who acts in both with different hats.
SANDER STEFFANN: Hats don't matter here. This is about content.
REMCO VAN MOOK: Thank you.
GERT DOERING: The general discussion starts when there's a slide about general discussion on it, and if you keep discussing while Remco is on stage, we night never reach that.
AUDIENCE SPEAKER: That's why I'm asking.
REMCO VAN MOOK: I'm willing to stand up here for a while if that helps people.
ALEX BAND: I think it's very confusing about what we're supposed to discuss or not, but I'd like to pick up where Hans Petter left off. Over the last few years, we did about 150 acquisitions. At this stage, I don't know how many last /8 /22s we have. I'm fine with keeping the LIRs open, but we're doing various levels of mergers and integrations with these companies and some of these companies don't exist any more or have their names changed and it turns out I can't easily change the name on an LIR in these cases. I can keep them over under the old name, we'd end up with a registry which contains incorrect data. How do you plan to address that?
REMCO VAN MOOK: So, as much as I appreciate your problem, I don't think that's a particular problem for this policy proposal. But it's more a procedure issue with the RIPE NCC, so I suggest you talk to the nice people behind the desks in the hallways, and I'm sure they'll have coffee and accommodation for you. And if they don't, I'm sure that the RIPE NCC Executive Board wants to hear about that. But, I also still don't see how that relates to this policy proposal. Thank you.
GERT DOERING: Okay. Thank you so far. You stay here.
So, the timing didn't go as I planned. So, as I said before two software competing proposals on the table. We can, of course, select bits and pieces from each of them, but we need to find a way forward. One way would be just give up on this and say, well, the process is geared towards being conservative, so if cannot agree on anything, nothing changes. The other option is decide consciously to go to what more restrictive of things, the direction Remco's proposal is going in, the other one is consciously decide to give out more v4 right now and help newcomers today sacrificing newcomers in three years. This is what we need to keep in mind.
SANDER STEFFANN: For people making notes, it actually says 2015‑04, that should be 2015‑05, so if you are making notes or discussing this on the mailing list, please use 05.
GERT DOERING: Sorry. Some other ideas that have been mentioned in the big discussion on the list that actually what we want is to make LIRs go to v6 and not discuss v4. But that seems to be sort of hard. Riccardo's proposal focuses on new LIRs, but the pain level at some point is you do all you can on v6, but all the content or all the other ISPs have enough v4 and don't bother to do v6, so what you do is sort of like only half of what needs to be done. So can we reach out to the other LIRs that should be doing v6 but have enough v4 space, so whatever we do in policy land is not interesting to them because they are not coming back anyway.
Another idea that was voiced was restrict the last /8 to renew entrants. So if you have space, where it came from, you are not eligible to a /22. Right now you are unless you have a /22. And, of course, the topic of reclaiming v4 space from those figure fat old LIRs that are not making good use of it came up. But this is actually complicated because cannot do it. There is nothing in our v4 policies that says if you have an allocation and don't use it, you have to give it back. I think Marco analysed all our policy sets a couple of years ago, and tried to find whether there is anything anywhere, and it isn't. Because the allocation policy always assumed up and to the right graphs. So ISPs either grow, grow, grow, grow, or they die. But they never level out and have unused space. So the policy framework that these addresses had been handed out under, have no clauses for taking them back. And if we try to retroactively change policy for existing blocks, go out out to LIRs and grab the addresses, I think that will put us in deep problems.
Anyway, we are totally out of time now, so I just steal ten minutes of your coffee break and try to get a bit of discussion on future directions going. We have more time in the second slot, but Remco has to go and run another Working Group. Whoever did that scheduling, needs to do better. He gets away...
So let's do a quick discussion on future directions, where do we want to go? And then get back to the mailing list and make it more specific then.
BENEDIKT STOCKEBRAND: Just to make sure we're not drifting off into a discussion where we shouldn't. Just one thing you said that apparently it's completely lost pretty much all the time. The last /8 is for transitions to IPv6 and it should be. So, any policy that comes from the address space Working Group should actually be aimed at promoting or whatever, to switch towards IPv6 because everything else is just going to make the situation worse. And I have a feeling that for a number of reasons that gets frequently forgotten here in these discussions. Just to keep that in mind. This is where we should go. And if people use the last /8 address space for doing whatever, but not for transitions and then show up and say I need some more through whatever means or what, that's... well, it's pretty much their problem and I don't see we have any reason to actually cater for them at everybody else's expense.
GERT DOERING: So your approach basically is to work on our outreach, make this more clear. We old timers all know what the intent was but it's not really written down anywhere. So make it more clear, do more outreach here.
BENEDIKT STOCKEBRAND: I just wanted to remind for the discussion that this is actually what was intended and what we should actually do, because it's one of those far reaching goals that you frequently forget in these immediate problem level discussions.
ANNA WILSON: Anna Wilson, HEAnet. This is triggered by the talk earlier of Remco's policy and giving back /22s. Something that's come up in a lot of policies lately in the last few years, and I do feel quite strongly about, is that if, in a time of scarcity, we try to use the database as a means to police how people use their IP addresses, we end up with a less accurate database, we can quibble about how less accurate but it will be less accurate and I'm afraid when I talk about where I would like to see these policy proposals going, my first priority in this room is always going to be we need a more accurate database.
My second priority will come down to I think the blocks we have should last as long as possible, but the first priority is more important.
AUDIENCE SPEAKER: Yes, hello, proposer of 2015‑05. Well, my point is that the fact there is a need for IPv4 and not IPv6, there is big business to be done with IPv4 and not by selling blocks being a broker, by selling connectivity with IPv4, not v6. V6 doesn't selling. So, I don't find that the current policy states that we should use the last /22 as a migration, as a means of migration to IPv6, it's not stated in the policy.
SANDER STEFFANN: I can tell you how that happened. When the time when this policy was made, we consciously decided not to limit it to whatever people want to do with it, and we said if people ruin it and use it for the wrong purposes, that's their own problem. So that was the wording we used when this policy was made.
AUDIENCE SPEAKER: Which is what is happening mainly. Second, we are not in a such a restrained situation. We have almost one /8 left and if we are going to a proposal like Remco's one, we'll lock‑out about 1.6 /8s, which is huge. We already have the most restricting policy concerning the distribution of IPv4 and we want to make it even more restrictive. Is it reasonable ‑‑ we saw even AfriNIC which has the biggest pool of remaining IPv4, even they have a more, let's say more lacks policy in distributing IPv4, and no ARIN did not run out.
SANDER STEFFANN: So ‑‑
REMCO VAN MOOK: I follow the comment, but with your last remark I'm just say I'm not going to comment.
SANDER STEFFANN: You say that a /8 is a lot. In 2012, when we reached runout, we were using a /8 per month, so, a /8 isn't that much.
AUDIENCE SPEAKER: Depends on point of view.
GERT DOERING: I think Erik is next.
ERIK BAIS: I want to have a quick comment on Radu, I'm not sure where you're getting your data, but you're wrong. It's puzzling to me. The intent for the policy as it is currently was very clear. You know, it's been stated repeatedly, and I know you can circle back on this, but we're out. Having a /8, although it might seem a lot, it's not. You know, if you give half of the room here the opportunity to actually fulfil their allocations request by RIPE, we will be out before coffee break is over. Now, this is not an issue. Your view on this is so wrong I cannot even begin to describe it. The policy that we have currently is for new entrants. Period. Not for current businesses that already have some piece of the pie, however small that is. For the rest, there are various brokers if you need more because you didn't use the space where it was intended to be used for and provided to you. I have no sympathy. That is where it is. Back to stage. How I like to keep things in the discussion, I think the restrictive policy from Remco has interesting topics. However, I don't think it will come to a workable solution. Although, I feel the sympathy of moving towards that. Going even further, you know, from the current process into where Remco's policy is, I see from various reactions in the room, from Hans Petter, from Alex Le Heux, and others, that there might be things that are unworkable in the solution that Remco's proposes, and by that, I don't think that it will actually gain enough momentum to actually get in there. Also the fact, the other option, you know, going back to 2015‑05, that is also not an option. Having the options here is either, you know, clear it out, you know, give it back to IANA, that's a fourth option, because we don't care, and there is the option of keeping things as we are, as they are because we actually need to provide for our children, and our children being the students currently that have a start‑up in two years, three years, five years, that want to bring up the new Snapchats, Twitter, Twitch, whatever, they need some as well. We need to be good, you know, citizenship in this and actually provide them with an actual opportunity to do something in the next couple of years, because we're not there yet with v6, yes we should go there, but we're not there yet. And we need to provide for the future.
SANDER STEFFANN: Thanks for your statements. You seem to have brought support. I would like to close the microphone queues at this point because we're really running into the coffee break, so, if everybody can please keep their statements short.
AUDIENCE SPEAKER: Hi. Elvis. One of the initial proposals of 2015‑05, I worked with Radu on the first version and when I realised it will never fly I decided to withdraw. Radu got someone else to work with him. His decision, but I already knew one year ago this will not fly and there's no point in continuing. I really do not agree with the way Remco came up with his proposal, or not the way he came up with it, but I really don't agree with his proposal, he's put there some things that are really, really weird and impossible to be verified by the RIPE NCC, or checked, or imposed, or whatever. The only way this will work especially seeing the e‑mail from the board yesterday asking us to refer the decision to allow multiple LIRs per company tonight, the only way this will work is keeping things as they are. One way or the other. Both are not going to fly. And of course, if we do keep things as they are, we will end up running out within a year. Not five. Because we will see at least a handful of people that have registered dozens of LIRs in November last year coming back and registering hundreds. So, we will run out really quickly regardless of what happens if we do vote tonight as the board is asking us to do.
SANDER STEFFANN: Let's leave the voting for NCC Services and the board and focus on the policy here. I think your statement was stay with the current policy.
ELVIS VELEA: Stay with the current policy ‑‑
GERT DOERING: Since you brought up the topic, this is actually touching on database accuracy, so the reason that Nigel explained in the mailing mail, if they try to disallow, or we as the members, multiple LIRs per company, those people that we try to stop will then just set up lots of shell companies with different names. So, the original mission was not achieved and the database accuracy sucks. So this is the reason behind. Not that the board likes people opening multiple LIRs, but they like a good database. So... okay, I think Nurani is first and then Jim. You sort it out.
AUDIENCE SPEAKER: Nurani Nimpuno from NetNod. I'll start off by mentioning Snapchat because I think that's what gave Erik applause as well so that makes me look hip and with it.
On a more serious note, I think ‑‑ I agree with the previous statements, I think we're a little bit ‑‑ we need to be a little bit careful actually about talking about more restrictive of loose. We have run out. So whatever policy we come up with now is not about how generous we want to be. And it's also not about how fair we could have been if we had more addresses. At this point, like could he pointed out, we are giving out addresses to help people transition to IPv6 and we need to keep that in mind. And we need to do it in a workable way. I have got similar concerns to Erik's about Remco's proposal, but in some ways, I'm actually leaning more towards Remco's proposal not because we can preserve the existing ‑‑ the increasingly shrinking address pool of v4, but simply to manage it in a responsible way to allow new entrants into the market so that they can again can transition into IPv6. And I think the things we need to consider is about how do we manage that in a responsible way, in a workable way and in an accurate way. It's not about how generous or not we want to be.
So, I think in general, I'm actually leaning towards keeping things the way they are. Having said that, I just want to say that I think that this is a healthy discussion to have even if we end up staying with the current policy and we're going to have several of these discussions again and again and that doesn't mean that we don't progress, it just means that we have thought hard about how we manage the end of the address pool. So thanks.
JIM REID: Representing nobody but myself. I don't run any networks, I don't assign IP addresses to any paying customers, so I clearly don't know what I'm talking about. I think what people have to do here is I would hope that the authors of both of these proposals withdraw them and we can stop any further discussion of it because it's quite clear that neither of them is actually going to reach any kind of consensus in the Working Group and I think there's no point really continuing. It's worthwhile to have a discussion but a discussion around the idea we can somehow coalesce around one or other of these policy proposals is ultimately doomed and I would hope this Working Group could see the sense that have and just say let's withdraw these proposals, sit down, have a little holiday for a while, have a little drink and come back to this once we have all calmed down and thought a bit more about it. My personal inclination is, I'm more in favour towards accepting the proposal that Remco has got in some senses. I think there's some issues at the margins of that but really I think all we really can do at this stage is perhaps tweak some of the language in the existing policy document, to clarify some things where there's a little bit of ambiguity. For example, some people seem to think that 185 /8 is the only thing that the /22 policy applies to. It applies to all of the NCC's address resouces. I think we should maybe clarify that. Likewise, some people in the room are talking about using the /22s to assist in the transition to v6. That's what they should use it for but it's not mandatory and what people choose to use that address space is entirely up to them. Sander has already made that point the maybe we need to do a bit of tweaking of the language here but I wouldn't want to go any further in terms of saying maybe we should do stuff about what an LIR can or can't do after a transfer or some kind of merger or acquisition, because ultimately what we're doing is rearranging the deck chairs on the Titanic and we have got better things to do with our time.
RANDY BUSH: I think I'm entitled to comment on the intent of the policy that's current in place, known as the /8, last /8 policy, due to the fact I proposed it and APNIC before. It's not to promote IPv6. That's not to say we shouldn't promote IPv6. It's that new entrants may come into the game, whether they choose to use IPv4 NAT, IPv6 or whatever, it's that they can enter. Okay. While I am a proponent of IPv6, my company deployed it commercially in 1997, okay, I don't want to mix this. And I think one of the problems with all of the proposals we're doing is we're doing big proposals that solve 19 problems at the same time. Any proposal which attempts to solve the fact that we're running out of IPv4, I think, is a fantasy. Any proposal which tries to change human behaviour is a fantasy. A proposal which takes a specific point and tries to deal with it, is simple enough to judge. We have the problem of phony LIRs. Can there be something simple which ‑‑ pardon the pun ‑‑ addresses that problem. I think that's the one real problem we have here. The details of what happens if I merge two companies, etc., come on, who cares? But the real problem with people intentionally ripping off our grandchildren, I'm sorry, I am old enough, I'm no longer worried about my children, is ‑‑ you know, that's, I think, the only thing we really need to address.
SANDER STEFFANN: So, I think the point of the multiple LIR thing is something that's going to be discussed in NCC Services or General Meeting, so, we should wait until that discussion is finished. I'd like to summarise it. I think what I heard was people leaning towards Remco's proposal but see too many potential problems, so, staying where we are now seems to be the most likely outcome. We should encourage people to deploy v6 but not put it in policy and not mandate it like Randy said, it's the LIR's choice what they do with their addresses. So, I think that ‑‑ if I got it right, that sums up a bit what we have discussed now. Anybody thinks I missed something?
GERT DOERING: And with that said, I thank you for actually going with us running 20 minutes over the coffee break. That discussion might not have led anywhere, but it was important to have I think. So, thank you very much for being here all the time. Enjoy your coffee now and we continue at say five minutes past eleven.
SANDER STEFFANN: Anybody that needs help with all this difficult v6 stuff, there are towels being handed out with some helpful information.
Coffee break
