Archives

Address Policy Working Group
26 October 2016
12 noon


GERT DÖRING: We'll start. We're five minutes late. I am full of the best intentions to not steal a single minute of your lunch break, so we go.

Welcome back. I can't see anything because I forgot to put on my glasses but I do not actually need to see anything right now, as I'm handing the microphone to Andrea Cima anyway. So we have this item.

We agreed a couple of years ago to have this regular item... the point here is, the NCC RS volunteers to bring up issues they've encountered in day‑to‑day operations and give us a chance to see if we want to do anything about it, and there we are. Thank you.

ANDREA CIMA: Good morning everyone. Thank you Gert and Sander. My name is Andrea Cima, I am part of the registration services team at the RIPE NCC and as Gert just mentioned, the goal of this update of this report is to give you feedback, is to report back to you.

We want to report back to you the feedback that we received from LIRs in our day to day activities, and we also want to highlight potential problems that we see, and that you may want to discuss.

Now, this is the outline for today. There are four topics I would like to address. The first one is about unused AS numbers. What should we do with those?

The second and third point are related to IPv6. LIRs with multiple IPv6 allocations, is this okay. Is this an issue or is it not an issue?

And I want to address the differences between the IPv6 first and additional allocation policy and are these out of sync? And if so, should we do something about it?

And finally, this is a topic that I had brought up during the last hype meeting, but because of time constraints, it was not really well discussed, so, I wanted to try to give it another go. And that is related to legacy resource after inter‑RIR transfers.

Now, starting with the unused AS numbers.

Now, according to the ASN policy an AS number should only be issued if a new external routing policy is required. The same policy also mentions that a network must be multihomed in order to qualify for an AS number. I think the important point is here is the policy mentions it if an organisation no longer uses the AS number this number should be returned to the available pool so that it can then be issued to other organisations that need it.

Now, if we look at utilisation of AS numbers in the RIPE region, we can see that slightly more than 6,5000 AS numbers are not advertised in the routing system. Now, that is between one‑fourth and one‑fifth of all the AS numbers that the RIPE NCC has assigned. So we can see that this is quite, this is a relatively high number. Now, what we see and what our perception is is that most of those AS numbers are issued to organisations that either out of business or do not need the AS number any more because of changes within their networks.

Now, as a consequence of those AS numbers being somehow abandoned in the registry, we believe that this deteriorates also the quality of the registry itself. Why? Because AS numbers reference to organisations that A) no longer exist or are not related to the AS number no more. Furthermore, abandoned resources we have seen are usually prone to hijack by organisations or by people that want to make certain use of that and it's not always a good use.

So, what we would like to address here is to propose a cleanup of the unused AS numbers to the free pool, and when would we want to return an AS number to the free pool? There have been a lot of discussions in the past about what is considered to be in use, what is not considered to be in use, and what the AS numbers that we would address are the ones that are not originating any address space in BGP. The holders of those AS numbers would be contacted by us, and asked if they have any plans to us auto the AS numbers in the coming period. If they say that they have no plans to do so in the coming six months or if the end user is unresponsive, we would want to bring back the AS number to the free pool. Unless of course the resource holder has a reasonable explanation and by reasonable explanation I mean that somehow they are using the AS number even if it's not originating any address space in BGP.

We have seen organisations that, for example, use an AS number in a private network, but this is due to a very old setup and of course we wouldn't want to disrupt their operations. So this would be our high level proposal. If you think that this is something doable, if you think that if there is a mandate for it, we could come up with a more detailed plan of course.

The second point is related to LIRs with multiple IPv6 allocations. Now, since March 2015, LIRs can transfer IPv6 allocations. We have done about 160 policy transfers of IPv6 allocations so far. Plus other transfers due to mergers and acquisitions.

If we look at the numbers here, we see that of course, the vast majority, almost all LIRs have one IPv6 allocation. Now we have a few hundred LIRs that have two, sometimes due to merger or acquisitions as I mentioned before and we under up with two handful of LIRs that have more than ten IPv6 allocations, getting up to 18 allegations for a single LIR.

So, the numbers, as you can see, are not impressive in the sense that it's still a limited trend that we see, but we thought that this is the right moment to bring this to your attention.

Now, when we have asked some of those organisations like why are they still piling IPv6 allocations some of the questions we got is for easier deaggregation or otherwise it was much easier than justifying an additional allocation which according to policy was quite hard.

So, our question here towards you is, is this something that is considered unfair towards organisations that are struggling or that trying to put together plans for additional allocations? Is it something that you want us to keep an eye on? Is it something that we want to address right now?

Moving onto the IPv6 first and additional allocation policy. I just want to introduce that, until not so long ago, according to the IPv6 allocation policy, if you wanted more than a /29 the only way to justify the additional space was according to a number of users and to the extent of your current infrastructure. Now, while this applies to, and this works really well for the classical ISP, we had seen that this was actually creating problems to multinational organisations, or governments, where there are other different important points on which the amount of address space was based. You, as a community, decided that the policy had to be changed, in order to allow for more flexibility in order to allow for organisations which do not have a vast user base to get a larger block and some new criteria were introduced in the policy. Like hierarchical and geographical structure, security level and a planned longevity for the allocation. So since the introduction of the policy, there was an article written, it has been quite successful, we have had a few, a large allocation, larger than a /29, based on the new policy criteria, so this seems to be working.

If we look at the IPv6 subsequent allocation though, this has not been changed in the policy review. The subsequent allocation is fully based on utilisation according to HD ratio. This means that if you receive an allocation, a first allocation based on those new criteria like geographical, or security reasons, you will not be able, based on the same criteria, to justify an additional allocation in the future.

As well, organisations that, in the past, have received an allocation before the new IPv6 policy was approved, reached consensus, also for those organisations it's very difficult to justify an additional block in case they need the additional address space for geographical reasons or for security reasons. So we believe that there is a synchronisation issue now between the first and the additional allocation policy which is sometimes hindering the deployment of IPv6 as organisations, for organisations it's quite difficult to justify the additional bit.

