Archives

Address Policy Working Group
5 November 2014
9 a.m.


CHAIR: Good morning dear Working Group, and now you are awake. This used to be the Address Policy Working Group, since we have no more addresses, it has become the no more addresses Working Group since a couple of meetings, and that joke is getting a bit old in the teeth. So I think I'm not repeating it again. So welcome to the Address Policy Working Group.

We are the two chairmen. Sander Stefan, Gert Döring, most of you in the room, those who actually bothered to be here at 9 a.m. after a LINX party are regulars and know us, so, not much more introduction needed. I am glad you made it, it was a good party and I'm sure half of the meeting will only show up at lunch today.

This is our agenda for the first time slot today. Some administrative stuff. Well, one of the big topics for this meeting in all the Working Groups will be the Working Group Chair selection election process. Sander will explain more on that, and present our ideas and so on. Then we have the traditional overview about current policy topics worldwide from Marco, which used to be the first thing on the agenda, but I decided that the Working Group Chair procedure fell off the agenda last time, so I put it first this time to make sure we cover it.

Then we have some feedback from the NCC registration services about things they see in the daily business dealing with customer requests and answering questions about why is this and why is that. After that we entered the discussion of open policy proposals that are formally in the PDP. In the first time slot, I intend to cover these two, 2014‑03 and‑04 which have been in the system for a while so the discussions shouldn't be that long.

The second time slot starting at 11, will have more policy proposals. Actually this is the meeting with the most policy proposals on our agenda ever, because the shoulds and musts came in with five different proposals. On the other hand, those are mostly word changes, so the discussions about the wording shouldn't be that long. And then we have two new ones about IPv6 and AS transfers.

That's pretty much the agenda. The formal item is something that is missing, something that needs to be shuffled around to avoid clashes with other Working Groups. I don't see anybody speak up, so this is the agenda we are going to follow.

Administrative stuff:
Minutes, the minutes from the RIPE meeting in Warsaw have been sent to the list a few weeks ago. As usual, the NCC did a tremendous job in creating the minutes well on time and then they were sitting three months in my ‑‑ I need to read this queue, so apologies for the late delivery, that was me and not them and thanks a lot to the NCC for really good quality minutes, thank you.

Is there anything in the minutes that is not right? So, I see nobody come up to the microphone. I have to ask the question even if nobody ever stands up, so, by this I declare the minutes final. They have been on the mailing list anyway, so if there is something grossly inaccurate, usually somebody speaks up on the list.

So, Working Group Chair collection procedure.

There is the rumour, I'm not exactly sure where it's coming from, that I intend to step down as a Working Group Chair and I'm not. But, the whole process on how Working Group Chairs get their job and if they want to get rid of their job, how to do that, should we ever want that. It's fully undocumented, so, it used to happen by acclimation, back in the day Sander asked what is that you have to do as a Working Group Chair, and that was enough to just recruit him. Oh, you volunteered. Thank you. And in the light of transparency, all the Working Group Chairs decided that we want to have this better documented and well, since we are the first on the agenda this time, we start with it. Off to Sander.

SANDER STEFFANN: So, well, like Gert said, I was sitting in Amsterdam, asked fill it's was sitting in front of me, that was when Hans Petter was stepping down as a Chair, I said what's a Working Group Chair do and I she said Hans Petter I found your replacement. At that point I got drawn into the process and still enjoying it. This is not the way we should do things.

As a Working Group Chairs collective, we realised that once you select a Chair, they could remain there forever, and there is actually a big barrier for new people to become a Chair, because you know, you already have chairs, they are never stepping down, so, there's no position to fill.

We have seen a case where the Working Group was really unhappy with the Chair, and it got so bad that it was actually brought up and the Chair was removed. But you know, there is a really big barrier to actually, before you deal stand up and say we want this person gone. I mean usually you don't do that.

So, there has to be a nicer way of actually making sure that there is opportunities for new people to join in, there's a way of ‑‑ to get rid of the people that are not doing a good job. And there's also the point that for me at least, I stepped up as a Chair seven and a half years ago and I would like some reconfirmation once in a while that people actually think I'm doing a good job.

So, what we have now is not a healthy situation, it's not open, it's not trans apparent and I don't think this is the way that RIPE should run its Working Groups. As a collective, we realised that we had to do something.

Then we said well, let's try all together to find something that would work for all Working Groups that we can propose to our Working Groups as a solution. But then not all Working Groups are equal, and doing things a little bit top down turned out not to work. Well, this is RIPE, we do the things bottom up. So what we're doing now is every Working Group decides for themselves how this re‑election process should go. Depending on the needs of that specific Working Group, and maybe in the future, when we have some experience, we might merge those policies and create a more generic one for all the Working Groups, but for now we decided that every Working Group is run by its own people and they should be able to decide how to select their chairs.

So, this is what we were proposing the first time, so very simple. We should try to get two Chair persons whenever possible. Once per year one of the chairs will step down and allow now candidates to become a Chair. This is done on the mailing list and at least two weeks before the RIPE meeting starts. Anybody is allowed to volunteer. Including the person who stepped down. So there's no limit to how long somebody can remain a Chair but they have to be re‑elected effectively every two years.

So, at the next RIPE meeting the decision will be made using consensus, but we feared the situation where if there is no consensus and nobody is elected again, then there's one person left as Chair who has to run the whole Working Group by itself which is not good for stability of the Working Group. So we suggested to have a situation where, if there was anything going wrong, the current chairs would stay on to ensure the stability.

So, we put this on the mailing list and we got some feedback. The policy actually ‑‑ the text actually doesn't say which Chair steps down. It's just once every year one of the chairs steps down. Do they take turns? What happens if a Chair leaves mid‑term? There was a discussion on should we actually select our chairs on the mailing list? There was a discussion about if consensus is the right way to select it, and about the risk that if the current chairs stay on by default, if a Chair doesn't want to be removed, he could actually block the process in some ways. So, these are all points that came up, and I'll discuss them one by one.

So, the first one, do chairs take turns stepping down? Yeah, this was the intention that we would alternate, so I would step down the year after Gert would step down and this would continue like that. We'll make it explicit in the next text. I haven't written the next text yet because I want to discuss it with all of you but in the next version we'll make this explicit.

Mid‑term changes, also it wasn't mentioned in the text but our intention is that if a Chair leaves unexpectedly, at the next RIPE meeting a new Chair is is elected. So this is not that exciting, I guess.

Then a bit more difficult subject. We always made our decisions on the mailing list, not during RIPE meetings on policy. But selecting a Chair you have ‑‑ it has to be a person who can stand up, lead the Working Group, so, actually having people at the meeting and be able to talk about it helps a lot to make, to speed processes. So, we still would like to keep the Chair selection happening at the RIPE meeting, but we do want to make sure that remote participants do have a say in this and are included in the way chairs are selected. Because we realise that not everybody is able to come here, and we do represent more than just the people present at a RIPE meeting. So ‑‑ but for simplicity, we would like to keep the selection in the session.

