ARIN XXVI Public Policy Meeting Draft Transcript - 6 October 2010
Table of Contents
- Opening and Announcements
- NRO NC Election Procedures and Candidate Speeches
- RIR Update - AFRINIC
- Internet Number Resource Status Report
- Draft Policy 2010-11: Required Resource Reviews
- Draft Policy 2010-13: Permitted Uses of space reserved under NRPM 4.10
- Draft Policy 2010-14: Standardize IP Reassignment Registration Requirements
- Policy Implementation Report
- ARIN Board and Advisory Council Election Procedures
- Advisory Council Candidate Speeches
- Board of Trustees Candidate Speeches
- Closing Announcements and Adjournment
John Curran: Good afternoon, everyone. I'm John Curran, President and CEO of ARIN. I'm here to convene the ARIN meeting.
So welcome to Atlanta. Thank you. I have some brief announcements as I call the meeting to order. And we'll get started. First, everyone who has a pager, cell phone, like that, please turn it to vibrate or mute so we can have a good meeting.
We have -- Susan, do you want to do this now? On the slides. Okay. Let's get started. Slide 1. There we go. Thank you. We have the Board of Trustees present for the meeting. Some of us are at the table. I'm a member of the Board, as President and CEO, but also at the meeting we have Paul Andersen. Raise your hand, Paul. Where are you? There you are, back there. Scott Bradner. I know Scott's here somewhere. Tim Denton, very good. Lee Howard, very good. Our Chairman, Paul Vixie, and Bill Woodcock, also at the head table.
Also present for the meeting are the Advisory Council. Rather than reading them all off, I'll ask you all raise your hand or stand up as you might prefer. These are the members of ARIN's Advisory Council. They're the elected body that's responsible for working the proposals and draft policies through the policy development process, making sure we have good policy that's available to you for number resources.
NRO Number Council. The NRO Number Council sits -- we have a 15-member council, three members come from this region. The NRO Number Council forms the body that serves as the ASO Advisory Council and that ASO AC sits as part of ICANN and works on the global policy harmonization. We have three members of the Number Council: Martin Hannigan. Jason Lee -- sorry, Louie Lee, and Jason Schiller. I see Jason. Marty's probably here somewhere.
Okay. Next, RIR colleagues. We have quite a few attendees from the other regional Internet registries. Adiel, are you here? I know you were here. There you are, thank you, in the back.
We have from the RIPE NCC, Axel, Dmitry, Andreas, Emilio and Nick, all here. Nigel. We have Nigel, yes. Thank you, the Chair over there.
From LACNIC, Carlos and Rafael are here. Yes. And yes. And from APNIC, Geoff Houston, Samantha Marks, and Elly Tawhai.
The ARIN management team, folks kind of work with these folks every day. You probably know a lot of them. First and foremost, Susan Hamlin runs the meeting and makes it happen. Thank you, Susan. Mark Kosters, in charge of engineering. Where are you, Mark? Our CTO. Thank you. Mary K. Lee in charge of HR and administration. Leslie Nobile, in charge of registration services.
Bob Stratton, Mr. Money, our CFO, in the back. Myself, obviously. Nate Davis, our Chief Operating Officer, my right-hand man, probably getting something done somewhere. Cathy Handley, director of government affairs, is not here. She's attending the ITU Plenipot meeting, the once-every-four-years ITU meeting. And Richard Jimmerson is off doing outreach at a different conference.
I'd like to welcome also our fellowship recipients. As you know, we have a fellowship program which allows people from each region to come and attend the meeting. We offset the travel costs and costs of the conference.
This year from Canada, Loki Jorgenson. Loki, yes. Thank you. U.S.A., Charity Embley, in back. And from the Caribbean sector, Lyndel Fitz McDonald. Yes, very good.
Welcome first-timers. I know a number of you are here for the first time. I actually met a lot of you yesterday when we had the First Timers Luncheon. Everyone got to meet the staff in a little more -- have a little more personal discussion and questions, learn on the policy process and how we work.
One of the things that happens is we get feedback from that survey -- from that by means of a survey. I have the surveys here. And I promised them that we would draw them so someone would get a gift certificate. The surveys, we need someone to draw from the bowl. Owen, could you please come up here.
Close your eyes. Before I open us up, you do need -- you do not need to be present to win. So I have the winner. And we will mail you the gift certificate. The winner is Christian Tacit. Christian, are you here? Still eating lunch. Congratulations anyway, Christian.
John Curran: We will get that sent to you. Which everyone else will tell you about, no doubt. And emergency procedure. If the alarm sounds, remain calm. Exit the ballroom and locate the nearest emergency exits. All exit signs are lit with red writing. Do not use the elevators. I've never actually read emergency procedures at one of these conferences.
So proceed down the stairwell. It leads outside the building. Walk to the front of the hotel and meet at the parking lot directly across the street or in front of the hotel entrance. The gathered open lot is located on 11th Street. Please wait and do not reenter the building.
I hope we don't need these, but it's good to know we have emergency procedures.
Welcome remote participants. ARIN prides itself on remote participation. We do a webcast and a live transcript. You can get all the meeting materials online. We have chat rooms where you can ask questions that will be read back during the question session. So we have monitors in those. So that's on the record with a virtual microphone.
And when we actually do a show of hands, we have a virtual hands-up practice. So you can actually show your hands during the policy proposals when we're counting interest in one. So I'd like to welcome all the remote participants. Thank you.
Okay. You should all have a participant's packet. Came with your registration materials. It has the meeting program, including a survey form. It has the Policy Discussion Guide, which has all the policy proposals in it, and a guide that covers the policy development process.
You have a copy of the Number Resource Policy Manual, which is our allocation policies as of current. So that's the reference book, which we're changing when we make new policy proposals. Has information about the NRO NC and ARIN elections.
Attendance. We have a very nice meeting attendance. So I see we have 150 in the U.S.; 17 from Canada; two from the Caribbean; 21 from outside the ARIN region, and 72 remote participants. Very nice attendance for an ARIN meeting.
Thank you. At this time I'd like everyone to clap one more time to thank our sponsors, Network Connectivity from Telx. Big round of applause. To say they worked hard to make this happen is an understatement. We have very good connectivity because of their above and beyond efforts.
Rules and reminders. The Chair will moderate the discussions, Paul Vixie will moderate the discussions when we get into discussions about draft policies, giving everyone a chance to speak. State your name and affiliation each time you're recognized at the microphone. Please make sure you realize that we'll try to make sure we hear from everyone before we come back and look forward to your views the second time around.
So share the microphones, I guess, is what I would say. Please be clear with your name, your affiliation, and it would also help when you stand up at the mic if you have a particular view in favor or opposed to make that clear.
Okay. Today's agenda. We're going to have the NRO NC election procedures, and the candidate speeches for electing the open slot that will be open at the end of this year for the NRO NC. We'll have the Regional Policy Development report. We will have the Internet Number Status report on how we're doing in terms of number resources.
And then we'll have the ARIN Board and Advisory Council election procedures and candidate speeches. So it should be a good day getting started with policies.
We have three policies on the agenda. Draft Policy 2010-11: Required Resource Reviews; Draft Policy 2010-13: Permitted Uses of Space Reserved Under NRPM 4.10; and Draft Policy 2010-14: Standardize IP Registration Requirements.
We try to get all those policies in and try as much as possible stay on the agenda for when we consider each one of those.
Okay. Have a ball and bowling pins. Tonight we'll be at Atlanta's swankiest bowling alley, Ten Pin Alley, 7:00 p.m. Buses will load at 6:30 outside the lower lobby. Bring your name badge. That's how you get in. That will be the social for tonight. Great time.
I'd like to introduce the folks at the head table. So working our way from one end to the other Tim Denton, Board member. Paul Vixie. Let's see. Bill Woodcock. Sorry about that. I blank out on names. Bill Sandiford. Thank you, Bill. I'm sorry. John Sweeting. Scott Leibrand.
I blank out on names like that. These are members of our AC. Tom will be doing, Scott or Tom -- Tom is doing the remote jabber, which will be reading questions back in. And we have these folks up here to help -- if the discussion gets low, they'll help put questions in. We will cycle people at the head table throughout the day, so you get to see everyone in action up here.
Okay. Let's start right in. The first item on the agenda is the NRO election procedures. I'm going to ask Jud Lewis to come up and give the presentation.
Jud Lewis: Hi, everyone. I'm Jud Lewis. I work in the Communication and Member Services Department at ARIN. And today I'm going to give a quick rundown on how to vote in the NRO NC election. And after I'm finished talking, we're going to have the two candidates come up and give some brief speeches.
Here we go. What's new? This year NANOG and ARIN meeting attendees can vote over the entire voting period at NRO NC. In the past, it was a bit confusing. NANOG attendees could only vote on one day and ARIN meeting attendees on another day. A lot of people didn't understand what was going on.
It was a lot like a Lady Gaga music video in many ways. But now we simplified it. So now those two groups can vote over the entire voting period. Also new is, remote participants can also cast their vote for this election, as long as they registered for the meeting before the 21st of September. Candidates will be able to provide in their candidate biographies one URL of any social networking site of their choice, like LinkedIn or Facebook or things like that, if they so choose. So voters can then establish a dialogue with them.
What's the NRO NC. John described it a few minutes ago. The Number Council advises the Number Resource Organization's executive council on proposed global Internet number resource allocation policies and serves the function of the ICANN ASOAC. If you want to learn more, you can go to that URL right there, aso.icann.org.
You may be asking: I need to vote, Jud, what email should I use? If you're a DMR, a designated member representative, use that email. If you're an ARIN attendee, use the email that you've registered for the meeting with. If you're a NANOG attendee, use the email that you registered for NANOG with. Note that even if you're a DMR and NANOG50 and an ARIN XXVI attendee, you can only vote once in the NRO NC election.
All right. The details. What? There's one open seat. Term begins the first of the year in 2011. Who can vote? I just went over that.
When? Voting opened on the 29th of September, and it closes today at 5:00 PM Eastern time. And I encourage you to not wait until the last minute to vote in case any problems come up. You can either write to firstname.lastname@example.org or come that way to the election help desk and come talk with me and I'll make sure you're able to vote.
And where? To vote, you go to www.arin.net/app/election, or if you're on the home page, you can click on the "Vote Now" button that appears in the bottom right corner.
Speaking of the home page, there it is. That's not the home page; rather, that's ARIN election headquarters. There you find the voting booth, candidate biographies, based off of questionnaire answers that all the candidates submitted, and statements of support from the community.
A little calendar here. Like I said, voting opened on the 29th. It closes today at 5:00 p.m. Eastern time. Tomorrow morning at the meeting we'll be announcing the winner of the NRO election.
All right. Thank you very much. And I will now pass this over to John, who will introduce this year's candidates.
Andrew Dul: Good afternoon, everyone. Thank you for having me up here. I'm trying to come up with something interesting or witty or something to say to talk about myself. But what I thought I'd do today is talk about three things about our industry that I think are important, and then you can use that to judge me as a person, as well as the information that's available about my bio and other stuff to choose in your voting.
So the three things that I thought I'd talk about is fear, hope, and a challenge. And why fear, hope, and a challenge? Well, it's sort of a good, bad, and something to do about it.
So fear. So IPv6, you know, has been coming for forever. And the IPv4 train is coming to an end, as we all know, with the depletion going to happen probably early next year.
So this morning one of the things we talked about was all the transition technologies. And one of the things that I thought is important to realize is as we go into this transition technology time frame, we need to be very cognizant about the choices we make such that those transition technologies don't become crutches and methods for continuing IPv4, rather than doing the hard work that is necessary to really build the network that will sustain us for the long term.
We can continue to crutch our way on IPv4. But it would really be to our community's benefit, all of the people in the world who will have to use the Internet for the decades to come, to do the hard work now. And that involves showing leadership in our companies and also working to make sure that we add those operational costs that never appear on capital balance sheets and types of stuff in our conversations when we're making decisions about deciding what to do.
So I think there's an opportunity here. And we can do IPv6 the right way, even though it's going to be hard, and we can come out in the end. I think one of the ways that's possible that will actually push IPv6 is those streaming media content providers like Netflix and Hulu and those kinds of people, because those are the type of things we don't want to have to run through transition technologies.
So, secondly, hope. Why hope? Well, I think the thing that is important this year is the DNSSEC has finally made it to the mainstream. We have assigned route, which is a big deal.
And even though it's quietly sort of gaining momentum, I think there's a real air of hope that's possible with this. There's a lot of things that we can tie in, a secure DNS environment, and provide applications and other types of security features that have not been possible before, because we haven't had sort of a single crypto source. So I think that's really a great thing that is happening. And I'm looking forward to how that is going to play out in the future.
And lastly, a challenge. The challenge is to go out and vote. And that might seem simple, but there's been a lot of debate in Internet governance forums as well as here about participation and ensuring that what we've built over the past 10 to 15 years is a bottom process remains.
One of the ways you can do that is to vote in the elections and make your voice heard. And that sends a message to the public that you're involved in this process and you have a voice in making sure that someone has -- making a determination there.
So I encourage you to vote. Not only in the ARIN election but in the NRO election. And the NRO election is different. Every person almost in this room can vote. So I want to make sure that you make sure you have your voice heard.
So I thank you for your time, and I'll pass it back to John. Thank you.
John Curran: Thank you, Andrew.
John Curran: Our second candidate, Jason Schiller. Come on up, Jason.
Jason Schiller: Hi. My name is Jason Schiller. For those who don't know me, I'm a senior Internet network engineer at Verizon, formerly UUNET.
I've had a lot of industry involvement. I've been involved in ARIN, active in ARIN, I've authored policies, I have originated policies, I read PPML. And I'm also involved in NANOG. I've looked at issues of routing table growth including v4 and v6 routing table, and also how we're going to make v6 multi-homing work. Given various NANOG presentations on this.
Also have had some involvement in IETF and served on the Routing and Addressing Directorate.
My experience ranges from enterprise LAN to enterprise WAN to carrier-grade ISP. So I have a lot of varying expertise to bring to the table.
I have a strong technical background. And you can see that from some of the projects I've completed such as rearchitecting our BGP topology in each of continental networks in the former UUNET networks, architecting and designing our various phases over IPv6 deployment, architecting our Latin American network and our multicast network. I'm also responsible for setting global routing policy standards as well.
So why run? There are a number of very important issues that we're faced with in the next three years: IPv4 depletion, IPv6 adoption, we have the transition issues. What happens if the Internet is partitioned, if a large amount of the content is still only reachable over IPv4 and we've depleted our IPv4 reserves and we're only deploying IPv6 networks.
How do we bridge that gap? Do we look for some transitional technology that's going to basically be NAT? Is that going to be suboptimal? Is that going to be painful? Or do we just start building v6-only networks and say, you know, I'm really sorry you can't get to a large portion of the Internet but that will change really soon, I hope.
And how is that going to work in a competitive landscape? What happens if you're the first to run out and your competitors still have plenty of v4 addresses? Are you going to expect your customers to move to your competition?
What if you're the one that has the only one left with v4 addresses in your market segment? Are you going to start doing aggressive business practices because you're the last resort?
There's other issues. I mean, should we just do business as usual until the very end? Or should we do something different? Should we try to have some sort of a soft landing? And is that a good thing?
Is that good because it allows new entrants into the space and allows us to still transition after we've run out? Or is it a bad thing, because the people who have justified need today can't get the resources they need and they hit the wall sooner?
And one thing that everyone's been looking at is the depletion studies and when they're going to hit the wall. And my hope is that they're making the appropriate business plans so that they are v6-capable right before they hit the wall. But if we move where that wall is, we might not have enough time to react.
So these are all very difficult questions that we're going to be faced with in the next three years. I understand these issues. I understand their trade-offs. I understand the technical implications of these decisions.
And I'm well suited to act as an information conduit between our community, between the other communities, between the ASO AC and between the IANA. I have tried in the past when we were faced with global policies or considering policies similar to policies in other regions to try to bring our conversation there and bring their conversation here, to see if we can learn from what they're discussing, to see if they can learn what we're discussing, and to see if we can actually get a global policy proposal.
We have a very big problem right now. The IANA post depletion has no policy for which they can make allocations to RIRs. If someone decides to return addresses to the IANA post depletion, it's not clear what the IANA will do.
Will they sit on those addresses because they have no policy? Will they decide to act based on what they think is the right thing to do or based on some authority they think they have?
So we really do need a global policy in this area. We've already discussed one. We passed different texts in this region than the other RIRs. That's not moving forward.
A bunch of us got together and authored a new -- I should say originated a new policy proposal, and we'll be discussing that later this week. And I urge you to pay close attention to this, because globally this is a very important issue.
Lastly, I'd like to just say thanks. I'd like to thank the community for giving me an opportunity to serve on the NRO NC. I'd also like to thank you for being involved, for participating, for making this bottom-up process work.
And I'd like to thank you for your time and your consideration.
John Curran: Next up on the agenda we have the report I believe from AFRINIC. Yes, AFRINIC report. Adiel, very good.
With regards to the NRO NC elections you can vote now and you can only vote for a short while. So you should now go online having seen the candidate speeches and vote.
Adiel Akplogan: Thank you for allowing me to make my presentation today, because this was originally scheduled for tomorrow.
Just to add that I'm not alone here. I'm here with Philemon, one of our Board members. I think he just stepped out of the room. So I will give you a very brief update of AFRINIC activities since the last time I was here.
Next, please. So AFRINIC has five years this year. And since 2005 we've made a lot of progress in terms of our activity, budget and our membership as well.
This would not have been possible without the continuous support that we have gotten from local community, from the team at work, including the Board, which worked hard, despite a very small team that we had, to achieve our objectives.
We also are thanking the global community for their continuous support, including you participating in our discussion and providing your feedback.
AFRINIC at a glance. We are 19 employees today. Representing approximately 15 FTE. We are 700 active members today. Our budget for this year was $2.1 million, and we are expecting a significant growth next year as well because we are putting a little bit more resources on some new projects and also on hiring.
So far we have run 12 public policy meetings in 10 different countries in Africa. We run 38 training on IPv6 and Internet number resource management in total, where we have trained around 1,000 people on IPv6 and INR training. 19 policies have been discussed in the region.
Three are still under discussion right now. That means within the past five years we have worked on different things and we will continue to strengthen the organization, especially in the policy development aspect.
So policy on that discussion now, we have the IPv4 soft landing policy, which is still open and still under discussion. We have a policy on introducing the contact information in the Whois database. This is also under discussion.
We have a new policy for the global policy, for IPv4 allocation by IANA, the post-exertion allocation. That is a new policy and is still open.
We have the second revision of our policy development process, which has been discussed during AFRINIC 12, reached consensus, and now on the table for the Board for final ratification.
Just to talk a little bit about the post exhaustion allocation policy. We have one policy proposed before, which was also global policy that reached consensus in our region, but not ratified by the Board yet.
That will be ratified probably during the next Board meeting, because actually we were waiting to look at what will happen in the ARIN region related to that policy. Even though it reached consensus in our region, we want to see what is happening, because it's the only region where that policy has not yet been adopted.
As I announced earlier this year in my presentation we were working very hard to move into our new office. The office is now completed. We have moved in our new premises in June this year.
So these are a few pictures of the new office space. We have a training room which we have fully furnished for our training activities because it is an area where we're going to put in a little bit more resources and effort. So we are now well settled down in the new office, more space, and very nice environment for the staff to perform their work.
So what are we busy at now, the engineering and infrastructure area. There are five staff working in that area today. They are very busy reviewing and improving our technical infrastructure, of the five years of operation, we are moving stuff. We are consolidating the infrastructure, and we're actually making Mauritius our main network operation center. Before we have it split between Mauritius and South Africa. We're consolidating everything in Mauritius even though most of the infrastructure allocated in South Africa.
We are also actively, as all the other RIRs, busy developing RPKI infrastructure, both business and RPKI infrastructure. We're doing both together. The project has progressed a lot. We have now completed the integration of the RPKI in our member portal, which is the AFRINIC portal, combined with the Business PKI.
This is working quite nicely. I've actually tested the last release just this weekend, and it's working very well. So we are on track with all the other RIRs on this very important project, which is the RPKI.
We are also working to improve our member portal to add new features like online voting, credit card payment. We are improving the credit card payment facility that we had before.
And one thing that we also are working on, on the myAFRINIC side, is to try to automate as much as possible our membership process. Today there's a lot of things in our membership process which is done manually, and we are trying to remove the manual part as much as we can, so to allow new members to go more smoothly through the process.
In parallel with that, we are also working to release a new version of our Whois server. We are deploying DNSSEC on our infrastructure, and anycasts on the DNS infrastructure as well. Although, those are developed on the technical operation area of AFRINIC.
We have created earlier this year a new member service, which is a service dedicated to our membership. It includes the registration service as we know it today. But also will include the training activities and our IPv6 program, which we are hiring somebody for.
It will allow members to also have a dedicated and consolidated front line for the membership process. Another thing that we have conducted this year is the review of our registration service agreement.
We have collected feedback from our members for the past few months on our registration service agreement. So we have gone through a review, a total review of the current registration service agreement.
This has been completed. We have completed the open comment period. And now we are waiting to implement this as from January 2011. There will be a presentation on this during AFRINIC meeting, the last presentation and a comment on this.
One thing that we have added to the new RSA is an appeal procedure. We have received several comments from people to ask us, okay, what do we do if we got rejected in our request for IP address or you refuse -- what's the recourse do we have? So we have added an appeal procedure to the RSA so that people can make an appeal either to the Board or even to scale it up.
Few figures about our membership and our location. The membership has grown continuously since 2004/2005, actually. These figures are from June of this year. And as you can see, we are seeing more growth in extra small membership, which is where people -- I mean, that's the size of the member that join us mostly. And from these numbers, we can see that South Africa and Nigeria are on the top of the new membership that we are receiving and that we have received in 2010.
So this also is growing. And we are expecting -- actually, we have noticed an increase in membership interests for the past few months or so.
As AFRINIC is one of the -- or the only formal organization in -- in -- active in Internet governance in our region, we are also very active in increasing our cooperation and support to the organization.
Training is one of the activities. We have conducted eight trainings in the region up to now. There's one training actually running in Nigeria right now. We continue to provide support to AfNOG. I know this meeting is run back to back with NANOG. We also have one meeting per year with AfNOG. We provide them with financial and logistical support, because the two communities cross at some point and we rely a lot on AfNOG community as well.
We are improving our involvement and cooperation with government as well. We have set up a government working group in our region. We had the first meeting earlier in January and are planning to have another meeting in November in Johannesburg.
We have been involved with the past IGF meeting where we had two workshops. We have also helped coordinate a few regional IGF events in West Africa and East Africa.
We are also helping to incubate few other regional groups like AfCERT, which is the African CERT organization grouping. They will have two workshops actually in Johannesburg for technical staff offset in Africa and another one for policymakers and managers.
So we want to help this group to be formally organized, because the security issue is becoming very hot in the region.
We have continued as a member of the NRO to support NRO activities in different areas in the EC, in the engineering coordination group and the communication coordination group.
The team is growing. We have hired four people in the past quarter. We have a new event coordinator. We have now a public relations and community engagement officer that has joined two months ago.
We have two part-time -- one sys admin and one business coordinator -- that also joined recently.
We have three other people joining this month. We have a technical editor, a writer joining at the end of this month, and we have an IPv6 program manager that will be also joining by the end of this month.
As I was talking about the growth of the team, this is one area where we have challenges of getting committed and skilled people to join AFRINIC in what we are doing.
We have a few positions open internationally for someone now. And we are still looking for people who want to come down to Mauritius and spend some time supporting what we're doing.
If there's any interest in joining our activities, feel free to write to email@example.com. Positions which are currently open: communication area manager, marketing officer, system engineer. We need two. We are looking for a software engineer, Web developer, and IPv6 program manager.
IPv6 program manager, we're almost done with the recruitment process, so that's almost done. That will be probably announced very soon.
That's it. To close this, I would just invite you to our next event which is AFRINIC-13 meeting that's taking place in South Africa from the 20th to 26th November 2010. You are welcome. Thank you.
John Curran: Any questions for the AFRINIC representative? Okay. Thank you.
John Curran: Next up on the agenda today is the Internet Number Resource Status Report. Leslie Nobile, Director of Registration Services, will come on up and give that.
Leslie Nobile: Good afternoon, everyone. Okay. So this is the Internet Number Resource Status Report. Basically this is -- anyway, this is the number resources that all the RIRs are issuing, all five of us, in a side-by-side format. You can see basically what we've done over the past ten years and how much address space has been issued and ASNs have been issued.
We update this quarterly, and the last time this one was updated was June 30th.
This meeting came up quickly and we really didn't have time to do the third quarter. So the data is just a little bit stale. I'll try to update you when I can, whenever I can.
John Curran: Do you want us to reorganize the agenda or stand by? Two seconds, okay. 1.5.
Leslie Nobile: You gotta start with a glitch. That's the way that meetings start.
John Curran: During this brief delay I will entertain you by singing.
Unidentified Speaker: No.
John Curran: Maybe not.
We're working on it. I ask everyone's indulgence for another moment. This is usually what happens when I reorder the presentations. Only I didn't do it this time, so I'm not quite sure.
Here we go. Yea. Number Resource Status Report. Right click.
Leslie Nobile: I already talked to that one.
So, anyway, this report shows the joint statistics of the five RIRs and it shows the status of the global IPv4 address space. That's our first slide.
So I'm going to start with the top pie, the green one, which just shows there's 35, currently 35 /8s not available for the IANA to issue to the RIRs because they're already in use by the technical community.
For going to the gray pie, going left, the Central Registration Space, that's actually the old legacy space. That was the space that was issued prior to the establishment of the RIRs, and that space was issued under U.S. government contract: The SRI-NIC, the DoD NIC, the InterNIC. And there were 91 /8s issued before the RIRs came about.
In total, the RIRs you can see in the blue pie, in total we have together issued or are still issuing 114 /8s. That's how many of the five of us combined have received from the IANA.
And we further break that down below, in the pie below. You can see APNIC has received 38 /8s from the IANA; RIPE NCC has received 32; LACNIC has received eight; AFRINIC has received three; and ARIN has received 33.
And then probably the most interesting pie is the gray one, and that shows what's left of the total IPv4 global pool. And that's held by the IANA right now.
And it says that there's 16 /8s. However, APNIC was issued two new /8s in July, so that number is currently 14. And this year alone, in the first seven months of the year, IANA issued 12 total /8s to the five RIRs -- actually, just to four of us. APNIC has gotten six of them so far; RIPE has gotten two; ARIN has gotten two; LACNIC has gotten two; and AFRINIC hasn't been in this year.
IPv4 address space issued. This is the total amount of v4 we've issued. We've gone back as far as 1999. We really didn't have space to go back much further. But we sort of track it from '99 through 2010. And you can just pretty much see the growth in all of the regions. And the thing that's really noticeable about this slide is that most of the growth, most of the v4 address space, at this point is being issued in the APNIC region, and they are in yellow.
And another interesting point is ARIN in the blue has really just kind of slid down a bit. We were sort of level for a bit. And we've been issuing less address space. And that's very obvious when you look at this slide. And part of the reason that we think is that a lot of the large ISPs just haven't been coming in this year for large allocations. That's the only thing we can attribute it to. So this is just a similar slide.
It shows the cumulative totals we've issued to our customers in v4 over that same time period. And you can see RIPE has issued almost a little over 27; ARIN, almost 25; LACNIC, almost five; AFRINIC, 1.52; and APNIC has issued the most v4 space in the region over the past ten and a half years.
This is ASN assignments. Early on ARIN was issuing more ASNs than any other region. At this point RIPE has been, since I guess about 2005. And ARIN has just kind of leveled off, maybe even gone down a bit. The other RIRs have been pretty steady.
And this is the cumulative totals. ARIN and RIPE have issued almost the exact same number of ASNs in the past ten and a half years.
This is the 4-byte ASNs. This shows the totals we've issued. You can see RIPE in the green has issued more 4-byte ASNs than any of the other RIRs. This slide shows the cumulative totals. I showed this last night. This is only current as of June 30th. But ARIN has only issued 27 to 28 up to this point, and RIPE has issued more 4-bytes than any other RIR.
IPv6 address space. So this shows the total global space, the /0. There's a /3 reserved as global unicast space and there's 506 /12s left in that space in that particular /3. Five of the /12s were issued to the RIRs. We each received one per global policy in October of 2006.
And there's one /12 that has miscellaneous bits reserved and used at this point. That's the one in red at the bottom.
IPv6 allocations from the RIRs to their ISPs and LIRs. As you can see, RIPE has been making the most IPv6 allocations of all of the RIRs. And last year ARIN issued more IPv6 than AFRINIC, but -- I'm sorry, APNIC. But in the past year there was a policy change in APNIC that said basically anybody who has IPv4 address space can come in and get a /32 of IPv6 space, any ISP.
So we really saw the numbers creep up in the APNIC region over the past year in IPv6 allocations, which explains the difference between ARIN and APNIC.
This is just the total amount of allocations we've made and then the total amount of space. On the left you can see that's the total number of allocations each of the RIRs have made to their customers, to their community. And then on the right we looked at the total amount of the space, the total number of /32s being issued.
You can see some of the RIRs make allocations that are much larger than single/32s, particularly RIPE, ARIN, and APNIC.
So this is a new slide. We added the IPv6 assignments from us from the RIRs to our end users. We weren't showing IPv6 assignments previously. And at this point ARIN has issued more /48 assignments to their customers than the other RIRs. And this shows since policy implementation dates on the left. It doesn't go back to '99.
And these are links to the RIR stats. They're on the NRO site, of course. Each of the RIRs have their own stats, and the raw historical data is at ICANN IANA website. It's all available, if anybody is interested.
And that's all that I have. Are there any questions?
Lorenzo Colitti: Lorenzo Colitti, Google.
I don't know if this is the appropriate forum. I'm curious as to if we just look in terms of /8s, how far away are we from IANA runout? We know the last five are special.
If we look at the trend along maybe the last couple of years of when the /8s are given out, when do we get to five, which is the magic number where things start to change? Do we have a date predicted for that?
John Curran: We actually have someone who specializes in this. Geoff Huston, please.
Lorenzo Colitti: I'm aware of Geoff's numbers. The question is: Does the NRO have a different number or do the numbers disagree at all?
John Curran: No, we all point to Geoff when that comes up because he seems to have spent a lot of time doing it.
Geoff Huston: Today's number is the 2nd of July, I think it is, 2011. They do change, because allocations don't actually conform to a strict model. Quite frankly, if you're going to leave your last request into ARIN for June 2011, you'd be okay. But if you kind of look at APNIC, you might be getting a little bit more worried. But IANA itself, mid next year is the current prediction.
Tony Hain: I do this as well. It kind of depends on how you run the numbers. Tony Hain. Sorry. And as of my last run of the numbers, which wasn't today, it was last week, I actually end up with hitting the -- triggering the last five on February 1st.
John Curran: Ouch.
Tony Hain: Looking at 18 months.
Lorenzo Colitti: Does the NRO have a position on this?
John Curran: The NRO does not take a formal position on the date of runout. We point people to many folks who do extrapolation.
Lorenzo Colitti: Thank you.
Leslie Nobile: Thank you for your time.
John Curran: Okay. So we're now going to jump into the policy portion of the agenda. And the first draft policy we're going to look at is 2010-11: Required Resource Reviews. So you should have a copy of this in the Discussion Guide in front of you.
Draft Policy 2010-11. History. It came in as Proposal 117 in June and it became draft policy. The current version is 20 July 2010. AC shepherds Marc Crandall and Bill Darte.
Summary. Required Resource Reviews. Adds triggers for mandatory reviews to the existing resource review policy. Whenever a transfer is initiated with ARIN or ARIN becomes aware of a transfer -- when a transfer is initiated or ARIN becomes aware of a transfer where the customers aren't transferred, is what that probably should read.
Owen DeLong: Customers are transferred but not addresses.
John Curran: Where customers are transferred but not the addresses. Thank you, Owen.
Now, we already have a resource review policy. What this does is it makes mandatory the staff initiating specific resource reviews under these circumstances.
Status in all other RIRs. Unique proposal to ARIN. There's nothing comparable to our knowledge in the other RIRs.
Staff assessment. Legal liability. No significant legal risk. Issues or concerns. The proposal could cause us to conduct resource reviews on a more frequent basis. Any prescription for prioritizing such reviews could delay other important work from being processed.
So literally this creates work that's not predictable, that's outside of our control, but that's mandated by policy. That work would have to get done or at least initiated in a true and faithful manner.
And that means we don't necessarily control the prioritization of other things. We probably would still get a meeting held. But I don't know if we have a lot of requests what would get set aside during any time period.
Resource impact. Potentially moderate. These are fairly intensive -- resource-intensive activities where we contact you. I think some of you have been through this process. We contact you. We ask for your records. We ask for your records from another form. We look at configurations. We ask for documentation about your customers.
It can be an extensive, time-consuming process. And at the end of the day, it could affect the budget of ARIN if we have a prolonged period of these to the point where we fall behind in regular work. It might impact the staffing and the size of the organization.
So that concludes the staff assessment.
PPML discussion. Five posts by four people. Two in favor. Zero against. Though, someone said: I don't want to see significant ARIN resources dedicated to this, but auditing where it's warranted as suggested by 2010-11.
And someone who said they're opposed to reclamation techniques that step up the confrontational and adversarial relationship between ARIN and address holders, even if it's essential for continued consumption of IPv4 and we had no IPv6. I view increasing auditing and mandatory triggers of audits with similar concern.
Those are some of the comments on the discussion.
That concludes the introduction of Draft Policy 2010-11. I'll invite Owen up to give his presentation on it.
Owen DeLong: Okay. That should work. So since the inception of Section 12 of the NRPM, there's kind of a community perception that it's seen minimal use, and that was kind of the driving factor in this policy.
It turns out the staff has actually been quietly using NRPM Section 12 more than a lot of us probably realize. So some of that may be less true than we thought.
The authors are aware of several recent events which seem to warrant Section 12 reviews, but it's not apparent to us in the community that they necessarily happened. And in the past staff has actually on occasion suggested that guidance on when Section 12 should be used would be useful. So what we actually do is we set forth a few limited criteria under which resource reviews are required to be conducted of an organization under Section 12. And I'll talk about what those triggers are.
The first trigger is an organization which sells or transfers a significant customer base and/or infrastructure to another organization without transferring the related addresses, we felt that at least ARIN should do something to ensure that the organization that transferred the customers and/or infrastructure had something else they were doing with those addresses that was legitimate rather than just keeping them for some random future use without having them subject to verification.
Another trigger: If ARIN receives a credible report of fraud or abuse, the term "credible" is left to staff discretion to define to some extent. Abuse is construed specifically in the narrow concept of abuse of ARIN policy. It does not relate to generic network abuse.
ARIN doesn't really have any ability to even define what generic network abuse is. It specifically does not cover host abuses like spam, malware, botnets, et cetera. That's just not ARIN's purview; that's up to the ISPs to deal with.
So what are some of the other triggers? If a Section 8.3 transfer recipient is getting address space and hasn't been recently reviewed, mostly this just expands the existing practice of the way they would qualify for the address space to include making sure that they're using all of their address space rather than just the most recent stuff.
So in this particular trigger, it wouldn't be a major impact, we don't believe.
Another case is overuse of the residential customer privacy. The specifics of the policy aren't quite as they were stated in the introduction. What it specifically says, if you've got more than 25 percent of your total address space issued to residential customers under residential customer privacy, which means it's in chunks of /29 or larger assigned to those residences.
So this is an ISP that is assigning /29s or larger to residential customers such that they constitute more than a quarter of their total address space.
This shouldn't really impact any legitimate ISP that exists today or is likely to exist, because almost anybody that's issuing large address chunks like that to residential customers also has business customers and other larger users of address space that are using at least 75 percent of their address space.
So if you're using more than 25 percent of your address space hiding it this way, more than likely you're doing something dodgey to skirt ARIN policy, and it's at least worth having ARIN look at that before they give you more address space. Because, remember, this doesn't trigger until that ISP asks for more address space. If they show that their use of that space in that 25 percent is legitimate, then they pass the resource review and we all move on. It doesn't really discriminate against anybody. And it only applies to IPv4. Does not carry forward into IPv6.
So the research that I did and a couple of other people did failed to identify a single residential ISP that would be affected by this as it currently stands.
Again, the concern here is to prevent somebody from doing something that could be used to skirt ARIN policy going forward when we get closer to runout.
Smaller thresholds would run the risk of accidently discriminating against legitimate residential ISPs. That's not what we wanted to do. Generally speaking, if you're obscuring 25 percent or more of your address space, the community at least has a reason to ask some questions.
And then, finally, 12.10(e) basically says that, other than 12.10(c), each of the criteria represent a specific suspicious use case which may be asynchronous to other events. So those events, those triggers are exempted from the two-year free ride that you get if you've been through a recent resource review.
And, finally, in the rationale, there's a typo that talks about comments referring to 12.10(e). The comments that it actually addresses refer to 12.10(d).
In closing, I'll say most of the behaviors addressed by this policy have been observed in recent history in one form or another.
The second bullet I'm told is not quite as people perceive the facts to be, so I won't dwell on that.
And, finally, as addresses become more scarce, the level of abuse and such is likely only to get worse.
And, with that, I'll open it up to discussion.
Paul, if you'd like to come up and moderate the discussion.
Aaron Hughes: Aaron Hughes, 6connect.
I like this proposal. It looks great. I'm only curious about the first trigger. How does one identify that a transfer of assets has happened and not the IP resources that could go along with those customers since the retainer of those IP resources would probably not be going back to ARIN for resources?
Owen DeLong: Well, presumably there are a variety of ways. It could go in through a fraud report. It could go in through the person who received the customers coming to ARIN and asking for this big chunk of address space for all these customers that they got out of the blue. I would think staff would go, "Well, where did those customers come from?"
Things like that.
Aaron Hughes: I like this and I support it as written.
Owen DeLong: Thank you.
Kevin Oberman: Kevin Oberman, ESnet.
First I have a question with regards to policy here. This first section replacing the text under 4.6 in Section 12 with -- in paragraph 7 with under paragraphs, blah, blah, blah, this looks to me like it's simply an editorial change to correct an oversight because the current reference is simply wrong.
And I'm not sure why this needs to be in a policy proposal. Does it need to be a policy proposal change or is it simply an editorial change that should be corrected by ARIN?
Owen DeLong: I think as long as we were making changes to the policy for the other purposes, it made sense to make the editorial change at the same time.
Kevin Oberman: I agree that the editorial change needs to be made. I mean, if people read this and go look at 4.6, they're going to be very, very confused, since 4.6 really doesn't cover this.
My major concern is we've got an obvious yes, this should be done, mixed with a policy which may have some controversy, and we've had that happen before in the results in the policy not receiving consensus when one part of it clearly should be done, which is why if it has to be a policy proposal I would much rather see it divided into two proposals so that the one that is totally noncontroversial could just happen and we don't have to risk it falling on the floor and having to be resubmitted later.
Other than that, I support this proposal. I am a little concerned about Section D. It strikes me that the home service providers, cable companies, and ADSL providers primarily, perhaps a couple of wireless providers as well, this means that they potentially are going to be doing an awful lot of audits on those folks. I may be wrong. But if not, could you explain why we're not going to be doing a lot of audits on those folks?
Paul Vixie: I want to note that the editorial change will inevitably be made, whatever happens to the rest of this policy, as to the question.
Owen DeLong: As to the question about the residential providers, most of them are giving /32s to their customers, not /29s and larger. This only happens if you're doing things that are SWIPed, which would mean /29s and larger and hiding those 29s and larger behind residential privacy.
So the vast majority of residential providers that are legitimately assigning addresses to their customers are as it currently stands, current common practice, not affected by this policy.
Paul Vixie: Left microphone.
Mike Joseph: Mike Joseph, Google.
Also a bit concerned about Item A in the trigger. Specifically when referring to acquisition or merger, is it the intent of this policy that an acquisition of a company with resources should always trigger audits of those resources, or only if --
Owen DeLong: No, this actually triggers if you sell a bunch of your customers and the infrastructure supporting them and don't send the addresses with them.
Mike Joseph: And I suppose the following question, then, becomes with the ambiguity of even detecting the first condition, how do you differentiate that from the example that I just gave?
John Curran: So we have had occasions where an organization comes to ARIN and says, "I have done a business transaction. I now have a lot of customers. I don't appear to have -- I have equipment even but I don't appear to have ISP addresses; that wasn't part of the arrangement."
Well, that makes us scratch our head and wonder: If you got the customers and infrastructure traditionally, that would meet the requirements of transfer under Section 8; we'd expect the IP addresses to be transferred with the infrastructure.
When someone comes to us and says, "We're asking for addresses because a large number of customers and infrastructure has been transferred and we didn't get the addresses," this would mandate us going back to the other organization that didn't transfer the addresses and conducting a resource review.
Mike Joseph: All right. Thank you.
Paul Vixie: Right hand mic.
John Springer: John Springer, Inland Telephone.
Owen, if somebody announced an intention to sell or transfer their IP addresses after the sale of customers to be a valid use of that trigger review?
Owen DeLong: I'm not sure I understand the question, John.
John Springer: We're going to have a situation arise where people can do transfers. So if somebody says, "Okay, let's just dismantle this business unit and sell the customers and the equipment to somebody, and then let's sell the addresses separately on the transfer market," is that going to -- is that going to be a valid use of those addresses? Are we going to look away from that?
Owen DeLong: We're not necessarily going to look away from that. They're going to at least get audited for -- I'm not sure what would happen in that case. That's a case not addressed by this policy. So I'll turn that over to John Curran for interpretation.
John Curran: If this policy was passed and an organization moved customers and infrastructure off addresses but retained the addresses, this would cause a resource review to be triggered.
Now, simultaneously, we have a policy out there that allows someone to list resources that could be freed up, okay, specifically for specified transfer. We have a policy that allows that.
So there could be a race condition here where effectively you have a circumstance where either policy is applicable. You would be subject for review, but you also would be simultaneously potentially listing and/or transferring the resources.
So this would have to be disambiguated along those lines. Now that you've pointed that out, almost certainly the staff would come back with a recommendation on that.
John Springer: Would the justification of immediate future growth satisfy the requirements of the audit?
John Curran: Yes. In fact, any justification that would put them to use, I guess the only question that comes up is if you freed them up to make them available for transfer, okay, this policy would indicate that under resource review those would probably be reclaimed.
And that might be interesting given that we allow such transfers under specified transfer.
John Springer: Thank you.
Paul Vixie: Center front.
Matt Petach: Matt Petach, Yahoo!.
As it stands, I have concerns about this policy from the potential impact on the ARIN staffing. There's also two points that I'm a little bit concerned about the wording or confused about the wording on. Section 12.2(c) of the existing policy seems to indicate that a full review would only happen once every 24 months.
Owen DeLong: Correct.
Matt Petach: Would the new policy supersede that if you got multiple reports of fraud within a 24-month period?
Owen DeLong: Yes.
Matt Petach: So would we need to amend Section 12.2(c)?
Owen DeLong: No, because the new policy specifically states it does supersede 12.2(c) for each of the triggers except the transfer case. If you read 12.2(e), it covers that. 12.10(e), sorry.
Unidentified Speaker: In the new policy. Very last statement.
Matt Petach: Excellent. That also addresses my second concern.
John Curran: So, as written, would you be for or --
Matt Petach: With those clarifications as written, I would actually be in favor of that, yes.
Paul Vixie: We're going to be asking for a show of hands in favor and opposed to this in the general -- after the Q&A is finished.
Rear center mic.
Alain Durand: Alain Durand, Juniper Networks. Do we really need a policy where that goes into some very specifics about what staff is doing or not?
As kind of an overall concern that I have in some of the policies to discuss this week or have been discussed previously, that we tend to develop policies that are extremely specific, that goes in with a microscope into some of the details, where I think we'll be much better off letting staff interpret things and essentially trust them to do their job or ask the Board to give guidance to staff to do their job a certain way.
And I don't really understand the need for a policy.
John Curran: John?
John Curran: As I understand why this policy was proposed, there was concerns that the staff had a tool at its disposal, Section 12 of the NRPM, and it was not using it as frequently as the community might expect.
So in the past the policy did give that discretion to the staff about when to make use of this policy based on its judgment.
And I guess this policy is a reflection of the question of that's been tried, if you want to ensure resource reviews are happening, you have to mandate that they be initiated under specific circumstances.
So to the extent that the community adopts this policy, it's saying yes; it's saying effectively the staff discretion way isn't the way to do it.
Paul Vixie: Left hand.
Stephen Middleton: Stephen Middleton with Verizon.
I'd like to go back to the original or the first motivator of this policy in that there was a perception that ARIN is not performing their duties as policy has stated. I would think rather than creating a new policy to mandate ARIN's behavior, how they spend their money and time, I would like to see ARIN report on what they're doing already.
Adding a layer of transparency, without specifics, metrics in the resource reviews, fraud investigations, and hijackings that they currently work would be helpful in moving forward with any policy that mandates ARIN's expenditure of time, resources and money.
So perhaps pausing on this policy to allow ARIN to report on that for a period of time would be wise.
Paul Vixie: Thank you, John.
John Curran: So I think the request for metrics is a good one. We'd be happy to take that one on. That's just good management. And we should have it for this. I just want to make sure, I don't think there was a report that ARIN wasn't doing its job. It's that ARIN wasn't exercising an optional policy as often as it was expected.
Paul Vixie: Marty.
Martin Hannigan: Martin Hannigan, Akamai Technologies.
I'm currently experiencing a Section 12 audit. They're very expensive, time-consuming. They utilize extensive resources from ARIN's perspective and from mine.
I support Section 12. I also support, and I usually don't support, the flexibility of staff; I like to have policy that spells things out for me.
In this case, due to the complexity of these audits and the cost of the audits, I would echo my friend from Verizon's comments where I'd like to see some statistics and see how if this really is a problem from the community's perspective.
And I just -- I'm not clear what the problem is that we're trying to solve without those statistics, but as it's written, and with the ability in code or codified to repeatedly perform audit -- audit -- audit the utilization of my resources, which, again, I completely support, I'm opposed to this proposal. Thank you.
Paul Vixie: Thank you, Marty.
Rob Seastrom: Rob Seastrom, Afilias.
I understand the problem statement, but I would suggest that perhaps rather than codifying this in the policy, which is a very, very inflexible situation in terms of allowing staff to set appropriate priorities, that a more reasonable place for the staff to look for guidance on applying Section 12 would be upper management and counsel.
And I would like to ask John whether any suggestions have come in via the ACSP that say, "Hey, can you guys like step this up a little bit? It doesn't seem like you're doing this."
I wonder if -- the policy is an awfully big hammer. And I'm not sure that I support putting this in policy. Although, I support the general sentiments.
Paul Vixie: John, before you continue. I want to note if you are planning to ask a question, I'd like to see you in queue right now.
John Curran: So we will perform -- we do perform resource reviews. We'll continue to do so. I think we need to add stats now that it's been considered an issue that you folks need reporting on.
With respect to increasing it, we're happy to increase it to the extent that it makes sense. Right now the problem is a lot of these reviews, for someone who is willing to create a sufficient fantasy, fake organizations, fake customers, fake addresses and keep it all self-consistent, it can be pretty hard to figure out that they're to some extent trying to pull one over on the community.
So a lot of these reviews don't yield an action because at the end of the day we get done, and even with an extensive amount of work we don't see anything amiss contrary to policy.
So we can increase the rate of them. I guess I'm concerned. What I'd like to hear is if there's a particular problem or a particular type of review that you always want done, that might be much more helpful than saying all of these trigger conditions are ones that we need them done on. We're sort of right now making mandatory a whole group of items, but I don't know whether all of those are actually problems that the community worries about.
Rob Seastrom: I'd like to zoom in on one thing you've said, which is now that we understand that that's something that statistics need to be reported on, I suspect that it may be -- that this may be more a matter of perception rather than a matter of reality.
And I am not in support of policy changes to fix perception problems. Thank you.
Dave Barger: Dave Barger, AT&T.
I guess first question: The 25 percent obscured SWIPs, just curious, where did you come up with 25 percent? Does it just seem like a good number? Because real quickly we're over here doing the math, because I'm thinking we're at like 25.15. So just curious.
Are you saying that -- so if we have this much address space and 25 percent of that total space is SWIPed as private customer --
Owen DeLong: Correct.
Dave Barger: Correct? You're not saying that 25 percent of all the space that's SWIPed? Because we also report --
Owen DeLong: No, 25 percent of your total overall address space.
Dave Barger: I wanted to make sure we're clear on that.
Owen DeLong: I believe you would not be affected by this from my review of Whois.
Dave Barger: I don't believe we would either. But that's a point that could be read different. I read it three different times, and it could be interpreted differently. It might offer a little bit of clarification right there.
Owen DeLong: The intent was to set the threshold high enough that it didn't impact legitimate use.
Dave Barger: I think we're fine. And one other question. Let's see. Where you talk about the fraud and abuse of an IP address block, you go on to explain the definition of abuse. But what about fraud? And I'm just wondering if that needs to be explained as well, or if that could be just dropped from the wording.
Because when I think a fraudulent IP address use, I think of hijacking address space and things like that; that may not be something you can penalize somebody for because a guy who is doing the hijacking doesn't own the address space in the first place.
So I'm just wondering if we need to either drop the word "fraud" from there or explain that like you did with abuse.
Owen DeLong: So I think, actually, we're not looking to penalize anybody with these resource reviews, so much as to have the legitimate use of the resources verified. Generally speaking, for a hijacker to hijack something, it has to be in disuse or non-use to be successfully hijacked in a useful manner.
So I think having ARIN review the legitimate use of the holding organization works out just fine in that case. And, again, this doesn't -- this isn't a penalty policy. This is an examine what's happening here and make sure it complies with policy policy.
Dave Barger: Do I have time for one last comment?
Paul Vixie: I'd like to get to the fellow behind you. The microphones are now closed. The queues closed.
Alex Ryu: Alex Ryu from KDL. I'm curious whether you look at the cable modem provider for that 25 percent usage guideline. A lot of the littler cable modem providers, Triple Play provider, they may only have -- most of their customers are residential customer. They may not have business running around the town to consume the 75 percent of their usage. In that case, when they recast additional IP address, they may hit this policy every time.
Alex Ryu: I think a lot of cases, they just use /24s, those bigger block as a kind of like DHCP pool kind of information. They kind of use the same address for the big subnet to make it simpler.
Owen DeLong: Again, that wouldn't trigger it, but we'll take it under advisement.
Paul Vixie: Last question.
Justin Deckness: Justin Deckness, Tri-County Telephone.
I have a little concern with part A, because I'm kind of visualizing -- help me with this -- a nationwide ISP pulls out of a small market where they only are providing, say, a /24 to that market. Another company comes in, purchases it, gets all the infrastructure and everything, but the national ISP retains their IP space. Correct me if I'm wrong, but this says that you're now -- you're now going to review the huge ISP's entire address space over a /24.
Owen DeLong: Yep.
Paul Vixie: One question from the panel.
Tom Zeller: I have a remote question here: Is there a definition available for certain circumstances? And why not all circumstances?
Owen DeLong: Well, the certain circumstances is in the presentation, not in the policy. The policy does define those circumstances rather thoroughly.
Tom Zeller: Okay. I'm just reading the remote question.
Paul Vixie: Thank you very much.
John Curran: Thank you, Owen.
John Curran: Okay. One of the things we do at ARIN is we provide advice to the Advisory Council as to what the community thinks about a policy proposal, whether or not it should be advanced or not.
When we do this particular matter, we do it by using --
Are you going to do this for me?
Paul Vixie: I'm going to do it. Sorry. John did this last meeting. So --
John Curran: I saw you sit down, so I thought --
Paul Vixie: That's okay. I'll get it eventually.
Noting that ARIN is not a direct democracy, we do not vote on policies; neither the public, nor those in the meeting, nor the members, get to vote directly on whether policies are to be passed. The Advisory Council would still like to know what is the preponderance of opinion.
So we're going to ask for a show of hands, those in favor, those opposed, in order to give that guidance. So we have our tallyiers.
And if you could hold your hands up nice and high and keep them there until we've counted them all, all those who think this policy should go forward.
Okay. Thank you.
All those opposed, think it's a bad idea and you would like to see it dropped. Nice and high. Okay. Thank you.
Your input will be passed on to the AC. And now we're ready to go to the next policy.
The bean counter. Oh, my goodness gracious. This hardly ever happens. We have 158 people in this room. Number in favor, 33. Number against, 33.
(Laughter and applause.)
John Curran: That should help the Advisory Council do their job.
John Curran: Moving right along, our next policy proposal is Policy Proposal 2010-13: Permitted Uses of Space Reserved Under NRPM 4.10.
So original proposal was on the 18th of June this year. Draft policy of petition, 4 of August. The current version has been updated as of the 23rd of September.
Draft policy is under control of Owen DeLong, gets the petition. It has AC shepherds Scott Leibrand and Bill Sandiford.
Summary. It changes the policy of dedicated IPv4 block to facilitate IPv6 deployment. It sets aside the entire last /8s that ARIN receives for networks transitioning to IPv6 as opposed to the current policy which sets aside a /10 of that space.
Any IPv4 address space returned to ARIN and not subject to global or regional transfer policy gets added to this transition pool. Establishes four classes of requesters with four different pools to draw from.
So in the other RIRs, AFRINIC, their reserve space. They have an IPv4 soft-landing policy. In the APNIC region, they have a policy that says organizations can make one request for a minimum allocation. And in the LACNIC area they have a policy the last /12 is reserved for new ISPs and critical infrastructure with one application per party. And the RIPE NCC has a policy that allows one /22 from their final /8.
So staff assessment. Legal liability risk. Pending. Actually, it was cleared as of yesterday. I think it was posted to the list that there's no legal concerns about this policy.
Issues and concerns: Complicated. Hard to understand. That makes implementation always amusing. Seems to be a little bit out of order in terms of understanding the reservations and the qualifications for the reservation which follow. There's a requirement to hold a two-year reserve, which means that some people can apply and not be able to get space even though we have it because we have space under reserve.
It will effectively supplant the waiting list for unmet resource policies for those people who meet these criteria. And there's a requirement to verify -- I'm not sure if there still is -- is there still a requirement, Owen? Yeah, still a requirement to verify X percent of a organization's content. Is IPv6 reachable. That might require some interpretation and work to accomplish.
We can probably handle these, but they're -- obviously the complexity of the policy means quite a bit of work to implement. And it also means that we'll be doing allocations for blocks smaller than /24, which has some implications for how inverse DNS is done. Effectively we would have to get involved in reverse DNS in a way that's unexpected.
So discussion. 44 posts in favor. Sorry. 44 posts by 13 people. Four clearly in favor. Five clearly against.
Some of the comments: Unless a policy has actively caused serious issues, even if all it accomplishes is preventing more of the last /8 from running through at the same rate as current, I'm going to support it.
I have to admit my choice of a policy strategy when it comes to IPv6 adoption is to go with 4.10 as is. I believe this is a misuse of a whole /8 and that a /10 is already designated is sufficient. I think a large part of the ARIN community wants to have all the details of an IPv4-IPv6 transition figured out before IPv4 runs out.
A noble goal, and to the extent it's possible it should be done, but it's important to realize, though, it's not possible.
So that concludes the discussion. I'll invite Owen up to give a presentation overview of the proposal.
Owen DeLong: So if only the world we live in is as simple as we would like our address policy to be.
So what are the problems we're addressing? Well, there's a lot of uncertainty about runout. The last bits of IPv4 really should leverage our progression towards v6. And there's very limited guidance to the ARIN staff in the original 4.10, which was intentionally, when it was created, left to be improved upon later, because we figured at the time we really didn't know what transitional technologies would emerge.
It turns out they mostly haven't. Some disadvantages to this policy, yes, it's complex and has a lot of moving pieces. There are a lot of compromises in it, which has made it more complex.
But a very large number of people worked very hard on this policy, and believe me when I tell you there's no ideal solution and we really felt that this was about the best we could do among the group of us that really struggled to try and put this together.
The advantages to this policy. It ties every address in the last IPv4 space to real IPv6 deployments. You don't get any of this unless you are really deploying IPv6 on your network. It tries to provide a certain measure of fairness and certainty to the allotments from the last /8 and it tries to balance a whole lot of different trade-offs as equitably as it can.
The fact that almost everybody is equally pissed off by this policy pretty much seems to be a sign that we got pretty close to the mark on that.
It does provide for more granular address distributions after runout. It does prevent some large land grabs that could be possible under existing policy near the end. It's not a rationing system and doesn't make any effort to delay exhaustion; it just tries to get us there in as equitable a manner as possible.
Yes, it's a complex policy. It's trying to address a series of complex problems. We really have spent a lot of effort simplifying it. If you think this is complex in its current form, you should have seen some of the earlier drafts.
We really tried to strike as fair a balance across the variety of stakeholders as we could. And nobody is going to get enough IPv4 after IANA exhaustion if they need any IPv4. That's just pretty much the way it's going to be, and we all should face that.
So this policy really started out simple, as an effort to clarify the intended uses of the existing /10 reservation in 4.10 and not much else. Unfortunately, there were a number of groups that expressed there was a need for more.
And to address a variety of other issues. And as the number and types of requirements that we tried to balance grew, so did the complexity of the policy.
Scott, do you need to interrupt me?
Scott Bradner: Scott Bradner speaking for himself.
While you're talking, just is there any interaction between this and the transfer policy?
Owen DeLong: Not really.
Scott Bradner: If somebody is pushing the transfer bits through ARIN, it doesn't apply?
Owen DeLong: No. It specifically exempts transfers.
So why did we go to a reservation system? To try and provide a certain amount of predictability and to try to increase the fairness of the system, is what it boils down to.
The reservation system does not, by the way, guaranteeing people two-year reservations. It's allowing for them to define what their two-year need is and then it cuts the amount they're going to get down to where everybody gets roughly the same percentage of their two-year need after runout.
And they get that on a quarterly basis if there are enough addresses to do more than one quarter worth of allocations to people. But most likely I expect it's going to be so thoroughly oversubscribed it won't be an issue; that we'll hand it all out in the first quarter and move on.
It makes an attempt at providing a fair proportion to people, and it's staged to try and prevent a strong first-mover advantage that was sought by some stakeholders in some of the other policies that exist.
Before depletion, we vet reservation requests on a two-year justified need basis. That's a typo there. Or actually just didn't get updated to the latest version.
And at depletion, we scale the approved reservations to fit the available space to the extent possible. If we've already cut everybody down to the minimum and there's still not enough space, then the reservation holders all receive minimum allotments on a first-come, first-serve basis and the remaining reservation holders become the beginning of the queue for allotments as space is returned.
After depletion, a reservation queue is created and people don't get a two-year or three-year reservation. They get a -- basically a quarterly allotment of space in the queue and then they can resubmit.
Reservations move from a two-year to a three-month basis. And any reservations not issued at depletion are first in the queue.
The queue is satisfied on a first-come, first-serve, from any space received through returns or other means. And if you get a partial fill of a quarterly allotment, you remain at the head of the queue until you receive the rest of what you're entitled to.
It creates four basic categories of IP address consumption, or four classes. It does not create four separate pools to draw from. It does set aside the original /10 for that intended use as it was in the original policy. The other uses all draw from the same common pool. But they do each have their own maximum amount they can exhaust the pool by.
Access service and end sites get category A, content and infrastructure servers get category B, high-ratio transition-specific technologies are in category C -- that's basically the original 4.10 usage -- and critical infrastructure is category D.
Why did we create these categories? Well, each of these different classes has different utilization patterns and requirements. And there was no fair way to do kind of a one-size-fits-all policy. So we set aside specific requirements for each category of usage to try and fit that category fairly.
Organizations can request reservations in multiple categories. So if you have both content servers and you're an ISP providing services to your customers, you can get a reservation in each of those two categories.
Category C is guaranteed at least a /10 from the global /8. Categories A and B are limited to no more than a /9 from the total /8. Obviously they can't both get a full /9, but this prevents one from just absolutely overwhelming the other.
Why the pool size variation? One reason is there will be addresses added to the pool after depletion potentially. Returned address space. The size and extent is not yet known. And so the policy attempts to provide a fair mechanism for utilizing those resources.
Why would you want to pass this policy? It is far from perfect. There really is no possibility of perfect policy here. We tried to make this as fair and balanced as possible, and I think we did reasonably well.
I do think it's better than the current policy and just going on with the status quo until we hit the wall. And if we want to have a clear policy for transition space that's meaningful, we have to pass something at this meeting, otherwise the space isn't going to be there to set aside by the time we roll to the next policy cycle.
Our next meeting will be after IANA runout by the most likely projections, I believe. IANA's probably going to run out in February.
Once that happens, ARIN will likely begin allocating from that final /8 prior to June of 2011 which is probably the earliest policy from the next meeting could get implemented outside of emergency action by the Board. This policy really was a team effort. My name and Chris Grundemann's name are on it at this point. There are a lot of other people who worked very hard with us to try and make it happen, some of whom ended up not supporting the policy in the end. That's okay.
I want to thank everybody who worked with me on this, even those that ended up not supporting the policy. It was a balancing act. Recurring theme as we debated and modified this policy was large versus small advantages.
And some of the people that ended up not supporting this are because they think it's not sufficiently fair to the large providers, and there are other people who think it's not sufficiently fair to small providers. The reality is we really did try as much as possible to seek balance. And get the pain distributed in as equal a proportion as possible.
And, with that, I will pass it over to Paul.
Wesley George: Wes George, Sprint.
I need to ask a couple of clarifying questions whether I say I'm for it or against. There are a couple of different references in the policy to requesting blocks in size of /28, /29, /25. Is the expectation that that would be given to an end-user and they would then be expecting to route that on the network?
Owen DeLong: Unfortunately, I think that's going to be part of the reality we face with these last tidbits of address space in the v4 world.
Wesley George: Given that, I'll say this. I supported the petition for this policy because I thought there was probably value in having more discussion about it. And trying to come to some sort of an update to this policy, I agree with you that we've got to do something now. But I can't support the policy the way it's written right now because I think that's essentially useless, to have allocations that small.
I understand that there are going to be situations where trying to divide things up over the right number of folks in order to give everybody a little piece is going to end up with a lot of these little tiny pieces. When things possibly come back, the size that comes back isn't necessarily going to divide evenly into the amount of folks that need a part of it.
But ultimately I think that's where it would make more sense to try and aggregate it up a bit, because, otherwise, as an operator, you're putting me in a really difficult position. My stated policy says that the smallest announcement that I will accept in the global table is a /24.
With this, what you're essentially doing is forcing me to either have to basically tell those customers to get stuffed, because it's not going to route on the Internet anyway, or update my routing policy and therefore carry a whole lot more junk in the routing table that is not necessarily -- even if I do it for the stuff that comes out of this policy, it sets a precedent that I have to start doing it for other things.
So, if nothing else, you need to clean up the language here so that it's very obvious that this is only applicable to one certain block or one certain portion of a block so that, if nothing else, I can filter based on the assumption that this is the only place that I'm going to see /28s or /29s or /25s that are going to sit in the global table.
And even then I'm still kind of on the fence as to whether or not it makes more sense than simply saying the limitations are what they are and there's no value in trying to allocate those small of a blocks just in order to try to be fair to a larger amount of people.
Paul Vixie: Thank you. Left-hand microphone.
Dan Alexander: Dan Alexander, ARIN AC.
When I look at the wording of the current policy as it's written, aside from this proposal, it's stated in Section 4.10 that maximum size out of this /10 is a /24. And then it goes on to say that no organization can receive allocations from this /10 more than every six months.
So given a /10 that is set aside for this purpose, and around 3,000 ORG IDs that are currently out there right now, I fail to see the rush and the sense of urgency that this is going to deplete overnight. I think there are plenty of safeguards in place that this could potentially last for two years or beyond. So I'm at a loss as to the problem we're trying to fix.
Owen DeLong: The urgency is if we want to reserve the /8 instead of the /10, the rest of that /8 will disappear in the time before the next policy cycle.
Paul Vixie: Thank you very much. Time being short, we're going to close the queues soon.
Dan Alexander: Can I reply to that comment? In addition to that, we also have other safeguards in place. As soon as IANA hands out the last 8s, we shift to three-month cycles and ARIN staff is going to be managing that also. So it's a hard time to see that we're all of a sudden going to be done in a matter of a couple of months.
Paul Vixie: Thank you. We have a question from the remote participation.
Tom Zeller: Michael Lambert of the Pittsburgh Supercomputing Center asks: Is there any concern that we reached the point of allocating from the last /8 before ARIN staff can work out implementation details for this admittedly complex policy?
Paul Vixie: John?
John Curran: Yes. There's a significant chance that -- but particularly because the rate of all these wonderful models that say when we run out and the final /5, they're models. We actually run out when we actually run out. And you don't get to complain to the model that it was wrong.
And so, yes, there's a very real and tangible chance that we could be in runout before this got implemented in any case.
Paul Vixie: Thank you, John.
Scott Bradner: Scott Bradner, speaking for himself.
I note that this policy, draft policy, is 1500 words long. I think that the rigor at which one can implement a policy is inversely proportionate to its length.
And the likelihood of John and staff actually coming up with a rigorous way to implement this in a timely manner is effectively zero. So I'm not going to speak for or against the concept, but I think there's far too many words between the beginning and the end of this policy.
Paul Vixie: Thank you, Scott.
Martin Hannigan: Martin Hannigan, Akamai Technologies.
I'm not in support of this proposal. I could go into all the reasons that I've already stated on the mailing list. I feel adamant that this is the Robin Hood approach. I think that it's fairly -- it's significantly disproportionate.
Also, I don't know how you would intend for us content providers to actually be able to deliver on any kind of content requirement over v6. It would be difficult to measure, approve, codify, I think.
But, more importantly, I think that we do need something. But I'm still opposed to this proposal. And let me suggest an alternative approach.
So there's already another group of folks ramped up to take another stab at this, Revision 2. And I realize that it's likely we will run out of address space before the next meeting. And if you don't believe that, I would suggest that you rethink your position. I think it's the safest way to act.
I think, though, that if we get something to the mailing list and try and reach some consensus, we can provide the Board with a template to act if they feel they need to act on behalf of the community. And I think that that would be a much better approach than this. Thank you.
Paul Vixie: Thank you, Marty. I'd like to note that the queues are now closed. And we're going to go to the left.
Matt Pounsett: Matt Pounsett, Afilias. I'm not in support of this proposal. Like a couple of other people, I think it's trying to solve stuff that we've pretty much already solved and in a way that's far more complicated than, as John says, we're likely to be able to implement between now and runout.
It seems like there's just way too much going on in here, way too many moving parts to even begin to get it implemented in the next six months, which realistically might be all we've got.
Paul Vixie: Thank you, Matt. Center microphone.
Alain Durand: Alain Durand, Juniper Networks.
I was the original proponent of 2008-5 which became the policy proposal that we're trying to update here.
I would like to go back to the rationale for this revision. It was essentially to enable new entrant years down the road to get some address space to get started. That was the initial action. It was not about trying to share the last bits and pieces from all of us. And I'm afraid that this is what you're trying to do here, to grab the last crumb of bread. And this is quite complex for very low return.
Now, if you wanted to expand this a little bit and go from a /10 to maybe a /9 or a /8, that could be something fairly simple that we can understand. But adding the extra complexity to really find a model to grab the last crumbs I think is counterproductive at this time. So I'm not in support of this proposal.
Paul Vixie: Thank you, Alain.
John Springer: John Springer, Inland Telephone.
I'm actually casting my eyes forward about a year after the runout has taken place and there's a lot of finger pointing and screaming and pain going on. And it's at that point that I think the AC and the community need to be cognizant of the idea that we need to have done as much as possible in stewardship as is feasible.
So the complexity of this policy actually seems like a plus to me in that regard. There's a lot of different moving parts. There's a lot of different groups that are getting a little piece. You comment that the pain is equally distributed. As long as we hang on to those messages, I think those will be adequate protection against a lot of howling after next summer.
So for that reason I support the policy.
Paul Vixie: Thank you, sir.
Michael Sinatra: Michael Sinatra, UC Berkeley.
Of the three possible stances I could take on this policy -- for, against, and confused -- I definitely fall into the confused category. And I think that the complexity of the policy certainly has something to do with that. I acknowledge that the group that worked on it did a nice job of really trying to put something together.
I think what I'd like is maybe a brief statement on sort of the problem that I see, which is I worry about organizations forming after runout has happened and before transition to v6 has completed that need address space that can only get IPv6 address space, but they still need to provide information resources over IPv4 or access information resources over IPv4. What do they do in that situation?
So my feeling is that these sets of policies should be kind of trying to deal with that contingency. Is that a big enough worry that we should actually be worried about it? Can you provide a brief statement to how this revision to 4.10 adds to that or improves that situation?
Owen DeLong: For those trying to access v4, it clarifies and expands the scope and the ease with which ARIN can allocate the original 4.10 /10 which becomes 4.10(c) under this policy. For those trying to provide information services over v4, this doesn't do anything for them. The existing 4.10 doesn't do anything for them. There really isn't anything we can do for them without being unfair to the existing community.
Michael Sinatra: Thanks.
Paul Vixie: Right hand.
Chris Grundemann: Chris Grundemann, TW Telecom. Speaking as one of the authors of this proposal, I don't support the proposal anymore. It's not for -- I actually disagree with most of the other folks who don't support it.
But the reason I don't support it is I think that there's two options to the end game and that we tried to pave a third road through the middle and that in doing so, in trying not to choose either of the extremes, we created something that's probably not going to be effective at all.
So those two extremes I think are running headlong into the wall with current policy, which solves the predictability issue by staying the same.
And the other option is to create an actually effective soft-landing strategy which is to force people to use v6, which has its own inherent issues.
I think those are the two issues, and trying to not choose one of them is not going to be effective.
Paul Vixie: Thank you. Is there stuff up front? I thought I saw a hand.
Unidentified Speaker: There was a question that got withdrawn.
David Farmer: David Farmer, University of Minnesota, ARIN AC.
Unfortunately, I want to support this policy, but I can't. It is too complicated. I would much prefer something really, really simple, like APNIC and some of our other RIRs have.
Let's recognize it's the last /8. Stick it aside. Give everybody a little bit. Yeah, I know there's a bunch of people around here that don't like that. But that's the most rational thing I can think of.
Paul Vixie: Thank you.
Andrew. I note that I've closed the queues before you got in them, but please go ahead.
Andrew Dul: Andrew Dul. I'll make it quick.
I do not support it as written. I do support the idea of reserving the last /8 for something different than what we're -- than just regular allocations.
Thank you very much. Thank you, Owen.
Paul Vixie: So resisting temptation, we're not going to be asking for a show of hands on confused.
Paul Vixie: Although, if the author requests it, we'll put the question, I suppose.
So noting again the AC very much appreciates the guidance that it receives from the room, both from remote participants and the room here.
Even when it's a tie, I think that's guidance of a sort.
Chris Grundemann: I'd like to ask that we do a couple extra questions that we sometimes do. Based on what Marty said, I think that there is a possibility that some kind of Board action may be necessary and some guidance from the room may help facilitate that.
I think we should ask if people believe that the last /8 should be reserved and not handed out, and I think we should ask if an IPv6 requirement for IPv4 -- new IPv4 addresses is supported.
Paul Vixie: I think that is a related poll not germane to this proposal, but certainly interesting. John, start thinking about how I'm going to ask that question. But first --
Paul Vixie: Marty?
Martin Hannigan: There seems to be a few issues that might be subject to that discussion. Perhaps we can do it during open mic, kind of neutralize it a little bit.
Paul Vixie: That would be better.
Two shows of hands: one in favor, one opposed.
Let's begin with those in favor. Hold your hands up nice and high.
I think we have our tally. Thank you.
Paul Vixie: Thank you very much. I can see we're going to have a very interesting open mic session.
So here comes the tally. Thank you, sir.
158 in the room. In favor, we have three. Against, we have 62.
John Curran: Okay. It's now time for our break. We should come back here at 3:30, but as we're running late, we're going to have a little more time. We'll give you a little more for break. Just so that we don't shorten the break to an absurd amount. You have until 3:35. We will resume at 3:35. Thank you. Break is outside.
(Break taken at 3:11 p.m.)
John Curran: I invite everyone to come back in. We'll be starting. We're continuing our policy proposals with Draft Policy 2010-14: Standardized IP Reassignment Registration Requirements.
History. It was submitted as Proposal 109 on the 4th of February. Current version is 10 August version. It is a petitioned one. The draft policy is under control of Chris Grundemann.
Okay. Summary. Changes several policies. Establishes that organization information is legal name, street address, one technical and one abuse point of contact. Both email and phone number better defines residential customer. Replaces the current cable address policy with a broader policy applicable to all residential market areas. Extends the residential market area policy to IPv6. Changes reassignment policy so that /64s and larger must be registered via SWIP Whois. Allows a resource review when ARIN believes an organization is not complying with reassignment policy.
Status. The existing cable policy is unique to ARIN. The RIPE region is presently discussing IPv6 registration in customer areas, for example, with registering a DSL customer area for a given part of the region.
Staff assessment. Liability risk. Counsel's reviewing this with respect to law that applies in the ARIN region and has suggested changes to balance in the current ARIN policy on customer privacy and business proprietary information. At this point, we don't see a significant legal issue.
Staff comments: The current cable policy requires 80 percent of the ISP's space to be provisioned to hardware and to be reassigned with 50 percent utilization. So 80 percent provisioned to hardware and to be reassigned with 50 percent utilization across that. The proposal removes the 80 percent reassignment to hardware requirement. Policy would benefit many of ARIN's customers who have residential areas such as DSL, fiber, et cetera. The proposal provides a well defined explanation of what a residential customer is and will be beneficial to community and staff. Existing definition of "residential customer" has caused some confusion for customers.
Impact. There is a significant resource impact. We need to figure out how to represent this in a database. IPv6 space is vast. And so will take a little bit of planning. The assessments available online for those who want to read it.
The current 50/80 change explained. So a cable provider gets 100 units of address space. They deploy 20 units per four regions. The use per region over time is 15 out of 20. 12 out of 20. Eight out of 20. 11 out of 20. They've applied 80 percent of their 100 units to hardware, but it's not presently at 50 percent utilization. Utilization is at 46 percent. They are not ready to request additional address space. So we're counting utilization against the deployed infrastructure, presuming 80 percent is deployed to hardware.
Okay. That's the current policy.
PPML discussion. Three posts by three people. One in favor, zero against. Little discussion. That concludes the staff introduction for the policy. I'll now bring up Chris to do his presentation.
Chris Grundemann: Thank you. Draft Policy 2010-14. Start with the current SWIP requirements today, or current Whois requirements. In IPv4 the requirement is a /29 and above needs to be SWIPed. IPv6 is a /56. IPv6 language is a little bit ambiguous right now. It says it needs to be registered. It doesn't mention Whois, SWIP, RWhois, any of that.
Second thing, organizational information that's required today, this is not specifically codified. It's more of a general understanding: organizational name, street address, and the POC info. In IPv4 these Whois records are required to be visible within the database within seven days. And that's not true in IPv6 currently.
There is one exception to those rules today, which is the residential customer privacy section, which allows ISPs to substitute their own information for their customers when it's a residential customer.
One of the problems with this, again, like organizational information, it's not actually defined what a residential customer is. There's wiggle room there. Possibility of loopholes and just general confusion.
So Draft Policy 2010-14, the first section of it logically is definitions. And it defines those two missing pieces, organizational information and residential customer. It gives them a strict definition so that everyone's on the same page.
Organizational information under the policy includes the legal name, full address, and both a tech and an abuse POC which both have to have a phone number and an email address. Residential customer is someone, not an organization, at a residence using the addresses for personal use.
The second part of Draft Policy 2010-14 is kind of going back through and cleaning up all the other ambiguities in the IPv4 policy. It's kind of spread across two different policies right now. And so this basically brings it all together. And those are the requirements there. I won't read through them all right now.
The residential market area is where that cable address policy comes into place where basically two things happen. I've basically taken the residential customer privacy section and combined it with the cable address policy which allows market areas to be SWIPed. And that's where the 80/50 rule comes in.
Again, this is the cable address space policy text. The intention of the text of Draft Policy 2010-14 is to carry over this policy and just not restrict it to cable companies. So anyone with a residential market area who is doing dynamic allocations should be allowed to SWIP an entire market area and then let the dynamic allocations get up to 50 percent and then you can get more space.
Then the second thing that Draft Policy 2010-14 -- or the third thing really, it reroutes the IPv6 registration requirements completely to mirror the IPv4 requirements so that they're actually the same. And I think that this is extremely important as we move to IPv6 to have policy from IPv4 and IPv6 in line with each other so that it's clear and understandable, so that when people come to ask for IPv6 space and they go to SWIP it or put it in Whois, they can do it just like they're already doing with their v4 space and lower the barrier of entry into IPv6. Again, here's the policy text for reference. The last part of 2010-14 is a change to Section 12 of the NRPM, just allowing staff to audit a company faster than 24 months if it's believed that they're doing something wrong with the registration requirements. If they're falsifying SWIPs basically is what it would come down to.
I presented this during the Open Policy Hour in Toronto. Some may be familiar with it. There have been some changes. Some members of the community got in touch with me; we worked through it and made some changes. One of the main changes is organizational information was tightened up a little bit to include phone number, street address, and an abuse POC. Also residential customer added the "for personal use only" text just to ensure that we're really talking about a residential user.
In the registration section, we added just -- but not limited to in the -- so you have to provide this information, but it doesn't preclude you from providing more information. Also, IPv6 lowered the boundary of registration from a /56 to a /64.
The idea here is that basically every customer with a static IP assignment should be registered in SWIP so that law enforcement, abuse contacts, whoever needs to get a hold of the people responsible for the addresses, knows who is responsible for those addresses.
And resource review section was added. Obviously there's a lot of text going on here. But there's not a ton of substantial changes, I think. It's a lot of cleanup and bringing IPv4 and IPv6 in line with each other.
So this is exactly what the policy actually changes, right? The 24-month resource review restriction is removed, /64 instead of /56, the cable-only policy is expanded to all ISPs, and a little bit more information required for all your Whois data. Obviously, this has pros and cons. It provides enhanced clarity into the Whois data, which, of course, increases the burden on ISPs and ARIN as well to register that Whois data.
I think by opening up the cable address policy, it creates a more even playing field for all residential ISPs. The complaint that I've heard against that is it brings utilization policy into directory policy. But I don't know that that's a fair argument, because today if you look at the Whois policy and the cable address policy, they both talk about utilization. It's already intermingled, already mixed together, already makes sense to have them together.
The primary thing here, it builds parity between the IPv4 and IPv6 policy, which is what created so much text. Also adds needed definitions. Some of that is a little bit current practice already. So it may seem a little bit pedantic to do that. But I think having that clearly defined in policy removes some ambiguity and helps the community as a whole.
I did want to point out one thing. There was kind of a mechanical -- a textual error basically in the current policy. I want to make it clear that the idea is not for every residential customer to have to be entered into Whois. This is -- the basic idea is dynamic allocation versus static allocation. If you're statically assigned space, you should be in the Whois database. If you're getting dynamic addresses as a residential customer, you should not. Also, the last sentence there, it makes it clearer that the 80 percent utilization and that 80/50 rule is retained. I think that's it.
Paul Vixie: Cathy.
Cathy Aronson: Cathy Aronson, ARIN AC, and person quite familiar with cable allocation policy.
The original intent of the cable policy -- and I just really want to be clear about this, because I'm not sure it's still applied the same way. But I -- if it is applied the way it used to be applied; I have no idea why anyone would want it added to them. Okay.
So the reason that it came to be is because in cable you end up having to SWIP to your own infrastructure, to your own market. Okay? And those customers don't get blocks. They get like an address. Okay?
So we had a huge problem, because they were -- and we had to SWIP huge blocks to our infrastructure, because the cable end gear was horrible. So when we went to get more address space, they said, well, there's no policy for you to get more address space, and look at the tons of it you've used and it's all on your own infrastructure and yada, yada, yada.
So we said, well, great, we'll have a compromise. We'll SWIP to our markets and before we go back to get any more address space we'll be 80 percent SWIPed, which is not utilization, and we will show you in exhaustive spreadsheets all of our customers and that every market is at least 50 percent utilized, which means customers.
Now, as an ISP, you SWIP stuff to your customer; they tell you whatever lies they want to tell you, whether it's going to be utilized or not. Sure, you tell ARIN those lies, but you don't have to actually prove that it's utilized. Maybe it's applied differently now than it was for us. But it was a whole lot of work to generate these tons of utilization data to give to ARIN to get more address space. And so I can't understand why anyone would actually want that.
And also there's a huge difference between SWIPed and utilization. And we use them interchangeably. And I think as a community we really need to understand -- I need to understand how this is applied and whether they're used interchangeably the way it's applied. But, anyway, it's a mystery to me why anyone would want it.
Paul Vixie: John.
John Curran: The reason they want it is the same reason you wanted it: We are now facing other broadband access situations where companies assign infrastructure, addresses to infrastructure, but then can't come back and hit the utilization and prove that they actually have the customers. But we don't have a policy for them; we only have it for cable. So if you have the same problem but it's now repeating itself on a different access structure, they can't get more space.
Cathy Aronson: You said, John, in your talk that the 80 percent was going away and you said it wasn't.
John Curran: I was probably wrong. Go ahead.
Chris Grundemann: The intention is for it not to go away.
John Curran: My apology.
Paul Vixie: Bill.
William Herrin: I like your ideas, but I can't support the policy as written. The last thing we should be doing right now is creating more paperwork for folks trying to deploy IPv6. Thank you.
Paul Vixie: Rear microphone.
Matt George: Matt George, Verizon Wireless. I have a couple of questions. With regards to the 50 percent, and the gentleman up there had said that the 80 percent would still apply, that's 50 percent utilized, 80 percent assigned, correct?
Chris Grundemann: That's correct.
Matt George: The difference between an ISP with a residential market area and a typical ISP is a market area -- is an ISP that is swiping IP addresses for customers? Could you elaborate on the differences between the two?
Chris Grundemann: The intention is that you assign a market area that then dynamically allocates addresses as opposed to statically assigning addresses to customers. That's the key difference.
John Curran: To the extent you have a technology where the addresses are dynamically used by a pool of customers, they're not assigned to the customers. They're assigned to the market. But you've got a ratio of addresses to customers. That's what happens in the cable case, where you literally have a pool of addresses. You can still run out of addresses but it's not allocated individually to customers.
Paul Vixie: Noting we have nine people in the queue, I want to say I'll be closing the queues soon. A remote participant should probably go next.
Tom Zeller: Joe Maimon at CHL asks two questions: Until 2008-1, SWIPs for allocations and assignments smaller than /29 were not accepted by ARIN citing policy. As a result 2008-1 was authored, debated, and adopted. Would smaller than /29 SWIPs continue to be accepted under this policy?
Chris Grundemann: So that was part of the reason why we added the "not limited to" text, just to make sure that -- it's required at /29, but you can do more.
Tom Zeller: Secondly, what differentiates cable address space utilization from resource pools? I think that's what you were just talking about.
John Curran: That's what I just answered.
Tom Zeller: Just answered. He said he does not support the policy because of the inclusion of the auditing clause: I think auditing needs to be handled more delicately than this.
Paul Vixie: Thank you.
Jean-Francois Tremblay: Jean-Francois Tremblay, Videotron. On John's last comment, one thing that's not clear here is what exactly a residential dynamic address is. Because we're looking at making the v6, especially in v6, making it as stable as possible. So what becomes dynamic versus static? Even if an address is not -- is not directly assigned to a client, it can stay with that client for maybe years. So what is dynamic in this case versus static? It's not defined here. So it becomes very confusing.
Chris Grundemann: I think some of that is left to be played out in technology. I don't know that we know exactly how providers are going to provide /64s or what they provide to their customers in dynamic pools. But the idea is if it's a market area and you're assigning a block of addresses to all of these customers, whether or not their lease keeps renewing and they keep the same address is insignificant.
Jean-Francois Tremblay: That would be dynamic, then?
Chris Grundemann: Right. If it's out of a pool for that area, that's what we're talking about, as opposed to saying this customer A gets block B, period. And it's statically assigned to them.
Paul Vixie: Thank you. The queues are now closed. Let's go over here.
Jason Weil: Jason Weil, Cox Cable. Actually, I just have some nits on the -- like the residential description says the actual -- the use of "for personal use only." This is kind of confusing. So if a customer is using VPN to do work at home, is he now in violation of the residential policy? That's just a small thing that could be changed with our wording.
The other one was under the residential area market area 65531. I don't believe it's the intent of this wording, but it does say any assignment to specific end users holding /64 or larger still requires registration, to which to me implies every /64 needs to be registered. That probably needs wording.
Chris Grundemann: Yes, it does. That's something that hopefully the AC can help in Last Call. It's an oversight. That's not the intention. Like I said, the real intention is the difference between statically assigned and dynamically assigned.
Paul Vixie: Far left.
Mike Joseph: Mike Joseph, Google. Following up on the previous question regarding the /64 and larger, then are you referring to just clearing up just to say larger than /64?
Chris Grundemann: Yeah. So this is my suggested fix here in the bold text. You can see it now. It says: More than a single /64.
Mike Joseph: So consensus is coming together amongst IPv6 residential providers where larger than /64 allocations may become the standard or at least commonplace. Based on that, and then the following section for residential customer privacy, it would entail effectively tons of identical SWIPs with one /56 after another, or one /60 after another with identical privacy data. How is that a benefit to the community or law enforcement?
Chris Grundemann: It's not. And, again, the idea -- and, like I said, obviously there is -- text needs to be cleaned right there. The idea is the difference between statically assigned and dynamically assigned. And so however we word that, if we just say statically assigned addresses have to be SWIPed, I'm fine with that.
Mike Joseph: Yeah, but if I put an address in my database that says user A at the time of provisioning has block whatever, that's statically assigned. Yet it would be absurd to suggest that we would have to provision all of them and have to enter all of them into SWIP with identical anonymization data. I'll leave it at I can't support this proposal, but I do have one question for staff. In John's summary, the written staff assessment for this proposal says it's staff's observation that cable policy works well for cable providers as is, but that seemed to be dropped from John's initial introduction. Is that still staff's position?
John Curran: The cable provider provisions work satisfactorily for cable companies but do not consider the wide range of people providing broadband residential service.
Mike Joseph: Okay. So staff's observation that you cannot determine -- or you cannot discern what problem this section of the proposal is attempting to solve is no longer valid?
John Curran: No, it's -- we don't need necessarily to change the impact of this for cable providers. And it does. So we're not sure what drove it to be changed with respect to cable providers. On the other hand, if it's to make it all uniform, that's probably why you have that side effect. There's no need to change, per se, just the policy for cable providers. It is working. But it's getting changed as a result of this policy. Alain?
Alain Durand: Alain Durand, Juniper Networks. I'd like to follow up on the question from Jean-Francois Tremblay. I have a comment about this distinction between static versus dynamic is not going to make much sense in the future. I've heard people talking about DHCP allocation with infinite lifetime. So at that point with static or dynamic, I'm not sure I understand.
Now, is it in the market or is it out of the market, also as a service provider we're contemplating the idea of you have a block of v6 and it could be moved with you when you move to the other side of the country. So how does this work here? And what about wireless? And if you are wireless, you're not bound to a market. So with all of this, I really have a hard time to understand this notion of static versus dynamic.
Chris Grundemann: My personal opinion on it is if you have a system that's assigning an address block to a customer, there's absolutely no reason why that system can't also kick out a record of that assignment. If you have a pool of addresses that is shared among customers, whether they keep them forever or not, you don't specifically have a system that's setting up that correlation, then you can't kick out a record and you shouldn't have to.
Matt George: Matt George, Verizon Wireless. I can actually answer some of your questions. If -- your handset would actually be assigned as long as you stay within a given market. If you power off that handset and power it back on, you would receive a different IPv6 address. So there is still going to be a difference between a static IPv6 assignment and a dynamic IPv6 assignment in the wireless LTE world. Something else I wanted to mention. I'm not sure if the Board's aware, the 3GPP spec for UE or user equipment is a /64. So what you're basically saying is every wireless provider out there that provides a static service to its enterprise customers is going to have to swipe every customer. SWIP, whatever.
Paul Vixie: Well, okay. Center microphone.
Wesley George: Wes George with Sprint. In general I support this policy. I think there are probably some clarifications that need to be made. I don't know whether they're all trivial enough to be made in the process of Last Call or whether we're going to end up having to revise this and try again. But I kind of want to echo some of the comments that have been made about concerns over size being the defining value of whether or not you need to SWIP something.
Chris and I have had some discussions about this offline. And I'm generally in agreement with the sentiment he expressed about it doesn't really matter how long you keep it if it's not physically assigned to you as in there's no possible way you can ever have it associated with someone else, not in the context of I get a pool and I keep it, keep the same DHCP address for what may seem like virtually infinite amount of time, that should be the dividing line, rather than size, a /64 or /56 or a /48 or whatever it ends up being, because there are legitimate cases where you might assign a fairly small block, a /64 or /63, a /56, to a business user. And you will have -- because that's more than enough address space for your average business user that needs just a /24 today in terms of amount of networks or amount of hosts or however you want to look at it. So you're tying it to size kind of ends up creating problems, I think.
The other thing I want to say is that from a residential definition I think you need to make sure that you tighten up the language a little bit to keep mobile in mind. Similar to what my colleague from Verizon mentioned wireless kind of blurs the definition of business use versus residential use. And while in a lot of cases if we go towards making dynamic versus static kind of the dividing thing, a lot of that will be solved.
You still -- since we're talking about definitions here that may or may not actually have direct bearing on it; it is worth cleaning it up to keep the fact that you're going to have this explosion of mobile devices that are going to have addresses that are kind of like broadband home devices. That's something you've got to consider.
The last thing I want to do is respond to the relative non sequitur comment about paperwork. You have to do paperwork now or later. It's better to have it be a requirement up front so people know what they need to plan for. And, yes, I realize that it is a barrier to deployment of IPv6, but so is everything else. And ultimately this is part of the deployment. And to simply say, well, let's not do that because it's hard is kind of not valid, in my opinion.
Paul Vixie: Thank you. Far left.
Bobby Flaim: Hi. This is Bobby Flaim from the FBI. We want to say we're in support of the policy, particularly the third part, /64. It's very hard for law enforcement tracing and tracking criminals. We feel this would be certainly a help to us. And also it would be more efficient, you know, with cyber crime and some of the things we're looking at.
Speed is of the essence. Not only for the FBI, but even more particular for our state and local and international partners that may not have the resources that we have, and the fact that we can find out exactly who the organization is that we can actually serve legal process on, the faster, as opposed to going to different ISPs to figure out who has that IP block, I think this policy would be a tremendous help.
And some of the clarifications with the definitions and even the audits, I think it provides also a good checks and balances, where IPv4 you have organizations that need to currently come back to ARIN to ensure that they have the space, and it kind of makes them put their information in the Whois and the RWhois and so on and so forth. With IPv6, the way I understand it, you wouldn't have those checks and balances where they would do that. So this provides that.
So thank you.
Paul Vixie: Thank you. I want to note we're a little bit over time. So I'll ask our Q and A to be brief. Rear microphone.
Christian Tacit: Chris Tacit, TekSavvy Solutions. So the concerns I have are in two areas. The first is a continuation of the concern that I expressed yesterday, and it has to do with the cable situation, in particular, in Canada. And it has to do with new entrants into the market.
And that revised wording that I just saw up there seems to be tighter, in fact, than even 4.2.6 was now requiring to go back to the 80 percent utilization, whereas I think 4.2.6 said between 50 and 80 percent. That is really not feasible for a new entrant with small scale.
The other thing to be considered in that section is that unlike the U.S. situation, in Canada, where you have a new entrant that's a competitor to an incumbent, it's the competitor that has to get the IP space but the incumbent that owns the infrastructure going to the home. So whatever language you end up doing, please don't tie it all together, because in 4.2.6 that caused some interpretation problems.
And the final point that I have relates to the same point that the previous gentlemen just made. Unfortunately, under Canadian privacy law, the new qualifications on privacy could actually be in breach of certain Canadian privacy legislation. So I would encourage all of you to look at that a little more closely before you finalize this policy. Thank you.
Chris Grundemann: So to the first two points, the intention is 80 percent SWIPed and 50 percent utilized. Just like it is today. The intention is not to change that. So you SWIP it to a market area, and you have to have 80 percent of your space assigned to a market area, and then 50 percent of that space has to be utilized.
Christian Tacit: I'm not sure that's totally clear yet. But other than that, I would ask you to bear in mind that we want to get past some of these cable problems we had in Canada, so keep us in mind.
Paul Vixie: Thank you. Counsel.
Steve Ryan: Before you leave the microphone, since I'm barred in the United States -- and barred doesn't mean you can't practice law, it means you can practice law -- I would ask my Canadian colleague, if you could be more specific, either right now in your comments or in writing, if you could post specifically what aspect of Canadian law you think is implicated by the current language of this. I would confess I'm not as expert in Canadian law, and, in fact, ARIN will engage Canadian counsel if we have a serious issue here, and I appreciate that you're raising it. It would be very, very helpful if you could be more specific, I think, in the point you made.
Christian Tacit: Yes. And the reason I raised it was because I noticed the note in there that that analysis hadn't been completed. Rather than take up time now, I will post something later on.
Matt Petach: Matt Petach. I'll be very brief. I just wanted again to also respond to Mr. Herrin that there's no better time than the present to make sure records are up to date. We've already faced in the v4 space trying to go back, and going back is a pain in the butt.
Second question: Was the omission of the Section 12 changes from the printed documentation intentional or just an oversight?
Paul Vixie: Oversight.
Matt Petach: Thank you.
Paul Vixie: Far left.
Marc Moreau: Marc Moreau, Royal Canadian Police. I wanted to echo what Bobby had mentioned that for law enforcement obviously I think this is something that I would support in principle, not withstanding some of the issues of perhaps with the privacy laws. But overall on the -- for law enforcement from an international perspective, I understand that the paperwork sucks, but sometimes it could be very worthwhile obviously with investigations. So I would support it in principle. Thank you.
Paul Vixie: Kevin.
Kevin Oberman: Once again, in regard to pretty much the same controversial section here, I think that the whole attempt to draw a dynamic static line in IPv6, in particular -- it isn't like v4 -- is virtually impossible and a big, big mistake. v6 tends to almost be dynamic by nature and by characteristic. If I'm providing service to a few thousand residential customers off of a router, make some changes in my network configuration and change the /48 that that router gives all its prefixes from, assuming you're doing DHCP or even EUI-64 addresses, either way, the addresses just all changed or they're all still residential. So is that dynamic or is that static? It's not -- I really think you're going to have a very hard time approaching it from that standpoint. I think your heart is in the right place, but I think it's going to be really, really hard to codify it in a manner which is not going to cause great confusion and potentially a lot of unnecessary paper churn, perhaps even the FBI would agree it's unnecessary in some cases, though probably not.
Chris Grundemann: Understood. We'll definitely take that under advisement, dynamic versus static and the way to word that.
John Curran: Cathy?
Cathy Aronson: Cathy Aronson again. I don't usually go to the microphone more than once for the same proposal, and I almost never say that I'm against this proposal as written, but you have completely changed the cable policy. It's been completely reworded. All it says in here is that you strike the policy and that a greater than 50 percent utilization rate shall be considered efficient for market area reassignments from all the ISPs' recent allocations, which is certainly not how it's worded in the NRPM. So I'm completely against that. I mean, there's a reason why it is the way it is. And there's a distinction between SWIP and utilization that's inherent in that policy for a reason. So you have changed it. Maybe that wasn't your intent. But it's not in here now.
Paul Vixie: Thank you, Cathy. Marla.
Marla Azinger: Marla Azinger, Frontier Communications. I support the policy as is written. Speaking as a network that -- what Cathy just spoke against, I speak for. It needs to change because it needs to include not just cable heads. I have massive --
Cathy Aronson: I agree, but I don't think it should be changed. It should be applied to all.
Unidentified Speaker: Microphone.
Cathy Aronson: I totally agree with that, Marla. I think it should be applied to everyone. But he's completely changed it in here. It's not the same as it was. I'm totally --
Marla Azinger: The specific change it reduces. I support the changes, too, and here's why. When you have very large networks -- and I don't know why, but we had the very large networks kind of disappear from voicing opinions around really five years ago. And, geographically, when you have nationwide networks and you have massive, large DSL pools, your last allocation from ARIN has to go out to all those massive pools. And 80 percent utilization, it becomes -- for even -- run a network and only do 80 percent -- or do 80 percent utilization across -- go ahead.
Cathy Aronson: I'm just wondering if your distinction utilization between SWIP. That's all.
Marla Azinger: He wrote it right. You SWIP 80 percent of it, which you do, but the utilization, when you go down and you look at all that address space and all those pools, it's only 50 percent, because when you actually -- when you actually go and make it higher we can't manage, we actually have to halt installs. We actually have halted customers. So it's people. These are customers, these are people, these are you that we have to go, sorry, yeah, maybe we'll get service once we get our next allocation. And as far as the paper requirement of showing that 80 -- like right now I have to show 80 percent utilization of those in all of my pools, static and dynamic. And that is a pain in the ass, especially when it's at an 80 percent level. They are no longer saying, hey, just show us utilization. They're also saying show us specifically how it's used. So I didn't just have to say here's my DSL pool in Orlando, Florida, and this was what was put in it; it was, okay, I see your /29 assignments and larger that are SWIPed, but now we want to see all of your /30s and /32s matched up to somebody as well.
We run large networks. That amount of workload is crazy. And, okay, at 50 percent, one, it helps me out so I don't have to shut down a service area until I get more address space from ARIN, and, two, it's a little less paperwork I'm having to pull together in order to show ARIN. So I fully support this proposal how it's written as it is. The /64, I support that as well. I would suggest that somebody people -- I don't know how RWhois started to get a bad name back a couple of years ago because I love it. It is very simple. We automate things with it. So to do /30s or /32s, even, it wouldn't be that difficult to automate things with RWhois. And that makes it very easy to see everything.
And I will admit -- sorry, ARIN, close your ears -- it's kind of a pain in the ass to get customer info updated if you SWIP it directly to ARIN, because the customer has to do it themselves, and that takes a lot of gymnastics, which probably some of you have gone through, which is why I went to RWhois, so that I change it when my customer says, hey, this is the new info.
Anyway, I think that was -- oh, and the Canadian one, I was just interested in what law that was to. So that's it.
Paul Vixie: Just a moment.
Chris Grundemann: To Cathy's point, I think I understand what the cable address policy does today, and I was trying to not have to put all that text into the new policy. And I believe that Section 220.127.116.11 in the NRPM today requires all ISPs to SWIP 80 percent before they can get new space. The reason I added just the 50 percent actual utilization requirement was because that seems to be the only part that was missing.
Cathy Aronson: I guess I understand that, but in the current regular ISP policy, a SWIPing of 80 percent is equated to utilization of 80 percent. And in the cable policy, that's not the case. There are two different components of it: There's SWIPed 80 percent, utilization 50 percent, which is more than you have to do as a regular ISP right now.
Chris Grundemann: Understood.
Paul Vixie: Heather.
Heather Schiller: You're all arguing over something that doesn't actually exist. Go read it. For v6 there's no standard 80 percent utilization requirement in order to get additional space. It is HD-ratio in the allocation that you got as an ISP .94 percent. That policy doesn't exist. So you're actually requiring a higher utilization requirement to get additional space than is there today. If you look at what the HD-ratios work out to by your prefix size, it can be as low as 20 percent utilization in order to get additional space, because the HD-ratio is that crazy algorithm based on the size of the prefix you've been allocated.
So what -- be really careful about what you do here, because 80 percent of a v6 allocation is a lot higher than the bar is today. And you're going to put that on cable providers and not other ISPs. Be careful.
John Curran: Heather, hang on. Leslie. Leslie, can you reconcile Heather's comments? I believe, Heather, that the cable address space policy says: Using super RWhois, cable ISPs must show they have reassigned at least 80 percent of their space with a 50 to 80 percent utilization rate.
Heather Schiller: That's a v4 policy.
John Curran: You're saying with respect to v6 this doesn't exist.
Heather Schiller: You're effectively creating that and creating a significantly higher bar for additional allocations for cable providers than you have for other ISPs.
John Curran: Because it doesn't use the HD-ratio. Okay. Got it.
Chris Grundemann: I'd like to point out quickly this in the bold text is a suggested change, kind of guidance to the AC. It doesn't actually exist in the text today. So that sentence would be applicable to IPv4 and a similar one, basically saying that you follow your SWIP requirement for IPv6. I understand. I understand what you're saying. And it's an oversight. That sentence is specifically applicable to IPv4 and it's meant as guidance to the AC on how to fix the change that staff may need.
Paul Vixie: Last comment.
Brian Rucker: Brian Rucker, U.S. Drug Enforcement Administration. DEA supports Policy Draft 2010-14. Just wanted to make sure you understood that. And I can't emphasize more how accurate Whois data will successfully impact our investigations. It will speed up the investigations and ultimately, just to put it in simple terms, will get the bad guys off the street and save a lot of lives. Thank you.
Paul Vixie: Thank you very much. Thank you, Chris. So for the last time today, we're going to be asking for a show of hands in support and a show of hands not in support, or in opposition, I guess, I should say. And, once again, please put them up high. Those in favor of this proposal. Okay. Thank you very much. Those against the current policy. Okay. Thank you.
We've gone a little bit over here, but I thought the information was informative. And I'm sure the AC will have a lot to chew on in their discussions about this, no matter what the numbers turn out to be.
Chris Grundemann: A question for -- regarding support in general for this type of proposal, because there was there's obviously some textual/mechanical issues.
Scott Leibrand: You usually ask would you like the AC to keep working.
Paul Vixie: Scott points out that the normal form of that question is would you like the AC to keep working on this. And so once I have my tabulators back, I will ask for that.
So those of you who think that the AC should keep working on this, please raise your hands now. Thank you. Those who think the AC should not work on this, let the matter drop, not improve on this, raise your hands now.
Okay. Thank you. So to the first question about the proposal as written, there were 20 in favor and 36 against. As to the second question, we are tabulating those results now. Room count, 163. Thank you for asking.
John Curran: To be clear, that's room and remote.
Paul Vixie: Room and remote, yes. As expected. To the question should the AC keep working on this, we have 63 in favor and one against, with the same room count as before.
John Curran: Okay. We're running a little behind, but we're going to catch up now. So the first part is the Policy Implementation Report. Leslie will come up and give that at a brisk pace.
Leslie Nobile: I will go quickly on this. This is actually a new report. We don't typically break it out separately, but we thought we would inform the community of what new policies ARIN has implemented since the last meeting. So basically we update you on recently implemented policies, and we'll provide any relevant operational details. There were four new policies implemented.
The first one was 2010-6: Simplified M&A Transfer Policy. And it basically clarifies the existing text of the M&A transfer policy and it requires that unused space be returned to ARIN. If there's unused space in the course of the transfer, it stipulates that it has to be returned to ARIN. And we implemented it in September 2010. Don't have a lot of implementation experience at this point, not much to report on.
2010-4: Rework of IPv6 Allocation Criteria. So it just had four new criteria and have you to meet one of -- only one of them, have an IPv4 allocation or be multi-homed or have a plan to have 50 customers in five years. Actually, only one of three. And it was implemented September 2010. Nothing's really changed. Most people were qualifying for IPv6 allocations anyway.
2010-2: /24 End-user Minimum Assignment Unit, says the new minimum assignment size for end users that are multi-homed is a /24, and /24s and /23s must renumber if they request additional space under this policy. Implemented September of 2010, and so far, on the past month or so, we've issued I think seven /24s to end users under this particular policy.
2008-7: Annual Whois POC Validation. It's the annual validation of all registered POCs in ARIN Whois. We implemented this in early June. That's one I do have some operational information on. So we fully automated the process via ARIN Online. We made it pretty simple for people to use. We basically send them this message and they hit "validate" if their information is correct. If it's not correct, we offer them the other option of going through ARIN Online and updating the info. We actually -- so, as I said, we started in June. We started with POCs with direct resources from ARIN. There were about 42,000 of them. We've completed the first cycle.
It was a really quick process. We were staggering emails and we were finding we weren't getting very many questions or comments. And so we increased our numbers. And we finished it relatively quickly, I think in mid-July. Got a response rate overall of about 33 percent. Didn't have a lot of questions. Very smooth.
So in August we started mailing the POCs with indirect resources. That's those with reassignments from upstreams, and there are about 200,000 of them. And we're having a very different experience with indirects.
The response rate has been below 7 percent. I don't have an exact number, between 5 and 6 percent. There's a clear lack of understanding on their part. We're getting a lot of questions, and it's very difficult for them more than for us.
So these are our observations. POCs of reassignments are very unhappy ARIN is contacting them. They don't know who we are or what we're talking about when we're sending them these emails, and we get a lot of phone calls and emails back saying: Who the hell are you? Really. I mean literally. People are so annoyed. They accuse us of spamming them, amongst other things. They don't understand why their name is listed in a public database and they want it removed.
They don't know what record they're associated with. That's really typical. They're like: What am I registered against? I didn't even know. I don't know what this is. And they've told us many a time they want their upstream ISP to handle this for them.
So we have some questions. There are two very different questions. So just look at the first one. So we've asked this before, and the community said you should contact indirect points of contact, contact those with reassignments. But based on our implementation experience we're going to ask it again, because we're not finding we're having huge success rate in this. So should ARIN stop contacting or continue contacting, whatever, the reassignment POCs and instead make the upstream ISP responsible for their downstream records?
The second question, unrelated to that, is: Should ARIN continue updating network and ASN records that have points of contact who have not validated their records? And the reason I ask this is because I was reviewing a request with staff the other day and I noticed that the record, the POC record, said this POC has not validated their record. And I thought why are we actually even making an update on their record? If they haven't responded to us, should we continue updating their ASN record or their network record or whatever it is they're asking for.
So I thought it would be good to throw this out. Should ARIN be actually working on updates and modifications to records, points of contact who are not responding to us? And I don't think that was ever really raised in any previous conversation. So I'm throwing it out there. And we can go back to the questions or you can, whatever, but I do have another slide. Open mic or whatever.
So besides the policies, we had one other service that we implemented. And this was a consultation that the Board put out to the community, and it was called the Specified Transfer Listing Service. It was established to prepare for the time when ARIN will no longer be able to routinely satisfy v4 requests due to the depletion of the v4 free pool. Says organizations with available IPv4 addresses may transfer them to organizations with demonstrated need in accordance with NRPM 8.3, transfers to specified recipients.
So we have set that up. We've implemented it and it's running. So we started it in 2010, September 2010. And the process is that all applicants, whether they be needers -- excuse the terms -- or listers -- it's the only thing we could think of at the moment -- they have to be vetted. We have to see who they are and what their needs are. And they all have to have assigned RSA. And the needers have to actually be approved for space under current policy before they can even be put on the list. So we're doing a whole lot of vetting verification up front.
To date we've had 23 organizations come in and apply. So none of them have actually made it to the list yet, because most of them seem to be done in error. We have two listers. One was a reassignment; obviously can't list that. And one wouldn't list the block that they were trying to put on the list. So we contacted him and he's not -- he or she, don't know -- no response so far. And then we have 21 needers. And we realize they didn't understand that there's still space available at ARIN and that they could come apply directly to us. So what we did was we sort of tightened up the language. We tried to provide clarification text on the Web, and we've responded to all of them letting them know they can still come to us for space. Most of them have closed their tickets. So that's where we stand. There are no valid needers or listers at this point. And that's all I have.
John Curran: Any questions briefly? The topic of continuing contacting indirect POCs I'd like to defer until open mic because of the vast amount of time it has capability of absorbing and the fact that we have a fixed amount of time for candidate speeches, which started six minutes ago.
Any other questions on her presentation? Thank you.
John Curran: So we now are going to have the ARIN Board and Advisory Council election procedures reviewed by Jud Lewis, and then we'll actually have the candidate speeches, first for the AC candidates, and then for the Board of Trustees candidates.
Jud Lewis: Hello again. I'm Jud Lewis again. And I'm going to be going over the procedures for this time for the Board and AC.
Alright. So what's new? Like I mentioned for the NRO election, this year candidates can provide a URL to any blog or social media outlet of their choice to establish a dialogue with potential voters.
Second new thing this year is members must be on record by the first of the year, 1st of January, to vote in elections and the current elections. So everyone that joined after the 1st of January this year is going to become eligible to vote in the 2011 elections.
Alright, here's the calendar. Today we're going to have candidate speeches. The voting opened at 3:00 p.m. Tomorrow, mid-day, you can look for the speeches you're about to see. They'll be published online at election headquarters.
Ten days from today, on the 16th, the voting closes at 3:00 p.m. Eastern time. And then we're going to announce the winners on the 22nd of October. Again, election headquarters, you can go there for the voting booth. Read the candidate biographies, review statements of support submitted by the community, www.arin.net/app/election.
Voting procedures. Only designated member representatives, or DMRs, from general members in good standing may vote in this election. The 21st of September was the cutoff for them to be eligible. You must be a general member in good standing. You must have no overdue invoices per ORG ID. And the email account, DMR email account, that we have on file has to have the DMR's name or initials and their domain name, the organization name we have on file, or doing business as name, like firstname.lastname@example.org or email@example.com.
Wednesday, 6th of October, today, we sent out an email and an announce message to all the voters saying voting is now open, go to election headquarters and you can cast your vote.
Voting procedures. If you haven't voted before, you need to register. There's a form to do so. You provide your first and your last name. The DMR email that we have on file -- if you have voted in the past, you log in with your previous information. If you have forgotten your information, there's a way -- instructions you can follow. The system will remind you what your username is and how to update your password as well. If you don't want to go through that, you can write to info.arin.net, and I can help you with that.
Step two, you vote.
And this is important, step three, make sure that after you vote -- there's a "confirm vote" button. Make sure you click that as well, that way you know your vote will have been cast.
This is what the voting ballot will look like. On the left hand side is the Board of Trustees. You may select up to two candidates for that election. And on the right hand side is the Advisory Council. You may select up to five candidates for that one.
By the way, in your meeting packet, it is this voting guide with candidates' names and FAQs and some instructions on how to vote as well. Without further ado, I'll pass it over to John who will introduce the candidates.
John Curran: Thank you, Jud. I do want to remind people of a different election going on in parallel, not to risk confusing you. The NRO NC candidates' election is closing in 22 minutes, I believe. You have 22 minutes to vote in the NRO NC election. If you have not done that already and you were planning on doing it -- NRO NC election, if you're planning on voting on that and you have not done so, you can beat the rush by doing it now rather than 19 minutes from now.
John Curran: Okay. We're going to call up the nominees for the Advisory Council, and then the Board of Trustees. Each one has two to three minutes to make a brief speech. For the ones who can't be here, we either have a video or we have a slide that I'll be reading. First nominee for the Advisory Council, Cathy Aronson.
Cathy Aronson: I think it probably takes longer to walk up here. So somebody asked me the other night -- they had a really, really hard election question for me. And it was: Really? And so I thought about that.
I've been on the Advisory Council for 12 years, which is kind of a long time, I guess. I'm really passionate about what goes on in this community. The next three years are going to be a real challenge. And I guess I just ask for your vote so that I can continue trying to make things happen. So thanks.
John Curran: Jim DeLeskie is the next nominee, and he cannot be here. I'll read his slide.
Motivation to serve: The Internet has been very good to me and I'd like to return the favor.
Biography: I've been working on the Internet since 1994. I've worked at every job from help desk to chief architect. And I've been involved in various security groups and active on NANOG for more than 15 years.
Okay. The next nominee is Owen DeLong.
Owen DeLong: I think most of the people in this room are fairly familiar with me. I won't rehash a lot. I've been actively involved in the ARIN policy process for more than a decade now. I haven't been on the AC as long as Cathy, but I've certainly enjoyed the last three years serving with her. And I hope you guys will give me another three years. I think there's a lot of work left to be done. I think it's important work. And I think that, you know, if you look at the contributions I've made over the last three years, and even in the time when I wasn't on the AC, and consider it, I think that I've earned your vote. And I hope you'll give it to me. Thank you very much.
John Curran: Next nominee for the AC is David Divins, unable to be here.
Motivation to serve: To help the community and assist in policy legislation that will enable the best utilization of available resources.
Biography: Principal engineer, Carpathia Hosting, ARIN XXV IPv6 and Web Hosting panel member, CISSP. That's David.
Next nominee is Wes George.
Wesley George: Hi. For those who don't know me or aren't that familiar with me, I'm a relative newcomer to ARIN. I've been working at Sprint doing a number of different jobs for about 10 years now, everything from NOC Monkey up to various flavors of engineering. And my current role is kind of strategy and network development. Through a lot of that I've been the resident IPv6 sandwich Board carrier and have been maintaining Sprint's v6 testbed network, and then as we've gone to production rollout, I've been working very closely with a lot of the folks in both the operations and engineering side on that.
So obviously my focus within ARIN has been on v6. But the reason I want to serve within the AC is that I think it's a good way to give back. I didn't self-nominate. I didn't ask someone else to nominate me. But when I was nominated, I accepted because I think the role that the AC plays is not an easy one. And it's not trivial.
I think that there is value in having folks kind of rotate in and out so the folks who were on there don't get burnt out so as new ideas come along, things of that nature -- I'd like to think that I'm pretty objective when it comes to trying to get what is the best policy for the community at large rather than simply my own interests or my own personal view of the universe, and I'd like to work with other folks as they bring policy forward to try and shepherd that in the right direction. So I ask for your vote. Thanks.
John Curran: Thank you. Next up, Advisory Council nominee Gary Giesen.
Gary Giesen: Thank you, John. Most of you probably don't know me. Some of you I've just met recently. But that's okay. I'm a relative newcomer to ARIN. I've only been involved in the last six, eight months or so. But I've been in the service provider industry for a little over seven years, IT for a little over ten.
I'm currently a senior network engineer at AKN, a Toronto-based company whose primary focus is managed end-to-end networks. What's really missing from that title is that I really wear a lot of hats and I work in a number of roles including resource management and allocation, network design, planning, operations, product development, also do community coordination, regulatory review, and operational systems and administration. In short, I get to see problems from a lot of different vantages. I also get to build networks over and over.
We do private networks a little bit differently than everyone else. So I get to see all kinds of different deployment models, developing best practices, et cetera. And since I get to iterate through that process again and again and I build both the service provider side and our enterprise customers' side, I get to see both camps. And it will be interesting to see how policy will influence and affect the transition of v6 and vice versa.
One thing I'll also do is challenge some assumptions, because I believe honest, open, and spirited debate in the community exposes new approaches, refines existing ones, and -- excuse me -- and, in general, produces sounder policy. We have to engage stakeholders too and reach people who would not normally be involved in the ARIN process to ensure their needs are met and no one is left behind.
We've arrived at a critical juncture in Internet resource governance. There currently exists a sort of duality. On the one hand we have IPv4 which we have to carefully manage as a finite resource, which is quickly exhausting. On the other hand, we have IPv6, which will be a virtually unlimited resource, still has to be managed carefully because of other constraints. And then there are the transition technologies. There's the post run-out transfer market. All of these combined mean we have to create effective policy that balances the needs of enterprise and service provider customers with operational, administrative, and economic realities that exist both before and after free pool depletion.
I believe I can provide unique insight and build precious consensus to help navigate these turbulent waters. In closing, I'd like to ask you all to vote. I'd like you to ask your colleagues, your friends, even your competitors, to vote. Anyone who is a member. Because I'm a firm believer that even if we don't agree on everything, or even anything, for that matter, that engaging people in the process, that making their voices heard creates better policy for ARIN and the Internet community at large. And that's really the whole point. And if you decide that voting for me will help further that goal, well, I encourage that, too. Thank you.
John Curran: Thank you. Next up is Chris Grundemann.
Chris Grundemann: Good afternoon. I'm Chris Grundemann. I'm a network architect for TW Telecom. I'm also the founding chair of the Colorado chapter of the Internet Society. This election is not really about me or any of us. It's about this community and it's about the future of the Internet. We, obviously, over the next three years and beyond, are going to face some tumultuous times, some difficult choices, a little bit of hardship, if not a lot.
And I think the most important thing for all of us during this time is to maintain the one thing that has gotten us this far, and that is the open, bottom-up, consensus-driven process that built the Internet. Not just ARIN, but all of it. With that in mind, I'd like to ask you to go read the bios, look at the statements of support, check out the websites, and vote. Thank you.
John Curran: Next Advisory Council nominee is Martin Hannigan.
Martin Hannigan: Hi everyone. I'm Martin Hannigan. I'm really excited to be up here. I can't remember a time that I've been so excited to be in the Internet industry. I'm really getting geeked about v6. Seems like the train has finally left the station and it's about to become a bullet. I won't go into too much gory detail. I wrote fairly extensive -- fairly extensive answers to the questionnaire. Please read my bio online.
Just a couple of points. I'm working very hard to make v6 happen. I've got 22 years of Internet experience. I've got some legal training in civil society as it relates to Internet policy. I've got finance and economic training. I've worked in probably every segment in the industry that you can think of. I also worked at Kentucky Fried Chicken once and I think I have relation -- you know, an understanding of how end users in business may be affected with respect to v4 and v6 policy.
I want you to vote for me, because I think that I'm one of a bunch of great candidates, and you couldn't do wrong with all of us. And thank you very much.
John Curran: Next 2010 Advisory Council nominee, William Herrin.
William Herrin: My name is William Herrin. And I seek your vote for Advisory Council. So $2 billion per year, that's the portion of your router costs that's attributable to the size of the BGP table. And one of the major factors in the size of the BGP table is policy at the registries including ARIN. Three years ago I asked what that actual dollar cost was, and nobody knew. So I found a cost analyst with about 40 years of experience in the field. I got his help. And I figured it out.
On the AC, you can expect me to ask the hard questions like that and to seek the answers so that you can make well informed decisions about whether to support or reject a particular policy. My first priority on the AC would be helping you take your ideas for policy and create well crafted policy text and then championing those ideas through the process. It's not my job to act as some kind of congressman and make the law. It's about you and your ideas.
So, again, my name is William Herrin. I seek the privilege of serving you on the Advisory Council. And I thank you for your kind consideration.
John Curran: Next up in the 2010 Advisory Council nominees, Scott Leibrand.
Scott Leibrand: Scott Leibrand. I think most of you probably have seen me up here at previous meetings, if you've been to them. I've been on the Advisory Council for the last three years. I think I've been one of the most active Advisory Council members in that time on PPML, at the meetings, shepherding proposals. You can read some of the details of that on my bio, if you weren't involved in the process at that time and don't remember it yourself.
There's been a lot of important stuff going on the last three years. I think it's going to get even more interesting the next three years. We have exhaustion happening probably in the next year. We have a lot of policy that's not quite defined yet. There are a lot of issues with regard to global policy with regard to a number of things that are still in flux, still need to be worked out. I would like to continue working on those things. And if you like what I've been doing so far, would like me to continue representing you, I'd like your vote. Regardless of whether you want to vote for me, please do read the bios. They have very good information on all the candidates and the statements of support. And please make sure you vote. Or if you haven't, if you're not the one to vote, make sure the DMR for your org or any other orgs you're affiliated know they need to go ahead and vote. Thank you.
John Curran: Okay. Next candidate is Andrew Mentges. And he has a video. So here it is. Andrew.
Andrew Mentges: Hello, everyone. My name Andy Mentges. I've been in the hosting industry for over ten years and currently serve as vice president of operations for Jumpline, a large Web hosting provider. I believe my experience in ten years in the hosting industry will prove valuable to the AC. The hosting industry is subject to so many different types of technologies, whether it be different DNS platforms, different MTAs, databases, cloud infrastructures, voice over IP. It really runs the gamut in terms of technology. It also touches the end-user maybe more than any other industry.
Also the hosting industry counts for a large portion of IP allocations given, and as a longtime member of the industry, I know firsthand the obstacles of the IPv4 depletion.
My primary view on this is twofold. I believe we can achieve more efficient IPv4 allocation deployment. Secondly, this is obviously an issue not only on the network layer but also on the application layer. I believe the more that we can get software vendors to adopt IPv6, the more ease of transition it's going to become for the rest of the world to transfer from IPv4 to IPv6.
I have two master's degrees, both in business and information systems. I understand fully the technical and business impacts of IT governance and ARIN's policies. This is really why I'm excited to participate at a regional level and help determining, refining, evaluating new and existing policies.
The aforementioned experience and qualities I believe would make myself a valuable addition to the AC. I respectfully ask for your support and your vote. And I apologize for not being there in person today. However, I'm exhibiting at a conference and I'll be arriving Thursday night and I will be there Friday as well. If you happen to run into me, feel free to snag me and ask me whatever questions you feel are important to you, and I'd be happy to give you my stance on them. Thank you very much and have a great conference.
John Curran: Next 2010 Advisory Council nominee, John Springer.
John Springer. Hi, everybody. I'm John Springer. Like Marty, I'm excited to be up here. I am with Inland Telephone Company, who I've either worked with or for virtually my entire Internet career. It's a small ILEC in Washington and Idaho that covers a big chunk of the American west. I've had the singular pleasure of developing networks from its inception in early 1995 to the present, growing it from networking with a 56k frame relay connection to our current gigE fiber connections.
I started coming to ARIN meetings in Orlando in 2005. Since then I've been to ten of the 12 meetings. During that time I have been showered with kindness and encouragement. This community is a very welcoming one. So when my reaction to being asked to accept the nomination for this race was terror, I was a little embarrassed. But after I began to get over that, it occurred to me that this community has a call on my participation.
It's been remarked that the coming period is going to be very challenging. I do believe that a wide variety of viewpoints brought to bear on the issues is going to be critical. I'm very much a proponent and an admirer of the transparent bottom-up, community-driven process. So if this community should perhaps be ready to accept my perspectives as valuable, then I ask that you vote for me. And I will do my best to be useful. Thank you.
John Curran: Final nominee for the 2010 Advisory Council, Tom Zeller.
Tom Zeller: My name is Tom Zeller. My day job is at Indiana University. I've been serving on the Advisory Council for the past year. And that has led to an increase in my appreciation for the amount of effort, intellectual involvement, engagement, and passion that this community brings to bear on these somewhat arcane and obscure policy questions, but important nonetheless. And when I watch my deepening involvement in that process and I watch it in action and I see people like David Farmer and Scott DeLong -- Owen DeLong and Scott Leibrand -- got ahead of myself there -- and Chris Grundemann doing the hard work of crafting these detailed formal policies, I see the length of service of people like Cathy Aronson and Bill Darte back there bringing a lot of institutional memory and experience to the process, all the effort of everybody that works on the PPML, just to read all that stuff, and plus those that actually make the lengthy comments to get us to think about these things and all the impacts, obviously bothering to attend these conferences in person and remotely, and I should also mention the outstanding, competent execution by John Curran and the entire ARIN staff, when I look at all of that, I'm truly impressed. And I'm actually in a bit of awe of the collective wisdom of this community.
And I think for the purposes of this organization, we couldn't assemble a more wise crowd, and therefore I see my job on the Advisory Council as participating like all of you but listening carefully to the wisdom of this crowd and making sure that the policies that get adopted are well thought out, well crafted, well vetted in this community, and have achieved something very near consensus before they're adopted. We are about to enter a more perilous period. And I think it's important that the policy is as stable as possible so the rules are known to everybody, they're fair, and they're defensible.
At the same time, we need to be flexible enough to tweak the policy as it needs to be tweaked to solve problems that can be solved. And I think this work is very important, and I'm very proud to be part of that work. And I have to say it's quite an outstanding selection of candidates, and I feel that this organization will be in good hands, whatever the outcome. Thank you.
John Curran: That concludes the speeches for the 2010 Advisory Council nominees. We now have four nominees for the 2010 Board of Trustees. We have one video speech and three in person speeches.
The first candidate is Vint Cerf, and he is unable to be here and will be doing a video speech.
Vint Cerf: Hi. My name is Vint Cerf. I'm Google's chief Internet evangelist and today I'd like to briefly explain why I have such an interest in running for a Board seat at ARIN.
Some people have said: Why would you commit time to such an endeavor? Frankly, at this point in the history of Internet, as we run out of the IPv4 address space and must introduce IPv6, at least in my opinion, this is a very tricky time for all of the RIRs and for anyone who is involved in making use of the Internet. Somehow we have to get through the period of run out. We almost certainly run into tough policy problems having to do with legacy IPv4 address space and what to do with it. There will be buying and selling of IP addresses and the question about whether they will show up in the routing tables or not, and if they do, what does that do to the size of the routing table. At the same time that we're trying to introduce the IPv6 address space. So this is a very complex time and a very important time for the Internet. And I'd like to offer to assist in working through that time frame.
Those who know me know that I have a fairly long history in connection with the Internet, starting with the design of the TCP/IP protocols and the architecture with Bob Kahn in 1973 and I've also been involved in the formation of the Internet Society and served as chairman for the Internet Corporation for Assigned Names and Numbers, which, of course, has a very important relationship with the Regional Internet Registries and the Number Resource Organization.
So to the extent that you're willing to allow kind of an old dinosaur to participate in this part of an ARIN activity, I would certainly be grateful for your support. And, in any event, I certainly commit myself to showing up at the meetings and participating deeply in the work of ARIN. Thanks very much for listening. Bye-bye for now.
John Curran: Okay.
John Curran: Second candidate for the 2010 Board of Trustees is Lee Howard.
Lee Howard: I've done this four times now. Getting used to it. I considered not running this year. I gave serious consideration to it, because the next year's going to be a tough year. The next two years are going to be complicated. Not just the transition from IPv4 to IPv6, but the management of address transfers is going to be complicated.
And I thought about the operationalization of those transfer policies. So I thought about whether this was even really a time that I should run again. You know how you go watch the nominees in front of congress getting reviewed for whatever they're nominated for, and you think: Why in the world would anybody subject themselves to that? Right? That's kind of how I feel right now, is why in the world -- Lee Howard, why would you want to do this job? And the example that I want to bring up is from our last public policy meeting where there was a proposal brought forth that had been posted to PPML for the process, and the Advisory Council considered it and said: We're not going to work on this. And it was appealed. It went to the community and the community said: No, we think we want to work on this. It came to the public policy meeting, and the proposer said -- and this was somebody who did not have an extensive history. This is just a member of the public. Came to the meeting and talked to a bunch of people. And after talking to people he listened to their opinions and he said: You know what? I don't think I want to actually advance this proposal anymore. And we went ahead and had the debate anyway. And we had a discussion about that proposal to make sure that every person who supported that petition had a chance to voice their support for it and to make sure that nobody was disenfranchised and every single person who wanted to talk about it in our region had a chance to say what needed to be said. And even people who are not predisposed to like ARIN very much said that we were a shining example of open Internet governance.
And I have been associated with some organizations that I'm really proud of. I'm an Eagle Scout. Worked for some really great companies. But I've never been prouder to be associated with an organization than I was then. And I said so at the time. And that's exactly why we need to be here and we need to continue to serve. I think it's not fair for me to look at what's going to happen in the next three years and wonder whether it's worth running. The work's probably never going to be harder. But I can't not run just because it's hard work. It's worthwhile because it's hard work.
I think if you look back at what's happened over the years with ARIN, I think outside of staff probably nobody has done more for the organization than I have. I'm currently serving as the IPv6 guy for Time Warner Cable, and I'm trying very hard to make sure that people know what's going on in this time of transition, and I would like to continue serving and having the ability to do that.
One of the things that I think that I want to provide for you is the ability to know that when somebody grabs a Board member in the hall and says "how did we get here? How does ARIN work and what is the policy process," I want you to have someone who can explain that. Please vote for me. Thank you very much.
John Curran: Third nominee for the 2010 Board of trustees is Aaron Hughes.
Aaron Hughes: Hello. My name is Aaron Hughes. We have a great slate of candidates so I would be honored to see any one of us serve on the Board of Trustees here at ARIN. So I figured I'd tell you a little bit about myself to help you with your decision making. I work with quite a few companies, particularly as it relates to IPv6 transition. I work with quite a few companies on IP address management; that is allocation, assignment tools and automation systems and discovering new problems with v6 and really understanding what the operator community is running into today.
I'm currently a business owner. I sit on a couple of Boards. And I work in network architecture, system architecture, policy, strategy. Participate in meetings such as this, ARIN, NANOG, RIPE, GPF, EPF, as well as local member meetings. And I have a pretty good idea of what are current issues in the community, as well as fiduciary responsibility for both my own company as well as the companies that are hiring me to help them. I'm happy to serve on the ARIN Board of Trustees, and I would certainly appreciate your vote. Thank you.
John Curran: Fourth and final candidate for the 2010 Board of Trustees, Paul Vixie.
Paul Vixie: Thank you, John. Hard to believe it's been six years already. This is also my fourth time doing this, I think.
I will not regale you with stories of why I want to do this. I know that the questionnaire that I was sent asked me for those details. So it's online. But it's not really relevant. And also I don't know.
Paul Vixie: So what I will say is I came late to ARIN. I am normally somebody who starts things. I took over BIND when the BSD team kind of retired in place and started the first commercially supported open source DNS company back in the early '90s. I started the first commercial neutral Internet exchange. That was PAIX. Started the first anti-spam company. That's MAPS. That's "spam" spelled backward, for those who weren't there.
I've done a lot of things starting from whole cloth, starting from, gee, nobody's ever done this before, nobody even knows why that needs to be done. But I came late to ARIN. And what I have found by coming late is that it's almost the same as starting a new company, because you have to reinvent every couple of years. ARIN had to become an IPv6 company, and soon ARIN will have to become a post-IPv4 depletion company. And I enjoy that kind of creation or reinvention activity. I'm good at it. Finding traction where there is none and doing something that a lot of people think can't be done are specialties of mine.
So I agree with the other candidates, both for the Board and the AC. I'm very impressed with the slates this year. You almost cannot go wrong. You will do well no matter who you vote for. And I urge you to vote.
I'm asking for your vote because this is something very difficult. The stuff we need to do is very difficult. I like doing things that are difficult. If this was easy, I would not be running. I believe all of us sort of remake the world in our own image every day, whether we mean to or not. I choose to do it consciously. And I would like to have a world where the transition to a post-v4 Internet economy is successful and we all move on. And I think that the best way I can leverage my own skills is in this position. So thank you for your vote.
John Curran: I'd like to thank all the nominees for the Advisory Council and the Board of Trustees for taking the time to share their views. Encourage everyone to vote.
John Curran: This concludes our program for the day. We don't have open mic today. So the things we've talked about talking about at open mic, that's tomorrow's open mic session. And we want to stay on track because we don't want people to get tied up and not be able to make it to the social. The social is tonight at 7:00. Buses begin loading at the lower level of the hotel at 6:30 and they'll run for about an hour and a half over there. The buses return -- return service starts at 8:00 p.m. and will run -- last bus will be 11:00 p.m. It's at Ten Pin Alley. Should be a lot of fun.
I don't think I have any other messages. Tell me if I do. Vote now. Yes, elections are open. Go forth and vote. You can vote for your ARIN Board of Trustees and Advisory Council nominees.
And that's it. Thank you everyone. I look forward to seeing everyone here tomorrow.
(Proceedings adjourned at 5:17 p.m.)