Then finally, this is a point, as I mentioned before, that I brought up last time, there wasn't really a conclusion because there was not much time to discuss this. But, if we look at the Inter‑RIR Transfer Policy, the issue is that you, in order to transfer resources from regions where there is a need basis to the RIPE region, the recipient of the resources must provide a plan, must have a plan to use at least 50% of the transferred resources within a certain period of time.

Now, what we see is that, in spite of the five year plan, if it is ‑‑ if the resources imported are legacy resources these can be retransferred the day after because there is no policy that doesn't allow legacy resources to be transferred for 24 months. So, actually what could happen is that a block gets imported in the RIPE region and after the recipient even though the day before they provided a plan for the utilisation of the 50%, the day after they can split the block and we transfer it toth to someone else. Maybe even to a holder, to an organisation in the region where it came from. So, let's say that this would look quite strange.

So, it's all okay according to policy. Like I said before with regards to legacy resources there is no limitation whatsoever to transfers, but is this also within the the spirit of the policy that was set in place for inter‑RIR transfers. That's it.

And I think that those were the points

GERT DÖRING: First. Thank you for bringing this up and giving us something to think about. Then how we are going to discuss this. We need to do this in a structured way to give enough time for all of your items because some stuff slipped off the agenda the last time, this shouldn't happen, so what I'm proposing to do now is, we have something like 40 minutes and spend ten minutes with a fixed boundary on each of the items and start with the first one. So I saw waving from there, which is about the third one. First, could you go back to the implementation plan for the AS number reclaims?

So, if we spend less than ten minutes discussing this, we have more time for the next proposal, but we have ten minutes, and we can make good use of it. Now...

JAN ZORZ: The queue was...

AUDIENCE SPEAKER: For the AS numbers, at least in France, we use AS numbers for inter‑connection with several external entities, generally with transport providers, but there are sessions that are not visible in the routing table, they are done let's say not behind the scene, they are done on the... in order to get the traffic to you, you have inter‑connections that are not visible. So this is ‑‑ this should be taken into account as one of the valid reasonable explanations. I'm not sure that the resource, the people dealing with the checks have this information, so there are a number of cases that should be described quite clearly, not necessarily policy wise, but at least as a procedure for people processing AS numbers within the RIPE NCC. So, do we need to start compiling such a list so that... no? Okay. Thank you.

ANDREA CIMA: Actually, I think this is a perfect example of a very good reasonable explanation of how the AS number is used. And if there is a mandate to do the cleanup from the community, I believe that we, as the RIPE NCC, can better explain what we mean, better define what we mean by reasonable explanation, and like you mention, include cases like the one that you just mentioned.

GERT DÖRING: This was also my concern when we talked about this beforehand, that there are AS numbers that are perfectly in use, but cannot see them originating, something on the public Internet, because there is more networks. Private peerings and stuff, so this is why the sentence is there actually.

Question to the room: Do we want the NCC to go out there and spend some effort on this or do we think this is not worthwhile? I think this is the question the Working Group needs to decide. The NCC is aware that there are exceptions when they cannot see an AS number and I understand that they are going to be careful about it and not going to bully people, just clarify, is this in use? If yes, sir, fine; if no, please return. Actually, we have time for voices.

AUDIENCE SPEAKER: Erik Bais: On the ‑‑ before we make a decision, do we want the NCC to spend time on this, do we have an indication of on how much time? Is this going to be, you know, 20 FTEs doing work for three years or is this, you know, mill shot, see how it goes, get the replies and within five or six months we get to a point where you get diminishing returns?

ANDREA CIMA: That's a very good question. Before actually doing an analysis like this one of the effort and going into more details, we wanted to see if there is a feeling from the community that this is something that is, you know, should be looked at and be tackled. And this would be the first thing to do afterwards, would be to do a better analysis, a better process on how we would be doing this. But in any case, when it comes to the ‑‑ I mentioned in the example the 20 FTEs, that wouldn't be the case, we would try to automate things as much as possible, with, as you say, an e‑mail, possibly automated to the organisations that are holder of AS number not originating any address space. So it would be e‑mail based contacting in an automated way.

ERIK BAIS: One of the suggestions that is to include it at least in the arc, because then at least you have all the LIRs already in the process in a contact point. Obviously there are a lot of resources in use with direct end users, which you did not cover with an arc, but maybe with the sponsoring LIR for the resource, so that might actually be a process and it will probably be fairly light touch.

ANDREA CIMA: That's a very good point as well and it can be included in there as well. Yeah.

AUDIENCE SPEAKER: I have a question, what is the current practice when it comes to returned AS numbers? Are they rea joined again or how long after? I mean, are is this just for, we don't sort of unused AS numbers registered? Or are we going to reuse them?

ANDREA CIMA: Let's say that it goes from a multiple first of all, maintain an accurate registry, meaning AS numbers issued, assigned to organisation that is do not exist any more, should not be out there. So that is the first call. And, yes, eventually those AS numbers would be reissued, they would return to the free pool after a period in a quarantine, so, we would make sure that they would be clean and like we have always done for any other AS number after a certain period of time, they would be reissued.

AUDIENCE SPEAKER: Hi. Ken, I have a question about the unresponsiveness of the end user. How much time should you give the end user to respond and if they are unresponsive and the AS number goes in quarantine, is there a way to get back your AS number if it just shows a misunderstanding or something?

ANDREA CIMA: Like I said, if there is no response from the end user and the idea is that even if the sponsoring LIR which also plays a very important role has no more information about the organisation, yeah, they would be able to put the AS number in quarantine. As the goal would not be to reclaim AS numbers but do a cleanup, if an organisation then pops up and says we are actually using it, we would of course take it out of quarantine and re‑issue it to the organisation. So, we would be quite flexible on that perspective, and like, Gert mentioned before, we want to take a very light approach on it and we wouldn't want to be seen as abusive towards the users.