Then, another one, who determines consensus? Well, usually, when there is something that really affects one of the chairs, the Chair that is affected abstains from any official duties, and the other Chair makes the choices. So, in this case, if a Chair is stepping down, then the Chair that is stepping down will not be involved in determining the consensus. And then there was a mention that it might be difficult for people to speak up at the microphone and reach consensus when talking about their co‑workers, about other people.

So, I want to say what our thoughts are there. We don't expect there actually to be like a huge competition on who can become a Chair. We expect that somebody volunteers, maybe two people volunteer, there's a bit of talk like what would be the best team of chairs, and then maybe one of them ‑‑ one of the candidates says, okay, you do it and steps down and there's just you know, with normal discussion, we reach a conclusion who will become the next chairs. It's actually quite a heavy job being a Chair, so I don't think people will be running up to become Chair here.

But we need something like, if there is no agreement on what the Chair team should be, if we can't find an easy solution, we do need something else.

So what if consensus cannot be reached. Well, so far HTTP hasn't happened. When Hans Petter stepped down, I volunteered, there was one other person who also volunteered. When he saw that there were multiple candidates, he just stepped down, I took the position, there was consensus in the community, everything was fine. So ‑‑ but with the current text, a Chair could actually cause a big discussion and make sure there was no consensus so he could stay on indefinitely.

So what we did is when the Working Group Chairs collective was discussing this, basically the best way to get out of this was by holding a secret ballot. So, we see if we can just talk about it and select our chairs. If there is no easy clear consensus right away, we hold a secret ballot, ask the RIPE NCC to do the counting and the person who gets the majority wins.

Now, I realise that this is not our style. I mean, in the RIPE community, we try to do things by consensus and I hate having to have a voting procedure or a secret ballot or whatever. But, on the other hand, we haven't come up with a better solution for this. How can you have something that is quick that doesn't take up an hour of our precious time where we can have a good collection of chairs so we think that even though it's not our favourite option, having this as a backup if consensus fails is the best we can do.

So, these are the things that came up on the mailing list and this is how we propose to deal with them.

And now I would like your opinion on this. Do you think this is a good way of doing it? Do you have any comments? Please let us know. We are your chairs, so, we do whatever you ask us to do. Well, within limits.

AUDIENCE SPEAKER: Randy Bush, IIJ. As you said, one of the big problems is a Chair making things complex and long. Thank you for the example. Can we just get on with it?

SANDER STEFFANN: Getting on with it means getting consensus on that this is the right way forward, so...

GERT DORING: So what I hear is take the feedback that has been received. Write it up, send it to the list and declare it as this is how ‑‑

RANDY BUSH: No, that's not what I meant. I meant, would you two stand for Chair again? Yes, I support you. End.

SANDER STEFFANN: Thank you for that

GERT DÖRING: Thanks for that.

SANDER STEFFANN: If there are no comments I'll put it into a new text and put it on the list. Thank you.

GERT DÖRING: That was quick actually. I expected more discussion as there was quite a bit of feedback on the list. But I'm fine with that as the agenda is packed anyway, and I don't actually want to rush any discussion, so if there's no discussion, it leaves us more time for discussions later on.

Marco, please. You all know Marco, he is the good soul at the RIPE NCC with all the policy work that ensures that the Working Group Chairs meet their time lines, that proposers get help if needed for proposals, and that everything once smoothly and he brings an overview of the ongoing policy stuff. Thanks Marco.

MARCO SCHMIDT: Thank you Gort. I work for the RIPE NCC as the policy development officer and I would like to give you the regular update about current policy topics, and like usual, I would give you a very brief summary of what's going on in our region and then have a selective overview of what's actually going on in the other regions. This will be a bit divided by different topics like pour depletion or IPv6 do it deployment.

But first let's have a look what has happened here in our region since the lath meeting, since RIPE 68 in what you are saw, and actually quite a lot.

We had two proposals that got accepted. The first one is the 2014‑01 which removed the minimum allocation size. It was approved, reaches consensus in July and was implemented shortly after by the RIPE NCC and since then it's possible that allocations of any size can be transferred. Also, LIRs can convert their PI assignments to allocations of any size and suballocations of any size are also possible.

Another proposal that has accepted at the end of September is 2014‑02 which allows pour PI transfers. The RIPE NCC right now is in the process of implementing it, the full implementation is expected at the end of this month, so quite soon. To this relate it had might be interesting for you that we now have a new website on our home page where we show you the implementation status of proposals that have been accepted because in the past it was sometimes a bit confusing. Proposals accepted, why the RIPE NCC cannot immediately work with, it but it needs always time to adjust our processors, to adjust the tools and now you can follow this on the website what's the status on that.

Also, I would like to mention at the last RIPE meeting there was an adjusted PDP approved by the Working Group Chairs collective. Main change is the way how the final consensus is reviewed and decided. That's now done by the Working Group Chairs of that specific Working Group. Before, it was by the Working Group Chairs collective. And there's also a new appeal procedure in case somebody disagrees with the decision of the Working Group Chairs of that Working Group.

And, these two proposals that have been accepted already follow this new PDP.

Also one proposal was withdrawn, which is the 2012‑02, the inter‑RIR transfer for IPv4 resources. It was related to publishing a new inter‑RIR policy, Sandra brown, and you will hear more about it in the second session of today's Address Policy Working Group.

And now I would like to just show you actually which proposals are right now in the discussion phase. I will not go into the detail into them because you will listen about all of them in the next hours. And as Gert says, we have this year, so far, we reached already 13 proposals and we still have two months left. So in case you would like to increase the numbers of proposal of this year, you still have sometime for it.

In the review phase, we also have quite some proposals. Again I'm not going into the detail, just the last one, the 2014‑06, which is the only proposal that is not discussed at the Address Policy Working Group. It's discussed in the NCC, RIPE NCC service Working Group and it's about the publication of the sponsoring LIR for legacy resources, because we have a policy to publish this sponsoring LIR for independent resources, so for PI and non legacy ASN and if this proposal would be accepted it also would apply for legacy resources that have chosen to have a /SPERG LIR. (Sponsoring)

This was my brief overview for our region. Now, I like to tell you a little bit of what is going on in the other regions because there is quite some lively discussions right now in, if I counted correctly, in ARIN, there are 6 draft policies under discussions. In AfriNIC, 5 proposals. And in LACNIC, 4. And only APNIC has right now no open policy discussions.

I have done a kind of ‑‑ so I will not talk about all those proposals. I did no, ma'am grouping a bit by topic to see it might be interesting and it's a selective overview.

The first one I would like to talk about is a proposals that relate to IPv4 depletion.

In AfriNIC, there's one that is quite recent to make a resource reservation for Internet exchange points. The plan is to set a /16 aside, quite similar like it's in our region, we also have a /16 pool. IPv4 reserved for IXPs, and in addition, this proposal also would reserve a pool of 16‑bit AS numbers for IXPs. And it was just published a couple of weeks ago and is under discussion at the mailing list.

