Address Policy Working Group
26 October 2016
10 a.m.

GERT DÖRING: Good morning dear Working Group. The slide machinery is sort of stuck, it used to work five minutes ago but right now it's refusing to give you my slides. So we'll just tell you what's on there. It says good morning, this is the Address Policy Working Group. We are in nice Madrid. It's 10 a.m.. these are your chairs for the Working Group. Sander Steffann and Gert Döring, and looking in the room, I see a lot of people being addressed in Address Policy and you know who the chairs are anyway.

For this session, we actually have recruited add deputy co‑chair, Jan, has volunteered to help with the discussion organising because in this room setup, you need more eyes to keep track on who wants to say something to be real fair.

So, to present the agenda I actually need to present the agenda.

This is the plan for the first slot, some administrative matters first.

Current policy topics overview from Marco, the usual presentation to explain what happened in the last six months worldwide. A few words on mailing list etiquette from Sander. Then we will go into a quick round of discussion or just recap of the Open Policy proposals currently in the system. And then we have something from Nick Hilliard about supermarket check‑outs, airline hand‑luggage, etc.

In the second slot we have the traditional item feedback from the NCC registration services presented by Andrea. I have allocated lots of time for that because he brought quite a number of points that we might want to discuss.

Then we have a presentation from Erik about the end of IPv4 and whether this should lead to restructuring this particular Working Group.

Also quite a bit of time set aside to that.

And then Open Policy hour and AOB in case something else should show up.

So, agenda bashing. Did I miss anything? Did I produce conflicts? Do you want to see anything changed? I cannot see very much with the light, but I can see that nobody is jumping up.

I can see enough to see that there's no hand waving, so, I'll just leave the agenda as published.

Of those you that have been here yesterday and Monday have heard this before. This room setup is different from the usual rooms we have, meaning that cannot really ask questions while the presentation is going on because the presenter will not see you and the microphones are not live.

After the presentation, when we call up for discussion or questions, the room light will be turned on and you have to raise your hand and the chairs will try to keep track, that's Sander me and Jan, who is wanting to speak and then we will basically point at you and then you can turn on the microphone, that's the right most button on the console before you. If you press the button while somebody else is speaking, you are cutting them off, which is considered impolite, so as Jan said on Monday, if you do that, you will be required to state your name and affiliation and apologise to the person you cut off, and Jan is a man of authority, so if you do not follow proper microphone etiquette and are generally impolite, he might ask you to leave the room.

I know you are a very polite crowd so this is just an empty threat but it's still there.

The minutes from the last meeting have been posted to the list. The RIPE NCC did a tremendous job on the minutes. And then they, as usually, sat eight weeks in my mailbox waiting for me to review them. So all the delays are my fault, all the quality is their good doing. I have not received any comments on the list, so unless somebody has to correct something now, I will just declare them final. So any comments on the minutes?

No, good. So, the minutes from Copenhagen are now final.

Current policy topics. So, Marco. I don't think I need to introduce him really into this group but anyway Marco is the good soul at the RIPE NCC to gets to do all the paperwork for the policy proposals we mess up. So thanks Marco for doing this and bringing us information.

MARCO SCHMIDT: Good morning everyone. My name is Marco Schmidt, and I'm really happy to present you this little update, especially to all of you that made it so early in this room after yesterday's social. And I hope that you will find this presentation interesting.

As usual, I will start with a little overview of what's going on in the other regions, then I will give a very brief summary what has happened in our region since the last RIPE meeting, and I will talk of a little policy development office update. But first let's have a look at what is discussed elsewhere in the world. This time I want to do something a bit different because normally I just present this presentation for you for your information, but today actually I want to also ask for your feedback about one proposal in particular that is right now discussed at the AfriNIC community. It's called an Inbound Transfer Policy, so it's an inter‑RIR transfer policy, and basically it would allow that IPv4, IPv6 and ASN numbers can be transferred into the AfriNIC region. But this proposal doesn't allow any outgoing transfers, so no transfers can be leaving AfriNIC. And we have been asked if this proposed policy text would be compatible with our Inter‑RIR Transfer Policy, and, yes, it would.

So, then why I am bringing this up at this audience? Because, considering the AfriNIC community, they might have some good reasons to be a bit protective for the resources but looking at it a bit from the RIPE community and looking at the spirit of all the transfer policies that we have discussed over the last years, then it was always the spirit wherever resources are needed they can move to wherever ‑‑ I'm sorry, wherever resources are not needed any more they can move to wherever resources are needed. And, this of course doesn't work so fine in the case that there's only a one way road to AfriNIC, so whenever resources are not needed any more in AfriNIC, they cannot move anywhere else, not even inside the region because there is no transfer policy.

So, is this an issue for you or is this simply a non‑issue? If you have an opinion about it you have basically three options. First one is you can go to the AfriNIC mailing list and state your opinion there.

Secondly is at the end of my presentation, you have the opportunity to give your feedback, and the AfriNIC meeting will be in around four weeks and by then, we have RIPE NCC stuff going over there and they will be happy to present your feedback to the AfriNIC community then.

And the last option would be especially if this audience would consider this might be an issue, to have a look at our Inter‑RIR Transfer Policy if there is any adjustment needed.

So, I will let you think about this and come back to it at the end of my presentation. And in the meantime, let's have a look what else is under discussion in the AfriNIC region.

They have more transfer policies. The first one is number resource transfer policy. It's under discussion since quite a while and it's a bit stuck actually. It would allow IPv4 transfers inside AfriNIC region and also in and outside to other RIRs. And then there's the second one, IPv4 resource transfer within the AfriNIC region and the title actually explains itself, and these proposals also will be discussed in four weeks at the next AfriNIC meeting.

AfriNIC is also discussing adjustments to their IPv4 soft landing policy, and they actually have two proposals right now, and although they have very similar names they try to an achieve something quite opposite. One of them wants to remove a lot of restrictions so they want to just go deletion its natural way and only reserve a small pool for new companies. While the other proposal wants to be more restrictive to just allow smaller allocations once the AfriNIC has reached the threshold of a final /8.

And AfriNIC is also discussing a special policy about audits that would mandate AfriNIC company to audit their members about actual address utilisation of their Internet resources.

