These are unedited transcripts and may contain errors.
Address Policy Working Group
15 May 2013
9 a.m.
CHAIR: Good morning. Welcome to the second slot of the no more addresses policy Working Group, it's now the second meeting after the RIPE NCC has run out of IPv4 addresses. So, we used to call it the Deck Chair Rearrangement Working Group as well, but actually we're not rearranging deck chairs this time, so we're back to Address Policy Working Group. Here is the two chairs of the Working Group, Sander and Gert, in case there is somebody new in here who is not yet ?? not asleep any more from the nice party yesterday.
And that's what we have on our plate today. Actually, we, in the original meeting plan, we had two time slots, but since our agenda is somewhat light and NCC Services had too much for their time slot, we traded, so this is the single time slot we do Address Policy today and after the coffee break, it's NCC Services, just as a reminder who hasn't seen the announcement or forgot about T that's what we're going to do today. First are the administrative matters. Then meal from the RIPE NCC will report on a global policy overview, what's going on, what are the hot topics. Then and an a from the RIPE NCC registration service also bring back feedback on things that have been seen where the policy Working Group might need to consider doing policy amendments or give guidance to the NCC.
Then a few words from the Working Group Chair, me, on consensus, and on actually IPv6 PI allocations which is not on the agenda, but it's sort of a longstanding action item on us. Then we go discuss the open policy proposals we still have, which is mainly 2013?03, the no need protocol, and then a few final words on the IPv6 PA /PI unification policy approach and what has happened there and why not?
And then basically open policy hour, AOB.
So, reminder again, in the next time slot, there is no Address Policy, so NCC Services has the ground work today.
And now we are into the administratives, is there anything on the agenda that you want to see changed that is missing? Here is the agenda again. I see nobody coming to the microphone, so that's what we're going to do.
Another administrative issue that is traditionally there, and is important so it needs to be done is thanking the scribe actually, Anthony from the RIPE NCC was volunteered to take notes what is said today, and publish and so on. This is not easy, so help him by speaking to the microphones, stating your name and if relevant association, a fillation. So, he can properly note who you are and what was being said.
The next administrative issue is minutes from RIPE 65. The minutes have been sent to the mailing lists, I have sent a reminder yesterday to ?? well, remind you that they have been sent. I haven't received any comments, so I assume that the minutes are exact enough to reflect on what was said and discussed.
Any comments from the room? No...
Okay, thank you. ...
So the minutes are final and we jump to meal's presentations on current policy topics.
As a matter of introduction, Emilio is our counterpart at the RIPE NCC, he is the policy development officer and takes care of all the paperwork, the red tape and all the formalities concerning policy proposals, policy implementation, so, he makes sure that we run everything according to the rules, why ?? Sander and I try to sort of like, cheer up the crowd. So thanks.
EMILIO MADAIO: I love my job...
Yes, I am from Rome, Italy and I work as a PDO. I am the one responsible to make the bottom?up open protocols process to happen. Usually I report here what's going on in the other region. What is going on and which protocols protocol completed the PDP since RIPE 65, since the previous RIPE Meeting and then some of the other activity I am involved in, and that engage the RIPE community on different levels.
I think I have to rush this time around, so, I want to jump into the discussion, common policy topics in other RIR regions and what the other RIR communities are talking about or trying to decide policy wise.
V6 depletion and especially v4 depletion solutions, VIX deployment and Internet resource transfer (v6) by depletion I must clarify when an RIR is starting to use, or is using the last /8 block of their pool. Other RIRs we call this phase as gradual exhaustions or runout or differently, but this is what I mean by depletion. The only draft policy I could find in the ARIN region related somehow to v4 depletion is this one and got implemented at the beginning of the year after discussion at the ARIN meetings.
Now, critical infrastructure have reserved pool of /16, /15 and not /16 like before. A larger pool for just critical infrastructure. This other policy protocol in the LACNIC region got discussed at the LACNIC meetings and got recently ratified by the LACNIC board. Basically all the IPv4 space LACNIC will receive from IANA will be reserved for LACNIC new members.
In terms of v6 deployment, this first policy protocol in the APNIC region got approved and is implemented actually, the announcement of the implementation was sent around February, if I recall correctly. And is something that should ring a bell to the RIPE community. We have been there. PI assignment now can be received by request there. Without the requirement of multihoming or to plan to multihome. This other draft policy in the ARIN region was in last call until last Monday, I don't have an update ?? a more recent update. Basically changed the way ARIN will calculate the utilisation rate of IPv6 suballocations.
In LACNIC these two policy protocol reached consensus. If I recall correctly LACNIC 18, not 19, the last one. Basically now it's possible to receive an initial allocation larger of a /32 for IPv6 and again, it's something that we have worked in the past. The other policy protocol was just an update of the text, there was a reference to an up sort RFC that needed some work, so just an update of the policy manual.
In terms of Internet resource transfers. Things are a little more lively. AfriNIC and LACNIC have these two policy proposals. The first one in AfriNIC was submitted at the beginning of the year, and will be discussed at the next AfriNIC meeting. There is a large feedback. There is a long thread in their mailing list related to this one that can be ?? I can't say much at the moment what is the direction of this attempt to have an inter?RIR policy. In the last three years this is the second attempt the AfriNIC community is trying to define a framework for inter?RIR transfers. Similar, in LACNIC, this policy protocol accidentally has a very similar name to the AfriNIC one, similar title, sorry, and the version 3 of this protocol was discussed at the last LACNIC meeting, consensus was not reached. However the LACNIC community decided to keep it in the mailing list for further works. And this last two policy proposals got ratified by the board ?? yeah ?? both of them. And they are related ?? no, sorry, they were not ratified, quite the opposite. They were' band on the by the LACNIC community after some discussion. I was confusing myself. And they were trying to work around the transfers in other way. The first one was allowing LIRs to receive v4 from from a transfer. When the gradual exhaustion would have started. And it was abandoned, it didn't reach enough support to be accepted.
The second one wanted to change the evaluation period for transfers, so to easy up the way LIR could transfer among each other, also outside the region. But this one again didn't take off.
In the ARIN region, these two draft policy actually, I don't think there is anything new, they just tried to improve the text. The first one is still in the ?? remains in the Advisory Council, the AC docket, wants to add explicitly autonomous system numbers in that section of the policy manual related to inter?RIR transfers. The other one is implemented, yes, and just allows ARIN to apply the same procedure to transfer and to measure acquisitions, it was just a textual change, as you can see self explanatory, it was aligning the wording in the two sections of the policy manual related to measures and acquisition and the one related to transfers of v4 resources.
The last one in APNIC reached consensus and is implemented too, changes the evaluation period for transfers up to 4 months. And it went straight in, it was an easy community discussion in the APNIC region.
This is an extra slide I would like to explain just quickly, because there is a couple of events that happened between RIPE 65 and 66, and they are relevant in the policy world.
ARIN has a new PDP that was announced in January 2013 after a long review. I highlight here the main difference, but there is this new activity between maybe some of the AC can confirm, before submitting a policy protocol, the Advisory Council and the proposer work in order ?? work some more in order to define a clearer and more comprehensive scope statement and then have a policy discussion further along the PDP.
As per AfriNIC, there is this new policy proposal that aims to rewrite completely the v4 policies without changing them, just a documentation improvement necessary after so much time spending in changing and patching here and there the AfriNIC v4 policy. Something to keep in mind, it will be discussed at the next AfriNIC meeting.
Now, in terms of the policy protocols you have been busy with in the RIPE community. I want to start with these two that are more or less correlated in the sense that the first one is the revert runout fairly. This protocol put the allocation period back to 12 months. Like it was before 2009, like it was when the runout fairly proposal, previous proposal was accepted. Somehow this change overlapped the scope of the proposal 2012?03 for the intraRIR, a proposal wanted to improve, to change the text in the section 5.5 on transfer, just changing the allocation period necessary to use for v4 transfer and so basically the proposer said that practically, 2012?065 already solves the problem of 2012?03. So the proposer decided to withdraw it.
Similar correlation is between 2013?03 and 2012?04. No need proposal is policy proposal that will be discussed more by dearth and presented by the author today is still active in the PDP. We are about to move to review phase and we are working to complete the impact on that.
Input on this proposal is more than welcome. Don't be afraid to speak out. We really need to hear what you say on all the different points that Gert and the proposer will highlight. However, the large support this proposal received at the beginning of the PDP conveyanced the proposer of 2012?04 that the community is not that interested in to an address management that includes PI assignment. And therefore decided to with withdraw this proposal.
This three policy proposal completed the PDP. All with consensus. The first one allows now the RIPE NCC to publish online weekly updates on the transfer that that were completed or transfer requests that were rejected.
The second one is self?explanatory, now we have new time limits for temporary assignments. 2012?10 is the extension of IPv6 /32 to /29 now on LIR that holds multiple /32 has the right to extend to a /29 each /32 they hold. An announcement on implementation of this proposal will follow the proposal 2012?10 and the PDP this week actually, I think we announce it on Tuesday.
These two policy proposals are both active in the PDP at the moment. If the first one as it was announced in the mailing list, it's the our inter?RIR policiy proposal. And the author is working on some wording, considering the latest feedback received in the mailing list.
2013?02 is instead a policy proposal in last call. So we have still four weeks ?? yes, still four weeks to comment and present some valid objection. So far we received only positive support and it's basically a small change, textual correction in the section 5.5 related to the transfers.
Now, in terms of PDO activity, I can go quickly over them. Maybe you didn't notice, we didn't send reminders about that but we have a new current policy proposal page. This is intended to be more colourful, efficient and surely more eye catching. We received only good comments after publishing this one, but I'm still open if you want to talk to me, if you think there is room for improvement, please let me know.
And this is something else I usually mention, but this time I want to show you because it can be important considering the age we are living. This is the NRO comparative matrix as we policy development officers call it. It's the outcome of the collaboration of all the other PDOs, like me in the other regions. We regularly review this document in order to highlight the similarity and differences of our policy, of the RIR policies classified under different topics like allocation, initial allocation, policy for sub allocation, ASN distribution, and this is on the NRO website. And you can find it there. Actually, something that gets overlooked most of the time. In this current policy proposal web page, on the right?hand side, just above the PDP tutorial YouTube video that explains roughly what it is the ?? what the RIPE PDP is, you have that link that is RIR comparative policy overview. So any time you access this web page and are curious what the other RIRs doing, what are other RIR communities are doing to solve the same problem, to tackle the same issue, you can access the list of these documents and find also the latest one. This is the latest one, label 2012?04.
Cosmetic surgery, it allows me change the text of policies, only could see metically. I do not intend to change the policy itself. It was a request of the RIPE community that was formalised in, at RIPE 59, and I'm working on that. I had six policy documents for review on this and unfortunately the last two were v4 policy and v6 policy and they were both active in the PDP so I could never find the time to work on a fixed document.
So, thanking the flexibility of the Address Policy Working Group co?chair, I had the permission to move on this other RIPE policy document that was not included in the original project. You can see here actually this is not the original title, this is already the new title that I am suggesting. This is the page where you can access this new draft and see both the new text with highlighted changes and the text with the comparison between the new and old text. And the input I'm asking you is to check if you find it clearer than the original, so you see the improvement in the readability of the document, and if these changes are not conceptual, I'm not changing the policy itself, but just the ability to read it and understand it.
For this one too, there are four weeks of review and there will be some evaluation of the feedback and some weeks of ?? four weeks more of last call before renewing the document.
These are the usual activities I do. I collect the input and organise all the work for the Impact Analysis. I just listed these two that are more or less active at the moment in the PDP, especially for the second one, again it's very like low that most of the input we will receive at this RIPE Meeting will also be evaluated and considered for the Impact Analysis we are going to publish soon. And RIR outreach, this is also just a part ?? it's too much to say about this here. The NRO comparative matrix I presented before is just one simple example of this coordination with the other RIRs.
References. The PDP, this is the web page I suggest to you to keep open during the Address Policy Working Group session and actually every time, also in the NCC service Working Group session, where we will discuss other policy I didn't present here. The current policy proposal web page is something that I invite you to book mark. And my contact: This is the e?mail you should use to send me feedback, ideas. Also to start a PDP, to start submitting a policy proposal. If you are not sure which is the Working Group Chair right for you for that proposal, if you are not sure of the format you are using for your policy proposal, I read the e?mail and I gladly reply. And last but not least, the Twitter account for every now and then I tweet news on policy. Not only our policy but Internet policy in general and everything related.
I think I'm done and I think I was very good because I didn't run long, correct?
CHAIR: Thanks for the overview. Thanks for being quite rushed about it, so we have more time for the discussions later on. I think it wasn't too rushed. Everything was there and clear. Thank you.
So any questions on that? Anything you want to see explained in more detail or... I hope that's not because everybody is still asleep but because the presentation was so clear that all questions have been answered. I take it it was very clear. Thank you.
We used to have feedback from Alex Le Heux from the RIPE NCC at this point, but he left the ship and is now working for an LIR unheard of. So Andrea Cima from registrations services volunteered to try to full the role.
ANDREA CIMA: I'll try to do my best.
CHAIR: I am sure you can do it as well and bring back issues that have come up in the day?to?day work registrations services that we might need to consider in our policy work. So, thanks.
ANDREA CIMA: Good morning everyone. My name is Andrea Cima, I am part of the registrations services team at the RIPE NCC.
As Gert has previously mentioned, this is a report from the registration services department. As most of you are aware of every month we are in contact with a few thousand people, mostly LIRs. Now, from the people that we're in contact with, we receive a lot of feedback about our procedures, about the way that we interpret policies, and about policies themselves.
So, the goal of this brief presentation is to receive some guidance from you on some of the feedback that we receive, and we want to also provide input to you with regards to potential policy discussions.
Now, I have three topics on the agenda. The first one is reassignment of returned but referenced an AS numbers. The second one is what we see that there is a request from members to change status from PI assignments to PA allocations and finally we want to share with you a bit the experience that we have with the current transfer policy.
Now, starting with reassigning referenced AS numbers. The RIPE NCC received issued AS numbers but also received AS numbers from organisation that is stop using them. Over the years, we have accumulated about 14 hundred 16?bit AS numbers. Those AS numbers are all referenced in the RIPE database, meaning that they are referenced in import and export lines of other AS numbers, and in route objects. Now, because those AS numbers are referenced, we had no redistributed them so far, but as you are all aware 16?bit AS numbers are a scarce resource right now,
We see a few potential solutions, of course if you have any other ideas, please let us know, but the solutions may be that we do not Ray sign those AS numbers because they are referenced, so we keep them there, that we reassign them, even though they are referenced in the RIPE database in other objects. Or that we do a cleanup of the RIPE database that we remove all the references. And in this case, we could do a big silent update or we could inform all the holders of the objects about the updates that we're going to do. This, of course, would create some additional work because we are talking about thousands of references.
So, I would like to ask if anyone has any feedback about this? If you have any input on how you would like us to deal with this issue.
CHAIR: Okay. Group, now it's your turn...
What should the NCC do? I personally think that reassigning, not reassigning or reassigning them even with references in place is not such a good thing.
Finally, updating has problems, as, for example, my own registry, we just have a template that we add to and then send it off. So, if you change it in the RIPE date, the next overview we do it's overwritten again. So, I assume that other people will run it similarly. So, my gut feeling is that, actually, you would have to do some work that is inform the people that you are referencing something that is no longer active, and if no response ?? fits not cleaned up in four weeks' time, do the update for them, tell them, yes we have updated your object, and if they then readd the reference there is nothing you can do about it, but if them a chance to get their own records in order. That would be my approach, as a user, but...
AUDIENCE SPEAKER: Kurtis Lindqvist, NetNod. I think B is out of the question, that's clearly not going to work. A, maybe. We're not really running out of the AS numbers any time soon but then again you never know. And for C, I agree with Gert, if you do the clean up, you can't do it silently, you have to inform the object holders; that might be an option, but how do you inform the object holders, that might be an option but you have to inform people one way or the other that you are changing the objects. I don't have a preference between A and C, we can do this later as with we have done in the past. But I would prefer the clean it up now, I am with Gert on that in the C.
AUDIENCE SPEAKER: Rob Evans. I agree with both Gert and with Kurtis. C, you have to do the notification first. Then give time for people to clean up themselves and then update if they don't.
AUDIENCE SPEAKER: Randy Bush, IIJ. You are returning your rental car before leaving the car, leave the keys in it and make sure you have your cell phone and all your personal possessions before you accept it from them it should be clean.
CHAIR: That's actually what RS does, asking the person who returns an AS number to get the references removed. What are you going to do if somebody else is references your AS number? It's not just route objects, it's also somebody else's import statement and you have no ties to them to actually make them do T what are you doing then, not returning the AS number?
RANDY BUSH: No, then let it stay. If somebody else is leaving garbage in the car, let them leave garbage in the car.
CHAIR: And that's what we have sort of. So somebody needs to clean up.
RANDY BUSH: I'm just... if I clean up for you, it's like what I call do?gooder software that tries to cover errors. If it successfully covers the error, no one every says thanks. Make one mistake and you get hell.
AUDIENCE SPEAKER: Hi, CK from Akamai. I strongly like actually A. I think as the people said before, we really have enough AS numbers so there is really no need to clean them up because we are running out tomorrow. Some people, and I might be special there, tend to have an emotional component to the AS numbers, I really get confused if they come back and you know different networks, different ASs and different cops and stuff like that. If you really, really, really have to clean them up, then please go for C 2. Thanks.
AUDIENCE SPEAKER: Raymond Eliza. Actually C 2 in a different way. Probably issue the list of these ASs which have to be cleaned up, inform all the LIRs that if you have references to this AS number, clean up your ship because you haven't done your job. Then once they are freed, if someone really still needs a 16?bit AS number, then they can be reused.
CHAIR: I think we have heard clear words from the community. So you have something to work on.
SANDER STEFFAN: I think it's at least very clear that nobody likes B, to put it in Randy's terms, we don't want the rental company to give out the car while it's still dirty.
ANDREA CIMA: Okay. Thank you.
The next point that I have on the agenda is changing status from assigned PI to allocated PA. Now, we are receiving an increasing number of requests to change the status from a signed PI to certain object to allocated PA. Now those are usually organisations that receive the PI block when before becoming LIRs. Once they become an LIR, they would like their former PI to be transformed into allocated PA so that it has the same status as the addresses that they have received directly from the RIPE NCC.
Also, those are often LIRs that have taken over organisations that have PI address space and again they would like to change the status to allocated PA. Now, we have been asking some questions like why would you like to do this? Why are you asking to us do this? And apparently because of the scarcity of IPv4 addresses they would like to restructure networks, use the IP addresses for different reasons than they were originally assigned for, which is not allowed with PI addresses so far.
So, also here, we couldn't really find much in the policy with regards to the possibility of changing the status from a signed PI to allocated PA, if not one sentence which though it's taken a little bit out of context because it refers to the general choice between PI and PA. So, here we have two potential solutions: Allow LIRs to change the status of their PI assignments, meaning the PI assignments issued to them, to PA allocations, or to deny those requests. Again, as the policy is not really clear about this, and we receive an increased number of requests, yeah, I would like to know what you think about this.
SANDER STEFFAN: I was talking about this to Wilfried, who is unfortunately in the other room doing the Database Working Group at the moment. He reminded me of that in the beginning, the difference between PI and PA was not very clear, and he has personally been involved in cases back in the nineties where the status was changed from PI to PA and vice versa so, this is not actually the first time this happens, but yeah, we have to consider it in the current situation. So... but he wanted to remind us that it's not that new idea.
ANDREA CIMA: This is correct. Especially, a long time ago, these changes have been made on a case by case situation, but this was ago long time ago, and as we are receiving many of those requests, it's good to be aware of like, shall we, shall we not do this? So to get your input on this.
AUDIENCE SPEAKER: Eric Bais, on this topic I am much in the train as we need to get rid of the difference between PA and PI, because, it actually creates more hassle currently for a lot than specifically, you know, making specific choices or making specific policies about it. I would definitely make it as easy as possible for people that want to do it, as long as we still have the status PI, would I like to have the LIR have the option A. I would definitely vouch for that one.
AUDIENCE SPEAKER: Kurtis Lindqvist. Maybe I missed this when I was reading the e?mail, but this is a question in general about v4 and v6, right?
CHAIR: V4.
AUDIENCE SPEAKER: If it's more v4 only I feel they are rearranging the deck chairs for the Titanic and it doesn't really matter, we can label them whatever we want.
CHAIR: It does matter because people might have a big block of PI and by following the rules, they cannot use that address space to number their customers until they give only a single address to the customer, so if they properly want to document their stuff and properly document their assignment, the RIPE database will not let them, so, to be honest about what they do, they need to change the status.
KURTIS LINDQVIST: What I mean is they should be allowed to go to PA, I don't see why not. It's better to have the data up to date and it's going ?? they are not going to be numbering new customers for everybody anyway.
AUDIENCE SPEAKER: Sascha Luck from SF. As I understand it on the current policy, if they were to re?number that PA space, that would go back into the general PA pool anyway, so why would you make them re?number if could you just convert it into PA anyway?
CHAIR: I'm not sure I understood this. This is not about renumbering. This is just relabelling, so that somebody has a /16 PI and wants to use that for PA purposes now, and formally asks can I do that? So ??
AUDIENCE SPEAKER: If it were not allowed, they'd have to re?number, which would give them PA space but at the cost of a lot more hassle.
CHAIR: Actually no. If they were to return the PI, they would get a /22 PA or nothing, so cannot just trade it in. So, either you are able to document what you are doing or you do it behind the scenes or you lose your address space, so there is no obvious way forward unless we actually permit relabelling it. Randy.
RANDY BUSH: I'm a little confused. When you say "They have" PI space, is the "They" the PI holder or the LIR?
CHAIR: Which might be the same entity in the end.
ANDREA CIMA: In this case it's the same entity, we are talking about LIRs that have allocations from the RIPE NCC but they also have PI addresses which have been assigned to them.
RANDY BUSH: So the LIRs are the PI holders
ANDREA CIMA: In this case, yes.
RANDY BUSH: Sure, there could be edge cases like, as Hans Petter says, they acquired somebody, in the normal case who is the holder, the LIR or the end user?
ANDREA CIMA: In this case what we're talking about the LIR.
AUDIENCE SPEAKER: Which may include, because this is, in many cases, old stuff which may include some formerly independent organisations that have been absorbed by the LIR.
ANDREA CIMA: Correct. I will go back one slide, as I mentioned here usually these are LIRs that received address space before comings members and LIRs that have taken over end user ??
RANDY BUSH: Part of what confused me. LIRs that received PI space. No, the end user ?? didn't the end user reserve the PI space under an LIR.
CHAIR: Over here, you can have the case of some network provider say a DSL provider getting PI space on their name and giving single IP address to say their end customers from it. There is a loophole in the PI policy that the transit network to the end customer is considered yours. So you can number a whole DSL network from your PI space, which is sort of like an edge case, but it happens.
SANDER STEFFAN: A lot.
RANDY BUSH: The PI space says that end user could have taken it somewhere else.
CHAIR: Yeah, but the end user is actually the LIR ?? the network provider in that specific edge case. So actually, we are trying to clean that up.
AUDIENCE SPEAKER: This is Hans Petter, two comments. One is that I think Randy is pointing at a very important point, who is really holding the address space? Because there could be border case where is that's not clear and I think that's the can of worms we're opening here. Are we really sure an LIR is taking away address space from one of the customers, I mean that would be the sort of the disaster to go into. I think from the principal point of view, as a non?native English speaker, I have never been able to have the distinction between the I and the A in PI and PA, so, let's get rid of the distinction. I think that would be the sort of end solution to this. So ?? switching the label, no problem with that. But who is actually the holder of the address space? I think that's the clue to this.
AUDIENCE SPEAKER: Lars Liman from NetNod. I fail to see here what's the downside with allowing this change. Who is the entity that has a negative impact of doing this? Why would you disallow it
CHAIR: That's not necessarily a downside. It's an area where the policy doesn't say anything. So, actually, the NCC, I think they could just go forward with it and they have done it in the past but they are now bringing it up so that we are aware that this case happens and if they think there is a down side to it, we can tell them.
AUDIENCE SPEAKER: Okay, so we're looking for a downside.
CHAIR: What I'm here hearing now is there is a risk with unclear ownership of the PI block and I think 2007?/O 01 contractual work should give you clear statement of who is the holder of the PI block.
ANDREA CIMA: Yes. Before in any case before making any changes to a branch, we make sure we are in contact with the length met holder and we verify the documentation to ensure that the person holding the resources is the legitimate holder.
AUDIENCE SPEAKER: It actually seems that the question is, in many cases, triggered when the PI space is picked up for processing for getting the contractual relation, I think. So, kind of pointing at the contractual relation being in place is kind of missing some of the interesting cases and, again, this kind of shows that, or this applies to stuff that comes from the early distribution of NCC.
Recent, I think ?? is not a big thing, but let me loudly state, we appreciate that the RIPE NCC is stepping up and telling about the policy problem and asking for input. That's kind of an improvement.
AUDIENCE SPEAKER: Filiz Yilmaz, I have a question first and then maybe a following comment. There used to be a laws in the IP version 4 policy documents of RIPE that any assignment or allocation is valid as long as the original criteria is still held. Is it still there?
ANDREA CIMA: Yes, it is. And that is one of the reasons why LIRs that hold PI address space would like to change the status to PA. So that they can make a different use of the PI addresses compared to what the PI address space was assigned for. So at the moment you have a PI assignment, you can only use it for what it was assigned for. So cannot reorganise your network, make customer assignments to, it you must only use it for that specific reason. And that is one of the reasons why we are being asked to change the status to allocated PA which gives you much more freedom in the use that you make of the PI addresses ?? of the addresses, sorry.
FILIZ YILMAZ: Okay. Then may I continue? Nigh following comment is: This is not just labelling. There is a change there. There is a need ?? there is a you in need, maybe, that registration services should evaluate, because this can cause different consequences or end results, especially nowadays. Thank you.
GERT DOERING: Last comment, then we actually need to close the discussion.
AUDIENCE SPEAKER: Erik Bais, yeah, would I like to comment on the last speaker. Most of the policies that are in place, specifically about PI space and limiting the usage of PI space, come from a time where the policies were ?? the majority of the policies were for distribution fairly purposes. That game is over. So for now, it's making the change to PI space and actually keeping the registry up?to?date on a daily basis; up?to?date I think should be applauded and that's basically what we're trying to do here and I think that's a good thing.
CHAIR: Okay, to wrap it up. I'm taking your comments into account. What I think we need to do here is now to sort of write a proposal from the NCC, not a formal PDP proposal but like the Database Working Group has that the NCC sort of like proposes how to approach, it what to check for and so on and bring it to the list and see whether we have overlooked edge cases or we can go forward. That should take your comment into account.
And now we need to go on. Andrea has a third item and we need to leave time for Tore to actually discuss his proposals.
ANDREA CIMA: So, the last topic, we are not asking for direct feedback here but this is more that we want to raise awareness of one issue that we are seeing. We speak with many people as I previously mentioned, and we get many questions about the following topic.
Now, according ?? at the moment transfers of address space can happen in two main ways. First of all, through a merger and acquisition, company LIR A takes over LIR B or LIR A takes over a part of LIR B. Or through the transfer policy. Now the transfer policy at the moment is really clear. And it mentions that: "Any LIR is allowed to reallocate complete or partial blocks of IPv4 address space. Such address space must not contain any block that is assigned to an end user."
Now, what does this mean? There are ?? there seemed to be quite a number organisations that are end users, they receive a PA assignments from an LIR. They use the address space in their own network for their own customers and at a certain point they become an LIR themselves because the company is growing, they have more need for resources. At this point, they come to us and they say, okay, is it possible to transfer this address space, this part of the PA allocation from this LIR to my own LIR because my whole network is running on that space. That those people are falling a bit through the gap in a sense that this is not considered a merger or acquisition, because it's not, but it does not also not fit within the current policy because the address space is actually being assigned to them and to their customers. So, in this case, the transfer cannot occur according to the current policy. And we see an increasing number of people that are actually interested in such a transfer, but there is no possibility according to the policy. So this is to raise awareness to you to know that we have seen this possible issue.
CHAIR: Any comments on this so far? How should we handle this? There is of course loopholes around this like deregister all your address space, transfer the now seemingly empty block and reregister it, but that's sort of like lying to get around policy shortcomings to maybe that's not the best plan.
AUDIENCE SPEAKER: Donal Cunningham from AirSpeed. How big a problem is this? How many times has this actually cropped up?
ANDREA CIMA: Officially, if we look at the number of transfers that we have not approved, there is only one. But however, I have been talking with, in the last two, three months I have been talking to between 25 and the 30 organisations that had this in mind, but they are not going ahead, they are not requesting it because they know that it's not within policy.
AUDIENCE SPEAKER: Aled Morris, I think in the old days it was a lot of policy about not breaking out the PA space and it was all very laudable but I think I'd refer back to the previous comments, we are now at a stage where we are trying to get the documentation right and get the database correct because it's just managing the deck chairs.
CHAIR: Actually, I think we cannot just do it because the policy is clear here, so we would need somebody who is willing to volunteer with a policy proposal to actually get that changed. I don't see anybody jumping up and down, so we will bring it to the list and ask for volunteers there to help with it. Thanks for bringing it up. Thanks for being here explaining the problems. And well now, it's back to me...
ANDREA CIMA: Thank you.
(Applause)
GERT DOERING: Here we go. We are running a bit short on time, but the discussion was important, so, it was good use of our time. There is a draft in the IETF that tries to define how the IETF defines consensus and draft consensus and I think much of this is relevant to the way, well, we in the RIPE region, handle consensus, especially in address space. Like, there seems to be consensus, but one person is consistently declaring that he's opposing the proposal based on grounds that everybody else thinks it's not reasonable and so on.
If you are interested in the whole consensus thing, I think it's worth reading, it's not that long, four or five pages, and gives lots of background on the thought process, what defines a rough consensus, the IETF is the IETF and we are RIPE, so it's not directly applicable because we don't have running code. But still, the basic principles are very similar.
Then we had this policy proposal 2011?02 that loosened up the rules on IPv6 PI assignments, and at that time, the worry was the world would go down, the assignments would explode like crazy, and ?? well the chairs promised that we would watch the growth of the IPv6 PI assignments, and if something weird happens, would report it back.
Actually, what you can see here is the assignments and allocations of all five registries broken down by class. The dotted lines are the PI. The straight lines are the LIR allocations PI/PA blocks and what you can nicely see is when IPv4 ran out, the PA allocations jumped up. What you cannot see so clearly is the the RIPE PI assignments is here. It's basically growing at a sort of a constant rate. There is no bumps in the curve, no uptake. So, I think we are still pretty safe, and given the ratio that we are at about 1,000 PI and 5,000 PA blocks, we are not yet breaking the routing table. So, safe enough.
Open policy proposals.
I go through all the stuff that's in the system very quickly to leave time for Tore.
2012?02, that's the policy for transferring IPv4 addresses across the different regions. It's at the end of the review phase. There was no clear consensus neither to go for it nor to abandon it on the mailing list. But there were comments that the policy text was less than clear. So, the proposer agreed to work on the text and come back with a new policy text that is maybe easier to understand and easier to reach an agreement on. So, this text is not there so we have nothing to discuss here today.
2012?03:
That was modification of the transfer time lines, the document need time lines inside the RIPE region, and that basically got obsoleted because 2012?065 already changed the time lanes back to something reasonable. And 2013?03 the know need proposal, but do away with the whole timeline thing anyway, so that was withdrawn, nothing to discuss here.
IPv4 PI assignments from the last /8, it was discussed at the last meeting. It was quite a heated discussion with no very clear outcome. The proposer sat on the proposal for a couple of months and tried to make sense of it, and at the end, he withdrew the proposal because he said it's unlikely to reach consensus at the moment. So it might be back, but at the moment it's just off the table.
2013?02.
The removal of requirement for certification of reallocated IPv4 addresses. That's actually a cleanup thing, so that there is something in the transfer policy that if you transfer, you have to get a certificate from the RIPE NCC, assuming some ?? assuming a framework of certificates that never came into place, so that policy proposal is just removing that sentence because it doesn't make sense.
The review period has ended. There was quite strong support, no opposition so, it's in last call now, so if all of a sudden you find reasons why this is not a good plan, now is the time to speak up and, if you are fine with it, just keep silent and I don't think we need to discuss it today here because the voices on the mailing list were clear enough.
Which brings us to 2013?03.
No need. It's really a massive cleanup proposal, and Tore Anderson is here to present on it.
TORE ANDERSON: I represent an LIR and operator in Norway. So I wanted to start by asking you a question, that's whether or not you see in this form, it's the RIPE 5?something?something from the address assignment form, or if you have seen, it if you have filled it out, if you have reviewed somebody else filling it out, or you have a colleague filling it out or a local version of this form. Hands?
That's quite a few. Okay.
Follow?up question: How many of you enjoy doing this? Or think that's a very good or productive use of your time hands? One. Don't worry you'll be able to do it in the future after this proposal as well.
But for the rest of you that did not raise your hand the second time around, this proposal is for you.
All right. So, this is part of our current policy. It's one of the four overarching goals of the policy, which is, and I quote: "Conservation: Public IPv4 address space must be fairly distributed to the end users operating networks. To maximise the lifetime of the public address space IPv4 address he is must be distributed according to need and stockpiling must be prevented."
It sounds good and something that has served us well for a long time. If you actually look at the recent events, we ran out of IPv4 address space September last year.
So, with that in mind, going back to this goal, we can see that the goal is to maximise the lifetime of the public IPv4 address space, which is zero. So, this goal cannot possibly be come published any more. This is obsolete. It has ?? so this goal has served its purpose.
So, the high level executive summary of my proposal is basically to drop this goal. That's it. That's the gist of it.
So, in a more kind of detailed looking at the policy, what actually we had for mechanisms and provisions in the policy that worked towards this goal, it's especially the requirement document needs at all levels, the end users how to do it, the LIRs have to do it and even though they could document need, even though they could document it for a certain amount of time, they might not get for any time period that they would be able to document. And that's the name of the proposal. No need, because the need part is the most significant mechanism in the policy that serves the conservation goal.
There is other things, like the assignment window, the slow?start principle and some other stuff, that all work towards conserving the address space in one way or another.
So, again, proposal: We drop it. Outdated, it's all obsolete.
What's the benefits of doing so? Well, first of all, you don't have to fill in the form any more. You can trust your customer. If you sit there ?? well, if you have nice customers and you sit there in a meeting with your customer and a customer says, okay, this is what we have and this is what we want to do and you might sit there as an operator and say, yeah, you are going to need a /23 or whatever and the customer says yeah, that's what we had in mind. That's enough. You don't have to say to the customer, okay, that's fine, but now you have to type it into this RIPE 5??something form that we can actually put it in the archive. That's one thing.
And of course the LIR audits becomes much lighter, because with no need to have the documentation for the need, then the RIPE NCC doesn't have to actually audit that documentation. Hence the audits will basically be checking for overlaps, checking that contact information in the database is correct. They can let whatever assignments therefore, the size of them, be valid.
And of course, the time lines goes away. So, in my case, I often work with customers that have a three?year contracts, and I can't ?? even though I have a contract signed saying we are going to have this, and we are going to buy all this or run these applications in your data centre for the next three years, I am not allowed to make that assignment today. And that's not convenient for me, and it doesn't benefit anyone really that I'm not allowed to make that assignment. And if I take away the time lines, I can.
And of course there is also an impact on the transfers that you are able to say yourself like, I need address space, IPv4 address space for two, three years. I found somebody who is willing to part with theirs and give it to me. Done. You can register the transfer and it's done.
And of course, if there is no need to convince the NCC or the LIR that you need so much address space, there is no need to lie about it either. I remember in the last weeks running before runout, there were some serious accusations going on at the mailing list saying, yeah, this LIR is in my country and I know them and there is no way they need the /12 that they got. They are cheating. Maybe it was the case, maybe it wasn't the case but even so, when you have such a ?? the potential for cheating in this manner, then you get a nasty environment, so if taking away the incentive to cheat makes the entire playing field level and fair.
And like it says on the slide, in the IPv6 policy or at least in the IPv6 actual implementation of the policy, almost none of the assignments or allocations are done according to need, or sized according to need. They are within the minimum delegation size. So, we don't have to do it in IPv6 to document the need really, to we went have to do it in IPv4 as well, and that makes things more similar.
So, when I was actually trying to implement this policy, I tried to kind of extract all the need stuff and all the conservation stuff from the policy document, and it's kind of hard because it's intertwined lots of different text all over the place and I figured out that okay, I am actually sitting and rewriting policy sections which are completely out of date and not used any more, because the last /8 obsoleted them. Then I figured it's easier if I just delete all the obsolete stuff first and then rewrite what's left.
So, here some of the examples: Like PI assignments, except for the IXP stuff in the last /8 policy, the NCC doesn't give out PI any more. They don't give out PA assignments except for the last /8 stuff, so there is a lot of text there that can go away.
So, what I'm proposing is to just delete all the outdated stuff. And also, promote the last /8 policy to the policy. So that there is no confusion that this is the policy that applies to all the address space even though it is not actually is not actually part of the contiguous 185/8 block. There are some other stuff. I mean Emilio pointed out to me that in the section, that is about closing LIRs and when the NCC can close LIRs, there was for some reason a link to ?? you can find training documentation on this site, which has nothing to do with closing LIRs, so then we took that out because I don't know where that came from and Emilio didn't know and it didn't seemed to fit in there, for example.
So this half ?? or cuts the policy in half about, at least on word count and it takes away the obsolete stuff. It takes away stuff where the policy contradicts itself, where the last /8 policy is in conflict with the pre?last /8 policy, and it makes it more approachable, really.
I am guessing that most of you have clicked through and EE ULA because it was too long to read. If anything this makes it more likely that the community will actually bother to read and care about the policy. I think.
So, discussion phase is over, and we are waiting for the Impact Analysis which should be coming shortly. And it was, well... a hot discussion, with lots of posts, but for the most part, support. So ?? and what we were talking about or what was being discussed most was was the transfers, and then there was some proxy war going on between some factions in the ARIN region about legacy status over there, or how you'd buy radio frequencies in the United States. So I don't know why they chose that venue for this discussion, but anyway...
There was not so much discussion about the actual assignments and the actual bureaucracy that I'm, kind of is my main goal here. So I feel compelled to point out that this is not a transfer protocols proposal, even though the discussion would have you believe that. So, I asked the NCC for some numbers on assignments versus allocations, and since depletion we have had three dozen transfers in totalling. In the same time period, we have had more than a quarter million assignments. So, when I say that I want to get rid of bureaucracy, I'm not talking about 36 forms, I'm talking about the quarter million forms that if all those assignments were done according to policy, somebody filled out, somebody archived, somebody verified, and I'm not ?? I don't want to guess how much time we collectively as a community have spent on those forms, or chosen to just ignore the policy, whatever, because in any case, it far eclipses any bureaucracy surrounding transfers.
So, the transfer impact is basically just because F you take away the assignment justification, you can just say I want to assign whatever, now I have need for the allocation to provide that assignment, so, please give it to me, so there is no point in upholding needs basis on the higher allocation level, once you have removed it on the lower level.
So, that's just a side effect. But... and I think, based on the actual numbers that the secondhand, the market of IPv4 addresses is overhyped or exaggerated, it seems like there is more people interested in talking about it and making policy about it than there are actually people making transfers. But some people seem to think that that's precisely because they have to fill out those forms, so... if this proposal makes it easier for those people, then great, no problem with that.
So, I want to also, to be fair, those people that I made arguments against the proposal on the list, to go through those. And the first one that came up was that it conflicts with RFC 2050, which is true, but 2050 was written in a pre?IPv4 depleted world, so it describes the state and the best current practice when there actually is a public pool, and we don't have a public pool. But if you say we always did it this way so we should continue doing it this way, that's actually a fallacy called the appeal to tradition, because the criteria on which the original best practice was founded is no longer there. So, I don't really buy this argument. But, it has been made.
At least I don't buy it on its own. If it's filled out with something else, then maybe, but so far that hasn't happened.
Then there was one guy that was saying if this goes through, then the LIRs just, they will just throw out all their space to their end users and the end users are going to say, oh, I have a need for a million addresses and give it to me and the LIR would go, okay, here you go. And I don't see that happening. Precisely because an LIR will know that I cannot go back to the RIPE NCC and cover for that million I just handed out. So, I expect that anyone with a slight amount of, the minimum amount of sense to say, apply some sort of local conservation policies to their own remaining space and that goes for anything really, for money or for whatever, you don't throw something valuable and limited out the window.
So, and if they do, then that's just their problem. We don't get ?? or the rest of us only gets another, or one less competitor to worry about. So, there is no harm done really, if this happens.
Then there was one saying that now we can buy and sell IPv4 allocations, and the RIPE NCC should reclaim allocations that are not being used and distribute it according to the conservation policy. Which is just a valid position to have, but it's not really relevant to this proposal, because this was already allowed since 2007, or maybe 2008 when it was implemented.
So, one variety of this is it would be possible for an LIR that have no operational needs for address space to buy them. That's true but it doesn't seem very likely. Much for the same reason that nobody goes and buys all the bread that's available in the store just because they can. I mean, when you have to spend money on something, you typically spend money on something that you actually need. And especially when most of us actually have a real operational need and potentially quite desperate need for those addresses and if somebody goes and says I don't need them but I am just going to out buy you for the heck it have, this concern doesn't really seem very likely to me. And that's especially because if they do that, they can't resell those addresses to somebody else until 24 months have passed and that's a limitation that this proposal does not remove. It's there in the policy today and I don't remove it.
So, if you are trying to invest in IPv4 numbers to sell them when the market goes up or whatever, then you can't necessarily sell those addresses when the market is actually high.
So... I don't think this is a very likely concern either.
And then there is the ARIN incompatibility. Which ARIN folks seem to be very concerned about. ARIN's inter?RIR transfer policy says that, well, we can trade with other regions as long as those regions base their policies on the needs criteria. And if 2013?03 passes, that will obviously not be the case in our region. Then again, we don't have an inter?RIR policy today, and ?? so cannot trade with ARIN anyway. And the proposal that actually tries to establish such a policy seems to have no consensus and very little support. And also considering how little transfers are actually taking place internally in the region, it seems like, to me at least, that the assignments and the day to day operations of an LIR and reducing the bureaucracy in those situations are more important to us as a whole than it is to be able to transfer a block or two to and from the ARIN region. So that's my point of view. It's kind of a valid concern, but I don't think it weighs very heavily.
And there is also the fact that ARIN does have a free pool at the moment. So, they have some justifications for trying to uphold the need basis for all downstream allocation and assignment paths even out of region transfers. But they will deplete soon so maybe they will Ray line their policies as well as a result, I don't know. (Re align)
The other RIRs, nobody is doing something like this at the moment. I think we're the first. AfriNIC, ARIN and LACNIC, they all have remaining free public pools, so, the last ?? they have a reason to have the need basis, and the only thing that I have heard about being talked about in those regions is the informal discussions in the ARIN region which still haven't become a formal proposal. Maybe it will be, I don't know.
And in the APNIC region it's kind of interesting because their first implementation of the transfer policy did not have a need basis component. Which made the ARIN community go, ah oh, no you don't, and implement this requirement that we talked about earlier, that they require the other RIR to have a need basis policy in order for them to be able to trade. And then APNIC said okay, we do it your way and added back the need basis in their transfer policy. So, currently, APNIC is doing need, in all parts of the policy as well.
So that was the last slide. Thank you, and any questions or comments?
CHAIR: Okay. Thank you for a very detailed explanation of the pros and cons and so on. It took a bit longer than I expected and the initial discussion also took a bit longer, so we are running into the coffee break and that's the ?? that's what I have to pay for giving up the second slot to NCC Services, so bear with me.
AUDIENCE SPEAKER: Hans Petter, I think this is a dramatic change of the policy. I think it's high time, I think we should do T I think the cost may be that we are not able to do an inter?RIR policy with ARIN. I don't think that's a problem. If you are out of addresses today, you can open a subsidiary in California, a lot of Norwegian venture companies do that anyway and you can apply during normal ARIN procedures and get your address space. I don't really see that point. On the RFC 2050 topic, RFC 2050 was developed many years ago, all address space in the RIPE region has been passed after that, not within the sort of limits or the ARIN interpretation of the limits of RFC 2050 but within our community's interpretation of that, and I think we should continue with that so this is what policy do we want in our region to live through the next couple of years. Thanks.
AUDIENCE SPEAKER: I just want to quickly share with you on how APNIC managed the IPv4 transfers. APNIC has IPv4 transfer policy to allow IPv4 can be transferred between APNIC account holders and also with other RIR regions. We still intend the need base, that demonstrated need is based on 24 months requirement. And we recommend our member to submit an approve, if they want to do an IPv4 transfer. And after this, we offer them to be released in the APNIC website. We have transfer listing service. List those companies who actually need the IPv4 space. We also have listing service for bogus, list those bogus who take IPv4 space. So for both sides we have listing service. We also have IPv4 transfer list to allow people to post their offer of IPv4 address space. If it seems so far we are working well. We have done 146 IPv4 transfers, and out of that is 11 is inter?RIR transfer from ARIN region to APNIC region.
Regarding to the list base, we continue to maintain the demonstrate for both allocation and transfer. And we don't see any problem so far for members to demonstrate their list and also there no evidence for people like trying to avoid transfer or going to the market because of this list base at this stage, there is no discussion of change at the list base in the APNIC region.
Thank you.
CHAIR: Thank you. Next one, sorry for mixing up the sequence.
AUDIENCE SPEAKER: I'll comment on that, and if you have had 11 transfers since you depleted from the ARIN region, that cannot further strengthens me in my belief that that's not the biggest concern here, and the transfers in general aren't the biggest concern. That said, I actually review the APNIC transfer policy and as far as I am able to understand it, the APNIC policy only mandates need for their own region which means that even for 2013?03 passes and the inter?RIR policy passes, we would be able to trade with the APNIC region. Then an APNIC recipient will be subjected to the evaluation that APNIC enforces, whereas the other way we would not subject the RIPE region LIR to any justification. But it will still be compatible.
AUDIENCE SPEAKER: My name is Rob Blokzijl. I think this is an excellent proposal in cleaning up a lot of regulation which was needed in the days we did distribution. Those days are over, so we don't need those regulations any more. And I think your approach of throwing out everything that is tied to the old situation and see what is left and rewrite it in a readable, sensible form is excellent exercise.
I think we should, for the progress of this proposal, we should not try to be bogged down into the ins and outs of transfer policies. I think it's much more important, as you showed with some figures, to get this bureaucratic overhead out of the way, and that will make it easier to concentrate on little add?on policies like transfer, but let the ongoing discussions on transfer policy not stop the progress of your basic proposal. Thank you for all the good work.
AUDIENCE SPEAKER: I think I'd like to say two very separate things. The first thing is that I think we have entered an era in which your basic methodology of simplification and removing of crupt is appropriate. I think that policy making simplifies the existing documents is the right way forward. That said, I think that the fallacy that you accuse the detractors of this policy of, that is an appeal to tradition, is a far more minor transgression than the straw man argument that this entire policy is based on. Whereas, you are accusing the detractors of an appeal to tradition, you are making an appeal to hedonism, and the straw man basis here is that the purpose of conservation was to conserve the free pool, which is not the case. The purpose of conservation is to conserve the resource for the use of the community. Addresses in the free pool were not in use by the community; the addresses that are already allocated that are in use by the community. The conservation is to maximise the useful lifetime of the addresses in use by the community. This has nothing whatsoever to do with the free pool, the amount of space in the free pool, or the continued existence of the free pool.
So, the need for 2050 needs?based allocation continues today with even greater urgency than when we had a buffer that protected us from the immediate effects of a lack of need?base policy; that is, when we had an unallocated buffer, 2050 was a good principle, but a failure of 2050 would not have had immediate negative consequences because you could always bail people out from the free pool. Now that there is no longer a free pool, getting rid of needs?based allocation means that speculators could have an immediate effect on the market. Bill Woodcock.
TORE ANDERSON: First of all, the conservation goal will live on in all the RIRs. Like I said, if you have a thousand addresses, and that's what you have from now until eternity, you are not going to throw those out the window. I don't think anybody would do that; they would try to conserve their addresses as best as they can and make them last. If that is overloading them into a CGN so that you get more customers for one address or whatever, or being very strict with what assignments you make.
BILL WOODCOCK: Again, this is a straw man because it assumes that the recipient had need. You only conserve on your own behalf if you actually have need for the addresses. If you have no need, you don't need to conserve. You can manipulate the pool that you have in accordance with the market, rather than in accordance with need. You are assuming that ?? the fundamental basis of your argument there, is that the recipient had need. If you get rid of needs?base, the are recipient no longer has need for conservation.
TORE ANDERSON: Well, if you come to me and ask me to assign you address space, I'm going to make sure that you have need for it because I have a limit to the amount left; right? I'm not going to say, oh, you have no need, but I'll give it to you anyway, right, because I have a limited amount left. And I think every LIR in the region have a limited amount left, and they can see that we have to play with the cards we're dealt now. We are not getting any more.
BILL WOODCOCK: That can't be trumped by money or bankruptcy? An LIR goes abrupt or an LIR needs money more than they need addresses? Either of those would trump need, and in this case.
TORE ANDERSON: And I believe that if an LIR decides that they need money more than they need their already?dealt addresses, then the basic foundation of a market will be that there is lots of other people with need and the people that have the most need for those addresses, they are ones that are going to put the most money on the table to get those addresses.
BILL WOODCOCK: So, that's the ?? I can't remember his name ?? the rent?based economic philosophy that highest need is demonstrated by greatest ability to pay. There were a few people in the Chicago school who actually believed that, but they are on the fringes of economic thought.
TORE ANDERSON: I agree, I might have a very big need but a very low ability to pay, and somebody else might have a lower amount of need but a higher ability to pay. But there are people with ?? the need is there in our community.
SANDER STEFFAN: I'm sorry, we are already running into the coffee break. I think we should ?? we are aware of your concern and I think we should move this part of the discussion to the mailing list, so we have some time for the other people at the microphones.
AUDIENCE SPEAKER: I am just speaking for myself here, because very, very surprised at the entire basis of your argument is, I am lazy, so we should delete all of the policy. That was just kind of a shock to me. So, I just wanted to make sure that I wasn't missing something. You're really just saying, I don't want to fill out a form so we are going to delete all the policy. Because cleaning up the policy does make a lot of sense, but deleting huge tracks of it willy?nilly because you don't want to fill out a form ?? there is a lot of things I don't like doing that are necessary to keep things running, and you know, knowing where my addresses are seems like one of those things that I just have to do in the course of business, and filling in a form actually becomes very, very easy if I'm actually tracking what I'm doing on my network. So that part was surprising to me.
The other piece is, I think kind of what Bill was saying much more eloquently, I would repeat in that, IPv4 is still a limited community resource regardless of whether it sits in the RIR free pool or in everyone's network. And so, that idea of conservation being gone because the free pool is gone really doesn't make any sense to me. I don't understand that argument at all because there is still you know 4.2 billion IPv4 addresses, they have just shifted where they reside. We haven't, you know, sprouted new ones. Nothing has changed because the free pools have run out. And so on organisation, say, that has a lot of money that's in the Internet business and may want to keep other folks from being in the Internet business, without necessary demonstration of need, can very easily purchase addresses or find addresses or keep the addresses that they have and not allow other LIRs to have them and hand them out to customers which is a net?effect bad for the Internet.
So, I would much rather fill out the form and have the Internet keep operating as it does today than get to, you know, have an extra five minutes a day and have things start to breakdown, personally.
TORE ANDERSON: My conviction is that we don't have to fill out the forms any more. So, I don't like to fill out the forms, I would much rather spend that time deploying IPv6 for something like this, but when we had the free pool, filling out the forms and applying the need criteria from above, like, as in having the community policy that defined that this is how it's going to be for us, a necessary bureaucracy, but once the free pool is gone, then conservation will come automatically and there is no need to have it in the policy as a mandate from above any more. That's my point.
AUDIENCE SPEAKER: Michele Neylon, Blacknight. I don't normally play around with address space much, I spent more of my time arguing about domain name policy and other things. So I have been listening to all this and I don't mean to be offensive, but I think you are being incredibly naive. There is an ?? you may find that there is an issue and an overhead with filling out forms and having to justify IP spaces, but if you remove those, that need space requirement, you are going to open this entire thing up to gaming and you are actually going to create a bigger digital divide. Because what will end up happening is, you know ?? and other speakers have spoken more eloquently than I will about this ?? but you are going to end up with a situation with whoever has the deepest pockets is going to rule the roost so. You are going to have a very, very big companies grabbing large allocations of space and transferring them around and then smaller companies are going to be totally and utterly screwed. They won't be able to expand. It will be a limiting factor. You have got developing markets in central and eastern Europe where a lot of those things that we are getting in western Europe, they won't be able to do it unless they move fully to IPv6, which is a very nice philosophical idea but the reality sits not happening very fast. So, I think if you go back a bit and look at maybe simplifying and clarifying policies, that's fine. But removing the needs based requirements is incredibly naive. I mean, you may think that everybody here is very, very sweet and very, very nice and would never do anything nasty or anything like that, but I can assure you there is plenty of people who will abuse the system to, and make lots of money out of it. And the rest of us will suffer. We are a relatively small company, we are going to need more IP addresses and IPv4 in the future. If you remove that, you are basically going to limit our ability to grow.
GERT DOERING: Let me answer that, please. I completely don't buy that argument at all. Because if you want to gain the system today and do transfers to the one who pays the most, you can. Because everybody can demonstrate need today on the level of ??
AUDIENCE SPEAKER: If you remove the barriers, you end up putting us in a position where other regions like ARIN are going to lock?down the policy so they won't allow transfers of IP allocations from the ARIN region. That's what seems to be you're suggesting.
CHAIR: First thing, ARIN doesn't allow transfers to the RIPE region today anyway.
AUDIENCE SPEAKER: That's because ARIN doesn't have a policy on the transfers.
CHAIR: There is no real interest in our region to permit transfers from ARIN, because we have a policy that nobody is interested in. So, the whole argument of transfers from ARIN is actually something I'm considering as rough consensus and not following. And all the arguments from the Americans in here that the RIPE region should keep the needs proposal is also something that sort of surprising me. I would like to hear more from the RIPE region actually. I think the next point is Marco representing Jabber.
AUDIENCE SPEAKER: A comment from Jabber ??
TORE ANDERSON: Can I respond also first? You pointed out the elephant in the room, which is people are going to abuse the system, and once you accept that, they are going to abuse the system no matter if we say, oh, you have to have need and I say we have need, okay, here you go. And so, if you are willing to abuse, then there is no amount of policy that's going to stop that. I mean, even if you can't register the transfer, you can still say, okay, this LIR puts up a big amount of address space for sale and I'm interested in keeping this off the hands of my competitor, instead of buying the address space, we can just pay that LIR to take it off the market. Sign a contract. You do not transfer this address space or you don't transfer to my competitor. So, abuse can happen no matter what. So, I don't see how we can pretend that the RIPE policy document is going to prevent abuse from happening and people are actually lying.
AUDIENCE SPEAKER: Raising the bar, you are making it more difficult ??
TORE ANDERSON: That raising the bar was the...
MARCO HOGEWONING: Marco relaying from jabber, message from John, informational point in response to an earlier speaking in opening an subsidiary in the ARIN region to obtain address space. Note that this only works if you are obtaining the addresses which will be substantially used for infrastructure located in the ARIN region. This is not a view for or against policy proposal, just a clarification for this community.
CHAIR: Thank you.
AUDIENCE SPEAKER: Last comment. I have a lot to talk on the issues raised in proposals, but I want, first of all, to commend on some statements that I heard in this hall today to escape any misinterpretations on RFC 2050. I want to+ remind you it was written ten years after we exist. It just described how we lived ten years ago, and even on the discussion on 2050, it was confirmed that the just information description document. Nothing more. It's not a law and I prefer to escape any references to 2050. 2050 should reflect our policies, not our policies should reflect 2050. Thank you.
CHAIR: I see Rob still standing, so...
SANDER STEFFAN: I must say a lot of the comments that came from the room had already been addressed by Tore in some slide. Obviously, there is still some confusion there so we need to that I can that to the mailing list. But ?? thank you ?? we still have a speaker at the microphone. Sorry.
AUDIENCE SPEAKER: Louis Sterchi. I wanted to address one comment about how it, this policy potentially hurts smaller people, smaller companies in their respective fields. I think, I actually would argue that the contrary, that this argument actually potentially helps them. Two years ?? being able to demonstrate need, you can ?? a huge company can demonstrate incrementally more than a small person can and that's not necessarily an issue when there is infinite space in a world where there is finite space, as we know, that incremental extra that they are able to demonstrate, whether they do it nefariously or actually by the books is so much more that there are already at a huge competitive advantage. So by taking that away and letting a smaller company potentially get more, if they are able to justify ?? sorry, without justification, but sort of take a longer view, it gives them actually a more level playing field than they currently have today.
SANDER STEFFAN: Thank you.
GERT DOERING: Well, thank you for the comments. I'm closing down the mikes know. We are well into the coffee break, sorry for that. Thanks for bearing with us.
There is one other thing I have on my mind, which is quick, which I'm not going to put on the screen.
There is the idea of unifying the IPv6 PA and PI policies to basically only have addresses. I initially planned to have something on the table, something like eight months ago, and, well, life caught up with me and I couldn't find time. So, I'm actually going to ask for volunteers to help me with that on the mailing list since we're completely out of time today, and bring back that topic, because it's interesting and relevant and I just don't have the time to do it properly. So, volunteers will be needed.
And with that, I conclude the Address Policy Working Group session for today.
Thanks again for being here and giving feedback. Enjoy your coffee and at 11:00 it's NCC Services, not Address Policy. Thank you.
(Coffee break)