Then, in ARIN, a draft policy was accepted. I mentioned this proposal, this draft policy during the last meeting. These two sections, .46 and .47 refer to the possibility to get a bigger address block for amnesty and aggregation reasons and as this was seen as a potential to be abused at the moment of IPv4 depletion, these sections were removed and this has been accepted by the ARIN community.

The same goes for proposal, or draft policy 2014‑13. This one reduced the minimum assignment and allocation size to a /24. It was before between a /22 and a /20. And now everything starts with a /24, also for the depletion. Or to count a little bit the depletion.

Another big topic in our region is Internet resource transfers. We have the PI transfer accepted. We have free open proposals and also this topic is discussed in other regions. The first one in LACNIC, there was an inter‑RIR proposal for v4 since 2012. It was discussed several times during LACNIC meetings. It was discussed on the mailing list in LACNIC without reaching consensus, and now a few weeks ago before the latest LACNIC meeting, the proposal decided to withdraw it.

Then, in ARIN, there was a draft policy 2014‑15, to allow inter‑RIR ASN transfers. This was ‑‑ the idea was to have a kind of counter policy like for APNIC, where such transfers are possible. However, it was abandoned by the community, so it has not reached consensus and it's withdrawn.

One discussion that is ongoing in ARIN is for 2014‑14, which would remove the need test for small IPv4 allocation transfers. If this proposal or this draft policy would be accepted, a need justification is only needed for a transfer larger than a /16 or if in the last 12 months, a transfer, an allocation transfer has happened without need justification. So, to make it short: Each LIR in ARIN would be able to receive once every 12 months an allocation not bigger than a /16 without justifying the need for it.

Another proposal that was withdrawn already in ARIN, but also related to transfers, is the 2014‑20, that had the idea to give some slow start, some special rules for new companies, for new end users, for new LIRs. But it couldn't reach consensus and is abandoned by now.

And last but not least, I want to mention another ARIN proposal that I also we're talking about at the previous RIPE meeting. This section is 8.2, 8.3 and 8.4 are relating to transfers and currently the minimum size is a /24 and this proposal wanted to remove this minimum size. But, it could not reach consensus and is withdrawn.

Next interesting topic obviously is IPv6 deployment, also have quite some discussions in other regions. The first one in APNIC. There was the proposal that LIRs can get up to a /29 without justification, or without detailed justification. Similar like in our region. However, in APNIC it could not reach consensus. There was some people who didn't like that idea, that an LIR could get so easy so much address space. While other people thought it would be even better to stay with the nibble bounder and allow up to a /28 and as these were quite conflicting opinions the proposer decided to withdraw it for now but there might be a new proposal coming up in the future related to this topic.

Then, in LACNIC, there is still discussion ongoing to create an extra reserve pool for IPv4 pool for v6 deployment. At the last meeting in Warsaw, I actually mentioned that this proposal had reached consensus, because just a week before the Warsaw meeting was the LACNIC meeting and there in the meeting it had reached consensus. However the LACNIC board decided that there was no discussion on the mailing list for this proposal and also the amount of support during the LACNIC meeting was not sufficient, so they decided to put it back to the mailing list, back for discussion. If it would reach consensus, it would allow LIRs that deploy v6, so they'd get IPv6 address space to get between a /28 until a /24 IPv4.

And in ARIN, there is a very new proposal actually that is quite related or is similar, because ARIN has such a pool, /28 to /24. IPv4 for v6 deployment, if everything else is exhausted, but the proposal says any size smaller than a /24 is not routable so it would not really help for the deployment of v6, so therefore the minimum size should be a /24 only.

And last but not least for IPv6 deployment in AfriNIC, there is a proposal to allow for Anycast IPv6 assignments, because the current AfriNIC policy doesn't allow it, and that this proposal tried to change that.

Another topic that is right now discussed in two regions is the out of region use. First in ARIN, it's discussed in quite a while because there is no clear policy definition how much address space can be used outside of ARIN region, and this proposal tried to change that. It basically would allow the address space can be used outside of the ARIN region the same as inside with just a few limitations that the LIR has to use at least some address space of its pool in the ARIN region, and the purpose for which it will be used outside of ARIN region, this purpose cannot be used again to go to another RIR and request address space from there.

And AfriNIC also has an out of region use policy proposal. And there the intention is quite clear to disencourage organisations to address space from AfriNIC and just use it somewhere else. So this proposal would limit the amount that can be used outside of AfriNIC to 40%.

And then I picked one ‑‑ another proposal that was discussed in LACNIC, because it's quite related to an ongoing proposal discussion in our region. It's the LACNIC 2014‑2, which would modify the text for receiving AS numbers, so this removes the multi‑homing requirement and it says now actually that if you have a need to interconnect with another independent ASN, that's enough to get your aut‑num system number and you have to interconnect within six months. And it has reached consensus last week and it's now in last call for comments actually.

This was the overview about policy discussions in other regions, and now my last slide I would like to talk a little bit about what is actually the policy development office doing or what I'm doing especially what activities I do related to increase the awareness about the policy development, and also increase the participation.

I mean, all of you, just by the fact that you're here on Wednesday morning in the room, you have already proven to be hard core policy developers, but there is also more ‑‑ it's always good to have more participation and more people joining discussions and coming up with ideas and giving their feedback.

One activity is that since around two months, I'm sending out a monthly update about the policy, open policy proposals to the MENOG and to the he nothing mailing list, so to the Middle East and the eastern network operating group and with the help with my colleagues from the Moscow office and the Dubai office, the updates are also in Russian and Arabic to reach the Russian and Arabic speaking community, or part of our community a bit more easy and this was very well received.

Also I deliver training courses, I go regularly out to the training courses that are given by the RIPE NCC, and informing more about what's going on about policy land, how the policy process works, which are the open policy discussions.

And there are quite a lot of smaller and bigger activities to facilitate the participation on the policy development. One thing is, for example, if somebody wants to make a proposal, I'm happy to help if all the format details, all the structural things, if somebody has an idea, ex focus on the idea I'm happy to do the ‑‑ work to put it in the right shape.

Another example is the use of the PDO Twitter account. That has become quite a success story by changing a little bit the way to make it more informative, to make it more entertaining, to make it more up‑to‑date; to keep the people informed via Twitter what's going on and about policy proposals and it has reached now, the tweets reaching more than 700 views, and weekly, views are above 2000. And I'm looking further into this to maybe give also more updates about other regions, so if you are interested and auto would like to hear more about this, just follow me, I am happy about every new follower.

And this is just a regular link where you can see what proposals are currently under discussion. And this is the way how you can contact me. Of course you can also find me during the whole week here in the RIPE meeting. Today from lunch I will be at the info hub, so if you have any question about any proposal. If you have your own proposal, just come and find me, I'm happy to help you.

