These are unedited transcripts and may contain errors.
Address Policy Working Group ?? 27 September 2012 ?? 9 a.m..
CHAIR: Good morning everybody. We are not going to schedule Address Policy against IPv6 again, because it's nine o'clock in the morning, we have a conflict with IPv6 and the room is pretty empty, but I'm still happy that actually somebody showed up, so, thanks for being here.
This is the no more Address Policy Working Group, as you can see on the slide, because we have no more addresses. On the other hand, there still seems to be interest in doing policy work so maybe that's the wrong term and we should rename it to the Deck Chair rearrangement Working Group instead, because that's what we are going to spend our time today with it.
Anyway... back to serious welcoming.
No, we are not voting on the name of the Working Group today. We actually have IPv6 addresses so we do have addresses and we do have reasonable policies to make. It's not just about deck chairs.
They only have implementation plans and time lines. The addresses are coming from here.
Anyway, good morning again, I think everybody who is going to show up is here now.
That's our agenda for today for the first slot. It's pretty much the usual stuff, Emelio is giving us an overview of what's going on in policy land here and in the other regions. Alex reporting from NCC registration services, what happened, what issues we have seen, what fun they had with the last /8. And then we enter discussion of these policy proposals, 2012?02, 3 and 4. And I think that will pretty much carry us to the coffee break, because the PI stuff seems to be a bit controversial.
After the coffee break this is what's on our agenda. Policy proposal from Tore. Some updates from me on ongoing stuff that has been up here on the previous meetings, but sort of didn't progress as we imagined, the maintenance policy and the IPv6 PA /PI stuff. Then we have the open policy hour with two things that are not yet formal policy proposals but might want our attention. And then yet another open policy proposal which is right at the very end because the proposer is sitting on the west coast of the US Skyping in and it's at that point in time well be six o'clock in the morning over there, so we try to be considerate. Not calling him at three o'clock in the morning.
Anyway, is there anything you want to see on the agenda that's missing? Is there anything you want to see changed?
JAN ZORZ: Can we discuss the PI last /8 on the next session please?
CHAIR: The request for the sake of those listening to the microphone is can we discuss 2012?04 in the next session to avoid the conflict with IPv6? It will mess up the schedule for that slot, so it would ?? we could do that, we could move the open policy hour ?? we could move H and Y to here and ?? if Nick is fine with that? I will try to get the timing sorted out. Thanks.
I think that's the first time ever that agenda bashing was used. Thank you.
So, minutes: The minutes from RIPE 64 have been sent to the list. Thanks to the RIPE NCC for actually doing a great job with very detailed minutes and, no comments on the list so far regarding the minutes? Anything anyone of you might want to add to that? No. So, the minutes are declared final. Formality stuff.
And then off to Emelio. And he asked me not to introduce him so I am curious what this is all about.
EMILIO MADAIO: Good morning. I am Emelio from Rome Italy and I am the policy development officer at the RIPE NCC. I will try to be short, to talk slowly and to go through this easy.
I give the usual overview on policy related topic. News from policy land as Gert says, in the other regions, in the other RIR communities, in our NCC service region and some of the activity that the NCC is busy with policywise.
Starting with the common policy topics in the other RIRs. Organising this areas of interest, v4 depletion, v6 deployment and IPv4 transfer. I start with this ARIN draft policy proposal that will be discussed at the coming ARIN meeting. It's the only one actually related to the last ?? what we will call the last /8 policy, the v4 depletion. Basically they want to change the are reserve IPv4 space for critical infrastructure from a /16 to a /15.
In the LACNIC region this, community is discussing this other policy proposal that would allow all the IPv4 space received by IANA in the future to be used only under the new members section of the LACNIC policy manual. Maybe this one needs some description. There is a global policy that was ratified in May this year. The global policy for the IPv4 mechanism of ?? for the IANA mechanism for distribution of IPv4 space post exhaustion, and that will be triggered when one of the RIRs will declare to have not more than at that /9. At that point IANA will redistribute according to that policy, IPv4 space. In the LACNIC community, they are discussing to have that space that we will receive in the future to be ruled /AOULD only under the section 11.2 of the LACNIC policy manual, that means only for new entrants, only for new members. And it will be discussed at the coming LACNIC meeting.
In terms of v6 deployment, I have to mention this to APNIC policy proposal. The first one is self explanatory, and should remind you of something that we have already done. It reached consensus at the last APNIC meeting. It is in what we would call a last call, it's in the final comment phase in the APNIC mailing list. The second one is also approved in the APNIC community, but it's also already implemented, it was approved at the previous APNIC meeting. Self?explanatory, this one too, they practice postalcation for v6 allocation.
As pair the ARIN interest draft policy, I'm not sure this is the original text. It's very likely that the text will be updated. This draft policy intends to simplify the criteria to request and receive subsequent IPv6 allocation. So changing the way the usage of the, the current usage v6 allocation is calculated.
As per LACNIC there is two policy proposal active now not LACNIC PDP. The first one tries to set up new criteria in order to allow an initial v6 allocation larger than a /32. The second one is just an textual update, not so an improvement. There is a reference in the LACNIC policy manual to RFC that just recently became obsolete, so they want up to date that reference to the new RFC, for your information it's the 6177 and they also want to add something about the RFC that, describes the principle of v6 distribution.
As per v4 transfer, this is the news I want you to be aware of that. LACNIC also started discussing inter RIR transfers. This policy proposal has been published as a Version 2, has already been updated. Tried to set the criteria for inter RIR transfer. And for example, distinguish the inbound and out bound transfer from and to the LACNIC service region. The other two LACNIC proposals have to do with transferring in another way. The proposal 2012?06 basically wants to allow transfer also during what we would call the last /8 phase. At the moment, during the, what they call the gradual IPv4 exhaustion, an LIR can receive IPv4 and then for six months cannot receive any other IPv4 resources. With this proposal, they would be allowed to receive v4 via transfers intraRIR transfers, so the local one. The other proposal instead wants to remove a restriction in one of the LACNIC policy section. The one that describes the transfer. Basically that section will be activated once an LIR or LACNIC itself is not able to fulfil a request. Soon this will happen, the section, I think it's 2.3 in the LACNIC manual, will become active and it will be possible according to the rule of that section to perform transfer. This proposal wants to remove this restriction. It would like to allow transfer already at the moment.
All this LACNIC proposal will be discussed in the LACNIC coming meeting.
And as per ARIN, the only one worth mentions at the time relating to transfer is this one, they want to change the wording of this section, 8.2 covers measure and acquisition in the ARIN policy manual. 8.3 covers transfer. If I recall correctly, all types of transfer, intra, inter RIR, and basically they want to change the wording so that the process ARIN stuff Luisa Villa to follow will be more consistent.
As per APNIC, this policy propose reached consensus at the last APNIC meeting. It is in the last call phase in the mailing list for four weeks, I guess roughly at the end of the month it will be moved words to, if there are no more feedback. It's self explanatory. They will keep the need basis principle, even for transfer, for all types of transfers.
Now moving on to our region. Let's start with some proposal who reached consensus and when implemented. 2011?04 is the extension up to a /29 for the initial v6 allocation was approved and implemented during the summer. Now, it's possible to request as an initial IPv6 allocation, a minimum /32 and with the same documentation, up to a /29. For the documentation if you want more of a /29. 2011?05 was approved and activated during the summer. Now it's possible to implement it simply because it was a change at the final /8 policy, it's possible from the last /8 now to assignment to IXPs only and to reserve address block of a /16.
Moving on, this policy proposal was discussed in the Anti?Abuse. I can say that in the afternoon it will reach consensus in the afternoon very likely, I will be able to publish the new policy document. 2012?01 is the first inter RIR policy proposal we ever discussed. If you recall correctly it was withdrawn at RIPE 64, because the proposal wanted to submit these two other proposals, that covers both inter and intraRIR transfer. The first one will be presented by the author today. The second one is an update of our current transfer policy that I would like to remind you is section 5.5 of our v4 allocation assignment policy. And you will hear more about them. They are both in discussion phase active in the PDP, so any input is more than welcome.
2012?04 is the PI assignment from the last /8. I will say something more about this later and you have the author here that will present. It is in review phase. So, again, active in the PDP and all of your comments and feedback will be valued.
2012?05 is another proposal related to the way policy describe intratransfer, intraRIR transfer. And you will have a presentation from the author that will participate remotely.
This is also from 2012?06. I won't comment much on that. The author in the second session will describe the rationale. It is in the discussion ?? it is in initial discussion phase. Some feedback already arrived and was posted in the mailing list. More is welcome.
And the last one is 2012?07, is the legacy resource holders policy proposal. It's discussed in the NCC service Working Group, it is at the moment active in the PDP. Feedback is welcome. The author has already explained that they are draft ago new version, considering whatever ?? whatever they will collect during the discussion phase.
Now, in terms of how the PDO is busy these days. I have to give you an update of the cosmetic surgery project. It is the project that allows me to change the RIPE policy documents, only at a level, you are not changing the policy itself, we just try to make it more readable, easier to read and try to improve a bit the consistency all over the policy document system. At the moment it is in review phase, and the second review phase, this draft policy of our policy document for reverse address delegation. We received positive input in the second phase. We published the second version after some input in the first review phase. This review phase will end on October 3rd, and if things remain as they are, very likely Gert and Sander will agree with me in moving to last call and very likely update this RIPE ?? 302 document.
And as I am reaching the conclusion, I would like to highlight something that most of the time gets overlooked. The Impact Analysis and the outreach and the extended coordination that as a Policy Development Officer that I have to perform. I list here some policy proposals that represented the living proof of improved communication between community and RIPE NCC when it comes down to policy making. 2011?06 is an example of a PDP performed with a good cooperation, the community itself, during the discussion phase, addressed what were the concerns and what were the input they wanted to read in the Impact Analysis, especially in terms of what kind of implementation consequences that proposal was meant to introduce. 2012?04 is another great example of the community clearly asking what kind of forecasts, what kind of number they wanted to read in the Impact Analysis, and we were happy to comply.
2012?05, on the other hand, is another example of the community reading and understanding the policy proposal because we had a chance to clarify what were the technical side, technical aspect of what was requested and how it was possible to perform the, what requested we dealt actually a real policy framework, so it was clear to the community that what was asked to do was possible to be performed by the NCC directly asking or with a clear request, or could I have, reach also a sense and a value in a policy framework, it could have been a more authoritative community request in our policy documentation.
So, it's something that is improving and I am happy to mention it in here.
As per the outreach, I usually take the opportunity when I'm on stage to thank all the other RIR staff, especially the Policy Development Officer in the other region. We try to ?? we work together on the policy comparative matrix that is available to you online, also on the RIPE website. And the second bullet point you see the current policy proposal, where you can read about the text and the PDP status and our Impact Analysis if they are in review phase of all the policies I mentioned. You also have on the right?hand side the policy comparative may things that I mentioned before. The first bullet point is just something I put for the fun because it's the PDP and I know that he ever one of you knows it by heart. And I conclude with a contact. This is the e?mail address that I read for your official requests, comments, input, or when you want to submit a proposal and you don't know how to start or you want to start, you e?mail me there. The other one is the Twitter account that I use for update and the Twitter sphere on policy related issue.
As I conclude, if you have questions, otherwise up to my colleague Alex.
CHAIR: I don't see anybody lining up on the microphone, so thank you for bringing us all up to speed. And now we give ??
(Applause)
CHAIR: Now the microphone goes to Alex, who will bring interesting news I think.
ALEX LE HEUX: Hi. My name is Alex Le Heux. I am the RIPE NCC's Policy Implementation Coordinator. First, I'll report on the implementation of 2007?01 which has now been ongoing for about three and a half years. And we have covered under that policy now a total of 51,000 direct assignments, both v4, v6 and AS numbers and at the moment we have about 70% of them covered under an end user contract. When we started this three and a half years ago, we had, of course, a huge number of assignments that we had to get under contract. Of those, we have a little bit over half of them are covered. Everything since then has of course been covered under a contract from the beginning. And we still have an about 15,000 to do.
We are making steady progress. We have got about two FTEs working on this. It's usually not the host masters or that work on this, but administrative assistants, and it is starting to get a little hard to get into contact with the end users, where we are slowly ending up in the tail end of the distribution.
It's a lot of work. The resources are often clearly end used, they are routed on the Internet but we have to make a lot of effort to get in contact with the end user because either e?mail addresses don't work or they are not responded to, etc.
And even when we get into contact with the end users and they find themselves sponsoring LIR, there is often still a lot of e?mailing back and forth because many times we receive the contract but then it's not signed, or only signed by one of the parties or it turns out that the name on the contract doesn't match the company registration papers. So, it's steady progress, but it's getting a little bit harder.
We are making allocations from the last /8s. It's a little bit early to say how quickly it's going because we have not been doing it for very long yet. There were quite a few allocations we had to do in the first days of reaching the last /8 because of the backlog of requests. It's settling down a little bit. Somewhere in the name neighbourhood of the number of allocations that we used to do before reaching the last /8. But it's a little bit early still to say how quickly it's all going.
The policy about this is not a complicated policy, this is the main thing, the main line from that policy. An LIR may receive one allocation from the last /8 and this allocation is a /22. That means an LIR gets only one allocation. If they would transfer this allocation away to another LIR, we are not going to give them another one.
One member, though, could have multiple LIRs. The policy is ?? the policy text is clear, it talks about LIRs, not members. So, a member with multiple LIRs can have one /22 for each of these LIRs. LIRs may merge. This has always happened and will probably always still happen in the future. And these LIRs ?? if LIRs merge, they will end up with multiple /22s. We do intend to ask if any of them are unused and can be returned, but they may end up with multiple /22s.
Now, if you think that now we have reached the last /8. That was the last time you see graphs like this. You'd be wrong. In RIPE NCC service region, the ASN 32 takeup has been quite good. A lot of AS numbers we assigned, over one third, are 32?bit and growing up quite rapidly. However, if you look ASN pool and you flit it up by 16 and 32?bit ASs, it looks a little bit like this, the red line is our pool of 16 bit AS numbers, the two blue are 32 bit ASs. The spikes going up are the moments received new blocks from the IANA. And it's of course clear that the rate by which we assign these is not the same for both. That means that at some point, one of them will be, Luisa Villa ?? there will be less AS numbers in one pool than in the other pool. And if you would extend this a few months into the future, it would look like this, and somewhere early next year, the ?? our pool of 32?bit AS numbers will be exhausted. The global policy for AS numbers does not differentiate between 16 bit and 32?bit AS numbers and it has some very clear guidelines about when we can request new AS numbers. At this moment in early next year, we will not qualify yet for additional AS numbers from the IANA. This means that there will be a short period of about two months in which we will only be assigning 16 bit AS numbers. After that, we will qualify, we can request new, block new AS number blocks from the IANA and we then have a choice. If we get more 16 bit, or ask for more 16 bit AS numbers or more 32?bit AS numbers and depending on what we do, at some point in the future after that, one of these will run out again for a short while. We propose, to as long as it's possible, try to set things up so that we will run out of 32?bit AS numbers so that we are always able to assign 16 bit AS numbers, because for some operators, this is still a big issue. But, perhaps the room has a different opinion?
Okay.
So, it's another runout, but one that's probably going to be a bit stressful than the previous one ?? a bit less stressful than the previous one, so...
All right. We are now operating under the last /8 policy, and a lot of people expected everything to be ??
GERT DOERING: If I may inject a question to the AS numbers. Gert Döring, Address Policy Working Group Chair. Sander just reminded me that when you come up to the microphone, please speak your name and affiliation. Anyway, what's the current estimate when the 16 bit AS number pool will run out completely?
ALEX LE HEUX: The IANA pool? I don't have that number off the top of my head at the moment, but you can mail it to the mailing list later
GERT DÖRING: That would be interesting to know, to see whether this is sort of like will go on forth next 25 years or next year it will be over anyway.
ALEX LE HEUX: I see Leo Vegoda approach the microphone.
LEO VEGODA: Hello, Leo Vegoda from ICANN. I can tell you that we have, in the small 32?bit AS number pool, we have available for allocation to RIRs from 61,000440, to 64,495 so that's how many is left, it's sort of about 4 blocks
GERT DÖRING: So that might actually be gone next year?
LEO VEGODA: Yeah. I mean ?? maybe each of the RIRs gets one more of the small 32?bit blocks, but ?? yeah, something like that. But year, 18 months, something along those lines
GERT DÖRING: Okay. Thank you.
ALEX LE HEUX: So, last /8 policy, and everything is going to be different. Perhaps not. If you look at what the policy actually says, it's a large document, it has many things in it, only a small section deals with the last /8, and in summary, we are not going to be doing IPv4 PI space, we are not going to be doing Anycast assignments, and all allocations are a /22. Everything else, however, is still there. New LIRs still have an assignment window that's 0. The assignment window is still raiseed to a /21 after six months, even though they may only have a /22 allocation. The 80% rule for existing LIRs who want to receive an additional allocation, a /22, is also still in effect. If policy still requires PA assignment requests to be sent if the LIR has no assignment window or the assignment is larger than the assignment window. Verification for always on broadband type services is still required. The BHP pools, statistics, that kind of thing. 50% of the assignment must be used half?way through the period and that period is still three months, even though there is a proposal to change this. So in the end, not so much has what I thinked. No more direct assignments and part of the discussion, when make ?? when evaluating the allocation, the last part about how large is the allocation going to be, we can skip that part. Everything else is still there and everything else we are still doing and I have seen some people be very surprised about this, both in requests and here at the meeting and even on Twitter I think, so, that's why I'm talking about this here. This is something that might be desirable. It's something that might not be desirable. I have thought about this. I think what to do with the v4 policy has been discussed a few times. There was Randy Bush's proposal 103 in the APNIC region, which if I understand it correctly said let's stop fiddling with these policies and just leave them be. That would of course be a policy that would be fairly easy to implement for the RIPE NCC. Another thing that was discussed a while ago was Rob blocks all's IPv4 maintenance policy which recognised that there was a major discontinuity any time in the development of the IPv4 Internet, and then tried to almost start with a clean slate and keep the bits of the policy that should be there and make a few changes that are relevant for future registration of the addresses is actually much more important than things like conservation. So, is there an opinion from the Working Group about what this should look like? Should we continue the way we have been doing the last 15 years?
AUDIENCE SPEAKER: Wilifred Woeber from Vienna university. Answer to the question is there a need to step back and try to clean up the mess? My answer would be a very loud and very shouted yes. We have put the cart pretty deep into the mud over the last couple of years with the large number of special policies for the special IXP here, the special PI there, the special reservation for A, the special reservation for B. My feeling is and unfortunately I didn't have the free cycles to prepare a presentation about that one, we are, at the moment, already in a situation where you can read the various policies to contradict each other. We have, at the same time, pretty gaping holes in what we wanteded to achieve during a discussion and what ended up in the text of the policy. This applies to address transfer stuff, for example, like there is the whole time of 24 months for address space received, but if the same entity holds other parts of addresses they can take other parts of addresses two days after and transfer them on. So there is a lot of these inconsistencies as I perceive, it and I think the community here should really sort of step back a couple of paces and try to clean up. And in particular, that's sort of going back to the previous slide, I don't see any good reason why the community would want the NCC to continue with broadband verification stuff. And you know, there is ?? I think everyone in the community should really have a look at some parts of those documents and whatever pops up as inconsistent or given an opportunity to misinterpreted which people either by chance or on purpose, sort of to bring that up, because we have a huge load of text which is extremely difficult to understand for anyone who hasn't been here for 15 years, and who hasn't participated in the background discussions for the policies and I think it's going to give pretty bad grief to the RIPE NCC and as we discussed on the Monday in the arbiters meeting we expect those to give us grief in the arbiters environment. Thank you.
CHAIR: Thank you, Wilifred, that was a very clear message and we hear you. Rob, what do you want to directly answer? Otherwise Nina was first.
ROB BLOKZIJL: I can be very short. Most of the things I wanted to say have just been said very well by Wilifred. About a year ago I started looking at the existing IPv4 policies and saw the same need for a cleanup, getting rid of dead wood, whatever. The work has been interrupted a little bit by the fact that we ran out of IPv4, which put a lot of workload on the registration services people of the NCC, but I think now is the right time to restart this work. And what we are basically trying to do is go through the policies along the lines Wilifred just explained, keeping in mind what is still relevant and important in 1, 2, 3, 4, 10 years from now, and that is mainly registration, and all the rest of the policies are mainly derived from allocation policies where the allocation game is over, so we don't need that any more and let's see what is left. The bare minimum needed which can be explained in a few words in five years' time to people who are then building networks and have not the burden of all this history. I think this community should realise, as I do, that IPv4 is over, and we should not waste too much time in leftovers of policies which might result in you getting an unexpected /24 or 23 if you interpret the spaghetti heap of policies in a particular way. I think that is a waste of everybody's time. So if you could clean this up and end up with one clear document saying that the history was IPv4 and this is left of that history which is still relevant today and today and in the coming here is, then we have done a good job. Thank you. So I support Wilifred.
CHAIR: That was wasn't a particularly short remark, but it was an important one to make. So thanks for that. Nina please.
AUDIENCE SPEAKER: Nina, TDC, I am not sure I can add much except that I actually think it's a little bit urgent that we clean up the assignment policy, because we are some people like to do things within the rules and the current policy is now very little operational and very tight, because that is what we wanted it it to do because it was so tightly connected to the allocation policy and we were all running out, but now we have to have our operation back in a sensible state, and assigning customers and assigning addresses to our products with a three month time range is not a sensible way to run your network. So, I really think that we should put some effort into cleanup and simplify the assignment policy as one of the urgent and prioritised actions in this group. Thank you.
CHAIR: Just as an added remark on that. This has been noticed by other folks as well, so this is why Tore Anderson actually put in the 2012?06 policy which reverse runout fairly for the assignments effectively. So, he also noticed that being tight there has no useful purpose any more except general paperwork. So, we can get there pretty quickly by just agreeing on the policy proposal. We could try a Fastrack this time with no extra rounds, no extensions of discussion periods and so on, just voice your opinion on that.
Thanks for actually making clear that there is an itch that needs to be urgently scratched.
AUDIENCE SPEAKER: Hans Peter. I was just going to add to what you said there Gert. Since everybody seems to agree that something needs to be done, we need a proposal on the table and a quick decision.
CHAIR: We have a proposal. So, we actually ?? somebody actually did their homework before the meeting. Okay.
ALEX LE HEUX: Well, that's the end of my presentation. Are there any other questions or remarks or things I missed?
CHAIR: Thanks Alex for bringing these up. Thanks for the AS number thing.
(Applause)
CHAIR: And, back to me up there.
GERT DÖRING: So I'm actually going to jump back and forth a bit and mess up the agenda completely. This is what I had for the second time slot, the updates from the Chair. Which is exactly this. We had the IPv4 maintenance policy on stage two meetings ago. Since then, not much has happened, because everybody else was ?? everybody was too busy with the IPv4 runout and actually we have a number of IPv4 related policy proposals on the table so, from a purely process perspective, it's sort of hard to in the middle of the process rip out all the bases and introduce completely new text, so the idea was to wait for the dust to settle somewhat and then do the complete overhaul of the document so. The urgent things gets fixed quickly with urgent policy proposals, so to speak, and the complete overhaul is not forgotten, just postponed a bit.
That's for that.
And then back here. So now we are actually going to enter discussion of specific policy proposals and that's a reminder slide sort of what's there to be remembered. No decisions are made here. So, we hear you, we listen to you and it helps deciding which way to go with a policy proposal, but everything needs to be on the mailing list and the mailing list is open and so on, and consensus is based on what happens on the list.
If you speak up, please speak to the microphone, state your name and, if it's relevant, your affiliation, or if you want to, whatever. So that people listening to the webcast can know who is speaking. And we also have an RFC channel to provide feedback, but you all know that.
So, 2012?02, 2012?03. Two policy proposals centering around transfers and fixing bits in the transfer policies. Sandra Brown is working on these and she has a presentation and will then lead the discussion. Thank you Sandra.
SANDRA BROWN: Good morning. Sandra brown from IPv4 market group. A little IPv4 humour before we go into the proposals, anybody God a good answer for this one. What did the IPv4 address say when it walked into the bar? Quick, give me a drink mime I'm exhausted.
Okay, so the purpose of 2012?02, first of all, two of the other RIRs have, as Emelio said earlier, have existing inter RIR transfer proposals between the regions, so, APNIC and ARIN and so what this will do is bring RIPE into that group of RIRs. So it will allow transfer of IPv4 addresses to and from the other RIRs, supplement the pool of IPv4 addresses available to the RIPE region, provide access to addresses, should companies or entities in the RIPE region need them and ensure the database, the registration database accurately reflects transfers. We don't want transfers happening outside of the database.
The second proposal, 2012?03, the purpose of this proposal is to extend the period not only for interRIR transfers, but also for internal RIPE transfers from three months to 24 months, and this will bring RIPE transfers in line with what is happening in ARIN today, so bring some commonality across regions and there is a proposal on the table in the APNIC region to extend the time for transfers in APNIC from 12 months to 24 months so we are starting to see some commonality across regions there as well. And I'm not talking about the other two regions, Africa and South America. Just because they still have a supply of IPv4 addresses still in the registries and they really won't be a source of IPv4 for RIPE or a destination for RIPE in the short term.
So, the body of the proposals. Basically, just really over simplifying for discussion here today, but transferring to RIPE. So, I believe most of the IPs will come from the ARIN region, because that is where most of the supply exists today as opposed to APNIC where there is also a shortage. So the originating organisation would be in compliance with the originating policy meaning that the ARIN organisation would be in compliance with ARIN policy F you read between the lines. And in ARIN would have an inter RIR policy, meaning that today, we don't have a policy in the regions supporting Africa and South America.
Second bullet is that the destination organisation, the RIPE organisation, would be in compliance with RIPE policy and qualified to receive the addresses, meaning it follows or meets all RIPE policies.
If transferring from the RIPE region, which is quite possible, the originating organisation in the RIPE region would be in compliance with RIPE policy and the originating organisation would be in compliance with destination policy ?? sorry, the destination organisation would be in compliance with destination policy and with the destination RIR. So, there could be a transfer, for example, from RIPE to APNIC, for example, where there is quite a shortage, and that situation would cover that everybody is in compliance with policy there.
Feedback received so far in the discussion group, should it apply to just LIRs or to all organisations? And there were some questions about alignment of time periods and as I mentioned APNIC has a policy under do. To move from 12 to 24 months, so that will help to align the time periods that are applicable.
And just to conclude, the path forward for this is there will be a four week discussion period and then approximately three months to implementation if all goes smoothly. So we're looking at getting this in place roughly January 1. So that is it and any questions?
CHAIR: So, now we need feedback from the Working Group, because if we want this to move quickly, we need actually some support from the Working Group, because if nobody speaks up, then it's not moving anywhere. Silence is not fully consent. There has been some positive voices on the mailing list, but I could use some more feedback. Remco.
AUDIENCE SPEAKER: Remco. Just to start the comments off, as a former co?author of these proposals, would I strongly encourage everyone to be in favour of these, and have this moved forward. Thank you.
CHAIR: That was clear. Thank you. Anything else? Improvements?
AUDIENCE SPEAKER: Ingrid from RIPE NCC. I have a question. I noticed in your slides that you were talking about implementation time of three months. Because, we normally have the Impact Analysis done estimating how big the proposal would be, how difficult it would be to implement, and depending on what is possible we would implement it as soon as possible. So, I am wondering where the time frame comes from?
CHAIR: I also think that three months might be a bit optimistic. But we could do that, if we really Fastracked it, if we get enough support at every stage and everybody does his homework right on the next day and so on, but it's ?? it will be tight.
AUDIENCE SPEAKER: We always try to do it as soon as possible, but it depends on different factors and other things.
CHAIR: Like an IPv4 runout getting in the way. But, I don't think that's going to happen in the next three months again. But, thanks for reminding us that it's ?? there is lots of work to do behind the scenes and that takes time of course.
On the topic, any other comments? Nina, thank you.
AUDIENCE SPEAKER: Nina, TDC, I was just, in my head, linking this back to the assignment policy that we just discussing a few moments ago, or not discussing, but talking about we should get that back into an operational stage as soon as possible, and I see a new link forming here, but this isn't a new way that people can get new space, so this is actually our new allocation policy. So maybe we should consider if these two things should also be aligned, it's just a comment. And by all means let's get something operational and some operational time frames into place so that we can plan more than three months ahead, all of us.
CHAIR: So, I take that as a support and please make sure it doesn't conflict with anything.
AUDIENCE SPEAKER: Nina: Yes, it's a support for getting it going and then let's move on with our lives.
CHAIR: Okay, thank you.
So, while there wasn't that much feedback, what I heard was support and nobody violently objecting, which usually means it's not that bad a policy. Then, we just take it to the list and see what else comes from it. There have been editorial comments on the list so the next version of the proposal will incorporate these, but they have been well taken so far, so everything that has been proposed didn't raise violent opposition either, so, I think we are going smoothly here. Thanks for bringing this up. Thanks for volunteering to actually defend it here. There was a comment from Jabber I think.
AUDIENCE SPEAKER: I have a comment from Tore on Jabber. As a follow?up to Nina, there is no policy covering transfers of assignments. This policy would therefore only cover transfers of allocations, at least for now. That's a comment from Tore Anderson.
CHAIR: Tore brought that up on the list already, so, it's there, yeah, thank you.
Okay, I think we're done with that one so far. Thank you.
And now I will have to juggle a bit with the agenda items, because the next one would have been the PI discussion that we have been asked to not have in this time slot.
Jumping to H again. Besides the IPv4 maintenance policy, there is another long running item here, which is the IPv6 parks PA/PI unification policy, it's not a proposal yet, but a policy idea, which basically is all about removing the distinction from PA space and PI space and depending on the colour of your addresses, you could do something and not something else and the price tag would be significantly different and cheap addresses don't allow to you do A and more expensive addresses don't allow you to do B, so the idea was to sort like streamline all this to just addresses with the same rules applying to everything.
It turned out to be not exactly trivial, because if you simplify it all down, then you end up finding interesting side effects in other bits like the charging scheme and so on. So, this is currently not in a state where anything can be presented. I have been asking the RIPE NCC for help in drafting something that's implementable, and everybody there has also been very busy with this IPv4 runout thing, so, we don't have anything to show right now. But, I'm definitely intending to bring up something in the next few weeks or months, so, you will hear from me.
That's that.
Then we have 2011?02. That is the policy proposal that removed the multihoming requirements from the IPv6 PI assignment policy. And at that time, there was ?? there were worries that this would make the routing table explode, this would make everybody come running for IPv6 PI assignments. Open the flood gates, so to speak, and we promised that we would monitor this and, well bring back the results to the Working Group, and this is what I'm doing.
This is the line with the IPv6 PI assignments in the RIPE region, and here is where the policy came into effect, and as you can see, cannot see anything. So, the line didn't change to exponential growth or anything, but it's going steady. So we fixed somebody ?? well, some people had problems with the policy, and we made them happy. And it's not like there have been 10 million people just waiting for this to run for it. So, I think we haven't done harm. Which is always something to keep an eye on.
So any questions on that? Eric.
AUDIENCE SPEAKER: As the author of this policy, I want to thank you for the update and it came nicely in line with what I was expecting. So thanks.
CHAIR: So, that's for the updates. Then we go to the open policy hour, which ?? okay, another comment.
AUDIENCE SPEAKER: Can you go back to the ?? are there any sort of specifications what goals you have for this project or author's proposal?
CHAIR: There was actually a sort of a concept paper on the mailing list about a year ago, which didn't have the formal policy proposal format. It just wrote down the ideas and what sort of side effects to be expected, and you can find it on the list. I think the subject was concept paper on PA/PI unification or something. Basically the idea is really there is just address blocks and depending on what you needed for, you get a small block or a big block but the rules are the same so you can do with it whatever you like. If you have a 48 and you want to assign something to a friend from that, you can.
AUDIENCE SPEAKER: I completely agree, because my question is: I mean, do we really want people to use IPv6? Because the rules are so strange today and they sort of don't really match and when people apply they get to know and they get lots of strange questions and it's not the Hostmaster's fault because they only do what they are supposed to do.
CHAIR: The policy is full of interesting bits and pieces.
AUDIENCE SPEAKER: Okay.
CHAIR: I want to make the IPv6 policy as simple as possible. While taking care of all the interesting side effects and the side effects is what's slowing this down a bit. Like, if you have an LIR and, everybody else in your neighbour decides to just close down their LIR and move their address space to your LIR because it's cheaper that way, will it do harm to the NCC funding and such consequences, it's not fully trivial, but I expect ?? I want to have a very simple, very straightforward IPv6 policy in the end.
AUDIENCE SPEAKER: Please tell if you want any help with work, because I think it's very important.
CHAIR: There will be something on the list and I will need feedback, so thank you for that. Okay, anything else on these?
If no, we jump to Y.
This is actually why I don't even bother with having the letters of the alphabet in the right sequence because they end up in a different sequence anyway. So in case you have wondered why certain letters are in my agenda, this is why. It doesn't make sense to try to keep them in any sequence. Just recognisable. Y. Nick, do you have something for Y.1 for us?
NICK HILLIARD: Hello everybody. My name is Nick Hilliard and I am CTO at INEX. A couple of years ago I proposed a policy to introduce the concept of a temporary Internet assignment. And the idea is that if you have a conference or a meeting or an experiment or a project or, you know, even some sort of commercial thing that you need to have IP addresses for on a strictly time limited basis that, there would be a small pool of addresses maintained by the RIPE NCC which you could pull on. And I believe the current pool is a /13, there is lots of address space there, so, it's ?? and this is kind of a long term pool that's going to be there as long as the RIPE NCC is around.
So, unfortunately, it turned out that the time scales listed in this policy were wrong. And I have been getting a lot of feedback from, specifically from people who run conferences that when they try to build their conference infrastructure beforehand, that the timescale of a week in advance, so getting the addresses a week in advance isn't actually going to work for them. Typically, they need several weeks. The RIPE NCC, for example, requests that all its infrastructure is in place, or at least that the IP connectivity is in place and running up to three weeks beforehand, there are many other conferences, there is the CCC, there is hacking at random, there is ?? there are quite a lot of confrences which use this IP address pool at this stage, and it turns out that one week simply doesn't work.
And there are a lot of reasons for this. There is the getting the infrastructure built in advance. Some people pre?ship, or at least ship pre?built equipment with full configurations and they need to know the IP addresses in advance. Other organisers like to deboganize the address space just to make sure that they don't have problems with reachability to the rest of the Internet, and it just can't be done in one week.
So, there are three possibilities for dealing with this situation.
The first option is to change the time scales, to change them from, say, you can get your address space one week in advance to say four weeks in advance.
The second option is to remove the time scales and to hand over the responsibility to the host masters, the IPRAs and to give them a mandate to say well look, you know, you talk to the assignees and see what looks reasonable to them.
And the third option is to implement some form of booking system so you can go a will think to the RIPE NCC and say look, we have a conference that's going to be six months in advance, could we kind of book this address space and maybe you could tell us in advance what the address space is going to be, but it's actually only going to be assigned a week in advance so. That means that people can still do their, can still pre?build their equipment, maybe they can do a bit of deboganization, you know, a week in advance as well but maybe it's not going to work.
I have solicited some feedback on the mailing list for this. A lot of people are very keen on the idea of just completely removing the time scales. In one sense, this is probably my least favourite option, because it creates the possibility for potential assignees to get into fights with the RIPE NCC about what institutes reasonable, because a reasonable timescale in advance for one organisation is not going to be the same as a reasonable timescale for another organisation, and whenever you have flexibility like this, it creates the potential for arguments.
Changing the time scales, it's also a little bit difficult because you are always going to run into the problem of well, what actually institutes a reasonable timescale? And if you have a timescale in there, well what's the purpose of it? The purpose of it is to stop a sort of a level of abuse, because these are temporary assignments, they are given to you on a time limited basis, and if it's given to you a month in advance of your stated requirement, well that's giving you a month extra and maybe that's taking a month away from somebody else who might need those IP addresses.
And the booking system, that's also kind of difficult, because there is no facility in the RIPE NCC at the moment to do this. In a sense, it's quite a radical departure in terms of general policy. But, you know, maybe it could get to work.
So, I think we need to get a little bit more feedback on the mailing list about what's going to work for people. And in particular, if anybody from the RIPE NCC would care to issue, you know, maybe, a little bit of feedback about the feasibility of a booking system, that would be very welcome. Otherwise, from the community, if people have strong preferences, one way or the other, for changing the time scales, or removing the time scales, I think that would be very useful.
So, any questions or comments? Remco.
AUDIENCE SPEAKER: Remco, private Internet citizen. This is quite a niche case, if you allow me, and I would really not like ?? so, what we shouldn't be doing, if we are going to fiddle with this, we shouldn't aim for perfect. We should aim for good enough. And booking systems sounds lovely, sounds perfect, but that's like aiming for perfect and I'm probably not going to like what it's going to look like on the implementation side and how much time and effort we are going to put into that. Removing the time scales, as you indicate is probably not the best option because there is also discretion and discussion going on after that, so I would simply say, change the time scales to something sensible, i.e. four weeks and have it over with.
NICK HILLIARD: Okay. Thank you very much.
AUDIENCE SPEAKER: A comment from Tore on Jabber. I really don't like the booking system. It's overengineering. The NCC's developers have more useful things to work on. Besides, if you can't actually announce or use this space, you can't really deboganize, it can you?
NICK HILLIARD: That's absolutely correct and I think possibly that as Remco said, overengineering the problem is probably not a very good idea. Just because we can do something, that doesn't mean we ought to do it.
AUDIENCE SPEAKER: Wilifred Woeber without any hat on. I'd like to see the most simple and the most consistent framework here with the least risk of routing operation accident on the network. With that background would I propose to align the time scales for the IP address assignment and the availability of the autonomous system to go with it potentially to be exactly the same time frame, because it doesn't make any sense to sort of try to deboganizing, try to set up stuff, try to test drive it, if you do it with the correct IP addresses and from the wrong ASs, that sort of thing. The second thing is, we collected a little bit of feedback from the hostmasters about sort of this potential size of the problem we are trying to manage here, ,and it appears to be a non?issue. So, there doesn't seem to be any competition for any big blocks for any long periods of I am. So I don't see the need for going booking system direction.
And even with the booking system, we will probably end up with the situation that people, or different parties in an organisation then the people talking to the NCC will get the information, this is going to be the address space for us, and there is a pretty high probability that they start configuring it, that we are going to see that leaking and I really don't see a need to over engineer this when we are having, if I remember correctly, three concurrent assignments at most for the last one?and?a?half years or something like that. So come up with very generous, very well defined time scales. It doesn't put the burden on the RIPE NCC host masters to do whatever to come up with a yes or no, it's simple, everybody knows, this is going to be the address space, it's going to be valid from date A till date B and be done with it.
NICK HILLIARD: Thanks very much for your comments. I have two responses. The first is that we haven't seen a huge amount, or at least the IPRAs haven't seen a huge up take in address requests from this pool yet because there hasn't been a constraint in supply of general address space. Organisations have been able to go out and get PI space or get you know other address space to suit their needs. Whereas now we are operating in a much more constrained environment and this is the environment that in fact the temporary IP address policy was intended to operate in. The other thing I'd like to say to compliment what you said is that somebody made a comment on the mailing list, Neilus Bocker, he said that the purpose of this policy is not to punish the people who have a valid requirement for address space. So I think, yes, you are probably right, let's be generous about the availability and let's make this system as simple as possible. Thanks very much for your feedback.
CHAIR: So I'd actually like to solicit some feedback from Alex on this, on the viability of things. I have a suspicion that changed time scales is what you would like best, as it's most easy to implement.
ALEX LE HEUX: Okay. I haven't had the time to do a full Impact Analysis on this proposal yet.
CHAIR: Give it an Impact Analysis light.
ALEX LE HEUX: Well then, for the sake of fairness, I'll say something about all three systems.
The booking system is, has been mentioned before already, it's going to be very big thing for us to implement, and it's going to be complicated, and as Wilifred said, I would expect sooner or later, perhaps sooner, to see it happen that someone here in six months from now you'll be using that address block and then all of a sudden it accidentally appears today in the routing table already because the reason we do that is so that they could already configure their systems and they might forget to inplug them from the Internet first. So those are two issues I see with that.
Removing the time scales. Nick rightfully expects a lot of discussions with the host masters between the requesters, because yes, what is reasonable for some people is different for everyone, and without any clear guidelines, it's going to be difficult for the IPRAs to make the case that something is reasonable or not. So that is a problem I would expect with that, especially now there is more pressure on the IPv4 pool because there is no more PI and people need for address space, we might get people thinking okay we can try the temporary pool and see how far we can stretch this and they go oh I really need this one year in advance and without clear guidelines it's going to be difficult for the IPRA to say no, that is not reasonable.
Changing the time scales is, I think, very simple to do. I'm not sure if it's going to make everybody happy though, because what's reasonable for some may not be reasonable for others. But it's by far the simplest thing to implement, and the simplest thing to explain.
CHAIR: Thanks for that. It's good to have the sort of like the guidance before having this as a feedback later on this didn't work out.
SANDER STEFFAN: I think Alex's last comment also shows that we should be a bit generous to make sure that we make, give enough flexibility to make most people happy with this.
CHAIR: Yeah, well, I think what I'm hearing from the feedback is we go for changed time scales and make that a formal policy proposal.
NICK HILLIARD: Very good. Keep it simple, that sounds good to me. Okay, thanks everybody.
CHAIR: Thanks for bringing this up.
Okay, then we have another not yet formal policy proposal. Alexey, please get up. Alexey Ivanov, who ran into an issue with suballocations as currently defined and brought it here to get some feedback.
ALEXEY IVANOV: Hello, my name is Alex Ivanov. I am from Leader Telecom BV group. For now, I visit IPv4 unavailable from RIPE and we have a lot of requests from customers, but we don't have free allocation for now. And we need to find as a way how to give our customers possibility to provide app addresses. We found another LIR which can give for us IP address and we tried to find how to correct in the database RIPE to put information about allocation for our LIR. And we found that it is possible with sub allocations, but for now, size for sub allocation maximum is /20, and this allocation can be made not often than one time per 12 months. As address to change size to unlimited, and the result, any restriction for period.
It is very flexible alternative for transfers while not need to do for RIPE stuff, innocent changes, we just register in RIPE database, and I think it's simple to use IP addresses from other LIRs.
What do you think about it?
AUDIENCE SPEAKER: Remco, this time as the original author of the transfer policy in this region. Everything that you have just described is 100% possible with the existing transfer policy, even sort of temporarily handing over address space and returning it later on. It's all in the policy text. So, I'm not quite sure that we are going to need another piece of policy or change policy to do what you need.
ALEXEY IVANOV: Transfer need to ?? just not work for RIPE side, correct? I think counter transfer for now when IPv4 finished will be very big and for RIPE, that may be required to get additional people to provide this service and sub allocation don't need any work from your side, isn't it?
AUDIENCE SPEAKER: Remco. It's not my side to begin with of course. But, no, I mean ?? I mean... you have to demonstrate need for both sides anyway, so, I really don't see why one would be more or less complicated than the other. But I mean, if you want to do a full policy proposal, I am happy to review the full policy proposal and I'll then say well I'll think about it, for now I'm really unsure why you would go to the trouble.
SANDER STEFFAN: Thank you. I think we'll take this to the mailing list. By the way, very good as this being your first RIPE meeting to actually stand up here and propose a new policy. So thank you very much.
(Applause)
CHAIR: Well, since you didn't want to argue this, it's now time for coffee. So, thanks for being here. And please be back at 11:00.
(Coffee break)