AUDIENCE SPEAKER: Thank you. Jano, I would like three quick comments. First of all, on the first bullet here, we see an originating, it may be that the AS appears in the AS path but it is not necessarily originating, so I would just suggest to clarify that.

The other question was whether it makes sense to start the process of the claiming. I think it is a good idea because there is no price tag attached to the ASs, so that also doesn't give an incentive to return it. So, it would be good to clear up a bit the database especially from the companies which have disappeared.

And just an idea: We could prioritise it in a way that we first concentrate on the 16‑bit ones. Thank you

GERT DÖRING: To wrap up. What I'm hearing is that nobody strongly objects to that. There are concerns about the amount of effort you are going to spend on this. So, I think the way forward is to come up with an implementation plan on the list. And if nobody strongly objects, then go for it.

ANDREA CIMA: Okay. Yes, we will do that. Thank you very much.

(Applause)

GERT DÖRING: So, let's jump to the second issue, which I think is the secondary allocations.

ANDREA CIMA: The question was, is this an issue at the moment or is it something that you want us to continue monitoring or is it something that that needs to be done about it? So...

GERT DÖRING: Is this seen as a problem?

AUDIENCE SPEAKER: Looking at the numbers, I have the impression that this is something we should just keep an eye on it. So, I don't think it is a problem right now

GERT DÖRING: The numbers definitely look like it's not that many. Well...

AUDIENCE SPEAKER: Well, I also have the opinion that we should just keep an eye on it. It's not a problem right now, it's more a problem if you have to re‑number users and this is a very big problem which I find that a lot of people underestimated very much, so for the moment let's keep the things the way they are and have a look and see how things evaluate and eventually try to do some indication if, for example, there are also the cases where an organisation has multiple LIR. Do the multiple LIR need to request each time a new IPv6 allocation? I am not sure, especially that there is at some point a question asking is the IPv6 allocation, will it be used for the whole organisation or just for the...

Then there are a lot of other LIRs that still have the impression that in order to get your first application, first IPv4 allocation, you have to request the IPv6 one, which is no longer the case for quite sometime. So... well...

GERT DÖRING: We have certainly ‑‑

AUDIENCE SPEAKER: Doing something at education level might help preventing this from becoming a problem

GERT DÖRING: We certainly do not want to discourage people from requesting an allocation.

AUDIENCE SPEAKER: Erik Bais. Looking at the numbers, there is not a relationship from what I see from people that are actively abusing the /22s, because they are actually setting up an LIR and create a new, and they just go for the LIR for the v4 part and not for the IPv6 part, because otherwise there would have been parties in here like 39 or even more /29s in there. So, from ‑‑ I see where, you know, this might originate from. I would suggest, you know, keep an eye on it, but I don't see a problem at this point.

GERT DÖRING: I think the message from the room is clear. I second that. It's good to have an eye on that. But it doesn't look like a problem.

ANDREA CIMA: Okay.

SANDER STEFFANN: And thank you for keeping an eye on this stuff

GERT DÖRING: Let's jump to this one. I have one candidate already.

AUDIENCE SPEAKER: Tasha, consultant for German Government speaking on behalf of them. We were involved in the policy proposal which changed the initial allocation criteria, and we discussed this issue of the subsequent allocation criteria already when we made this other proposal, together with Mathew from UK MOD and cough land, and since then we thought of, okay, we should perhaps do a policy proposal adapt the subsequent allocation criteria too, and now we want to do it. So, we think it's an issue. We think it should be adapted and to be in sync with the initial allocation criteria, and what we really like to see is some support for it. We don't want to do it for our own. We want to have a small community developing this policy proposal, discussing it. We need a co‑author for it. So, feel free to talk to me, say hey, we would like to support you and we plan to start immediately after this meeting.

SANDER STEFFANN: Thank you. People volunteering, always good from a Chair point of view.

AUDIENCE SPEAKER: I just have a question. NRI from ENW. I have a question in the direction of the NCC as for the adapted policy for the initial allocation.

Since this has been in place like 12 to 15 months, how many numbers, how many applications for allocations larger than /29 have you seen? I'm not interested like in an exact number, but is it ten or is it in the hundreds? And how many of them have succeeded like percentage wise? Is it ‑‑ have many of them been rejected or accepted? I just want to get a feeling is this in use kind of off.

ANDREA CIMA: Michael wrote an article on labs putting some exact numbers in there, but we're talking about like, maybe, 6, 7...

AUDIENCE SPEAKER: Marco Schmidt here, policy development officer. We have received tens of such applications. As far as I am aware nothing has been rejected. Several are still ongoing because it requires quite a lot of documentation and I think a handful has been already finalised.

ANDREA CIMA: And what I want to say is that the numbers do not seem really, really high, but those are the kind of requests that in the past were very difficult to approve and organisations that have been submitting those requests in the past have been working for many, many months trying to gather information, trying to see how to justify their needs according to the policy. So, what we see is that the changes in the policy have really benefitted the deployment, the large deployments of IPv6.

AUDIENCE SPEAKER: Hi. Carlos from the Portuguese research network. I agree this needs to be addressed, and I'm volunteering for this work. Perhaps the timeline is not so great, but we need to do this.

AUDIENCE SPEAKER: Jano Zsako again. I think since there are no possibilities to request address space, it makes sense to adapt the policies to these ones as well. I am curious whether you keep track on which basis the allocation was made originally, because if you do, we could even consider allowing lower, or other criteria for a new allocation for those who got it based on the new criteria.

ANDREA CIMA: The larger allocations that we have issued were based on the new criteria that the policy had brought in.

AUDIENCE SPEAKER: So it's clear who ‑‑