And this brings me to the end of my presentation. I'm happy to take any questions

GERT DÖRING: It seems you didn't leave any questions unanswered. So thank you very much.

The next one on our agenda is Andrea Cima from the RIPE NCC registration services. This is, as most of, you know, a regular item on our agenda, sort of like to realign us as the policy making group with the real world of policy execution in the NCC, and if we do a poor job in defining policy, these are the guys that have to live with it so they bring back the issues arising out of interpretation of the policy, and I think that's a very useful thing to have.

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

So what is the goal, what is the aim of this presentation? Is that we, as registration services department want to report back to you. We want to report back to the RIPE community, the feedback that we received in our daily operations from the LIRs. But we also want to highlight any potential problem that we see. For the moment we want to ask you for guidance about topics, as you will see later on how should we interpret certain parts of the policy. And finally, we want to provide some input to you for your discussions.

Now, these are the four topics I will mention today. As you can see, the first one is about LIRs, local Internet registries that have an IPv6 PI assignment and have to return this back to the RIPE NCC.

The second point is about the definition of infrastructure still? IPv6 PI. So as you can see we are getting more topics related to IPv6 nowadays than we had in the past.

For the more, we would like some advice from you on how to interpret the transfer policy when it comes to the 24 months holding period.

And finally, we just wanted to give you some additional information, we wanted to give you some feedback about what we see happening with regards to /22s being issued.

Now the first point about LIRs returning their IPv6 PI is a point that I had brought up also during the last RIPE meeting and I have brought this up today again, because during the last RIPE meeting, there were some comments about this. Even before the RIPE meeting there was some discussions on the mailing list, some pointers about this, but then nothing happened. So I thought okay, I'll bring it back for a second time. As it is quite an important point.

Now, according to RIPE policy, if an organisation has received an IPv6 PI assignment before becoming an LIR, when they receive an IPv6 allocation, they should return the IPv6 PI assignment if there are no specific routing requirements to justify having both the IPv6 PI block and the IPv6 allocation.

Now, as, you know, in order to receive a /22 from the last /8 block, you must receive an IPv6 allocation. So, what happens is that we receive a request for an IPv6 allocation by organisations that have successful deployed IPv6 PI. It happens that this assignment is often in use. But, there is no different routing requirement that makes them justify having both blocks. And this puts us a bit in opposite situation as the RIPE NCC when we ask them if you have no different routing requirements, you are not justifying both, and you know, you should return the PI assignments. This puts us in an awkward position because it's a bit weird if someone has deployed IPv6, we ask them to return a block. And so far, about 47 IPv6 PI assignments have been returned to the pool in this way.

This was the first point I wanted to address. The second point is the definition of end user connectivity or infrastructure in IPv6 PI. Now, as you can see from this graph, we have quite a number of IPv6 PI requests at the moment. The number of requests is quite stable. And there is a difference between requesting IPv6 PI and IPv6 allocation. As I mentioned before, if you want a /22 from the last /8 of IPv4, you must have an IPv6 allocation. But the people that request IPv6 PI, they request it because they really want it. And these are usually the organisations that have an IPv4 PI block and now decide to implement the same also with IPv6.

Now, what happens is that if we look at the policy, both IPv4 and IPv6 PI policy do not allow for making further assignments. And these are the two quotes: IPv6 policy mentions "PI assignments cannot be further assigned to other organisations." Now this is quite clear. The IPv4 policy bit uses a bit more words but the meaning is more or less the same. "Assigned PI. This address space has been assigned to an end user for a specific purpose. It cannot be used to make further assignments to other parties." So you cannot further assign the addresses with IPv4 and IPv6.

However, IPv4 policy defines infrastructure to include the IP addresses you use to connect your customers. From the quote of the policy "IP addresses use for the connection of an end user to a service provider are considered part of the service provider's infrastructure." We don't have such an definition for IPv6 PI. This means that organisations that have IPv4 PI use it to connect customers to their network, cannot do the same with IPv6 PI. So, this means that these organisations come to us, they are a bit confused because they say yeah, but I want to replicate my v4 network in IPv6, why can I not do the same thing? And it also means, apart from the confusion that some IPv6 deployment may be cancelled or delayed, or sometimes we have people that say okay, yes, just keep me this space I will not use to connect my customers, wink. So this is also not optimal.

The third point that I would like to bring up and where where we need your feedback on how to interpret columns is the 24 month holding period for temporary assignments. Now, as, you know, reallocations, transfers, can happen on a permanent or non permanent basis. Meaning temporary. And permanent basis, if as as an LIR give my allocation to someone else, to another LIR, that LIR will be the holder from that point on, of the address space, from a permanent basis. In case of a non‑permanent or temporary transfer, if I give as an LIR my resources to another LIR, after a determined amount of time the allocation comes back to me.

The policy also mentions that the LIR that receives a reallocation cannot reallocate complete or partial blocks of the same address space to another LIR within 24 months of receiving the allocation. Now, we had even internally within RIPE some discussion, is does the 24 months holding apply to temporary transfers once the transfer period has ended and the block has returned to the original holder, or does the 24 months holding period not apply to temporary transfers?

And the final point that I wanted to mention, this is more for you, for your information, as I believe that it is our mandate to let you know the development that we see. And it's about the number of /22s issued out of the last /8.

Now, according to policy, the RIPE NCC can make one /22 allocation out of the last /8 to each LIR. What we see at the moment is that there are a number of organisations that are opening multiple LIRs. We also have cases where an organisation or an individual has opened more than 10 LIRs, what we see is the /22s are then quickly transferred to another LIR and the LIR that was opened to request the /22s is closed right away.

So, we know that this is against the spirit of the policy because the policy was made to that everyone would receive a /22 from the last /8. But in a technical perspective it is possible to act in this way. At the moment we have 70 cases in which we are 100 percent sure that the LIR has been opened to practice, but I just mentioned. 70 cases is not a lot. If we look at the total number of LIRs that we have and the total number of LIRs that have been opened every year. However we see a growing trend. So we just wanted to make you aware of this, that this is happening so that it's up to you to decide if you feel that this should happen or not.

And these were the points I wanted to bring up.

GERT DÖRING: We actually have a your of an hour time to go into the individual items there. I have a question about the infrastructure used in IPv6 PI. Could you go back to the graph so you have roughly 30 PI requests per month for IPv6 PI. Are these 30 requests that you have to turn down because they want to use it for infrastructure or is it more like 29 of them are good and one you have to turn down? So what's the ratio between people who just want to use it for their own and people who run some sort of ISP like business on v4 PI and cannot do it on IPv6.

ANDREA CIMA: What we see at the moment is these are the once that have been issued. These are not requests, they are ‑‑ these are the successful ones. I believe that we have, I think I have 20% more or less of requests that we have to gently say no to. Sometimes what happens it that they come back to us and say okay, I will not use it for connectivity and at that point, of course, we will have to issue the /48. But I think /EULGTS a 20% or 25, but it's increasing.

