These are unedited transcripts and may contain errors.
16 October 20139 a.m.
Address Policy Working Group
GERT DOERING: Good morning dear Working Group or whatever is left of it. I'm happy to see a few faces here, I assume the party was great yesterday but I have been told that those that are here are those that didn't go to the party, so that speaks for its own.
The face you see on the slide is John /POS tell, it's his 15th death day today so he died 15 years ago today, and I think it's a nice idea to spend a few seconds in memory of John past tel. If you don't know who John past tell is you are young enough to be really fresh blood, talk to one of the old timers, it's worth it.
This is the first slot of the no more Address Policies Working Group, so in the 9 to 10:30 time slot we will be discussing IPv4 and after the coffee break this is the Address Policy Working Group which will discuss IPv6 policy.
So, we are the two Working Group Chairs, my co?chair lost his badge somewhere, but we are identified by the yellow badges if we carry them around. I'm Gert Doering, he is Sander Stefan, but looking into the room I am sure all of you know us anyway.
This is what we're going to do this morning in the 9 to 10:30 time slot. First, a few administrative matters.
The usual stuff, then the policy overview given by Ingrid Wjite from White the RIPE NCC. Then feedback from the NCC registration services from the troubles they have been seeing, discussions with customers and so on given by Andrea Cima.
Then we will enter discussion on the currently open policy proposals for IPv4. And after the coffee break, we have the big IPv6 policy proposal on PA, PI unification, and a few smaller points about the use of RC 2119, statements like should and must in policy documents. And if time permits, we will spend a few minutes on discussing how this Working Group is selecting its Working Group Chairs, or not.
So, agenda bashing. Administrative stuff, is there anything I have missed? Anything you want to see on the agenda?
No...
Minutes: The minutes from RIPE 66 in Dublin have been sent to the mailing list. One sentence was attributed to a wrong person, that has been corrected. No other comments have been received on the mailing list and unless there is more feedback right now, I will just declare them final. So any inaccuracies in there?
No... okay, so the minutes from RIPE 66 are now declared final.
And I forgot one slide, actually I lost one slide. The administrative staff PIRA additionally has thanking the scribe in it, and that's Anthony from the RIPE NCC who is trying to make sense from what we say, the stenographers and Marco as the Jabber human gateway. So, I know this is not easy, thank you all for your work.
Now we go to the current policies to Ingrid.
INGRID WIJTE: Good morning. Thank you for coming this early. I'll be giving the policy updates this time.
And I'll start first with a brief overview of the proposals in the RIPE PDP and then give a brief overview of what's happening in the other regions.
So, the proposals in RIPE PDP, we have a few archive proposals that reach consensus and were implemented. Run?Out Fairly was reverted, we now extend v6 per LIR ?? sorry, per allocation versus per LIR. I didn't even go to the party last night. Imagine that...
And there is no longer a requirement to certify reallocated IPv4 address space.
Two proposals were withdrawn the intrapolicy proposal and PI assignments from the last /8. The proposer decided to withdraw these for lack of support.
Now to the ongoing discussions. There is two proposals in discussion phase. One in the Anti?Abuse Working Group regarding openness about policy violations, I believe that will be discussed in that Working Group later this week. And a large proposal regarding v6 address space which will be on the agenda today with quite sometime to discuss it.
Then we have quite a few proposals in review phase. We have the inter?RIR transfer protocols proposal, which is actually awaiting outcome of some other proposals. The 2012?07 and 2013?03, I believe. 2012?07 that's one in the RIPE NCC Services region Working Group, and will be further discussed there. The no needs policy proposal on the agenda today, and the restrictions on end user assignments in inter?RIR transfers currently address space can only be transferred if the block is unused and this proposal intends to change that.
One more in review phase in NCC Services again, that Working Group is quite busy on the policy proposals nowadays and there is one in last call regarding resource certification for non NCC members.
So that's for the RIPE PDP, there is quite some activity. There is also some discussions in the other RIR service regions, and I tried to group them by topic.
With regards to v4 depletion, ARIN has a proposal regarding the allocation of address space for out of reach requesters. That one received a lot of discussion in the recent meeting in Phoenix, and in short, the question is whether ARIN should hand out space when the network is not fully used in the ARIN region. That one is going to be discussed lots more before ?? no, I see some nodding from the ARIN people ?? okay, does not seem to be going well, but I'm sure the AC will be giving and update on that very soon.
In LACNIC, they are discussing a proposal to change the policy for IPv4 exhaustion. They have reservations for new members and for gradual exhaustion and the proposer tends to increase those pools, both pools from a /12 to a /11. And in APNIC they are discussing how address space that comes back to APNIC should be distributed. They have a last /8 policy in place which they said a member can only ?? or a requester can only receive up to a /22 from that /8. And now they intend to have a separate policy for address space that comes back, so that the members that already received from the last /8 can also receive some address space from the space that got back to APNIC.
In this region, as it stands now, all address space that comes back is distributed according to the last /8 policy. So there is one policy for all the address space that's in our region to be distributed.
Then with regards to resource transfers, AfriNIC and LACNIC are discussing inter?RIR address transfers. They are being discussed, so far no consensus. In this region it's on the ?? APNIC and ARIN they already have a policy in place.
In APNIC and ARIN, they are also looking at A FM transfers. ARIN abandoned that policy proposal and in APNIC it's actually in the final comment period, so about to be accepted. And this policy proposal caters for both intra and inter?RIR transfers of ASNs.
In AfriNIC, they are almost ready to remove the requirement to announce your v6 allocation as one single aggregate. I believe they are the last region to make this change.
And finally, there is some discussion regarding the RIR principles in both ARIN and LACNIC. Now that RFC 2050 is historic, those principles may be added to the v4 policy documents and some references so the RFCs need to be updated.
And then there is some URLs and contacts information and I'll take questions, if there are any.
GERT DOERING: I don't think there are questions, so thank you.
(Applause)
GERT DOERING: Maybe a word of explanation in between that I should have said before. Usually this topic is given by Emilio, and unfortunately Emilio left the RIPE NCC, so, we are in a sort of like intermediate phase with reorganising the policy development office at the NCC and Ingrid has volunteered to step in for the time being, thank you for that. And with that, we now go to Andrea to the feedback from NCC RS.
ANDREA CIMA: Good morning everyone, my name is Andrea Cima and I am part of the registration services team at the RIPE NCC.
What is the goal of this presentation? Now, we as registration services department want to report back to you as a community. We want to report back to you the feedback that we receive in our daily work from LIRs, and we want to also highlight eventual issues that we see when we do our job.
So, it means that sometimes we will ask you for guidance. We will ask you can you please tell us what you would like us to do in a situation, but we also want to provide input for you for discussions.
Now, I'll quickly go through the topics that we have discussed last time to let you know what the outcome has been and I want to introduce a couple of new topics.
Now, during RIPE 66, we introduced the returned but referenced AS numbers, these are AS numbers that have been returned by the users to the RIPE NCC. However, those AS numbers are referenced in other RIPE database objects, meaning that we have never been able to resign those AS numbers to other organisation that is need them. During RIPE 66 and on the Address Policy Working Group mailing list you gave us feedback, you told us to go ahead and clean the references, thank you for that, and because of this we have created a process, a procedure that has been published in labs article and summarising this, we will contact the holders, the maintainers of the objects in which those AS numbers are referenced, asking them to help us with cleaning these entries.
Another topic that was discussed during RIPE 66 was the transfers of Address Space that is actually in use, now, what happens is that there are many organisations that have a PA assignments from one LIR, they become LIR themselves and they would like to move this address space that they are actually moving for their infrastructure or for the customers to their own LIR. Now, this was not foreseen by policy, and therefore this was not allowed. Now, we brought this up during the last RIPE Meeting, there has been some discussion and this ended up with the creation of policy proposal 2013?05: "No restriction on end user assignments in intraRIR transfers." Also this input that we have given you for discussion has brought this solution.
The last point of discussion of the last RIPE Meeting, which has not been resolved yet, it the changing of the status from PI assignments to PA allocation.
Now, to give you a little bit of background information, it happens that organisations receive a PI assignment, then they become an LIR, and they would like to change this PI assignment into a PA allocation. Now, there are multiple reasons why they are requesting this. For example, they want to due to scarcity of v4 addresses they want to restructure their network and PI addresses can only be used for the original criteria for which they have been issued. Some organisations want to make customer assignments out of it and others like one of the brokers mentioned yesterday on the panel, other organisations would like to transfer their resources to an organisation which is not allowed with the PI.
Now, we proposed initially two solutions. One is we do not allow this to happen. We keep the policy as it is, and the process as it is. And one is to allow LIRs to change the status of their PI assignments into PA allocations. Keeping in mind the minimum allocation size, which is a /22 at the moment.
On the Address Policy Working Group mailing list there has been quite some discussion, there seems to be some kind of consensus about allowing LIRs to change the status from PI to PA, but also there seemed to be quite a lot of people in favour of ignoring the minimum allocation size so, getting rid of that. So this point has not been finalised yet, so how would we like to proceed with this Gert?
GERT DOERING: This is actually where I'd like to have some input from the room, and potentially a volunteer. The policy document, as it is now, is understood by the NCC to not permit allocations smaller than the minimum allocation size. When looking from the outside as what should be the thing, I would have said well the minimum allocation size is for allocations made by the NCC, and changing PI is not an allocation made. Well on the other hand, it's made into an allocation, so that's all semantics again.
So to be sure that we know ?? well, the NCC knows what the community wants and is asking for, I think it might be good to have a policy proposal to actually change this ?? change the wording to make it clear that this is okay, and the minimum allocation size doesn't apply for that, if that's what you want. But as the policy text is now, the NCC says they cannot go ahead with this, at least with allocation smaller than the minimum allocation size...
AUDIENCE SPEAKER: Good morning, Freddie /KUPBS letter, I vote for it should be ignored. If we consider why it is actually made up the allocation size, I mean, we look back in history a bit and then we had this allocation size. When I started it was a /19 I believe, and people were actually able to consider the small ?? this is the smallest block from that and this /8 we are going to see in the routing table. This is no longer the case, as we all know, we see recommendation, so just abandon it and ignore it because I mean it's not real life what we are discussing here.
GERT DOERING: That's actually what we heard on the mailing list. The problem is was the policy text we have, I think ?? well the NCC thinks cannot just do it so we need to change the text and I would be happy if somebody who would be willing to volunteer on that. Maybe not Tore who has spent a lot of work on policy text, but you are at the microphone.
AUDIENCE SPEAKER: Tore: To add?on what Freddie was saying, the minimum allocation size, the way I perceive it is the purpose of it is to fulfil the goal of aggregation, right, to not make lots of small allocations and you know float the routing table, but all of these PI assignments, they are already made, so if we say that it's okay, if it's a /23 and it's lower than the minimum allocations size, we can relabel it, but cannot further deaggregate it than what it is initially. Then I think that is consistent with the aggregation goal, it doesn't hurt the aggregation goal. So that's all.
SANDER STEFFANN: Indeed, the assignment allocation is already out there, to changing the label daunt affect aggregation in any way.
AUDIENCE SPEAKER: Wilfried Woeber. I'm just the same opinion because we have assigned these PI blocks from a separate pool, so even in the past it was known that from this pool, we can see the prefixes being announced, so even if we agree to this one, I don't see any noticeable impact on the operation of the network or I don't see any major need to modify filters or something like that. I think it's just the relabelling so I'm in favour of that.
AUDIENCE SPEAKER: Hello, Marco ?? Jabber ?? my personal opinion would be that we should allow changes no matter what the size would be and I don't think that we do need policy proposal to change that. I don't think we do need a policy proposal for that.
GERT DOERING: Okay. I think what I'm hearing now is some action item on the NCC, and that is that you tell us on the mailing list exactly which bits of the policy you interpret which way, so it's very clear that these sentences you interpret this as cannot do, it and then we try to find a volunteer then. If it's sort of like conclusive that this is really the only valid interpretation of that, then we find a volunteer to work on changing it.
ANDREA CIMA: Thank you. It's good to receive this feedback to see where we stand. Thank you.
So these were the topics that we discussed during the last RIPE meet and then further on the mailing list. So, as you have seen, it it has brought some actions and changes.
New topic that we would like to bring up this time are two.
One is AS numbers, 16?bit AS numbers. We are all aware that the global supply of 16?bit AS numbers is slowly being exhausted. If I'm wrong the IANA has about 500 of them left in their pool at the moment for allocation to RIRs.
Now, we at the RIPE NCC still have a good number of 16?bit AS numbers. However, these will eventually be exhausted. There are about 5,000, 16?bit AS numbers which have been issued in the RIPE region that are currently not being advertised. Now, according to policy, if an organisation no longer uses the AS number, it must be returned to the public pool of AS numbers.
However, at the same time, we never went after those not advertised AS numbers because I have been told a number times you guys are not routing police so we stay away from that. However with the number of 16?bit AS numbers being exhausted I'm bringing this question to you. What would you like us to do with this? Would you like us to not contact the holders of those AS systems and leave things as they are? Or would you like us to contact the holders of those and advertise 16?bit AS numbers and ask them if those AS numbers are actually used or not, and if they are not used according to what they tell us, would you like us to ask them to start using the AS number within a reasonable time frame or otherwise return it to the available pool so that you can reuse those AS numbers for other organisations that is need them?
GERT DOERING: I think you already said one very important sentence. If they are used as far as they tell us, because there are certainly case where is you just can't see it in the global routing. Wilfried.
AUDIENCE SPEAKER: Wilfried Woeber. Just returning to a different question: Do you see sort of large number of requests for 16?bit AS numbers in our region?
ANDREA CIMA: That's actually a very good point because I think that in the RIPE region the operators are doing really well with 32 bit AS numbers, I think more than 40% of the AS numbers that we issue are 32?bit but still we like have 60% are 16 lit bit, even those this is slowly decreasing. So over time I believe there won't be a problem any more but currently we are still receiving a number of 16?bit requests.
WILIFRIED WOEBER: And you don't have any left.
ANDREA CIMA: We currently have ?? we have a few thousand left. So that's why we are asking this now so that if you give us the mandate to go and look at those we would have the time to look into this. But we are for the moment we still have 16?bit AS numbers left, yes.
WILIFRIED WOEBER: The reason I'm asking these questions is that going after the holders of those maybe unused AS numbers is just putting a load on the IP resource analysts and if there is no shortage at the moment, then I don't really see why we should spent the effort to go after those. As soon as you perceive sort of a real need to find more of those old numbers, then I think it's the point in time to, with a reasonable lead time of course, to ask that request again. Otherwise I think it would be more useful to focus on different issues.
ANDREA CIMA: As far as we can see, I think we have like 16?bit AS numbers for about one?and?a?half years still so, that's why we are asking this question now to have time in case you give us the mandate to actually process those requests. Thank you.
AUDIENCE SPEAKER: Rudiger Volk. My ageing brains don't recall which chapter and verse I should be looking for that policy, then the question ?? well, okay, giving chapter and verse for that would be a nice thing. The next thing is does it say "Use" or "Announce"? And when it says "Use," which should be the correct thing.
ANDREA CIMA: Yes, the text, I am quoting "The autonomous system number assignment policy, it's RIPE 525 says "If an organisation no longer uses the AS number, it must be returned to the public pool of AS numbers."
AUDIENCE SPEAKER: So it says use and use of AS numbers is not only in BGP announcements.
ANDREA CIMA: Exactly.
AUDIENCE SPEAKER: Okay. That's important to keep in mind.
BILL MANNING: The next slide please. I think A is appropriate, but the notification should be a notification that says RIPE does have policy 525 and we'd like to make sure that you are in compliance with that with regards to these resources. Going back when you hit a time of scarcity and trying desperately to recover addresses is ?? has proven to be less successful. If you are a prudent steward of the resource, then you would check regularly with those people you have allocated them to. So I think that you shouldn't wait. I think you should have an ongoing process that says hello, we see that you have this AS or these resources and we want to make sure that you are aware of the current policies regarding these resources. And if you are out of compliance with these policies, you might want to take steps to become compliant and we'd like to help you. And in that way, the people who hold those resources know that RIPE is a good steward as opposed to a panic after a company has gone out of business for four years and you are trying to find the appropriate party to reclaim the resource. It doesn't ?? I mean, that's just my point view.
ANDREA CIMA: If I may answer. It's a very good point, one of the ways that when we were talking about the referenced AS numbers, we have seen the number of returned AS numbers increase a lot and that was also through the 2010?701 policy implementation according to which an organisation has to enter into a contractual agreement, either with the sponsoring LIR or the RIPE NCC, and during this project, the organisations that are not existing any more we have not been able to contact they were not using the AS numbers and those AS numbers have been adjusted so there has been some kind of a cleanup process which has been ongoing for the last few years as well.
AUDIENCE SPEAKER: Geoff Huston: We have 429, 32?bit ASs in the routing table. 24 hundred of them were originally allocated RIPE NCC. It seems that this area of the world is well and truly capable on the whole of actually doing full byte ASNs. The only really anomalous recently is ARIN where 24 bit are in the routing table which seems weird. The problem seems more for there than here. I note you have 5324 unadvertised 16?bit numbers. If you were able to contact ten people a day, that's 18 months. That's an awfully long time to contact folk and do the negotiation. I'm just wondering is it a more broader question. One of the things we thought about when we thought about what we did with v4 addresses was that actually allowing other folk to broker and trade actually flushed out unused addresses for efficiently than we could. I notice ARIN has done a policy around transfer of AS numbers which might well have a similar effect for actually identifying and recycling old numbers in the AS block efficiently. You might want to consider that kind of policy as an alternatives tif to using the registry doing this, quite long and expensive issue of contacting and establishing, because other folk might do it for you cheaply. I'm not suggesting you should or you shouldn't, I'm just observing that's a side effect of what's happening in the ARIN policy in this space.
AUDIENCE SPEAKER: Rudiger. Stepping a little bit to the side, I wanted to point out that Geoff's observation of 4 byte AS number take up in the various RIRs looks to be a little bit ?? well, okay ?? coming from some cultural thing where someone has moved and others haven't. I would like to remind that I think, yes, on reasons of equipment used and so on, there are really no acceptable reasons any more for clinging to 16 bits, but there are a few corner cases where actually certain functions cannot be done for 4 byte AS numbers because the protocols don't provide the appropriate data structures. I know certain functions in the portfolio of the services of my network that will not ?? that are only available for targeting 16?bit numbers. I cannot expand the community field by another 16, or 32 bits. And kind of requirements for actual use may come up from that side and it is really not predictable where that will be a real requirement because when people start, they probably don't understand what holes we are running into. So ?? well...certainly RIPE NCC should keep those numbers available and make sure that numbers can be moved to parties that have a need. That does not necessarily mean it has to go through the RIPE NCC mediated policy process, not really having an opinion on whether that needs to be recognise regulated.
AUDIENCE SPEAKER: Freddie again. I support what Bill was saying. And I would like to focus quickly on the term "Use." I mean what does use mean? Usually people use an AS number for routing purpose, so I'd say 99 percent of all AS numbers are showing up in the table when used. So, I suggest that the RIPE NCC should contact those guys which have an AS numbers but are not using it in the global table after let's say 12 months. I mean you start sending out e?mails saying you are not complying to policy, whatever, 525, and then the 1% which is actually using an AS number not showing up in the global table they still can have a reasonable explanation for that, so that seems to me a pragmatic way to reclaim AS numbers which are not in use.
AUDIENCE SPEAKER: I have to disagree, I agree that the majority of those AS numbers would probably be visible in the DF set but there is probably a few case where is you don't see them and where there is a proper use case for a globally unique AS number, so I sort of ?? I'd like to put that into perspective, the use is not just being visible in the global routing. There are different case where is this is not the case. Thanks.
GERT DOERING: I think that's well understood by the NCC as we had the discussion before, so, that was why they are going to ask are you using it, not just looking into RIS and oh it's not announced, take it back.
So what I'm hearing is that there is not an overwhelming rush to make you do it but there is also not strong opposition, so, I would actually sort of bring it to the mailing list and say feedback we had was half?way positive. This is what we intend to do. What does the list say about it?
ANDREA CIMA: Yes, we will do that. Thank you.
The next point if I may stay a few more minutes. The next point we wanted to bring up, this is mostly for discussion and it's mostly for awareness, is one of the things that we have seen when doing our daily job is an increase in the requests for transfers of provider independent address space. Now, current policy does not support transfers of PI address space. Therefore we have to often deny those requests. According to policy, there is a transfer policy but that is only about allocated address space, not assigned, and we have the part of the policy text that says that assignments are valid as long as the original criteria on which the assignment was based are still valid.
This means that if you want to transfer your PI address to say another organisations that will make a completely different use of them, this is some discussion not valid any more and the provider independent space should be returned to the RIPE NCC. So there is a way however to transfer PI address space and that's through acquisition, merger acquisition, you acquire the other organisation, or you acquire their network or the service that is they provide with the customers in this case the IP addresses are still used for the same purpose and can still be continued to be using.
So, one of the things that we have noticed, and we just want to make you aware of is that quite often when we deny those transfers of PI requests, we see afterwards a change in the contact details anyway in the RIPE database, organisations tell us, oh, okay, cannot do that, it's a pity. Thank you very much, please close the ticket. But then if you look at the object itself, you see that the contact details have changed. Maybe the organisation name is still the same, but the contact details change, which means that we would expect that maybe the transfer has gone through anyway and the data has not been properly reflected in the registry.
So, this could be some kind of a barrier for organisations to keep the registry accurate and current.
Another point is that sometimes when we say that we receive some immediate acquisition documentation, some transfer agreements of networks or customers which are two scribbles on a piece of paper and actually seems to be improvised as well. We have a bit of a feeling that for a number of organisation this is current policy is seen as a barrier, but this is, like I said, more of a heads up to bring eventually for discussion in the community.
And I'll be taking if I questions if there is time and if you have any.
GERT DOERING: Well there is time for some more comments. Thanks for bringing up these points. I'll hand to Wilfried.
WILFRIED WOEBER: A comment. My feeling is that this issue that you have brought up with PI and that sort of things, I think we should look at the problem with a broader view, because in my books, legacy address space is also PI in the sense that it is not given to an LIR to be cut up into pieces and redistributed to End Users, so my feeling at the moment is as soon as we tackle that one, we should do it more or less in parallel or just seeing most PI and legacy as the same problem. Because, if we are not doing that, if we are coming up with a special handling for PI, we are just making this whole policy landscape even more complicated and even more different depending on what the history of address blocks is and I think this is the wrong way to go.
ANDREA CIMA: If I may add something, the PI and legacy resources are of course different in the sense that PI follow policies set by the RIPE community as the IP space has been issued by the RIPE NCC. But I understand when you say that creating many different flavours of transfer policies for different, for resources with different statuses is complicating the landscape and we see this when we talk to LIRs, when we talk to End Users. It's like okay, for allocated PA I'm allowed to do this but for PI I'm not allowed to do something and I have to do something and it can be quite confusing, so yes, that is what we see in the community.
WILIFRIED WOEBER: And we are also in the process of sort of bringing legacy address holders into the system and sort of doing this contracting thingy with the sponsoring LIR, so I don't see any major difference in handling of those address spaces in the long return. Whether it's being PI and distributed by the RIR or whether it is legacy which has been distributed by the top level, by IANA, I don't think this is a major difference in handling of the address space in the future.
SANDER STEFFANN: I can respond to that, as I am involved in 2012?07 which is about bringing the legacy space into the fold. The legacy space is actually different in regards to which policies apply to it, so, I think if you want to discuss that, it should be done in the NCC Services Working Group later where 2012?07 is but this doesn't policy doesn't apply to the legacy space anyway.
GERT DOERING: But maybe Wilfried is right and it should be ?? it might be a worthy goal to just look at addresses as bits and ignore the colour. We actually tried that for IPv6 in the next slot, and you will see that this is surprisingly complicated, making it simple isn't always... anyway, there was another comment.
AUDIENCE SPEAKER: On the part for PI space, what's your view on how we should proceed in that? Do you think the community in itself actually wants to have a transfer policy in place or clear, more clear structure on how to deal with PI? Because I see in our own company, we get questions from customers saying well I have this IP space colour A, B, C, and can we actually buy this space? Can we sell this space? Can we transfer it to somebody else? And obviously we know all the corner cases on what we can do or cannot do. However, it does not make sense for End Users and it doesn't make it clear currently on why they can do things with IPX and cannot do this with IPY. So, what would your view on the current situation and what you see in the NCC would be the best in this and how can we help you actually make our lives easier and also yours? Because updating the registry should be key, and that should be the priority regardless of colours of IP addresses, and as you stated already, and I have seen it as well, it will happen anyway.
GERT DOERING: Okay, so, if I may answer. What I seem to be hearing from here is that this is a real problem. This is affecting people that are not here because it's, well the PI holders usually don't go to RIPE meetings, but you seem to have direct contact with people that run into this, and well, if we want to tackle it, we would need a policy proposal and for that I would need a volunteer, I seem to recall that you have experience with policy proposals.
AUDIENCE SPEAKER: I have done some PI policies and I'm absolutely do not have a problem volunteering for this one.
GERT DOERING: Thank you very much for that. A round of applause please, because that's work. So I think the way forward is that you two talk to each other in the coffee break and see where the itch is, then we try to work out how to scratch it, yeah. Last comment, Freddie.
AUDIENCE SPEAKER: Freddie again. I have a question unrelated to PI and PA. Andrea could you please go back to the slide where we have the reference ASs from last, from RIPE 66. I wonder whether the new, or the work of the RIPE NCC already had an effect ?? you started a couple of weeks ago sending out mails about the referenced AS numbers which are actually the pool, so do you see any effect of that already?
ANDREA CIMA: Like you mentioned we have just started with this, sending out first batch of automated e?mails. We have start with a very small batch to, of about 100 e?mails to see what the reaction S also, to see what the work load related to it is, and based on the results of this first batch, then we will proceed with the next batches of e?mails. So, yeah, we have only started with 100 and we really do not have tangible results yet. But we will keep you updated. Denis has written an article are the process describing the process and the reasons on RIPE Labs and we will write and updated article as soon as we have some results. So, full transparency and keep you updated.
GERT DOERING: I think we are fine now and we are perfectly on time. We could have one more question or comment. Rudiger. Or two, we are afford that.
AUDIENCE SPEAKER: I'd like to give my opinion to the question Andrea asked: Do we allow PI assignments transfer from one organisation to another? I think yes. If we have transfer agreements signed by both sides. Thank you.
RUDIGER VOLK: Kind of Andrea made a remark that makes me talk on something that's a little bit off topic. You mentioned yes, there is less article this is describing this process. Do we have official process descriptions that are only there? Do we have some systemic inventory of where I can go and look for what are the actual valid things? My understanding of Lapse is that well, okay, this is personal utterings from certain people and the usage tool says we could go away, we try not but, well, okay, having the official stuff there only is by far not sufficient.
GERT DOERING: I think that's a valid point. Somebody else has also raise that had on one of the mailing lists that official procedures should not be on labs, because that sort of like seen as a person block and as soon as you start doing this it's not personal any more.
ANDREA CIMA: In this case it was the official announcement was done on the mailing list, but I agree, I agree that ?? yeah, we will ensure that this process, this project will be documented on the RIPE dot website. Thank you.
GERT DOERING: And with that a big thank you for bringing up these things, standing up there.
(Applause)
GERT DOERING: So, when we were discussing the 2011?02 which was the removing of the multi?homing for PI spaces. One of the opposing arguments that was it would make the routing table explode and when we decided to just go ahead anyway, I promised to keep track of the PI assignments from the RIPE region and this is from my usual routing tables statistics. The problem is that you consistent actually see the PI. It's the dashed red line hiding here. The policy proposal went into effect about here, so if indeed the PI would have exploded, you should have seen some noticeable change there.
So far, we have seen an uptake in the PA allocations. Over here when IPv4 ran out, but IPv6 PI is still growing quite slowly, so I don't think we have a problem here.
As promised, we will monitor it and report every RIPE Meeting, but so far everything is good.
Now we enter discussion of the open policy proposals and I just want to remind you of the house rules. Decisions are not made at RIPE meetings. Decisions are made on the mailing list or by the feedback on the mailing list. The meeting is useful to have quick feedback to bounce ideas back and forth and so on, but the mailing list is what is publicly available, what is easily accessible for people that can not come to the meeting, so that's what really counts.
You all know the drill. If you say something, please speak to the microphone that people that are not here can hear you. Please speak your name and if it's relevant, the affiliation, if it's not, then not.
And there is an Jabber channel to provide remote feedback, but you all know that.
Discussion of open policy proposals.
The first one we will do without presentation, and discussion. That's 2012?02, that's the policy for inter?RIR transfers of IPv4 address space. Which sort of did not find very much interest by the community, so at the end of the review phase, the Working Group Chairs decided that there is not enough support to go forward to last call. The proposers then ?? well, decided that the text might need changes because it's too computer?science oriented for normal people and there wasn't clear consensus anyway. Then the proposal 2013?03 came up which, if it is accepted, will change the conditions under which we can transfer stuff to and from ARIN, so this policy proposal would need changes to be compatible with ARIN if 2013?03 goes into effect.
So the proposer has said that they want to wait for the result on 2013?03, and then this will be reopened. So, that's the status of this. Nothing has happened in the last half year. And we might see a revised version at the next RIPE Meeting.
2013?03:
If you are reading the mailing list, I am pretty sure you have noticed that something is going on. That's the post?depletion reality judgement and cleanup proposal. It used to be called no need, but due to bad public relations, we have been asked to not call it "No need" any longer.
Some textual changes have been made. It went into a new review phase which is about to end coming Friday. The proposer is here, and I just hand the microphone over to him.
TORE ANDERSON: I am Tore Anderson still. I'll give you a quick status update on the proposal. I won't go through it like I did in Dublin. I'll just talk about what's changed since then.
We had and Impact Analysis published by the RIPE NCC and we went to review phase and that was extended because it was in the middle of summer and people were on holidays, so, it needed some more time. And there was some feedback that led to the proposal being changed which meant that we went back to a new Impact Analysis and a new review phase, that is still active.
So, the amendments in the proposal are three, and the first one is to keep the overall policy goal of fairness. So, the initial proposal removed the entire paragraph there which were ?? well the intention was only to remove the part that had to do with maximising the lifetime of the address space, so the last sentence. And it was pointed out that if you remove the entire paragraph, then we are sending a message that could be construed to mean that we don't care if the address goes into operating networks any more, and that's not the intention of the policy proposal at all. So, the amendment is basically to keep the first sentence intact as it is in today's policy, and that's also helpful when explaining this policy change to other entities or other RIRs and governments, etc., etc.
So, the second amendment is to update the allocation criteria for who can obtain an allocation, and before, in the previous version of the proposal, it was enough to be an LIR, you could just tell the NCC I want an allocation, and you'll get it just like that. Even if your reasoning for wanting the allocation was not to actually put those addresses into use, so the amendment says now that in order to obtain an allocation, you need to promise to put those address into use in the network because of the previous slide, this means that it actually has to go to a user that is operating a network and it has to be done fairly.
So, this means that if you want to start a new LIR only to receive a /22 and to immediately proceed to selling this /22 on the market, that's not sanctioned by the policy. So this makes that clear. And by extension, this applies to allocation transfers as well, because the transfer policy says that there are no difference between transferred allocation and allocations received directly from the RIPE NCC, so in order to receive an allocation, you would have to make the same pledge or promise. And this is also beneficial for external relations because it removes any confusion that someone might say, well, no the RIPE NCC is just about selling IPv4 address space, it's a for profit outlet of some sort, and this takes away that potential confusion, or miss characterisation of what the RIPE NCC is actually doing.
The third amendment is the criteria for what size assignment an IXP can get from the reserved IXP pool, and that was something that the previous version of the policy proposal removed because of some sort of layer of indirection. The IXP assignment policy didn't say anything about this, but it had an implicit reference back to some other part of the policy which the proposer deleted, thus the reference became pointing nowhere and it was left undefined. So basically what we have been doing here is just to put back the specific current operating procedures of the RIPE NCC into the policy text, so that nothing actually will change.
And those are the textual changes to the policy since Dublin. And I'd also like to point out that all of the precise wording of these amendments is something that I have been collaborating with the RIPE NCC on to ensure that their interpretation of the new text is exactly what we want it to be, and there is no confusion there.
So, that's the current status, and what is going to happen now is that we are going to change the supporting notes of the policy proposal, because based on the feedback from the Working Group on the second review phase, it was said that the notes, they are giving the wrong message, and I can sympathise with that concern because I am an LIR Hostmaster and when I wrote the proposal it was written with me and other LIR hostmasters in mind and it focuses on the interactions between the LIR and the end user and the need bureaucracy, the documentation bureaucracy on that specific level, and that's where the nickname "No need" comes in.
But on the the other level such as between the RIPE NCC and the LIR, there is no such "No need" change. Nor does this "No need" nickname mean that I expect LIRs to stop checking if their customers actually need the addresses. I believe that I will continue to do so because they have only a certain number of addresses left and they will probably want to conserve them as best they can, but there is no reason why this has to been coded as a very specific bureaucracy end policy any more.
So Malcolm Hutty has been talking to me and the Chairs about how can we improve the notes to send a better message that actually applies not only to, you know, where I'm standing as an LIR Hostmaster but something that is better when communicating to external entities such as governments or other RIRs or international organisations, and I'm not familiar in those circles but Malcolm is so he will help me with producing some text and we are almost already have completed the new notes, and I'm very thankful to Malcolm for helping house constructively with this. So he will be my new co?author on this proposal.
And this is only changing the supporting notes, as the notes put on the web page of the proposal. It does not change the text of the proposed policy at all. But still, this means that we have to go through a new Impact Analysis, a new review phase, but since we are not changing the policy text, it will be a shorter one, both less Impact Analysis making so to speak.
So, that's my last slide. And questions or comments or...
GERT DOERING: One comment from the Chair on the process. What we had on the mailing list so far is very high number of people fully supporting this. So, this is why the chairs have asked for the policy text to be not changed because that text obviously has large support. There is a few persons than don't agree and that don't think there is any way we can keep the gist of this and get them to agree, so we apply the rough consensus rule and we have so much support that we will have to ignore those few voices that are unhappy with it, because there is no way to get unanimous support of that.
The external relations bit was actually something that made people unhappy so maybe, with the change supporting notes, we can actually make them, or alleviate their fears.
That's from my point of view. Process wise, now I welcome comments from the room. Wilfried.
WILIFRIED WOEBER: Could you please go back to the amendment number 2 slide. And it was the first time when I read this paragraph in bold that it occurred to me that there is a use of plural in only to end users, so if you stick to the letters here, then an entity creating an LIR to obtain an allocation would not be able to use that address space for their own network operations. I think I do know that this was not the intent of this paragraph, but if this is just a clerical or editorial change, then I would suggest to omit the S, or at least to put it into parenthesis.
TORE ANDERSON: So, this End Users on the slide there, that's not part of the second amendment. That comes from this text where it says "IPv4 address space must be fairly distributed to End Users operating networks." And that's in current policy. So this is not a new text. The specific text of the second amendment is something along the lines, I can't remember exactly, but something along the lines of: "The LIR must confirm that it will make assignment from the allocation."
WILIFRIED WOEBER: This precludes from the own infrastructure use that we had in the general policy.
TORE ANDERSON: Only to the extent current policy does, because this isn't current policy. So if it had been the way that the NCC had interpreted this to say cannot assign it to your own infrastructure, that would have been the case today. But I think the RIPE NCC Andrea correct me if I'm wrong, considers this to mean if you are assigning it to your own infrastructure you are basically your own end user, so it still matters.
AUDIENCE SPEAKER: Randy Bush, IIJ. This question is really to Raz and the people doing audio visual. Is this whole process being recorded? Because it's such a wonderful example of petty bureaucracy gone insane. How many times do we have to cycle through reviewing stupid, minute changes and discussing them endlessly? Get this Goddamn thing out the door.
GERT DOERING: Point taken. I think what we all learned in the process, that's the Chair, that's the proposer and the NCC, is that working more closely with the NCC earlier in the process helps avoid text that then causes the NCC to go panic on it in the Impact Analysis, which we did this time, so... I hear you. On the other side, I don't think we can just ship it right now, but we will try to ship it as quickly as possible. More verbal explanation will come on the mailing list.
AUDIENCE SPEAKER: Mike:
ALEXEY IVANOV: Come to the microphone to thank the proposers and the chairs for taking the time and trouble to correct elements of this proposal that in its original form would have cause the risk of causing problems. I fully appreciate that a substantial majority of this community wants this protocols to go through and feels that it is clearly and repeatedly expressed, yeah, we support this, we want it to happen. Nonetheless, I think we can all agree that this is a significant policy, and that outside eyes are on it. It is entirely appropriate, in my view, that we should act with care and caution, that we should ensure that we don't cause unforeseen reactions by a misunderstanding of what we're doing. Frankly, the very stewardship of IP space by the RIRs at all is under scrutiny from outside entities and they want to be sure that they can trust us with the management of such an important worldwide resource. If we were to give out a message that said we don't care about the outcomes any more, yeah you can go and speculate, we don't care whether people are actually using it. That's the interpretation that we are given and I must say that the nickname of "No need" certainly contributed to that, it would cause the risk that those parties would no longer have confidence in us in doing it at all. So it is very much in our interests to make sure that the external communication of this is as clear as it should be, and that we are explaining in language that could be understood by those parties what it is that we are actually doing so that this additional work that, these additional amendments that Tore has spoken to, and also the rewrite of the accompanying proposal text, would I say is worthwhile and I'm sorry if you are frustrated that it does cause a small delay, but I assure you that in my opinion, at least, it is absolutely worth it. I thank the chairs and the proposer.
TORE ANDERSON: I thank you too for not only pointing out the bug but also sending patches that fixed the bug, that is much appreciated, thank you.
GERT DOERING: Okay. Well, I already told you what the chairs plan to do: That is amend the supporting notes and go for another Impact Analysis and a short review phase then, and since the only objection I have heard is make it faster, we will go for a two week review phase, which is about the shortest we can usefully do without being accused of rushing things, which would then backfire in last call, I'm sure of that. So that would make it even longer. So, that's actually what I'm a bit afraid of, of having the proposal come back in last call with you should have fixed that before, because that would delay everything. Thanks, Tore, for taking up this work. Keeping on it. Working with Malcolm. Thanks for the Working Group for providing feedback and then we go to the next proposer right away. We are perfectly on time.
(Applause)
GERT DOERING: The next one is: Andrea brought up the point that transfers of allocations that have assignments in there are currently not permitted by policy because the transfer policy very clearly states it's not allowed. When the transfer policy was written, it was a compromise between we can't have that and we might want that. And I think at that time we focused on empty allocations to sort of like have middle ground. But it turned out that there is a couple of real world examples where this just doesn't fly and Sasha brought a couple of examples and a fix for it. So thank you.
SASHA POLLOK: This should be pretty short so this has come up several times regarding transfers.
The current IPv4 address allocation and assignment policy says these sentences. Especially ?? well it allows for a transfer but gives the restriction that these addresses must not contain any assignments to End Users, which leads to some problems. I want to give one example here which is a real world problem I tripped into. So, I was happy to volunteer to bring this forward.
You see there is an LIR A, which runs several businesses and one of the businesses is an ADSL business run on a /20 allocation. Now, let's say the business is not going well and they want to sell it to a different LIR which is happy to take offer the business and would like to transfer this allocation to its own LIR, which is currently not possible because it is of course in use and they cannot just free the blocks and transfer it because it is, as a matter of fact, used with users inside and this is a problem that I understood the RIPE NCC sees or has seen several times.
The solution to it should be quite easy, my suggestion is that we just remove this restriction from the current policy so that transfers can also be made when a block is currently ?? well if there is End Users users inside the allocation.
So this is currently open for discussion. The RIPE NCC has published the Impact Analysis which was quite positive I would say, the cushion phase is currently going on until the end of October. And I ask you to please support, contribute, or criticise. Feel free to step up and give a comment. That's it.
GERT DOERING: Well, first, thank you for taking this on. We asked for a volunteer, we got one. Thank you. And then feedback from the room please. Feedback on the mailing list so far on the revised version with more supporting notes was positive. I think I have seen five or six plus 1s and not a single opposing comment, so, that's good. We still have ten minutes, so make good use of the time. Elvis.
ELVIS DANIEL: I think it's a very good idea. Many businesses will just shift customers around and not being able to just move the IP addresses with the customer...
And actually, there is a work around for this. It means that you are just going to lie. So it means you have to delete the assignment, pretend it's not in use, then it is transferrable, and then register it back, which is not a fix. It's a bug.
SASHA POLLOK: But it also might require to remove route objects which could cause operational trouble.
GERT DOERING: And lying to the NCC is not encouraged in any way.
SASHA POLLOK: Networks we don't do that.
AUDIENCE SPEAKER: So my plus 1.
GERT DOERING: Okay. So I am clearly hearing the message that you want coffee now. We could move something from the second slot up here, but I think I will just grant you your coffee. So thanks for being here. I hope to see you back at 11:00 because then we will focus on the IPv6 policy changes.
Coffee break.