ANDREA CIMA: It seems to work.

AUDIENCE SPEAKER: Then it makes sense to treat these a bit differently perhaps.

AUDIENCE SPEAKER: Just a comment on the comment of Andrea. From my perspective, the large allocation requests are so long ongoing and the people are working so hard to gather the data to justify the space and so on, this proves that there is, until now, a completely no abuse of this policy that someone says okay, I just need space and I don't want to justify and I just misuse this criteria. They all take it for serious to follow these policies. So I think it's a good thing

GERT DÖRING: Speaking as an individual concerned about policy, I don't think we should make special treatment for additional allocations depending on how the additional allocations came to be. Because we have large allocations going back like 15 years, and treating them differently depending on how the initial allocation was done is going to make our life complex and miserable. I like the approach of just aligning the policy for additional allocation much more, so I thank at that heart for actually he approached me yesterday already and said this is coming and I said oh my God it's not another policy proposal but it's a v6 proposal that is fixing something in the policy that is in need of fixing. So thanks for volunteering on this. Thanks Carlos for joining. Let's have a go. Thank you.

(Applause)

And with that, we go to this. And I'm not sure we have an opinion on this because it's legacy resources but let's hear the room.

AUDIENCE SPEAKER: Erik Bais: Yes, so I have seen this and actually seen this in practice. All the resources, whether they are legacy resources or not are actually listed on the inter‑RIR transfer statistics, so there you can actually see where the certain resources, where they came from. Looking at how quickly resources are actually being in use or getting in use, or whether it's a transfer or the actual end user where it's being allocated to or transferred into, it is well within the parameters of the need base assessment for you know 50% in five years. Because the majority of the transfers will actually, you know, make sure that the actual space is going to be used typically within three months. So even if they split it up or resell whatever is left or transfer it out, it is actually what it is. So from that perspective, it is actually used.

On the part, can you actually do something about this? This is a difficult one and I actually struggle with that as well, you know, writing some of the transfer policies. There is no limitation on legacy, and if we want to change this, we need to change the actual legacy transfer ‑‑ no, the actual legacy services policy. And I have no opinion at this point if that is something that we should do, because I think the things that we're doing here, or what's happening, may not be in the intent of the transfer locking, the Mons or those kind of things because it's actually being used, you know, it's not stockpiling from what I see. (24 Mons)

GERT DÖRING: I'm curious about the detail. How do legacy transfers work in our region? What's the man IX behind it because it's not transfer policy, so holder just approaches you and says please update registration or...

ANDREA CIMA: If they do that, but when it comes to legacy resources, if you have a maintainer to an objector, you can give that maintainer to someone else without contacting the RIPE NCC, so we are quite out of the loop when it comes to legacy resources. There is no policy that mandates you to come to the RIPE NCC and to update the registration or at least the information that the RIPE NCC has. So, some occasions it happens, on some it doesn't I agree with what Erik is saying, it's a difficult case, a delicate situation, and our only concern here, and that is what we wanted to make you aware of, is that if today organisation A receives blocks of addresses and organisation A is the recipient and tells us, yes, because of the policy I will tell you that I'm going to use 50% of it in five years in in way, the day after organisation A, the recipient breaks it into 50 blocks and gives it away to someone else, there seems to be an inconsistency in what we have been told and what is actually happening. That was our concern and we wanted to make you aware of it that we see this.

SANDER STEFFANN: The case you have just described sounds more like fraudulent behaviour than anything else to me. I mean...

ANDREA CIMA: It's according to policy you are allowed legacy resources holders can do that.

SANDER STEFFANN: If I file a plan and within a day you change it, you can say the plan changed, but that doesn't sound right. You mentioned in your presentation ARIN allows out bound policy its on the condition that we have a needs based policy. If then people can just file fake documents and then just ignore that, I can imagine that people in ARIN wouldn't be too happy with that either. So, I can see the problem, but the solution would be to apply all kinds of rules on legacy space as well and we intentionally decided not to, so there is a big conflict here in what we should do and I agree, this is definitely not an easy one.

AUDIENCE SPEAKER: Erik Bais: Yeah, to give you a perspective on that, Sander. One of the things that if the actual company that is actually getting the resource out of, in your case, ARIN. You need to provide documentation how it's going to be used. There is nothing that says that your plan says, you know, this /16 and we're going to break it up and this /18 in that /16 is going to be transferred to company A. There is nothing that prevents you from doing that. And that's perfectly acceptable.

GERT DÖRING: If it's being put to use, because somebody ‑‑

ERIK BAIS: Because it is in use. And actually, one of the biggest issues that we find in this whole process with inter‑RIR is actually dealing with the originating RIR, and in facilitating address policy or number resources to other companies, getting that space in a more, you know, in an environment where we actually have more control over it, like the RIPE database, you know, it's a fine line, you know, where you say this is how we are going to use it on one side and actually providing a service to the customer and then the opposite of the spectrum is you know, let's lie to the NCC and we'll say of course we are going to use it on the DSL, and then two days later, sorry, we don't do DSL. You know, there are great parts here but there are more ‑‑

SANDER STEFFANN: It sounds like this is more an educational thing, because according to what you say, we could just tell, you don't need to lie to us, you can just be honest about what you are going to do with it.

ERIK BAIS: Exactly. But the thing is, we need to be clear on how we are going to perceive, if you are buying a block and then break it up for different purposes, at least be honest about it, because if the prefix is actually going to be in use and you have a valid use case for it, by all means.

GERT DÖRING: It's used.

AUDIENCE SPEAKER: We have seen in all of the inter‑RIR transfers we have done, no evidence of any type of speculation and I would ask RIPE NCC to provide any type of details if they think that there is a problem going on where people are changing their plans that are being justified. I know that all of our customers have used all of their addresses. In fact, RIPE NCC space is some of the best space in the world, specifically because of these policies and because of the ability to transfer ARIN space into RIPE. Now, I mean we have also seen transfers going from RIPE to ARIN as well, so I mean, do we have any approve that this is even a real problem or are we just chasing a boogeyman?