GERT DÖRING: Well it was intentional, we are aware that these clauses are different in the v4 and IPv6 policy and we have mentioned it here I think at least three times, and so far the pain level doesn't seem to be high enough that somebody actually steps up and says I want to change the policy. So, I think it's a useful exercise to report it every now and again to remind people that there is an imbalance, that it's an intentional imbalance and of course it can be changed, submit a policy proposal, find enough people that think it's useful and change it. But as it is, there's nothing you need guidance. The policy is quite clear here, so it's useful to basically know how things go.

Wilfried.

WILFRED WOEBER: LIR manager. Just to round out a little bit of the statistics here. As you were asking sort of, or as you were stating that the pain level is not big enough. The question for me is the percentage of requests being turned down, have they mostly been submitted by established LIRs, sort of more like longstanding well established LIRs, because then those folks actually should be aware of the possibility to submit a policy proposal, and sort of get the discussion going and starting. Or, on the other hand, whether this is more like from the new kids on the block which don't have the background information? Just for the statistics and curiosity. Thank you.

ANDREA CIMA: That's a good point. When it comes to IPv6 PI assignments, the request is usually made for end user organisations, smaller organisations that are not members. They are not LIRs. And these are organisations that in the past already had IPv4 PI and because they had IPv4 PI, they would like to continue and continue with IPv6 in the same direction. So, those are usually not long established LIRs, they are usually organisations that are a bit at the boarder of the whole happening. We have suggested to a few people that we could help at the moment, together with Marco, to create a policy proposal if they wished to do so. But as I said, it's usually organisations that are not really involved much when it comes to policy development.

GERT DÖRING: Thank you. I think that's all you can do, communicate what is the issues and what is the options.

Other comments. We have ten more minutes to discuss and I fully intend to make good use of that time.

So, I see Eric.

AUDIENCE SPEAKER: Erik Bais. I would like to make a short comment on the holding period for temporary transfers. Although the policy in itself is clear and it could actually apply to the temporarily transfers as well, I don't think that would be the intent. That is how I read this. But looking how it's put in the policy, it is actually ‑‑ if you lease out IP resources and you actually do a temporary transfer and get it back, those are actually ‑‑ you know, if you look at how it's been registered in the database, it's actually a transfer to and a transfer back. I think the intent was more for the 24 month waiting period, the holding period is more for you know the flipping of resources which is not the case in this case because it actually goes back to the original owner.

ANDREA CIMA: The point that you are asking your feedback about, as you mention is, once the address space goes back to the original holder, do the 24 months apply from that moment on for the original holder or would the original holder be able to re‑issue it to someone else again right away on a temporary basis?

ERIK BAIS: I would say the 24 month does not apply to temporary transfers. That's how I see it, because the way around it is that the issuing party, so the actual original holder what they'll get is that they will do a lease contract without updating the database and they will get around it. That is basically what will happen. Unless the actual other company will say you know, I need to have this transfer or I need to do the temporary transfer and I want to have the database updated that they will actually you know go through RIPE and actually get it temporary transfer. My personal experience, I haven't seen them very much. I think really they are corner cases, we might see more of this, but leasing with temporary transfers updating the database, I don't see them much. But that's my experience. You can probably tell about how often this happens.

ANDREA CIMA: Yeah, we do not have many temporary transfers, but in case the situation would occur, we would have to know how to handle it, that's why we are asking. But it's a minority. Most of the transfers are permanent transfers, yes, you are correct.

ERIK BAIS: So, I would say treat it as a leasing contract where is basically it's the same as an assignment that's probably best. And that was my part for this one. Anybody else on this point?

GERT DÖRING: There is another point but let me just inject a few sentences. As far as I remember the 24 month period was put in there to avoid speculation, and you don't speculate with temporary transfers. So, from the original intent, I think ‑‑ well, at least to me as a participant of the Working Group and not as a Chair, it was always clear that this is to, well to avoid people stockpiling and then selling it off and auctioning and whatever and doing, a fluid business with buying and selling addresses and not doing the proper thing with temporary lease. There is somebody else on the microphone, please.

AUDIENCE SPEAKER: Hi. Liuhneg, I'd like the problem you mentioned on the /22 ‑‑

GERT DÖRING: I take the notice of that. Is there somebody else who wants to comment on the temporary leases? I think then, basically we take what Erik said as the word from the room and don't apply it. Similar that is quite clear, thank you very much.

AUDIENCE SPEAKER: I'd like to make a short comment about /22s. The first I have a question for the RIPE NCC that: How many /22 had to be issued? I understand from the last meeting that over 10,000 has been passed in numbers and in total there will probably about 16,000 /22s can be issued from the last /8. And are we running out of /22s at this moment?

ANDREA CIMA: No, we are not running out of /22s at the moment. In the sense that the RIPE NCC has a bit, has more than a /8 available for allocation. When it comes to the number of /22s issued, I believe it's between the 4 and a half thousand and 5,000 in total so far. If we look at the number of new LIRs that we had over the past 12 months, I think it's about 1,000 new /22s issued, so as I mentioned it's quite small because 70 out of 1,000, because these are events that we have seen over the past year. Not before that we are talking about 7%. So, 7% is not very high, but as I mentioned, it's a growing trend. We see this more and more. So that's why we it was important to bring this to your attention. But if you look at the absolute numbers, yeah, the absolute numbers show that it is a very small percentage.

AUDIENCE SPEAKER: I think the communities have time to make a policy about it, because I think the original intention for /8 basically, make IPv longlasting making the new entry for the coming decades. And it's definite not intentionally to make a /8 for the transfer market because if we look at the total IPv4 in the RIPE region, the last /8 really, the last little bit of the total allegation so the transfer market should not be affected anyway. So my personal belief would be we should put a more strict rules on the last /8, so, we make sure the last lasts much longer for the time being and any newcomers in the next five, ten years, can get their hands on IPv4 at very minimum cost

GERT DÖRING: I hear you. I think it will be ‑‑ it will not be easy to actually define terms that achieve what we want. Assuming that we know what we want. But, yeah, I welcome your policy proposal to help define this more clear. I see Erik, then Sebastian, then Wilfried on the microphone.

AUDIENCE SPEAKER: Erik. There is ‑‑ there are several ways to sort this out. One of them is to disallow merger or transferring /22s into another LIR that already has the /22 from the final /8. Another one is to actually put a holding period on the LIR so that they are actually ‑‑ so that they cannot transfer a newly allocated /22 directly to somebody else. Both are basically, you know, options to say you know we need to pay an upkeep. The reason why this is a viable option and it's actually, you know, financially interesting for some, is because specifically in the last quarter of the year, they open the LIR, they only pay a quarter of the yearly fee, they transfer out the /22 and there out, there is no enforcement to actually require them to keep the LIR and actually pay the upkeep of the yearly maintenance fee. And by doing that, they are actually increasing their own profit. And I think that, I totally agree with hen low, it's against the intent of why this was created. I have asked already on the mailing list, I have asked that during the policy for the transfer of PI space, do we need to fix this? And if so... so far the reaction that is I have received, it's not required, we'll leave it run out, who cares. But, this will be an issue and we'll see more and more of that. I totally agree that this is a growing trend and this will go faster and faster.