Moving on to APNIC, they had their meeting in Columbo a few weeks ago, and one proposal was discussed there and has not reached consensus yet. It would disallow the transfer of IPv4 space from the final /8 block. So something similar like our proposal 2016‑03. And they are also discussing a proposal about how select and elect a Working Group Chair for their policy Working Group, the SIG.

Going to north America to the ARIN region. As usual they are discussing, or they hav0e discussed quite a lot of policy proposals, their meeting just took place last week and a lot of these proposals are related to transfers mainly to ease transfers. And the results of these discussions are not published yet but I mentioned here some proposals that have done quite well so the consensus for these proposals it likely. The first one is modify section 8.4, inter‑RIR transfers for specified recipients. Because right now in ARIN, if an organisation receives any IPv4 resource, it allows 12 months, it can not do any transfer to another region of any other resource that they might hold as long as 12 months have not passed, and this proposal wants to remove this restriction.

The next one on the list is 2016‑1. It's a reserved pool transfer policy. ARIN has some specific pools for IPv4 pools, for example, for IPv6 deployment, and this proposal suggests to don't allow transfers of this specific IPv4 address space.

Then we have proposal 2016‑2. That wants to change the time frames in the ARIN policy manual. Because right now when you look at the ARIN policy manual, you can see time frame three months, 12 months, 24 months, and this proposal wants to align all these to 24 months.

The last one on this list related to transfers is policy 2016‑4, and it's called transfer for new entrants. Because right now in the ARIN region if you want to qualify for receiving a transfer, you must show that you have got at least a /24 assignment from an upstream provider and that is getting more and more difficult especially for new parties entering the market. That's why this proposal aims to remove this restriction.

ARIN also is discussing IPv6, there is one proposal called eliminate HD ratio from the policy manual. And this might sound more dramatic than it actually is because right now already there is only one mentioning of the HD re‑issue left in the ARIN policy manual for some very specific assignments, so‑called community assignments. And if this proposal will reach consensus also from there, this term will be removed.

And this brings me to the last but not least region, LACNIC. They had their meeting also a few weeks ago in Costa Rica and one proposal has reached consensus there, it's called IPv4 reserve pool for critical Internet infrastructure in the region. Has reached consensus and now LACNIC has created a pool for infrastructure such as IXPs that will be available also after the run‑out of the normal IPv4 pool.

And another proposal is still under discussion to remove the reference of multihomed and non‑multihomed from their policies.

LACNIC is also discussing IPv6. They have right now two proposals with identical name and almost identical content. It's about to modify the size of the initial IPv6 allocation, it wants to introduce new criteria under which large IPv6 allocations can be justified. Quite similar to our IPv6 allocation policy where you can justify large allocations for criteria such as hire key or security. The only difference between these two proposals is the second one, 2016‑7 has a wider scope what kind of organisations could request larger IPv6 allocations under this policy.

So this was a little bit of global overview. Now very briefly what's going on, or what has happened in our region since the last RIPE meeting in Copenhagen.

We have, right now, three policies under discussion. I don't need to say anything about them because all of them will be discussed later in the session.

And since May 2016, three proposals have been withdrawn. First one is 2015‑05, the revision of the last /8 allocation criteria. You might remember this because it was discussed in this Working Group that would have given the chance for LIRs to request additional IPv4 /22s.

The second one was discussed in the Anti‑Abuse Working Group and would have introduced mandatory abuse contacts for legacy resources but it has been withdrawn.

The same goes for the last proposal on this list the resource authentication key code for third party authentication, which was discussed at the other Working Group.

This Linx me to my last section, a little update from the policy development office, because I always try to update you a little bit. What we do to raise the awareness and also to ease the participation, and if you follow the recent mailing list discussion it was quite active again. So for this year so far already, more than 1,000 posts have been received at the Address Policy mailing list, from more than 140 participants coming from 30 countries, and there is also a link on this slide that links to our web page because now they also update regularly this information about participation. And on this page you also can find this map that shows from which countries actually the people are coming, so, the darker the colour is, the more people from the country participate. So you see Spain there is some participation about you it could be a little bit more, but overall if you look at Europe there is a quite nice distribution of participants, but, however, we could need a little bit more people joining discussions from countries from central Asia or from the Middle East.

Then we have something just applied recently to our policy proposal page. It's a third tab called Discussion Summary. Because usually at the end of each phase the Working Group Chair sends out an e‑mail to the mailing list summarising what was discussed in this phase. And in order to help latecomers to a discussion to catch up, we have now this tab where this e‑mail basically is shown, is posted, and also with a link to it so that they don't have to look up in the mailing list archive.

And also quite recently we have deployed a new tool that allows an easy differentiation between different versions of the same policy proposal. So if a proposal has now at least two versions you can see this little icon beside the versions and if you click on it you will see something like this, that will show you what has changed, what has been added, what has been removed, what has been change and if you have any questions about it or feedback to this quite new tool, we are happy to take this into account.

Another not so new tool any more, it's active since the last RIPE meeting is the so‑called RIPE Forum. It's basically a web‑based interface to all the mailing lists, to all the Working Group mailing lists, and so you can go on your browser, you can see all the discussions in the different Working Groups, like in the a forum view, so you don't need any inbox, and if you put a post there, it will create an e‑mail and vice versa, any e‑mail will create a post in this forum view. So if you are interested, just go to our main page, you will see the screen banner there and click on it and have a look yourself.

And this brings me to my last slide. So if you download my presentation you will find these links that are hopefully are useful to the policy proposals, the overview, to the map that I have just shown you and also to the RIPE Forum and also I included my Twitter account so if you want to get the latest policy updates not just for our region but also globally, I am always happy for some new followers.

And that's the end of my presentation. I am happy to take any questions and also as I mentioned before, if you have any feedback for the AfriNIC Inter‑RIR Transfer Policy proposal, just that's your moment.

SPEAKER: Alexander. A single question. You brought the map of participation. Is this active participation or just mailing list subscriptions?

MARCO SCHMIDT: No, this is active participation, so it's really the people that have sent an e‑mail to a policy discussion.

SPEAKER: Steve Nash, just to say thank you for those changes to the website. That looks useful

GERT DÖRING: I actually want to second that. It's useful. People have told me that they like the feature, and thanks.

AUDIENCE SPEAKER: About the AfriNIC discussion, am I right to assume that they have not come into sort of the runout of IPv4?

MARCO SCHMIDT: That's correct. If I remember, it's right now around 1.5/8 left.

