Address Policy Working Group
Wednesday, 14 May 2018
At 11 a.m.:
GERT DORING: Welcome back, and I have been told that this room is much more practical for reading emails so don't let me disturb you too much. This is the Address Policy Working Group, if you are looking for connect, they are in the big room. This is what we are going to tackle now. First item is feedback from the NCC registration services, from Andrea and then the open policy proposals. The usual intro slides to discussions, we don't do decisions at the meeting, as we have heard at the last slot already; we do decisions on the mailing list, but the meeting is to get quick feedback to the proposers to discuss ideas and then we take it to the list. If you want to say; come up to the mic phones so people listening remotely can hear you, please speak your name and if relevant your association, and that is basically it. And handing the microphone to Andrea.
ANDREA CIMA: Thank you, Gert. Welcome to the cosy room, it's a bit smaller than the other ones and the chairs are a little less comfortable. I am part of the RIPE NCC registration services team, and what is the goal of the common slides? The goal is to report back to you. Once a year Gert, Sander and now Erik give us the possibility to talk to you, to let you know what kind of feedback we receive from our members in our daily work, but also to highlight potential issues or things that you may want to discuss that may affect policies.
So, today I will talk about IPv4 exhaustion. We have been talking a lot about IPv4 exhaustion over the last few years, and about a couple of RIPE meetings ago Nick Hilliard brought up the need to discuss what are we going to do post exhaustion with IP addresses that are being returned to the RIPE NCC, and there were similar discussions as well in other registries, as Marco ‑‑ in APNIC so I want to talk a little bit about the road towards IPv4 exhaustion, what are our allocations practices and I would like some input from you but also what to do with IP addresses that are being returned to the RIPE NCC in the period post‑exhaustion.
So, at the moment, we still have IPv4 address space for about two years. Now, two years seems like a long period of time but have seen that time goes really fast and if we want to get through some well thought through policy, this is the time to act. What are our allocations practices at the moment? As you all know, according to RIPE policy, we issue a /22 to every new LIR. Now, we still have about 7700 /22s to give out. Once the /22s as one aggregated block will be finished, then we will start still issuing a /22 in total but this will be divided in smaller blocks so LIRs will get maybe /23 and two 24s or two /23s, so we have about 900 LIRs that will receive a /22 according to this allocation mechanism.
Then, we will have the smaller bits and pieces,/25, 26,/27, 28, even 29s. As it stands at the moment, five LIRs will get those small blocks, to get a /22, and then we have a few 100 IPs left over and those people will not be happy when they get the /28s and 29s, we have seen this in the past. Once those have been issued, then, according to policy, we will be able to issue /22s again from the unforeseen circumstances pool which has been reserved by policy. So 64 LIRs will receive a full /22 again. And at that point we will have exhausted IPv4 addresses. Now, my question is and I would like to discuss those things at the end of my slides is what shall we do with this what we can consider IPv4 dust, small will not make people happy and a few IPs left over after that.
The second point that I wanted to bring to your attention is we have, according to policy, a temporary assignment pool. You gave the RIPE NCC the possibility to decide how much we wanted to reserve for this pool. At the time when the policy was made we deemed/13 as the reasonable amount enough to cover the needs for the policy, and if, however, we look at the maximum contemporary usage of this pool, we have never given out more than a/13, /15, /18 con temporarily meaning at the same time. My question to you is, should we reduce the size of this pool at the moment and maybe reduce it from a /13 to /14 so that another 256 extra LIRs can receive a /22 allocation? That is an option.
Then what to do after IPv4 exhaustion, what shall we do with return to IPv4 addresses. Now, at the moment as you know, we give /22 to every LIR. Every little bit of IP addresses that come back go to this pool and after a period of quarantine are being reissued to LIRs. At the moment you are getting back about 500,000 IP addresses per year, these come from LIRs that gives back the space or are being closed for non‑payment or companies that simply don't exist any more. So these 500,000 IP addresses go back to the pool and are being reissued. But what should we do once we have exhausted the IPv4 pool? Should we create a waiting list, people can sign up to get more IP addresses, should these addresses be added to the temporary pool? There is a certain number of possibility of what we can do with this, but this requires policy change. In ARIN, there is a waiting list for resources, something similar in APNIC as well, actually as Marco presented this morning in APNIC there are discussions about how to manage those pools so I think we should do that here as well.
Looking at the waiting list option, I think there are few questions that we have to ask ourselves and that we should answer, first of all, who should be eligible for this waiting list, if that is the way you want doing? Should it be anyone, LIRs that have received in the past, only new entrants, but also what should the allocation size be; should it still be /22 or reduced to, for example, /24. Those are potential questions. I think the main question is, is it worth it to create a waiting list? We decided to look at the numbers from 2017 and do a small simulation and we asked ourselves what if we had run out on 31 December 2016 and we take the whole period of 2017? How big would this waiting list be at the end of the year? At the end of 2017, we would have 3,000 LIRs in the waiting list. This is considering the number of requests that we have received for /22s. And as a you can see, by the yellow packets which is really small, about 500 LIRs would have received an allocation. So that means that if you had signed up at the end of 2017 for the waiting list you would have to wait another three years in order get your block. And you can ask yourself if you need IP addresses today, is it ‑‑ does it make any sense to wait for three years because if you need them today you need them today and not in three years' time, the question is is the waiting list option a feasible option?
The temporary pool option, now this may seem a bit contradictory to what I was saying before because I told you let's take some IP addresses out of the temporary pool and I am saying another possibility is to add returned address space to the temporary pool. This is another option. We could reduce the temporary pool by half at the moment and then say, okay, all the returned space goes into the temporary pool because even though the contemporary usage so far is not really high once IPv4 has been exhausted there may be more organisations requesting a temporary assignment. Then the other question is, how much should this pool grow, indefinitely, or up to a certain amount of IP addresses, these are things also to look into.
Other options are that lottery system, but this could have potentially legal implications in certain jurisdictions, I think that is something that would have to be checked out. We could even return the IPv4 addresses to IANA, on the other hand IANA would then redistribute them to us so we would still have to do something with them and I am sure that there are other potential options here.
The last point that I wanted to bring to your attention is the IXP pool. There is a /16 reserved for IXPs and this is set aside by policy and the address space is for the IXP peering LANs. We looked at how long will this pool still last and it's going to be lasting at this allocation rate a a little bit less than four years. Do you think as a community that the size of this pool is big enough? Should we increase it because if we want to increase the size of the pool from /16 to 15, then this is the moment to do it and we shouldn't wait much longer because again also in this case policy would have to be changed.
So, for the discussion, these were the four points I wanted to bring out, what should we do with the IPv4 dust, as I like to call it, the little bits and pieces left, should we reduce the temporary pool from /14 to 13, what should we to with the returned address space and do you want to increase the pool size for IXP, so also in the future there will be address space set aside for them? So I think these are the points.
ERIK BAIS: Before I give the questions to the mic, I have a question for. How much dust are we talking about? Is it within the space of a single /22, but in smaller chunks.
ANDREA CIMA: At the moment we are talking about very little, we are talking about less than 5500 IP addresses so as I mentioned, yeah, there would be 5 LIRs that would receive little bits and pieces and then there would be a few 100 IP addresses left so less than 5 ‑‑ one could be add to add them to the temporary pool to get them out of the way.
ERIK BAIS: Okay. Have you considered specifically the option to allocate or specifically have people request them for research purposes for doing routing security leaks, filtering, that kind of research with it?
ANDREA CIMA: That is one of the possibilities. At the moment if you look at policy, it says you have to issue /22s, and we have to issue /22 as one aggregate block and once we don't have one aggregate block any more to give to an LIR we will have to still give a /22 but in smaller bits and pieces but still coming to a /22. Base even for this policy changes is required?
ANDREA CIMA: I think in the past you gave us the freedom to add resources to the temporary assignment spool if, for example, we were to add the dust to the temporary assignment pool, there would not be a policy requirement for them. We would still want to and mandate from you to do so, the backing up of the community but there would not be need, the need for a policy change in that case.
SPEAKER: Lars and this is a comment not to you but to the audience. Can I suggest that whatever policy we put in place here aims at not cementing the use of IPv4 but to facilitate and encourage the use of IPv6 so the policy for the IPv4 stuff should be to encourage IPv6, so we get away from this some day.
ANDREA CIMA: Yes.
SPEAKER: So Sébastien. To return to the dust for a moment, I think to ‑‑ there should be somewhere put away somewhere and if people explicitly ask for it for reasons not, that not require it to be routable on the global Internet, then be my guest, take some of it, yeah. But I think most of the people will not ‑‑ if I get it I cannot use it anyway for most of my purposes so I think we should put it away for special reasons, for special, like research or something, you know, or whatever people come up with. But I think that would require some policy change again.
Gert Doring: This very much sounds like temporary pool. Because if you do an experiment the experiment runs for three months and the is over and you get a /29 for it from the temporary pool, you return it, no policy change needed. Seem indeed that is one of the case cases of the temporary pool for events and to experiment exactly what you are both mentioning.
SPEAKER: You said the temporary pool the biggest assignment was /15.
ANDREA CIMA: The biggest amount we gave out at the same time, so it was multiple assignments but at the same time but all together coming to 15, 18.
SPEAKER: So not one entity getting a /15?
ANDREA CIMA: No.
SPEAKER: I was asking why that would be. Thank you.
ERIK BAIS: Anybody have an idea about what to to with temporary pool size?
SPEAKER: I was actually thinking instead of reducing the temporary pool from 13 to 14 reducing it to 15 and having that dust going to the temporary pool so, we will have in the temporary pool something between 14 and 15 but we give more space for real usage.
ERIK BAIS: The additional IXP pool size that needs to ‑‑ the increase of the IXP pool size that needs to come from the temporary pool as well?
ANDREA CIMA: That is could come from, from anywhere, also from the current pool but that requires a data policy change because the policy mentions that we have a /16 set aside for IXPs so you can also at the side that this is enough and indeed we still have a bit less than four years for peering LANs of IXPs and that should be a long period enough, then we tonight have to touch it. I wanted to bring this to your attention as this is something that is there and it's better to take a conscious decision about it whether to leave it like it is or to expand it, but not just to let it go.
SPEAKER: David farmer, University of Minnesota, ARIN AC. I wanted to bring us to different question you had earlier and that was is a ‑‑ is a waiting list useful? And I think that is the wrong question. The policy purpose of a waiting list is to ensure there is no IPv4 at RIPE or at whatever RIR, it's not to provide an effective means of getting resources to LIRs; it's to ensure no resources sits stuck at RIPE in this instance. And that there is a fair way to push that out. So if you are asking is it effective, hell no, the not effective, but it's a way to ensure that the resources aren't stuck some place, which is a good policy intent.
ANDREA CIMA: Thank you.
SPEAKER: Consultant for German government. I am not quite familiar with the issues of IXPs, I must say, but this IPv4 stuff is a thing which is, we have too less of it so we have to make priorities and the question is, what are our ‑‑ what is our priority list? What do we want the last IPv4 addresses used for? And from my perhaps not perfect point of view, the IXPs are one of the core parts of the infrastructure of the Internet, and perhaps we would like to have them running as long as possible with this IPv4 stuff, even if we all have the aim to get rid of it, we would like to have them going on working with the addresses rolled out. So perhaps it is a wise thing to think about increasing the IXP pool and getting this ‑‑ these addresses from the temporary pool, I don't know? But perhaps someone who is more familiar with the IXP needs can have a comment on this.
ERIK BAIS: The majority are probably in the Connect Working Group currently. But I do agree with you, yes. But what Andrea said, we need to have a policy change on this and it's definitely worth having a discussion with the people in the connect group as well to see what they are predicting. If they say well, you know, we have seen a ramp‑up but the amount of IXPs will actually stabilise at some point, you know, that is okay. If they say, well, we don't see any change in this and this is actually go linear as we see it currently, then it's over four years and then I think I agree with Sasha, we need to see if we need to increase this, rather sooner than later, I think.
GERT DORING: So I am hearing at least one guidance that we need to take care of and that is bring this question to this list and the Connect Working Group list so they are aware that we need their input.
So what to do with the returned addresses? Anyone any comment on that? My gut feeling is just put it into the pool because then we don't need to do any extra process. We have a process today what to do with returned addresses and that is in the pool.
ERIK BAIS: That means that we will have to, indeed, create a waiting list at a certain point for LIRs that are requesting resources.
GERT DORING: We will have to have some sort of mechanics, how to distribute the remaining pieces in a well‑defined way, whatever that is, because there might be addresses coming from IANA, like somebody else returning a pre RIR junk to IANA and then IANA distributing it so we have to be prepared to deal with, oh, addresses.
ANDREA CIMA: Like I mentioned, we have about half a million of IP addresses being returned to the RIPE NCC on average a year so inteed that would also be a return. But if we leave things as they are we to not touch the policy then yeah, indeed, organisations will sign up, become member, become LIR, request resources and then we will have to place them on a waiting list and organisations ‑‑ LIRs would still expect a /22 so the size would be the same as currently and also who qualifies for a /22 would be the same as today so there would be no change in there. That is how it would be.
ERIK BAIS: I have a question. On the signup or the requesting of a new resources in the LIR Portal is it possible to close down the request as soon as RIPE NCC is out of IP space and if they get chunks of IP space that they say, well, at that point we will actually open up the request again so that you don't get a waiting list of 3,000, 4,000 people and actually have people that need it at this point actually requesting it at the point that you actual have it but there needs to be communication?
ANDREA CIMA: I think in any case communication will be a key to local Internet registries about what the situation is, but especially if we keep the policy as is, indeed it must be really clearly communicated to them what they can expect and when they can expect it, to avoid surprises where people become a local Internet registry, they want to request a /22 and then they see I to have to wait for a couple of years to get it, we want to avoid that. And then when it comes from a technical perspective what we can to in the LIR Portal, I think we can do a lot of things, wave great engineering things so if we have to do certain things to facilitate we will be able to do that certainly but I think at the moment it's, we should focus on what is it that we want to achieve and how do you want us to deal with the IP addresses that are being returned.
David farmer: University of Minnesota. You need to think about the fairness of, oh, we turn it back on again and then it's whoever gets there first and it's going to be a rush model and that may not be the host fair way to deal with that.
ERIK BAIS: So will a lottery, probably.
PETER KOCH: DENIC. So on the suggestion of a waiting list which I guess is coming from the idea that first‑come/first‑served needs interpreted even if there is a no supply and I demand something I am in in for an assignment or allocation in that case, maybe that needs a bit more analysis from a legal/policy side and I guess you did the legal part but I think first‑come/first‑served with be argued both ways. If you ask for something and it isn't there, if you want to register a domain name and it's already gone, you don't get it. If there is no addresses and you want some, you lose, if, in 15 minutes, somebody else returns an address and then, in 30 minutes later, somebody comes, they get the address. Both scenarios are open for abuse or say will attract specialised industry to gain the system, so this is something that, yeah, needs ‑ I think, a number of brain cycles because the price will go up and so will the resources invested by specialised industry.
GERT DORING: So actually, we play that ball back to you.
ANDREA CIMA: Thank you. Yes.
GERT DORING: Think more about aspects of that, and maybe come up with suggestions, what we could to and what the consequences are, from the NCC point of view and then we can make a more informed recommendation, discussion, policy, whatever is the outcome of this.
ANDREA CIMA: Yes. Okay. That is clear. I think we can take it from here, and as you mentioned with regard to IXP send an email to the list to discuss this further and if you are okay with it, you could also send an email to the mailing list about IPv4 dust if it would be okay to move this to temporary assignment pool and we will work a bit further on potential solutions for both run out returned address space. Thank you very much.
(Applause)
GERT DORING: My slide is already up so I don't even have doing up on stage. Now we end the discussion of open policy proposal section, we are doing quite well on time, we have three proposals and so we have 20 minutes per proposal. If you take too long you steal your own time. First proposal, Jordi can take it from here. This one is special, in one aspect, it has three proposers one of them is now Working Group Chair, so for the mechanics of this, when judging consensus I to it and Erik abstains. But otherwise it's just a normal policy proposal.
JORDI PALET: Very brief presentation because this has been widely discussed in the mailing list. The idea is basically to clarify terminology because we have mix usage of organisation and LIR and this is quite different from what we had in IPv4 so basically what we are trying to do with this policy proposal is to align the same terminology and the same usage and the same goals that we had in IPv4 already. So, I tried to make as few slides as I could but using like some text scratched and some texts in red so you can see the difference between the, in your left the actual text of the policy and the proposal. So basically, the thing here is the initial location criteria, it's not just generic, it's for LIRs and then we change organise to be LIR and because one of the criteria was be an LIR and now it's four LIRs, we don't need to mention that any more. That is very, very simple change and very clear. Same here, in initial location size we changed organisation to be LIR, and then we took the opportunity also, I think there is a pointer here, to clarify some text that it just an English change but not really changing anything in the sense of the policy itself. So we have three more mentions in the second paragraph about organisation and then again it gets to LIR. Then we have the same in subsequent allocation and criteria, it's just a change between organisation and LIR and then we need to change the wording because here we had that whole and existing and we need to have that have received it and IPv6 allocation and the same here, there was a mix usage of ISP and LIR and it becomes just LIR, okay? So for the subsequent allocation size we have the same thing, it's just organisation becomes LIR and in the second paragraph also the the same change. We have exactly the same in LIR to ISP allocation, assignment to operator infrastructure and registration and you can see here organisation again, LIR, organisation and ISP again, LIR organisation, LIR. We must look up similar situation, we have organisation, so it becomes LIR. I think there is three of them, one, two three, and one two three, and basically, that is it. What we did make sure is that by changing that we don't actually really change the policy except in the sense that now our organisation can have, as well as in IPv4, multiples LIRs and each LIR can have his own allocation so that is aligning the policy which existing usage that we have in IPv4. I don't think I need to read all these, and I think basically what we said, and opposing the proposal, will, may consume more space from the NCC, the pool will dry faster but of course in the band of abuse, we will need to review the policy as we usually do if we discover that. And I think that was the last slide, yeah. Very, very short, I think more or less the discussion in the list was ‑ what we are trying to happen, there is not any argument against unless somebody here want to say something.
GERT DORING: So from the PDP point of view, it went through discussion phase with quite a bit of support, it's now review phase with analysis posted which didn't bring major surprises. So far on the list we had a few questions on the grammar, where the A‑LIR or M‑LIR and I considered that solved but we haven't had voices of support yet and technically we need a few more voices of support on the list. There is no opposition either so wake up. And thanks for picking up the task of fixing our sloppy documents.
THA SHA: For German government. I don't want to oppose it, but when I read this, I thought about why was it originally not LIR but organisation, and I think it had ‑‑ it had reason and the reason is, if you think about a big ISP, the LIR is not the ISP; it is the department of the ISP. And the criterias doesn't refer on the organisational structure of the LIR itself because it's only a small department within the ISP, but it refers on the organisational structure of the whole organisation where the ‑‑ where the LIR is LIR four so it's the LIR is not from the wording and from the self understanding of the organisation, not the organisation itself, do you know what I mean? So perhaps it is okay but perhaps it is a little bit weird for organisations with this self understanding, you know.
JORDI PALET: If we don't do this in the IPv6 policy then we should consider another policy in the IPv4 to align with this one because it's not fair that you have different situations for IPv4 and IPv6, and also we may need policy change in case of accusation of LIR by a previous organisation, that casts in a bad light, LIR. So, I think I really think this is the best way to do that. I don't think going back ‑‑ you said you don't oppose.
GERT DORING: Let's cut this a bit because I have historic context why this is an organisation because the original IPv6 policy back from 20 years ago was a global coordinated policy and since the other registries did not have the term LIR in the word ‑‑ in the sense we use it, the original text said organisation without ever defining what an organisation is. And that is what got us into the mess here in the first place, that wave text that says organisation without being specific what is considered an organisation according to this. So with an LIR here it's very, very precise who, what, which sort of contract is governing this. It's not like it was consciously putting an organisation as the term in here but it sort of happened 20 years ago. So, what Jordi says, all the policy text that originally done here in the RIPE region already say LIR and it's just this one who, which we inherited from the early days.
SPEAKER: If I may have another comment on this. Yes, but perhaps it's a little bit of changing history with this organisation term because with IPv4 it was quite clear that normally an LIR was an ISP and the ISP has this own network infrastructure and he made it for himself and with IPv6 came up different organisations which are LIRs now also, and perhaps it's not so self explaining that LIR and organisation which the LIR is for is the same. Perhaps we should have somewhere a comment on this.
GERT DORING: Well, actually, talking about LIRs is a well‑defined term that has well‑defined contract, to well‑define everything and there is LIRs in IPv4, that are not ISPs. And have been for, like 15 years, like, all the Nicks and ISPs, so I don't think this is a very strong argument.
SPEAKER: Okay.
GERT DORING: So any other comment? So then we considered this not strong opposition, but we still need to take it to the list to get more support.
JORDI PALET: So you think we should even ask in the list for the A or A N LIR?
GERT DORING: No, that one has been covered. It's in line with the other policy texts so whatever people more fluent in English than I say, I don't care as long as our policy documents are consistent across the documents and this is what we have now. But the Chairs will have, so that is us, will have doing to the list and ask for more feedback on this, otherwise we are stuck in limbo with he can tending the review period.
PETER KOCH: You asked for that extension. I re‑read the thing just a minute ago and I think there is different use of language and there is not necessarily fixed by policy proposal and ask for consensus because one talks about being an LIR and the other one is talking about what having an LIR and so on and so forth and unless and until we clarify we mean by either of those, it is hard to achieve consensus because that con census is still covered by the different meanings of the word. So complicated issue, needs more research.
JORDI PALET: You are discussing now a different topic, it's being an LIR or having an LIR, not A or A N.
PETER KOCH: I think the being and having is slightly more complicated than the A versus AN.
JORDI PALET: Okay.
GERT DORING: So, could you please bring that to the list, then?
PETER KOCH: Yes, please.
GERT DORING: Yes, sir. ....thank you. So, next one. Jordi, what a surprise.
JORDI PALET: I have two more later. You still don't know. Assignment clarification in IPv6 policy. Well, basically, where it comes this thing, we had already a discussion during two years, I think it was since 2016, about the clarification of assign, which is the Section 2 .6 of the RIPE, I don't have my glasses, 699, I think, yeah, and my perception when basically the Chairs were already considering the ‑ consensus or the consensus was look, if I read the impact analysis and the policy proposal text I do not agree, there is something that maybe is because I am not native English speaker but there is something that is not ‑ to me. So I even considering making an appeal and thin discovered the broken PDP that I am trying to fix with another policy proposal. And well, the suggestion was, yeah, do the appeal or improve it and, yeah, that is what I am trying to do here, I am trying to say okay, we have consensus, let's try to improve it and actually think it's the best way, the policies have not something forever and we need to keep improving them if needed. So what is the change? It's only this: The basic thing is that the actual text of the policy says providing another entity with separate addresses not prefixes from a subnet used on link operated... is not considered a sub‑assignment. This includes letting connected to the assignment holders network to assignment holders network and setting up point‑to‑point pinks with third parties.
So my proposal is considering as well which I didn't mention in the previous slide, if I can go back this way, I didn't mention this RFC ‑‑ I cannot use the glasses ‑‑ okay. So considering RFC 8273 which I will present in the IPv6 Working Group this room ‑‑ this week in case you don't know about that, this is basically telling you that today it's possible using a SLAAC, using auto configuration instead of giving a single address to an interface of a host, providing a /64, for example that host may be running ‑‑ you have one address for every ‑‑ so why not clarifying in ‑‑ what I think is broken between the impact analysis and the policy text itself clarifying also that we agree instead of a single address as mentioned here, separate addresses not prefixes, which were strange because separate addresses that is plural, it's not single address but you are saying prefixes, that is part of the inconsistent see. The fact that the unique address or even a unique /64 is not permanently provided to third parties, on a link operated by the original receiver of the signals shall not be considered a sub‑assignment. And I provide some examples. This includes, for example, guests or employees, devices or servers, so that will be matching the original policy proposal, hot spots and point‑to‑point links. What I change here is, I am using non‑permanently, I use it originally in my first version, this is the second version, I was using temporary. And I think it was comments from the staff or in the list, I don't recall right now, like temporary means minutes, hours, days, weeks, so it looks like non‑permanently, it's more clear, it means it's not always the same in indefinite period of time. That is a matter for discussion in the next slide. Wait a minute. The provision of addresses for permanent connectivity or broadband services is still considered sub‑assignment so if you plan to not become an LIR but an end user to provide broadband services that is not good, we don't need that, you need to become an LIR. Only addressing of the point‑to‑point link itself can be permanent and the final sentence, it's basically to avoid that you are using an IPv6 NAT which is point‑to‑point link to provide services or a proxy or something else, okay? I am not sure but I didn't get a comment on that sentence if it's clearly understood but I think it's okay but anyway, we can find a better wording. So this is about it, the basically here set is we want that the if you have an end user like a university or enterprise and somebody is visiting your wireless network or ringing a serve for a few days, it's not considered a sub‑assignment. That is the thing. And the main discussion that we have in the mailing list or the main opposition we have in the mailing list from the previous policy proposal, which is narrower policy was that he was considering in his policy proposals that sub assigning addresses in a data centre should be still lowered but that is permanent, for me it's not the right way to have a data centre being an end user if offering services to others. Is this for you it's okay, if it's for enterprise it's okay but if it's enterprise which is reselling data centre space, services hosting whatever, to others, is that really what we want? Or we believe that is, that must be an LIR? So that is an open question. And so I think we mentioned all about this, the proposal will avoid the ‑‑ blah‑blah, non‑arguments opposing the proposal beyond what it was already mentioned in the impact analysis that RIPE ‑‑ the NCC did for the previous policy proposal and because I have submitted this policy proposal to all the other regions because the text is Gert explained it, the text from all the original IPv6 policy proposals comes were the same root, we have the same text broken everywhere. Okay? So I already mention about the data centre usage. This is something that we need to clarify and discuss. Then there is some people in different registries, I think the comment to me by means of the staff of LACNIC, for example, but also in the mailing list of RIPE, I am trying recollect all the discussions, that why the registry, why RIPE in this case should care if the sub‑assignment is not being registered at all in Whois, is that what we want doing? It's something that we are doing for IPv4. In fact, if I go back to the last question in the slide, to we have the same problem which IPv4? Yes and not. If you are using NAT we don't have that problem. But what happens if a university has enough IPv4 addresses and they are sub‑assigning addresses to the cellular phones or laptops or tablets of the students and teachers, they are actually sub‑assigning, okay. So we have the same situation in IPv4. And in fact, one of the suggestions in PPML, in the mailing list, is let's change your text to a.m. could I date the case for IPv4 and IPv6, we need this clarification but let's make a simple text to accommodate both of them. So, if we don't care about the registration or we don't care about the responsibility from the PI holder, then we don't need even the previous policy proposal, so do we need to just roll back and unfortunately there is not in the PDP a way to roll back so we need to still a new policy proposal to cancel the previous policy proposal, if we believe that that is the case. This is something that I don't recall if since 2016 come to the discussion of the previous policy proposal, but that is only true again if we believe that if a sub‑assignment is not registered we are not breaking the policy so we need a discussion on that. And finally the discussion which is the one that is taking longer about terminology, we should use temporary, non‑permanent, non‑continuously, that was my last suggestion in M MP, ancillary, any other wording, if it's temporary or non‑permanent are we talking about days, weeks, months? So, questions?
ERIK BAIS: Raymond.
Raymond: Raymond, with Elysa Auch and speaking for myself. Jordi, your proposals are usually complicated many questions asking and it makes it yet more complicated to give an answer to it but I will try to do one, and I will try to do one on the temporary non‑permanent and other things. Could you go back to the slides where you have the comparison.
JORDI PALET: Yes, of course.
SPEAKER: So if we are talking about a non‑permanent, I would rather have it mentioned in a way that the customer or the end user does not know which IPs he gets and he cannot claim a certain block or IP to be used because if you do that, you have an assignment. In any other case, you just have a temporary address.
JORDI PALET: Let's ‑‑ if you read RIPE 690, we are using a different terminology to avoid the confusion that you are having right now, we are using a terminology which is persistence. So what you are basically talking here is about the same device or the same end user device gets the same prefix or another one or the same address or another one, I am not talking about that here. What I am saying is, if a student is coming every other day to the building of the university and is getting an address, is that a sub‑assignment or not?
SPEAKER: If he cannot know which IPs he gets on four then it is not.
JORDI PALET: We need to still have definition for that, then.
SPEAKER: That is what you are asking, right.
SPEAKER: Max. Can we have slide 5, please.
JORDI PALET: Which one?
SPEAKER: 5. Okay. I don't think we change anything on v4 any more so that is done. And on the first point we obviously have different viewpoints. We had, as you said, two years of discussions and I think the consensus were we should include data centre set‑ups which include permanent assignments for VMs or whatever and I really like to keep those.
JORDI PALET: I think the key here is, this point. I really think that is the point. Because if this is right, then we didn't need it, the previous policy proposal. Do you recall we had discussed that in the past two, three years?
SPEAKER: What exactly?
JORDI PALET: The registration. So it's sub‑assignment or anything in the policy proposals or sorry in the policies, BIND to the concept of registration or not necessarily, because that basically changes the thing.
SPEAKER: I think the first I AA from the NCR had some point of registering sub‑assignments within the database and I think we all concluded that this was ridiculous on a /64 level or something. And then this topic never came up again.
JORDI PALET: Maybe that regards some clarification from the NCC, I don't know, I don't have a clear view of having discussed this in five regions already.
GERT DORING: Well, there is a clear answer ‑‑ should we care at all? Policy text should reflect the consensus of the region. Whether somebody does something in their network with PI space, that is not according to policy text, is a different issue, but we should care that whatever we agree that should be the intent should be in the text. So just to declare we don't case let them do whatever they want, we are not seeing it, it's not giving the right signal.
JORDI PALET: Not willing to say that. What I am saying is, if sub‑assigning but there is not a registration is not considered by the NCC as sub‑assignment then we don't have a problem.
ERIK BAIS: I think database is actually not allow you to sub assign PI space.
JORDI PALET: That is my reading but having some discussions in different regions that is not clear.
GERT DORING: Policy is about giving guidance to people how to do things. If the policy says this is not the way to do, registering or not is not ‑‑ not even coming into the picture. If it says you should not go there, it's a clear guidance and so we still care.
PETER KOCH: DENIC. So Jordi, I think you are addressing an important aspect of this, although I would suggest that your flight level is far too low and the speed far too high, controlled flight into ‑‑ I can only imagine that we make the registering in the database dependent on whether the researcher has a lifetime or bi‑annual contract and that needs to be policed and audited and everything so this is completely off the rails. However, when I think we need is a discussion at a much higher level which is what is the purpose of the database and what are the purposes of the registration in the database? And we having law enforcement knocking at our tours and bringing in completely different ideas of what should be registered, while we are dealing with things and by the way last time I looked we didn't' have a consistent definition of what a sub‑assignment is. So this is a symptom of a bigger thing, and I would suggest that we do not waste any more time, it's not wasting, but we do not spend any more time, I think the discussion is useful to have otherwise I should have sit down anyway. So we don't spend more time on these details but go back to the bigger picture and think about what the purpose of the information in the database is. Because in the end GDPR will hit us badly no matter what we are going to have to discuss that later this day I guess. But there are lots of aspects that come into play and the detail level, although it's hard work, I appreciate that, but maybe not at this point in time.
JORDI PALET: So basically you think we are still missing a good definition of sub‑assignment and that is it.
PETER KOCH: You have lifted the flight level but you are not already there. I am flying you too here.
JORDI PALET: Thank you.
GERT DORING: This sort of matches the feedback we have received on the list on this, so we have had three comments, comments from three different persons on the list that all were unhappy with the proposal, for different reasons, so indeed this is my suggestion as well to take a step back and figure out what are we trying to achieve and have a bit wider discussion and then come up with specific text again.
JORDI PALET: We are working on new version if needed.
GERT DORING: First have the discussion of course. Then come back with text. Otherwise you spend quite some effort finding nice text that you think is good, that is fine and the Working Group says that is completely the wrong direction, it's a complete waste of your time.
JORDI PALET: Okay. Thank you. So done.
GERT DORING: Thank you.
(Applause)
We are doing well on time, thank you all. So it's Andrea again, lets of familiar faces again. It's a bit unusual that someone from the NCC actually does a policy proposal. The main reason why we are doing this is because it's not changing policy policy per se but changing policy text so it's somewhere between housekeeping and policy, but since we changed policy text we agreed on the last meeting that it needs a formal PDP to be really clear, transparent, open and so on. But since Andrea is not trying to change policy as such, having the NCC come up with a proposal is okay, I think.
ANDREA CIMA: And it makes me feel closer to the community, part of it. Part of registration services at the RIPE NCC. I will not take half an hour like before, this is going to be just a few slides. This is, as Gert mentioned, about fixing some outdated information in the IPv4 policy. So a bit of background about this of the during the last RIPE meeting, you gave us the mandate when we presented the inconsistencies, when we presented the outdated information you gave us the mandate to make a proposal and that is what we is it. And the proposal focuses on two areas, first of all fixing outdated, the reference to outdated RFCs and the second point is to match the values that we have in the RIPE database with the ones that are reflected and described in IPv4 policy because we had a bit of a mismatch there.
Starting with the update to the references of RFCs, initially we focused on RFC 3330, proposed to update the reference as this RFC as being obsoleted. We got some feedback on the mailing list, David farmer sitting in the room commented on it and Leo commenting that actually it would have been better for, also taking into consideration that RFCs get obsoleted once in a while, to refer directly to the IANA IPv4 special purpose registry page. So this is the feedback we have received. My question to you is, because most of you are more expert when it comes to RFCs than what I am, what shall we do with other references to RFCs like 1918 or 2393, 1918 is still current but but a of course there has opinion some updates related to it over time, do you want us to keep the references to those or do you want us to refer to a more generic title as well in this case?
The second point is part of this policy proposal is we want to remove some address types. We don't have early registration set in the database any more. We have removed them and the same as allocated PI which are still there but we are in the process of getting rid of all the objects with this status. Early registration was what has been replaced by legacy later on, and not set was a status which had been issued a number of years ago and it wasn't really clear was it allocated, assigned PA/PI, and we have been working together with some holders of this ‑‑ some holders of this space trying to clear up these statuses. So those statuses, address types will not exist in the database any more so we would like to remove them from IPv4 Address Policy.
Then we have another type we would like to update the definition of. As you can see for allocated unspecified we have a definition, which says that this address space has been allocated to both to both RIR meaning to RIPE NCC but also to local Internet registries for further distribution. There were organisations, LIRs that has allocated unspecified and were further issuing assigned PI or PA blocks to their customers. It was however not very clear whether this address space was really PI or really PA, we had seen that some end users had issues with it. So as part of the projects to clean up references in the RIPE database we worked together with many of those LIRs actually transforming what blocks from this and giving them a specific definition. So we actually transformed and changed those blocks in address and PA or assigned PI or allocated PA. So the proposed definition here just removes the enact this address space is being issued to LIRs but only to the RIPE NCC, and we use it as a place holder, for example if you query address space which has been issued to other RIRs and you query the RIPE database.
Address types to be added to policy, we proposed a definition for legacy. Now this definition is taken from the legacy policy, so the not, lets say, created, written by us. But it indicates that legacy space are resources that were obtained prior to or outside of the current hierarchical system meaning the RIR St. And during the legacy policy implementation we gave the status legacy to all the legacy resources in the RIPE database so this is a status which is used but it's not listed in IPv4 policy.
So summarising, we have made a policy proposal, the discussion phase will end later on on the 23rd May, we believe that it will be nice to receive a little bit more feedback, be a ‑‑ support the proposed definitions or not, and do you suggest more updates to policy in order to improve the references. Yeah. That is it.
ERIK BAIS: Any questions?
GERT DORING: Any voices of support? Any voices of disagreement? You are not getting out of this room before ‑‑
ERIK BAIS: This needs to be solved.
ANDREA CIMA: I think a number of people are hungry.
SPEAKER: Both the allocated and unspecified you mean you are going to keep it on RIR level but not on LIR level, that's correct?
ANDREA CIMA: Correct.
ERIK BAIS: Any idea on the RFC references? Where is Peter? RFC references are your job.
ERIK BAIS: What do you think of it?
ROB EVANS: I was going to mention that RFC 1918 is also known as BCP 0005 which might well, if 19 is ever updated the BCP number should stay the same.
ANDREA CIMA: So we could reference BCP number.
PETER KOCH: This goes on Gort's time account because he invited me to the microphone. I think in previous proposals or changes for proposals I exactly made that suggestion, that these be updated but on the fly like when you touch the document anyway, and at some point in time just warning that upping the RFC number may change the semantics of the underlying text. That is not necessarily true for the special use addresses but not the others, that might influence the policy, which is ‑‑ you don't need the advice that yes, read the document that was referenced, right. Other than that, yes, thumbs up.
GERT DORING: We have had one comment on the list, that was about one of these RFCs and, basically pointed the IANA side directly which makes sense. And since it's in discussion phase we don't need strong support, having some support and no strong opposition is basically good enough and then we do impact analysis and the NCC will tell us that the NCC is all wrong about this, maybe not so.
ERIK BAIS: Discussion phase ends 23rd May. So that is one more week. And so please add to the mailing list some support or disagreement or suggestions.
ANDREA CIMA: Thank you.
(Applause)
GERT DORING: This brings us to the open policy. I had some discussion with Jordi about 15 more policy proposals coming up and ‑‑
ERIK BAIS: Again Jordi.
GERT DORING: Yes. And one of the things I just want to say here is that Jordi has been spending too much time in the IETF, the IETF is, you write a text and post a draft and if nobody reacts on the draft the draft expires and nobody has work. This is basically just discussing things here. If you right a formal policy proposal it goes into the machinery, Marco has to do things, the Working Group chairs has to do things so a PDP is formally heavier than just a draft. But we don't need a PDP to get feedback from the community, so if you have an idea of something that you might want feedback on, this is exactly where you go, on stage, or if you feel like in between the meetings something needs to be done, just send a mailing to the list and say, I have come across this, I have this idea, I want to change here, what do you think? Then you discuss it, and if there is some sort of positive feedback and people say really, we should do something about that, then it's the time to go more formal. We have discussed this already but I wanted to sort of repeat it for the whole room.
JORDI PALET: ‑‑ that is true but I reality is I tried that several times, not just in RIPE but also in other regions and unless you have a formal policy proposal you don't get enough comments, and even though the number of comments we know is slow comparatively to the number of ‑‑ to the members ship, right, so that is the thing, I mean, I don't care if I need to spend additional four hours in the plane from Madrid to the the car writing policy proposal, I actually did for the one. I have some slides, I don't know if we have time doing through them.
GERT DORING: We have 15 more minutes.
JORDI PALET: They are already uploaded.
GERT DORING: You are welcome to present your ideas. Posting them as a formal policy proposal is not guaranteeing you feedback either. We have had proposals that got exactly zero feedback but creative work.
JORDI PALET: Usually you get slightly more feedback which is better than nothing.
GERT DORING: We immediate to find the proper balance here.
JORDI PALET: This goes back to the previous discussion we had in the clarification of the IPv6 PI sub‑assignments. I use 2018‑05 I think it's the following proposal number that I will get if it goes formally to the process. It was sent about ten days ago to the policy responsibility about but we discuss it by email it's better we present it here than going. It's PIs not standing for what you think but IPv6 ‑‑ just so you are aware.
The thing here is, when we come to the discussion of the sub‑assignment clarification, there is a point in the discussion where you can think why we have PA and PI, do we really need that any more? I launched this idea I think in the previous meeting and then we have a discussion in the mailing list but I don't think there is a real consensus of we should keep both PA or PI or should remove that. So basically I decided to write it, if you go to any of those links you have a diff of what will be the actual policy text and what will change if we go for this and then very quickly go for some slides we will basically delete what ‑‑ in the previous policy proposal for the clarification, okay. That will be one quick change. We will change the minimum allocation to say if it is an ISP, if it's an LIR which is ISP still starts from /32 at the minimum but if it's an organisation the a /48, so we somehow are mixing together the concept of PA and PI, we don't need that distinction any more. And we change also the initial allocation criteria to restate that. So that is not really a change, just to confirm that the intent of the policy proposal. We have a few places in the policy where we will need to say those LIRs which are ISPs and the other ones which are end users and fending on that you go for /32 up to /29 or you stay for /48 for each N side. Again, the same sentence here, which are ISPs so basically for ISPs this is not changing anything, but what we are doing is basically on the same for TLDs removing part of the text and then of course we delete all the IPv6 provider independent section and again changing here the title to say if you are an ISP those are the conditions, if you need for an addition
JOHAN AHLEN: Ication, and then we need some text for the transition, which will need to agreed, which the NCC something like, I don't know, maybe one year, one year‑and‑a‑half, something in the middle, about the time that the NCC needs to change the actual end user contracts into LIR agreements and inform the community and that is it. I think that was ‑‑ and the rationale for these pros and cons. So this is not just an idea, it's concrete text that you have there, you go to the links I posted before. Let me go there. You see the concrete text, and it's up to discussion. I mean, what is the real need today to differentiate between PA and PI? If we are having this discussion about the clarification of the sub‑assignments and some people say, yes, some others not, so I think we are making it simple this way and not going into that discussion any more.
SANDER STEFFANN: Speaking as a participant of this Working Group, just a few ‑‑ a points of order. Can you please respect and follow the guidance from our dear Working Group Chairs, because I do think we ‑‑ and don't start randomly assigning your own numbers, that will only confuse people in the long run. But can we please move back to the discussion, first determine what we want and why we want it before we start looking at the actual changes. Thank you.
JORDI PALET: I think the intent is from my perspective is clear, I don't think the actual policy, it's good enough in regarding what is considered or not a sub‑assignment, and this is one more possibility to solve the problem. I really think that if we get rid of IPv6 PI we don't have that problem any more. There is not a total line where you are in one side of the other. I think that's ‑‑ it's not only my view, I mean, I went into this because I was talking about so many people, I got in addition to the mailings ‑‑ to the mails in the different registers, I got additional 20 private emails telling me you should consider this. So, of course I ask always the people like in IETF, don't send private emails, send to the list but the people don't do.
SPEAKER: Randolf. I have a feeling of déjà vu. I think we have also discussed issue about unification of PA, PI because it's A and I, we also discussed this, if we are to discuss it again we can ask the question: Why in the first place we had these? We also have this in IPv4, do it for both IPv4 and IPv6 or do it just for IPv6 and we leave IPv4 the way it is or whatever? And some part comes to the money. There are organisations that do not want, cannot afford to become LIRs. There is organisations for which, well, paying 1,400 a year, it's peanuts, well they should become LIR no matter what, even if they only need /48, it's their choice and the organisation for reach those money, it's considerable. And PI IPv6, it's ‑‑ in a number of cases it's used for, by those organisations, and actually, since we are talking about we ‑‑ we were talking previously about providing service over PI, I suppose most of you are aware that there are a big number of organisations that do provide IPv4 service on PI space which they shouldn't but they still do it. Why? Because they don't feel that they have the size to become LIRs or stuff like this. Some of them do become LIR eventually but the time they do, it's a longer story and I am not sure ‑‑
JORDI PALET: So you are confirming somehow there is something broken in the policy.
SPEAKER: There is something broken but there is some reason for all this brokenness. And the ‑‑
JORDI PALET: The reason we have IPv6 PI is because as we had IPv4 PI there was a discussion in the older regions and I was, if I recall correctly, I was the proponent of IPv6 PI in all the regions basically, so that is the reason we have PI because we had that in IPv4. Now, coming back to the question of the money, this is something out of the scope in this group but if but it to the ‑‑
SPEAKER: Taken into account.
JORDI PALET: If you go to that point, I think the differentiation in the cost between them eventually will node to change if we adopt this policy because having a /48 should not get the same price in terms of membership that having a /22.
SPEAKER: Which is out of the scope of the group also.
JORDI PALET: Exactly. But I mean, I don't think we node to consider the problem of the price because that will need to change if we go for this.
SPEAKER: Sebastian. I'm having also bit of problem with the term LIRs which are ISPs because there are LIRs there are not ISPs. What about them? I mean, I'm here representing an LIR that is not an ISP.
JORDI PALET: I understand that.
SPEAKER: So I think as we had before as a well‑defined term and I don't think we chose now make this term smaller by saying yes but there are LIRs to ISPs and other LIRs. I am not really in favour of that.
JORDI PALET: Totally agree but I will say you don't look right now to the concrete text because that's just a first review, and maybe we need in any policy proposal during the discussion we come how to better text, I mean the goal here is what about the idea of removing the concept of end user, not the concrete text here because we need to adjust that. Maybe it's easier to say if you are just an N site and that makes a difference, okay. So a regular RIR is not just an insight and other one is, I make it up it right now.
SPEAKER: I see that but I don't see the big benefit of putting a lot of energy in this if the status quo is quite okay now, I don't see the benefit. I really don't, at the moment.
ERIK BAIS: It's actually different because you will actually have contractual agreements that you need to adjust, and there are actually companies that cannot enter into an LIR agreement with the RIPE NCC. That is one of the reasons why PI is there from historic reasons. Look at UN kind of companies, organisations. So there is more than ‑‑ to this than just how it's been used and semantics. And cost was one point and contract and companies going into an agreement with the NCC was another one, that was probably the main reasons.
JORDI PALET: But again it's a matter of fixing that agreement. I mean, it's not something that we need to discuss it here. I mean there is nothing that this ‑‑ to say, hey, we are removing the user agreement, let's make a modification of the LIR agreement to cover ‑‑
ERIK BAIS: I understand. But if the end result is going to be similar, namely an LIR which has network in the infrastructure and ISP, versus end user organisation, what are we fixing here?
JORDI PALET: Making the policy simple, making a single contract, that simplification. It's a simplification, even for NCC, once it's done.
SPEAKER (Heng Lu): Hi, (Lu, from Aluris ? ? Claseris. Well, I actually support the idea that getting rid of PI because IPv4 PI pass ten years a lot of abuse, because it's pricey, modern everything and it's create a total mess in past years and I think a lot of people know that as well, get rid of it, my ‑‑ make database more clear and ‑‑ don't distinguish two ‑‑ Erik am I understanding your comment certain organisations are unwilling to enter agreement with RIPE NCC but I think that is more of a legal issues, we should have lawyers sort that part out. And also, if the space need to be mobile we don't really need PI to do that, we can have a transfer policy to transfer space from one provider to another. Work around to those problems. I support to get rid of PI and PA distinguish and make the database more easy to understand and a easy to manage as well. Thank you.
JORDI PALET: Want to add just one final sentence: We know all of us that there is people using PI for offering services we want to allow that or we are going to review if that is happening otherwise we really need to do something about it.
GERT DORING: What I am hearing ‑‑ I think clearly hearing here is that I should echo Peter's statement about flight level, so we don't even have a well‑defined problem statement yet so coming up with specific text is way too early. We don't know if there is a problem, we don't know if we agree what the problem is, so we should agree on the problem before trying to fix it. And I am not hearing strong agreement from the room that we know what the problem is.
JORDI PALET: So you are saying that I am wrong and nobody is misusing PI?
GERT DORING: No. There might be a problem or not but it's way too early to come up with specific policy text before we even know ‑‑ before we even have agreement on what the problem is.
JORDI PALET: That is part of the problem.
GERT DORING: But coming with particular text isn't identifying the problem. The trying to fix one particular view of what the problem might be but we should agree on the problem first and if the problem is some people are misusing PI or PI is to cheap or too expensive or too complicated that should be communicated first and agreed on and we do the next steps on deciding on how to fix it, like if the end result of the discussion is PI is to cheap, we play the ball to the AGM and not to the policy text. But let's agree on the problem statement first and then come up with text.
(Applause)
I thank you for taking the initiative. It's not easy to come here with ideas and then get shot down. You are lucky that we had no ‑‑ it's right now half past 12, time for lunch. Thanks for being here.
Thanks for being here, thanks for helping shape policy and see you again at the next RIPE meeting. Enjoy your lunch.
LIVE CAPTIONING BY AOIFE DOWNES RPR