AUDIENCE SPEAKER: Sebastian: I agree with most of, or what my previous speakers, in that that is not what was the intention for the last /8 I think. Though, as we have seen increased cases, or I think it will increase more and more. We should do something about it as soon as possible, because now we can do something.

Another thing that I don't know is how much effort is it for the RIPE NCC actually to create a new LIR and close it so it's something where we can run in problems also for the RIPE NCC. I don't know how much you have to do to create a new LIR, so legal and the payment work and everything that's something you have to shoulder after all. So that's also not something there was intended. So I'm not sure if you...

ANDREA CIMA: With regards to the work load, we have processes in place to help organisations to enter into contractual relationship with the RIPE NCC. We are actually reviewing these processes at the moment to make it easier for organisations as well. But the amount of work is a process that we are used to do for a long period of time now. The actual creation of the closure of an LIR are part of how our normal practices, processes and processors that we're used to. It doesn't add any extra burden on the RIPE NCC from that perspective.

SANDER STEFFANN: I think you can basically rephrase that question is the 2,000 euro sign up fee enough to cover that cost.

ANDREA CIMA: There is a sign up fee and a quarter ‑‑ so I'm looking at the financial people. But yes, it should cover it, I believe, in my personal opinion, it should cover the cost.

AUDIENCE SPEAKER: So I want to say I think we should do something about it. What the best way is, well I think that's up to debate

GERT DÖRING: I see three more people on the microphone. We are running out of time. I'm hearing you, Wilfried, Angel and Elvis.

WILFRED WOEBER: Just very briefly, because most of the stuff that I would have wanted to add has already been said. The observation from my point of view is that obviously there is perception that going the route of creating an LIR and then moving the address space somewhere else is perceived to be cheaper than going to the IPv4 market.

GERT DÖRING: It is.

WILFRED WOEBER: And if it is, then this is even a stronger incentive to look at the intention we had with hold times and limitations and that sort of thing. I guess if there are a few others that feel strongly about that one we should actually start to submit a policy proposal to change that. Thank you.

AUDIENCE SPEAKER: The last comment about it is, I think there's actually practical way to do it. And the last speaker just mentioned that the reason why it's happening is there is financial incentive in that business, especially in the last quarter of the year and to get IPv4 transferred. So I think the best way to do it is probably make the /22 from the last /8 different from the norm at allocation, so this /22 should not be participate in the transfer market itself, and it should be kind of red line or specially Teredo to prevent people from getting financial gain from it. Thank you.

AUDIENCE SPEAKER: Elvis: I wanted to say something very similar to what Wilfried said. Indeed, it is, right now, a lot cheaper to just go and register as an LIR, get a /22, transfer it, close the LIR, register as an LIR, get the /22, transfer, it close the LIR, and repeat. It costs only, let's say ‑‑ if the people that want to do this do it in the last quarter it's only going to cost them like €2,400. And if they do it, let's say, at the beginning of the year, it's going to cost them maximum €3,000,600. While going on the market, it's going to cost them maybe somewhere around 8 to 10,000. I do think we should do something about it because we are also noticing, we as a broker, we are also noticing a lot of people just registering the LIR, coming to us and saying, this has never been used, this is the cleanest space you could sell. We want €8,000 for it. And we always tell them, yeah, if I want to sell your space, I could just register it myself. I could register myself as an LIR and do it myself, but we don't want to do that.

Now, what I would propose, and of course this has to go to a policy proposal etc. I would say that it will remove the incentive of doing this if we would put the two years gap, the two years limitation for the /22s as well. Because, if we put the two years limitation for the last /22, then the person would actually have to pay the RIPE NCC two years in a row, which would cost 3,000 something, plus the 2,000 signup fee. It would get not as ‑‑ it would not cost as much as a normal transfer, but it would get very close to that price

GERT DÖRING: Actually, I really like that. I have been ‑‑ while you have been talking, I have been thinking about caveats and like you are not permitted to transfer it at all, which might prevent legitimate mergers, if I buy somebody who has this 22 and there is customers in it and I have to return it after buying, it this is sort of not what we want, but‑ just blocking it for transfers for 24 months might actually be the least complicated way to make it uninteresting to do that. And I'm wrapping up the line here, sorry for ‑‑

AUDIENCE SPEAKER: I have five seconds. This is Christian Kruger from IPv6 Berlin. What I would also see as a problem is, due to the fact that there are already people lined up for that kind of business, we could face that getting into kind of level very soon. It is quite easy to register a company. It is easy to register LIR if you know what to do. So you could face just a few hundred papers going for the /22s in a time period that we could probably deal with right now but not in the future. Because if that paper arrived, then things are running. So I think we should do it quite quickly, yes

GERT DÖRING: So what I hear from the room, which is very clear, is that we want to change this. I think the idea from Elvis has the least ‑‑ and I welcome Elvis and maybe Wilfried and Eric, who really know the scene, to come up with a proposal. Thank you very much in advance. That should actually be not so complicated in that case, but thank you anyway. It takes some effort to do that.

Now, we are actually nine minutes behind the plan, but I think it was time well spent. And the next one I think it's Job. We have a presenter, we have slides. This time we are better organised than last time. Thanks for being here and presenting your proposal.

JOB SNIJDERS: Hi guys and girls. I'd like to talk about proposal 2014‑03, formally known as the proposal to remove the multi‑homing requirement for when you request an AS number. I informally call it "AS numbers for everybody."

The goal of this policy proposal is that we want to align reality ‑‑ or we want to align policy with reality. In this day and age, the RIPE NCC requires that if you want to obtain an AS number assignments you have to be multihomed. You have to prove it in some form. But in reality, they cannot really verify those facts at all in a trustworthy way, and there are many good reasons to get a globally unique AS number but not multi‑home.

For instance, if you are building out a site and you start with one upstream and then maybe in the future you will multi‑home but not today, why would that prevent you from getting an AS number today?

So, we sent the proposal to the list, it went through Impact Analysis, it then went to review phase and based on the feedback we received in the first round of PDP, we made some modifications to the proposal. Originally the proposal was just remove the sentence that states multi‑homing is mandatory, and now we have added some more text, because, there was some feedback that people were afraid that somebody might come along and request every ASN on the planet. And because there is not a yearly fee associated with the assignment of AS numbers, one could argue that the barrier is quite low. But then again, already today, you could request all the AS numbers that are available in the pool by just having them multihome with each other.