AUDIENCE SPEAKER: So that might explain why they want to protect their own space a bit. But I think that from the RIPE sort of point of view, we should aim for symmetry when it comes to transfers, that's just my point.

GERT DÖRING: One of the comments I have actually received on the computer while you were speaking were also along the lines of he could understand why AfriNIC doesn't want to open the outbound flood gates, so, there is understandable reasoning behind that.

MARCO SCHMIDT: That's actually enough, because I just want to bring it up to this audience and if there's full understanding, then it's probably good for us to bring up to the AfriNIC meeting in about four weeks.

Then, thank you very much.


SANDER STEFFANN: Hi. I don't want to spend too much time on this, but I do want to make some comments. We have seen some really bad behaviour on the mailing list recently, language that is completely unacceptable, but also, like, bad discussions on the topics that are on the table. Gert already commented on the mailing list about getting proper subject lines in the e‑mails, making it possible for us as chairs to actually summarise up all the discussions, all those things, and we really, really need to do better here. Like I said, the language that was used is completely unacceptable, so we will not accept that. Period.

Please, make sure that if you discuss something, you come up with good arguments, you are open also to the other person's point of view, and really try to be constructive here. We need to work together to get good policy proposals.

So, like I said, I'm not going to spend too much time on this but I thought it really should be mentioned that as a Working Group, we really need to improve here and I please ask your cooperation for that. Thank you.


GERT DÖRING: Thanks Sander.
At the last meeting, we totally overran both sessions, because, basically we spent lots of time discussing. Being here being able to discuss is valuable, but spending our time here to rehash discussions that have been done on the mailing list and continue on the mailing list afterwards is actually not the best possible way to spend the time.

So, while we usually discuss the policy proposals that are open, for this meeting I have decided to only do Q&A on them, so, when we go to the proposals, the presenters will present and then we do Q&A, but we will not go back and forth and back and forth and back and forward for half an hour and then overrun to the coffee break again. Because basically that's unfair to you, taking away your socialising time in the coffee break. And since the decisions are made based on the discussion on the mailing list, the feedback in the room is basically just to give the proposer an idea where the journey would go. But for these proposals, we already have good feedback, so this is really more about clarification.

Anyway, we do accept questions; in that case the usual etiquette holds, so state your name and affiliation, speak to the microphone, you all know that anyway.

So now we go to the oldest one in our list, 2015‑04, that's the transfer policy document unification plus cleanup from Erik. Erik is there. I hand the microphone to him.

ERIK BAIS: Morning all. So, as Gert already stated, we are going to do this policy, I think it's the fourth time I am actually standing here in front of you, specifically for this policy. The end is in sight, so, we'll get through this.

My name is Erik Bais, current policy is after the impact analysis, we're at version 4, last version had some specific changes specifically, not so much about the policy text itself, but it was more, you know, where were references being put in the old document, where text was basically removed and put in this document. So that was incorporated, you know, we did quite some work on that, Marco and I, it's been interesting, and I think it's a very clear and concise document at this point.

So, this is for people that missed the whole discussion on the policy. Basically what we're trying to do is get all transfer‑related text out of the other documents, because basically we were all over the place. You know, it was hard to find where specific information could be found on specifically transfers, so this policy document does now have all the transfer text in it. But, also, you know, what the limitations are and what we're doing. Basically the idea of the whole process was to make things easier to find for people that are new in this community.

So, on the mailing list itself, there was quite some discussion on the actual goal. You know, that things were not mentioned specifically in the goal itself, but were in the policy, and that was already, you know, the case, you know, from version 1 specifically the version questions about the MNA, was it included? It's not. Those kind of things. The whole discussion was done in length on the mailing list. You know, I also stated, as of version 1, what the actual changes were with the document itself besides the actual changes of, you know, combining everything to one document. But this was, you know, discussed at length already.

So where we are currently? We are basically in this phase, and during the RIPE meeting, the actual end of the phase will actually pass, and then it's up to the Chairs to decide was there enough consensus, and then go to last call.

Any questions?

GERT DÖRING: So, thank you for summarising where we are with this. As I said we're not going to discuss the merits of the proposal, just questions and answers if anything is unclear.

AUDIENCE SPEAKER: Peter Koch, I have one question because I reread the document recently and there's the IPv6, the general IPv6 policy document, if you look at it in the acknowledgements, it looks like it has been a document that was originated elsewhere and almost like in a globally synchronised manner. Would the changes that we are about to apply here affect the symmetry or equality of these policies in any way and should that be of concern?

GERT DÖRING: I think that's an artifact. That needs cleanup. So, the very original IPv6 policy of about 20 years ago was a global ‑‑ well, it was a synchronised document that all the RIRs started their policy work on. Since then, all the RIRs have changed incompatible ways anyway. So the fact that it still says this is the global thing is an artifact and maybe one day somebody should just clean up the text. But these changes will not synchronise ‑‑ will not be propagated elsewhere.

PETER KOCH: I understand that. But if ‑‑ well, maybe during the editing phase you get that remark clarified in the end and then next time I won't be confused.

GERT DÖRING: Point taken.

MARCO SCHMIDT: Perhaps a show of hands, to see how people feel about it? Do you want to do that now? Not?

So, for ‑‑ can we have a show of hands for people that actually read the document or read the policy or... to see what it actually...

Okay. And would you agree on moving forward to the next phase after this, how would you feel about, a show of hands for yes? Okay. Thanks.

Any other questions?

GERT DÖRING: So I think we're done with that for today. We have to take it back to the list anyway, and I will go through the comments on the list and see if we have sort of like sufficient voices one way or the other on the topic, and call for more comments.

MARCO SCHMIDT: I think the ‑‑ yeah, let's do that, but I think the majority of the questions that were asked are either answered by myself, Sander picked up a couple as well, so it looks very good from what I see.

GERT DÖRING: It was lots of comments and I admit I have not read everything of it yet.

MARCO SCHMIDT: It was a bit much, yes... all right. Thanks.

GERT DÖRING: So we need to go through it and summarise it and see. Thank you.


So, 2016‑3 is the next one on our list, it's in revision 3 right now and what my slide says is that there was a heated discussion in the discussion phase and people have accused me on taking sides because I permitted it to go to review phase.