ANDREA CIMA: If I may answer this? I haven't been talking about speculation and of resources and we stay far away from that. What I can mention and what we do see is, and that was my concern that I wanted to bring up to you, is that if a recipient gives us a plan an how to handle what to do with certain address space, and the day after you see that, or the day after, a week after or a month after you see that that block gets split into many different, in many smaller blocks, that is a fact, this is something that we see. What that is due to, if it's speculation or something else, we don't know. I stick to what we see when it comes to objects and to the kind of information that we received. That was the concern I wanted to bring up.

GERT DÖRING: So what I'm hearing is that you might just want to encourage incoming transfers to be open about it, if they have the plan to then distribute it within the region, just say so, it's making use of the addresses. They are not going to be stockpiles, people need addresses.

ANDREA CIMA: Yes.

GERT DÖRING: Just be open about it and then there is no change of plans in the next day, if it's in there, if there's a need. It might complicate the documentation a bit instead of saying we will use it in RDSL and the next day they transfer it, you just put in there what you plan to do it for. But then this is really all on the open, no sort of like hidden agenda, speculations on what people might really be up to. So, it's up to being a bit more open about the documentation, and I think there is people here that would be happy to help with good documentation.

I don't certificate receive that the Working Group sees this as a serious problem that we need to tackle which cannot easily do because of the legacy space. It's good to be aware of. If something needs to be thought of...

ANDREA CIMA: Okay. Thank you very much.

GERT DÖRING: And with that, thank you very much for bringing up these, and having good input on what we might think about it. Some applause for Andrea please.

(Applause)

So, just I forgot to put up that slide on discussion rules. You are well aware, you were all very, very disciplined, thank you very much. Now it's Erik again, who wants to I think do something about IPv4 or so. You have met Erik before, he has been very active participant in our policy process and let's see what he is up to now.

ERIK BAIS: This presentation actually came, you know, from discussions in previous RIPE meetings. And we're actually hoping to inspire some discussion here and on the mailing list later on this, and specifically looking ahead, moving forward. Because, there is the end of the road. We need to ‑‑ you know, we can create multiple policies on how we work with scraps. Well basically it actually looks at an empty barrel and you know, there is only so much that we can do and we have seen today that on certain things to lock things down even further or not, or give it out for free, whatever.

We come to a point where the actual consensus on specifically v4 policy where the actual current policy is not broken but it actually tries to favour certain parties might actually, you know, have a diminishing return on the amount of effort that we put into new policy for it.

Then there is this: And this is something that was spun up in the IETF, although it actually expired as a draft, it is an interesting part to see how, you know, do we need to stop talking about v4? Because, v4, as it says here, has been superseded by v6 and is therefore historic. And that's an interesting way of looking at it. Although I don't think that we're there yet, but it's a good point to see where we're going.

And I think that we need to shift our focus, so if you focus on what you have left behind you will never be able to see what lies ahead. And this is something that is extremely important in where are we going to put or focus? Where are we going to put or energy?

So, if you want to do something you never had, you have to do something you have never done.

And what consumes your mind controls your life.

So if we keep talking about v4, we keep talking about v4, we keep talking about v4, put the energy in v4. And the thing is, v4 is dead. The end is here. You know, we need to start looking at the future.

So when you focus on problems you'll have more problems. When you focus on possibilities, you'll get more opportunities.

Miserable people focus on things they hate about their life and happy people focus on things they love about their life.

And that's the ‑‑ the mind is actually a very interesting mechanism. And you'll see this with all the inspiration al speakers that you have, the personal coaches, look at Tony Robbins, or similar kind of guys, it's about putting the dot in the future and work goal‑related. We need to look ‑‑ shift the focus from what we had and we need to go ahead. We need to focus on what's in the future.

And if it is important for you that, you know, how we're going to get there, you'll find a way. If not, you'll find an excuse.

Whether you think you can, or you think you can't, you're right. And it's actually interesting, I didn't include it in the slide here, but it's actually an interesting way of looking at you know some of the number organisations in this community and their name is actually I can!

It's time to change. So, we need to change either we need to stop talking about you know stop the AP Working Group. We need to look at policy in general, or, perhaps we need to change the current charter, because you know, the charter, the current charter actually talks about v4, v6, and AS numbers. And only focus on current and future protocols. What is ahead.

Obviously there are things that we may need to cleanup, you know, Nick mentioned one of them, Andrew addressed something, you know, what are we going to do with legacy resources that come back, do we need to hand them back to IANA or not? You know, give some guidance, there are always some little things that we need to look at. But the majority of the work needs to shift in focus and we need to put our energy where it's actually put to good use.

Are there any other ideas on this? You know, fill in the blank, think outside the box, because we need to get a state of our mind of of wonder, what have... you know, where do I need to go and how do I get there? And this is where the community actually thrives. We need to ask ourselves you know, how do we get there?

So, I had to look up in the mail archives and they are actually pretty good, when Address Policy was actually created, and it came actually that it came from the LIR Working Group that was split into Address Policy Working Group and services related NCC related stuff in Services Working Group. And it was around 2003.

So, policy Working Group might be a way forward if we decide to you know abandon AP Working Group. We can say let's do v6 in v6 and Routing Working Group can do something with AS numbers. Services group does something with the NCC Services. And then there is always policy related, you know, overall things that we can talk about, you know, policy. And that might actually be an interesting way of looking at this.