So we decided to protect against excessive consumption of AS numbers by limiting the amount of AS numbers to 1,000 per end user organisation. So me being Job Snijders I could request 1,000 AS numbers and the RIPE NCC would say no more for you. And this number is chosen on an arbitrary guesstimate of what is fair. We asked the RIPE NCC what is the current maximum number of AS numbers, a single organisation has? And answer was 100. So we just multiplied it with ten and that's what I put in the policy.

We also differentiate between 32‑bit and 16‑bit because 16‑bit, there are less of those than in the 32‑bit space. If you want a 16‑bit AS number and there are various reasons to do so, the policy essentially is the same as it is today. You have to be multihomed and if you want a 32‑bit AS number, then it doesn't matter.

So, with these changes, I hope we accommodate the feedback that was given to us and that we protect the pool from excessive over consumption. But, yes, everybody that wants an AS number can easily obtain one.

We are now going through the second round of Impact Analysis. Marco Schmidt, where are you? Is it finished yet? No? Oh...

I assume Marco is typing right now on that analysis. Let's assume that that's finished within the next one or two or three weeks, then we go through a new round of review phase, and what happens after that, I don't know.

Because this is the most interesting slide, let me put that. Are there questions? Objections? Do people feel like we should do this or...? Please voice your comments, concerns... Eric, go ahead.

AUDIENCE SPEAKER: Erik Bais. As stated on the mailing list, I think that the intention of the policy is correct, fully supported. So, I'm looking forward to the second analysis and see how it goes from there. But, my support for it. Good.

JOB SNIJDERS: Thank you for your feedback.

AUDIENCE SPEAKER: Kurtis Lindqvist. So, rather than having an arbitrary number 1,000, I was just thinking is there a definition of an autonomous system something similar to a collect of router network elements with what is different routing policy or whatever, the definition says. Would it be simpler to say that you are allowed to have an autonomous system if you can prove that you have a separate routing policy to the rest of the organisation. Because after all, that's the definition of autonomous system and then you'll need to have random numbers.

JOB SNIJDERS: The reason we put a random number is because some people argued that ‑‑ so, what you mention is, I agree with that, it would make more sense, but then again, we're in the address space Working Group, so, logic does not always apply. Cannot prove to me that you really have separate routing policies and I cannot verify that in any easy way. So, if you have a random number that just caps it at 1,000 and we can up that in two years if, I don't know, some car manufacturer starts assigning AS numbers to each car, but with the thousand number, there is no need for fact checking so there is no need to lie, there is no need to dig into people's networks, and if the method you suggest, it becomes more complicated because it's hard to check.

KURTIS LINDQVIST: I'm not suggesting that you need to check the and verified. We have not bad policies based on random numbers in the past and I just don't think of adding to them it the best way forward. I can't I feel very strongly about, it it's just I don't want to stand here in the future and say oh that thousand number was a bad idea, or 200 as it have the last time.

JOB SNIJDERS: If it were up to me, my preference would be that AS number assignments costs a euro per year, it used to be €50 and then that cost was removed for whatever reason. And if they would cost a euro per year, we would not need this arbitrary number, because then you would have a system that enforces people to pay for a resource and if they don't pay the resource disappears. But ‑‑ so, I would launch a new proposal if an AS yearly cost was reintroduced and then I would get rid of the thousands and just let it be.

GERT DÖRING: Something I want to mention is that on the RIPE General Meeting today, there is a point on the agenda charging forecast numbers. So, I'm not sure who put it there. It wasn't me, but I saw it and that makes me happy because it puts the discussion there as well. It's an arbitrary number obviously, but the feedback that came from the mailing list was very clear that if we change the policy that way there is nothing in it that would stop people from just grabbing 4 billion AS numbers and driving the NCC crazy and depleting the pool. Most likely driving the NCC crazy before that, but still... so it's an arbitrary number which is higher than anything that we have seen so far and anything that we could reasonably imagine, but low enough to be sort of like a sanity margin. We might not actually need it if the AGM decided that the charging scheme should have something for the AS numbers again, so, if it's €1 per year, and you get 4 billion AS numbers you might reconsider the plan.

JOB SNIJDERS: Well, it would mean that membership is free for everybody.

GERT DÖRING: We have no formal power to make the AGM do that. So if all of you who represent an LIR go there and vote for it, there is voting, and we can drop this from the policy afterwards. But, as soon as we don't know what the AGM will decide and they are not deciding today, they are discussing and then the decision will be maybe in two meetings or so, I find this a fairly reasonable compromise in the meantime to go forward with this, and have the limit in there to prevent abuse.

SANDER STEFFANN: I think the number of 1,000 of the biggest entity that has AS numbers like 100. So we picked ten times the biggest we could find. So, to be safe.

AUDIENCE SPEAKER: I don't really like this random number. My name is Tashaw, I am a consultant work for German and Swiss Government. And my question is: Isn't it possible perhaps to justify somehow a number based on scenarios which makes sense to use?

JOB SNIJDERS: Yes, we took ten times the highest use.

AUDIENCE SPEAKER: And do you have some document where this scenario is documented why someone needs 100?

JOB SNIJDERS: We looked at current usage. And the RIPE NCC has documentation why that organisation has 100 ASNs. I don't know which organisation it is. I don't know why they have 100 ASNs, but they obtained them somehow following the current policy. That's good enough for me.

AUDIENCE SPEAKER: So my proposal is perhaps to make a document where some sense making scenarios are described so justify somehow this number.

JOB SNIJDERS: To what end? What do we gain by doing this?

AUDIENCE SPEAKER: Yeah, you see, okay, there's nothing thinkable nowadays with more than 100, but this is nowhere written, there is no scenario written why is this 100 and not 1,000 or not 2,000, so perhaps it should be a documentation about it. So...

JOB SNIJDERS: Why?

AUDIENCE SPEAKER: Because someone without, who don't have a clue about everything, just say okay, I need 2,000, and there is no document which corrects him in his view. This is the issue.

JOB SNIJDERS: There are ‑‑ I don't know the RFC number from the top of my head, but there are guidelines for assignments of Internet resources and those guidelines they are referenced in the current policy and they do elaborate on when you would or would not need an AS number and in which scenarios you would require more than one. So there is documentation for that specific aspect. I can e‑mail it to you.

AUDIENCE SPEAKER: And this leads to this 100 highest number, yeah?

GERT DÖRING: Networks the 100 ASs are the maximum number that the RIPE NCC has ever given to a single organisation so far so we put ten times the number as limit because we think that it's very, very unlikely that anybody else will reach that. If somebody will reach 500 I'm pretty sure Andrea will come up. We have seen a new trend, people are burning AS numbers like hell and they will hit the thousand limit by next you're, do you want to do something about that? I trust the NCC to give us early warning if we ever run into problems here. So... I think you are making this more complicated.

AUDIENCE SPEAKER: Me too, but perhaps 100 doesn't make sense either.

JOB SNIJDERS: Who are you to judge and why do you care about an organisation having 100 out of 4 billion ASNs?