Well, technically that's a decision of the proposer. So now I get accused of having other proposals being sort of like not promoted to the review phase. Anyway, sometimes this is really, really difficult for the chairs to decide. The PDP says that the decision is made by the proposer together with the Working Group Chairs. So, sometimes the Working Group Chairs think this will not go anywhere. Sometimes we are undecided. In this case I was very undecided and the proposer said I want this to go forward. I understand that for review, it needs much stronger support, so please move it forward and put that note into the summary, which what I did. And here is the proposer to comment on it. Thanks Remco.

REMCO VAN MOOK: Good morning everyone. My name is Remco van Mook. It's not on the slide but I guess most of you have seen me by now. We're going to talk about a brief update on 2016‑03, we are now at version 3 of the policy text. Previously on this show, we had a version 1. Version 1 was pretty severe when it came to the restrictions they were going to apply in the final /8 space. Not as severe as possible but as severe as somewhat practical, but it was pretty clear early on that that text was not going to achieve consensus.

So we moved to Version 2, which removed most of those restrictions from the proposed policy, but still in some limitations in there. That went to the review phase. Posted and excellent summary on the mailing list, it's also available now on the website as was pointed out and as a result of that, version 3 and the Impact Analysis done by the RIPE NCC was posted last Wednesday, and since then we have seen around 90 e‑mails on the list within that thread.

So, changes between Version 2 and 3. It's mostly formatting and clarifications. I have changed a couple of the pieces of text to bullet lists or numbered lists to make it more readable or clarified. And I have changed the definition of allocated final to align better with allocated PA to prevent confusion from what piece of text mean in there.

The Impact Analysis itself. You can see Marco's e‑mail, it's also on the website. The impact on policy and of the policy on registry and addressing is small. Impact on operations and services. The NCC commented that they would need extra effort to educate LIRs on using suballocations to prevent a drop in registration quality. And the implementation part of it was assessed as medium impact.

New concerns raised since the Impact Analysis was published on Wednesday:
This is a very incomplete summary. Some of the points I picked up. Nick Hilliard had some very useful comments. He is sympathetic to the idea of a proposed policy won't fix the issue. That's exactly right. There is ‑‑ or you could potentially write a policy proposal that will fix the issue in its entirety. The chances of that one ever reaching consensus are probably below zero. He says the proposed policy just moves to speculation around to entire companies instead of just allocations.

And he is afraid that unregistered transfers will increase and reduce the registry quality.

Elvis had a few comments. One of them was that it creates yet another colour of IP addresses, which I see, I mean I wrote that. It's... I think if you want to do something that looks anywhere near this policy or putting any restrictions on a particular block of address space, then basically there is no other option than to create another colour. I would personally use the analogy of, I'm using, I am adding a bit of smell to these addresses, to make them less commercially viable because they smell funny.

And what else do we have? So, as from last week, I actually got a few voices of support for this proposal, which I'm very happy with, so thank you for whoever did those. And more sadly and that's already been commented on, I have seen probably the storiest collection of bow that I have ever laid my eyes on. I have seen ad‑home attacks, there is implications of interference from the RIPE NCC, Godwin's law been envoked. If you are going to stream it, please be creative. Don't use Hitler. That's just tired. Claims of introducing second class citizens, chairs being accused of having hidden agendas. It was pretty ugly.

So here im. As Gert said, today we're just going to do Q&A. Please don't remit the same argument over and over again, it doesn't make it more valid.

Let's hear it. Any feedback, questions?

GERT DÖRING: Thanks for the excellent summary. This was useful. Let's start.

ELVIS VELEA: So you did mention a few, you mentioned one of mine. I suppose that's also because I repeated some of Nick's concerns as well. Can you go back one slide? The concerns.

Okay. Do you think you have addressed any of these?

REMCO VAN MOOK: I haven't answered yet.

ELVIS VELEA: In previous commercials because some them are just repeating.

REMCO VAN MOOK: Some of them are definitely repetitive, and as Gert brought in his summary, all of the open issues from the previous phase that he considered more or less addressed, with one or two open ones if I recall correctly, Gert doesn't remember what he wrote, so ‑‑ it was a long e‑mail, to his credit. So, I mean if there are open issues then we'll need to resolve those during this phase of discussion.

ELVIS VELEA: One more thing was the last comment I had was you said it was a claim that the RIPE NCC Board's participation in this policy proposal. I actually tried to clarify it, or explain it that the NCC has, right now, a third of new members that have come since 2012 onwards, and I have talked to a few of them, I can claim, I haven't been able to talk to all of them but I have talked to dozens and dozens. All these new members do not understand what hats mean or how what is it when someone wears different hats. So all of these new members do see this proposal as coming from RIPE board member. While I used to work at the NCC, I know that the NCC was not supposed to interfere with, or comment, unless asked, about policies. I think it would be a good idea if the Board or members wouldn't do that either, because it does give the members, mostly to those that are not very educated or understand the PDP so well, the idea that the board is pushing this forward.

REMCO VAN MOOK: Okay. Can I ‑‑ so, I'm sorry, chairs, I'm going to be slightly blunt here. To me, that comes across as cutting off any board member, as experienced as they may be, in terms of policy development, from having any comments or any initiative whatsoever. The board, as the PDP well describes, or actually doesn't describe at all, the board has zero, and I have to stress, zero role or position in policy development. As such, I have no special way of moving stuff because I am a board member, whatever the hell that means. So, are you just trying to cut me out?

ELVIS VELEA: I don't think that's possible. However, what I'm saying is I think you should understand that the NCC members, especially the new ones, or especially the ones that are very, very not ‑‑ that do not understand how the PDP works, will see this as coming from the board and not from you as a person.

REMCO VAN MOOK: So in that case, sorry for interrupting you, but in that case I would suggest in your conversations, that you point them to the PDP and say start reading before you come to conclusions.

SANDER STEFFANN: I want to make a short comment here. We have board members that are Working Group chairs, we have board members that participate in this community, board members are just as much a part of this community as anybody else. They don't have any special powers. I see no problem at all with a board member proposing a policy because it's us as a community that needs to get consensus on it.

GERT DÖRING: I think that's an important point actually to stress that the board doesn't decide on policy. Anyone can propose a policy proposal, but unless you accept it, it will not go anywhere. And, yes, you are right, we need to work on the outreach to new members to explain better how the PDP works. I have no spontaneous idea how to tackle that, but maybe we can sit together with Marco and do a bit of brainstorming. So educating you new members ‑‑ well basically, Address Policy Working Group is not members stuff. So whether or not they are members or not has no influence on whether they have a voice here, so everybody has a voice. But, still, I can see the point that if you have not ‑‑ didn't have any contact with the RIPE circles so far you join to get addresses and all of a sudden you are being asked to contribute to policy, you might need a primer how to do that. And this is maybe something communication PDO can find something about it. Let's see. Thank you.