So, this is another option: Looking at the current charter and this is something that, in this whole process, you know, looking at what happened in the last month, we may need to look at you know, how we're going to do this. Do we want to rehash certain policies or ideas, because they are rehashing of rehashes? Or do we need to have a stronger discussion ‑‑ a stronger say by the chairs or moderateers on the discussion by saying guys, this is off topic, move out of the way. You know, take this off line. You know, keep on topic. Those kind of things. So the current charter for the AP Working Group, I actually looked it up in the mailing archive, because I couldn't find it on the website itself until Hans Petter actually pointed out to me it's actually on the Address Policy Working Group website. So on the page itself, it just doesn't say it is the charter, so that was interesting. But, it is actually there for everybody to read.

This is the part that I actually took out of the mail archive, and there are some topics here where we can say, you know, it may actually need updating. So that is something that we can do regardless of the whole discussion here on how do we move forward.

One of the interesting things in the charter on the mailing list was actually that I found that the Address Policy Working Group meets three times a year.

So, one of the things that may also help in this whole discussion is a stronger, you know, or a different governance, so we might say a stronger role for the chairs to say you know, as a moderator on certain topics when things go off line or off topic, perhaps look at how do certain policy, how do they actually come to the whole PDP process. And are we actually using the PDP process correctly. So those are things that are currently, that we need to have a good discussion about.

A lot of the mailing list chats are either ping ponging between one or two people and we want to keep the discussions as much on topic because you know, there are things like IRC and personal e‑mail that people can use for you know discussions between, or among each other. And it is actually ‑‑ it would be a shame if we lose people on the mailing list for Address Policy Working Group in flame wars or other reasons because we actually need the participation of the community and we need to keep the community together, so one of the questions is you know, is the mailing list the best way of dealing with those chats? How are we going to facilitate, on the one hand, what is the discussion between those without people actually going, you know, unsubscribing from the mailing list because of the amount of chatter on it.

So this is the big question. And I know that you know, dear Remco is in the other room currently. Nobody needs a rerun of another policy of Remco about the final /8 scraps. I just... you know, we need to move forward. We need to look forward at what we need to do. And it's ‑‑ although it was an interesting discussion to have, there are diminishing returns on this.

This is basically what I wanted to put on the table. Microphones are open. Raise your hand, press the button, let us know.

GERT DÖRING: So thanks Erik for actually taking a step back from just to day to day policy proposals to the larger picture and asking where do we want to go. This is important and it's important it's coming from a member of the community and not from the Chair. So, we have 20 minutes. Go!

AUDIENCE SPEAKER: Thank you, Jan Marco from the RIPE NCC monitoring the chats online. I have a comment made by Sascha Luck, speaking for himself who would like to support to move to concentrate policy work in central B WG and also made a note that there is also a v6 related proposal in APNIC Working Group and not in IPv6, and that's 2016‑04. That might be worth a look. Thank you.

AUDIENCE SPEAKER: I think this is, this concerns much more than people in this room than the Address Policy Working Group, if we are to do something like this, I think this is something that has to be discussed probably in a Plenary since it concerns, it also concerns other Working Group, for example the most that have been presenting are routing and IPv6, and splitting, saying that the policy has to be done by each group individually may lead to a situation where you have, let's say, global policies that concern all kinds of resources and that get differentiated. For example, you have transfers for IPv4, transfers for IPv6, transfers for AS numbers and each of them have different rules at the point that you start getting lost at some point. So, personally, I think that number relating policies should be kept somehow together and well... this is my opinion.

AUDIENCE SPEAKER: Jim Reid just speaking for myself. First of all, I must complain that Peter is going to get to speak after me because then he can see he is going to disagree with me. Would I like ‑‑

GERT DÖRING: Just disagree with him beforehand.

JIM REID: Erik, I am very, very keen, and grateful for this presentation. Since we're actually in the v4 run out, I think it would be good to think about what's the future for this Working Group, and my own personal thing is possibly a bit of v chat erring is called for. I don't like your suggestion about the idea of having the Working Group Chairs have a more proactive role in if you like filtering policy proposals and stuff of that nature. I think that crosses a boundary where the Working Group Chairs are supposed to be considered neutral and impartial. These matters. So I think that's maybe a bad idea. But we can a further discussion about it.

However, I want to be provocative, it's not like me, I know, and what I would like to suggest is how about you and I write a policy proposal where we say that we will no longer entertain any discussion whatsoever of any policy to do with IPv4 allocations. That's done, we're finished with it. And any further work that happens here can then focus on v6. Now, we might have some other issues around v4 that may need to be looked at say, for example, about improving the quality of the data in the database, cleaning up contact objects, that kind of housekeeping type of activity. Proposal along those lines would be fine. But anyone that's suggesting changes to how we allocate v4 addresses, no, we just stop that. Because that discussion, quite frankly is like a bunch of old men who are bald, arguing over a comb. So if you and I, let's have a drink or something, and we should write up a policy along those lines if you are agreeable, I have let lit the blue touch paper and let's now watch for the fire watch.

ERIK BAIS: There is another option in that. And that is actually in the PDP process, there is a discussion phase. There is one option that we are currently not using, and that is actually discuss on the mailing list in the Working Group this actually something that has consensus as a problem? So if there is no problem, why do we get a fully written down policy proposal on the mailing list that we yank into the PDP and if we actually start usersing the PDP differently that might also be an option to say you know, there's no consensus in the room to even get started on this, because there is no clear problem statements, you know, that might actually have a similar you know result.

JIM REID: Maybe, but Erik, my feeling now is that we are probably never going to get consensus in this Working Group on anything to do with v4 and the smart thing to do in my opinion now is just stop talking it.

ERIK BAIS: I agree.

SANDER STEFFANN: If a couple of little cleanup things we need to do, like this queue algorithm

GERT DÖRING: That's housekeeping. That's not policy.