GERT DÖRING: We need to take this to the coffee break. I'm pretty sure you two have lots to argue between each other, but we are running out of time and I want to take the time for the next proposal as well. Elvis, ten seconds and then Marco and then closing of the line.

AUDIENCE SPEAKER: Elvis: I don't like the arbitrary number of 1,000 either. I understand the reasoning behind it but maybe we should just start with 100 and see if we ever get to the thousand.

JOB SNIJDERS: If we start with the hundred already today we would immediately have a conflict with an organisation that has 100 today.

AUDIENCE SPEAKER: I think that the company you are talking about might be actually a company that has received legacy resources ‑‑

JOB SNIJDERS: No this is excluding legacy. So 100 is incompatible with reality

GERT DÖRING: This is just a stop gap to stop a wide running abuse. We don't think it will ever hit.

MARCO SCHMIDT: I just wanted to answer the question, what organisation got 100 ASN? I will not give the same because that's confidential, but it's an organisation in Russia, a huge telecom provider and you can imagine a country like Russia, just from the geographical dimension you need a lot of networks and ASNs, so...

GERT DÖRING: Thank you for that. I hear that there is some more need for discussion. The proposal will go to the mailing list anyway for review phase and we have the Impact Analysis which will tell you in no uncertain words what the NCC thinks about this, whether it can be implemented or it will cause problems. Thanks to the NCC for that because it really helps.

Thank you for being here and arguing the point.

Let's discuss this on the mailing list as we need feedback there anyway. It's in review phase, or it will be in review phase very soon now and if we don't get feedback on the list it can not become policy. So... let us know your thoughts on the list as well.

Then we come to the latest item on the agenda with this, which is policy proposal 2014‑04. Relax IPv6 requirement from the last /8. The two proposers cannot be here, which is why Sander decided to sort of give up his Chair neutrality status for this proposal and sort of like step in as proxy proposer.

SANDER STEFFANN: So, 2014‑04. There's been quite a bit of discussion on this. As the proposers cannot be here, I promised to help them out. Which means I'm actually going to have opinion on this topic, which means that I am disqualified on judging consensus and things like this on this subject, so Gert will do that and I will abstain so, we have a neutral Chair who can make the decisions.

So, the reason for this proposal is that we have one sentence in the v4 policy that says "Allocations will only be made to LIRs if they have already received an IPv6 allocation from an upstream LIR or the RIPE NCC."

And the problem we have is that there are organisations who maybe run their own data centre and they can perfectly well from IPv6 PI space, but IPv6 PI is an assignment and not an allocation. So, when they want to get an allocation, it means they have to give back their assignment and they have to re‑number their whole network, which makes it really difficult for them.

So, basically we're punishing the wrong people. We have people who are already deployed IPv6, who have been working on IPv6 and now we're /TAELG them to do a lot of work and re‑number and I think the last /8 policy was meant to help such organisations in the transition by giving them a bit of v4. So, I think we're doing the wrong thing here.

So, how did we end up getting this requirement in there anyway? From the rationale from the policy proposal that introduced this, it's 2010‑02, the proposal attempts to ensure that no organisation lacks real routable v4 address space during the coming transition to IPv6. We have organisations actively deploying v6 and we're hurting them.

So the intent at the time was to make sure that people knew that this last /8 block, the /22, was a special one, it was not ‑‑ it was not just a normal allocation. They couldn't go back for more. That was the last they would get. This was for making sure they could survive in the transition period. And to actually make people aware that they needed to work on v6, which was a good goal at the time. And still is.

So, the first attempt the proposers made was actually just expand the wording a bit. So say not only an allegation is good enough to get your last /22, but also an assignment. That led to a discussion like but what happens if they don't have an assignment in the RIPE region but they have an assignment or allocation in some other region? And maybe we should actually make sure they are using their v6 space, so maybe we should require that they have a web server running in their space and this whole discussion went all over the place.

So, I think the better solution is to actually just remove the requirement. Because, making sure they have a v6 prefix doesn't mean they are going to do any deployment. There is actually a lot of IPv6 PI blocks being allocated just to fulfil this requirement. If ‑‑ I talked to some NCC people yesterday and they told me like, there's a lot of ‑‑ if you look at the star system, there's a lot of organisations that have one star. They have an allocation. But they are not routing, it there's nothing in the database, it's just there probably just to get their last /22. So, it's not really advancing the deployment of v6. And we can't tell them how to run their network. We can't say you have to have a web server because there are plenty of other good reasons why you have address space besides running a web server. So this requirement, well it does some promotion of v6, it makes people a little bit aware it have. It's not helping deployment in any way and it is actually hurting people that are deploying v6.

So, my opinion is, we should remove this line from the policy. All it does is just create a little bit of awareness. The RIPE NCC is working hard on that anyway and doing a good job. If we think that should improve, maybe we should need to go to the NCC Services Working Group. But I think this promotional line doesn't belong in an address space document.

So, your opinions on this please?

GERT DÖRING: I realise that everybody who stands up to the mike is standing between you and the coffee break but I think it's worth taking five minutes from the coffee break and get some feedback from the room. So Eric please.

AUDIENCE SPEAKER: Erik Bais: I really like the intent of getting rid of the complete IPv6 allocation requirements to be able to get the final /22. It really doesn't make sense and as you said it doesn't really help any deployment.

MARCO SCHMIDT: We right now doing the Impact Analysis but we were asked to if possible to give a preliminary analysis, so, we are, as I say, business busy, but we can see that the amount of IPv6 allocations will decrease that we hand out because it's true, like you said, that there are quite some new members that put them on the shelf. We see we need to increase the communications efforts. There is the risk and it might be perceived there are stakeholders that are not so close to a technical community that the IPv4 support IPv6 is withdrawn but we then would need to increase the communication that it's not the case.

GERT DÖRING: That could be some sort of like here is your /22 and by the way, please do not forget that the world is moving to IPv6 and please evaluate the possibilities in the initial mail, right?

ELVIS: I want to add to what Erik said, and if one needs an IPv6 allocation they can always come to the RIPE NCC and get it if you want a /22, all you need to do is make three extra requests for the IPv6 and just get the IPv6 and not do anything with, it then it's useless. So, what the policy is doing right now is just requesting any new LIR to ‑‑ or any LIR to just do four or clicks because the RIPE NCC process is very simple now, and just request an IPv6 allocation, and I don't think that's any good right now.

SANDER STEFFANN: Those are two voices in favour. Anybody think this is a bad idea?

GERT DÖRING: To report from the mailing list. On the mailing list we had one person who said we should do much more to incentivise IPv6 but couldn't really come up with working approach, and a number of voice that is said just kick it out. So this is what has been done for the next release and it will hit the mailing list soon as formal new version of the poll proposal.

And with that, thank you for your feedback. Enjoy your coffee and please be back at 11.

LIVE CAPTIONING BY MARY McKEON RMR, CRR, CBC

DOYLE COURT REPORTERS LTD, DUBLIN, IRELAND.

WWW.DCR.IE.