JAN ZORZ: There is a queue. Please, the gentleman here and then it's Benedikt.

AUDIENCE SPEAKER: Hi. Tim Armstrong, representing more than one new member as it happens and I have to completely disagree with you. I think there's a number of people that do understand and are choosing not to, for their own benefit, and trying to make a land grab even though they are late to the party. Because, a lot of us have read stuff and do know how it works. Thanks.

AUDIENCE SPEAKER: Benedikt Stockebrand. I think when it comes to the members of the board getting active in whatever and people working for NCC, that's quite a difference, because as I understand the board is doing this on a volunteer basis, whereas people working for NCC are doing this to make a living. So, I think that's a huge difference that you should keep in mind. So, if anybody, any member from the board or even anybody from the NCC, whereas there's no potential for conflict of interests, I actually quite welcome people getting involved who actually are really deeply involved with all these things going on.

REMCO VAN MOOK: Thank you for that Benedikt. I mean, yes, board members and Working Group Chairs do this entirely on a volunteer basis. What that says about our sanity I'm not going to go into.

ELVIS VELEA: It was just based on this discussion, the fact that also it's been quite crazy the past couple of years with all the changes that are being made on this last bit of addresses that the NCC can still allocate. So, putting together the decision of the board of stopping to allow multiple /22s, that then was reverted by a vote of membership. And also the fact that right now, if this would ever become a policy, it would actually indicate that you are allowed to get /22s, the board even recommends to get ‑‑ recommended the membership to allow this to happen in order for an individual or a company or a group of companies to not just go ahead and set up shell companies here and there and have loads of votes. But after allowing this, after recommending the membership to allow this, now we're coming to a point where a board member in his own personal capacity actually wants to tell these members okay, you can get them, but from here on for each registry that you open, you'll have to keep it opened as longs you need those addresses and if you would ever want to consolidate those into one membership, that's no longer going to be possible. You are going to be forced to keep, 10, 20, that's what the policy will say.

REMCO VAN MOOK: I was unaware that we have already crept to the General Meeting because I don't think that starts until 7 o'clock tonight. Am I wrong? So you are very much confusing a decision by the board basically where there is no good answers, where the board says ‑‑ basically what the board said, which you carefully left out of your summary, is the only way to fix this is through policy. And here we are.

AUDIENCE SPEAKER: Nurani Nimpuno. First of all, I think this discussion about the board members, it's a distraction. Can we please just focus on the issue at hand. There are a lot of people who don't understand the offside rule in football, that doesn't mean that we should take that on. If people want to understand, they can come and talk to me during the break.

I think it was a good effort to actually put forward this proposal. I think that ‑‑ I actually think that up until very recently we have had a good discussion. It went a bit crazy on the mailing list and let's maybe ignore that and move on with our lives. I think... I agree with Nick Hilliard's analysis and some of the concerns he raised, so I think they are very valid points. And apart from that I think I have said my piece, but I think even if this proposal doesn't go forward, it was good to have this discussion, we needed to have this discussion. Maybe we need to have it again in five years time or maybe this is the last we'll speak of it, but that's part of the process, right? So thanks for bringing it up. If ‑‑ I am not sure if it has enough support to go forward. But, I think we learned something along the way, so...

SPEAKER: Marco Schmidt, RIPE NCC, Policy Development Officer. I just want to respond to the comment from the Elvis and make an official statement that the proposer, Remco van Mook, has exactly received the same treatment and support as any other proposer gets from the RIPE NCC.

REMCO VAN MOOK: Thank you.

AUDIENCE SPEAKER: Riccardo, I will focus on the ‑‑ I see a couple of problems in this policy, and so the question is, the question is, how do you handle the problem of splitting companies? If I have a business partner I will split my company, he will ask some space back and I couldn't handle this request, because we have business splitting and the other problem is if I am sharing space with a downstream app, in case it's up as a new LIR, I cannot give him space, and he can give him back this new space acquired just for not numbering their network. And this is a simple business example, but happening, so this policy will forbid this.

REMCO VAN MOOK: Yes, I mean if you are going to split up a /22, then I mean you are going to end up in trouble anyway. And yes, that would have been feasible. But if you decide, you and your business partner decide to split up and that business partner wants to keep running an LIR, they need to open a new LIR anyway.

So, I mean, I kind of see your point. I don't think that's fixable. I mean, to an ex extent the same thing happens with PA space except for the fact you can do suballocations within PA to sort of fix that.

ERIK BAIS: So I agree with Nurani on basically the same as with Nick. I see issues in what's going to happen and where we are actually going to shift into. I think that's the biggest concern that I have on this. That being said, you know, this is... it's... I think the policy actually opens a whole can of worms as we have it currently, because ‑‑ and that's probably one of the biggest issues that I see with it. The room is so divided, if I look on you know the new members and people trying to protect the land grab, as you know, the word came up earlier, it is interesting to see the intention with the policy, and I know how difficult it is, but this policy will, from how I see it, not solve, or get consensus on where we need to go. It's good to have the discussion. But you know, I don't see it landing in consensus. Specifically because it will have two opposite sides from the spectrum here and... so, that is basically where, we cannot fix the one end and please one side or because we have, you know, two teams left and right and, you know, the policy in itself does doesn't combine here I think.

REMCO VAN MOOK: Okay. So, I guess one of the reasons why I have gone through this effort is because even though the actual policy text may not have changed for the final /8, what's happening right, now no longer aligns with the intentions that came with that particular policy proposal. So, in that sense, the policy has changed without this group ever making a decision about it, ever having a discussion about it. And that is something that I wanted to fix. And in all honesty, I have one more slide. I am abandoning this policy effectively right now, and that's not because of a lack of consensus, because that's up to these lovely gentlemen in front to decide, but I am embarrassed by the "Discussion" and essentially how it's damaging our community's reputation. I hope nobody ever reads that mail archive from last week. I hope we can outsource the management of that e‑mail archive to Hillary Clinton. I have no idea. I hope it gets burned, to be honest with you. This is damaging for our reputation. The whole community, the whole bottom‑up policy process making is based on having a meaningful respectable discussion, and that's not what I have seen.