AUDIENCE SPEAKER: Peter Koch, I apologise in advance because I cannot fully disagree with Jim. So, Erik, I think you found some issues with the PDP in general and not so much with things that happened in this Working Group. But let me come to that later maybe. What you are trying to do here is actually what Jim probably kind of tongue in cheek expand add bit on which is like petrifying the v4 policy status. Do I not believe ‑‑ well I have a political signal that might be interesting, I would suggest that this is in conflict with the current PDP because the PDP doesn't allow lock of policy that is would be on the operational side. So while the idea may have some merit the problem is at one point in time one will find out there is a tiny loophole in there in the current policy that needs fixing and then you are screwed. That's the second argument against that.

Also, by closing this Working Group, you'll not take away the ground for discussing new policy proposals. Policy proposals will pop up anywhere and then if you look at the PDP there is a fallback and it's the RIPE Chair to take care of that. Again, while I understand the political signal, this is like wandering around the PDP and won't achieve that final goal. People will discuss this, or even kick up a new Working Group.

ERIK BAIS: Yeah, but cannot just start a new Working Group. That means you need to have Plenary consensus, or you know, a majority in the Plenary, you need to take it to the Plenary, you need to start a birds of a feather twice ‑‑

PETER KOCH: That's an IETF stuff, no, and you don't need majority because I have been told conusely that we don't do voting, we have a very strange way of not voting (continuously) the threshold is not too high.

ERIK BAIS: The threshold goes up.

PETER KOCH: What happens and the risk is you get only a concern interested bubble group to spin out that new Working Group and actually define RIPE policy and if you want a bad example for that, look into Anti‑Abuse, right? Things happening there affect everybody and go under the radar while following the PDP. So things are a bit strange already. Anyway, keeping by chairs, I don't think that's ‑‑ I fear, I agree with Jim there, that's probably not the best idea, and finally, please, we have had blunt discussions, people have been over doing it, but this is not the end of the world. Can we please stop to refer to the previous discussion on the list and then try to change policy around this because we need more tools. This is how security people try to influence politics these days, yeah? One thing happening and every law needs to be, every legislation needs to be changed. No, the tools have actually worked. Of course that's after the fact, but that's a fact of life. So, we don't need more moderation, we don't need stronger rules for people getting to the list, but maybe you need stronger rules for me getting to the mike and that's it.

GERT DÖRING: I find myself in agreement with Peter which is strange enough.

SANDER STEFFANN: What I'm actually feeling here is that people say don't close down v4 policy completely, but maybe ‑‑ I kind of feel that as chairs we need to be nor selective because the PDP actually says that the Chair has to accept the policy proposal into the Working Group, that maybe we need to be a bit more selective there

GERT DÖRING: What we actually can do, which is fully in the bounds of the PDP, is to play the discussion phase a bit differently like actually converge on the problem statement before formally putting the policy proposal in the machinery.

SANDER STEFFANN: Which is actually how the PDP was designed. We have just had a proposer who actually started the discussion with the policy proposal which the PDP doesn't require.

AUDIENCE SPEAKER: Filiz Yilmaz, Akamai Technologies and I will try to be brief and I would like to remind as of the housekeeping matters. Just for everybody, we were having a side conversation about this yesterday, the setup of this room is like you have your personal mike, that makes you unaware of the queue behind you. So normally we are auto sensoring ourselves from the time you take, if you see a queue behind us, this time we don't. So can I call for everybody to keep your comments brief, which I will try to do myself.

So, thanks for bringing this up Erik. I think as a community we will evolve, our industry evolves and I think there is merit and there is usefulness in looking into our procedures from higher, more helicopter perspective. And thanks for the history of that. A little bit of it where I was involved as the RIPE NCC staff, so I remember things because I was in the middle of conversations during that time.

There is ‑‑ I want to remind you that everybody as well, just to throw the idea there. I don't have an opinion yet. I think we need to discuss this more, but there is merit in having smaller Working Groups. Traditionally the Working Groups were created in the sense that they are deep device, you know, with the subject matter experts with specific interest in a topic how we do things. If you create overall more broader policy Working Group where you know, policy about routing can be discussed there, policy about NCC Services can be discussed there, version 6, version 4, you may lose that expertise part because then it will be diluted and since it is so big people may be starting missing things. A lot of people are paying attention to this because it is about address space you see. And maybe I'm thinking, instead of changing the structure of our mechanisms that really work so far having this division we could introduce more cooperation between Working Groups, more strengthened cooperation which puts a lot of weight on the Working Group chairs fact, they need to work for closely, which subject will be discussed in which Working Group if it is lying in the grey zone in between two Working Groups and then make necessary calls for the other Working Group, we will be discussing it here, instead of, you know, the Routing Working Group. But for that you don't need to create a new one. You just need to strengthen the cooperation between Working Groups I think.

And in fact, this is not new. We had that with a few subjects like that lying in between, but the communication issue rather than you know creating or changing our structure overall upside down. Thank you.

AUDIENCE SPEAKER: Marco, RIPE NCC. Let me be very clear, I have no opinion on where to move forward, how this move forward which also means that I can't agree or disagree with neither Peter or Jim.

But, because of my job, I happen to be in that room in Buenos Aires I when the IETF had the discussion and I would like to share some observations because I do think they are relevant and that is that there are a lot of people out there watching this space who may or may not be fully aware of how RIPE internals works, setting up Working Groups. We although there is a way around it if the need arises. Let's be honest, we all would love the day to come, but IPv4 is around will be around for the foreseeable future. The problem then is that as search needs emerges that might be perceived as a gap if this group or RIPE in general says in general we'd rather not discuss IPv4 and that perceived gap exists there might be other international or intergovernmental organisations that would volunteer to pick up that slack. Now I'm not speculating on the outcome of such discussions, where and when they cake place but I do want to urge the community as this discussion moves forward to occasionally take a step back and take a look on how this would look with people to people that are not really involved with RIPE and the internal procedures of this Working Group. Thank you.

