Table of Contents
- Call to Order and Announcements
- IPv4 Depletion, Adopting IPv6, and Authorizing IPv4 Requests
- RIR Update - RIPE NCC
- NRO Activities Report
- 2009-3 (Global): Allocation of IPv4 Blocks to Regional Internet Registries
- ARIN Board Resolution re: 2009-1
- 2009-2: Depleted IPv4 Reserves
- ARIN Government Working Group Update
- RIR Update - APNIC
- 2008-3:Community Networks IPv6 Assignment
- IPv6 IAB/IETF Activities Report
- RIR Update - LACNIC
- Open Microphone
- Closing Announcements and Adjournment
MR. CURRAN: Good morning, everyone. OK, welcome back to day two of the ARIN meeting.
First thing, as noted, everyone who fills in our surveys gets entered into a raffle. We have our daily meeting raffle. I have the list of entries here. I need a volunteer from the audience. There we go. I'm going to take Stacy. Heather, you should relax. We have 30 survey participants. Choose a number 1 to 30.
MS. HUGHES: Seventeen.
MR. CURRAN: Read me the name.
MS. HUGHES: Rui Wang, from Indiana University, Bloomington.
MR. CURRAN: Yes. We're going to send you--
Thank you. Come on up. We're going to send you your prize. It's a $50 Think Geek gift card. I just want to shake your hand. Thank you for participating in the survey. Thank you. We're going to send you your prize. It comes by mail. OK, thank you.
So you can be a winner tomorrow. Fill out your survey today. Again, surveys can be filled out between 8:00 a.m. and 6:00 p.m., and there will be a prize drawing tomorrow and you must be -- if you're here, you must be present. If you're a remote participant, you're fine. Consolation prize, all of the people who did not win and respondents will be entered into a final, last-chance drawing for Monday, May 11th, which will be announced. Very important to fill out surveys. This is how we know what we need to change, what improvements we need to make and we could win a Nintendo. Very nice.
OK, ARIN Information Center, reminder, it's right next door. You can take a break there. Watch multimedia presentations. You can get information on any of the policies. It's right next door. Registration services helpdesks are open. The hours for today are 8:30 to 5:00 p.m. You can just show up or schedule an appointment by dropping mail to firstname.lastname@example.org. Also the billing helpdesk.
Presentations and reports. We have some interesting presentations and reports today. So we have the -- I'll be doing a presentation about IPv4 depletion and adoption of IPv6 and authorizing v4 requests. We're going to have the NRO activities report. We'll have RIR updates from APNIC and LACNIC. The NRO AC will give its report. We'll have an update from the ARIN government working group which will be fun, and the IPv6, IAB, IETF activities report. Also policy discussions. We have 2009-3, allocation of IPv4 blocks to Regional Internet Registries. That's a global policy. We have 2009-2, depleted IPv4 reserves and we have the 2008-3 community networks IPv6 allocation. Good policy discussions as well.
Again, when you approach the microphones, be clear. State your name. I'm going to ask specifically for the head table to state your name as well before speaking. Apparently, we all sound alike up here to the remote participants, so if you're at the head table also remember to identify yourself. Everyone be polite to one another. Allow other people to speak. Don't approach the microphones until you see that everyone's had a chance to speak once and the microphones are queuing up. Please limit your remarks to a brief amount of time, one point or two points. We will implement the three-minute rule if you are prone to monologues like some of us are. And also remember to speak very clearly and say whether you're in favor of the proposal as written. That's very important for people when we're doing policy discussions.
At the head table, we've got our team here. Let's see. We've got Paul Vixie, our Chairman. We've got Bill Woodcock, ARIN Board of Trustees, Tim Denton. We've got Dave -- I'm trying to find -- sorry, Dave -- ARIN AC. We have Leo and we have RS, three Board members and three AC members. And I'd like to also remember to thank our sponsors, Time Warner Cable Business Class, thank you.
[ APPLAUSE ]
If you want to see how valuable these people are to the meeting, just turn off your network interfaces and you'll learn instant appreciation. It's only because of sponsors like this we can provide the connectivity at the meetings. It's essential to what we do here.
MR. CURRAN: Okay. I want to start in on the first presentation. And this is regarding IPv4 depletion, adoption of v6 and authorizing IPv4 requests.
Based on guidance received at the past public policy meetings, ARIN, the ARIN Board of Trustees took an action to make clear that we are doing everything we can in terms of making sure that IPv4 resources are being used wisely and are not being used in a way where we're trying to make slur we're doing responsible administration of the address pool. To that effect, next slide, we have taken to notifying our community that we may not be able to provide IPv4 addresses going out several years. We have probably, based on free pool estimates by experts in the field, we have some number of years left, two to three years. There's some windage on those estimates, but we felt it was important to make sure that people who have IPv4 blocks and might come back to get additional space are aware that there may not be space available and that if they're planning on growing and getting additional allocations, there's some important things they need to know.
We actually sent a letter to the CEO or executive that we could identify of every IPv4 resource holder in the ARIN community. This is 8,100 organizations with IPv4 address assignments that have an ARIN RSA or Legacy RSA. Very simple, because they have agreements with us, fairly easy to know who we're dealing with.
We also identified 9,400 organizations who had legacy blocks. Wanted to provide them this information as well, and if we could get clean matches on data bases, we did that as well. So the total is in excess of 1,700 letters that went out. These letters went out with delivery -- these letters went out with signature required, so there's a little bit of expense involved. You can actually see the letter that went out to the CEOs and executive directors online if you want to see it. Next slide.
What it says is exactly what I noted, that IPv4 address space will be depleted within the next few years. That might mean that it's necessary for your organization to consider the transition to IPv6 and also to make sure that we're doing responsible administration of the address space that an attestation from an organizational officer will be required beginning May 18th on your application for Internet resources. The reason for this is because we want to ensure that we're getting accurate applications. It's that simple.
The trustees would be remiss if we accepted applications and didn't require some statement that says these applications are actually accurate. So we've worked through all the policy implications of that in terms of processes. It's all available on the website. Next page. As I said, the letter that was sent out went by certified mail within the U.S., registered mail outside the U.S. to the most senior executive we could identify, based on the organization. That would be a CEO, President, Chairman, might be chancellor or president for an educational institution, ministry or department executive, governors, mayors, managers, sole proprietors.
These have actually been being received because since my name is on the bottom of them, I'm tending to get a little bit of the feedback and it's actually -- the feedback has actually been positive to date. This is actually something in some organizations we already heard is causing executives to say what are these IP addresses and why am I worried about them and who is my network engineer? Which is probably a good thing. A lot of network engineers have indicated, they haven't had a good ability to raise this issue. So maybe if they can't raise it from within we can help them with a little bit of visibility from the top. Next slide.
In terms of the exact definitions for a nonprofit, when you're doing the attestation, it has to be someone who is capable of engaging the organization in a contract, someone elected or appointed by the profit corporation's Board of Directors or the nonprofit's Board of Trustees, executive management or manager of an LLC. If it's a limited partnership, then it's any partner, sole proprietor, obviously, if you are a source of one, this isn't all that hard to get your own attestation on your application. Government entity, same sort of thing. It's an entity able to commit the department to contract.
What you should do? If you want to read about the procedures, there's a whole web page set up. You can take a look at it. Within your organization, obviously, if you're going to be sending in address requests, you're probably going to need to set up an internal process as to how to get that application reviewed. In some organizations, this will be pretty routine. In other organizations, this may require finding someone who you can educate about what exactly you're doing by asking for these IP addresses, but it's something depending on the size of your organization you want to start thinking about now, not when you're panicked, under the gun, doing the application at the very last minute. It's probably something if you are a large organization you want to plan a little earlier for. That's it. Questions?
Microphones are open for questions, remote is also open, obviously. Yes, Mr. Schiller.
MR. SCHILLER: : Jason Schiller, UUNET/Verizon. Do you expect to extend the need to have an executive officer sign off on requests to be extended to other number resources, such as 4-byte ASNs?
MR. CURRAN: Such as 4-byte ASNs. Good example.
MR. SCHILLER: : I'm sorry. Such as 2-byte ASNs.
MR. CURRAN: I was going to say, we are having enough trouble getting people to apply for 4-byte. The attestation would just an interesting twist on that. So as you can look from the policy -- body of policy that we've discussed over the last few years and all of the initiatives, there's a huge amount of pressure to make sure we're doing right by IPv4 and the use of the address pool. If this community thinks that we have the possibility of applications for ASes, 2-byte ASes in advance of need, AKA hording or something similar, it's something that obviously this community could suggest with the suggestion process. We wanted to address the key problem. The key problem is making sure that applications of IPv4 space are accurate. I don't know if we have a run on the bank on 2-byte ASNs, but if we do and someone feels that, make a suggestion through the suggestion process. The board's happy to look at it. We know by doing this for IPv4, we're addressing the central problem that it was created. Other questions?
If someone wants to get up and say this is really awkward for me and really bad and I don't like this policy and it's not that I was going to submit inaccurate information, but it's a lot of work for me to do so and I don't think I want to go through it, you can do that, okay? It's something that we has heard as feedback. The reality, folks, is if we don't do these hard decisions then the person beside you is submitting an accurate application, and we think this will help. See? I knew we had a question.
MR. NEIMAN: How is attestation not redundant with the actual signing of RSA contract, or shouldn't attestation be included in the RSA?
MR. CURRAN: The RSA contract is signed by someone who can commit the organization to contract and you agree to abide by ARIN's policies and procedures. That doesn't say that the list of information that you give to ARIN for this particular request is actually accurate. So when someone is saying here is the allocations and assignments that we've made and we no longer have use of these addresses because they have been given out to clients and now we need a bigger block, that's not seen by the same party who signed the RSA. In fact, it may be being done by someone who is fairly junior in the organization who has just been told get the job done by any means. By making an officer look at this and say, yeah, those usages are actually from a source I understand to be accurate, we're getting a little more -- we're getting an accurate -- a more accurate chance of applications for address space at the actual application time. Not just at the RSA signing. If there's follow up, let me know. Microphones remain open, center front.
MR. TEMPLIN: Pete Templin, Texlink Communications. As far as feedback, I want to thank you for putting your name on the letter and providing that opportunity for feedback, and I do hope that ARIN continues to use that as its motto for all the communications that it sends out. Thank you.
MR. CURRAN: Thank you. Sure. Far right microphone.
MR. KITCHENS: Doug Kitchens, Suddenlink Communications.
MR. CURRAN: Step forward, please, so others can hear.
MR. KITCHENS: Doug Kitchens, Suddenlink Communications. I just had more of a comment than anything. Yesterday, we went over several policies that seemed to have the intent of prolonging the life of IPv4 which to an extent, I can understand. But I think this really goes a long way in helping to us identify the problem and raising awareness so to say within our own companies that, yes, this is a problem and the solution is to get off of IPv4 because we are about to run out.
MR. CURRAN: Thank you. Any other feedback? Anything from the remote folks? Okay. No other feedback, thank you. Thank you very much.
[ APPLAUSE ]
MR. CURRAN: Wow. We're ahead of schedule, which means I want to look at Axel and make sure he's ready. Yes, ready, Axel. We will move ahead to the RIR update from the RIPE NCC.
MR. PAWLIK: Good morning. I'm Axel from the RIPE NCC Pointers anywhere?
Okay. Quick update, some of you might have seen some of this. There's some new information here as well. For the very first time, we went last year to sort of the outlying regions of our service area, that is, to Dubai. We have had quite some interaction with the people there with more regional meetings that we call them, whereas the updates from the RIPE NCC, what has been going on but we have heard quite a lot from them locally that we should go there and bring the RIPE meeting, which is what we did a little bit of trepidation because we didn't know how many of the regulars would come and then would the locals come if we came and stuff like that. But I'm happy to say that there was quite a number of people. There were locals there as well. We would expect that. From about 50 countries, overall, it was a great big meeting. It was really lovely. We had a nice social in the desert somewhere where they had row of white Land Cruisers picking us all up, a really long road, took a while and then they ran out of white Land Cruisers in Dubai and they came with gray and black ones. Interesting.
The focus of the meeting was similar as here, v6 and v4. We have had for the first time, our cooperation working group which is basically the governmental folks talking to the engineers a bit. We had our first meeting those guys there. Interestingly enough, the Chairs couldn't make it. It was the first time only. It went quite well. Then in October, we had a general meeting as we do twice a year. At the end of the year is always about plans for the next year. You had fairly good attendance and 72 votes, doesn't really look that much seeing that we have over 6,000 members, but, you know, in relation, it's quite okay. The charging scheme for this year was adopted with a bit of discussion. We didn't propose any changes in the fees. There was the intention from some of our members to look at PI space and to discretely charge for PI blogs and we said at this point we don't really want to propose this because it would -- it would affect a lot of members quite significantly to the tune of much more they would have to pay at the RIPE NCC than before. They in our opinion, didn't have enough time to be prepared for that so that's what we did. That was adopted. That's good. Budget for this year is about 15 million euro and approved by the board, that's our board. You have seen them before and Nigel is sitting over there. Thank you for coming. If you have any concerns, talk to him.
The interesting thing is that we had a lot of candidates and we have this very nice voting system where -- a procedure where it takes a while and it is just before the party sometimes, and you know, people get tired of the voting, so we said we want electronic voting and we looked at electronic voting and we're not doing electronic voting right now because we have some concerns about secure voting encryption and some countries in our service region might not really like it that much. So we are looking at the whole thing and even paper balloting and we'll see what happens there. We'll propose an overview -- we will present an overview at the next week, actually, the next RIPE meeting. So preparations, hey, preparations for the future, well we very been talking with our board. We have focused on -- we are focusing working on three main areas of retention strategically. Role of the RIPE NCC in terms of community building, building and expanding the community and stabilizing it, outreach, get more people in, get new people in newer sections of what we think is our community and doing PR as well. Trusted source of data. Hey, we are the registry. We should have correct data. We should make it available. We should be using more reports and have tools available for you guys and our members. I already called the third pillar there, numbers, those life cycle management, basically dealing with the whole life cycle of resources and giving them out, tracking them, auditing, reclaiming where necessary, and certification comes in there as well. And so we have been looking at those things for quite a while and focusing and are implementing.
So basically, those are the big things that are keeping us busy still, certification, support for policy development -- obviously that's a lot of things going on. Developing information services and rebranding them and making them more available and in a better way and outreach PR continues to be important to us. Certification, all right, you have seen that slide before. We have started this by setting up a task force of our members, guiding us in terms of business processes, how we should be doing this so it is helpful to them. We have announced that the last RIPE meeting also a limited test run with a couple of participants and we have plans to deploy this year, but we think what we have been doing so far -- and that's a technical infrastructure that works that is fine. We're done basically. Now the question is do we want to roll this out? Are there any other concerns? Are we creating tools that are favored by some members of our community but certainly not by others?
We have to think about this a bit so that's what I'm presenting next week at the RIPE meeting also. Let's think about this and give us more strong feedback, who is going to use this? And there of course we are connecting with the other RIRs in terms of what we are doing. It needs to be compatible and it is, but what does it all mean, policies and practice statements and stuff like that, okay.
Policy development, 2007-01 is a lot of work. We knew that and that basically is an attempt to get a better grip of who has direct assignments from us, [by us] basically. We have started to implement this. The idea is that people need to have a direct defined contract with our members or if they don't find a member who is willing to do this with ourselves and we started that phase one and just do it for new assignments and of course, we need to look at the previous assignments and that's where a lot of work comes in and I have couple of spreadsheets on my desk saying we need so many more people for this. I think Nigel has noticed. We will talk to him later. Yeah, reallocation, that's a transfer proposal that has been accepted in December finally, there's a whole lot of other things that you might find similar to what you're talking about here and well, yeah. Good.
Information services, we have quite a lot of them and what we want to do is to make them available through some sort of a portal innovator that you don't on the individual service that we see ourselves but on the data and the results that you get. So we are quite busy working on that stuff. As said, we have about 6,000, probably some more by now, members, 6,000 and a bit. We do see a certain slowdown not in terms of applications where people send us application. I want to become a RIPE NCC member, there's plenty of those, but we do see the conversion rate dropping. I think we have 50% and it used to be 80. There's something happening there. We get less new members in the end than before.
But, well, we pay for that, and that's okay. Regional meetings and I mentioned those. Basically, it's an update from the RIPE NCC in the region and the regions are the Middle East and basically Moscow, or Russia. We try to get out of Moscow and St. Petersburg and some other places built people are telling us no, go to Moscow, that's where you find the people, okay. Good. Operators group, network operators group, that is something that came out of regional meetings in the area there. We have had the fifth or sixth one recently, I think, actually. Let me think, the fifth one, yes. The fourth one was at the interspersed with the RIPE meeting, basically at the RIPE meeting, and a couple of weeks ago, we went by Rhine and had the fifth one. Membership survey has been done last year. We have the results and for quite some time and we are looking at what we want to do with this.
Basically people are telling us, you are great. You are better than the last time you asked us, but overall, there are so many who say, well, you need to make yourselves available by telephone in so many different languages and we say, oh, we don't feel so comfortable that we have to find a way of making something like that available. Other comments were very, very easy to implement like more belly dancing at trainings.
[ Laughter ]
More belly dancing at trainings? Interesting. So we look at that. Other PR and outreach, we have a PR agency and work closely with them, Racepoint in London and we use them for stuff that we do together with the RIRs as well. V6 update, 4-byte ASNs, stuff like that, we are talking to -- they facilitate me, talking to join lists and stuff like that. Support for events and I think I have shown that slide before.
Announced cooperation, governments, as I said, we have the RIPE coordination working group now. Basically it's meant to bring governments together with the rest of the community. Maria Hall from the Swedish government co-chairs it with Martin Boyle, formerly of the UK government, and now nominated. It seems to be quite popular. Other external relations, we have been talking to the OECD. Of course we went to the meeting there last June. Roundtables for governments and regulators, we do regularly, twice a year. The last one actually had a little workshop attached to it on the following day for law enforcers. That is quite interesting to us. For a long time, we do get the occasional faxes and saying tell us who are the bad guys and who is using this address or that address. Now they know -- quite a number of them know that we are there and said that we have very good relationship with the British guys and with the Dutch guys and starting to move into Germany as well a bit.
This is something that we think is extremely important to us and to our community. The police force needs to understand what we can do and can't do. Right. Next RIPE meeting, next week. If you pack up your bags quickly tomorrow, you can make it to Amsterdam in time. It will be -- don't want to say what the weather will be. Better than here, I think.
[ Laughter ]
If that isn't good enough for you, you can come also come to Portugal at the end of this year and for next year, we are preparing Prague and Rome. I'm not promising that we will actually do it, but we might. That basically is my presentation, but one more thing. I received a couple weeks ago a mailing in my mailbox, the challenge from APNIC. Basically, there was a cheeky girl saying, well, we are challenging you guys to beat us in the corporate global challenges. What is that?
Well, of course, they would understand if you wouldn't be able to stand against the superfit Queenslanders, oh, that's something to do with sport. That's great. I love that. So I said, well, you bastards, we'll do that.
[ Laughter ]
Whatever it is, we'll do that. We have five teams so far, and you still don't know what this is about. Basically, it's about getting out of your chair in front of your computer and run or walk, move around. On average, 10,000 steps a day and that seems like not terribly a lot and you have to walk up and down the stairs and whatever you want to do. No hopping around in front of your computer, that's cheating. And it runs 125 days and obviously, we are challenging ARIN staff.
[ Crowd moans ]
MR. CURRAN: We will take this under consideration.
[ Laughter ]
MR. PAWLIK: That's not good enough. I know what this is really about, but I can't tell in public. I this is from a certain girl in APNIC and you can talk to me in private about this. It's for a good cause. Well, thank you. Any questions? Thank you very much. This is going up and down the stairs. That gives points.
MR. CURRAN: That doesn't count. No way. That does not count.
MR. CURRAN: Next on the agenda the NRO activities report by Axel. Take it away.
MR. PAWLIK: I'm living on the 17th story here and I considered walking up the stairs, but the thing only starts on the 21st of May, I think. So there's no point in doing that now.
[ LAUGHTER ]
All right, no, I'm not Adiel. Adiel is the current chairman of the NRO. Here's a quick report on what the NRO is, of course and I think you more or less know this. We are here to basically promote and protect our policy development process. That's something that all the RIRs are doing as well, but they're doing it together as the NRO, has been established by the MOU and stuff. Current officeholders are Adiel as the Chairman and I'm currently secretary and Raul over there is the treasurer for this year. We have two formal coordination groups, the engineers and the communicators, and Andrei Robachevsky from the RIPE NCC is currently chair of the ECG and CCG is Paul Rendek. I'm from the RIPE NCC, as you know. We look at our joint expenses and basically this is about our contributions to ICANN and small meetings that we do together and we all put that together into one big pot and divide, and this is divided on the basis of how many resources we giving out in our overall budget among the RIRs to keep it fair. We have recently renewed our commitment to ICANN and that's no big deal. But formally, we have exchanged letters. This is the same terms in the exchange of letters as of December of 2007, that basically says we will give you the same amount of money this year. It's appreciated by ICANN and it's good. Future meetings, oh, that was in the future some time ago. Yes, we went to Mexico. I'm happy to say it was quite a few weeks ago and I'm feeling healthy still.
[ Laughter ]
It's a bit of a concern these days. And of course we will also go to Sydney. The one constant thing that I'm happy to say that we are doing at those ICANN meetings, we do talk to a lot of people specifically to the government advisory committee, the GAC. We went in there last time and basically they praised us and it was a little bit embarrassing in terms of what we were doing as the RIRs to talk to the governments, how they feel supported by us and of course that is exactly what we wanted to hear. Good thing. The IGF, it's still going on.
We have been in Hyderabad. We have a small booth there usually if they get it sorted out that there's a possibility to do that. It's we think fairly harmless these days. It's exchange of information. As you know, there's no power to make any decisions by the IGF itself so its discussions, we engage people there and hold workshops and it's basically a good thing. So the next consultation meetings are -- the next one is happening also in a couple of days already in Geneva to prepare for the meeting this year. And of course we do occasional statements among the RIRs and in terms of the enhanced cooperation, what have we been doing that over the last few years. It's quite good. So representation, coordination among the engineers, addressing before on v6 issues jointly. We have had a couple of meetings with broad participation among the RIRs also, and I'm very happy to say that our executive council has finally agreed and been able to agree, that’s the main point, on a two-day retreat. We will have that in June and we think it's only five people and another couple of supporters and observers there and it should be easy to find a date for this. It is very difficult. So I'm happy to say that we are actually doing this June. That's the quick update from the NRO and again, I'm still here until tomorrow. You may ask me any questions you would like.
MR. CURRAN: Questions for Axel.
MR. PAWLIK: Thank you, again.
[ APPLAUSE ]
MR. CURRAN: Moving briskly ahead we're going to pull up the 2009-3 presentation of policy proposal 2009-3, allocation of IPv4 blocks to Regional Internet Registries so bring up the policy history. Introduced on 13th of January, 2009. It has been through the ARIN Bridgetown, Barbados, public policy meeting. Draft policy with staff assessment is the 23rd of March, 2009, along with the current version. In the other regions, and this is very important for global policy, it's in last call at APNIC and AFRINIC, LACNIC and RIPE NCC. The shepherds are Scott and Marla. Summary, RIRs would return IPv4 space to IANA. So when space is returned to an RIR, in turn it would return to it IANA. Legacy space mandatory, space allocated or assigned prior to the creation of the RIR.
So if a resource was returned to a Regional Internet Registry and it represents space prior to the creation of that RIR, it would be something that would get returned to the IANA. It's possible for the RIR to return other space to the IANA if so desired. New IANA to RIR IPv4 allocation policy, this is the interesting part. One-tenth of the free pool every six months. Presently, the allocation method is not size variable based on the remaining free pool. This would make it variable, based on the remaining free pool. A six-month period that begins with 1 March and 1 September. So within those periods, each RIR would get one-tenth of the remaining free pool. Next slide.
Staff assessment of this, liability risk legal. The proposed policy would establish a different political and not needs-based method for allocating returned space. This proposed policy undermines the legal rationale for distribution. Staff comments or concerns, issues. Yes. The majority of legacy space in the ARIN region will incur a quote, "net loss," quote. Staff implementation, resource impact, minimal. Because this is truly between the IANA and the RIR, it's not something that really affects your templates, applications, online. It just affects how often we apply and what we receive. The impact is available at that URL and so PPML discussion, one in favor, one against out of 35 posts by 12 people. Some of the comments from the PPML, I believe that there's a need for some sort of policy on what the IANA should do after it allocated all of the currently unallocated IPv4 /8s. There may not be a global PDP, but it sure would help to post any global idea to the RIR communities first, and then incorporate their input into one proposal that includes rationale. This policy has shown us there is no such thing as a shoe in and that the policy capability established inter- RIR works fairly well. With that, I will have Scott come out.
MR. LEIBRAND: The problem statement, this is intended to capture some of the reasons this policy was created. Right now, the current policy does not provide for any way to redistribute any reclaimed space back up to IANA from the RIRs or to distribute that down to RIRs. It is currently only set up to allocate unallocated /8s to RIRs from the global free pool. There's no more global concepts on what to do when there's no more /8s. The proposal context is long. I don't expect you to read it off the slide. You have it in your handout. I have bolded some things which I will get back to you later. Those are changes. The second page of it.
The rationale as provided by the authors is that this will provide a mechanism for the RIRs to, and I will paraphrase, reallocate space to the IANA. We already have gone over this in the other slides -- and give it back to RIRs on a needs basis and it creates the global pool and reallocated space without requiring transfers between RIRs directly. There have been a number of concerns of the original text and those were captured. The staff and legal reviews were actually on the revised text but the same concerns were expressed before the revisions, as well. One way that that could be expressed is that this creates a disincentive for anyone -- any RIR to actually expend any real resources, time, staff effort in reclaiming space. Steve has put together the LRSA and ARIN is doing a lot work on that. This would mean that address space goes back to IANA so there's less incentive for an RIR to recover space. On the other flip side of that, some current holders of address space, we're thinking here I think mostly of large holders who are more public interested and less commercial and might be less willing to return space to ARIN if that space were to go all the way back up to IANA instead of staying within the region and this would also, if it were done with small blocks, would fragment the reverse DNS such that there would have to be all kinds of interesting glue to make point of records work. As a result of these changes, myself and the AC -- excuse me, as a result of these concerns, the AC made some changes to the policy in an attempt to address those. I am not going to claim that we did address them all or very well, but we'll get back to that.
Most of the concerns seem to center not around the structure of the system but around the fact that address returns are mandatory. So that's where we focused. We modified the original text to make returns optional for regular space and mandatory for legacy space. The idea there was that was kind of what was the essential focus to begin with and we want narrow the scope a bit. But that still leaves all the same concerns just applying to legacy space and not to all space. So there are a number of paths forward that we could take that I'd like to get feedback from the community on. One would be to go back to the original proposed text. Actually, I think we skipped. Yeah, okay. I wanted to say that the sections that we changed are in bold in the previous slide, which I should have done this in a different order, but I will go back and review those. So you can see at the top if you have really good eyes that the legacy space was made mandatory and nonlegacy was made optional.
We also added a clarification that address space returns can continue after the redistribution occurs. That wasn't in the original text, but I think that it was the intent of the legacy space. And then define legacy space at the bottom, so sorry for the out-of-orderness here. So the paths forward would be undo all those, go back to the original authors' suggested text, approve that. That's what APNIC did and that's in the last call and that would be the quickest path forward to getting this thing approved by all five RIRs and ratified and all the other global policy stuff. Another option would be to adopt the current draft policy and that is to say the version that we revised. That would leave legacy returns mandatory and all other returns optional. We could change it so that it's not based on legacy or non-legacy. It's just large blocks that have to be returned. So one example of that would be, say, all /8s that are returned to ARIN would go back to the IANA and anything smaller wouldn't have to. Or you could set it at /16, you could do whatever you want. We could make returns completely optional. That is, leave it up to ARIN staff to say this would be a good idea to return this block to the IANA, or we could abandon the proposal entirely. So I would love to hear what people think we ought to do, concerns, comments, questions. John, did you need to do anything, or Paul, did you need to do anything as far as mics, or just go?
If so, queue up, center microphone.
MS. ARONSON: Hi, Cathy Aronson, ARIN AC, and I wanted to mention and I know probably everybody probably already knows this, but since this is a global policy, it has to be identical and passed identically and all of the regions and we're pretty much the first region to actually change the text. So even if we do approve it, then all the other regions have to adopt the same text that we adopted. Otherwise, it won't actually become adopted.
MR. LEIBRAND: Right, that's a very important point. Thank you. The way the global PDP works is minor changes, such as maybe that clarification about things continuing after, whatever, those could be reconciled but major changes, maybe substantive changes like making it mandatory or not mandatory would have to be gone back and approved by the other RIRs. That means APNIC, they've already approve one version, they would have to reapprove this or we would have to approve theirs and the other RIRs that are working on it would have to choose to approve the same text and that would have to occur before that could go up to global policy.
MR. SEASTROM: Ed Lewis participating remotely: Regarding the fragmentation of the DNS regarding legacy space, it's probably already fragmented as part of the ERX, the early registration transfer process is five years back and he would not care if returned space escaped the region.
MR. DELONG: Owen DeLong, ARIN AC. I oppose the policy as written. I think that having any sort of post-runout mandatory return to IANA interferes with staff's ability to effectively manage the IP address space that we have and how we serve our users in our region. I think that staff is perfectly capable of making appropriate judgment calls on what should go back to IANA versus what we want to keep and use in region of returned space. I don't expect that we're talking about a huge amount of space anyway. And so, you know, this level of micromanaging how we handle the crumbs that are left is kind of silly. In terms of us being the first region to change the text, that's not true, we are the first region to change the text after one region adopted it, and that's because the other region adopted it in February. The text was changed several times by APNIC and the authors went along with those changes and submitted those changes to the other regions because APNIC was the first place to consider it. So I think we should feel equally free to modify the text as necessary in our region and they can sort it out in the global process, but as currently written and as originally proposed, I absolutely oppose this policy.
MR. LEIBRAND: Would you support one of these options up here?
MR. DELONG: I would make all returns optional under the policy. That's that would be the only way I could support it. Staff has to be able to manage that.
MR. VIXIE: Raul.
MR. ECHEBERRÍA: Raúl Echeberría from LACNIC. I'm one of the authors of this proposal so obviously, I support the proposal as written. This proposal was the result of a long cooperation and collaboration of all the boards of RIRs and the CEOs. It took a lot of time to get this proposal in the way that it was written. I think that this proposal takes into consideration some concerns that have been expressed by different stakeholders in many international forums. I think the RIRs is a global system and basically the original structures but this is a global system we have the challenge to think in a global way here.
This is a global policy proposal so this is something that will affect the whole Internet community and not only one region. This is something that we have to have in mind while taking into consideration the interests of the specific region but thinking in a global way. I think if some changes -- if to make mandatory only the legacy space recovery as a way to get a consensus among all the communities, I am ready to support that. If it is -- if it gets consensus in every region, I am going to forward the same proposal in other regions. I am very confident that this proposal could be adopted in every region. If we don't make mandatory the return of any space so that the policy doesn't make sense because it doesn't rule anything. It is just an aspiration of a wish so it probably we will be sending the opposite signal that was expected with the original proposal. Maybe it is better to do nothing than to send the wrong message to other stakeholders that are concerned about this issue, obviously in this moment. Thank you.
MR. VIXIE: Thank you, Raul. Did you want to answer?
MS. NOBILE: Not answer. I have some information that might be helpful to the discussion. We went back and checked returned all address space, IPv4 address space returned to ARIN since January of 2005 and in total, returned, revoked, reclaimed, we had 1.6 /8 worth of basically discontinuous space returned to ARIN and we checked to see what was legacy and non-legacy and about one-seventh of that space was legacy space. The rest of it was all on ARIN-issued space. So 1.6/8 reclaimed over the past four years.
MR. LEIBRAND: Do you have any statistics on how big those blocks were?
MS. NOBILE: I do. I have it for a presentation tomorrow. It's all over the place from /14 to down to /24s.
MR. LEIBRAND: Thank you.
MR. HANNIGAN: Martin Hannigan, NRO NC for this first part. Scott, basically as Cathy told you, there is some concern about editing the policy but as long as you follow the ARIN PDP, you can do anything you want to the policy. You're not restricted from doing anything. The only restriction you have is to follow the ARIN PDP to the letter. Now I'm Martin Hannigan with a cold and I oppose this policy, and I think we had a pretty extensive discussion on PPML and one of my main points was that it's extremely unfair in my opinion, especially the way that the allocation algorithm works. So, for example, if the space goes back to the IANA and there's a one-tenth and that may take care of, for example, LACNIC for six months, whereas it would take care of the ARIN request queue for about two seconds. And I think that if there is to be any space returned to the IANA that the potential is there's a better way, but I think I raised the concern that there's problems with other regions' transfer policy. So we can theoretically return space so the IANA and have it allocated into another region and have it enter into some kind of market and that's not fair to the ARIN region as well. I think we should think globally as best as we can, but I think our primary responsibility is North America and I think the first bullet point on this slide here should be abandon the proposal. Thank you.
MS. ROBERTS: Lea Roberts, Stanford University, then the ARIN Advisory Council. I support this proposal both in its original form and as modified, and as a point of information when Stanford returned our /8, ARIN handed right back up to the IANA, and so I believe that at least legacy space should be handled that way. It was assigned essentially by IANA and so that is sort of where it should go back to. I'm really kind of the opposite opinion that ARIN should focus on themselves. I think we already have the reputation for kind of having the vast majority of legacy space and being the IP address hog in North America, it would be a good thing to not stick with that way of being.
MR. VIXIE: David.
MR. FARMER: This David Farmer, ARIN AC. I support the general concept of this policy that we need something -- we need a way to work after we have run out. I think some amount of space needs to be returned to ARIN -- or to IANA. Personally, I think -- and yes, we do have global responsibilities and to find a proper balance between those. I think something like a 50 percent requirement to return might be a compromise that's workable. The only problem there is you will get into -- we're going to all get into arguments about what the algorithm for the return is. If we could find a way to not have that argument, then maybe we can find a compromise.
MR. WILLIAMSON: David Williamson, Tellme Networks. I keep thinking about this and I'm on the fence periodically and then I start thinking, is this really just a tempest in a teapot? The amount of space being returned, I mean, it's not gargantuan. It's not an amount that's going to supply the global market for v4 for any period of time that's substantial, and I keep thinking, this is a very complicated, convoluted algorithm and a lot of requirements that are mandatory and not mandatory and edits and global policy development, and it seems like a lot of work for very little gain. I keep coming back to what's the point? It just doesn't seem like the amount of effort we're putting in this is not worth it. When I get down to it, though, I kind of start thinking about fairness and global fairness, and there's no good equitable way to deal with it. North America has a very large demand for IP space which is why we absorb a large quantity of what was available. We were early adopters and that gave us a head start. That space comes back, staff probably can find something to do with it. On the other hand, it could also be used elsewhere in the world. There's only so many three two-bit integers. We're running out. So it doesn't really seem that there's a real equitable way to deal with the problem that's attempting to be solved here, so I don't really feel like I can support any of these options. I don't have any good ideas unfortunately. I don't support this as written because I don't see any point.
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I have three concerns with regard to this policy. The first is if I didn't come up and talk about deaggregation, you would all think I'm asleep. My read of this policy is if a single RIR returns a single /24 in I think it's a six-month window then that block would be divided up 10 ways and if you are going to divide that up on a CIDR boundary that gives you 16 /28s which then could be -- IANA could then reallocate to individual RIRs. These are awfully small blocks and may lead to deaggregation. Am I misreading the policy?
MR. LEIBRAND: I believe there's a /24 limit on the smallest block given out. I need to find out.
SPEAKER: 2B, or not.
MR. LEIBRAND: The minimum IPv4 unit size would be /24. Last sentence of 2B at the top of the slide.
MR. SCHILLER: So if a single /24 is returned, they have to sit on it until they get nine more?
MR. LEIBRAND: Yes. Oh, okay. Apparently, they give it out to someone. I don't know how they flip a coin.
MR. SCHILLER: And that's fair?
MR. LEIBRAND: I don't believe by the time we get down to one /24 we're going to be so worried about who gets it.
[ Laughter ]
MR. SCHILLER: We're looking at a six-month period here. I mean, we're not saying there's only one /24 left on the planet. We're saying in this six months only one /24 was returned. It's very different than the picture you are painting. So let's be fair.
MR. LEIBRAND: I'm not the author here. I can't say what they were thinking. The way I read it, the idea here is there will be a bunch of returns right around the end of the pool. That's going to make a pool that is going to be gradually given out. At some point, we will get down to block sizes of /24 and at that point, everything will shut down.
MR. SCHILLER: OK. My second point is with regard to ways in which we could move forward. I wanted to offer another alternative, and that is if people in this region think that it is ARIN's responsibility to look out for this region first and then globally for the rest of the Internet, then I might suggest that what you might want to do is say ARIN can hold onto space if they project there's need for it in the next six months and if they project there's no need for that space, then they should be obligated to return it to IANA. That might be an additional way to move forward. Third point, I wanted to ask the authors, Axel and others that are in the room, it was my impression that the point of this policy was that in the event that stuff does get returned to IANA, we want to be able to have a mechanism to deal with it and use that space and not be stuck in limbo. If that really is the intent of this policy, then why would anyone be concerned about making the return of that space completely optional?
MR. LEIBRAND: Raul, are you answering that?
MR. ECHEBERRÍA: I didn't understand the last question.
MR. LEIBRAND: Let me see if I can paraphrase what Jason said. Part of the reason for creating this policy was to create a structure so any address space back to IANA doesn't get stuck there. For that reason, would it not be better to have this policy in an optional manner than to not have it at all?
MR. SCHILLER: Acceptable, not necessarily better.
MR. LEIBRAND: Better than nothing is what I was trying to say.
MR. ECHEBERRÍA: No comments. I will wait for my time.
MR. CURRAN: We have a remote question? OK.
MR. SEASTROM: Rob Seastrom, ClueTrust and ARIN Advisory Council. In response to David's existentialist view on this, which I sometimes fall into myself, while I am sort ambivalent about the little tweaks to this policy, I am very much in favor of having some policy that addresses these so I'm not in favor of abandonment, and for the same reasons that I elaborated on yesterday, which is that not having a policy to address this in the current climate gives fuel to the people who are not our friends and do not think that we are capable of self-government in this arena and, therefore, I am in favor of going ahead and moving this policy through in whatever form -- I don't think that the form of the policy makes nearly as much difference as having the policy in place.
MR. TEMPLIN: Pete Templin, Texlink Communications. With regard to leaving addresses in limbo, does this policy not leave half of the IANA free pool in limbo, or at least not available for assignment within a particular six-month window?
MR. LEIBRAND: Yes, but the idea is that if you get 100 units, you'll give out 50 of them in the first six months, 25 the next six months, 12.5 the next six months and so you have what essentially becomes a long tail that makes it so the stuff keeps getting allocated for a long time in smaller and smaller increments.
MR. TEMPLIN: Is that what the community thinks is best? And, secondarily, I would only support this if returns were completely optional. That said, assuming this paths in a manner that legacy returns are -- do we need to rewrite 2008-6 to specify the transfers are only possible from RSA-held resources and that legacy resources cannot be transferred because they apply under this.
MR. LEIBRAND: I don't know for sure, but I believe some action is going to be required to check the interaction of those. I think the -- we want the -- I think counsel wanted the addresses to go back to ARIN before they go out for legal reasons. I think what we would have to end up doing and we will have to review this now that 2008-6 and 2009-1 are likely to go. We probably will have to revise this policy slightly to make sure it's clear that it doesn't apply to the transfers.
MR. TEMPLIN: Thank you.
MR. VIXIE: I'm going to give Raul and Axel a chance to speak on the proposal authors. Yes, at the microphone.
MR. ECHEBERRÍA: I feel that I'm skipping somebody else. The main objective, of course, this proposal was collaborated on by many people by the all regions and probably each of us have different motivations for doing that. I don't represent the view of all of the authors. I represent only my own view here. I think from my perspective and from LACNIC's perspective, since the Board members were drafting this policy and proposal, the main objective is if IPv4 addresses are recovered, they should be recovered for making them available for the global system. That's the main objective. There is no other hidden goals with this proposal. Since I joined the RIR CEO's group in 2002, we have many meetings with and we have made many presentations in different forums. Many times we have been questioned by the unequal distribution of IP addresses among the regions, and we have always said that we were not responsible of the legacy space allocations. What we could demonstrate is that after the RIR system was created, the distribution of IP addresses, the allocation of IP addresses in all the world was done under similar basis and taking in consideration the needs of all the ISPs or Internet organizations or users. So this is -- I feel that we have to act in a consequential manner. There's no way to defend that the legacy space should stay within the region where they were allocated. Let me say something. In North American regions, there is about more than six IPv4 addresses allocated per Internet users, while in Africa there are 0.25. In if we have to defend primarily the RIR, if we feel the RIR system is useful for the community. So we have defended a way in which we have allocated since the RIRs were created. We have to act in a similar way and what we are saying here is that the system will continue working in the same way after the central pool is absolutely depleted. Those addresses that come back to IANA under IANA contracts will be made available for all the RIRs in similar ways that the current are available today. If the RIRs demonstrate a need for more addresses so they will receive up to two allocations per year. I don't think that we have to think that those -- this policy will sort the needs of IPv4 addresses after this is completed. That's not the objective. Probably, we will receive just small allocations that will be useful for attending to some emergency issues or dealing with infrastructure -- critical infrastructure, whatever, I don't know. This is what I am trying to solve at the time. We are not trying to solve the problem before completion. We are trying to give assignments to the whole community that the RIR system will continue working in similar principles of those in which we are basically working in now. Thank you.
MR. VIXIE: Before we go to the head table here, I want to ask Axel also as a co-author of this proposal to comment.
MR. PAWLIK: Thank you. I have presented this proposal in the APNIC meetings and there were similar requests, and basically I would like to back up on what Rob said earlier. The RIRs currently are under quite close observation concerning appropriateness of the policies and whether they do a good job or not in general. So similar to what Raul says this is not meant as a tool for fixing IPv4. That's dead anyway. We know we have to go to IPv6 and that's something that we should do. What we currently don't have is a policy that allows transfers between RIRs, assuming that they have needs in some regions that a region cannot meet and if there should be results available in other regions, we don't know what to do with that currently so this proposal would take care of this and I think this would demonstrate good stewardship on the RIRs to open the way to such a thing. On the details, we can discuss until the cows come home. I'm not sure that that will really be useful seeing that we are running out of v4 anyway.
MR. LEIBRAND: Would you support an optional return?
MR. PAWLIK: I really would like to keep the policy as it currently stands and exert a little bit of pressure on the individual RIR to actually do-- to conform with this policy.
MR. LEIBRAND: Thank you.
MR. VIXIE: John?
MR. CURRAN: John Curran, acting CEO of ARIN, member of the Board of Trustees, and I was a member of the RIR Board workshop drafting team that drafted this text. So I'm going to try to give some preface to this just to make sure everyone knows. I am not a signatory. I didn't list myself intentionally as an author because it was an RIR workshop of Board members to make sure that we got this globally agreed to and someone had to hold the editor's pen and I tend to do okay doing that. It's a simple issue. The simple issue is that there are two aspects of this policy that need consideration in region and it's a simple high-level policy question. The first one is pretty easy and it's when we get to the point of having resources are claimed resources, how do we pass them out? Do we pass them out needs based, or on an asset allocation system?
That's a change because everything we have done is needs based except that one /8 which we're not talking about and everything else is needs based and we need to decide if we will go forward with that. That's something for this community to think about and an opinion on one way or another. The second item which is equally important and which has been eluded to is how does this community, ARIN community, view its responsibility on legacy resources? Does it see it as performing stewardship and administration on behalf of North America and its region or on behalf of the global Internet community? This is a decision that is pretty important. It has impacts to all the businesses here, one way or the other and it has impacts on how we're viewed in the international community. It is equally important and in fact, it may actually be the harder of the two issues to discuss. This is one of these matters that there's almost no chance of the Board of Trustees making an opinion on without enormous community input. If you haven't spoken on this matter, I would like people on the microphones. There's no way we can make a judgment unless it's very clear how the ARIN community feels.
MR. VIXIE: We have two participants and I want to hear one and then we will do Goldberg and then we will hear the second one. Oh, you're behind Dillon. I didn't see you. Never mind. You're first.
[ Inaudible comment ]
I'm sorry. No, you're first. Rank has its privileges.
[ Laughter ]
MS. SCHILLER: All righty then.
MR. DARTE: Hey, if I were pregnant, you'd let me go first.
[ Laughter ]
MS. SCHILLER: Heather Schiller, Verizon Business. So I guess the first thing I'll address is John's question about at least my perception of legacy research within ARIN's role with regard to that, but for me, it's a little bit more broad in that I think that ARIN's role is to apply what it says up there and to act in the best interest of the ARIN community and if there's a resource in the community that is legacy or not, it's ARIN's role to act in the best interest of community with regard to that resource. That is their place as it is for any RIR with whatever resources that you've been tasked to administer. It's not fair that the system as it got developed and built didn't distribute resources. We didn't start out with five regions and equally divide the space into five pieces. It didn't happen. So we have what we have.
We have it set up regionally. It's not fairly distributed. If someone wants to come along -- I think my concern with this policy is it -- it doesn't say that the part about returning address space to IANA only has to do with legacy space. I might be able to handle that better, but it says that it applies to all address space that gets returned, and so I think that if you -- in my opinion, if you separate that part out, that's a consideration. But I posted a bunch of technical questions to both the ARIN mailing list and I think I did it to APNIC and I think I did it in the LACNIC region. I think I tried to get all five regions and said what else does this break? To me, it seems like Jason mentioned it breaks aggregation, it breaks DNS, it breaks geolocation. It breaks a lot of other stuff, and I didn't get any answers. No one provided any good technical answers about how that part of it would be addressed. So I would really like to hear from someone about that.
MR. LEIBRAND: I'll make one comment, which is that's more of a problem as you get to smaller blocks, in my opinion. Do you have any opinion as to whether this policy would be better if it were all /8s through /16s that we were dealing with, instead of smaller blocks, or does that even matter, from your perspective?
MS. SCHILLER: I think that the larger the block size the easier it is to fix that type of problem but the policy isn't written that way. It says down to the /24.
MR. LEIBRAND: Which is why I have bullet 3, which is not the text that we have out, but it's a possible way we could revise.
MS. SCHILLER: Yeah, I agree, but I just -- I guess I'm frustrated by the fact that I posted these questions several times and no one has come up with any good answers and it's like so now I have to stand here and ask and I'm not sure I'm going to get any answers and we're not going to move forward now.
MR. VIXIE: One remote question, please.
MR. SEASTROM: We're up to three now, so please interweave as you see fit. [Joe Neiman] from CHL says, fairness is important for many reasons but returning the recovered space to IANA does not seen compatible with any incentive-driven process or address transfer and he is in favor of 2009-3.
MR. VIXIE: Bill.
MR. DARTE: Yeah, Bill Darte, I'm on the ARIN Advisory Council. I'm basically in favor of this proposal because I think it sends the right signal and it's totally useless because, again, you know, Axel says IPv4 is sort of broken. I'm in favor of letting it die as soon as possible and I think this contributes toward that, and the other thing is that confuses me, though, is almost every region now is going to have some sort of a transfer policy and so I see the motivations that exist for space that could be redistributed in some way being motivated either by altruistic means, return it to ARIN or return it wherever and it will go back to the IANA pool or find someone who is going to compensate me for giving up the use rights of those IP addresses for some kind of a compensation, and I'm thinking that most people are going to motivated by the dollars anyway and so that very little of this address space would find its way into the policy anyway. Thank you. Just my way of thinking.
MR. VIXIE: Can we have another remote participant.
MR. SEASTROM: [Chris Grundermann] of Time Warner speaking on his own behalf says I am opposed to the policy as it is written and I am in favor a well-written intra-RIR transfer policy of some sort. Such a policy would need to leave optional to return resources and directly address the potential issues raise bid various reasons intra-RIR transfer policies.
MR. LEIBRAND: It's difficult to have a conversation with remote participants. But I would ask, if he could clarify, does he refer to a transfer policy of direct and end user organization, ISP organization to other organization transfers, or is he referring to a structure more of like this policy of RIRs sending it back to IANA? Those are two very different things with a lot of different implications.
MR. SEASTROM: He's waiting on delay of the video. So go ahead and take another comment and I will pass back his reply.
MR. VIXIE: We're going to go to the center microphone.
MR. GEORGE: Wes George, Sprint. I'm not in favor of the text or the modified text of this proposal. I am in favor of the concept of this proposal. I think in terms of a lot of what has been said already, our view to the rest of the community in fairness and things of that nature that the legacy space is really the primary thing here. All of the space since then has been allocated based on needs and you can -- you have a much harder argument to say that part was unfair. Legacy space is something where you can say this is sort of unfair. This corrects that problem and so I would be in favor of this proposal having a mandatory return to legacy space.
MR. LEIBRAND: The current text in bullet two, the current text that we're discussing for adoption is mandatory for legacy space, optional for non-legacy space.
MR. GEORGE: I think there's more to it than that and I think it needs to add something about the size of block because there are legitimate concerns about the aggregation and I think the only other point I'll make here is I echo the concerns of the other folks here in that this conflicts with any transfer policy that is on the boards within an RIR. I think that we sort of need to take both pieces back to the drawing Board and see if we can find a way to rationalize the two against each other because otherwise, this is never going to get used.
MR. LEIBRAND: Would you support this policy if it were to explicitly exclude transfers and change the /24 return threshold to be a larger block and left it legacy mandatory non-legacy optional?
MR. GEORGE: Yes, on the second, you can clarify what you mean by explicitly prevent transfers?
MR. LEIBRAND: There's some language that this applies to this kind of return but not this kind of return. If we add language that this doesn't apply to returns as part of a transfer between two organizations within the ARIN region, that's not a return. That's just a transfer. It doesn't apply to that.
MR. GEORGE: That's a good clarification, but I think you still have a problem with whoever is going to use. Here is this block back versus, hey, who wants to buy this from me, you know, that's more the issue. This is one of those things that looks great on paper but unless you make some method to do intra-region transfers which I know opens this whole other big huge issue, but that's really the issue is we're going to make this so there's some way that address space will see another region ever or we'll put this policy together and it looks good and it will never be used.
MR. LEIBRAND: I do think you and I have a commercial mind set and a lot of us do, but there are noncommercial entities that would be uncomfortable getting money that they got from the government for space in return space. It may not be as effective as we like, but I think there will be some returns under a transfer regime.
MR. GEORGE: That's probably true, but there are a lot of the same noncommercial entities that can see other ways of benefiting from a resource that they have that will solve a problem for them.
MR. VIXIE: R.S., do we have a clarification?
MR. SEASTROM: Yes, I have a response from [Chris Grundermann]. He says he does not have that capability sorted at this time, probably RIR to RIR with IANA as a registrar of registries. That brings us down to one remaining remote question or comment.
MR. VIXIE: We'll get to it. Marty?
MR. HANNIGAN: Martin Hannigan again, just speaking for myself. I sympathize with the desire to cooperate internationally, but I would like to point out that we already extensively do cooperate and for example, the IANA to registry policy of /8s, right now, the ARIN region is take 5/8 for every time they go to the IANA and there's an agreement between the RIRs that they only take two /8s and that's a good example good international cooperation as well. The other regions do think that they are not necessarily cooperative. For example, if you are a multinational cooperation based in the United States and you have elements that could be numbered in other countries, you still have to go to ARIN to get your resources. You can't go to the RIPE region or LACNIC and ask you to provide them with addresses. As far as that goes, there's still a good balance if this policy doesn't move forward. I guess I'm not clear on when you talk about transfers and when I mentioned earlier that I thought there was a risk that you could have legacy space returned and that goes back to the IANA and back out to another RIR, that is theoretically up on an open market and be sold and there's no restriction on that. I guess I have trouble understanding how we could have a que full of requests, take some space and give it back to IANA and watch it go to another region and be sold. I think that's a serious and legitimate concern, but at a higher level. This policy doesn't encourage any returns at all. It encourages, I think, a fleece of the open market because who will want to give space back in the ARIN region if it's just going to go somewhere else and be sold anyhow?
MR. VIXIE: I want to point out that we're close to the break so if you are planning to speak on this topic, if you could queue up soon, I will be close to the microphones. Cathy?
MS. ARONSON: Cathy Aronson, ARIN AC. I have a quick comment. I worked for a multinational company and I had address space and at the time, all three of the three regions at the time so I'm not exactly sure what Marty was referring to but I lived it.
MR. VIXIE: I encourage you two to talk at the break. Leo.
MR. BICKNELL: Leo Bicknell, ARIN AC. Back in the first couple of commenters made similar comments and I wanted to make sure that the community was informed on how this might work. Several people used phrases like “address space might be stranded in IANA” and I suspect most of the folks in this room aren't experts in how the RIRs and IANA deal with each other. Putting aside for the moment the question of how address space might get returned to IANA because that is half of the problem, we're used to IANA giving out /8s. I am actually personally completely unclear if an RIR were to return a /24 to IANA if there is any policy today by which they have give it out. Is that truly stranded today and we have to change policy for them to give it out, or would they, in fact, give it out under the current system with no problem?
I see some people shaking their heads and I'm sure there are at least several people in the audience who are unclear how that works because that's not what we deal with day to day, and I think that should be clarified.
MR. VIXIE: Anybody got an authoritative answer on that? Okay.
[ Laughter ]
MR. CURRAN: Authoritative is a strong word. At present there is no clear -- this policy creates a policy that would allow all sorts of sizes to get issued by the IANA. That at present, there is no IANA RIR policy to issue anything than the current /8s. So absent of this policy, there is no way to do anything with the /24 at the IANA. Without this policy, it would be stranded.
MR. BICKNELL: That’s the clarification I wanted.
MR. VIXIE: The microphones are now closed. If you aren't in queue, please don't get in queue. I think Owen was here before the third remote participant. So Owen.
MR. DELONG: I agree with what Rob said that we're under a lot of scrutiny from people who aren't our friends about whether we can govern ourselves. However, I think that if we use that as an excuse to make bad policy, we give them the ammunition that we really can't govern ourselves. So this is bad policy as it is currently written, and I think that it's a good concept and none of us really knows what's going to happen after we run out. We really don't know what the situation's going to be. Excuse me, and I suspect for some time, the situation will be very dynamic. As such, I don't think policy can adapt fast enough to the situation to be correct. I think what we need to do is recognize that the RIR staffs do a very good job of working with each other and working globally to do what's right for all of the communities, and I think we should put the authority to determine what should be returned to IANA and what should be held locally in their hands to react to a rapidly, dynamic changing situation. The only way to make good policy here in my opinion, is to make returns optional and let the RIR staff handle what is best for their community and the global community as a whole overall. Thank you.
MR. VIXIE: Thank you, Owen.
MR. WOODCOCK: Bill Woodcock, Board. So I think we got to really clearly recognize that there's nothing needs based about this. If we're trying to do something that is needs based on the allocation out, it's going to go straight back to where it would come from here, right, ARIN, APNIC, RIPE, because the rate at which need is justified in LACNIC and AFRINIC has historically been much more conservative. I think we have to recognize that there's nothing potentially beneficial about this. It's going to take blocks and move them around between regions and ways that will not necessarily make the backbone routing folks happy. What that leads us with is a fairly straight-forward matter of public policy which is not really what this body or any of the RIRs has done very well in the past, but, you know, when it comes down to it, we'll probably be able to figure out how to do it. I guess I would just recommend that we not try to kludge our way into it backwards with a whole lot of pseudo-technical language or pseudo-needs-based language or whatever.
If the goal here is to move some space from the ARIN region to the LACNIC, AFRINIC regions because that is what seems fair, I would prefer that we come out and say exactly that and not try and clothe it in something really complex that will come out with a lot of loopholes and encourage a lot of individual parties to try to exploit those loopholes.
MR. VIXIE: Last remote participant. Microphone, thank you.
MR. SEASTROM: The last remote participant is [Ed Lewis] from [Neustar] who says he's opposed as written but if the issue is intra-RIR transfer, let's make that explicit in a proposal. He would rather have the transfer from RIR A to RIR B be done with IANA as the registry of registries and the decision to do so with the consenting RIRs and not with IANA as a dealer or decision maker.
MR. HUSTON: Geoff Huston, APNIC staff member and a co-author and I would like to offer a couple of rationales and explanations and ask for one in return from the AC, Scott. So the first two things I would like to offer in the way of clarification and explanation s that certainly my understanding of the groups is the CEO and Board level over drafting this is this was not going to preempt or usurp any sort of transfer policy within any particular region or when regions recognize other regions' transfers policy. So if for example, RIPE and ARIN have policies that allow parties to exist in the region and this policy was not meant to cut across that. So returned space really was space without a nominated home. So if you are thinking that this somehow dilutes or cuts across any transfer policy, you might consider that was not the intent.
MR. LEIBRAND: I don't think we thought it was an intent.
MR. HUSTON: Nevertheless, I'm offering this explanation and we are hearing some comments that could cut across that. The other issue about intent is data and more fundamental, and it was a statement that our view of the intent of the RIRs was to facilitate the acquiring of the address space in regions so that you can deal in your own time zone with folks who hopefully spoke your own language. It facilitated that. It was not the intent of the system to create five local fiefdoms with large barriers. It was to treat address space as a global resource for a global network of global community. And this policy tries to reflect that and at a time when we're not facing abundance anymore, when scarcity rears its ugly head to say actually, these addresses aren't locked inside little fortresses. They are still global resources. And Bill's probably right. Not much is going to come back this way. Perhaps the only stuff that will might be addresses that were originally allocated towards governmental entities who feel that they have no ability to participate in a commercial transaction but nevertheless wish to do so with a global resource. And that is the explanation of the intent of the proposers side. So what I'd like back is to understand precisely what you mean by optional because I worry an awful lot when staff and other folk are placed in the position of having to make choices and decisions because the one thing we do really bad is trying to assess the relative merits of competing need. Who is the worthier? Who should do this? Making those decisions is extremely difficult. And when you say optional, where does this rather difficult decision sit? Because I'm not sure that staff wanted it. You are really saying the returnee gets to nominate?
So I would like that clarification of what is precisely what is meant here and I think it might assist because if the ARIN community move ahead with this optional thing, then the other RIR communities are going to have to consider a global policy with that change and that is the first thing that they're going to ask and in APNIC, which I know this original version of the policy has gone through, if it comes back, it will be what precisely are we being shown now? What is the exact nature of the change?
MR: LEIBRAND: So I can't really speak to what staff will do if we say optional. They have staff reviews for that, what I can say is what our intent is or my intent. I believe what we're looking at here is a case where every /8 that has gone back that I know of to ARIN has been returned it IANA. Lea said that Stanford's was and I think all the others have been. I don't believe that ARIN has been returning smaller blocks to IANA. I think what we're looking at here is, like you say, some competing needs but I don't think there's so much competing needs of different people who are having a beauty contest over who will get the IPs. I think there -- there's competing requirements between the technical aspects of who does the reverse DNS, the aggregation aspects of do we want to give back a little blocks and get back a big one?
I believe what we're trying to do is put in the I believe very capable hands of ARIN staff to look at things on a case-by-case basis and say with the general philosophy of this is supposed to be a global pool and we want to give globally significant address chunks back to the IANA while not giving back every /24 that comes in out of swamp space, please make the right decisions to do that, to implement this policy in a manner that is consistent with our global obligations and is also consistent with what ARIN needs. And yes, I understand that I am not answering your question of how do we codify this, but what I am doing is saying I don't know how it is in other regions and in the ARIN region, we have high level of staff and Board members who are very cognizant of the of the overall things and put together very good operational procedures for how to deal with this and those can change much more easily and frequently, as needed than can be done in the policy process and I am comfortable delegating this authority to John or whoever happens to be in charge in order to -- John Curran, acting CEO of ARIN--
[ Laughter ]
[ Inaudible comment ]
And I don't believe that -- As others have said, things are going to change and if we try to set the rules now, those rules may or may not be good in two years when exhaustion hits. I think we're better off leaving some general guiding and leaving the details up to staff.
MR. HUSTON: Thank you for that. I would like to say that I think it's going to a hard sell to explain that in the other regions. You might want to think about that answer a bit more if that's the way you want to go. Thank you.
MR. CURRAN: Geoff, I have a question. Actually, I get to respond to that and I have a question. So I'm with Geoff, clearer guidance is great. Saying we're going to leave it to John does not work with me in the other regions either.
[ Laughter ]
My clarification is, you gave a wonderful discussion of how we don't want to have fiefdoms and how these resources should go to the global pool and while we have RIRs for administrative convenience, they're not to create little separate pockets and I understand half of this policy and I how it advances that. The other half of this policy, instead of leaving things in that global pool sort of slices it up and force pushing it down in a way that is completely disregards needs basis. I'm kind of wondering how do you reconcile those two halves of the policy?
MR. HUSTON: I would reconcile it in the context APNIC, at least where I am familiar with that watching their policy processes where they deliberatively delivered policies to the last /8 they get. In the last global policy round that distributed that last /8 in a very, very different way by /22s for basically doing transition. As far as I can see, the amount of space that's going to come back is going to be limited to a small class of folk who realistically are a governmental size and just cannot participate in the commercial transaction. And I suppose in my head what I see is that if this passes through the global policy, certainly I would anticipate policies inside regional registries that go, look, treat that the same as the last /8. Use it to in fact do transition rather than perpetuate needs-based allocation. Quite frankly, after exhaustion hits, the queue is so long, trying to figure out the most deserving one or two out of an endless queue is an act that I think no deity is capable of let alone we mere mortals. Thank you.
MR. VIXIE: Raul.
MR. ECHEBERRÍA: Raúl Echeberría from LACNIC. And I heard some concerns in terms of what this policy could create regarding aggregation. I would like to point out that the routing of the routing table is a problem itself that is not produced by this policy specifically. I think that the impact in the routing table will be less than some people would think because I'm convinced that the amount of legacy? perhaps)space that will be recovered is not very much, but the problem of the aggregation and the growth of the routing table is something that should be solved anyway independently of this policy. This is a concern that should not affect the decision about the policy. Other people have said that they prefer to get the same results through intra-RIR transfer policies. I doubt that we will have these kinds of policies. We don't have -- inter-RIR transfer policies, no examples of global policies so we cannot deal with that through the global policy process, and there are no other tools within the NRO for dealing with this kind of policy. The concept of coordinated policies among all the regions. There are some regions in which there are no policies of transfer in advanced discussion so I'm not sure if there will be transfer policies in other regions and Geoff has mentioned some possibilities of doing that, but I think that is a remote possibility. So I think that this is a more concrete way to deal with this issue.
There are also concerns about the size of the blocks that should be returned – the /24. Originally, the first agreement that we had in the group that drafted this proposal was to make mandatory to return every block bigger than /20. It was reduced to /24 in order to give possibility of all the regions to return space because in some regions like AFRINIC region and LACNIC region, most of the blocks that could be returned were small blocks. There many legacy locations of /24. If we expect that return to this new global pool it is also fair that we do the same, and so this is a way to permit everybody to return those addresses.
Other concerns are regarding this is a policy for transfer, for passing from one region to the other. I think that's not an objective. I have said that before. That's not an objective of this proposal. In fact, it is just speculation, because when the center pool is depleted, all the RIRs will have their own regional stocks. The stocks probably in some regions will be for making allocation for more time than others. The first RIRs in my perspective that will go back to IANA to ask for addresses from these pools will be those that will be at the same time the main returners of addresses. So I don't think that LACNIC, for example, will go to IANA asking for those addresses at least for a couple of years after the center pool is depleted. So this is not the objective of the proposal. I think that this proposal is aimed that if there enough amount of recovery to create a secondary pool, those addresses -- this pool will be available for all the regions as the current pool is today. That's the objective. Thank you.
MR. VIXIE: Thank you, Raul. We're about 15 minutes past break time, but I think that this is a really important issue. Heather, you have the last comment before the cookies.
MS. SCHILLER: I don't know how to say it politely. With regard to Geoff's comments, I find it -- the reason I feel the need to say this is because you mention you're an author so I find it hard to accept your explanation that the intent was not to create and maybe the intent wasn't to create fiefdoms with the five RIR system, but it's hard for me to accept what you're saying with regard to this policy when you also go into the working group and advocate for having five separate routes for RPKI and that more so for this policy threatens to kind of fragment how routing in the Internet and all of this stuff works and you can't have it both ways, you can't have it both ways and say we want it to be, you know, kind of all of us working together and then implement something that is very technical level can fragment how addressing works.
MR. VIXIE: Thank you, Heather. I want to say we have the last hour today is open microphone and so we can continue this discussion at that time, but it's 10:45 so John.
MR. CURRAN: I guess the question that comes up is any relevant feedback that we can get to the AC on this matter, or it is still something that we need continued discussion on, and do you want a show of hands?
MR. VIXIE: Scott, do you want a show of hands?
MR. LEIBRAND: I would like two pieces of feedback. One, I'm not quite sure how to phrase these. Basically, the two items I want to get feedback on are, where should we be along the continuum of mandatory to optional, and should we do this at all? And I'm not sure what the proper order to ask those questions in or how we want to structure them. I don't think we want to say what we support. It's hard to interpret. If you have ideas on how to give feedback for those two questions, those are the two big questions that AC could use the feedback on in revising this proposal.
MR. CURRAN: I guess one of the questions that comes up is if we know we're going to have more time to discuss this, we could hold that until subsequent to an open mic session. I don't know. I guess the question that comes up is if we specifically want to set more time aside for discussion, we don't want to have a show of hands until we're done with all of that.
MR. LEIBRAND: Are you anticipating more time to discuss 2009-3?
MR. CURRAN: That's the question. Do you want more time?
MR. SCHILLER: : In this session, you are correct? You're not saying more time six months from now?
MR. CURRAN: No. Sometime today or tomorrow, like today.
[ Inaudible comments ]
We could carve up the open mic in half and set up half for 2009-3.
MR. TEMPLIN: Pete Templin, Texlink Communications. The first agenda item slated for 11:00 a.m. is to begin this discussion.
MR. LEIBRAND: We're running ahead of schedule.
MR. TEMPLIN: We're ahead of schedule, so we could merely resume after break.
MR. CURRAN: Also true. Do people want to resume after the break? Does that make sense?
In which case, we can move to the break section. Don't get up yet, though. There are some announcements. Okay, some important announcements. Break room is next door. We have surveys that are very important. Fill out your surveys and qualify for a prize. We have your helpdesks. Now is the time to go see them. Wait, one more thing. I need my pollers in the back of the room, nothing to do with the policy proposal, but I need to a show of hands about tomorrow's-- today's SWIP of the Future BoF. If you intend to go to the SWIP of the Future BoF at 5:00 to 6:00 p.m., I need to you raise your hand now. We have a variety of size rooms. We'd like to put new one that is appropriately sized. Raise your hand. Now, people. Like, wait a second. If you think you are going to be there for the sake of the other people, raise your hand. The hotel has very fine closets available and we're trying to avoid putting you in one if you are going to be there, for the sake of the other people, raise your hand.
MR. STRATTON: 32
MR. CURRAN: We’ll resume at 11:15 AM. [Break]
MR. CURRAN: Good morning, please be seated. We're going to pick up on our discussion of global policy 2009 3, allocation of IP blocks to Regional Internet Registries. I'll invite Scott back up here to help answer questions, and I'm turning the floor over to Mr. Vixie to moderate questions from the floor.
MR. VIXIE: Thank you, John. Thank you, Scott. Since we're ahead of schedule we had a lot more time to discuss this. I wasn't aware John had extra time. I thought he was changing the order. So I'm sorry for closing down discussion earlier. Although the coffee sure tastes good. So who would like to restart the proceedings on 2009-3?
MR. LEIBRAND: I could probably start by asking a few more questions. I think we've gotten good feedback from the community on what people think about on a completely mandatory proposal, the original text I don't know if this thing will ever let me it says Lawson, could you put mine back up in a minute? I'll ask the questions anyway.
The original text, I think we've got good feedback on that. Our current revision, I think we've gotten pretty good feedback on that. I think we've gotten pretty good feedback on a completely optional system. I think there's a lot of area in the middle. There's certainly more feedback welcome on all of those things, but what I would especially like people to think about and provide feedback, if you haven't already, is on if we think that one is too hot or one is too cold, how can we get to just right?
What type of -- To Geoff and John's point, if we don't want to leave this totally up to staff, what can we give them as far as guidance as to what is globally significant and should be returned versus what is needed in the region and should be retained versus whatever other words you want to put around it. I'd love to hear more feedback on that. I've got some ideas, but this is one of those things, like John said, unless we got some good feedback, it's kind of hard to make good policy.
MR. VIXIE: Bill.
MR. DARTE: Bill Darte, ARIN AC. I'm not convinced. I understand the endpoints of how many people say I don't want anything to do with anything like this, or I would support it as written. I'd be interested in hearing or seeing how many hands go up.
MR. LEIBRAND: I definitely think we'll need a show of hands at the end. But before we get to the show of hands, I think we need to discuss them. I think those have been discussed enough to have a show of hands. I think what hasn't been discussed enough is where in the middle we want, where in the middle the community wants the AC to take this proposal, if you think that optional is too loose and mandatory is too tight, which I've heard a number of people, not everybody, but a number of people say those two things.
MR. VIXIE: Counsel.
MR. RYAN: So I'm going to speak in a policy context that's not legally required. So you can pay no attention to this particular talk, because it's a rumination on policy. One of the things that I would if I were crafting this policy from scratch and I wanted it to be globally effective that is, I didn't want it to be a symbolic policy that would look good but not actually do anything, which I think there's a significant possibility that in diplomacy you do things that are symbolically good and that have no effect if we were trying to make this an effective policy, it seems to me that the best way to do that is to leave 50 percent of the resources home to the RIR who is able to recover them.
The reason I would put it as a high number, higher than the 20 percent and make it uniform for all of the RIRs is that that would create an inducement that might actually net the global community 50 percent of something instead of largely symbolic policy for which that 50 percent will be low. I also think it would encourage an entrepreneurial spirit in ravaging unused legacy blocks in finding ways to put them to better use, in that sense, that it would actually encourage.
So that ARIN's resources, for example, would be better spent if we knew at least some of that would stay in region above the 20 percent that would be globally allocated potentially, taking I thought a very interesting point Raul raised at the end that the three larger registries might be the first in line the first time at least, and I thought that was an interesting point.
So I think we as a community have to recognize that we live in a malign world of governments from other service regions like Cuba, like other countries that don't particularly value freedom. And if we allow the dismantlement of the NGO (NRO?) system of making good policy decisions by engineers in this kind of world and turn it over to a one vote per government kind of way, that's not a good thing either. So I think we need to look carefully at the need for a global policy to address these things, because they are politically symbolic, but I think we should also strive to make them effective.
MR. VIXIE: Matt.
MR. POUNSETT: Matt Pounsett, ARIN Affilias.
SPEAKER: We miss you.
MR. POUNSETT: Sorry. Old hat. Actually, I guess what I had to say kind of fits in with what Steve was just talking about a little bit. I think essentially what we're talking about here is something where it's going to be really, really hard to be very effective. That I think my gut tells me that the amount of returned address space versus transferred address space, as we're approaching run out, is going to be really tiny by comparison to the rest of the global pool.
And so I think most of what we're going to get out of this is that political statement that we're doing everything we can, even though there isn't really much we can do. And so I think if that's the case, then I think it's important that we have a policy that's built to do that as well as possible. And this seems to me to be really, really overcomplicated for what it's attempting to do, which is shift a bunch of address space from ARIN, RIPE, and APNIC into AFRINIC and LACNIC.
That really seems to be what the goal is here. But we're going about it in this really convoluted way. And also then given the amount, what I think is probably a small amount of address space that we're talking about here, I'm not really so worried about the technical hurdles. The DNS stuff is not that hard to deal with, really. And routing I mean, I don't have a good sense of the number of the amount of deaggregation that's going to occur, but I don't feel it's going to be a serious problem anyway. But that's so I guess I'm kind of advocating cleaning this up and just making it simpler.
MR. HANNIGAN: Martin Hannigan again. So I suggested some other things in the discussion that didn't make the bullet point list that you provided here today. I still support abandoning this but I don't think that's going to happen. I think the symbolicness of this is interesting and perhaps you should consider going back to the original text and inserting the word "optional" to take care of that.
But more importantly, I think we also have the ability to allow if the goal is to transfer subsidiaries space to LACNIC and AFRINIC because they have need, they could apply directly to us or we could create a policy or a mechanism that allowed others outside of the region to apply through us for an allocation and we could maintain that address space under the standards and methods that we apply to resources here in the ARIN region.
So, one, we could assure that those resources weren't used contrary to policy in the region, since the space was originally there, and I would expect that this community would expect that that space would at least be utilized in some fashion; i.e., not sold in another region. And, two, it would allow it would pretty much allow people to make application for additional space without creating a complex global policy, which, by the way, I'm sure everyone's aware, once these things are put in place, they're very difficult to undo. And if you can undo them at all. So I think that a local mechanism, if anything, is probably better if we're going to do anything with space.
MR. VIXIE: Marla.
MS. AZINGER: Marla Azinger, Frontier Communications. I'm an engineer, and, yeah, routing is one of my major concerns about this. It proposes possible issues with filters and deaggregation. Yeah, that concerns me, which is why I'm really not too fond of the original text. That's one of the reasons. The other reason is it just doesn't support other ARIN policy. I'm not going to talk about other RIRs. It doesn't support ARIN policy for reclamation and transfers.
My first gut instinct when this first came out was abandon immediately, but I didn't say that. And I actually helped work on revising it so that at least we didn't shut down the whole global attempts to try and work together. We did put in to help make it optional. We also believe the understanding is legacies have always been handed back to IANA. And when we did rewrite the text, we made sure that legacy actually still did go back to IANA. And I do believe that is a compromise.
The other compromises that have come up which I didn't have time to think about are doing ratios and that starts to get kind of cumbersome. That makes me step back a little bit, but I would like to look at that and possibly pursue looking at those issues. But I'm not a fan of convoluted policy either. So I do support the revised text that is there, because I believe it's at least a step in saying, hey, we do want to participate. We do want to enable what others want to do and not say absolutely no. So I guess that's all I have to say. Thank you.
MR. VIXIE: Geoff.
MR. HUSTON: Geoff Huston again, one of the co authors here. Again, I'd like to clarify some intent that I've heard from Matt and from Martin Hannigan. The intent is not to go let's take some space from this RIR and give it to that RIR, nor is it to make one RIR have supplication to another RIR. That is not the intent. There is a large political intent here, yes. And it's obvious why, I would have thought, that led me to explain the political intent.
We appear to be turning on on this planet around 200 million new services on IPv4 every year right now. And across the next two years we seem to have absolutely no intent of stopping it. So whatever wall we're going to hit, we're going to hit at the fastest speed we've ever run at. And when we hit that wall, there are a lot of folks who will not have what they want, and there will be some folk who will have what they want. And the recriminations between the haves and have nots will of course happen in every single circle, obviously. We can stop it. We can't ameliorate it to any extent. Unfortunately, it's going to be a situation where demand has outstripped supply.
To some extent, though, we have said the RIR system is fair across many dimensions, including internationally. The entire system was to aid and assist folk in every part of this world to have addresses as they need. That system we would like to continue beyond exhaustion, I believe. Either that or we'll stop working for this in two years and go and do something else.
So in looking at that world, what can we do to say the right thing? To actually answer some of those criticisms that will be based on geography and politics? And the intent here was relatively simple. No, we don't expect everyone to return address space or have a large pool, nor do we expect five or six /8s or /24s to start fragmenting it. I think we all realize that's an unrealistic expectation, and transferring policies which by and large meet a lot of that redistribution demand post-exhaustion.
But, nevertheless, when we do get space back that doesn't have a home, that is returned into the system, the intent from that group was very simple. It's a common resource. It's not a resource of any particular fiefdom or any particular fortress, it's a common resource. Treat it the same way, as far as we can, the way we've always treated it. Because if our system was one that we considered to be worthy, fair, reasonable, and appropriate for the last 15 years, then perhaps it still has the attributes that are worthwhile preserving with the few bits and pieces we might get returned.
So, yes, Steve, it is largely a political statement, I believe. But I believe it's the appropriate political statement that places the RIRs into context of working on one problem together, rather than magnifying our differences and making supplications to each other: Can I have some of your space as long as I don't do this to this and treat it correctly and so on. We shouldn't be working like that. And this policy was trying to say let's create a framework that at least says the right things about our common endeavor and common intent. Thank you.
MR. VIXIE: Thank you, Geoff. Leo.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. Speaking only for myself here. In deconstructing this policy over the break, it seems to me that there are two different things in it. And particularly since it is a global policy proposal that needs to be the same across five RIRs to get past, that makes it difficult. So I'm wondering if there is a simplification that can be had. We have a problem today where if any RIR chooses to give back something smaller than a /8 to IANA, we don't have a policy to cover that situation.
We don't know how to give it back out and get it used, and that's bad. And because it is IANA giving out a resource, we need global agreement on how to do that. So while I'm not terribly wild about the particular scheme described in this policy, I absolutely see the need for that half of this policy proposal. The other half of it is under what circumstances RIRs would give back space to IANA.
And I certainly can see political value in speaking with a unified voice there. But I can also see a scenario, particularly because of differences in things like transfer policy and all that, where the five RIRs might want to make similar but slightly different statements on how that process occurs based on the differences in their regions. And so I'm kind of wondering if there isn't a global policy here to cover the distribution of space should it be returned smaller than a /8 that is operate from what could be five different RIR policies on how the RIRs will return some fraction of space to IANA.
MR. VIXIE: Scott, do you have any comments in response to that?
MR. LEIBRAND: I’ll save my comments for later.
MR. VIXIE: Jason?
MR. SCHILLER: Jason Schiller, UUNET/Verizon business. Leo, this is addressed to you. And I'm not objecting to anything that you said. On your first point, I just want to point out that a block smaller than a /8 going to IANA is not the only way addresses get in limbo in the IANA. The global policy for the distribution of the last five /8s, the way it is written it says we move from a normal allocation process into the special allocation process where we immediately give one /8 to each RIR.
And the normal allocation process stops. So once we get into the end game, once IANA runs out of their free pool and moves to only having five /8s, if address space shows up at the IANA, there's nothing they can do with it. So that is another way in which addresses can get into limbo and we do need to address that in addition to the case where smaller than /8 shows up at IANA.
MR. SCHILLER: I guess the point is we need to do something.
MR. LEIBRAND: So I think Leo's suggestion is actually quite interesting in that we could, instead of saying this is optional, say this is an area for future policy development, "this" being return of space to IANA. This is an area for future regional policy development.
And that would address Geoff's earlier concern about APNIC having to pass a policy that says it's optional for APNIC without having any policy for saying what optional means, we could then do another policy cycle to make our own policy about what to give back when or we could make a procedure. Every RIR could do their own thing on that. I think that's a very interesting possible way out of this and would love to hear more comments on that or any other mechanisms for addressing the return question.
And also separately, if anyone thinks that the redistribution mechanism proposed in this global policy is bad, I think I've heard a couple of people say that but not a whole lot. I think we should get feedback on that as well. Because if we move forward with that part of it, once we pass it, it's pretty much there. So this will be our last chance to address that. So I'd love to hear more feedback on either or both of those so we'll have more ideas.
MR. VIXIE: Raul.
MR. ECHEBARRÍA: Thank you. I think that it is an interesting proposal that has been suggested. But I think if it is difficult to touch on this point today, it would be more difficult in the future. So I don't think that this is a workable solution.
MR. SCHILLER: Jason Schiller, Verizon Business. Raul, can you qualify your statement a little bit why would it not be more workable in the future? I'm not sure I grasp the point you're trying to make.
MR. ECHEBARRÍA: What I think is there's a moment to deal with those issues. And this is something that we are now in a moment in which we can discuss those points with less pressure. In the future, with probably the center pool depleted, it would be more difficult to discuss this, I think, because there would be more interest affected with any kind of decision. Understand.
MR. LEIBRAND: Raul, I see two competing things here: one is the time factor that you're outlining; the other is the global agreement factor. Which do you think and everybody else. Which do you think is a bigger factor? Do you think the fact of having everyone agree on what to give back is a bigger deal than having to agree on it when we're up against a wall?
MR. ECHEBARRÍA: I don't see exactly what are two competing aspects. But what I'm trying to say is that in any forum, in any RIR, it will be more difficult to take these kind of decisions later. It's not just the original characteristic of it's nothing with this, specifically with this community, such that there will be much more people looking at us in the future and all of us will have more pressure because of our own interests. It's natural. I don't know. It's very natural for my understanding on this.
MR. SCHILLER: If I could just paraphrase. We will be under more scrutiny later. So it will be more difficult to come to consensus, that's your point; is that correct?
MR. ECHEBARRÍA: I think that it will be more difficult to get consensus on these points in one year or two years, yes. My answer is yes.
MR. SCHILLER: Because of increased scrutiny?
MR. ECHEBARRÍA: Yes.
MR. SCHILLER: Okay. Thank you.
MR. VIXIE: Marla.
MS. AZINGER: This is just back to Scott's original question for more comments. There's really not a lot of engineers here. So you're not going to get a lot of people speaking about routing and a lot of people always say ARIN is not supposed to be routing to you so we need to be cognizant. I said there's not a lot. I didn't say you're not here. So it's just to the comment of you like to hear a lot more, there's just not a lot of us here.
MR. HUGHES: Directly to this point, actually, it probably would be good to find out if Mr. Vegoda has any data on who subscribes to the list and what's done with the data for various announcements like new allocations, if any of that data has been surveyed it might be useful to know what actions are taken from that.
MR. LEIBRAND: I'm not sure I understand the question.
MR. HUGHES: So every time there's a new allocation assigned to a given regional, Leo sends out a list, sends out an e-mail to operators that we take actions on, sometimes it's build filters. Sometimes it's add rules to mail servers or whatever. But it might be useful if that data has been surveyed to know what actions are taken so we actually understand the workload associated with the release of, say, an e-mail that comes out every three or four days or you know a smaller announcement, larger list of filters. It's not as simple when it's in that deaggregated.
MR. VIXIE: Owen, do you mind if we continue with this?
MR. DELONG: Please.
MR. VIXIE: Leo.
MR. VEGODA: To respond to the question directly. Leo Vegoda, ICANN. I send out announcements to operators list when I make a new IPv4 allocation. I target about 13 or 14 different lists, and I think there are something like 3 to 5,000 people that read and possibly act on the e-mails.
But we haven't actually done any studies to see whether the filters change, because I know that the RIRs do that work and it seems wasteful to duplicate. So I know the RIPE NCC has deep organizing projects, and it seems they do a reasonably good job, so why copy.
MR. VIXIE: Scott, do you have more questions for Leo.
MR. LEIBRAND: No.
MR. VIXIE: Owen.
MR. DELONG: Owen DeLong. I like Leo's idea about decoupling, but I share Raul's concern about timing. If we could have processed that suggestion several months ago in time to decouple this before the policy meeting, that would have been a really good thing to do. I don't know if there is a way to put something in a globally coordinated policy that says we'd like to modify this piece later regionally. But if we could do that, that might be a way forward.
MR. LEIBRAND: From a process perspective, I think what we could do is basically say the return of space to IANA will be determined by each RIR through their own policy development process. I think we can make that change, get the global policy passed and pass a separate policy within the regions to define that process.
MR. DELONG: Yeah, I think we need to have some default defined policy in the globally coordinated policy that lasts until such is done regionally. I don't think going forward with the global policy with no definition for what gets returned is a workable solution because of resource pressures and constraints that are going to occur. Are you trying to interrupt me, David, or are you just trying to get in the queue?
The end result, I think, would be very bad if we did that. I don't know if we can say this is the default until each region passes their own policy contrary to the default. But if we can do something like that, if there's a way to do that, I think that's probably our best way forward at this point. I would recommend setting the default probably somewhere at a minimum /16 and nothing longer, or nothing smaller, to be returned. Because I think anything smaller than a 16 at least initially is not going to be globally significant. And when you start handing out 24s to RIRs, it's sort of silly in my opinion.
MR. VIXIE: Bill.
MR. DARTE: Bill Darte, ARIN AC. It seems to me I've heard an awful lot of support for this in the sense that it sends the right signal. It's the right thing to do as global stewards and all these sorts of things. But what we're chasing our tail about is all the details of what are we going to do and how is all this stuff that's going to be returned going to be divided up and how is it going to impact routing and all that.
There's been several people who suggest already that there isn't going to be enough of that stuff returned to matter. I'd rather like to hear from anybody in here that can say here's how much of that stuff's really going to be there. If it's not relevant, why are we talking about it? If it's not going to be relevant, then...
MR. DARTE: Well, I heard people say they don't think I'm one of them. I don't think there's going to be enough of it to worry about. If there are people who think there will be enough of it to worry about, how do they think that, is what I'd like to know.
MR. LEIBRAND: I have an invisible crystal ball here that says that we will probably have some space, I would guess, a /8 or so. And we may not think that's a lot now, but when we're completely out that will be globally significant and everybody will care about it.
So in my opinion, well, from our current perspective we may think that the amount of space to be returned is not so much that it matters all that much, when that's the space that's left, we're all going to care a very lot and we have to have policy for what to do about it.
MR. VIXIE: Jason.
MR. SCHILLER: I wanted to give folks a chance to address I believe it was Bill's question about whether we think there's going to be a lot of resources. And if no one else wants to address that, then I'll speak.
MR. VIXIE: When you're pondering the question: Will there be a lot? And you're looking at your own invisible crystal ball, I advise you to remember there are two ways to evaluate your uncertainty. And depending on how you evaluate it, you may change your mind about how uncertain you are.
If you think there is probably not very much so we may as well pass this proposal because it will look good symbolically and will have no operational effect anyway, so we'll get sort of the pleasant strokes in the international community for not behaving badly, you might be comfortable with uncertainty. If, on the other hand, you think there's not going to be very much and so we really don't want to pass this policy because it could only have unforeseeable effects or no effect, and you're worried about those unforeseeable effects that might give you a different way of looking at your uncertainty. Anybody want to address Bill's question about how uncertain you are or are not?
MR. CURRAN: I want to remind people today we've had more than the equivalent of a /8 returned of which somewhere between a /6 and a /8 is legacy. Returning addresses to ARIN is not unheard of, and while it's true that the dynamics going forward are different than the ones in the past, we still have space returned occasionally. So people need to consider the fact that there is going to be some, we're fairly sure of it, and so this policy, if it's passed, will be operable even if it's on a very small amount of space.
I don't think it's possible for us to say this policy won't have any effect at all. There's going to be some number of equivalent of /8s worth of space. It might only be a handful. But if we want that to stay in region, that's an important decision for the community to make. If we want to share that with the people who have the most need at the time, that's an important decision to make. And if we want to share it so that it can be used by allocation policies which aren't need based, which is what this has, for things like transition, that's also a conscious decision.
So it isn't just whether there's going to be some; it's whether we agree to give it up in this region so it can be used in another region for policies to be determined.
MR. VIXIE: Jason, you were before David. So if you'd like to
MR. SCHILLER: Jason Schiller, UUNET/Verizon Business. I wanted to address a suggestion that Owen made, which was we passed this policy. We passed it as a global policy. But we leave off the bits about how this region decides to return space. Is that a fair, accurate description?
MR. LEIBARND: Owen's suggestion that we pass it with a default that can be overridden by local policy.
MR. SCHILLER: So I wanted to put somewhere the opposite alternate suggestion, and I'm not suggesting that Owen's approach is bad or this one is better, but we might pass this policy as is, putting in a snippet of text saying that we plan to override this piece of the policy with a local policy, and we've got almost a year until this gets around to LACNIC that gives us a hard deadline to try and get our stuff in order and come to consensus on how this region wants to return space and get it implemented before it gets to LACNIC and they accept the policy. That gives us a hard deadline of slightly less than a year to do something different than the default.
MR. VIXIE: Can I ask what default you'd be comfortable with?
MR. SCHILLER: I'm not sure where I stand on that. I think that there's some middle ground between always required and optional. I think that it would be very bad if this region was to sit on unused resources. I think it would be very bad if IANA was to sit on unused resources. However, I have a lot of difficulty with returning very small blocks and then further dissecting them and giving them out in a way that will never be aggregatable. So somewhere in the middle is as definitive of an answer as I can give you.
MR. VIXIE: Okay. I just want you to know that your proposal boils down to why don't you and him go fight.
MR. SCHILLER: Well, the proposal boils down to why don't we try and fight this out in the next year and in the meantime have something that we can move forward with. And if we can't solve it in the next year, then apparently this is the best we can do.
MR. VIXIE: Sounds like you'd have a lot of latitude.
MR. SCHILLER: I'm not sure I would support that approach personally. I just wanted to offer it.
MR. VIXIE: I see. We're getting close to lunchtime. So if you're going to speak, please get in the queue. David Farmer.
MR. FARMER: David Farmer, ARIN AC. I think I liked the idea that Owen brought up and actually if we could just simply add in take the original proposed text of mandatory as the default with a local RIR policy to if a local RIR has other policy on what to return, that allows local tuning. I think I could support that.
And the RIRs, the local RIRs are each going to have to that policy that they create is going to have to be viewed in the global arena. So it's not like saying that we can do anything we want. There's still going to be a global arena that we're going to be viewed in, and I think we'll all take that seriously.
MR. VIXIE: The microphones are closed to further queue. The center.
MR. KITCHENS: Doug Kitchens, Suddenlink Communications. I like the proposal Owen's brought here and what David has just said. I want to make mention that when we look into resource returns, as we go on, I foresee these getting smaller and smaller. When we're talking about /8, yes, that's globally significant, but when we get down to /20s, /22s, /24s, I don't see that as something being globally significant.
I think it's something that could potentially get us into problems with aggregation. Now, I just have a problem with opening the floodgate or leaving the door wide open. I think we should make sure we have something in place to prevent that from occurring.
MR. VIXIE: Marty.
MR. HANNIGAN: Marty Hannigan, Bahama Telecommunications Company, Nassau. I can tell you 24s will would be relevant to me. I could probably justify them on an as needed basis more so than /20s or /22s if we get to the point of exhaustion.
I can also tell you that I'm not going to be ready for exhaustion, and it's not because we're not trying; it's just the way the things work in that part of the world. I can tell you that a large part of the Caribbean probably not be ready at exhaustion to embrace v6 technology and move forward with it. And I still have trouble understanding if there's need in the region how we would let a resource that would address a need leave the region. And I guess to provide some basis for that belief, I would say that I think changing the needs based allocation system we use today globally is inherently unfair to all of us, because not all of us some of us, because some regions will feel the pain lesser than others.
And I don't like the idea of splitting the policy and putting a hook. What I do like is providing the mechanism to return space and then being able to dictate policy to ourselves at a later date.
MR. LEIBRAND: Question for you, Marty. It seems to me that needs based is a minimum, is a necessary but not sufficient condition for deciding how to allocate a scarce resource. That is to say, once we get to exhaustion, there will be a lot of people who have a need and there will not be enough space to go around.
So I don't think preserving needs based I think all of this proposal says you've got to have a need in order to apply and then if there are more needs than there are left, then we'll get it rationed out in a certain way. I don't think we're so much abandoning needs based as trying to decide what else in addition to needs based we're going to use as criteria for how to give out the rest of the space. Do you have an opinion other than ARIN should do what's best for ARIN first and then the globe, do you have any opinion on the meta question of what the allocation mechanism should be?
MR. HANNIGAN: I'm not sure. But let me just clarify. I'm not saying we shouldn't think globally. I think we should act globally and think locally. And I really don't have a solution, to be honest with you. But I am concerned that we will have needs. And my concerns are mostly economic based. And, by the way, I fake to be an engineer once in a while. I am concerned with aggregation and deaggregation and all that. I understand the arguments. But my concerns are mostly economic based, and I think that it's very important to act globally but think locally.
MR. DURAND: Alain Durand, Comcast, just speaking as an individual. It seems to me that when we go to the exhaust point or completion point, simply talking about needs based is not going to go very far because, as you mentioned earlier, there will be more need than supply, so we have to have other criterias. When you crafted 2008 5 this is exactly where we wanted to go, saying that we need to realize that simply saying, oh, (inaudible) that is not enough. We need to promote something, which is migration to a place where we'll feel better and not always transition technologies and all of that. So I would actually support saying that whatever is recovered after this exhaustion point is placed into a bucket but is labeled for transition.
MR. VIXIE: David.
MR. WILLIAMSON: David Williamson, Tellme Networks. One quick note. /24s are being handed back to ARIN by IANA at some future date. We presently have no way to hand those out except for micro allocation, so there's already another way for us to orphan space yet another way.
But away from that, I think I'm mildly in support of the Owen or Jason suggestion that we at least partially split this into two problems, because there's the problem of how is space handed back to IANA, which appears to be the much more controversial and difficult problem within this region at least, and then there's the IANA needs a way to hand out something that's not a /8. Seems like that latter problem everyone agrees needs a solution, so we should try to move something forward in order to solve that. I kind of like Jason's suggestion that we pass this as is, with a hook that allows us to regionally override it within one year. That really puts that stick out there to force us to figure out what we want to do in this region for return fairly quickly.
Basically a short cycle to complete that. If we don't pull that off, well, then we're stuck with what at least part of this community feels is a highly disadvantageous return policy for ARIN. It would on the face of it seem relatively unfair. But we need to figure it out or take that. That seems not a bad idea at the face of it. Although, I think given that we just broached it today it's going to require further thought, at least on my part and I suspect many others.
MR. VIXIE: Aaron.
MR. HUGHES: Aaron Hughes. On the point of making a regional point on policy that decides on how we return space, et cetera, it takes us quite some time to pass policy. But this one says upon ratification we start
MR. VIXIE: Get closer to the microphone.
MR. HUGHES: This one suggests that upon ratification of this global policy we start returning to this pool immediately. Would that mean we hold off until we decide whether we're going to have a regional policy?
MR. LEIBRAND: I can't say which of the many permutations of that suggestion would apply. But what I can say is what I think we ought to do, which is Owen's original suggestion, was that the default would apply until overridden by local policy.
If the default were to apply and the policy were to be ratified by IANA or ICANN, whoever does it, it would go into effect and we would have to start returning space under the default. At such time later, whether it's within a year or not, that we override that, I believe that would be appropriate to allow us to override it when we figure it out and will maybe be under the default rules until then, and once we come up with our own rules we can do that. That's in my opinion the best implementation of the Owen/Jason suggestion.
MR. HUGHES: And the only other issue that we haven't even touched, which I'm not sure if it's applicable or not, but we haven't really discussed what the future role of all the RIRs will be as money starts to run out and if there will be resources to do something with this space once it starts being handed back to RIRs, which is probably a significant issue.
MR. VIXIE: We have a remote participant. Cathy, the queue was closed.
MS. ARONSON: I have a question about that, though.
MR. MITTLELSTAEDT: Ted Mittelstaedt from Internet Partner. Hopefully everyone understands that within a few years after the exhaustion of IPv4 resources the use of IPv6 on the Internet will reach a tipping point and everyone will be forced to switch. And within a few more years after that IPv4 will be dead. So I don't see that fragmentation of IPv4 will be a problem in the long run.
MR. LEIBRAND: I'll respond to that. Whether or not you agree that v4 is going to die, I think there is going to be a time at which v4 reclamation is going to pick up. This will be something that we address later with 2009 2. I believe it's important that we have a mechanism to return space at that time such that if one region still needs it and another region is returning it in droves, it can be reallocated.
MR. VIXIE: Cathy, you had a question.
MS. ARONSON: Cathy Aronson, ARIN AC. If one region overrides it with this policy, does it make it valid for all five regions or just that region.
MR. LEIBRAND: The idea that I have is that we have a default rule that can be locally overwritten by each RIR individually and severally maybe that's not the right term individually, such that if ARIN chooses to override the default, what we choose goes; if LACNIC decides not to override the default, then they would go with the default.
MR. SCHILLER: If I may, can I address this? So I think we have to be very clear. If the global policy is written in such a way that it has a clause that says each RIR can override clause 4.b, with a local policy I'm just inventing a clause. That's not a specific clause.
What is the clause, actually?
MS. ARONSON: It doesn't matter.
MR. LEIBRAND: The clause is part of A.
MR. SCHILLER: If it's written in such a way that there's text in there that says that each local RIR can override this clause with a local implementation and all five regions agree to it through their PDPs, then, yes, we can come forward with our own policy and change that behavior.
If that text is not in the policy and it passes as written without a clause that says it can be locally overridden and all five RIR regions agree to it through their PDP processes and we want to go and make a change to it, that is a global change and all five RIRs have to agree. So let's be very clear about what we're talking about.
MR. LEIBRAND: Does that answer your question, Cathy?
MS. ARONSON: No. Kind of. But the other observation that I have about this is so if one region overrides it, maybe the other four don't want it anymore but the only way for them to override it is to write their own policy. So we just have to be really clear, I guess.
MR. SCHILLER: If they didn't want it in the first place and we put the clause in, then they would never approve it.
MR. LEIBRAND: Yes, there could be
MS. ARONSON: Whether they want it or not may be dependent on whether all five regions do it as opposed to four.
MR. SCHILLER: Right. I understand.
MR. VIXIE: I want to say I'm going to let these last two speakers speak and then we really need to roll out to lunch. RS first and then John.
MR. SEASTROM: Actually, I apologize for lagging in phase here. Martin Levy from Hurricane Electric had one comment before you closed the microphones, and that was that this is the root of the routing issue from earlier. Just because v4 exhaustion happens does not mean that the v4 routing table will go away. Your router will have this issue for another 30 plus years.
MR. CURRAN: My only comment is that one of these remote participants indicated that this is a short term problem due to the conversion of the Internet to v6, and I guess even if all of the public facing interfaces become dual homed and then eventually become IPv6 only homed on our web mail, SSL, all the million servers, there will still be a lot of internal infrastructure with IPv4 being numbered off that for decades to come.
So there will be raining IPv4 blocks at some point with lots of space coming in because it won't be useful for global connectivity but will be coming back and will be needed by some people who have infrastructure or devices that still don't support internally IPv6. So one of the things to think about with this proposal is that it's likely that there's still a nonpublic Internet IPv4 address need even once we've successfully transitioned the public Internet to v6.
MR. VIXIE: Scott, do you have any last remarks before I ask for some guidance?
MR. LEIBRAND: Not unless you want me to say what I was just trying to say in your ear publicly.
MR. VIXIE: Please do.
MR. LEIBRAND: I was just discussing with Paul what kind of feedback we would like from the room. In my opinion there are a couple of aspects we should really get a show of hands on. One I think is do you support the general structure of this policy with regards to IANA allocating space to the RIRs out of whatever is left over the last five /8s.
And I think the second question is do you wish for the AC to put together some text along the lines of the many, many suggestions that were given for how to basically it's a do you want us to continue working on this from the perspective of what to give back to IANA? I'm not sure about that second question, how you'd phrase it. But I think there's something along those lines that we want to ask.
MR. VIXIE: Okay. Thank you, Scott. So recognizing that we are into the hour we would hour and a half we would normally be using for lunch, I'll try to make this quick. As before, ARIN not being a direct democracy, you are not voting; are you giving guidance to the AC who really needs to know how hard to work on this given that they have a workload that includes other items.
And they need to know also whether this structure is acceptable, sort of the idea of signing on to this global policy, assuming they can find ways to make certain parts of it exceptional in some way. So first show of hands, please say whether this should be continuing AC priority, or do you want them to keep working on this? So I'm going to ask a show in favor and a show of no, just drop it, we're done.
So all those in favor of please don't give up, please keep working. Okay. Thank you. If you think this is a dead end and you'd rather that the AC focus their attention on other stuff or you don't understand what the big deal is, can we please move on, you don't want to hear about this again next time. Raise your hand. Nice and high.
Okay. Thank you. Now assuming that work continues, as it seems indicated that it probably will, are you in favor of the general structure of this proposal, with the understanding that if we proposed something radically different then that means that Raul and Geoff and everybody else has to go to every RIR meeting and sort of restart the process, but are you in favor of the current structure if we can modify it in ways that more or less keep it compatible with what's been passed in other regions.
So show in favor indicates that you think this is the right track, then I'll ask for a show of opposed where you think maybe it's time to scrap this approach, keep working on it but with a different structure. Jason.
MR. SCHILLER: Jason Schiller, Verizon. Is the question do you think it's the right track to try and modify it in a way that's compatible or do you think it's possible that we could move forward in a way with modifying it that keeps it compatible, because those are two very different questions.
MR. LEIBRAND: What I was trying to ask was separating out the question of how to return space to IANA, which is very controversial and needs a lot of work. Do you support the general structure of this form of rationing or whatever you want to call it for the IANA to give out space from whatever recovered free pool exists to the RIRs? Do you support the IANA down struck portion of this? Do you support that general structure? That's what I was trying to ask.
MR. SCHILLER: So as written the IANA will assign the resources as described in this policy?
MR. LEIBRAND: Yes.
MR. VIXIE: Okay. I'm sorry. I got Scott's question wrong. Assuming we're able to divorce the question of how we as a region will return space, we're just talking about guidance to the IANA as to how they hand it out, are you okay with the proposal as written? So all those comfortable with how it reads now.
SPEAKER: I don’t think that was clear.
MR. VIXIE: Still not clear.
MR. HUGHES: Sorry, could you repeat it just one more time. I didn't understand it.
MR. VIXIE: There's two general parts to this proposal: one where the addresses are returned to IANA, which we've had some controversial discussion here today; the other where IANA is able to hand out these return spaces after potentially after aggregation for reallocation inside the regions.
So I understand Scott's second request for guidance as are you happy with the part of this proposal that talks about how ARIN excuse me, how IANA is going to allocate from this secondary pool.
MR. CURRAN: Paul, may I ask a question?
MR. VIXIE: Yes, please.
MR. CURRAN: So the only problem is it’s as compared to what and why. So the question I think that we're trying to ask is would you be in favor of the phase B portion of this proposal allocation of recovered space being done in this manner as opposed to a needs based allocation. And that makes it clear that you're in favor of doing it this way as opposed to needs based, because that's the implied manner otherwise.
MR. VIXIE: Okay. Thank you for the rescue. So all those in favor of what John said.
MR. SCHILLER: Hold, hold on. I'm confused. In favor is you like non needs based or in favor is you like needs based.
MR. CURRAN: In favor says you support an allocation based on this proposal as written here. Opposed says you prefer a needs based allocation. Someone's still asking, so we can't have a vote. Yes, Owen.
MR. DELONG: Owen DeLong, ARIN AC. This doesn't change needs based so much as much as augment it to allow IANA to allocate needs based across the RIRs with some additional criteria in chunks smaller than /8s.
MR. CURRAN: This actually changes how the IANA allocates the RIR, not how the IANA RIR is allocated to there.
MR. DELONG: Correct. But it doesn't change it from needs based to non needs based; it changes it from needs based /8s only to needs based and other criteria in smaller chunks.
MR. CURRAN: That's correct. That's why I would say rather than characterizing it I would say characterizing it as written in the proposal for strictly needs based. So the question that should be asked by Paul would be: Does the community support the allocation of recovered IP address space as written in the proposal, yes, a vote of supporting it; no is to revert to strict needs based as we have.
MR. CURRAN: Paul, ask the question as you wish.
MR. VIXIE: Oh, God. Okay.
I think this is a hairball and we're not going to get a clear question. Nevertheless, there is a proposal here for how IANA can hand out space that is different from what's in the RFC 2050. So if you are in support of this modification to the way in which IANA will hand out space, please so indicate. Thank you.
If, on the other hand, you think the current system is just fine or you think the system needs to be changed but that this is not the change that you want to see, please raise your hand. No, I'm not going to do separate questions, Owen. In terms of guidance to the AC this can be pretty choppy
MR. ECHEBARRÍA: Can I say something?
MR. VIXIE: Raul, please.
MR. ECHEBARRÍA: If you say that the
MR. VIXIE: Put your hands down.
MR. ECHEBARRÍA: Interesting, your power.
If we say that the current system, the current way in which IANA locate (inaudible) is fine, it this impossible to apply at the time in which this policy could be applied, because there will not be in the center pool enough services for satisfying 18 months of RIR needs.
I don't agree that the mechanism included in this proposal is not needs based. I think that it is a false position between the two things that are being compared.
MR. VIXIE: Scott recognizes finally this is as far as we're going to go down this track at this time. We will get some AC guidance. While I'm waiting for those numbers, I do want to say the AC has a mailing list. They also monitor the PPML. If you have a view as to how this policy ought to be changed, then either send that view to an AC member, to the AC mailing list, to the PPML, talk to us in the hallways, talk to the AC in the hallways. We will continue working on this, I suspect.
So we have an asymmetric result, which I find puzzling. So of 123 people both in the room and remote to the first question as to whether or not to keep working on this, 41 were in favor and five were against. As to the second question, do we like the current do we like this proposed allocation structure more than what we have now, eight were in favor, 28 were against. So there's no way to get any rational information on the second question. So, John.
MR. CURRAN: Thank you, Paul. Excellent job.
Yes, lunch is coming up, but I have one quick slide deck to do and then we'll do lunch.
MR. SCHILLER: John, could we get the room count for that.
MR. CURRAN: Room count was 123.
.MR. CURRAN: Okay. So I have some slides regarding a Board update on 2009-1. Yes. Okay. So this is where we are in the process, folks.
This is right out of the online. If you go online, you look it up, policy PDP, you go -- slide all the way down to the end, you'll find this diagram. It shows the Board of Trustees. When we do end up doing something as the Emergency PDP, it ends up going to the PPML, the community responds. Sometimes vocally. And the result of the comments goes to the AC which is given five days to consider and make a recommendation, abandon, rewrite, last call, merge.
The AC's review of the BoT emergency policy then goes to the BoT that looks at that and makes a decision to adopt or trash accordingly. So actually there's a process here that intimately involves the AC. Along these lines the Board made a resolution earlier today, really earlier today, and I'd like to read it.
Board resolution regarding 2009-1: The ARIN Board of Trustees resolves it will not use its emergency powers to unilaterally implement draft policy 2009-1. The Board will rely on the ARIN Advisory Council following the Policy Development Process to consider amendments to 2008-6 proposed and 2009-1 consistent with the community's discussion at the Public Policy Meeting and the Public Policy Mailing List. On June 1st, 2009, the Board will direct staff to either implement 2008-6 as written or the results of 2009-1 after the AC has followed the next stage of the Policy Development Process.
If 2008-6 is implemented without amendment, it will be interpreted to permit -- only permit transfers of IPv4 resources between parties within the ARIN region and transfers will only be permitted when first -- transfer first returns resources to ARIN before ARIN issues them to the recipient.
So this is to make clear how we'll move ahead if there's no change to 2009-1 and we end up -- there's no change to 2008-6 and we have the current text. It also makes it clear we look forward to the AC to take the discussions here and the discussions on the mailing list and provide us comments accordingly that hopefully will take what they've heard into consideration.
That's it. And, of course, because we're late for lunch, I'm going to tactfully say no questions now but there's an open mic session at the end of the day and we'd of course welcome questions. All right. Now chow time. A couple of quick slides. Almost. There we go. We have -- Advisory Council has topic tables. Again, look around. That helps encourage discussion. Go find the table that has the topics you wish to discuss. Take your valuables with you. The room is not locked. And there is no security. Either take it with you or tie it down.
Thank our sponsors one more time, Time Warner Business Class and Rackspace. We are resuming a little faster than normal. We're going to be reassuming at 1:45, okay? You don't have an hour and a half. You have one hour and 15 minutes, 1:45. Same for remote participants.
Lunch break at 12:30 p.m.)
MR. CURRAN: Good afternoon. Welcome back. Glad to see everyone's had lunch. Going to settle down. We have some presentations coming this afternoon. The first presentation that we have to deal with is the 2009_2 Depleted IPv4 Reserves.
So I'm going to call Scott up to handle that policy proposal. After I tell you some other things. SWIP of the Future BoF, those who raised your hands, thanks, we'll see you tonight at 5:00. Reminders, done. You're reminded. Keep going. And we're going to get started. Going to catch up with the agenda. Keep going. 2009-2 policy proposal, here's the history slides.
MR. KOSTERS: John, one thing about the SWIP BoF since there's so many hands raised, we're actually going to have it in here and we're going to start 15 minutes later so that people who don't want to be part of it can exit out and allow the rest of us to continue to work.
MR. CURRAN: At the end of the meeting if you don't want to be involved in SWIP of the Future run quickly to the door.
Depleted IPv4 reserves draft policy 2009-2. History: Introduced 2nd of December, 2008. It made it to the Bridgetown Barbados meeting. Draft policy was staff assessment. It was done on the 23rd of March and the current version is that version. Similar proposals in other regions. APNIC and LACNIC – it was adopted in those two regions. The AC Shepherds are Scott and Paul.
What this does is reduces the IPv4 allocation assignment consumption rate to one /20 every six months. Takes effect when ARIN has less than a /9 remaining. The restriction is lifted when the ARIN free pool reaches a /7 equivalent.
Liability risk: Counsel respectfully suggests that as policy drafted may contain potential seeds of confusion by providing for switching back and forth between current distribution policies and then back to this policy. But not a liability risk. Staff comments, issue/concerns: Should address space be reserved for this policy, is a real concern. Are we talking about separate space when we're in separate modes of allocation. And staff implementation of resource impact? Minimal. Could be done in three person months, could be readily available thereafter.
Okay. PPML discussion: 30 posts by 12 people. Two in favor, one against. I'm not sure that policy is the best we can do. It's all stick and no carrot. But I do agree with the general principles and lacking any better options so far, I must support it. Perhaps we should instead make it less desirable to get provider independent space and have anyone who needs a /20 accept a PA from their upstream. I'm not in favor of this policy.
Large ISPs, because they have large numbers of IPv4 addresses, have the possibility to cover addresses internally by canceling less profitable customer contracts by moving certain classes of customers to their choice of NAT/PAT for IPv6 and so on. So only a few posts on this, and now I'll turn it over to Scott.
MR. LEIBRAND: All right. So what are we trying to do here? As we get towards the end of the free pool, there's a real risk that a single large request at the end will result in a number of people who thought they had a little bit more time to get in their last requests not being able to.
Lack of predictability, uncertainty are generally not good for this community. There are certain people it's good for, but not us. In addition to normal large requests, exhausting the free pool, we may see a number of organizations who have legitimate requests accelerating them in order to get them in before the exhaustion. And that could cause what's commonly called a run on the bank and cause us to run out sooner than people expected and, again, back to less predictability, more uncertainty.
Some statistics. Approximately 2000 organizations got space in 2006 and 2007. 41 percent of those were less than a 20. At the other end of the spectrum, 82 organizations received very large blocks. The last /9 obviously can't meet the needs of 82 organizations getting blocks that are that large, but we can definitely provide predictability for 2,000 or more smaller organizations.
So the proposal is to add this to the NRPM. Pretty simple. A limit will be applied to all IPv4 address requests when ARIN's reserve of unallocated IPv4 address space drops below an equivalent /9. When this happens, an ISP or end user may receive up to a single /20 within a six month period. This restriction will be lifted in the event the reserve of unallocated IPv4 space increases to an equivalent /7.
Rationale, why we did it the way we did it. The /9 was put in there to kind of balance the needs of organizations requiring some space while trying to minimize the degree to which we're rationing and preventing real legitimate needs for Internet growth from being met. The six month window is there to provide about a year of predictability in terms of those 2,000 organizations or so getting their /20s. It might go up a little bit. Might be a little more or less than a year. But that's a guess as to what it will provide. The /7 exit threshold is there so that it's set not at a /8 but at a /7 such that if we do get a /8 returned and it goes into ARIN's free pool that it doesn't to counsel's concern, it doesn't have a swapping in and out of this policy.
However, at some point we expect that v4 will no longer be very useful because everybody is on v6 and we'll start to get addresses back and we don't want to do this forever. So once we get a /7 back and that's not getting sent right out in rationing, that probably means that we've got enough that we can stop playing this game and go back to normal.
MR. CURRAN: Does this mean everyone likes this or everyone doesn't like this?
MR. LEIBRAND: I think it means everyone liked lunch.
MR. VIXIE: Don't be shy. R.S.
MR. SEASTROM: I won't be shy. Rob Seastrom, ClueTrust. Back in 1973 we had an oil shortage. It was artificially induced. This IPv4 shortage is not going to be artificial induced. We tried all sorts of crazy stuff like odd/even numbered based on your license plate when you could fill up your car tank kind of stuff. Didn't make much of a difference. And neither is this. I don't support it as written.
MR. LEIBRAND: I would mention we do have other mechanisms to handle the bulk of the shortage in terms of transfer policy, for example. This is not intended to be a rationing mechanism to handle all of the problems of shortages. It is simply intended to provide some predictability at the end.
MR. SEASTROM: If you give me enough time and enough liquor, I can think up some others ways to introduce some predictability at the end, too.
MR. VIXIE: Other end.
MR. WINT: I'm Donovan Wint. I'm with Johnson & Johnson, and this is my first time here. But I'm speaking for myself. One of the observations I've garnered or gathered during this session is it appears that there is a major problem here in terms of the IPv4 depletion. But as a private technical focus, I've been reading the trades and I haven't seen much of it, I haven't seen the urgency in the technical community that this is a major issue.
And so then my concern then to ARIN and you guys is: What have we been doing to sensitize the journalistic community or the technical journalistic or journal community to say, you know, this is happening and, you know, we have a situation here. Because I'm sitting here and it's like I'm hearing the sky's falling. And if I hadn't come here, I wouldn't have known that it would be a big issue here. So this is more of a question to the panel and my observation as a private citizen.
MR. LEIBRAND: That is very good feedback. I'm sure we have a lot of people here at the dais to talk about the details, and I'm sure we'll talk about it later.
MS. HUGHES: I have a remote comment so I don't have to talk now.
MR. VIXIE: Lee.
MR. HOWARD: I'm trying to speak and I'm trying there we go. Thank you. Part of the reason I think that you don't see more coverage in the press is it's really tough to say the sky's still falling. The headline doesn't read well. So I believe that ARIN is beginning to put together a public relations message, doing certainly a lot of outreach. But there's not a whole lot of blood yet to lead with in headlines. But I think we'll be seeing more in the near future.
SPEAKER: Can someone speak to whether any of the agenda items address this in terms of giving community an update on outreach efforts?
MR. CURRAN: Yes, there will be an outreach presentation talking about our initiatives which will be tomorrow. Tomorrow we'll talk about ARIN's outreach initiatives, how we go about doing it, the person to person activity. And recognize that the letters that went out to all CEOs and executives is a key part of that, because what you really want is you want that community to at least be aware and make plans internally so that when press pick up the phone and start calling around they don't get “no, I haven't heard of it;” they get a group of people who say “yes, we just started doing our planning.”
So we need to build a pretty strong solid base before we can actually involve the classical press, because their attention span for something is relatively short and might need to make sure we have a good groundswell base of support before we actually end up in the front pages of newspapers.
MR. VIXIE: Let's go to our remote participant.
MS. HUGHES: I will start with Chris Grundemann, TW Telecom. Sorry, Chris. Speaking independently. Not ready to support or oppose this policy, but I would prefer that if we do rationing, that we simply reserve a /9 for this purpose instead of the possibility of bouncing in and out of this policy with the upper and lower thresholds proposed.
MR. LEIBRAND: So to clarify that, I think, and you can correct me if I'm wrong, I think what he's saying is we have a /9 that we ration, that's it. Anything else we get back we allocate according to the ordinary needs based allocation, whatever that means in terms of rationing. In terms of a scarcity, excuse me.
MR. VIXIE: Leo.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. I actually think that the method of going in and out of an alternative strategy here is a good one. I actually would like to see it be bigger than a /7, although I think “slash-numbers” kind of fail. I would phrase it more like we need eight /8s free before we pop back out. I'd like to see a bigger buffer. But other than that, I like the mechanism.
The problem that I have with this proposal is that having heard many other ideas from the community, I think one of the ideas that's been proposed in other forums and in policy before is the idea that the last amount of space should be used to support transition technologies to v6 rather than giving out via standard mechanism. And there's been some people working on language for that. And I actually would kind of like to see the two ideas merged. I think the right sort of triggers for simple needs based doesn't work anymore. But rather than just rationing, I think it would be far more productive to switch to a regime where we do things like only allocate space to transition technologies and other beneficial things to allow us to continue forward rather than just giving out small blocks.
MR. LEIBRAND: I think we've already done that in that we have a policy that's already been implemented that says we reserve a block, /10, to give out smaller pieces for transitional technologies. That's not considered part of the general free pool, it's considered special for transition. This is what do we do with the rest of it policy.
MR. BICKNELL: And so for instance one approach would be to take the text from that, for what you count as worthy uses, and simply put it in here instead of giving out /20s. I think this is a better criteria for going in and out of that regime than setting aside a /10.
MR. LEIBRAND: Okay.
MR. VIXIE: Alain
MR. DURAND: Alain Durand. I have a question to who crafted that policy. What is the intent when we will go to maybe only a /8 left in the pool? Is it still to allocate /20s or revise the policies and say that the maximum block we will give out will be a /24, or do you think that you will give the last /20 and then be done? Actually my question is are you trying to go to where you give smaller and smaller blocks or there will be a point where you consider, no, we are done?
MR. DURAND: I think I can answer that. Dan is actually the one that wrote it. You addressed your question to him, so if Dan wants
MR. ALEXANDER: Could you say that once more? I didn't entirely follow that.
MR. LEIBRAND: Let me paraphrase and try to answer at the same time and we'll see. You're asking whether the intent was to give out /20s until we run out of /20s or whether we're trying to have space to give out for a much longer time.
It's the former. We're going to give out /20s until we run out of them, and we're not going to do anything until we get more /20s back and then we'll give those out.
MR. DARTE: The /20s are smaller than whatever is needed.
MR. LEIBRAND: I'm sorry. That's actually true. /20s is the maximum size. So it is possible for multihomed people to get a /22 under this or if we change policy, whatever. But we'll still give out up to /20 until we run out of space, and then we'll wait for more space to come in before we give that out.
MR. ALEXANDER: Original intent was not to specify particular blocks saying you can only get /20s but simply to put a ceiling.
MR. DURAND: Thank you for the clarification. But I want to add I do support this policy, written as-is.
MR. LEIBRAND: For the remote participants, that was Dan Alexander.
MR. VIXIE: Rear microphone.
MR. BEUKER: Scott Beuker, Shaw Communications. I vehemently oppose this policy proposal. All I see here is a blatant attempt to skew what was a fair and balanced system to favor small ISPs. We all come up to ARIN for a year's supply of IPs. But what you're saying here is in the end game the large ISPs have to get cut off early so that the small ISPs can be cut off late. What's the point?
If you wanted to modify this in a way that I could support it, it would be based on percentage. If you come to ARIN and you can justify a /whatever, you get 20 percent of that /whatever. You justify a /20, you only get or at 25 percent you only get a /22 and then /13 gets a /15. That works, that's fair. And that's slowly cutting people off. This is a blatant attempt to skew everything in the favor of little ISPs.
MR. LEIBRAND: I think you're making an assumption there that may not be correct. The author of this proposal is Dan Alexander.
MR. BEUKER: I realized that. I just figured it out a moment ago. And all I can say is, Dan, I don't know what you're thinking.
MR. ALEXANDER: So this Dan, I'm on the Advisory Council and I'm also with Comcast Cable. So it's pretty clear that we're one of the largest consumers of IP space out there and this does seem to shoot us in the foot, to your point. The thinking behind it and the reasoning for it was when we reach this point in the game, it doesn't matter if we're only getting 80, 50, 20 percent of that allocation.
An ISP the size of us, we've already hit the wall. So there's no question out there that the larger ISPs are going to hit the wall first. They're going to hit it the hardest and the only shot they have is to go and implement v6. This provides a means of predictability so one single organization doesn't deplete that remaining pool in a time frame that may catch everybody off guard.
And I know that the common reply to that is: well, if you're not ready by then, you haven't been planning appropriately. But when we're talking about being caught off guard by one or two quarters in a business cycle, that can have a dramatic impact on certain people's business planning. So to provide so even though this may be detrimental to the larger ISPs, the community as a whole is provided a certain window of predictability that everyone can wrap their plans around.
MR. BEUKER: Can I respond to that?
MR. VIXIE: Sure.
MR. BEUKER: I think your intent is good, but the rationale here, it's a mistake. Who it's good for is everybody who would actually need a /20 and smaller. Everybody bigger, you can classify yourself as an extra large ISP. I'm going to classify myself as a medium sized ISP. For you it doesn't make any difference it's the crumbs off the loaf of bread, you don't care where it ends up. It's not going to buy you any time. But if I'm 11 months or 12 months after my last allocation and my turn comes up to go to ARIN for more address space and, oh, I get cut off because of this policy and instead somebody else is getting all that space and I'm left to suffer, then as a medium sized ISP, I'm the one who bears the brunt of this proposal.
So it's easy for you to propose it and it's easy for a bunch of small ISPs to support it, but everybody else in between, those slightly larger than /… who are going in for, let's say, /20s to /14s each year, we suffer. We're going to get hit by this pretty hard. And that predictability that you talk about, that's gone. Now I mean, right now we can go to websites and see a prediction model and figure out, okay, we've got two, three and a half years. You know, what's giving me this unpredictability is all these crazy policy proposals that aim to dramatically change things.
So my policy proposal that I'll bring to the next meeting is to leave everything alone so we actually have some real predictability. That's all I want.
MR. VIXIE: Thank you. David.
MR. FARMER: To respond to that real quick. David Farmer, University of Minnesota and ARIN AC. Just to respond, you said you're a medium ISP. Well, what happens if there's still going to be a spot in the line problem if we don't have this.
So you're the medium, five other medium ISPs were in the line before you and exhausted it right in front of you. How is that fair? This is trying to say, okay, we're going to get to a point where we're going to try to make sure everybody gets a little bit of the crumbs out of the bottom of the bag. Or another way I like to put it is we're going to hit the wall, maybe we can pop an airbag. It's not going to keep us from hitting the wall but we might not hit it quite as hard as we might otherwise. But there's still going to be an accident and it's still going to be bloody and all of that.
MR. BEUKER: Can I respond again?
MR. VIXIE: Please.
MR. BEUKER: The system is fair right now because everybody has an equal chance to be the person who hits the wall. To be that ISP or that business that when they go to get an application, it may be their last or they might get another one in a year.
These kinds of proposals skew the odds. That's all they do. They change it so if you're small the odds are you'll be able to go back later and further into the future. And if you're large, the odds are exhaustion comes sooner for you. Fair is for everybody to have equal odds and for everybody to run out as close to the same point in time as is mathematically possible. It's simple math.
MR. VIXIE: David.
MR. FARMER: As was said yesterday, there are multiple definitions of what's fair. And we've got to find one we can all agree with. Because I won't disagree that what you're saying isn't fair. But I think this has its own fairness as well. And there isn't one of the things learned a long time ago, fair is from your perspective. And I'm going to leave it at that.
MR. VIXIE: Bill, before we do that I want to remind folks of what David Farmer was just referring to. Jean Camp's presentation, she talked about a number of different fairness models, and they were indeed all fairness models. They were properly called that. So predictability is going to be like that, too. If you are a large ISP, you can more easily predict the time that you're not going to be able to get another /10, than if you're a small ISP, it's hard to predict exactly when you won't be able to get your next /22.
So it's not, to me, a cut and dried proposition as to which one of these leads to the most fairness. That's all. We have three remote participant questions. Stacy, can you give us two of them?
MS. HUGHES: Yes. The first is from Ted Mittelstaedt. He says: I am generally in favor of this policy with some further tweaking of the numbers and cut off point, and here is why: It's pretty clear that any large ISP must move to IPv6 since the sheer size of their numbering needs means that IPv4 is a no op for them once IPv4 run out has been reached.
What isn't clear is what the small ISPs will need. My gut feel is that they will in fact wish to obtain IPv4 for much longer than the community will, frankly, want them to. Immediately after IPv4 run out it would be a hardship for them to deny them allocations. Further off than that, I don't know. But I think we need to recognize that small ISPs will want IPv4 post run out.
MR. VIXIE: One more.
MS. HUGHES: Yes, one more. This is from Joe Maimon, CHL: For Leo, do you believe possible or likely that any sort of rationing will probably result in receivers of the smaller portions using the space for transition or similar high value, bigger bang for the buck usages?
MR. BICKNELL: Leo Bicknell. Yes, some would. I have no idea if I can quantify off the top of my head a lot or a little, though.
MR. VIXIE: Bill.
MR. DARTE: Bill Darte, ARIN AC. I'm generally in favor of this, but not because of the mechanisms or even the fairness. I think that it goes to the other gentleman's question of this is just one more notification that the future is different than it is now. And it's sort of that next ratchet click toward that future that everybody's going to have to determine a way forward from. So that's why I think it's valuable.
MR. VIXIE: Thank you, Bill. Far left.
MR. MILLER: Joe Miller with United Telephone. I'd like to respond to two comments that were made previously. First to this gentleman over here. I'm with a small ISP and I agree that this policy unfairly advantages us. And I generally support it, but I would support it more if there were a statistical model or something that I would perceive as more fair.
And in response to Ted's comment from online, I think that we're, as small ISPs I can't speak for all of us, but the ones I'm aware of are very nimble and very capable to switch to IPv6 rapidly. The run out is not going to impact us as much as it's going to impact the big guys, it really isn't.
MR. VIXIE: I have a follow up question for that. You say you could switch to v6 and I think I know what you mean. If you're small, you don't have as much to renumber. But if other people haven't switched to v6 yet.
MR. MILLER: That's the problem. And I kind of want to help facilitate the big guy switching to IPv6 so that we have a v6 provider, a true one, not a tunnel. A true v6 provider.
MR. VIXIE: Thank you. Aaron.
MR. HUGHES: Aaron Hughes. So for the most part I think I agree with Scott's perception or opinions about this and think maybe as an alternative, rather than limiting the size of prefix we might consider something like what you can use in the next 90 days since at our current run rate we're going through about a /8 every 90 days.
The assumption that we all probably have is that when we only have a /8 of space it's not going to go away in 90 days, either it will go instantly or it will last forever and we'll already be using v6 and that free pool will just be growing. But if you look at a time period, then you'll get the appropriate sized space for that next 90 days regardless of the size of requests you're making and will still have predictability for the run out.
MR. VIXIE: Thank you. Remote participant.
MS. HUGHES: Jo Rhett, Silicon Valley Colocation. The last speaker and, Jo, if you could let me know which last speaker we're talking about because I'm back in the queue. The last speaker misses the point. 20 percent of large ISPs' need will be greater than all of the small ISPs' needs at 100 percent. If five of the large ISPs get 20 percent each of the total remaining space, then all smaller ISPs are dead in the water instantly.
I have two more remote participants as well.
MR. VIXIE: Wow. Okay. Rear microphone.
MR. BEUKER: Scott Beuker, Shaw Communications. I want to respond to a few of the responses. First, David, that there are different perceptions of fair. Yeah, I agree with that and I get that. I guess my point when it comes to fairness is if you don't have a better system, just leave the current system in place until you've got a better system. At best, you could make an argument that this is just shuffling the deck and redealing for everybody. And as far as the remote participant's comments… I'd like to speak to the comment at the same time that large ISPs have better predictability about run out than small ISPs do.
Honestly, all I can say is the people who are saying these things need to do the math. Every time any ISP of any size goes to ARIN, they go for a one year supply. So when it comes to your prediction model of when you're going to run out of IPs, I don't know about you guys, but mine is okay, I'm good for another year. Beyond that, it's all assumptions.
I don't get any more than any other ISP smaller than I do. I don't get a year and two months. I don't get two years and you don't get six months. We all get a year. So the predictability for exhaustion is the same for all us. 20 percent, whether you're large or small, I think people need to drop this idea that big ISPs are evil and you should always favor the little ISPs because there's something inherently better about them.
Once again, totally incorrect. What do we do when we get ISPs… let's say I got a /8 tomorrow. What am I going to do with it? I'm not going to sit on it and ping flood people. I'm going to hand it out to mom and dad and all these home users. That's where it goes. It just turns around and it goes out to the same people that you would give it to.
The difference is we do it on a larger, and I could make the argument, more efficient scale. But let's just not talk about that. Let's just agree that we're not evil. All we do is we turn it around and give it to the people who access your services the same way your customers access the Internet, so please don't treat us like we're evil and that we need to be prevented from stealing the Internet from you.
That's not the case. We're using it for the same reasons you are.
And, like I said, fair is to leave everything the way it is. If it was fair for the last 10, 15 years, it's fair now. I don't see why it suddenly needs to be changed. Thanks.
MR. VIXIE: Heather, you're next. But I just want to say I'm in support of one element of those comments and that is that every packet has at least two endpoints. And being able to grow one set of endpoints and not the others does not really advantage the first set of endpoints. So when we look at fairness, we should be looking at it systemically. And I think in some cases that's going to mean that what's best for the network as a whole is not going to be what's best for some particular class of participant. And that's… you say do the math, that's what the math tells me. Heather?
MS. SCHILLER: So he said a lot of the same things I wanted to say, which is kind of comes down to what do you think large providers are doing with this address space that's so different than what small providers are doing? We're handing it out to many of the same people that a lot of small providers are our customers. So they would get address space from us, too.
I don't see why this late in the game we're sort of deciding that there's going to be a special class treated so very differently and that we're not like you said, we're not doing anything evil with the address space and we're serving the needs of the community just as we did for the last 15 years. Large provider, small providers.
MR. LEIBRAND: Heather, I have a question for you. Does the last /9, if you can continue getting your normal allocations, does your portion of the last /9 help you in any way, or, as Dan said, by the time when we get to that point are you pretty much over and it doesn't matter whether you get space or not?
MS. SCHILLER: I'm going to do something maybe I'm not entirely sure I'm authorized to do. But sort of because so we have three main business units: Verizon Business, Verizon Telecom, Verizon Wireless. And so kind of speaking on the whole for all of them, you know, for the most part their infrastructure's built out. At this point it's largely addressing for customer base.
And so that's what I'm trying to say. What we would use the address space is to serve the community who are our customers. So it's not like we're building something new that should be built in v6 more than v4. And so I think that what sort of kind of concerns me is that the /20 seems arbitrary. And it seems arbitrary based on kind of like what Scott was saying before, that it's arbitrary to providers.
Smaller providers who regularly make smaller allocations benefit because the /20 will last them longer. We have customers that we allocate /20s to. I get a /20 and I have to wait six months before I can make another allocation to my next customer? How does that work? It's just not sustainable. None of it is sustainable, which is why we're having this discussion.
MR. VIXIE: Thank you, Heather. I want to say we have eight people queued plus two remote participants. If you intend to speak on this topic, if you could get in queue. Plus Owen. Unfortunately, I didn't see where you are in the queue.
MR. DELONG: Last.
MR. VIXIE: Okay. Far left.
MR. KARGEL: Kevin Kargel with Polar Communications. We are a small ISP up in North Dakota. I wanted to respond to a couple of things in terms of what Scott was saying. I understand your concern about being viewed as evil, but if you ever really want to do that walk into a roomful of ISPs and admit you're a telephone company.
Then you'll hear the word evil. Also as to the fairness of this proposal, which I obviously do support because it does benefit the small ISP, I think that the fairness is offset somewhat by the compressibility by a large pool of IP addresses. You can do a lot of things with efficiency when you have a pool of millions of IP addresses that you can't do as easily when you have tens of thousands. And that's what I have to say. Thank you.
MR. VIXIE: Okay. How many remote participants?
MS. HUGHES: Two.
MR. VIXIE: Can we have one of them, please.
MS. HUGHES: Martin Levy, Hurricane Electric. Question for ARIN counsel: Have you addressed the process of saying no to the allocation request and having a resulting legal action? Will this proposal stand up within a court of law? Will it come down to first come, first served immaterial to its size, company, ISP request, et cetera?
SPEAKER: Counsel has escaped the room.
MS. HUGHES: And Martin has escaped, too.
MR. VIXIE: Take the next remote participant.
MR. LEIBRAND: For the remote people, counsel was not in the room. So we’ll defer that.
MS. HUGHES: Ted Mittelstaedt. Another comment, you can put this at the end. Oops. -- We simply cannot have everyone run out at the same time due to how the Internet is structured. Small ISPs are utterly dependent on large ones for connectivity. If all run out at the same time, it will be a mere inconvenience for large ISPs that aren't ready to route v6, but it will be a death knell for the small customers if the small customers cannot obtain v6 routing from large suppliers. We need the large ISPs to fully route v6 first.
MR. VIXIE: Center.
MR. TEMPLIN: Pete Templin, Texlink Communications. Refresh my memory: How many v4 requests per six months do we see currently? Ballpark number?
MR. VIXIE: Leslie.
MR. LEIBRAND: This is what I know. Somebody else will have to speak to the specific question if it's not answered by the slide.
SPEAKER: That's two years. You can say 500, just rough number, looking at that.
MR. TEMPLIN: So based on this proposal, the rationing would only last… it would last for no more than two years' worth, because ballpark equivalent.
MR. LEIBRAND: That's what the bullet point is trying to say, yes.
MR. TEMPLIN: Between /9 and /20 but potentially shorter than that since folks would… some folks would be requesting 21s through 24s. Okay.
MR. VIXIE: Counsel is back in the room so can we have the previous question again, please.
MS. HUGHES: Yes. Sorry. Let me scroll. The question is from Martin Levy from Hurricane Electric: Has ARIN counsel addressed the process of saying no to an allocation request and having a resulting legal action? Will this proposal stand up within a court of law? Will it come down to first come, first served immaterial of size/company/ISP/request, et cetera?
MR. RYAN: So this goes fundamentally to a legal lesson. We are a standard setting body that allocates a scarce resource. In doing so, we have to do it in ways that do not violate antitrust conceptions and laws. So if a bunch of you in a snicker said let's do this so that we would disadvantage the large companies as an intentional strategy versus we have a run out problem and we have to allocate the last of something, your intent does matter.
Clearly, a rule that limits the ability of large organizations to obtain all that they need which favors small companies getting perhaps 100 percent of what they need does have an antitrust implication. However, given the circumstances that it's about the end of time, given the circumstances that the rule is facially neutral, given that the supposition that the rule would be fairly drawn up and fairly applied, I think that in this instance, you know, it could survive scrutiny.
I think I indicated there's a modest level of legal risk whenever you change allocation models like this and you start to do things like this. So a lawsuit might very well examine the debate that we had. Might look at the minutes of that to see what the intent of the parties was in creating this rule. As it stands right now, I think we can make reasonable rules for the end of time that have to make hard choices about where we allocate scarce resources. Does that help?
MS. HUGHES: Yes, thank you.
MR. VIXIE: Woody wants to follow up on this question.
MR. WOODCOCK: To Steve: A lot of regulatory regimes have a concept of enabling future market entrants; that is, reserving enough of a scarce resource to not preclude the creation of a competing entity tomorrow or next year. Can you address that in our context?
MR. RYAN: I don't think that applies to this policy, because literally at the time of run out, you know, as you're giving the last of these away, if you have a facially neutral policy that allocates fairly amongst all comers, you will, by nature, take both established businesses and non-established businesses and treat them in the same way. I think if… I think at the current time we don't have a problem with any doctrine like that, though, in my judgment, we don't have that problem.
MR. VIXIE: Okay.
MR. LEIBRAND: Leslie has a point of information
MS. NOBILE: One correction. Leslie Nobile from ARIN. The number of requests in six months is actually more like 1,200. We're getting about 2,400 requests per year for v4 space. So about 1,200, not 500.
MR. LEIBRAND: So is that based on updated 2008 information, I assume?
MS. NOBILE: That was last year's information, actually. End of 2008.
MR. LEIBRAND: So this slide was 2006 and 7, and that's updated since then.
MS. NOBILE: Right.
MR. LEIBRAND: Thank you.
MR. VIXIE: Lea.
MS. ROBERTS: Lea Roberts, Stanford University and ARIN Advisory Council. I think that I support this policy, and I believe that the intent has to do not so much about disadvantaging big ISPs or middle ISPs, or any of those; I think the idea is to have some resources left for those people who when they bring up IPv6 still need some v4 to do dual stack and talk to the IPv4 Internet. Let's not forget that's going to have to be working for a long time yet.
MR. VIXIE: Matt.
MR. POUNSETT: Matt Pounsett, Afilias. I don't support this proposal as written. I like the idea, I don't like the mechanism. The problem, this seems to me, to solve, as you're referring back, I forget who it was now, talking about fairness between large and small ISPs, to take the hypothetical example that everyone's requested their year of addresses and by some coincidence they're all going to run out at the same time, the first ISP that gets in there at the end and requests and gets the last /10 is going to have their next year of addresses and nobody else will.
And that's not fair to the small ISPs. It's not even fair to the other large ISPs. It's not fair to anybody. And this kind of tries to, seems to me, tries to solve that. The problem, I think, is that actual rationing doesn't solve that problem very well. The one element of this that I like that does approach solving that problem is shortening the request period. And I think that's a better approach in and of itself than trying to say, well, you only get so much of your request.
I think the better thing to do is to say you get a shorter time you get a shorter request period, not only part of what you need. And in that way, when people when we get down to only having a /8, I don't know, or /7 or something like that left, if we then start saying, okay, now we only get six months, and then later if people only get three months, right, and then that creates a much better predictability to the end and everyone gets everything they need right up until that end.
And still acts as a good signal that the end is near. I think that would probably be a better way to deal with this, even though even though it would increase some of the administrative burden, I think it deals with all these other issues of fairness and run out and stuff much better.
MR. VIXIE: Thank you, Matt. Bill.
MR. DARTE: Bill Darte, ARIN AC. I'm just making comment again that this I think the motivation for this policy was predictability and that the /20, the number wasn't arbitrary; it was to try to have basically a window of time that would be predictable for the organizations that need /20s or smaller.
MR. VIXIE: Owen.
MR. DELONG: Owen DeLong, ARIN AC. I support the policy as written. I think that large organizations are going to hit the wall no matter what. I think medium sized organizations are going to hit the wall no matter what. We're really talking about the last donut in the tray in the office building. And I've noticed this really interesting phenomenon in offices where nobody takes the last donut. Instead, the first person who comes up and sees there's only one donut left cuts it in half. The next person who comes up takes a quarter of the donut. The next person who comes up takes an eighth of the donut and the remaining of the eighth of the donut sits there and rots all day.
So I don't think that's the best allocation policy necessarily, but I do think that choosing some appropriate sized chunk to let the last donut be divided up among a maximum number of useful people within the ARIN region or maximum useful number of organizations is probably a reasonable thing to do. And I think that /20 is probably a reasonable place to set that boundary. It means a large percentage of people that apply for their last allocation will get a /20 as their last allocation and probably won't be able to come back for another one because it will probably be all gone after that.
And if we don't do that, then evil or not, and I don't think large ISPs are evil. But I do think large ISPs are large. And when we are down to only a /9 left on the tray, if somebody comes up and gets a /10, they got half the donut. If they come up and get approved for a /8, then they got all the donut and we're /9 in the hole.
So we need to do something different at that point in the end game and nobody's going to get everything they want unless what they want is small. All that's left is a small piece.
MR. VIXIE: Thank you, Owen. Stacy, any remotes?
MS. HUGHES: Yes. Jo Rhett, SV Colo. This isn't about evil. This isn't an emotional topic. This is about very large grabs of the remaining space versus small grabs. This is integer math, not ethics.
MR. VIXIE: Is that it for the remotes?
MS. HUGHES: Yes. There are voting suggestions, but that's it.
MR. VIXIE: Okay. Left hand microphone.
MR. PORTER: Jeremy Porter with Corenap. Speaking as both a small ISP and former AC member, you know, when we run out of address space, any provider that is not providing IPv6 to their customer will not be deploying new services. They will be going out of business. So whether or not you can get that last allocation is merely a matter whether you should be planning today or should you have started six months ago.
I do support this policy because it will allow things for customers that have technical requirements where they cannot use anything other than IPv4 and ISPs will be able to assign that for their needs, whereas large customers that… or large ISPs that are assigning, receiving /8s or other large allocations are assigning essentially to end users single ISPs where they can be deploying translation software inside their networks, they can be deploying those IPv6 to their end customers and basically proxying any IPv4 that's needed because those end customers have a much lower need for IPv4 because of the homogenous nature of those networks.
Not all ISPs are homogenous, but if there's some modification to this proposal, shortening the allocation time, I would also support that as it gives a better window and more data points. It does, of course, increase staff load and increase cost. So that's definitely something to consider.
MR. VIXIE: Thank you. Mr. Farmer.
MR. FARMER: David Farmer, ARIN AC. So on the AC we thought about and looked at several other mechanisms on this. And I just want to say there were several other issues. One of the things I hear… some issues about fairness. Would it be more fair if everybody feels some pain so that we had some sort of ratcheting down so even the small guy feels some pain? If that's something you're interested in, the only problem we ran into with that is you now end up with an algorithm that we have to put into the policy and we'll all nitpick that algorithm to death.
And so the reason we went with the /20 as a ceiling is it's simple, concise. Is it perfect? It's nowhere near perfect. But it's a line in the sand. And the reason we picked that particular line in the sand, that is very similar to what the policies in the other two RIRs that have passed this policy. They're allocating maximum /20s as well. So that's why we picked that particular line in the sand is to not have a great amount of difference between the different RIRs in this endgame piece.
There's already some differences. We're not doing they're all doing it at the last /8. We're giving us a little bit beyond that. We're making it the last /9. And I just really -- the advantage of this policy over some of the alternatives is the simplicity. Because we will bog down.
MR. LEIBRAND: Witness 2008-2.
MR. VIXIE: I would hate to have it be that an argument in favor of a proposal is that the AC could not deal with the more complicated one that would do a better job.
MR. LEIBRAND: The argument against a more complicated proposal is that everyone can find something wrong with it.
MR. VIXIE: Yeah.
MR. BEUKER: Scott Beuker, Shaw Communications. Speaking to what David just said, and I refer you to what I believe Matt said earlier, that you just switch this, I don't see a policy that changes one year allocations to, let's say, three month allocations all that complicated. It's really quite simple to me, but it is a lot more fair. That's really all I'm advocating here in terms of an alternative to this policy proposal. I don't feel I can speak to the numerous people who brought up that a big ISP needs to be cut off from IPv4 so that they switch to IPv6 so that they can later switch to IPv6.
The funny thing about a policy proposal like this is that it makes you kind of aware of the people in the room who haven't done their research on IPv6. I'll suggest from my personal point of view that when you finish deploying IPv4 and when you begin deploying IPv6 should have absolutely nothing to do with each other. You should begin deploying IPv6 ASAP. That's what we're doing as a big ISP and that's what every other big ISP that I've talked to are doing. And we're going to make IPv4 last as long as we have to, the same as everybody else in the room. If there are IPv4 resources out on the Internet that our customers want access to, we're going to try to get it to them. But that doesn't mean you have any more of a need than we do.
And as we all should well know, deploying IPv6 is not going to eliminate that need for us. We're interdependent on everybody else on the Internet just like you are.
MR. VIXIE: Leo, the microphones were closed.
MR. BICKNELL: Yes, I'm encouraging my RIPE colleagues to stand up and they won't. RIPE has a policy 2009-03 that may be of interest as they talk about how this could go into languages. It changes the threshold from 12 months to six months to three months and has language. So RIPE has an example policy.
MR. VIXIE: Thank you for that point of information. Last question. Rear microphone.
MR. KITCHENS: Doug Kitchens, Suddenlink Communications. I want to echo the sentiments of the last speaker we had here as well as voicing my support for what Aaron and Matt stated and what was just spoken by Leo in just decreasing the threshold. I can see several potential holes in the proposal as written. Though I can see the value in the intent.
I could go through this /20 in one to three weeks, depending on the allocation requests that were coming in to me. But at the same time I would probably be trying to reserve more of my space by telling these people to go directly to ARIN for your request rather than coming to me. And that would… it would skew your trending results as well.
So just a few things to keep in mind here.
MR. VIXIE: Thank you. Scott, can you not only wrap up but decide what you would like input on for the AC.
MR. LEIBRAND: My own personal opinion is that this is a simple yes or no, do you support this or not. If anyone, especially other AC members, thinks we need other input, please provide it. But, in my opinion, if the answer to this one is no, then anything, any revisions should not be revisions; they should be new policy.
MR. VIXIE: Thank you, Scott. We come once again to that time that we're going to ask for your input with the reminder once again, you are not voting; you are giving input to an AC who also has to use their experience, their education and their conscience to decide what to do next.
So with regard to the policy 2009-2 as written, and as frozen 10 days before this meeting, please raise your hand if you are in support of that proposal as written. Higher. Thank you. And now the opposing view, if you think that this is a bad idea and that you're not ready to support it, you hope it doesn't go forward in this form, please raise your hand. Okay. Thank you.
MR. ALEXANDER: Paul, I wonder if you could ask one -- this is Dan, ARIN AC -- if you could ask one follow up question: Simply, do people think that this community needs a potential end state policy like this or would they prefer to run as is with no change?
MR. VIXIE: So we do have some soft landing language in terms of reservation for v6 gateway functions and so forth. So do you want to you want to ask…?
MR. ALEXANDER: Do we need continued work on an end state or should we…?
MR. VIXIE: Mr. Stratton, we're not done. I've been asked to pose an additional question at this time, which is okay. Right now we're going to hit the wall, however soft or hard, we're going to hit the wall. We've got some proposals that are in place to soften that impact.
Should the AC continue working in this general policy area trying to find different ways to soften the landing or not? Should we just hit the wall the way we're going to hit the wall? So I'm going to ask you to raise your hand one of two times. Either please save us, please continue trying to work in this area; and then I'll ask, no, we're fine the way we are, we like the predictability of no more policy in this area.
If you'd like more policy developed in this area, please raise your hand now. Higher. Thank you. If, on the other hand, you like things the way they are, you consider it predictable, you're able to sort of base business decisions on the policies we have and you don't want to have to keep recalibrating, you'd like the AC to think of other things to work on that is not like this, please raise your hand now.
Okay. Thank you. So we'll wait for the numbers. Alain?
MR. DURAND: While you wait for the numbers, I would like to bring a clarification on a position that was shown by raising my hand for crafting more policies. I think it's okay to craft more policies for the very end, but I will oppose strongly changing policies for before we reach the very end.
MR. VIXIE: Thank you for clarifying that. While we wait for the numbers to come forward, I just want to say I kind of agree that you should be deploying v6 now. The people who are dual stack, when all of this comes into effect, are going to be laughing at the people who are not dual stack when we get to the very end.
Maybe that doesn't bother you. But maybe another way to put that is if your business relies on sort of predictable costs and controlled costs, you will be happier if you're dual stack when everybody else runs out. Just because when v6 only networks start appearing elsewhere from people who are not as well, as well prepared as you, they'll be able to reach your customers.
So we have 119 people combined in the room and remote participants. Support for 2009-2 as written: 17 in favor. 24 against. As to the secondary question: Should the AC continue to work on policy in this area. 22 say yes. 16 say no. Thank you.
MR. CURRAN: Break is coming up but it's not yet. So we've got to hold out here. Everyone get their second wind. We're going to get one more presentation in, because we want to try to catch up a little bit of time on the schedule.
MR. CURRAN: So next up is Bobby Flaim who is going to come up and do a presentation on the ARIN Working Group update. Bobby.
MR. FLAIM: I'm Bobby Flaim. I work with the FBI and I'm here to talk to you about the newly formed ARIN Government Working Group that was actually just formed a couple of months ago in coordination with ARIN and also some government agencies. We mentioned it very briefly yesterday when we got up to make a few comments about the WHOIS policy. I know in the forum some were talking about it. John gave an excellent explanation of what it is, but to go a little bit further about what it is and why it was formed and what we're about and what our hopes and aspirations are and our mission.
Just so you know, ARIN Working Group -- Government Working Group, a little bit of a misnomer because it's not purely government. We'll probably change our name because we're more of a cooperation working group. Had its genesis at RIPE NCC through Axel and Paul Rendek, and we saw it and thought it was a good idea to kind of get governments, some other agencies more involved in what ARIN does and let the governments know what they do in a very informed and public manner. And as you can see, RIPE already has one that's been in existence for a couple of years. We here at ARIN started one just this year. LACNIC and APNIC are planning to also do cooperation working groups this year.
And AFRINIC, I'm not sure. I'm sure they will do one as well. I just know in talking to Raul and Paul Rendek and some of our partners in Australia that they're planning that, too. So it's kind of not something unique to ARIN. Actually, all of the RIRs are doing it. And I think it's something that's very effective and ARIN and the government saw a good way to kind of meet all of our needs and kind of get governments and other partners more involved and realize the importance of ARIN and what it does.
This is our mission statement. Like I said, we're very embryonic and hoping to refine it. But this is basically it. To provide a forum for learning and discussing matters relating to ARIN with focus on cooperation between the public and private sector while adhering to all ARIN policies and procedures. Just so everyone knows, this is a group that is planning to work within ARIN, not without it. I think a lot of times when people hear "government," they think of regulation or governments trying to step in and tell people what to do.
And that is exactly what we are not about. We are here to work within ARIN, bottom up, to be cooperative, to understand what ARIN does, how it applies to what we do and to work together. We actually had our first working group meeting in Washington, D.C., on February 4th. We had 18 agencies from the United States and Canada. You see some of them listed up there. We had Industry Canada; we had the FBI; we had the Secret Service, the Department of Commerce, Department of Energy, The Royal Canadian Mounted Police. It was a vast array of agencies that attended. And it was actually a very good discussion. As you can see it was an all-day interactive discussion to let government agencies know what ARIN does, the importance of ARIN, how ARIN operates and why they really need to pay attention and actually get involved.
Like I said at the meeting, we discussed what ARIN does, what it is. Believe it or not, there are a lot of government agencies that are really uninformed about what ARIN does and we kind of had to let them know what they do and why it's important for them to know what ARIN does, because what they do affects their daily business, and also to let them know that ARIN is public. It's a bottom up. And they can participate effectively in that. So some of the discussions that we had that would relate to them that would pique their interest is something we discussed here yesterday, which is the WHOIS policy. And we also wanted to describe the PDP policy to the governments so they know that this is something that they're going to participate in, not dictate or regulate.
And also to reach out to our Caribbean partners at the ARIN Caribbean sector meeting that we had in February, also gave a presentation there. It was explained to all the participants there that we definitely want the Caribbean sector, the Caribbean governments, the Caribbean private sector, private IT industry to be part of this. And CTU, CARICOM, some of the ISPs, they were very interested and would like to participate. And we're hoping that they'll be here next time.
We also had a very brief meeting here. This was our second meeting. We had various agencies here, which is very good. We had a good turnout. We discussed drafting a charter. We a proposed charter which will be on the website so everybody can see. We discussed policy proposals that were discussed here; namely, 2008-7 WHOIS policy that we spoke about yesterday. We also spoke about next steps, what we're planning to do, which is to invite private industry in this.
People who have the technical and policy background who would be of a benefit to ARIN and the cooperation working group. We're planning another meeting again in Washington, D.C., and then again at the next Dearborn meeting, and we're hoping to adopt -- we discussed about adopting the charter. So I went a little fast. But I just wanted to give you a very brief overview of what we do and what we're about so that it's very transparent. Because I know that yesterday was the first mention of it.
So, like I said, we just wanted, ARIN wanted to let you know that cooperation working group wanted to let you know what it was all about.
MR. FARMER: David Farmer, University of Minnesota, ARIN AC. Would you envision state and provincial government participation at all?
MR. FLAIM: Yes, we would. When we say government, we mean federal, local, state, absolutely.
MR. HANNIGAN: Hi. I'm Martin Hannigan, representing myself and pretty extensive background in (inaudible) patriot, whatnot. Is this an open group that's open to any member of the ARIN community, or is this a closed group?
MR. FLAIM: It's by invitation because we want to make sure we're getting people that are understanding of government, the ARIN policy and what we're trying to accomplish. So if it was to be open to everyone it would be kind of an open forum. So for right now the cooperation working group that is decided to keep it by invitation at this time.
MR. HANNIGAN: Do you plan to keep minutes and make any of your proceedings open?
MR. FLAIM: Yes, yes we will.
MR. HANNIGAN: Okay. And observers? Perhaps you'll have an observers policy at some point to kind of balance between those who may not be so experienced in government but those who want to learn or observe and, frankly, be aware of what's going on in the working group?
MR. FLAIM: Yes.
MR. HANNIGAN: I almost said secret working group. Sorry.
MR. FLAIM: No, no, bad word. Bad word.
MR. HUGHES: Aaron Hughes. Obviously you have your own RIR; you're not a DMR for ARIN, so you can't vote on policy proposals. How do you plan on sending feedback to this group to influence or give us information about your opinions about our policy proposals?
MR. CURRAN: Can I -- very conveniently, you actually don't need to be a member or DMR to participate in the policy process.
MR. HUGHES: Right.
MR. CURRAN: You can pick up a microphone and voice your opinion. So we don't exclude government either from that process.
Any other questions for Bobby? Okay. Thank you.
MR. FLAIM: Thank you.
MR. CURRAN: Now is the time for the break. Okay. We're going to try to get back on schedule. And that means that -- I hate to do it, but I'm actually going to try to compress your break, which means I'd like to be back here at 3:20. Actually, it doesn't matter. We have remote participants and they tend to only come in on time, and since we're going to resume with a policy proposal, everyone gets a half-hour break, because remote participants, sometimes they're not online right now to hear we're coming back. We'll come back at 3:30 and start out with policy proposal, and when we come back --
MR. CURRAN: That's an excellent idea. 3:20. My head table reminds me we can do one of the updates, like an RIR update. We'll take one of the reports at 3:20. I'll ask everyone to be here at 3:20. And we'll start at 3:30 with the next policy proposal. Thanks everyone. Breaks are where expected.
MR. CURRAN: Okay. Welcome back. We're going to get started. Because we have a number of RIR reports, we're going to slip one in right now and catch up on the schedule. This is George Kuo of APNIC is here. Yes, thank you.
MR. KUO: Good afternoon, everyone. George Kuo from APNIC. Just a quick update on APNIC policy outcome from the last meeting and our recent membership survey and some current and future activities. Okay. From last meeting in Manila, APNIC 27, we have two proposals that reached consensus and now they're in the stage of last call for comment. And one of them is Prop-050, which is the resource transfer policy, and it reached consensus with some modification to the proposal. And basically it is minimum /24 transfer, at the minimum, units. And APNIC will publish a log of all transfer and the address transfer was subject to address policy. And the other one that reached consensus is what was discussed here this morning.
In December last year we conducted a membership and stakeholder survey, and we were quite happy for the participation because it's almost double -- the number of participants almost doubled to the survey placed in 2007. We had over 600 -- more than 600 participants from over 40 economies that responded to the survey. There are three sections.
Section 1: We asked them to assess APNIC activities and services. And for this particular section, what's ranked highest, APNIC's reverse delegation WHOIS services and liaison activity with the technical community, government, regulators and other stakeholders in this AP region.
Second: We asked them to rate the resource allocation for future activities. And what they really want to see APNIC invest in three areas: Research and development; and training, in particular for network engineer in the region; and also for IPv6 development support.
Section 3 is something new that we didn't do before. We asked them for their IPv6 readiness. And we put some questions, asked them about their status of IPv6 deployment and we asked them whether they're ready, whether they have deployed IPv6 or whether they're ready to deploy at any time. We've asked them if they have allocated budgets, either financially or on human resource or whether they actually have the plan, formal plan to deploy IPv6.
As can you see from the graph here, that's the result of the survey. We also put some proposition to the members and stakeholders, and you can see large majority of them believe that it's important to have government support for IPv6 deployment. They believe that -- most of them think that APNIC should have a bigger role in supporting IPv6 deployment and the government should require IPv6 compliance within their own economy.
So the conclusion that we get out of this survey is APNIC should provide training and education to make IPv6 information more readily available to those who don't have the access to it, and we should liaise with regulators, governments and organizations to make a smooth transition to IPv6. And APNIC should support the community to also integrate IPv6 into the future business plan.
So, in fact, APNIC has already been doing this since last year. We established a unit which is solely responsible for IPv6 programs. And Miwa Fujii, who's the IPv6 program manager, has been actively planning the projects and participation in some forums and activities in the region.
For research and development activities, we are planning to deploy 12 boxes for the Test Traffic Measurement this year. We've been working with RIPE NCC closely on this who has a lot of experience in this activity, and I believe currently we are deploying three boxes in Australia, Pakistan and Hong Kong.
We also have Day in the Life of the Internet. We are gathering three days data, and they will be made available later. And, in fact, my colleague George Michaelson's here. If anyone would like to have more detail, feel free to talk to George. So what's coming up. We also are going to deploy a new APNIC website. And the aim and objective is again in response to the community and membership demand to improve access to APNIC services and information.
And I'd like to point out we're also going to have a low-bandwidth version for the members, some of our members in the region who don't have a great Internet infrastructure to access the graphic-rich site. So that's coming up in the next few months. And this is a preview of what the new website will look like.
kay. So last I'd like to invite you to the next APNIC meeting which will be in Beijing end of August, and this is the first time that APNIC is having its meeting in Beijing. It's the economy that's been experiencing a lot of growth in the IP address space. So I'd like to invite you all if you do have an opportunity, please to join us in Beijing. And the registration is opening soon. And that's all for my presentation.
MR. CURRAN: We'll move right ahead into the next policy 2008-3, Community Networks IPv6 Assignment. History of the policy proposal: Original proposal is 11 February 2008. This has been through quite a few public policy meetings. It was at ARIN XXI. It was at the Kingston, Jamaica, and Nassau, Bahamas, meetings. We had it at ARIN XXII, and then the Bridgetown, Barbados, meeting. Current version is 23rd of March, staff and legal assessment. And there's a discussion of this in AFRINIC, but no policy -- no proposal at this time. Lea Roberts and Stacy Hughes are the shepherds.
Summary: Makes a /48 or larger IPv6 assignment available to Community Networks. Criteria: Free or low-cost network services are run by mostly volunteers. Annual revenues are less than $250,000. Minimum 100 users. Staff assessment: Liability risk? No. Issues or concerns from staff? No. Staff implementation, resource impact? Minimal. So fairly straightforward for implementation. PPML: 12 posts. Seven different people. Two in favor. None against.
We all -- we all want to support nonprofit community networks that help poor people get online, but at first blush this looks like the proposal authors are assuming IPv6 equals IPv4. Frankly, I believe that the current policy limiting IPv6 assignments is much closer to assuming IPv6 equals IPv4 than this proposal. And the stated definition is woefully inadequate to describe many of the community networks that exist in Canada and elsewhere. Limiting the definition to organizations with annual budgets less than 250k may encompass community networks in developing nations, but is far too limiting to include mature organizations in North America. So at this point I'll turn it over to Lea. Thank you.
MS. ROBERTS: Hi there. So this is -- as John says, this one's been going on for a while. How do I move it forward? There we go. I also included a history slide in the slide deck. I think most everyone has heard what -- that it's been there for a while. The authors have been looking for a fee reduction for community networks as well. So we pointed them at the ARIN suggestion process for things that had to do with fee assessment. And this is the third meeting. In the two previous meetings, support and opposition have been about evenly split.
The first time there was a large show of hands for the question, “Should we continue this work?” That question was not asked last time.
What are community networks? They're generally known as a cooperative group of users where members set up connectivity among themselves, usually using wireless links. They share their external connectivity which may move around dynamically among the members and provide the members with low-cost or free Internet access.
One special case we had pointed out to us while working on this proposal is emergency response networks where people have been setting up networks to be available in case normal telecommunications in an area goes down they can step up and provide communication in that area.
Also we discovered that there were some cases in the Caribbean region where they were interested in being able to set up a network close to a university out into the field and people that otherwise didn't have much connectivity so they could do distant learning, teach classes from the university to people in their homes in the area there, and obviously rural areas where there's little or no other network infrastructure.
And why would they want an IPv6 assignment? Well, for stable internal address structure. They have members come and go, but if at least the address space remains the same, people who are there should be able to communicate with each other. Other good things that would devolve from providing community networks assignments is they might experiment with some IPv6 software, get some experience of things we'd like to try. They tend to be technically aware and could try out some of the IPv6 transition tools and potentially experiment with the various locator ID split technologies that are just starting to come out.
At least in the Caribbean region they were thinking they might be able to take some of their community networks and connect it to an Internet exchange on an island and be able to communicate with other people who had different kinds of ISP connectivity on that island. And obviously the proposers would be happy to have their address routed globally, but they didn't actually expect that that would happen.
The changes to the proposal from the last meeting is we completed the cleanup of text in relation to the staff comments that had been received too late for those changes to be implemented last time. Added that the criteria could be relaxed by ARIN in the case of rural networks and for networks in the Caribbean region. And there was a further update after the staff comments. All cases of allocation were changed to assignment. It had been sort of used interchangeably as the proposal evolved, and the reality is that as it ended up, the proposal is for an assignment of an IPv6 address.
Interestingly, as well as in the community, there's no consensus in the Advisory Council for this policy. It's almost evenly split. There's a lot of concern over creating a special class of people who would receive these assignments and the assertion that community networks should meet the same criteria as others for receiving resources. Criteria. Some people felt that, opposed to the PPML posts, the criteria allowed much too rich a budget for fee reductions and that the community networks who have budgets in the order of six figures should probably be able to afford the cost of an ARIN PI yearly charge.
And there was also concern, of course, over the routing table growth should these prefixes be announced globally, and belief that someone would figure out how to game this policy and use it to nefariously obtain resources by creating pseudo-community networks and getting assignments. There were some on the AC who did feel that community networks were worthy. But this interchange all came too late to make any changes before this meeting. And in light of the new PDP, since the AC was so divided, there was some -- it wasn't clear whether it should be presented as a product of the AC draft policy process.
But we decided to go ahead and show where we've evolved to and see if there's somewhere we should go. And one of the possible new directions that came up in our AC discussion is that we could just change 2008-3 to add the community network definition to the NRPM. And since one of the responses to the suggestion process was it would not be possible to do any kind of fee reductions until the community network was defined under policy -- so looking at -- if you want to look at your policy there, what that would entail is just taking the first bullet -- creating the new section 2.8, perhaps tuning up the percentage of volunteers and the amount of budget for the community network. And then the next section, qualifying criteria, would be including the number of members and so forth without the direct assignments. Or that could be left in, too, if people feel that way.
But that would address the concern over not providing special access to resources for people who run community networks. They just have to qualify as others, but with the definition in the NRPM it would be possible for ARIN to grant them fee relief if the organization so decided. And that's it.
MS. AZINGER: Marla Azinger, Frontier Communications. I'm not going to go into details why I don't like the first part. Your new direction I would support fully; the other one, not at all. So unless needed, I'm not going to go into those details.
MR. FARMER: I support both -- Dave Farmer, University of Minnesota, ARIN AC. I support this policy as written or pretty much any change I could think of. I think community networks are in the best tradition of the Internet. And we need to support that. As was discussed earlier, we're under a lot of scrutiny from government and other folks. And we need to show why self-governance is the right model and that it's not just about commercial interests and all of that. So this is one of those ways. And I think I'll leave it at that for now.
MR. VIXIE: Thank you, David.
MR. HANNIGAN: Martin Hannigan, (inaudible) but not speaking for them. I support this. I'm fairly skeptical on some of the justifications, though. Some of the inter-island stuff is more like transport than community networking. I also am a little skeptical of the relaxed requirement, but I do support the policy.
MR. VIXIE: Owen.
MR. DELONG: I support the policy both as written or under the new direction. I wanted to comment on the comment from the mailing list that was put at the head of the slide that said the authors appear to assume v6 equals v4. I don't think that's the case at all. I think the authors knew well the differences. Community networks, it turns out, are in a unique position to lead v6 deployment in very interesting and novel ways. It's very hard, for example, for Comcast to deploy the technology that they showed us on Sunday to their subscribers or even a subset of their subscribers rapidly.
On the other hand, Comcast could work with a community network that was IPv6 only to roll that technology out and test it on those IPv6-willing guinea pigs in a community network and get a lot of interesting feedback and a lot of effort. There's a lot of other interesting and exciting opportunities that I'm sure I can't even think of right now but that other people smarter than me will come up with if we make it possible for community networks to get portable v6 space to take advantage of whatever connectivity ISPs are willing to offer them on a moment's notice and be able to attach and detach multiple willing backbones as needed to support and facilitate that.
The authors and I have discussed this a little bit and I believe that there is no way to feasibly facilitate this in v4 but that with v6 we have enough address space that this becomes a wide-open field and an opportunity to spur very interesting and useful innovation. And I think that is in the best traditions of the Internet and, as such, I think we should do everything we can to support it. Thank you.
MR. VIXIE: Thank you Owen. Stacy.
MS. HUGHES: I have a comment from -- a question from Ed Lewis: How many groups feel they can't get IPv6 because there's no policy to allow this? How big is this problem? He has not run into community networks before.
MS. ROBERTS: I personally can't answer that question. If anyone out there can, feel free.
MR. DELONG: I can provide some input.
MR. VIXIE: Owen.
MR. DELONG: Owen DeLong, ARIN AC. I don't have a scope of how many community networks there are. But there is a very large number of them. Almost every medium- to large-sized community has some form of community network, if not multiples.
I'm involved with one called the Silicon Valley Wireless Users & Experimenters group. And we're trying to build a Bay Area-wide emergency communications 802.11-based or WiMAX-based, or both, network to both facilitate emergency communications and also to provide free or low-cost wireless Internet access to people. And we're getting a lot of interest from both the emergency services departments and from organizations we never thought we would, like the water company that is saying we've got these big water tanks on top of hills you might want to put antennas on.
There's some very interesting things going on out there. And the bottom line is this is a very loosely coupled, loosely organized group of relatively dedicated volunteers, and they'd have a hard time coming up with 100 bucks a year. Most of our hardware is donated. We occasionally put our own money into going out and buying a few little pieces of stuff to experiment with. And the ARIN fees to get and keep an allocation or assignment would actually be a barrier for them.
So at least the definition part in the NRPM is needed because although policy-wise it's a no-op, it then gives the Board that definition on which to base potential fee relief later, which would be one of the biggest things. Qualifying under existing policy, we wouldn't have too much trouble with. But the relaxed policy would actually be helpful to a lot of other community networks I'm familiar with.
MR. VIXIE: Leo.
MR. BICKNELL: Leo Bicknell, ARIN AC. As I look at this particular policy and how it attempts to change what we do, it seems to me that there are a number of different groups that have different problems and we're trying to lump them all together. As Owen just said, his group may have a problem with a $100-a-year fee. But this policy includes folks that have a $250,000 annual budget. I would hope somebody with that budget wouldn't have a problem with a $100 fee.
As I look at it, today, if we assume a single home network, so we're not even going to give them the benefit of a multihomed network, you have to qualify for a /20 on end-user policy, which means you need 25 percent of that or 1,024 hosts day one, and you need to be able to convince ARIN that you're going to have 50 percent of that, or 2,048 hosts, in one year.
The ongoing fee for that is $100. And once you've done that under the current policy you can then qualify for an IPv6 /48 with no additional documentation. That to me seems relatively generous. I do think there are a couple of areas where we could improve that, however, but this policy doesn't address them. And the two areas I'll specifically speak to is I do think on the fee side, although that's not policy, that the Board could offer fee waivers in a number of forms to groups that can't pay. And I think that's important to anybody who can't pay.
Whether it's $100 fee or whether they're an ISP that for some reason can't pay whatever the fee is and we really deem they're worthy to the community, I don't know what that situation would be, but it seems there could be a field process and --
MR. RYAN: It’s called Chapter 11.
MR. BICKNELL: If all five Board members really deem it's in the community's best interests to give them a waiver, then I'm going to trust the five trustees to do that. On the other side of it, the bigger problem that I see is right now v6 end-user policy is coupled to v4. The v6 policy says: If you qualify for a v4 thing, you get a v6 thing. And that is unsustainable going forward and it's just not a good way to qualify. And so since the current requirement is 1,024 day one and 2,048 day 365, I would absolutely support changing the v6 policy to be something lower than that so we could bring community networks into the fold and they could get a v6-only assignment, not have v4, and pay the $100-a-year fee.
I think that's a very simple way forward and would bring not all but probably 80 to 90 percent of the community networks involved into v6.
MS. ROBERTS: How would you feel about adding the definition part?
MR. BICKNELL: If Board members thought that was useful in terms of the sort of fee waiver I described, then I'm not really against it. On its own, I'm not really seeing it all that useful, though.
MR. VIXIE: Right hand side.
MR. BOYD: Chris Boyd, Midas Networks, Inc., from Austin Texas. I would like to say I support this proposal. I think it would spur development and experimentation. And we have a very active interest group in the Austin area that's working on various community networking. Thank you.
MR. LEIBRAND: Scott Leibrand, ARIN AC, private experimenter with not quite community networks, but almost. I get this technology. It definitely makes a lot of sense. I can really see a lot of good use for this. I support this policy as written. I would also support it if we just do the definition for fee waiver. But from what I can tell, the qualifying for a /48 thing is also a need for some part of the community, and I don't think we should throw that out.
MR. VIXIE: We have a remote participant.
MS. HUGHES: Josh King from Acorn Active Media says: I don't have direct statistics on the number of community networks as my organization does not have the resources to do that research. But it seems to me that if this is a "if you build it, they will come" opportunity for them to innovate and experiment for large scale IPv6 deployment down the road.
MR. VIXIE: R.S.
MR. SEASTROM: Rob Seastrom, ClueTrust, ARIN AC, and I was also co-founder and president of the Cambridge Bandwidth Consortium, which was arguably and is arguably a community network. It's run as a 501(c)(12) co-op, and I sort of see two real roles that people will be acting in when they apply for space as a community network, and I think they're both valuable.
One is providing a utility type of connectivity perhaps with different expectations than one -- than you would get if you had commercial connectivity, and I offer as an example of that the wireless communications grids, for lack of a better word, such as Owen was talking about, and Roofnet, which is an experimental thing with Linksys stuff sitting on people's roofs in Cambridge, Massachusetts.
The others is a little bit more unusual. It's more of an experimental sort of thing, and that's what I consider due to my personal prejudices to be really sort of in the greatest traditions going back to the ARPANET days, it was originally a network which was not a utility to be provided but it was a place to experiment and come up with sort of the next thing. Amateur radio has a /8 allocated to it. Many people aren't aware of that. And I believe that facilitating both uses, address space, by eliminating the costs associated with it to the extent possible is a good thing. And so I support this proposal.
MR. VIXIE: Thank you, R.S. Any more remotes?
MS. HUGHES: Not yet.
MR. VIXIE: Aaron.
MR. HUGHES: I'm Aaron Hughes. I don't completely agree with the text as written; however, I'd say push it through anyway. I completely agree with Leo wanting to rewrite the end-user initial allocation section of the NRPM. And once we fix that, we can always get rid of that at that time. In the meantime, the community networks need the space. ARIN doesn't really care about the possibility of minor abuse for $100 a year. This isn't a huge impact on ARIN or the community. And on ARIN. It is, however, a huge impact on community networks. I support it.
MR. HANNIGAN: I'm Marty and I'm just going to speak for myself. I want to modify my support a little bit after consulting with a colleague or two. First, I think Owen's example is a poor example of a poor community network because the hundreds and thousands of dollars of radio gear involved in this project, it makes me wonder why someone can't pony up 100 bucks to support their hobby.
Two, I think I would support -- so I'd like to withdraw my support but re-offer my support as a Caribbean-only policy, and here's why: So in the Caribbean you can actually quantify that people are trying to get access to the Internet who can't afford to get access to the Internet. And they have real problems, like the incumbents in their way. For example, when you have a market in the Caribbean that isn't diversified and there's no competition, your mode of access is typically dialup at over $100 a month for a dialup connection. And it's not because that's what the actual cost is. That's because that's what they can charge.
Any kind of connectivity between the islands usually has to be funded by governments in the form of submarine cables or radio links which is why I'm skeptical of the justification of inter-island communications over Wi-Fi. It doesn't make sense. But, anyways, you can justify the need in the Caribbean more so than I think you can in North America, so I support this policy as a Caribbean-region policy, but not necessarily North America.
MS. ROBERTS: Just for clarification. The bullet regarding the Caribbean referred to intra island communication, where there's Internet exchange on the island and the community network could get a connection there and talk to other Internet users, connected to that exchange.
MR. HANNIGAN: I'm aware of that. But, still, to do that over those distances, and I have an example in mind which is probably the one you discussed, they should pay the hundred bucks in my opinion. But I think there are other cases that are truly needs based and truly community networks that they're trying to get access to the Internet because they can't, and I think that that's what a community network is.
It isn't a hobbyist network. It isn't a network where someone doesn't want to pay ARIN the fee, but it is a place where people cannot get access to the Internet and we're doing them a favor by giving them the allocation for free. How are they going to get those things routed? I don't know. I don't think we need to solve those challenges here today. So I support the policy as a Caribbean-region policy with the justifications that I provided. Thank you.
MS. ROBERTS: Thank you, Marty.
MR. VIXIE: Marla.
MS. AZINGER: Marla Azinger, Frontier Communications. I would support if it were Caribbean only in the U.S. main proper. If you look at it closely, it really is just a sly way of starting a new business model.
MS. ROBERTS: I don't know what to say to that.
MR. VIXIE: David.
MR. FARMER: For anybody that thinks that the kind of -- David Farmer, University of Minnesota, ARIN AC. Amateur radio in this country and around the world is a very important technology. It has spurred innovation for over a century. If you don't think it's important, go talk to some people in law enforcement.
When all of our network fiber was cut and the hospital in the Bay Area didn't have telephone service, it was amateur radio folks that did their thing and made sure that hospital could stay functioning so that community had emergency medical services.
This is a long tradition, and we need to support this. I don't care if you think it's a way to -- another business model. I'm sorry, the community that created the Internet could think you commercial people are nuts, just as you think we're nuts. And I'm going to leave it at that.
MR. VIXIE: Thank you David. Cathy.
MS. ARONSON: Cathy Aronson, ARIN AC. I wanted to say I think we're experiencing a complete instance of why we don't discuss fees.
MR. VIXIE: Jason.
MR. SCHILLER: Jason Schiller, kilo bravo 2 Romeo tango Quebec.
I oppose this policy.
MS. ROBERTS: Would you care to say why, Jason?
MS. ARONSON: Apparently not.
MS. ROBERTS: Well, I’m WA6ITV, and have been for many years.
MR. VIXIE: We have a comment from the head table.
MR. ALEXANDER: Dan Alexander, ARIN AC. This isn't a statement against or for. I would just point out a potential unintended consequence of this policy in that one respect there's a lot of policy effort around the integrity of points of contact and we also have Government Working Group to improve interaction with law enforcement and to prevent or to provide better abuse contacts for bad things going on. And giving a block to these community networks which area little more loosely administered could take a step in an unintended direction.
MS. SCHILLER: I agree with what Dan said, but what I really wanted to come to the mic and say is that I think I've heard from almost the entire AC, most of the ASO AC, but I would really like to hear from people that are not going to be talking about this tomorrow afternoon.
MR. VIXIE: Left-hand mic.
MS. HUGHES: I have one.
SPEAKER: You know, we've heard commentary from some people who are involved in amateur radio. And some of the commercial users may not even be aware of how much of a debt that the Internet owes to innovation done by amateur radio people for Internet operations, and saying that these people are trying to create a business model on the sly is both disingenuous and, frankly, a little disrespectful to their tradition of noncommercial activity.
If you've ever seen what happens to someone who tries to make use of a ham radio network for commercial purposes, you would not be worried about the regulatory or ability of them to track down the perpetrators. Now, obviously community networks are not just ham radio. But I think because these are community networks, the issue of identity and self-regulation are largely nonexistent because these communities will self-regulate, because they all know each other.
Anybody that knows anything or has ever been involved in any of these communities is aware of that. I strongly support any ARIN policy that encourages the development of community networks because it creates innovation. It creates new markets. It improves things for essentially everyone and only people that seem to dislike it are monopolistic companies that try and legislate those community networks out of existence.
MR. VIXIE: Marty.
MR. HANNIGAN: I wanted to address that point real quick, just a point of information. I assume these would be as surveyable as any other IPv6 address, and as far as POC information goes, we're not waiving any POC requirements or loosening that standard, and so there would be a place to get a hold of somebody if needed. And I don't know that there's really an issue there. Did you have something else in mind with regards to I guess --
MR. ALEXANDER: I understand that, of course, the allocations would have to have a reliable point of contact. It would just be the responsiveness of that contact could be a question.
MR. HANNIGAN: It could be Citibank or Caribbean Community Network. You can't really say they wouldn't be any more responsive. Actually, I would tend to believe they'd be more responsive than Citibank, to be honest with you.
MR. VIXIE: Right-hand.
MR. BOYD: Chris Boyd, Midas Networks. I'm not on the ARIN Advisory Council and I'm not a ham radio operator, but there are still a lot of people in the poorer parts of Austin and rural Texas that would like to be able to have Internet access. And there's basically no chance in hell that they're going to get it. If they can all band together and build a network to help them do that and to help them communicate, I think we should support that.
MR. DUL: Andrew Dul, Perkins Coie. I'm in support of community networks policy. Is this probably my favorite community networks policy? No, but I will support it. I think there could be things that could be done better in the policy. But it is what it is. We can always tune it up later.
MR. WILLIAMSON: David Williamson, Tellme Networks, no association directly with the AC or any other formal body. I have no doubt of the goodness of ham radio or community networks. I'm really rather ambivalent on the text as stated.
I think simple policy is always better. I really like the idea of simply having a definition for community networks and working from there. That really strikes me as possibly a very good way forward. And there must be some way to help out groups that are doing good things, and community networks clearly are one of those things that have a long tradition of doing nice work. But making a special class strikes me as problematic in a few regards, but it wouldn't be bad either. So I'm very ambivalent on the main text, but a definition I think is a nice way to go.
MR. VIXIE: Remote.
MS. HUGHES: Ed Lewis of News Star says: Listening neutrally to this it sounds like the AC needs to come to a definition of a community network before this can go anywhere. I don't know if I like the policy or not. So trusting the AC and hearing they're divided makes me wonder why something sounding so good has deep downsides.\
MR. VIXIE: Aaron.
MR. HUGHES: Aaron Hughes. I just wanted to bring up that we discussed this when there are deep downsides to experimental space for people to develop stuff in their garages and basements to help better the Internet. And we decided that it had to be part of an IETF plan and that you had to submit that as part of your development process in order to get experimental space. And it actually caused a problem for a while until we realized, just like we always have done, when we need space for some development to better the community or the Internet, we ask a friend and they give you the space to do it.
Community networks are going to get the space whether we permit it or not. We should support it and put it in a policy rather than let them do that on their own. At least we will get POC information rather than go: Where in the hell did this 48 come from that's out of some 32 that's in an entirely different location.
MR. VIXIE: Another remote.
MS. HUGHES: Yes, Josh King says: I think the intent of the policy is not to facilitate getting around existing policies for other business models, which is why there is a lot of problem with finding that financial threshold. Where some people think $250,000 is too large of a budget and others too little. I think it opens the door to something that is extremely beneficial to volunteer groups with very little repercussion to ARIN.
MR. VIXIE: Are there any -- Lee.
MR. HOWARD: Lee Howard, ARIN Board of Trustees. I have no intent of discussing this tomorrow, to whoever's point it was. I've heard a couple of people ask or make a point about being unable to find $100 for a maintenance fee. My understanding, and I admit to being largely ignorant of the community network community, is that we're generally talking about networks that provide connectivity for others and therefore would generally fall into the ISP model and get allocations. Right? Is that a fair -- I'm looking at Lea.
MS. ROBERTS: I think in terms of this policy, Lee, the way the authors phrased it, is they're looking for a particular community network assignment from which they would assign some small set of subnets to each of the members of the community. So you could consider it an ISP model, but I don't think they're looking at trying to assign /48s to each.
MR. HOWARD: What I was really trying to get to was if the assignments are -- in some cases we've heard of cases where people are providing connectivity to rural users or poorer communities that wouldn't otherwise be able to provide connectivity, which is probably a different case than a pure co-op, which maybe you could consider being more like an end-user assignment.
The point I wanted to make was that in those cases there is a different fee structure that is not $100 per year but it is a renewal based on the size of the allocation, and that I guess to somebody's point, it is -- that is not an insignificant amount of revenue. Whether the community networks' portion of that is significant, again, I couldn't say. We don't have any quantification of that size of that community. I'm not speaking for or against it, but I just like crisp dialogue, I guess.
MS. ROBERTS: The policy as written talks about a /48 or larger, if justified in the usual -- essentially the language is the same as the PI IPv6 allocation. And I think what they're looking at is being considered as like one site that gets a /48 and sort of manages it among themselves more than doing suballocations.
MR. LEIBRAND: I have a response to that. Scott Leibrand, ARIN AC. As I just posted to PPML a couple days ago, I can't remember where, I think that a lot of community networks, like you said, are more like ISPs than end users. So kind of the default position is to look at them as an ISP. I agree with you that means they get a /32 if they have 200 customers, and it means they pay 2,000 and some-odd dollars a year.
Obviously that's going to be cost prohibitive for many community networks. As Leo was alluding to, it's maybe possible to look at them as an end user, but that's kind of not what the idea was, and so I think this is one of the real reasons that we don't want to just define community networks, but we also want to set up a policy for saying they get an assignment, a /48, not a /32, if their community network bypasses the whole question of are they an end user, an ISP, whatever. They're in the community network. They get a /48, they can do whatever they want with it and the Board can set specific policy for them if they desire.
MR. HOWARD: Thank you, I find that helpful.
MR. VIXIE: Are there any more questions or comments on this policy?
MR. WOODCOCK: This is Bill Woodcock, Board. I just would like to really try and keep the worrying about the fees out of the conversation, because that really is what everything seems to get hung up on, if we can define a category, then subsequently we can figure out what the fees are like, and they may be much easier to determine once we see who is in the category.
MR. HANNIGAN: Hi, I'm Marty again, speaking for myself. I like what Scott said, but really all the symbolism we've engaged in in this meeting, I don't think that one more engagement in symbolism is going to kill us.
And perhaps community networking is a symbol. Albeit, for me it's a valid one. I think separating the fee out of the issue is a great idea. I still support it as a Caribbean-only policy. And I think adding some intent or definition might be helpful. I don't know if we can get this done here today. But I think it should focus on people that would normally not be able to get access to the Internet, not people with hobbies. Thank you.
MR. VIXIE: Owen.
MR. DELONG: So a lot of community networks that I'm familiar with were looking at just trying to be able to get an assignment rather than an allocation. Not because they're not really ISPs, but because they had no hope or even vision of hope regarding themselves as ISPs, with the ISP fee structure and the way that the ISP requirements are written, and they thought that they could at least serve their community with an end-user assignment.
It would probably be better for everybody concerned if there were a better way to treat them as ISPs without making it completely prohibitive for them to act as such.
MR. VIXIE: Jason.
MR. SCHILLER: Jason Schiller, UUNET/Verizon. I feel I need to be here and say why I'm against this because of something Lea just said which was basically this was the same principle we used for PI space. And it's really not the same criteria, as I read it. The bar is much lower for community networks to get a /48 than it is for a PI holder or for an ISP wanting to get PI addresses. And I really don't understand why the bar should be lower for community network to put an additional route in the routing system.
On top of that, I really don't understand why community networks feel that they can't use a v6 reassignment from an upstream ISP. I think there's plenty of ISPs that do v6. And if they're not connected to the Internet, why can't they use ULA. And these were the questions I asked last time around and I don't feel that --
MS. ROBERTS: I've asked them that, and I'd like to share the answers that I thought I understood from them.
MR. SCHILLER: Great.
MS. ROBERTS: First of all, one of the questions I asked specifically is whether they were expecting a routing slot. They said, as I thought I said in the presentation, they'd be happy to have one but they certainly weren't expecting one.
They didn't want to use ULA, because they would like to be able to interchange with other experimental networks using tunnels or whatever and have it still be globally unique space and not have to worry about registering your ULA with whoever and to be able to get some perhaps local routing from an Internet exchange or whatever independent of being in the global routing table, and, again, as a locator ID separation experiment to have that kind of unique ID as well.
MR. SCHILLER: Okay. Great. Thank you.
MR. VIXIE: Are there any more questions or comments about this proposal? Okay. Thank you, Lea.
MR. VIXIE: I'm Paul Vixie, KI6YSY. And I'm forbidden more or less by my own rules for commenting on this proposal. So we have reached the end of discussions. It is time to show your support or opposition in a way that will inform the deliberations of the ARIN AC who has a long meeting ahead of them with this on their agenda.
So if you would be so kind as to indicate your support, and then I will ask for opposition to this proposal as written and frozen 10 days before this meeting. First, those in support, please raise your hands high. Thank you very much. Those in opposition to this proposal as written. Please show your opposition. Thank you very much. Lea asks if a definition of community networks would change the support in opposition for this proposal. So I will say we don't have a specific one that we're asking about.
MR. LEIBRAND: Not exactly (inaudible) the point is -- I think -- Scott Leibrand. I think what Leo is asking is would you support just defining community networks without inserting the part about giving them /48s.
MR. VIXIE: Even I missed that part. So we're asking if a definition of community network would seem like a useful direction to go forward in.
MR. HOWARD: Absent any policy. Just a definition of community networks.
MR. VIXIE: Absent any policy.
SPEAKER: Adding to the NRPM (Inaudible).
MR. VIXIE: So we're suggesting adding a definition in the NRPM that would not be referenced in the NRPM?
MR. WOODCOCK: After all three-quarters of the definitions in there aren't referenced anywhere else anyway.
MS. ROBERTS: At the beginning of my presentation, I talked about how when the original proposal came in and it included fees, that was split off and sent into the ARIN suggestion or consultation and suggestion process. My understanding is the answer came back was such fee stuff could be considered but only if there was a definition for what a community network was in an NRPM.
So as the kind of lukewarm reception to this proposal proceeded through the AC, one of the ways to proceed that occurred to me would be to do the part of adding the definition and at least enabling the rest of the suggestion process to move forward.
MR. VIXIE: I see. Thanks. That's much clearer. R.S., what would you like to add.
MR. SEASTROM: So Lea, to clarify, this is suggesting that we add a definition of what the community network is in the hopes that the NRPM, in hopes that operationally staff will apply such fee mitigation as they see fit and hand out whatever sized network is appropriate.
MS. ROBERTS: I mean, the idea would be that the community networks would still have to qualify for resources as anyone else would have to qualify for those resources, meeting the same criteria. No special criteria for getting the address resources from ARIN. But it would enable the organization, should they decide to, to have a different fee structure for community networks, which would at least address part of the original proposal.
MR. VIXIE: I think Lea has made that proposal clear. Can we see a show of hands -- wait. R.S., did you have anything else to add?
MR. SEASTROM: I would just like to ask if you could have a show of hands for people who are in favor of doing that and a show of hands of people who are in favor of doing that to the exclusion of the policy as it's currently written. Because those are two different questions. As to whether that would be okay with you versus whether that would be more desirable than the current policy.
MR. VIXIE: So you're looking for people who would support that who did not raise their hand in support of the policy overall?
MR. SEASTROM: That's correct.
MR. VIXIE: All right.
MR. BRADNER: I'm as big a fan of glossaries as anybody but adding a definition of something to the policy manual seems not to be the right choice for anything. I think I happen to believe deeply that doing something with community networks would be very useful. Defining what they are in isolation makes no sense. I just don't see how, where, that would fit in or what it means.
MR. VIXIE: I appreciate that. In fairness to Lea, we're going to give that guidance to the AC. But Lee would like to say something.
MR. HOWARD: I think you've made it so I don't have to say that, thank you.
MR. VIXIE: So secondary proposal, and this is incremental secondary question. If you did not raise your hand in support earlier, so you're not in favor of this proposal as written but you are, in spite of that, in favor of adding a definition to the NRPM that defines what a community network is so that the member suggestion process could reference that with regard to a fee change, please raise your hand now. Marty, you've got to take a position.
MR. HANNIGAN: You guys kill me. I'm like the most corporate guy in the room and I'm for this because I think it's a social thing. I can't believe we're going through this. But, yeah, make a definition if it matters. I just don't think it's going to matter and we're going to -- we're going to go down the black hole for another meeting or two and let's just give them the frickin' network and figure it out.
MR. HOWARD: Admit it, you're a liberal.
MR. VIXIE: Do you need to know -- there's no opposition to that. There's no --
SPEAKER: (Inaudible) the other half.
MR. WOODCOCK: But we can just subtract to get that. I'm happy, though.
MR. VIXIE: That's the end of the questions on this. I will say that the support that the FCC gives to the amateur radio service makes the FCC and the U.S. government look pretty good in the eyes of the world. And support for a policy like this, assuming that it can't be abused and doesn't cost us anything, will probably make ARIN look good to the extent we don't already look pretty good, this would make us look even better.
Of 116 people who could potentially have indicated support or opposition, 33 indicated support as written and 13 were opposed as written. 17 of those -- this is amazing. 17 of those who did not raise their hand in favor -- so this got in not only some who were against but some who abstained previously -- said that they thought adding a definition of community networks to the NRPM could be useful. Thank you.
MS. HUGHES: I have a comment from the remote participants. They want singing.
MR. CURRAN: Boy, Paul, glad you're up here. Anyway, we're going to pick up with the set of reports that we had scheduled for the day.
MR. CURRAN: The next one on the list is the IPv6 IAB/IETF Activities Report. That's presented by Marla. I see her coming up.
MS. AZINGER: I'll leave Kumbaya to Stacy later. She can lead the round. Can't dance to it, though. Sorry.
All right. So on we go. IETF activities. This presentation was put together by myself and Thomas Narten.
And our disclaimer that we like to give: There is no official IETF liaison to ARIN or any RIR. It's believed to be accurate as far as we know. But the errors are solely our own responsibility.
And this presentation is not a detailed view of the documents that will be mentioned. So routing and addressing: Routing and Addressing Directorate has been working on a problem statement for the remaining issues and constraints regarding IPv6 routing. New comments have been just integrated and posted this last month in March.
The Routing Research Group continues to have members presenting several ways of providing the answer that hover around the same form of solution set. Most of these are all on locator ID separation. And this last conference permitted, finally, yea, a BoF for the topic and a new working group has been arisen out of it named LISP.
There was a discussion/presentation. One that was interesting was discussion of FIB reduction approach called virtual aggregation. The rough scenario is having to have internal router/routers that hold the FIB and all the edge routers hold RIB. Also all edge routers have a virtual IP that signals the direction to the internal route with the FIB. That presentation, I think Jason can back me up on this, kind it gets confusing, actually, if you were to go online and look at it. But it was interesting at least to say the least.
The IPv6 Maintenance Working Group. We have four active documents and one new RFC. So, yea, they made progress in one thing.
v6 operations: Despite a lot of back and forth that happens in this working group, they did manage to push out four documents that became RFCs. And at the last conference a lot of time was spent on documents and presentations that in the end were not accepted into the working group but did have feedback that they were worth working on by others on the side.
One of the active ones is Rogue IPv6 Router Advertisement Problem Statement. And the focus, the main thing about this one is the focus was changed from malicious to accidental. That was a very big debate. Active related docs but not adopted that they discussed was v6 services for UPnP residential networks. And they want input if global or ULA should be used. And they have zero input right now. So if you want to get involved, there's a good one.
v6 deployment and statistics at a conference. Experimental deployment of a v6 at 3000 plus conference was presented and they showed what happened and the results they got. Problems with v6 first address selection and v6 NATs. A lot of kickback on unrecognized assumptions in that document occurred. And there really was a lot. So it didn't go over as well as others.
Incremental carrier grade NAT for v6 transition. This displays carrier grade NAT but doesn't address the working relation between several carrier grade boxes and puts it off as a CGN issue. That's not resolved or part of the solution set. So it's kind of like: Hey, here's the big elephant but we're not going to address it. And 6-4 qualification. Not really necessary as it creates an alternate way to test 64. But in order for it to work everyone has to set anycast up for test to work.
It is very likely that just using an existing test that would work best.
MS. AZINGER: I'm sorry you guys. I'm going through mine. Sorry. I'm going through my notes. This is the one I was on. I'll let you look at it for a second. Sorry about that. It's really exciting, isn't it? Sorry.
The SHIM6 working group: Main documents finally cleared IESG. And they have three in RFC Editor Queue. And they have two active documents. So they've been making some progress. And they're still doing, believe it or not, the multi-homing issue came up a couple sessions ago and they're still working on that.
BEHAVE: They are getting pretty involved in v6 now. And they're really busy with the transition and focusing on that. They've written several documents addressing NAT and TURN, which is reversal using relays around NAT and just recently got one published as an RFC.
Internet Area Open Meeting: This isn't a working group. This is just one of the open meetings and lots of different discussions come up and presentations.
I picked out two that were kind of interesting. The DHCP versus RA. A new solution set to only do DHCP and not RA. Some ORGs only do DHCP. And they won't transition to v6 unless this option is created. This faced useless discussion from what occurred of it of why should we bother but in the end was seen by the majority as important since some folks can and will use it. So there was a big debate of do you spend time on it or not when only some will use it. Of course, the people that will use it want to.
Shared ISP addresses: Looking to use up one of the IANA /8s for basically another 10 net to try and resolve overlap when really it won't resolve this issue. Multiple people shot this down and it actually was a very lively discussion in two different groups. But it eventually didn't go anywhere that IETF folks that man those meetings decided it was not going to go any further at IETF.
Secure inter-domain routing: This one turned into a heated debate on proper route authority that unfortunately didn't really go anywhere. And currently there are around 15 different documents looking at the various technical aspects that need to be addressed in order to create a good plan for proper route authority. And some serious balance and cooperation and collaboration needs to begin in that group before it's going to go anywhere.
Softwire: I wanted to bring your attention to this. Softwire actually, I decided, got the award for the most productive group. They actually have three docs in IESG processing. They have three docs that just became RFCs. And they have one doc -- I'm sorry, they're in RFC Editor Queue. And one doc is in the RFC. They're just very active. And actually they're pushing out documents, which is a relief to see because sometimes these grids get a little stagnant with their documents.
DNSOP: We have one new doc that has become an RFC and six new active documents. And DNS awarded for the most entertaining draft title. "I'm being attacked by prisoner IANA.org," and this, seriously, this is the most entertaining one I've come across. The document proposes background information and technical advice to firewall operators involved with sending DNS reverse mapping queries for private address space. I just really liked the title.
DNSEXT. Those extensions, I don't quite say the abbreviation too well. So it has one working group doc, five active documents and one new RFC. They made progress, too.
OPSEC: Four active documents and one document that recently expired. And it features unknown. If you have an interest in this document you best get involved at least via the e-mail and op mail list because usually when they go into this status they usually just drop off the scope.
GROW: Nothing too excited there, but three active documents are actively being worked on.
And then there's a new working group as I mentioned, the LISP working group, new internet architecture defining two functions, routing locators and identifiers. And this presentation has e-mail group lists. So if you want to sign up and watch what's going on or try and be involved, get on that list.
And there's also a proposed working group which did have a BoF in San Francisco. And it's questionable if there will or will not be another one. But it's looking at standardization of v6 version of NAT. It was a lot of NAT discussion.
And they'll continue to discuss the problem requirements for NAT. The next IETF is in Stockholm, July 25th through the 31st. And if you want to see summaries of the BoF, they will be showing up on these sites pretty soon. And the officially approved BoFs once they're known as well.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. Not so much a question. I want to comment on two little items in your presentation. One is there are issues related to secure RAs, DHCP and VRRP v6 that are all tied together. And the operators have been complaining about them for a while. I'm certainly one of those, and I've also complained that they haven't been getting enough attention in the IETF.
First of all, I'd like to say on the record somewhere that several IETF folks have really stepped up and communicated with several operators involved privately and are taking that quite seriously. And I also bring that to this community's attention, because out of all the things that the IETF is working on, they are issues that we have seen in live test networks. If you've ever seen the rogue RA problem on an IETF or NANOG or other network, it might be the only IPv6 problem you've ever experienced. And it is a problem that has to be fixed at least partially for some of the issues in end host. It's not something we can fix in router gear.
If we deploy tens of thousands of computers wrong, we have to go back and fix them. I think it's a very important effort. Because they are listening, I want to re-encourage anyone who had been discouraged before to go talk to them about that. The second thing I wanted to say is about the LISP work. My employer happens to host one of the LISP test bed boxes that is out there. There is now a substantial community working on that. And in the greatest traditions of the IETF of rough consensus and running code, there is in fact running code.
I would love to be able to tell you that I thought it was going to save the routing system. I haven't been convinced of that yet. But if you're one of those people who is always skeptical of a research project until you see it in action, there are test boxes deployed all over the globe. It is running. They are somewhat willing to pull in other people who are willing to spend time experimenting on it. So if you're interested, you should look at the LISP website whose address I forgot, but probably through the presentations you could find it pretty easy.
MS. AZINGER: It's there. And right now they actually don't have any more boxes to hand out. It's awesome. If you want to be involved with something that's basically grassroots for Internet architecture, it really is an awesome group to get involved with and start talking and looking over the documents and getting involved as much as you can. And the RA thing, as Leo pointed out, it really is one of the most important things going on at IETF right now, which is why it's such a hotbed and such a heated discussion at IETF and there's so many different documents, that interplay is what really makes it difficult.
ny other questions or comments?
MR. CURRAN: Okay. We're cutting a little bit into open microphone time but I wanted to get one more presentation in today. We did not get a chance to get the LACNIC update. And I see Raul is here. So I'll ask Raul to come on up and we'll do the LACNIC update, and then we'll be done with the presentations and have an open mic session.
MR. ECHEBERRÍA: Good afternoon, everybody. I don't know if being the last one in the afternoon is a good thing or not. But I will try to make my best effort. Who is managing -- okay. I will tell you what I will not speak about today. As you can imagine, we're going to make allocations so I will not speak about how many IP addresses we are allocating the amount of addresses is growing as it is every year.
The membership continued growing so I will not show any graph with the evolution of the membership. I will budget it, as we have also more staff. And all those things that usually I speak about and you already know very well. And I will not speak about policy because Einar has given a very good presentation yesterday or today, I don't remember. But so you have been informed also about policy developments. So let me say only one thing about the policy development process, that is that we have a new PDP last year. And a couple of interesting things is that we have the new PDP includes the explicit policy approval process that is very useful tool for having in this interesting time in which we probably have to react in short time to some -- trying to put some policy for consideration in the community in a short time. The other change, interesting change that we use it to have one chair elected by the community. And we have two co-chairs now. They have changed last year. One of them is Francisco Arias from Mexico, and the other one is Eldert Louissa from Sint Maarten.
So let me focus in other things that we are doing in LACNIC. We continue running one of our most interesting programs. That's FRIDA program, through which we've funded more than 40 research projects. We organized at a meeting in Montevideo last week with more than 70 researchers from 10 countries of the regions. The objective of that meeting was to promote the research on ICT and scheduled the researchers to learn how to get funding for the process and promote the FRIDA. The FRIDA is a very successful program that is run by LACNIC and is co-sponsored by LACNIC, IDRC from Canada, and the Internet Society.
We launched this year for the first time, but it's something that we plan to do every year journalist contest on Internet governance issues. The objective is to have more, have a better communication with journalists that are working in this issues and at the same time to promote high level action of the journalists in these matters. This is first year we received works from 40 participants, and they are being evaluated by an independent group right now. And the results will be announced very soon since one of the main prizes is to participate in our meeting in Panama.
This has been a very interesting experience. It's interesting to realize the things that are being written or spoken on radio, TV, in other countries, in different countries. We don't know about that, because it has been a very interesting experience. We're working in many aspects of public affairs. As Bobby Flaim has said before, we're working the creation of the Government Working Group in LACNIC. It was a happy coincidence that we are working the same direction that having, and the same directions of other RIRs. The first meeting of this group is planning to be held in Panama in the last week of May.
As we are having a very active role in many governmental environments, some meeting documents provide information, proposing measures, giving presentations and participate in governmental meetings. In fact, we are submitting, I don't know if you are aware of that, but ITU is conducting a survey on IPv6 issues, and they have sent a questionnaire to all the member states. And some of the questions that are included in the questionnaire are about number of IP addresses allocated per country, number of IP addresses that are being used, and the number of organizations that have received IP addresses per country. So we take the opportunity to prepare documents and to submit the document to all the governments of the region, giving some information that can be used for answering the questionnaire.
Informing them how the information is public and how it can be accessed in the RIRs website and also making clarification about some ambiguous concepts that are being included in the questionnaire, like IP addresses that are being used, a number of organizations that have received addresses. So this is an opportunity. We have also prepared some documents in the last few weeks about how to implement IPv6 in IXPs, how to implement IPv6 in CCTLDs. And the document about IXPs has been presented in IETF and has been accepted by the group and now it will be submitted also to governmental, some governmental forums.
So we are also working in the organization together with APC and RITS which are NGOs, international NGOs, we are also working together, as we did last year, organizing the Regional Preparatory Meeting of IGF. This year it will be held in Rio de Janerio from 11-13 August. Some of you probably are interested in participating in this meeting. I'm not thinking about going to Rio de Janerio. I'm thinking about participating in the meeting. So if some of you want to be involved with this meeting and want some information, contact me. I will be very happy to provide information necessary for doing that.
As we continue with high involvement in IGF and in the advisory group, personally I'm a member of the multicore advisory group of the IGF since 2006. This year I have been agreed to continue in the MAG. And I think also somebody from this community will be part of the group. That is very good news. But I think it is not public yet. So I will let the interested parties make that announcement.
So we have submitted, LACNIC has submitted a couple of proposals for organizing workshops during IETF. One of them about the RIR system itself. The objective of the percent submitting proposal is that when similar proposals are presented in IETF, the organizer are asked to work together to merge the proposals. So we have presented some proposals in order to be there. And if somebody will speak about the IRC thing we will be part of the workshop because we have a proposal on that issue. So there is no way to be outside of the discussion.
Engineering projects: We are working in a couple of -- we're working in many things, as all RIRs do, but there are two projects that are receiving more attention within the LACNIC also for resources. One of them is the APP project. APP is a project that has been used until now basically for domain names registration. So we are adopting these protocols for the LACNIC system, so I understand it's the first time it will be used for IP address registration.
There is some -- there are some requests -- there have been requests for a long time from ISPs to have a solution, a system that permits them to combine the system that they use to manage their own IP addresses with our system. So this is one of the main motivations for doing this, for this development.
We have two national registries in the region. So we will use this protocol for implementing a solution that satisfies the request for our members. But at the same time for the communication between the NIRs and the RIR. The libraries, the first set of libraries for the customer for ISPs will be delivered in May, in the last week of May during LACNIC meeting.
The second stage, that is, the application, the APP applications for the NIRs, the libraries will be available at the end of this year. And we expect that starting in the second half of 2010 we will receive requests from the NIRs only using EPP. The other projects, as you can imagine, is RPKI. We have increased our involvement in this project since the last second half of last year. We have now one person working full time on these issues and obviously other people from the engineering department also working in the project.
We are working in deploying a better version that will be ready this year. I think that I don't need to explain what this will do. This is always. We are organizing many activities in many countries. We are very active with IPv6 training, tutorials about how the RIRs working, of course including LACNIC. Also supporting the meetings organized by other parties. We expect to have, in the next four months, we have activities scheduled, as you know, in these countries that are listed in the slide for this is challenging.
Our annual meeting will be held this year in Panama City in the last week of May as usual. Of course all of you are welcome and invited and welcome to joining us in Panama. Panama is a very beautiful place. Besides that, I think that the meeting could be interesting. So we plan to have a social on the Canal. So it's an opportunity to go there and to know one of the most interesting things of the region.
There will be many activities in Panama during the week of LACNIC meeting. As usual there will be CCTLs meeting, interconnection forums, IPv6 forums, security forums and many other things. And, finally, even the fact that Ray is not here today, I would like to take the opportunity to congratulate Ray Plzak for being appointed to the ICANN Board recently. This year the election I understand has been very hard. I think that Louis Lee will speak about that later. But there were very good candidates running for this position. But I'm very happy to see that Ray will be there. That is a person who knows very well and the RIRs community and I think that's a good thing.
So that's all. Thank you very much. If you have any questions. I have tried to be very short. Thank you very much.
MR. CURRAN: Okay. We come to the end of the day and we always end this meeting with, each day, with an open microphone session. And I'm going to turn that over to our faithful Chair who will manage the proceedings. So go ahead.
MR. VIXIE: Thank you, John. If there's something that you ran out of time to say or thought of after the end of the discussion period on some proposal, or if it's an idea that you had that's unrelated to any of the various policy proposals that you've heard this week but it's on your mind and you want to do some show and tell, this is your opportunity.
So come on up to the mics. It is fairly close to 5:00. We've got two remote participants. So if we go past 5:00, they don't sort of start flickering the lights and throw us out, but it does mean that Mark will be angry because I'm cutting into his SWIP BoF. So let's start with Leo Vegoda.
MR. VEGODA: Leo Vegoda, ICANN. I was out of the room for part of the 2009-3 discussion. I just wanted to confirm that IANA can implement that policy if it reaches consensus everywhere and it goes to the ICANN Board and gets ratified and everything.
MR. VIXIE: Thank you, Leo. Let's take one of the remotes.
MS. HUGHES: From Joe Maimon, CHL. So we've got about 3500 members. About 200 participants. About 5 to 6 percent. Is this the appropriate level of participation considering the challenges facing us by IPv4 exhaustion? Is more outreach called for?
MR. VIXIE: Lee.
MR. HOWARD: Lee Howard, Board of Trustees. I would like to ask Joe or anyone to offer a suggestion.
MS. HUGHES: He's got a controversial part as well. We may have to take this one to PPML to answer adequately.
But is there any available breakdown as to who is represented better, small, medium, large organizations? Is it possible that participation is skewed in favor of charging a fee for remote participation if it becomes necessary to support many dozens or hundreds of remote participants?
MR. VIXIE: Thank you, Joe. Lee.
MR. HOWARD: I wouldn't be able to find the message -- Lee Howard, Board of Trustees. I wouldn't be able to find the message quickly, but a couple of years ago on PPML there was discussion that the debate, the conversation on PPML was predominantly, it was dominated by large organizations.
And I actually did an analysis of all messages posted in a month, random month, and analyzed the -- and looked at who those posters worked for. And the phenomenal, the overwhelming majority of posters were from very small- or medium-sized organizations. There were very few posts from large organizations.
I have not done a similar analysis for people at this organization, at the meetings. But I can say that the meeting attendee list is posted online. If somebody else would like to undertake that that would certainly be welcomed and probably useful input, as a response to Joe.
MR. VIXIE: John.
MR. CURRAN: I wanted to also respond to the second part of the question which is regarding the cost of remote participation. Quite frankly, the costs of remote participation are fairly fixed with very little variable component. So the difference between doing this for five remote participants, 50 and 500, is de minimis. So if you have a way of getting 500 remote participants who are actually interested in being involved and paying attention, bring them on, please.
MR. HUGHES: Just one comment on the size of companies represented. There are a lot of people here who represent a lot of companies to try to educate all kinds of flavor of companies, particularly focused on the medium-sized companies that need this kind of help and resource. I see a lot of people in this room that do that. And I wanted to mention that as part of the factor for determining size of company.
MS. HUGHES: Jo is also wondering if the chat room, the remote participation chat room should be opened up to meeting participants as well as remote participants.
MR. VIXIE: I myself have been in the community chat room, because that's where I thought the cool people were. If there's some other chat room that we should all be in so that we and the remotes can all be in one place, I would worry that perhaps a lot of us would spend even more time looking at our laptops and arguing with people and maybe arguing on PPML instead of looking up at each other and participating in real time. That could be why there's multiple rooms. Anybody else want to speak on the current topic? We've got Scott.
MR. BRADNER: I will note that Stacy would need at least two extra hands to deal with 500 remote participants.
MS. HUGHES: Yes, I would. I would be like The Who.
MR. VIXIE: Which of you gentlemen was first? Marty.
MR. HANNIGAN: I just wanted to offer a few more thoughts on community networks. Marty, just myself.
You know, kind of takes me back to -- and I'm not going to talk any ragtime, but I don't know how many people remember ci.pioneer.net and NUUCP and fighter net gateways and things. And I think some of this community stuff, to me anyhow, to be classified as community should be more along the lines of extending the network versus supplementing it in some fashion. Perhaps some work could be done to define it around single provider markets, where there are rural areas that there's value in extending the network and offering some kind of symbolic or symbolic policy or other mechanism.
I know that we don't want to talk about fees. I think it's important to consider them in the grand scheme of things. But, regardless, I still support it, and I don't hate ham radio operators, by the way. I really value them a lot. And I hope it didn't come across -- I hope I didn't come across as a ham hater. I like hams. Thank you.
MR. VIXIE: Anybody want to follow up on community networks? I will say that I am personally aware of some Internet exchanges where $100 a year would be a pain in somebody's butt and nobody minded supplying free cross-connects and power and switches and everything else. But the moment somebody's got to write a check for 100 bucks, now you're talking real trouble. Maybe that's a bad thing and we should not support it. But I did the UUCP thing early on, and there was a lot of free network in it. I think it underlays the industry that we're standing on now. Let's do another remote.
MS. HUGHES: This one is from Ted Mittelstaedt, Internet Partners, Incorporated. I have a challenge for everyone here at this meeting. I challenge you to do at least one thing this week that will advance your own organization's IPv6 development.
If you haven't deployed v6 yet, then spend an hour this week planning it. If you are dependent on another network, then call your sales rep again and -- call your sales rep again and ask for native IPv6. If you have fully deployed v6 on your network then answer someone's deployment question on one of the mailing lists on www.ipv6.org
MR. VIXIE: Thank you, Ted. Was this going to be about community networking? No. Okay. Then we're going to --
MR. FARMER: David Farmer, ARIN AC. I just wanted to invite some comments. The AC since the last meeting has abandoned two proposals and if anybody wants to throw tomatoes at us they should get up and do that. In particular, the protective usage transfer for IPv4 addresses and then there's the sunset of 2008-6 on schedule. Just to invite people to do that if they feel they need to.
MR. VIXIE: I think in general, by the time the AC has abandoned one of these proposals, everybody else has abandoned it first.
Not having the same duty of care that you gentlemen do. Left-hand microphone.
MR. PORTER: Jeremy Porter. Just wanted to ask if the chat, the transcripts from the live sessions would be available afterward. Is there any plan to do that?
MR. VIXIE: John?
MR. CURRAN: Yes.
MR. VIXIE: Given that, it's at or beyond 5:00, I want to say that we're going to close the queue soon. If you want to get in it, now's your moment. Aaron.
MR. HUGHES: Aaron Hughes. I was just discussing this with some people and I've been thinking about this for a little while but wondering what people thought of spending some ARIN resources on writing some tool suites to keep data accurate, meaning -- we've been working at this from allocations and assignments area for some time.
But we haven't been looking at operational tools to, say, incorporate updating SWIP data with allocation tools to configure routers or just even building a nice open assignments and allocation tool that everybody could use commonly so we can integrate with other SWIP data information. Things like that. I don't even know if there's a place to vote in some kind of a use for ARIN resources for this kind of thing, but I see people are still using things from spreadsheets and 40 different kinds of tools. And I don't think our data accuracy problem is necessarily at that level and might be useful for the entire community.
MR. VIXIE: Are you thinking along the lines of an ARIN summer of code?
MR. HUGHES: Well, there's an ARIN website about resources for v6, but -- and I think there's even a little code repository thing. But I think it might be useful to actually write an open standard that works for everybody rather than saying, you know, here's some little things but actually offer some tool suites that work and the way we want them to rather than trying to fix all the companies and get them to change their processes.
MR. VIXIE: The reason I ask of a summer of code concept is the man standing behind you is no doubt programming as fast as he can and managing as many programmers as he can. And if we are thinking that we might want to use ARIN resources for this, we probably mean we'd like to encourage student projects and so forth rather than we'd like to hire programmers and have them develop open source as part of ARIN's mission. And I'm just trying to get a sense of what you're proposing.
MR. HUGHES: It seems to me, generally speaking, in businesses, in companies that have allocation and assignments, people have implementations people, have operations people. The last time compact information gets updated is at the close of sale and the initial request for space. And I would think that working on a tool -- I don't know exactly where in the stack -- to keep contact information accurate and make SWIP easy.
MR. VIXIE: You need to come to the SWIP BoF, I think. Before Woody adds his comment, grab a microphone, will you. I want to say the queues are closed. If you're not standing now, then better luck next time. Woody.
MR. WOODCOCK: Raul was just talking about EPP. And that never even occurred to me. But it seems like most of the work's been done by people who have more at stake -- Mark is shaking his head, like those are those crazy domain name people.
MR. KOSTERS: It was those crazy domain name people who did that. Actually, it's good work, what LACNIC is doing. But one of the things we do want to hear in this BoF coming soon after this meeting is what do people really want, and we have a list of choices that are going to come in this, and they go from incredibly simple to a little bit harder.
So we definitely need feedback on -- that's one point. The other point is we do have this website that was based on suggestion that was made last year. Projects.arin.net. And it has our WHOIS on it and a version of resource certification that -- and we would love to have some more that deal with ARIN-specific sort of tools and puts it in the repository and building it. Summary of code sounds great. Love to do something like that, too. Sounds great.
MR. VIXIE: Any more on this topic?
MR. HUGHES: Sounds like it's going to be covered somewhat in the BoF following this.
MR. VIXIE: Given that we're in the BoF's room, we probably shouldn't also take their topic.
MR. HOWARD: Lee Howard. Great suggestion. I support it more, and probably maybe not here because we haven't allocated time for it, first of all, there's the suggestion process. Great way to send specific ideas for tools that we ought to explore. And then it's on the ARIN web page. And then potentially maybe we could consider having a requirements BoF at some future ARIN meeting so we can get people who are interested in that together or outside of the ARIN meeting because the people here aren't necessarily the requirement writers.
MR. VIXIE: Good point. Cathy.
MS. ARONSON: Cathy Aronson. Aaron's suggestion reminded me now I wanted to ask if anybody had any feedback. In one of the earlier sessions we talked about the problem with the four-byte ASNs, and it might be useful to have some tools and documentation to solve some of the problems that are happening and wondered what people thought about that.
MR. VIXIE: I had the thought that if we somehow could raid the warehouse of energy in PPML and take maybe three percent of the engineering expertise and the passion for good writing and redirect that to the website having to do with four-byte ASNs, it would be as good as Wikipedia on that topic. So those of you who feel like you have a lot of time on your hands for this kind of thing might consider whether that would be a good outlet for you. John?
MR. CURRAN: Cathy, I wanted to double-check. Are you wondering what the community can do more to encourage education of four-byte ASNs or what additional ARIN educational outreach can be done?
MS ARONSON: I guess a little of both. But I wondered what people thought, do we need to do this? Should we bring it up at the members' meeting as something that ARIN should fund? Should we send a fleet to PPML? Everybody seems kind of (inaudible), so.
MR. CURRAN: I will just say certainly it's going to get discussion certainly within ARIN about what we can do to encourage it. It doesn't make a lot of sense to have people applying for ASNs, finding out they get four and returning it and getting two. That's a lot of work for everyone. It would be great for us to be able to somehow get some education. And I'm hoping it's possible. But we're going to be brainstorming internally to try to figure out how do we tell them they're about to get a four-byte ASN and that might not be what they're looking for.
MR. HUGHES: Aaron Hughes again. It is certainly on ISP's upgrade path. It's a code testing issue. It takes some time. It's in progress. The education is not as big of an issue as getting the ISPs to support it. And our tool updates are taking some time. I don't know that there's a lot to be done about speeding that up. But a lot of things need to be fixed like flow analysis tools and various tools we use to make any changes and so on and it just takes time.
MR. VIXIE: Noting we're probably facing a black market in 16-bit ASN transfers if we don't get this done, I'm glad to see it talked about. That is the end of open mic. I now return control of your television set to John.
MR. CURRAN: Okay. Thank you, one and all. This is the end of the meeting for the day. And I'd like to thank everyone for coming. We are starting promptly tomorrow. The schedule is, I think it's a normal schedule. Breakfast at 8:00 a.m. and meeting at 9:00 a.m.
Other reminders. SWIP of the Future BoF as soon as I get off stage. Next one. That's it. Thank you everyone. Stay if you want -- thank our sponsors again.
And that's it. To the extent that you want to stay for the SWIP of the Future BoF, please do. If not, move expeditiously to the door and we'll see everyone tomorrow. Thank you.