So I'm dropping it. And if anyone wants to pick it up from here, be my guest, but I do think that before anyone could do anything with final /8 in any way, shape or form we are going to have to talk about process first. And that's the end of my show.


GERT DÖRING: Actually, we need to thank Remco first before wrapping up. Well, it was not a very pleasant discussion, and I can fully understand you. Since we do not have an active proposer, unless somebody steps up and picks up the shards, we consider this abandoned, and it's not an Open Policy any more. Marco will go through the mechanics of this. But anyway, it was a problematic thing, we knew that from the beginning, and... we have a presentation from Erik actually on the way we want to do policy in the next slot, so, maybe we can improve. Thank you anyway.

SANDER STEFFANN: What really disappoints me about the whole thing is, we are working towards consensus here, we have to work together, and in the last years maybe, especially since we have run out of v4, the discussion sometimes seem more focused on blogging stuff and making the process impossible than actually finding solutions and I think this is really disappointing.

JAN ZORZ: And thank you to everybody that we managed to keep this part of the conversation civil. Thank you.

GERT DÖRING: We actually do have a new proposal, and it's actually IPv6 related, so that is the future.

Our PI policy was always targeted at end users and not ISPs, the full intention of the policy was to ensure that it's not used to provide ISP services like stuff. So it has the clause about no subassignments in there, which came up here once and then again, and we always decided that yeah, well it's the way it is. But the NCC interpretation of that has always been very, very strict, because since the document doesn't give the NCC leeway, the NCC isn't taking leeway and the only way they can have reproduceable results is by being very precise and that is no subassignments, not anything, which actually leads to the interesting effect of not permitting people to get PI to run public Wi‑Fi because giving a single address on a public Wi‑Fi by whatever DHCP to somebody can be considered an assignment if you are really, really strict about it. So, Maximilian ran into this and decided to not argue and haggle with registration services but just fix the policy instead and I hope the remote participation thingy is working because he cannot be here. Do you have good news for me tech support?

RASVAN OPREA: We are going to try to have Max on screen, and we want to have, we will also hear him as well. He will be able to hear you if you press the microphone.

GERT DÖRING: Good morning Max.

MAXIMILLIAN WILHELM: Good morning. So, you should see some slides. Thanks for the introduction. As it's relevant to last RIPE, I had ‑‑

And I want to clarify the policy about that.

So, people want to deploy IPv6 PI, we have seen that. I want to do it myself. Some already have PI space for IPv4. Some don't. Some want to start working off IPv6. Usually today you get some, I guess the word is public Wifi services or whatever, or you have VPN, point‑to‑point link with your officers within these they obviously work... probably the PI space. By means of slack and privacy extensions or even maybe statistically within the VPNs and that seems to be a problem for some people or some interpretation.

The contractual requirements from the PI holders state that no sub assignments be given to third parties. Some people within the RIPE NCC interpret this as /128 is a sub‑assignment and therefore IPv6 PI space is declined. I don't think that is a valid interpretation, and I propose to add the following sentence to RIPE 655, the IPv6 address allocation and assignment policy, so to clarify that a sub‑assignment in the context of the other ‑‑ is a prefix of /64 or shorter. So, cannot sub assign or delegate a prefix, but a simple address which is signed by a slack or anything to a device is okay.

Why would you do that? So to close room for interpretation and give guidance to the RIPE NCC, I hope Marco will comment on that later on.

I think that a /64 is a meaningful prefix length to achieve that. As new delegations will no longer approve it's unusually anway ‑‑ so what should the customer do with the /8, something like that. It will resolve some current policy violations, that have been people given PI space under the current policy. Some not. That maybe would help to deploy this v6 thing in the world, and we save some address space, so some organisation is happy to get only a /48, why would you have to reserve a complete /29 for them when they have to become an LIR. IPv6 space is huge but it's not infinite so we have a thing about saving address.

Why not? People could come to delegate a /8 to their customers, but who would really want to do that to people paying their money? I would not buy such a product. I hope this will not happen. Some people might use it increase in global routing table size. So for every PI space we give out one more entry. The alternative is someone that's part of the PA space, so at least we have 2 entries, an aggregate for the whole PA and sub‑assignment to the one getting the PA sub‑assignment. And maybe even some more routes for traffic engineering purposes or something. No win here. The potential PI space user is a registered LIR, we have at least that one entry, so basically it's the same difference, we're not getting worse or better.

So that's not really opposing argument.

What has been done so far. The proposal is published on the 21st, last week. There are some supporters. Other people wrote some questions why an arbitrary limit to the /64? Seemed to be the simplest way to close room for interpretation and it seems to be a good number or simple way to fix the problem. And there have been questions asked what the RIPE NCC say about that? And I'd like to give the mike to Marco to answer that question.

GERT DÖRING: Thank you so far. The people in the room can see me but you can't. I'm hiding. Anyway, thanks for the proposal, and the good summary of the status quo. We are a bit shorter on time than I had hoped for because the previous proposal took overall five minutes too much time. I think one of the really important bits I want to have here very clear is the statement from the RIS department on how the current policy is interpreted and why. Because part of the discussion on the list was, the NCC is interpreting this all wrong and we don't need this policy proposal because the policy is fine. So, Andrea.

AUDIENCE SPEAKER: Hello everyone, Andrea Cima, RIPE NCC. Our interpretation of this policy is that when we look at the policy text, the text is quite explicit about the limitations of the PI assignments and it mentions that PI assignments cannot be further assigned to other organisations, that is how very strictly, as you mentioned before, we interpret this. There is a difference between the IPv6 policy and the IPv4 policy for PI, because in IPv4, there was an exception being made. Where the policy text was mentioning that IP addresses used for the customers connectivity could be considered as part of the provider's infrastructure and this exception is not there in the IPv6 policy text. That is why we interpret the policy in the way we do it.

What I wanted to add as well is that the issue that Maxamilian has encountered when they are requesting his resources is an issue that many other organisations haven encountered before. So this is not an unique situation. It's not the first time that it happens. And we have, for this reason, brought this issue up also twice in our feedback session at past RIPE meetings and we think that this policy proposal, as it is today, could have a positive effect on those requests that so far we had to deny