AUDIENCE SPEAKER: Benedikt Stockebrand. I think Peart and Jim are both right in a way. I think yes ‑‑ and Erik as well ‑‑ we should leave IPv6 behind but that's more of a personal thing, and less of a ‑‑ well, we're not going to do about IPv4 anyway here so people are going to have to stop use it, that doesn't work, it would be nice but you can really start only with yourself. However, what I think what we should be careful with, because the IETF really screwed that up in my opinion, is that we should make sure that whatever we do here does not prolong the misery we have with IPv4 on a policy or whatever base. We have seen too many transition technologies that just delay the inevitable, and we would have been better off without these. So, that should really be our focus here when it comes to policy. Make sure that we can move on towards IPv6 as quickly as possible and not try to cater for all the immediate perceived needs of the IPv4 die‑hards, so, we slow down everybody else.

ERIK BAIS: I want to make one comment on that. There is actually a good term in consultancy and if you are not part of the solution there's good money to be made in prolonging the problem. And that is actually, you know, where we need to look at. You know, are we actually going to fix this and are we going to look ahead, or are we going to try and prolong whatever is a dead end?

AUDIENCE SPEAKER: You say the IETF is mostly run by consultants?

ERIK BAIS: I'm not saying that.

AUDIENCE SPEAKER: Janos. First of all, I would like to thank Erik for this presentation. I think there were a lot of positive thoughts in it, and it is good to look at the things from a different perspective and not the daily problems we have.

At the same time, I think it would not be a good idea to decide not to talk at all about IPv4 policies in this Working Group, because that would also be against the last /8 policy. That was the intention to be able to keep as much as long as we can some parts of the address space for those who want to enter the market and need it for transition and whatever. So I don't think it would be wise to close down the IPv4 discussions, because as Peter also mentioned, there could be a loophole and the whole pool would disappear in a couple of days, let's say.
So we have to keep an eye on the IPv4 as well, but I agree that we definitely should concentrate on the future and not on the small problems of distributing the last bits. Thank you.

AUDIENCE SPEAKER: Rado Sardan. Well, most of what I wanted to say has already been covered. It's the issue of, well, actually I have a question: Do we need to revise the PDP itself? For the moment you have to submit the policy in order to start a discussion phase. Do we have to ‑‑ and this is something that, again, if we have to do it, it has to be pushed to the Plenary, do we have to come up with something else we start with a problem definition, discussion, then proposal?

GERT DÖRING: No. That is, we do not need to change the PDP to change the way we run the discussion phase. So, if you want a formal proposal number rubber‑stamped by the NCC you need to submit the formal text and get a formal number entry on the web page. But if you just post a mail to the mailing list saying I think we have a problem here, can we agree that this is a problem and that we should be doing something about it. What we do in the Open Policy hour in here, just try to agree that there is a problem. This is part of the discussion phase without being a formal proposal, and then after that, to say, okay, we have agreement that there is a problem, and writing up something and submitting this as form will al protocols proposal. This is perfectly in line with the PDP and it's more lightweight than submitting the full proposal before we have agreement with the Working Group that there is an actual problem.

So, this is what I'm taking away from this discussion that we should try to be a bit more lightweight on formal group holdings. Have agreement beforehand on what the formal statement is and then come up with policy text to actually fix it. We will see how that is going to work out, but ‑‑ well we are fully optimistic to help with that. But you actually don't need the chairs at that point. Just posting to the list and saying I think we have a problem here, I agree with or do you think everything is fine? This can be done by anyone on the list. So you don't even need the formal agreement of the chairs for that.

JAN ZORZ: We have three minutes left and we have Nurani and Daniel in the queue.

NURANI NIMPUNO: I'll keep it very short. I agree with some of the comments that both Janos and Marco gave. Thanks Erik for bringing it up. I think it's a healthy discussion to have. But I think it is incredibly important to have a place where you can discuss v4 policy, even if there's nothing to discuss, just having that avenue is incredibly important and this is where those discussions should happen. Not elsewhere. So, even if that means that at some point we'll end up having an Address Policy Working Group that's only one slot and, in fact, it takes half an hour and there's no discussion, that's fine, right? And then we can all go and get on with our lives. Plus, that, you know, even though there have been ‑‑ let's not overlay some of the turbulent discussions. I have sufficient trust in in this community and in the chairs to ‑‑ that we will continue to have constructive and relevant discussions. So, let's continue on that path. Thanks.

AUDIENCE SPEAKER: Daniel: Just a brief comment to what Gert said and Rado's comment. You know, I know it's a case to present a problem or a proposal. But, I like the way they have now in the Database Working Group where you actually are not allowed to discuss solutions before you can agree on if there is a problem, because it seems quite a lot of times in this Working Group that someone presents a proposal and it's not a discussion is this a good proposal or not, etc., etc. And if you say okay, you should encourage people to present a problem, and then we can discuss is this a problem and then if we have a consensus okay, this is a problem go ahead with a solution, I think that would spare a lot of time

GERT DÖRING: Okay. Thank you. Thank you, Erik. Thank you to the Working Group for a very constructive and positive comments and for supportive comments because that makes our lives easier to know we have support. Thank you.

And ‑‑

SANDER STEFFANN: I just got a friendly reminder that the NCC asked me that there is a lunch meeting about Atlas in ‑‑

AUDIENCE SPEAKER: It's the ARIN lunch room, the first room you come to, so anyone interested in learning more about RIPE Atlas there will be a developer there doing a short demo and answering questions. Just look for the banner.

GERT DÖRING: With that, I'm not going to step up again. We don't have any pressing AOB as far as I'm aware. And we have no time for the Open Policy hour anyway. But, we have finished exactly on time. Not cutting anyone short. Thank you very much for this. It's an achievement of the room and not of the chairs, so, thank you and enjoy your lunch.

(Applause)

(Lunch break)

LIVE CAPTIONING BY
MARY McKEON, RMR, CRR, CBC
DUBLIN, IRELAND.