GERT DÖRING: Thank you very much for that very detailed answer. It gives the necessary background I think. And just give the microphones to...

SANDER STEFFANN: I'd like to, activate an institutional memory for the Working Group here, because this subject has come up before, specifically the bit about the connection to the customer explicitly not being allowed for v6, because at the time we saw this was being abused in v4, so, at that point it was consciously decided that this should not be part of the v6 policy. It has been brought up at previous meetings and I'm guessing this must have been like five years ago, and at that point, it was decided that the strict interpretation of the NCC was the correct one. So, please don't blame the NCC. We as a Working Group have actually told them that this is what we wanted, so, I think it's good that we are having this discussion, and giving clear guidelines here to the NCC.

JAN ZORZ: Okay, it's Jordi, Elvis and Erik.

AUDIENCE SPEAKER: Hi. I was the author of this policy text, so, when I was writing this text, I was reading section 2.6 of the rest of the policy which says that: "To assign means to delegate address space to an ISP or end user for a specific use within the Internet infrastructure they operate." So according to my interpretation, and this is why I didn't specify anything else in the existing text, was a device, an end user device is not infrastructure, okay. Because if we interpret a device infrastructure, that means that a company having an IPv6 PI assignment could not offer service to employees, because they are using their server forms and their infrastructure, okay. So, I think that the right way is to clarify section 2.6, not the text in the PI proposal, okay.

JAN ZORZ: We are one minute over. So I am closing the queue. Please be fairly quick, Elvis.

AUDIENCE SPEAKER: Elvis Velea. I think this is not a fixer to the problem but more an attempt to hide the problem under the carpet. While we have attempted to fix the problems with PI with a PA/PI policy proposal a few years ago that proposal was so complex that the community did not agree with all those things. I think the part that we need to fix is the part where we ‑‑ the part in the policy which forbids some assignments from the /48 PI at this multihome. Otherwise we might end up with /22s or /8s. I know we need to make baby steps. I understand with baby steps we will end up the some point in the future with the vision I had about a the v6 policy I had a few years ago, no difference between PI and PA. You are asking who could delegate the /8 to the customers? The same ISP or company that was using PI or is using NAT or CGNAT right now. The customers may not even know or care about this. So after voicing all of these concerns I still understand that nothing has been done to fix the problem over the past more than five years. There have been a lot of organisations that have been affected by the current implementation of the IPv6 policy. So, I support this change, although I think we should do something better.

ERIK BAIS: I actually wrote a lengthy e‑mail on the mailing list about this, and although I understand where Maximilian is coming from, I agree with Jordi, and you know, this is a question about what is an assignment, and handing out IP space on DHCP or for Wi‑Fi for usage, those kind of things, is definitely not an assignment and I think in that respect the NCC's interpretation in this is incorrect. And from there on, if that is the line of thinking, the policy in itself is redundant and not needed, although I can see other use cases. But that's where I see it.

GERT DÖRING: Okay. I am going to wrap up. Because we have another presentation coming, and we have already stolen five minutes.

What I am hearing here and on the list is that the general idea of using IPv6 PI in the way Max wants to do is something everybody is actually perfectly fine with, that we just have disagreement on the specific wording of the change to be the consequences of that and whether it's needed at all, but I'm hearing the NCC who tells me it's needed. So, I think we will see a new policy text that takes all this into account, but we have good support to actually move ahead with this.

Maximilian, sorry for cutting you short a bit. Thanks for taking the effort with the remote participation and everything, and thanks to the opes guys to actually make this happen. I know it's quite a bit of effort for you. Thank you all.


So, we have Nick Hilliard here who is going to talk about queue theory I think, and without further ado, I'll hand the microphone to him and the slides.

NICK HILLIARD: So, now for something completely different. We have had some pretty heavy technical discussions, so, actually I want to talk to you guys about something a little bit different, which is my minor obsession with supermarkets. They are absolutely fascinating places from quite a number of of different points of view, but you know, stacking shelves, how things are presented, how you are shoved through them. But what I want to talk to you today about is queues and check outs and that sort of thing. And this is a typical supermarket queue here. You can see that the supermarket is prioritising its time as being an awful lot more valuable than your time and the result is that we end up in a queue at check‑outs quite regularly. We're all familiar with the situation, you buy your stuff, you put it into your basket, and then you are presented with a choice. And the choice is, well, do you have to go to the self check‑out or do you go to one of the main check‑outs and have somebody do it for you? There's one thing that's guaranteed and that is that the choice that you make is going to be the wrong choice because somebody else is always going to get there faster than you are.

It's really annoying. Even on the self check‑outs, you know there is kind of you know probably five or ten people ahead of you, you look at the queue next door, you think well, you know, what's going to happen there? Maybe I should jump queues and it never works out. It's actually been proved, or demonstrated from a practical point of view that as a mechanism, it doesn't really work terribly well, which is kind of peculiar.

Like many people, I also came to Madrid by plane. I flew on a well‑known business‑class carrier. This isn't the plane that I was on, but it was coloured very like the plane that I was on. This is not the sort of colouring that you want to see early in the morning, but hey, this happens. And again, there is a kind of an issue here that airlines, what they want to do is they want to have planes flying in the air, and they ‑‑ and passengers want to get from A to B as quickly as possible. So it's really rather silly to have a situation where you have got somebody, you see that person just up at the top of the queue, she is actually blocking everybody else from coming in and that's really annoying. And it happens so regularly that you are trying to load up an airline, somebody stands at row 3 and as a result nobody else can get on the plane. There's huge queues are forming out the back.

And it's very annoying for everybody. It's very annoying for passengers, because they kind of get stuck on the airline lift, it's annoying for the airlines because their airlines aren't flying, but yet we do it because even organisations like Ryanair, they actually give you the ability to buy this, okay. And this is a really peculiar thing if you think about it.

And of course really what both of these systems are is they are queueing mechanisms. Now, we actually understand queueing mechanisms really very well. There's been an awful lot of theoretical work done on queueing mechanisms, mostly started off by airlines in the Copenhagen telephone exchange, very well understood mathematically. And we can actually optimise queueing mechanisms to have different outcomes depending on what we're trying to do. And the really curious thing about these two samples that I have just given you is that neither airlines nor supermarkets use optimal queue. The optimal queue that you'd really like is for everybody to be serviced as fast as possible, but they don't do that. Okay. And this is really weird. Why? The reason is very simple. And that is that consumer perception doesn't actually match reality. It doesn't match reality because consumers are not given the choice, and if they were given the choice, they will choose something which is less good and which will perform with less good characteristics than a choice imposed on them by somebody else who has actually sat down and thought about how all of these things work. Which leads to the statement that: Choice is more important than technocracy.

What does all of this have to do with Address Policy? It's really very simple. And that is that at some date in the future, I don't know exactly when, we're going to have an end to IPv4 in the RIPE IPv4 free pool. There's going to be no IPv4 addresses and that's going to be the end of it. But there is still going to be people there who are going to want IPv4. Now, that would actually be simple and straightforward enough, but it's not that simple. And the reason it's not that simple is because we're going to end up having refills from IANA. There is going to be redistribution of IP addresses, there may not be very many IP addresses but they will happen. And not only will they happen, they are going to happen multiple times.

And each time this happens, we are going to have a queue forming, and what we need to do is we need to have a little think about how to handle this queue. Because, demand is going to exceed supply. There's going to be a small amount of IP address spaces available regardless of what the community wants, a queue is therefore going to happen. We can't avoid this queue. And what we need to do is we need to have a think about this, because we have two options here: Either we can come to some consensus about what sort of queue mechanism we want to deploy, or the RIPE NCC is going to have to make a decision. There are no other options here. If we don't do something, the RIPE NCC is going to do something for us. And having looked at how airlines and how supermarkets handle this, the RIPE NCC is a great organisation, they are a technocracy, and I think if they make a decision, it will be a decision which optimizes things but it will take the decision out of our hands and that will attract criticism in the future and I think from that point of view, we probably need to think about what's going to work for us.

So, there are a couple of different things we need to think about. The first is, whether we want a first come first served basis queue or a priority based queue and that's really a question, if you want to turn this question around, do we want to have first come first served or do we want to have the ability for some people to be able to skip the queue? Probably we don't really want to have people skipping queues because that's generally considered to be pretty obnoxious. Certainly I rage about this in supermarkets, and fortunately I still have a full set of front teeth, which is testament to the fact that if I rage, I rage politely. Do queue positions expire? If you get onto the queue, do you fall off the queue at some stage? And this is also a really subtle question, because actually if you look at a router buffering, you have queues there but you don't have infintiely long queues. It turns out if you start cutting into that queue and taking members out of that queue or putting a maximum limit on the queue, that's a very sensible thing to do. But that's a very technocratic approach to the problem and I suspect it's a problem ‑‑ it's an approach that's going to cause an awful lot of disgruntlement.

The issue is, do we want to have any discussion about this now? We're a few minutes over time. Does anybody want to take any questions? It's really a very simple issue, we need to think about these three issues. We have a couple of hands appearing, one or two hands.

JAN ZORZ: We have four. I think Geoff first ‑‑

AUDIENCE SPEAKER: Just to put this in a bit of perspective, we had a discussion with IANA, and they have provided us numbers on the amount of address space that is going to be allocated to the Regional Internet Registries. And for example, in March 2017, the expected date is a /19; September 2017 will be only a /20 and the last allocation will be in March 2019, which would be a /23 so the amount of address space, I mean the charter seems a bit off if you compare it with the amount of address space we are going to get back. At least March 2019 would be the last allocation of a 23, and the expected pool if we look at the current /22 pool would last for another four years, so that is just to put it in perspective and then it's up to the audience to take any conclusions out of that.

SANDER STEFFANN: I think at some points we are also having LIRs closing down and other addresses returning so we need to think of something.

AUDIENCE SPEAKER: Let me say very quickly. This is Geoff have APNIC. I have done some modelling of this, the last /8 will last you approximately four and a half years at the current run rate. You are looking at an exhaustion point at approximately early to mid‑2021. Andrew is right. The current rate of the recovered pool, the recovered pool is going to disappear long before that. Whatever queue you might have is not going to happen because of the issues you have described here. There is a certain amount of of return and recycling going on. The real issue for you is to whether you want to think about this today or if you want to think about it it in four and a half years time or sometime in the middle. It doesn't seem to me you have a burning issue right here and now insofar as the recovered pool will have disappeared long before your last /8. As I said there are other residual returns. By 2019 we will all be running IPv6.

NICK HILLIARD: Thanks Geoff. You are completely correct. We have several years to think about this. And I think that the current unseemly haste in trying to scramble the last remains out of of the existing IPv4 pool shows that we need to do something before we get to a crunch phase. Not a burning issue but we do need to deal with it.

ELVIS VELEA: I am going to try to make this as quick as possible. We do need a queue for whatever will be continuously returned to the NCC for whatever reasons or for whatever IP addresses the NCC will receive from closing LIRs, from whoever, so we do need a queue. Can you go back to the slide for a second where we have the three questions? I wanted to answer to the three questions as well. I think first in and first ought.

SANDER STEFFANN: Please take that to the mailing list. That's too much for now.

AUDIENCE SPEAKER: I just want to make a really quick comment. I think it should be first‑come first‑served, SLS some concerning that a presentation yesterday about some IXPs has some financial difficulties and they would be considered a key infrastructure in various ‑‑ the part of which they are located, so I think ‑‑ should get the parity out of the normal commercialized, I suppose in general I support the idea of first‑come first‑served.

GERT DÖRING: Okay. I just cut off Jan as well so I'm cutting off everybody.

JAN ZORZ: I have a request to make. It's very hard to keep the queue so if you are sitting in the back, after the break, if you think you might want to talk, please sit here in front. Cannot possibly see people in the back and their hands and we're sorry for that, but if you want to speak please sit somewhere here. Thank you.

GERT DÖRING: Good point. Anyway, thanks for ‑‑ sorry for stealing your coffee time.

Thanks, Nick, for bringing up this. I have made a decision how to move forward with this. We have lots of discussion after the coffee break, so I think we will not have proper time to appreciate this after the coffee break, so, we just take the points you brought up today. I put a task on the NCC to come up with a proposed approach how to tackle this on the next meeting. Since we are at least one year away of the crash. I don't believe Geoff's numbers. Having a proposed implementation on the table next meeting and then the Working Group can say yeah, this is good, you make it happen, or we want to have something specifically. I think that should be the way forward, or maybe have it on the list before... you choose how it works out for you. Thank you. Thank you, see you back in half an hour.

(Coffee break)