Secure Login

ARIN XXIV Public Policy Meeting
Draft Transcript -
21 October 2009

"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."

Opening and Announcements

John Curran: Good morning, everybody. Welcome to ARIN, our Dearborn meeting. Happy to have everyone here. We have some brief announcements. Up here we have the Board of Trustees, or as many as we have; myself, President and CEO of ARIN; Scott Bradner, our treasurer. Timothy Denton is unable to be here, but he's listening in when possible.

Scott Bradner: You should say why people are missing.

Stacy Hughes: He has a day job; that's why he's missing.

John Curran: Understood. Lee Howard is our secretary. Paul Vixie, the Chairman, is unable to be here due to illness in the family. So I'll be running the meeting. And Bill Woodcock is here. Thank you.

Advisory Council, I think we have most of you here. I'm not going to go through the names. But if you're on the Advisory Council raise your hands. I see lots of AC members. Very good. The NRO Number Council, Martin Hannigan I see. Louie Lee is here and Jason Schiller is here. I have the full NRO NC. RIR colleagues, raise your hands. I see folks AFRINIC, APNIC, LACNIC and RIPE. Yes, quite a few of our friends are here. The ARIN management team is here. ARIN management, raise your hands. I guess I double count, huh? Nice and high. All the departments are represented. Richard Jimmerson couldn't be here. He's off covering SuperComm educating them about IPv4 depletion.

Our fellowship program. We have fellowship recipients. Please stand up, our fellowship recipients. There we go. Tony Vetter, Stephen Woodrow, Melody Palmer. These are folks picked to come to our meetings, take the lessons learned and take them back to their communities.

I'd like to welcome the Postel Network Operator Scholar. Are you here? Yes. Somewhere. We do a joint Postel scholarship along with the NANOG team that brings someone also from communities to learn about the NANOG and ARIN ways and bring them back to their groups.

Welcome first-timers. We had a first-timer lunch yesterday. We had quite a few first-timers. Raise your hand if you're one of those. That's ARIN continuing to -- thank you. Welcome. We had an exciting first-timer's lunch yesterday where I gave a briefing about ARIN and the organization. And actually we enticed these folks to come by also having a prize drawing, $100 gift certificate from ThinkGeek.

I actually have all of the questionnaires here. So I will now ask someone -- Patrick. Good morning, Patrick. Come on up. If you would choose one of these questionnaires. Thank you, Patrick.

The winner of the prize drawing is Matthew Petach. Matthew, come on up.

(Applause.)

A newcomer and an old-comer in a way. You'll get your gift certificate sent to you in an e-mail. Okay. Daily survey. Every day we have a survey of the sessions we present and your feedback on them is used to refine the meeting and the content. You get to submit your entry between 8:00 and 6:00 p.m. The prize drawing's done during the announcements the next day. You must be present to win. And remote participants are welcome to participate in the survey. Fill out your survey and remote participation counts in terms of presence. Today's survey topic is ARIN Online. So remember to fill out your survey sometime today.

Daily survey. It's time to announce our winner of the survey for yesterday. And today's winner, you're going to get e-mailed this prize -- e-mailed. No, you're going to get mailed this prize. It's a piece of physical stuff -- right after the meeting.

Wesley George of Sprint. Are you here, Wesley? Yeah, you'll get a prize sent to you, okay. Solar charger. Solar charger. Thank you for answering.

Remote participants. We have remote participants out there. They have access to the webcast of the sessions, a live transcript. They get to participate in a meeting and survey raffles. They get downloadable meeting materials. They have all the slides. There's a chat room open where they can ask questions. In fact they come to the virtual microphone, and they actually count in the consensus policy show of hands. So they're about as present as you can get, our remote participants.

Participant's packet. You should all have a participant's packet. It's that wonderful folder that you got. It has the meeting program. Yes, looks like that. It has our policy discussion guide and the policy development process. All of the policies that will be discussed during this meeting are in the policy discussion guide.

It has for reference your own personal NRPM, or Number Resource Policy Manual. This is a limited edition. It gets changed after each meeting. You should take yours, put it in a wonderful place. And the NRO Number Council and ARIN election information is contained in your packet. And then finally an ARIN Online information sheet, how you can interact with ARIN via the Web.

Attendance stats. We have 179 attendees: 156 from the United States, eight from Canada, 26 remote participants registered, one from the Caribbean and 12 from outside the ARIN region. We have 107 joint NANOG/ARIN participants. Thank you. Thank you all our joint participants.

(Applause.)

That helps keep ARIN anchored in the realities of operating networks and it lets the network operators know about the policies that are coming down the pike. It's a good thing.

Social. Get social. If you are online using social media, you can follow this ARIN meeting. ARIN XXIV. We've got an ARIN XXIV tag. You can find us on Team ARIN on Facebook and Team ARIN on YouTube. Those who like to follow the social media, we're out there visible to people.

Sponsors. I'd like a brief round of applause for Arbor and Merit, our two sponsors for the meeting.

(Applause.)

Transportation to and from our social is going to be provided by UnitedLayer and our media partners are PowerSource and TelecomFinders. Thank you for all of our sponsors.

(Applause.)

Rules and reminders. The Chair, or in this case myself, will moderate discussion of draft policy so all can speak and all can be heard. Please clearly state your name and affiliation each time you're recognized at the microphone. Please comply with the rules and courtesies in the program. There's rules and courtesies published in your program. They're very common rules and courtesies. Shouldn't be much surprise. We'll try to make sure we evenly get a hold of everyone. I ask that people speak once on a policy proposal and let everyone else speak before they go up and get a second chance to speak again. If you have a position on a policy proposal, start out by saying that. That makes it a lot easier for people to understand the rest of your comment.

Okay. Today's agenda: We have a few things. We have the Regional PDP Report, the Policy Development Process. We have the Internet Number Status Report. We have an IANA's Activity Report and we have a discussion about our templates.

We also have the NRO election procedures and candidate speeches, because we're electing the NRO Number Council candidate. And we have the ARIN Board and Advisory Council election procedures and candidate speeches.

Policy discussions on today's agenda. 2009-6, the global policy, the Internet Assigned Numbers Policy for Allocation of ASNs to Regional Internet Registries. And we have 2009-7, the Open Access to IPv6 Policy.

At the head table, well, actually, I think we've covered most people. Going down, we already hit everyone, but I'll do it again: Lee, Bill, Scott, Stacy, another Scott, and Marla. Thank you.

Members of your Board and your Advisory Council. Thank you.

2009-1: Transfer Policy (conclusion of the Emergency PDP)

John Curran: Okay. I actually have a little presentation I'm going to sneak in here. It's required according to our Policy Development Process. It's on Transfer Policy 2009-1. So I'm going to go through this. As I said, it is required. People kind of remember 2009-1. It was an epic event, it and its counterpart, 2008-6, the adoption of a transfer policy in the ARIN region. And I'll go through it and then take any questions.

So the background. In February of this year the Board adopted 2008-6, the emergency transfer policy for IPv4 addresses. It allows people to designate transfers to designated recipients based on need. It included a three-year sunset from implementation, and it allowed the Board to choose the timing of the implementation. Upon adopting it, the Board invoked a special policy action of the PDP, a section of the Policy Development Process that allows the Board to, when it sees a recognized crisis or emergency, get involved in the actual policy. But there are controls upon that, which is what we're talking about now. We revised 2008-6 prior to its implementation.

The PDP actions allows for temporary creation, modification or suspension of a policy. The process says we declare the emergency. We post the policy change to the PPML. The AC reviews the discussion and makes a recommendation within 10 days to the Board. If the Board proceeds, it is presented at the next Public Policy Meeting.

We invoked the emergency PDP and posted it to PPML for discussion. It was extended through the then upcoming Public Policy Meeting. It was presented in San Antonio, and the AC revised 2009-1 based on the community feedback and recommended the revised one for adoption by the Board.

We adopted that on the 28th of May and we implemented it on the 1st of June. Good. The net effect of implementation of 2009-1, as opposed to 2008-6, was some specific revisions. The requirement for the region, specific requirement for the recipient to be in the ARIN region and the removal of the three-year policy sunset clause.

The last part of the PDP special policy actions requires presentation at the next Public Policy Meeting after adoption, and that's where we are today. So people who have questions about the actions of 2009-1, now is the time to ask those questions.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. Has anyone used it?

John Curran: Has anyone used it? Leslie.

Leslie Nobile: We've had two completed transfers under the policy and one pending right now.

John Curran: We're working on getting a standard stats feed so you can see that. Those addresses do show up -- do they show up in the current stats files? They show up in the daily files to the extent --

Leslie Nobile: They show up in the monthly files and they show up in the daily files, but the type of policy they qualify under is not distinguished, so you cannot see that.

John Curran: We're working on enhancing it so you can break out and see specifically which policy was used. Any other questions?

NRO NC Election Procedures

John Curran: Moving ahead. NRO Number Council election procedures. I'll ask Jud to come up to go over the NRO NC election procedures.

Jud Lewis: Hi, everybody. My name is Jud Lewis. I work in the Members Services Department at ARIN. And right now I'm going to give you a quick rundown of how to vote in the NRO election. All right. As I stall, the details. Okay. What. There's one open seat for a three-year term beginning the first of the year, first of January 2010.

Who can vote in this election? Pretty much everybody in this room can. If you're an ARIN DMR, you've been eligible to vote for an entire week starting a week ago from today. If you're a NANOG attendee, you were able to vote yesterday. And if you're an ARIN attendee, a registered ARIN attendee, then you can vote today starting at 9:00 a.m. this morning until 5:00 p.m.

And I encourage you to -- if you're going to vote, it's a good idea to get it done early; I wouldn't wait until like 4:55 to cast your vote just in case there's issues with remembering your username or your password. So I encourage you to vote early. And when I just handed this for DMRs, there's a week-long period. It ends today at 5:00 p.m. NANOG attendees voted yesterday, 5:00 p.m. And if you're an ARIN attendee, then you can vote today, like I said, from 9:00 to 5:00 p.m.

Where do you go to vote? The URL is https://www.arin.net/app/election. Click the "vote now" button. Say what, Louie?

Louie Lee: You need another slash.

Jud Lewis: Oh, we need to add another slash in there. I can give you another shortcut. Go to arin.net. There's a big "vote now" button in the middle of the screen. Then you click on that "vote now" button, then there's another big "vote" button. So try to make it as accessible as possible.

And you may be asking yourself, Jud, what e-mail address should I use today when voting? Well, that's a really good question. If you're a DMR, you want to use the DMR e-mail that we have on file, and that's the one -- you can't -- it's important to note you can't double-dip in the NRO NC election. You might be a DMR. You might be an ARIN attendee, you might be a NANOG attendee. Regardless, you can only vote once in the election.

If you're a DMR, use your DMR e-mail that we have on file for you. If you're not a DMR and registered at the meeting here, then you want to use the e-mail that you signed up to register with, register to the meeting with.

What is here is a -- like I said, there's that big "vote now" button in the middle. There's a screen shot of the ARIN election headquarters.

And here, if you access this, you can get to the voting booth or you can cast your vote. We have biographies of all the candidates and some information about them up there as well as statements in support, the people submitted from the community.

Three easy steps to voting. First one is go to the election headquarters, the URL right there. Step one, if you've never voted in an ARIN election, you need to log in and register. To do so it asks you -- you've got to type in your first name and last name. Then you need to type in -- if you are a DMR, you put in your DMR e-mail, like I mentioned in the slide previous.

If you're an ARIN attendee, type in the e-mail you used to register for the meeting with. And it asks you to create a username and a password.

Or if you've used this election system before, you can just log in with the e-mail you previously registered under.

Okay. Step two. You vote. There's a ballot with the names of the two NRO NC candidates and you click on one of those. But you're not quite done yet. This is a very important step. After you're done voting, you need to confirm your vote.

If you don't click the "confirm vote" button, then your vote is not going to be counted. After you do so, you'll get a confirmation screen. Make sure you click "confirm."

All right. Here's a calendar. Like I said, a week ago, on the 14th, the election's open for DMRs. Yesterday, the 20th, NANOG attendees were able to vote. Today ARIN attendees are able to vote until 5:00 p.m. The voting closes for everybody at 5:00 p.m. today.

And tomorrow at the meeting we're going to announce the winner of the NRO NC election.

All right. What I'm going to do now is ask: Are there any questions about voting procedures at the moment? If not, I'm going to be out at the election help desk out there. Feel free to come up. I'll be happy to help you with username or password issues you have. Or, if you prefer, you can write in to info@arin.net. And in the packet we have the handy-dandy NRO Council frequently asked questions, so you can refer to that as well.

I'll turn this over to John to introduce the candidates. Thank you.

John Curran: Thank you, Jud.

(Applause.)

NRO NC Candidate Speeches

John Curran: We have two candidates. One is unable to be here, and I have a statement from them. So I'm going to read that, and then we'll invite the other candidate up to speak.

So one of the candidates is Babak Pasdar, and his motivation to serve:

I was an early adopter and provider of commercial ISP services and I have forged a career working with commercial and nonprofit organizations, architecting, implementing and securing and managing Internet infrastructure.

In my career I've spent considerable time in guiding my clients through new technology transitions. I look forward to leveraging my knowledge and experience with both the ISP community and consumers of the Internet to effectuate the responsibilities of this office.

Ultimately, I believe that this is a crucial time in the history of the Internet as we focus on migrating from IPv4 to IPv6. I would like to bring to bear all of my organizational, technical and evangelism skills to support this effort and contribute positively to the community's smooth transition to IPv6.

The rest of the background is available online, the biography.

And I'll now call the second candidate up to read their statement, Louie Lee.

Louie Lee: Thank you, John. Hi, everyone. So I'd like to continue serving on the NRO NC to promote the IPv6 adoption and also to give to the global community the ideas that we have -- I may not say perfected, but we're working on the bottom-up policy development process. Also...

Also now what? So you see my motivation to serve here, and I have a good biography, I believe, down there. This would be my third term if you would lend me your support. Thank you very much.

John Curran: Thank you, Louie.

(Applause.)

Stacy Hughes: I have a question. This is for Jud. Can multiple DMR accounts be merged, is the question.

John Curran: Jud, back on your presentation. Multiple DMR accounts, can they be merged? Actually, what would be nice is if you can get their e-mail, we'll try to get it offline and then I'll read and answer back tomorrow. I want to proceed with the Regional PDP Report, and I'll invite Einar up.

Regional PDP Report

Einar Bohlin: Good morning. My name is Einar Bohlin. I'm the Policy Analyst at ARIN, and this is the Regional PDP Report.

So this slide, it's got a couple of snapshots that were taken of the proposal situation at large amongst all five RIRs at two ARIN meetings ago, the last ARIN meeting and right now. The total -- let me describe this a little bit. It's by category. In the category of IPv4 proposals, right now amongst all five RIRs there are 17 proposals on that topic. IPv6 has 10, directory services has kind of fallen off the map, ASNs has come back primarily due to a global proposal that accounts for five of those. And then there's another category with things that don't fall into any of those categories.

At the bottom, it shows a number which represents how many of that category are current ARIN draft policies under discussion this week. We have two IPv4 discussions, two IPv6 discussions and one ASN draft policy at this meeting.

This slide shows the five draft policies under discussion on the left. And it shows if there's something similar or the same thing, perhaps, that's been discussed at the other four RIRs, and I'll just go down the -- I'll just go down the chart row by row.

The first one is a global proposal, and by definition those are entered into the policy development processes of all five RIRs. So we'd expect to see that at every RIR. It's been adopted. It's the -- the draft policy is allocation of IPv4 blocks to RIRs. It's been adopted in the AFRINIC and APNIC regions, and it's a proposal state at LACNIC and RIPE, and here at ARIN, of course. And so being a global proposal, what needs to happen is the same text essentially has to be adopted at all five RIRs and then sent to the ICANN Board for ratification. We'll get more about these Draft Policies as they come up during the agenda.

Second item is IPv6 multiple discrete networks. And it's essentially an ARIN-only, ARIN-region-only proposal at this time.

Another global proposal about ASNs, which has been proposed in the AFRINIC region, which is later in November, it's in last call at APNIC, it's using the expedited policy development process at LACNIC, which is a special policy development process that allows something to go through the process a little quicker than normal. And they do bring it to a meeting, but LACNIC only meets once a year and this proposal is saying that if it goes through, it needs to take effect starting 1 January that's coming up. So it needs to move along a little bit.

2009-7, open access to IPv6, has two parts, has two parts to it, which are kind of different. And that's why in some of the other regions there's two proposals on that topic. One of the parts is to remove the routing criteria that's in the IPv6 initial request policy. And that's already been adopted. If you go all the way to the RIPE column there, that's already been adopted in the RIPE region. And it's under discussion at the other RIRs.In fact, I think at the APNIC region, it's a little -- I've listed a proposal here. It's a little different. They're actually -- there's a proposal suggesting that subsequent IPv6 allocations be bundled and announced as a single prefix. So if you get more IPv6 space, you're to change your route and route that one prefix. That was presented at the last meeting. It's still under -- it went back to the list for more discussion.

Equitable IPv4 run-out is the last draft policy here, and all the regions are talking about the end of the IPv4 space. RIPE region has two proposals on that. Once again, our draft policy is two different things, and the RIPE region has two proposals that cover those items.

So I'm not going to tell you about every proposal. There's I think almost 40 proposals being discussed right now. Ten of them are global proposals. So there are about 30 individual ones. Most of the IPv4 ones -- I forgot to mention on that slide. Most of the IPv4 ones are about IPv4 depletion. The IPv6 topic is still making IPv6 space easier to get for ISPs and end-users. So if you want to see exactly what those proposals are at the other regions, go to these links. And all the RIRs have very nice sites where all the proposals are pretty much on one page. The bottom row here is the Policy Comparison Overview which the RIPE NCC is maintaining this year. It's a document that you can use to compare the policies amongst all five RIRs. It's like a quick-and-dirty, what's their IPv4 initial allocation policy, for example. You can go to that document and see if it's the same, if it's different. Thank you.

(Applause.)

John Curran: Any questions for Einar?

Internet Number Resource Status Report

John Curran: Okay. Next on the morning agenda is the Internet Number Status Report. I'll ask Leslie up to report that.

Leslie Nobile: Okay. Good morning, everyone. Leslie Nobile, Director of Registry Services at ARIN. So this report -- I've got to look this way, sorry -- it's basically a status of the IPv4 and IPv6 numbers and autonomous system numbers. It's something the five RIRs prepare together. We update it quarterly and it dates back to 1999, I believe. So we've got 10 years covered of stats. So the first slide is about the total IPv4 address space and where it stands currently. And probably the most interesting slice of that pie is the IANA reserve space. There are now 26 /8s remaining out of the total 256 /8s in the global pool. If you look above that in the green pie, these 35 /8s are in use by the technical community and are not available for the IANA to issue to the RIRs. And you can see how they're designated next to their numbers.

Moving left, something we call the Central Registry, but this is where the legacy space resides. This is the space that was issued by various government contractors when they were performing the NIC function and issuing IP address space. And 91 /8s were handed out in those early days prior to the establishment of the RIRs. Below that, the RIRs. In total the five of us have gotten 104 /8s from the IANA as of today, and further broken out, as the pie is showing, how many each of us has gotten from IANA: APNIC's gotten 34; RIPE, 30; LACNIC, 6; AFRINIC, 3; and ARIN, 31. So this is the sort of side-by-side, all five of the RIRs. It shows the comparison, the growth in each of our regions since 1999. And it's very clearly a steady trend up, but it's been up and down all along. And the thing really to take out of this is the growth at this point is mostly in the APNIC region. They're the green, whatever that is. And let's see. I think last year ARIN issued just a bit more space than RIPE. But previously RIPE was issuing more address space. This year I'm not sure what the numbers are going to look like. But last year the five of us issued a little over 12 /8s altogether and looks like we may be on track for that again this year.

So this is a similar slide to the previous one. But it's the cumulative totals of the address space that each of us have issued in our regions: RIPE, almost 25 /8s; ARIN, 23; LACNIC, 4; AFRINIC, just over 1; and APNIC, a little over 29 /8s in their region over the past ten years. As assignments, sort of up and down. The ARIN region we've been issuing fewer ASN assignments over the years, and RIPE has started issuing more. So other than that the other RIRs pretty much are on steady trend.

Cumulatively, there are the totals. ARIN's issued slightly more than RIPE, but at this point -- you can see the numbers; I don't really have to go into them. Okay. IPv6 address space. So we looked at the total IPv6 address space pool. The /0 over on the left. A /3 is carved out for global unicast right now, and that's 506 /12s that IANA holds in reserve. I'll go to the right. So it says the RIRs each have a /12. That was issued per policy in October of 2006. That was a global policy. So each of us is working from that /12 that you see. But prior to the establishment of that policy, we were getting small bits of address space from IANA. Small meaning -- not really small; they were /23s, so we were each working from /23 allocations from IANA. And that pie at the bottom shows how many -- I'm sorry. Yeah, /23s. Shows how many /23s each of us got. And again RIPE had gotten the most even early on, 15; APNIC, 7; ARIN, 5; LACNIC, 1; and AFRINIC, 1. And there are three that are carved out for special purpose: two are used in RFCs and one is in reserve for RIPE still. I think that's just a holdover. I'm not sure that's going to stay there or not.

So IPv6 allocations from the RIRs to the customers. To the LIRs and ISPs. Again, growth clearly in the RIPE region for IPv6. ARIN has issued more and more IPv6 address space as well. It's a bit of growth in all the regions, but it's nothing really remarkable except in the RIPE region.

Okay. This slide. Let's see. If you look on the left, the total allocations made by the RIRs to their customers is listed. So RIPE has issued roughly 1600; ARIN, 692; LACNIC, 213; et cetera, et cetera; APNIC, 575; AFRINIC 59. But in terms of the total number of /32s, those numbers get really, really large on the right, because some of the RIRs are issuing much larger allocations than /32s, RIPE in particular. Actually, all of us: RIPE APNIC, ARIN has issued several larger blocks than 32, LACNIC has done it once or twice. And AFRINIC has not to date issued anything larger than a /32.

Here are the links. The NRO has all these stats, and then the IANA ICANN website has all the raw data, historical data. So are there any questions?

John Curran: This is your opportunity to ask about the statistics report and where all the numbers are going. I knew someone would come up. Center mic.

Dave Barger: Dave Barger with AT&T. Leslie, this is a lot of good information about history and all that sort of thing, but are there plans to augment this data and possibly add information about IPv4 exhaustion and when do we project that we're going to run out, things like that?

John Curran: So at present the -- ARIN doesn't maintain an IPv4 depletion forecast. The Board has chatted about that. Turns out there's a number of folks who do do that. The chief scientist over at APNIC, Geoff Huston, does a remarkable job doing that as one of his projects. And there's a few others out there.

I guess I'd be interested in knowing if the membership wants us -- I don't want to duplicate efforts. But at the same time I need to know sort of is there a value of an official ARIN forecast and, if it is, should we take a greenfield approach to that or just adopt one that's out there and agree with its methodology? I'd be interested in your insight on that.

Dave Barger: Well, the way -- we're getting our data from two sources. You mentioned Geoff Huston's site, which is what we're using for a lot of our internal planning and IPv6 project funding and that kind of thing. But we also have -- see, it was a letter that I think you published, John, in April that said we're going to run out in two years. So our senior management is looking at both pieces of data and we're getting information from ARIN that we're going to run out in two years. But if you go to Geoff Huston's site right now, it's extended out quite a bit beyond that.

John Curran: Two years.

Dave Barger: Well, but if you look at the IANA exhaust date, that really is after the April 2011 date that is assumed from the letter you sent out. They're looking at two sources of data, and which one do we believe? Either we have this third-party site or we have ARIN, the Regional Registry, which I think they're more apt to believe ARIN. So it does bring up the issue of where does the responsibility fall in terms of just the overall reporting and which set of data do we believe.

John Curran: It's a good question. Actually, it would be a tragedy to some extent, I guess, if they were ready too soon, because it turns out that we didn't deplete as fast. But to the extent that we're successful in managing allocation size and in reclamation, the number is going to move from time to time. So I guess you're saying it might be necessary for us to send an update and say here's the progress we've made.

You're going to see very soon an announcement among all the RIRs, coordinating through the NRO function, talking about the fact that we're now down to about 10 percent of the remaining free Internet addresses for IPv4. That's probably within a month's time. So they're going to be seeing more information which might serve to confuse them even more if it's not put in context. So I'll take that under advisement and chat with the Board about whether or not we need to send an updated letter that says what our current status is.

Dave Barger: Okay. And I think that's good. And just get an alignment. I mean, if we have, if the consensus is that possibly Geoff Huston's site is the best place to look, then a consensus that that's where we need to go to get our data, that would be a big help, instead of getting it from multiple sources.

John Curran: We have a question from the head table.

Scott Bradner: Not a question but a comment. You said send out another letter. Well, I wouldn't want to send out another letter with a date that would change. Maybe send out a letter with a pointer.

John Curran: I'll take the one at the mic first, then the online. Three mics. Front center mic.

Jason Schiller: Jason Schiller, Verizon, UUNET and NRO Number Council. I would like to see ARIN publish a number when depletion is going to occur. I would like them to publish their own number rather than adopt a number that's already out there. Although, if they desire to adopt a number that's already out there that says this looks like a good number, that would be fine. But to the extent you would publish your own number, whether it is very close to the Geoff Huston or Tony Hain prediction, would lend more credibility to it. To the extent that it is far away from those numbers, it would give us a range within which we can plan to prepare networks accordingly.

So I think publishing a number would be useful. And I would like for that number to be sort of a live number that maybe not daily but regularly would be updated maybe monthly, something, on the website.

John Curran: Got it. Okay. The online question and then we'll take the mic over there. Online.

Stacy Hughes: Question from Joe Maimon: If all the large allocations are going to be providers, is it expected that they will or when will they be coming back to the well?

John Curran: I guess it is true that we've done this as an internal project, we actually know when everyone got their last block, and when we expect them to come back for the next block and can build a sawtooth demand for all the major providers going back to, say, if you do the top 20 or 30, you hit 90 plus percent of the demand, you can average the rest, put that all on a model and you actually get some dates that coincidentally look a lot like Geoff Huston's dates. We've done the internal bottoms-up demand-based model for the ARIN region and maybe we should look at cleaning that up and externalizing that, because that's in effect what they're asking. Far left microphone.

Matt Pounsett: Matt Pounsett, Afilias. I assume that the ASN stats that were put up there include 4-bytes.

Leslie Nobile: Yes, we do.

Matt Pounsett: Do we have any updates on who is keeping them?

Leslie Nobile: In our region, anyway, I think we've had a request from 278 people for 4-bytes. We ended up issuing 49 of them. And currently we have 11 active because everybody came back and said I can't use this. So over the past year and a half that's where we're at. 11.

John Curran: Center rear microphone.

Bill Darte: Bill Darte, ARIN AC. I actually think if there were multiple sources and they diverged a little bit since nobody really knows when the end date will come to IPv4 exhaustion precisely, having a range of those numbers actually gives people more pause to say there's risk in just the process of analysis here and might get them moving a little bit more quickly than they would if there was an absolute date posted somewhere.

John Curran: Okay. Center rear microphone.

Aaron Hughes: Aaron Hughes. I wanted to point out a couple of things. There's a few sources of data out there and different types of display. One are effectively live counters, right, they're based on what's assigned and what's been reclaimed every single day, and then counters that are targeted on average based on that data, which have really nothing to do with the end date. They're a live snapshot. This is a moving curve. Probably an accelerating curve and that date will come faster than those counters predict. The long-term plotters, the chief scientists at various routing registries like APNIC and RIPE, are analysis and prediction based on their chief scientists that have been hired.

So the question at hand is: Do we want to either hire a chief scientist for ARIN or dedicate some resource that already exists at ARIN to figuring out if those numbers make sense? And part of the problem is fundamentally that could change between now and then in that our policy changes here could affect how fast that runs out. So every time we have a policy proposal, that data will have to be redone again.

So at this point I think we've got two fairly good chief scientists that are doing this and they're giving analysis to the world. And I think it's accurate. And they're continuing to dedicate those cycles already for us even as we change policies.

John Curran: Okay. Thank you. Any other question on the Numbers Status Resource Report?

Leslie Nobile: Thank you.

(Applause.)

John Curran: We're actually running ahead of schedule, so we're going to reach forward in the agenda and pull something in. And I'm going to ask Mark McFadden to come up and give the IANA status report.

IANA Activities Report

Mark McFadden: Thanks. The eagle eyes among you will notice that I'm not Leo. Excellent. So the IANA Status Report consists of these items. A quick look at the pool status. Leslie talked about that a little bit. Some information on some special addresses that have recently been provided. Some reclamation information. And then I want to do a couple of overviews. One is the mechanism for selecting which /8s to allocate to RIRs in this period of scarcity, and then talk about the new reverse DNS self-management system. And then finally take a look at IDN ccTLDs, which is taking up quite a bit of time in ICANN, and as well talk a little bit about a new activity, the IANA Business Excellence Program.

So I'll do those in order and pretty quickly. So the situation here, Leslie already talked about this. There are currently 26 /8s left in the unicast free pool at IANA. Remember, of course, that five of those are the five that are reserved for the end game at the point at which the last ones are allocated. Another thing to note here about this number, in the discussion that we just had, one of the things that's an input to many of the models that are available is the rate at which IANA is actually allocating these /8s. I don't have a slide for that, but I would point you to IANA's website. And on IANA's website, one of the things about the /8 registry is that you can sort it by date.

And if you sort it by date, you can discover very easily a year-to-year comparison of how many /8s are actually being allocated. And it's not really rocket science to actually take a look at 2009 and get a feel for whether or not the rate at which /8s are being allocated are faster or slower. I invite you to take a look at the IANA website and especially the IPv4 Registry. Also, it's worth noting that there remain eight 16-bit ASN blocks. This is a resource Leslie talked about. This is again global the pool. And not much more to say about that, except that that resource is also available in the IANA website if you want to investigate further in terms of rates of depletion.

In terms of special addresses, one of the things that IANA is particularly thankful for to APNIC is providing a range of IP addresses for documentation purposes. This is actually something that has a fairly long history, but APNIC has been kind enough to provide two /24s as special address ranges for documentation that we can actually use in printed materials. And the use of those is actually in an Internet draft right now, which is currently in the RFC Editor queue. It's going to be moved to RFC any day now.

In terms of reclamation, many ARIN veterans will remember that net 14 /8 was recovered in 2007, and the organization that I used to work for actually was one of the holders of address space in that area, and we're happy to return them. That's the only /8 that's been recovered in that way where IANA actually did an effort to recover a large amount of space. It turns out that working with ARIN and the IESG there have been some smaller blocks returned in the last year. I won't go through them. But you can see the size of them. There's one each of a /16, /17, /18, /19, and /20. One of the things you can note very obviously here is that those are much smaller blocks than the /8 that was recovered back in 2007. But the point here is to know that's still an ongoing effort; that when smaller blocks are available to be returned to the IANA free pool, we work with the RIRs to do that.

Another important thing to know is that Duane Wessels did some interesting research a year ago, about 18 months ago, about what was happening in the remaining /8s. In fact, the research is interesting because it shows that people were using the remaining /8s in the free pool regardless of the fact they hadn't been allocated yet. And so the remaining /8s of the first 26 you saw in my slide there have been split into two pools. This is probably the wrong word choice, but a dirty pool and a clean pool. And the idea behind this is that some of the /8s have a lot of activity out in the community, even though they haven't been allocated. Some of the /8s are not like that. There's much, much less. So there's really a division here between the two. And one of the things that I think many of you know is that right now the RIRs have an agreement among themselves where when they come to IANA they ask -- when they have a justified need, they usually ask for two /8s from the IANA.

The way this is working right now is that the RIRs, when they make such a request, get one /8 from each one of the pools. So they get one from -- I regret using these words now, but the one from the clean pool and one from the dirty pool. The selection mechanism within the pools is random. So basically what we've done is used an older RFC, RFC 2777, to actually provide the mechanics for picking which particular /8 in each one of the pools is provided to the RIR. There's two that are set aside, two less used here, which is probably a better use of terminology. Two cleaner /8s have actually been set aside for each of AFRINIC and LACNIC, and the reason for that is their rate of request is so much lower than the other three RIRs.

Something that I think that the RIRs as well as IANA is pretty excited about is the introduction of a reverse DNS self management system. This is currently -- I wouldn't call it a cumbersome process, but it's more cumbersome than it really needs to be. Beta testing on this has been completed. The deployment is actually being scheduled in coordination with the RIRs. It's a secure mechanism, as you see here. It's based on https and there's a public key infrastructure available for it. And one of the benefits of this is that it allows in-addr.arpa and ipv6.arpa to be signed. That's a really big benefit here. It also allows the RIRs themselves to do what I would call very efficient management of their delegations in real time. So that's a huge advantage here.

One of the things that's going on that's very important, it's a high workload in IANA, but it's also in the ICANN community a very large workload, and that is the introduction of internationalized domain names in the ccTLD community. This is not the generic, top-level domain community -- for instance, the .coms, .nets, .orgs -- but this is the .uks, .frs, .us and so forth. And the idea here is to provide equivalence of those ccTLDs in the local language, in the local script.

Those requests -- the proposal is to launch those on the 16th of November. There's actually a proposal in front of the ICANN Board right now to actually launch that process on the 16th of November. That's a far faster process for those people who are engaged in this. It's a much faster process than what's going on with, for instance, the introduction of new gTLDs or IDNs in general. There's a fast-track string evaluation program, and then it goes through IANA's regular delegation process. That's the sort of safeguard here. There isn't a fast track for the delegation process. It's the standard delegation process for ccTLDs. Right now, based on who we've been talking to and what we've heard, we expect about 50, 60 requests for IDN ccTLDs in about 15 to 20 languages. This is pretty meaningful. Many of you in the room as operators are well aware that there already are IDN ccTLDs. But what we have here is the fast track of the production part of the effort. That's I think pretty good news.

Very important part of what's going on in IANA right now, and was part of ICANN's strategic plan, was for a real change to internal operations in IANA, in an attempt to actually bring business excellence to IANA's internal operations and also its external communications and relationship building. And so in that strategic plan there is a section called Strive for Excellence in Core Operations, and there is an absurdly long link there. Apparently I'm not familiar with URL shorteners. But at that link you can actually see that's the PDF of the entire strategic plan, and towards the end is this part where we talk about striving for excellence in core operations.

What's happened is inside of IANA there has been an adoption of a work item on business excellence, and the idea is, first of all, document where we stand. Many people in the room have gone through these kinds of efforts. Basically document where IANA currently stands and then make sure that there's a systematic, measurable, sustainable framework for improvements going forward. There's all sorts of business excellence plans. The one that we're using as a model is a European one. But, for instance, other people in the room would be familiar with like the Baldrige approach to business excellence and so forth. This is very, very similar. And right now what IANA is doing is engaging with its partners in the community to sort of talk about where we stand and what can be improved and so forth.

The time line for that is that there is -- on the 16th of December we're set to publish an IANA Business Excellence document, which is really a document that describes where we stand and how we want to move forward, and then there's a self-assessment component that happens a month later. After that self-assessment component, there is a prioritized list of strategic initiatives and the start of projects to actually -- to implement that business excellence plan.

There's also a communications plan. To be honest, much like ARIN, IANA is -- what the IANA is trying to do is trying to find clever and new ways to take advantage of new communications vehicles, whether it's social networking, whether it's blogging and so forth. And so in the 2009 communications plan, we're trying to use -- not only reach out to our traditional community but also reach out to other people through the very sorts of tools that, for instance, ARIN has talked about this morning already. So that is also part of the business excellence plan, something we'll attempt to do over time, sustainably a better job of that.

Significant IANA news is now posted to Twitter. It's attempting -- it's attempting to just point you to this and then leave it at that. It's updated. The volume here is not particularly great, but it is a really good way to keep up with what is happening at the IANA. And I think I will open it up to questions, if I may.

John Curran: Any questions on the IANA report? Rear microphone.

Bill Darte: Yeah. Bill Darte, ARIN AC.

John Curran: Hi, Bill.

Bill Darte: So, Mark, thank you for your presentation. You mentioned that there's 26 /8s currently available in the free pool and noted that using the term "end game" there's five set aside by policy for the RIRs at those later stages. But then you also noted that there are two /8s reserved also for LACNIC and AFRINIC.

So are there really seven allocated for the end game or a different allocation?

Mark McFadden: No, I'm sorry, Bill, and that's completely my fault for not making that clear. But basically what happened is the two that are separate for AFRINIC and for LACNIC are part of that clean pool. So at the time that AFRINIC or LACNIC come to the IANA for subsequent justified allocation, those are reserved out of that clean pool. They're just part of the general 21.

Martin Hannigan: Question. So why does AFRINIC and LACNIC need a clean /8 at the end? Why can't they share the load with the rest of us and clean up the mess?

Mark McFadden: So that's a perfectly reasonable question. I think this is an agreement -- this is sort of an agreement between -- the idea behind it is the rate at which those RIRs use address space is so much smaller than RIPE.To take the other three -- RIPE, APNIC and ARIN -- they would never have -- the potential exists they would never have an opportunity to get a /8 out of that clean pool. So that's why it was reserved that way. If that doesn't -- I'm happy to talk to you offline, Marty, if that doesn't feel right to you.

John Curran: Front center, Paul.

Paul Wilson: Yeah, Paul Wilson from APNIC. Thanks, Mark. A question along the same lines about the dirty pool. The idea of cleaning up the mess is a lot easier said than done. And what the RIRs have been concerned about, the staff in considering this, is whether or not IANA can do more before handing over chunks from that dirty pool to actually cease -- to have people cease and desist from the kinds of illegitimate uses that are going on. Because in fact to ask an RIR outside of this part of the world, in particular, particularly one like -- those like ARIN and -- sorry, AFRINIC and LACNIC, to take action from their part of the world against something that is likely to be happening more here than anywhere else is really a big ask.

And we didn't go into where the business comes from, who is responsible for it, but it's got to do with taking actions as soon as possible against it. And it does seem that IANA, as custodian for those blocks, is really best place to -- probably most obliged to do something about it sooner rather than later. Just interested to know whether that's being considered at IANA or not.

Mark McFadden: It's certainly been talked about. I think the place where we would like to have help is what actions the IANA could take. I think the IANA would certainly consider taking action if it were possible to be relatively sure that it would be effective in some way. And I completely agree with your first statement about the difference in the ability of different regions to have an effect on this problem. I think the biggest concern that I have, and now I'm speaking for myself here, is that what the IANA needs is an effective plan for what it would do to address the problem, if that makes sense. What action should IANA take here? It shouldn't be a letter writing campaign because in a lot of cases who would you write the letter to? It could be -- so I guess what I'm open to, and I would be open to this all week, is for people coming to me and making suggestions about what actions IANA should take against the people who are actually abusing the existing free pool.

Paul Wilson: Sure. I'd be happy to discuss it.

Mark McFadden: That would be great.

John Curran: Any other discussion? Back there by the left mic.

Owen DeLong: Owen DeLong, Hurricane Electric and the ARIN AC. In the vein of what Paul was discussing, it seems to me that we first need to divide the, quote/unquote, dirty pool into two categories: There's the portion of the dirty pool that people are using internally and there's not a lot of direct visibility to it other than DNS queries and things like that, and there's a portion of the dirty pool that is being actually somehow routed out on the Internet.

It seems to me the former is a lot harder to deal with, although you could try and contact people based on where the DNS queries are coming from, and the latter is probably much easier to deal with in that you identify the provider that's routing it, contact them and say, you know, you're routing something that's part of the IANA free pool and would you mind not doing that. Could probably go a long way in the correct direction.

John Curran: Okay. Center front microphone.

David Williamson: David Williamson, Tellme Networks. Just out of curiosity, can you comment on if the five final /8s have been identified and if they're in clean or dirty pool?

Mark McFadden: No, they've not been identified.

David Williamson: And which one is larger, the clean or dirty pool, at this point?

Mark McFadden: The dirty pool is larger.

John Curran: Okay. Thank you very much.

(Applause.)

Okay. That's a good start to our meeting this morning. It is now lunchtime. Folks should go to the -- time to refuel. Lunch is served upstairs on the second floor in the Bistro on the second level. There are AC topic tables. You'll look around. You'll see various AC representatives spread throughout the tables ready to talk about various topics. Choose your table for lunch based on your level of interest and indigestion.

And remember to vote. NRO NC voting closes at 5:00 today. You have a chance to vote for your NRO Number Council representative from the region. Please go to this URL or click on the vote link on the main ARIN page. Take your valuables with you. This room is unlocked and has no security. Thank you. I'll see you here at 1:30.

John Curran: So the first thing up is 2009-6 Global Proposal, IANA Policy For Allocation of ASN Blocks. There we go. History. Proposal was originally Policy Proposal 89, came in the 29th of May. Became a draft policy the 31st of August. AC shepherds, Stacy and Marla. It's a global proposal, and it's identical in all the regions. It's in discussion in AFRINIC, last call in APNIC, under discussion in LACNIC, and in last call at the RIPE NCC.

It allows for one summary. It allows for one more year for the RIRs to continue to make separate requests for 32-bit and 16-bit ASNs. In other words, to continue to treat those pools as separate until January 1st, 2011. Without this policy, when the RIRs make requests, we would not be differentiating in what ASNs we received. Liability risk, no. Staff issues or concerns, no. Would make sure the editing would remove the word "byte" from NRPM in favor of "bit." Staff implementation, minimal to do so. The assessment is available online at the URL and in the discussion guide. PPML discussion. Five posts. 12 posts by five people. Three in favor. None against.-- "I think modifying the IANA RIR distribution rules to accommodate the needs of RIRs to better serve their constituents makes sense." At this point I'd like to invite -- which shepherd is coming up for this? Andrew de la Haije to come up and present on it.

Andrew de la Haije: All right. I'll give a very short presentation on this proposal because the summary just given is quite sufficient. Until the 31st of December 2009, the RIRs can receive two separate ASN blocks from IANA, which was just mentioned before. So we can request either 32-bit or 16-bit, depending on our needs. As of the 1st of January 2010, IANA will treat this as an undifferentiated pool, basically stating that we can't request specifically for 16-bit. We just have to wait and see what we get. The risk here is that the RIRs will not qualify for 16-bit ASN blocks due to the low usage rate of 32-bit blocks.

Just to give you a bit of an example, and Leslie also gave an example this morning, out of the 1,346 assignments we did this year, basically 10 percent of them were 32-bit and all the others were 16-bit from the start or were basically changed again for 16-bit after getting a 32-bit one. Some of the reasons we see 45 percent of the regions, their networks, devices or member network devices are not ready. Hardware is outdated and there are no updates available. In 22 percent of the cases, one or more of the peering partners do not support 32-bit AS numbers.

There are numerous other reasons shown in the requests we see, and of course the merit of these considerations might be challenged. But overall we see that our membership has quite an issue with it. What is the allocation rate? If we would go on with the current rate, we see that IANA will still have 16-bit AS numbers to allocate until somewhere around 2012 or 2014.

So summary so far: the current policy was crafted around an operational incentive and an earlier run-out date than we are currently facing. Fact number one is there are numerous operational issues. And fact number two is there is still 16-bit left. So our proposal or my proposal is to sync the policy with the current fit. I've been looking at three different alternatives. Do nothing. I'll skip that one fast. Number two, extend the global policy by 12 months. The pros are it addresses all the concerns and all the cons of the last proposals, and it is not a substantial change, and we don't want to change too much on this proposal.

The cons, there is a need for policy change and it's a global one, which is where we are today. And, of course, there's less incentive to get ready for 32-bit ones. On the other hand, that's why we propose a one-year change, so that there's still some incentive to move. And if everything goes wrong, then you'll see me on this stage next year again to again tell you that this is coming up.

Now, this was the other option, run-out of 16-bit. But this is really a fundamental change of the proposal. So basically the current proposal is about option two. Extending the global policy by 12 months, which means that we are keeping a differentiated pool so that we can request 16-bit AS blocks and we can provide you with 16-bit AS blocks if you request them.

Other regions just mentioned under discussion in LACNIC and AFRINIC, and APNIC and RIPE it's in last call. Any questions?

John Curran: Okay. Thank you.

(Applause.)

Okay. We're going to get ready for a show of hands on this. Any comments? Of course, microphones are open for discussion. Sorry. I thought that's what he said.

Scott Leibrand: Yeah, I was confused about that, too. This is Scott Leibrand, ARIN AC, as I'm sitting up here. I also work for Internap. I support this proposal. We're just now getting code that can run 4-byte ASNs. I think we're well on our way. I don't think we're at much risk of not moving on this by delaying it a year, but I think we are at significant risk if we don't delay it a year of having some RIRs run out before they need to and causing unnecessary disruption. So I support this.

John Curran: Okay. Microphones remain open for discussion. Center front.

Leo Bicknell: This is Leo Bicknell, ARIN AC, ISC. I support the proposal. I believe that the appropriate place to apply pressure to vendors and ISPs and such is at the RIR level. I don't see why we should encumber the RIRs talking to IANA.

John Curran: Uh-huh.

Leo Bicknell: And because of that I'd actually feel just slightly better if this didn't extend for one more year, but extended for forever, until there's no more 16-bit pool, whatever date you believe, because I think the RIRs should be able to request the two separate pools because we will be back here in a year. And we already have RIR policies to apply vendor pressure and direct people to 32-bit ASNs first and that kind of thing.

But it is a global proposal changing. It's problematic, so I'll support it as it is.

John Curran: Okay. Thank you. Any other comments at the mic? Oh, yes, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric and ARIN AC. I support the proposal. I don't think the issue whether it goes a year or longer is going to be all that much of an issue, because I don't think 16-bit ASNs are going to last much more than a year if they do make it beyond that at the current rate of absorption. So this policy actually helps, whereas the RIR level policies that I've opposed I don't think actually accomplish much, especially in light of the staff planning to assign the 16-bit ones first just because of their assigning in numeric order.

John Curran: Okay. Any other comments at the microphones? Any other discussion of the proposal? Okay. Discussion's closed.

Now we get ready for a show of hands. We're going to ask the people in the room and our remote participants to participate in a show of hands. This helps the AC in the determination of their job, cage consensus for the proposal. There's going to be one show of hands regarding 2009-6. I'm first going to ask for everyone in favor and then I'm going to ask for everyone opposed. So my high-tech automated balloting system is ready. Yes, very good. Okay. On the matter of Policy Proposal 2009-6 Global Proposal, IANA Policy For the Allocation of ASN Blocks, all those in favor raise your hands now.

(Show of hands.)

Nice and high and hold it. There's a lot of hands out there. ARIN, the RIR with a built-in exercise program. A little longer. All good. Thank you.

On the matter of 2009-6 Global Proposal, IANA Policy For the Allocation of ASN Blocks, all those opposed raise your hand. All those opposed. Any opposed? Wow. Okay. And that's coming forth now. Thank you.

On the matter of 2009-6 Global Proposal, IANA Policy For the Allocation of ASN Blocks, number of participants, room and remote, 135. Number in favor, 72. Number against, zero. Thank you. This will be provided to the Advisory Council for their consideration.

(Applause.)

ARIN Board and Advisory Council Election Procedures

John Curran: Now moving right along, I'd like to invite Jud up to describe the ARIN Board and Advisory Council election procedures.

Jud Lewis: Thank you, John. Hi. Jud again. You may remember me from three hours ago. And today I'm going to be talking about the AC and Board elections. Okay. First off we've got this calendar here. And today at 3:00 p.m. the candidate speeches -- well, after the candidate speeches at 3:00 p.m. the voting is going to open for the Board and AC elections. It's going to remain open for ten days until 3:00 p.m. on October 31st, Halloween.

Also something new this year you want to take note of is we're going to have the candidate speeches that you're about to witness are going to be available online. And that's going to be tomorrow. They'll be available online. And those are going to be in addition to the other things you find at election headquarters, the candidate biographies, the Statements of Support from the community, and the voting booth, where you actually can log in and vote.

Okay. Right here is a sample ballot. This is what it looks like. Names of all these candidates here. On the left-hand side is the Board of Trustees. And you select three people, up to three people for the Board of Trustees, and for -- on the right-hand side is a ballot for the Advisory Council. You select five. And the candidates are listed alphabetically and three year terms beginning the 1st of January, 2010. Okay.

Voting procedures. Unlike for the NRO election, ARIN attendees and NANOG attendees can't vote. The people that can vote in these elections are DMRs. Each of our ARIN member orgs has one person, a designated member representative, that's designed to vote in these elections. And they've already been established to people that are eligible to vote on the 7th of October, was the deadline to establish that eligibility. You need to be in good standing with ARIN and you need to have an e-mail on file with us, where the name of the organization matches the e-mail domain. And it needs to be a personal e-mail, can't be a role account.

So Wednesday, 21st of October, we're sending out an e-mail to all the DMRs letting them know, hey, voting is open. Click on this URL and you can go and vote. And we're also sending that to arin-announce, as well.

Voting procedures. One, you register. When you get to the voting booth, you register to log in using your first and last name and again the DMR e-mail that we have on file for you. Create a username and password. A little asterisk there. Or if you've done this before, if you've voted in prior elections,you can just log in using your old information. Step two, you vote. You know, like the ballot I just showed you, you click on the candidates you want. And, again, it's important, is confirm your vote. Make sure you click the "confirm your vote" page or button.

Okay. Now I'm going to turn this over to John, who is going to introduce the candidates. We have a really impressive slate of candidates for you. And here he is.

Advisory Council Nominees

John Curran: Okay. First up is the Advisory Council candidates. We have some in attendance. We have some not in attendance. The ones not in attendance, we may have a video-recorded speech from them or we may have a statement to be read. So I'm going to work down the list alphabetically. Mark Bayliss. Mark, you here? Come on up. Each candidate gets three minutes to explain why they should be elected.

Mark Bayliss: Hello. Pardon my voice. But I believe my experience as being an ISP from back from 1993, being the head of Virginia ISP Association and my work with the U.S. IPv6 Association and work in early deployments in native IPv6 and real world environments will be a good asset to the AC committee. Also, and most of the ISPs and things that we represent or work with and ourselves are small- to medium-sized ISPs which make up actually the majority of the actually AS holders in ARIN. In fact, the large ISPs -- the large AS holders actually make up less than -- I think it's 150 total. And there's 1,024 small AS holders. So I feel that I'd be a good -- basically averaging of giving viewpoints in the policy actually as to how it would fit to the majority of the -- actually AS members. All right. And thank you, guys. And keep it short.

(Applause.)

John Curran: Thank you. John Brown. And he is not here. Do we have a video for him or do we have a -- okay. I will read his motivation to serve.

To help formulate a constructive policy that matches real-world conditions experienced by small, rural operators and others.

His background is: Network geek in New Mexico, rural network operator and backbone provider to other rural providers, co-founder of the statewide Internet exchange, former net.geek for L-root DNS server, previous member of the ARIN AC, and a user of ARIN resources.

Next is Rudolf Daniel, and we have a video for Rudolf.

(Video.)

Rudolf Daniel: Hello all, the ARIN Board, the AC council, the ARIN staff and the community at large. Good day to you all. My name is Rudi Daniel. I live in St. Vincent & the Grenadines. That's the English-speaking Caribbean, of course. And over the last 20 years I've lived and worked in Great Britain as a design and development engineer within the defense marine and offshore communications OEMs. Now I live in St. Vincent as an ICT for development consultants. So I assist SMEs, governments, regulators alike, to hopefully better understand how we can use these new tools that we have to increase our potential, depending on the environment that we're in.

I'm really quite excited at the opportunity here to participate at a regional level on the policy development process. And I am really looking forward to a learning experience if I am selected. It is also very important to me to leverage such an opportunity so as to provide a resource to the region at large about the importance and the relevance of Internet policy within the governance framework. This is something that I think that we all need to become better at. And if through me that ARIN can better understand the situation, the conditions in my sub-region, then I think a valuable contribution would have been made on both sides. So I respectfully ask for your support and for your vote. So thank you very much. Bye.

(Applause.)

John Curran: Next candidate is Steve Feldman.

Steve Feldman: Hi. I'm Steve Feldman, currently working for CBS Interactive and part of the NANOG steering committee. But also in my career I've worked for a variety of different companies, service providers, a vendor, enterprises large and small. So kind of been all over. You can see my motivation is kind of long-winded up there, so I'll summarize it for you.

At this point with things going on like IPv4 run-out and IPv6 implementation, policies that ARIN creates have an opportunity to have a very large impact on what happens for a long time to come. So that means we need to be really careful with what we do. We need to balance the often-competing issues of stewardship, availability of resources, premise of allocation and, most important, awareness of how things work out there. That's not simple. These are often opposing issues and often compromises are going to be necessary.

I'll finish by reading something that I wrote that isn't shown up there. I have no specific policy agenda other than to ensure that ARIN's policies represent and benefit the entire community and are well thought out, fair and realistic. And if I'm elected, that's what I pledge to do. Thanks.

(Applause.)

John Curran: Thank you, Steve. Next candidate, Wes George.

Wes George: Hi, all. I think most of what's here is self-explanatory, so I'll just hit a couple of things quickly. Been working at Sprint for about 10 years now, which I know is like forever in telecom years. I think it's given me a good range of experience in a number of different areas, because I started out as a staff puke in the NOC and have kind of worked my way up to -- through higher levels of operations and in engineering.

So I think that gives me a good perspective of operational issues and also some of the challenges on the engineering side, especially in the IPv4 side. I've been -- near single-handedly been baby-sitting Sprint's IPv6 test bed for -- I guess it's probably been at least five years now. So I have some real-world experience in a small network there, and I'm also heavily involved in Sprint's roll-out of IPv6 on the production network that's starting to happen now. So I think from that perspective I have a good level of experience. I don't go into this with a specific agenda in mind. I think it's better to go into it with an open mind in order to try and get the best representation of what the community actually wants.

I'm not afraid to challenge people on things that I don't think make sense because I think it's better to have that discussion and to come out with a better product overall. But I don't want my own opinions to color this so much that I'm not an effective representative of the community. So I think that's about all I have to say. Thanks.

(Applause.)

John Curran: Chris Grundemann.

Chris Grundemann: Sorry to make you wait. I actually sit back there on purpose, so I give my heart some time to slow down. I'm definitely not a natural public speaker. That being said, I'm getting a little bit more used to it even if I'm not getting better. About a year ago, about this time last year, I stood on a stage just like this one in Los Angeles and tried to explain why I thought I was a qualified candidate for the AC. That didn't go exactly as I had planned, so I'm back here this year. And this time I think I'll tell you a little bit about how you can see that I'm a good candidate.

The first thing is my activity on the Policy Mailing List. You can go through the archives and search for my name. I think I've contributed to refining the details of quite a few really good policies. I also co-authored a policy, 2008-7, which was just adopted by the Board after the last meeting. Another thing that I think makes me unique is that this is my third in-person ARIN meeting and it's the third time that I've attended an ARIN meeting on my own dime. And I don't tell you that so you'll pick up the check tonight at dinner. I say it because I think it demonstrates my personal commitment to this community and to this process. I truly believe in the open, ground-up, consensus-based approach to Internet policy in general, especially numbering policy.

If you want to know more about my specific beliefs and stances and positions and qualifications, I tried to answer the questionnaire as thoroughly and honestly as I could. Also, please feel free to come find me during one of the breaks or at a meal or at the social event tomorrow night. With that, I guess I'll just ask you to please vote, and if you do vote for me, I'd appreciate it. Thank you.

(Applause.)

John Curran: Thank you, Chris. Stacy Hughes.

Stacy Hughes: Okay. Talk about not a natural public speaker.

(Laughter.)

It seems like only yesterday I was here three years ago asking you for your vote. Everybody says it seems like yesterday, but really I dread this for every three years. My manifesto is online. I won't read the slide, but my manifesto is online and my voting record is online, so please visit that. Also, inexplicably a song in support of me is online. I would be honored to continue to serve, and I ask for your vote.

Small ISPs, CLECs and end-users large enough to need a direct allocation seem to be underrepresented with ARIN. I do not fault ARIN with this. It's a result of us as a group not getting involved. As a result, I decided to get involved after the nudging of several of our clients.

So thank you.

Mark Johnson. I'll read his motivation to serve.

It's important for providers to actively participate in the governance of the Internet. I would like to help the research and educational community take a more active role in ARIN, collaborating with the commercial sector to provide responsible stewardship for Internet resources.

His biography is right there. Ed Kern, come on up.

Ed Kern: So I actually look forward to these events because looking back at my bio, when you see the 17 years go by, a lot of the times you're in the room and you're the one with the most experience, but I look around this room and I see Cathy, my NearNet friend, and Scott, especially Scott. And I'm the young dinosaur. It's great.

(Laughter.)

So I was on the original Advisory Council that was picked and at the time I decided not to rerun because of time constraints. I'm now with Cisco for better or worse, even though that certainly doesn't -- I have my own agenda and I certainly don't carry Cisco's agenda into this. Lately I've been working on the RPKI side, basically about BGP origin, validation. And that kind of got me much more interested in how things were going on and the validity of the ARIN database. And it concerned me more and more that I think ARIN policy -- you know, I don't want to say -- it makes it more difficult or certainly puts obstacles in the way of people to come up and keep that data up to date or as accurate as possible. And when it comes to origin and validation, that's certainly going to be an important thing.

Let me think of anything else I really want -- as far as an agenda, I guess I'll be the one that says I do have an agenda towards the direction I think ARIN's going, and that's I always envisioned way back on the original Advisory Council that ARIN was more of a -- it says stewardship, but it was more of a title company or a very important bookkeeping function and it wasn't -- I didn't think it was the place that they should be the ones that dictate -- I think it really comes from the provider. I mean, that's my background and even though that's the Wild, Wild West, some might argue, I think that's where the control in a lot of ways should -- that's where the control should remain. And I think that's it. I'll turn it back to my NearNet friend.

John Curran: Thank you, Ed. Chris Morrow. Candidates passing each other in the aisle ought to be cordial; no rib punches.

Chris Morrow: Ed does have a shiv. Sorry for my voice. I can be really quick. My name is Chris. I work for Google now. I spent the last eight or nine years doing Internet things for Google or for UUNET before that. I think I provided some value in the past to ARIN and would like to do that as well on the AC. Please vote for me. I can't talk anymore.

John Curran: Thank you, Chris.

(Applause.)

Bill Sandiford. And Bill actually is unable to be here due to travel logistics. He asked that I read his statement.

Good afternoon. First, I wish to apologize that I'm unable to be there in person today. I'll be arriving tomorrow and look forward to meeting many of you in person. I wish to extend my sincere thanks to John Curran who has graciously agreed to read this statement on my behalf and my absence. As such, I promise to keep it brief.

I'm honored to be nominated and standing as a candidate to the Advisory Council. Organizations which I represent operate in several countries in the ARIN region, including Barbados, Canada, Jamaica, the United States, as well as Trinidad and Tobago from the LACNIC region. I feel my extensive board and group governance experience, as well as the extensive experience gained from over 15 years in the Internet and telecommunications industry, will be an asset to the Advisory Council and will make me a valued member of the team.

As IPv4 pool nears depletion, our industry finds itself at a crossroad. I'm of the opinion it's not ARIN's responsibility to maximize the duration of the IPv4 pool but, rather, to continue to ensure that the IPv4 space is well utilized. I'm also of the belief that ARIN needs to encourage and foster the adoption of IPv6 via its continued participation and industry events to raise awareness of IPv6 and by continuation of the fee waivers already in place.

If elected, I look forward to working with the Advisory Council and the members of the community to deal with these issues and any other issues that may come up in the future. Finally, I wish to apologize to anyone who is offended by an e-mail I sent to ARIN members during the petition process of this year's election cycle. As I mentioned previously, I'll be arriving in Dearborn tomorrow and welcome the opportunity to sit down to discuss the situation in detail with anyone who desires to do so. Thank you and enjoy the rest of your time. Bill.

(Applause.)

Christopher Savage.

Christopher Savage: Hi, everybody. I'm the totally new guy. My reason for wanting to serve is because I've sort of been on the periphery of the technical sides of the Internet for the last 15 years or so in the policy work I do for telecom Internet companies in Washington. And a client of mine suggested that I do this on the thought that the experience that I got from like the 25 years I've been in the PSTN, which has its own bizarre set of networking and addressing issues, might be helpful over the next cycle as the Internet community deals with the IPv4 exhaust and converting to IPv6.

It's obviously not an identical set of situations, but my hope would be that the kinds of policy issues and the kinds of solutions and things that work out in the PSTN might be helpful in making this transition on the Internet side. You know, plus all the usual reasons. I mean, the Internet has been very good to me and I'd like to do something to give back to the community. So that would be it. Thanks.

(Applause.)

John Curran: Heather Schiller.

Heather Schiller: Like Stacy and a couple of others, public speaking is not my favorite thing. But I can stand up and do it when it counts, especially when it's something that is really important and I'm passionate about like address management and ARIN policy.

So I've done -- I've been with UUNET, Verizon, MCI and all its iterations for about ten years. Managed router space there for about the last five years. So I've seen just about every kind of customer and address request I think imaginable and how that affects, how our customers are affected by ARIN policy, how ARIN policy could be improved based on some of the customers' needs. So I think that I'm pretty well qualified to be able to lend a hand and participating on the AC and representing a lot of views of different needs for ARIN policy.

In addition, I'm really passionate about having very clear and concise policy that -- some of the comments that were made at NANOG about policy being confusing and cleaning up the NRPM and that kind of thing. So I really enjoy doing that part of it. And I'm also interested in the RPKI stuff and what ARIN can do in policy to help secure routing. And I've really enjoyed my term on the AC thus far. So I look forward to continuing that. Thank you.

(Applause.)

John Curran: Rob Seastrom.

Rob Seastrom: Good afternoon. My name is Rob Seastrom. Some of you know me as RS. I'm standing for re-election to the Advisory Council. I work for Afilias, DNS registry and TLD operator. I've been involved in our industry for almost two decades. I've worked for large ISPs, small ISPs, large CDN, and now I'm working for anycast DNS operator. This makes me sensitive to the needs of large, small and nontraditional users of address space and the need for policies that accommodate the needs of all stakeholders in an equitable way.

We're living in interesting times. The inevitable and imminent depletion of the IPv4 free pool and rise of IPv6 raised many difficulties, both technical and political. But as we address those difficulties there's an opportunity for the ARIN community's bottom-up policy process to really shine. I'd like to thank my colleagues on the AC and the Board of Trustees for countless hours of work to enact good policy, but most of all I want to thank you, the community, for bringing us good policy proposals forward whenever you see the need. So, in closing, I'd like to ask you to vote for me as a candidate for the ARIN AC. Thank you.

(Applause.)

John Curran: Scott Weeks. I'll read his motivation to serve.

I'd like to give back to the community from which I've received so much. I have no affiliations or other interests that would cause me to have a planned agenda. I would enter open-minded, impartial and willing to listen to all points of view equally.

His background is shown on the slide. Thank you. Tom Zeller. I will also read his motivation to serve. Oh, he's here. Sorry, Tom.

Tom Zeller: Hello, hello. My name is Tom Zeller. I'm with Indiana University where I've been for 27 years. I'm thinking of staying. For the last 22 years I've been in a telecommunications-related role. As an institution, we were an early -- we helped in the formation of the Internet2 and design of its initial nationwide network, and we're still the NOC for Internet2 as well as the National Lambda Rail as well as 10 or 20 other statewide and international networks, and also home of the REN-ISAC, which is a higher education security information sharing center.

We turned on IPv6 on all 30,000 of our data jacks about five years ago. Although, of course, we still only have a trickle of traffic. So we have a long-time commitment as an institution to Internet governance and an interest therein. Personally I've been more involved on the enterprise networking side of things, leading teams that introduced Wi-Fi to campus. We now have 4,000 wireless access points. Introduced VPN to campus. Led the team that introduced firewalls into our data center. And more recently worked on with a group to define our Voice over IP platform and network architecture strategy, and another group to develop a 10-year, $180 million telecommunications plan, which in the higher ed space is a lot of money. I've worked with Internet2. Joint Techs has a side conference on enterprise large-scale campus networking issues called NetGuru, and I've moderated and hosted that for the last three years where I've worked with Lea Roberts and Dave Farmer who got me interested in what the ARIN committee does.

Outside of my work life, I've performed a lifetime of public service. I started a couple of 501(c)(3) nonprofits, which are going strong 20, 25 years later, with a handful of staff on each of those. And I see the ARIN committee as further public service, and I think what I bring to the table is a lifetime of being a good group collaborator, listen to all viewpoints with respect, and helping to form consensus and moving forward as a group. And I look forward to the opportunity to do that on the ARIN committee. Thank you.

(Applause.)

Board of Trustees Nominees

John Curran: Next up is the Board of Trustees. We have five candidates for the Board of Trustees. First one on the list, Paul Andersen.

Paul Andersen: Good afternoon. My name is Paul Andersen. And for those of you I haven't met, here's a little background about me. I've been in the service provider industry for over 15 years and been very active in Internet industry governance. Since I founded it in 1996, I've been with EGATE Networks, a hosting provider which offers a variety of services in and around Ontario Canada. I've been on the Board of Directors of the Canadian Internet Registration Authority that's responsible for the operation of the .ca domain. And I'm currently the chairman of that Board. I'm also an elected member of the Board of Directors of the Toronto Internet Exchange, which is the largest open peering and Internet exchange in Canada. And I'm currently serving as president. And, finally, since 2003 I've had the great honor and pleasure of serving on the ARIN Advisory Council.

The Internet community is in the midst of a massive transition in the way we operate. We are facing the technical challenges of migrating to IPv6 and dealing with the imminent depletion of the IPv4 free pool. As a member of the Advisory Council, we have spent considerable time on the policy work in this area, and it will be significant and continued work for the Council and the community. As this happens, ARIN itself is faced with several transitions as it copes with this different world. The Board and the organization has and continues to do significant work in this area, and I would appreciate the opportunity to join the Board in this important work. These changes will potentially involve many facets of ARIN. Membership services potentially takes on new roles. The revenue stream can be affected. The way the organization does outreach will need to be affected. And, most importantly, the policy process itself will need to continue to evolve to effect this changing role. All this will operate in an open and transparent manner to you. Again, I've enjoyed enormously working with my peers in the Advisory Council and have appreciated the opportunity to guide the organization's policy over the years.

With your mandate to serve on the Board, I will be able to contribute to ARIN more of my experience with governance as a not-for-profit registry as well as bringing more geographic representation. I do prefer to keep these things short, so I'm inviting any one of you with questions to feel free to grab me in the hall after or drop me a line, paul@egate.net, and I'll be happy to talk with you about any of this. I appreciate your time. I appreciate your support and your vote.

(Applause.)

John Curran: Thank you, Paul. Next up, Scott Bradner.

Scott Bradner: Good afternoon. So Ed calls me one of the old guys.

(Laughter.)

John Curran: Did he say gray beard?

Scott Bradner: No, I think he said old guy. But in any case, I'm one of ARIN's founding members, along with this guy here. It's been an interesting adventure. ARIN certainly has changed over the years. It's going to change some more. I'd like to be around to help make sure that the founding principles and the continuing principles are related in some way. This is a time when it's not entirely clear that somebody running for the board of an organization serving the particular role ARIN does at this particular time is indicating sanity.

We are in a confluence of events that we just heard some about. IPv4 run-out, IPv6 run-up. Going into an era of transfers. Significant turmoil in the Internet governance space, with the ICANN, the changes in ICANN structure, the relationship to the U.S. government and other places. What's going on with the IGF and the ITU. These are all things that are going to make this job interesting in the most morbid sense of that word. But I'd still like to try. I'd still like to do some of that. Three years ago -- as Stacy said, it seemed like last year -- I followed Stacy up, just like I did this year, and I can't -- I said at the time I couldn't remotely show the level of passion for the role that Stacy shows. But I do my best. Thanks.

(Applause.)

John Curran: Thanks, Scott. Next up, Lee Howard.

Lee Howard: In every boy-band there's the cute one, there's the crusty one, there's the Canadian.

(Laughter.)

I like to think of myself as the approachable one. I think that I've been very active trying to welcome people to the Public Policy Mailing List, to encourage them to post, and to encourage people to refine their ideas and take other ideas into account. And I try to do that in person, too, at ARIN meetings, at social events and, of course, at other industry events; earlier this week at NANOG, tried to encourage people to participate in the process and make it very easy for them to do so and of course to speak directly to a Board member. And I think that I try to be very, very welcoming in that role.

I have been doing this particular role for a while as an ARIN Board member, and I appreciate the confidence that the community has shown in me in that respect. I do have experience at large ISPs and small ISPs and a hosting company and an enterprise network, and so I think I can represent various different constituencies well. I'm currently an active advocate for IPv6 adoption and pushing where pushing needs to happen. And, finally, I guess I should point out that I'm also a very active member of the ARIN Board; that I look for things that I can do to contribute.

If you go back and look through the minutes of old meetings -- it's tedious, I know -- but if you go back and look through minutes of old meetings, you'll see I'm often the person making or seconding a motion or proposing a new idea or trying new things to move us forward. And so I think that I bring a lot to the Board in that respect. So I just want to say -- remind you my name is Lee Howard and I would like your vote. Thank you.

(Applause.)

John Curran: Aaron Hughes.

Aaron Hughes: My name is Aaron Hughes. I'm the president and CTO of 6connect. Over the years my role in companies I've worked with have varied from systems, network, product, architecture, its implementation and operations. Today I work with companies to plan for change, survivability, M&A, DR planning, cloud computing, data center load cost reduction, and IPv6 deployment strategies. With each of these projects I spend a good deal of time working to make sure each decision is fiscally responsible and meets the specific criteria as well as recovery time objectives. Just like each of you preparing for change IPv6 will bring to your respective companies, the ARIN organization itself must prepare for survivability.

Discussing fiduciary responsibility is not something we do directly every day at an ARIN meeting. However, in the next few years, the financial model of ARIN is going to change. The Board must continue to prepare for run-out. There are a good deal of options that the organization can evaluate for its future viability and continued good stewardship of our community resources. I have a unique blend of skills and industry experience which, when combined, are optimal for serving on the ARIN Board of Trustees, and I ask for your vote. Thank you.

(Applause.)

John Curran: Frederick Silny, and we have a video.

(Video.)

Frederick Silny: Hello. My name is Fred Silny. Thank you very much for the opportunity to talk to you today. Unfortunately, I'm traveling in Europe and can't be with you in person. I'd like to spend a few minutes going over my background and how my experience can be used serving on the Board of Trustees of ARIN. My experience has been as a chief financial officer and corporate secretary at both public and private companies. I've also served on the boards of private companies and nonprofit organizations. I spent the past 30 years focused on financial matters, corporate governance and fiduciary issues. I understand the challenges of governance issues, and I also understand the difficulty of making good business decisions and strategic decisions.

Although I don't have a technical background in the Internet IP world, I'm generally comfortable with IT issues. One of the companies I worked for was carsdirect.com, an Internet retailer, and three other companies I was responsible for the IT organization. At ARIN, I'll spend the time necessary to learn about the technical aspects of critical issues as they come up. I first heard about ARIN from one of your Trustees, Tim Denton. He explained the purpose of ARIN to me and how it's organized, and also some of the policy-making issues that you're dealing with. I've also spoken to other members of ARIN to get their points of view. The ARIN Board expressed some concerns about its lack of financial experience, and that's why I was approached, because of my relevant financial experience.

I understand from my discussions that the transitions to IPv6 may require ARIN to make some fundamental decisions about its future. To the extent that this change is inevitable, I'd like to help out in defining the future model of the organization. We are very, very fortunate that ARIN is voluntary, rather than government-led. I believe that it's absolutely critical that we stay flexible and adaptable and that we maintain a democratic policy-making process and stay relevant to the community. I'm sincerely interested and committed to bringing my financial and business background to ARIN. I'm a team player, and if you elect me as a Trustee, I'll do my very best for you. Thank you.

(Applause.)

John Curran: Okay. That completes the candidate speeches. And at this point we're running a little ahead of time on our break, so we're actually going to have Andy Newton come up and give a presentation on ARIN templates. Okay. He's on his way. So you'll enjoy a minute of my singing and dancing.

(Laughter.)

For those who look in the archives, there is actually a video record of me singing up here. It's not a pretty sight. Is Andy on his way?

Open Microphone

John Curran: Does anyone have any topic they'd like to bring to our real quick open mic session? No? Yes? Instant open mic. Cathy.

Cathy Aronson: Cathy Aronson, ARIN AC. We had a little side discussion -- maybe it was last night, but this is like dog years, so I don't remember -- but about people working together to perhaps come up with a more streamlined process for cleaning blocks to get back into the free pool. Because as we get closer and closer to run-out, we're going to need to do that faster than a year, and I just wondered, A, what people thought about that, and, B, who might be the link to work on it with me, without me, whatever. But, anyway, that's my thought.

John Curran: Raise your hand if you're interested in working on a process for cleaning up recycled blocks. Come on.

Cathy Aronson: The person I was discussing it with --

John Curran: I volunteer Leslie. Where is your hand? Leslie's hand is up.

Cathy Aronson: Apparently there's a process for domain names that maybe we can start with. If you guys will give me your e-mails. Well, I know Lea's. Maybe I can get us all chatting. Thanks. I don't know, do you want to talk about the process for domain names? You're the one who told me about it.

John Curran: Briefly. We have the time.

Eric Klein: My name is Eric Klein. I have a company called eDataCenter. Domain names have a process. If you know what you're doing, you can clean up a domain name that's been abused in the past but has come available in about five days. And it gets it off all of the blackhole lists and registry systems that screw up the domain system. And I want to try to develop a process to help do that with IP numbers.

John Curran: Chris, do you want to respond? Or new topic?

Chris Morrow: Oh, no, same thing. So -- Sorry. Chris, Google. So ARIN actually publishes a list of things as they come off -- I think they're reallocated or they get reclaimed -- So my name is Chris; I work for Google. Domain name's great. With IPs, ARIN publishes the list of blocks that they get reclaimed or as they get put back out into the field for new customers, and the current blacklist operators could follow this RSS feed and do what they want. The problem is that most of them -- I'm sure there's one in this room that's going to yell at me -- but most of them are just crazy. Or the lists are abandoned and they don't get followed. So I've dealt with this at UUNET for other customers and it's really a pain in the butt.

I had some big long discussion on it, I think ARIN discussed about this, you know, if there's a way for ARIN to more publicly make this information available, great. But I think that trying to go out and find every RPL operator out there, that's an exercise in futility. Unfortunately. That and you also have people with firewalls and other random crap that they forget to put things in them.

John Curran: Folks who are interested, find Cathy and get together and we'll see what they come up with in their exercise. Hopefully it's not futile. But obviously they get some challenges. Okay. Do we have Andy? Yes, wonderful. Next presentation will be Andy Newton giving a presentation on ARIN templates.

Retiring E-mail Templates

Andy Newton: Hi. Good afternoon. My name is Andy Newton. I'm Chief Engineer at ARIN, and today I'm here to talk to you about the retiring e-mail templates. There we go. We sent out a consultation last week or the week before last, September 25th, so it wasn't last week, regarding the retiring of e-mail templates. And there was a lot of feedback on the Mailing List. I'm not sure we fully explained ourselves when we did that. However, Mark did try to clarify. We are not trying to talk about SWIPs in this proposal; we're really talking about POC and ORG modification or operation templates and a request for new resources.

The confusion with SWIP is understandable. At our last ARIN meeting we had a Future of SWIP BoF. I can't exactly remember the name of it. Essentially it was a consultation or our attempt to understand what the community wants as far as SWIP is going forward, and the conclusion was that we had to have some sort of automated way of doing SWIPs for the networks and the network operators. But this consultation doesn't regard that. This consultation is really about templates that are not really backed by an automation system. So what we mean by nonautomated templates or templates that aren't backed by an automated provisioning system, like I said, we're talking about ORGs and POC templates, the creation, modification, and deletion of those, and requests for new resources. And the reason we believe these are not backed by an automated processing system is because we, ARIN, ourselves, we don't tend to process these things automatically in our own system. There's the likelihood that a template can come in, one of these types of templates can come in, and they will be responded to by a human. I believe actually only one of these types of templates gets processed automatically. When you have a human responding to e-mail, that really is not conducive for automation.

There are other reasons, and we talked about this in at the last meeting. But e-mail itself has certain problems. First off, it's fairly insecure. We do have security measures in place such as X.509 and PGP. But as you can see, we have 234,000 some-odd POCs registered in our system. Only 19 use X.509, and 48 use PGP. The adoption for POC templates is fairly low or for templates in general is fairly low. The other reason is that e-mail has this kind of spam problem. We get a lot of it in our mailbox. Sometimes on occasion our stuff will get caught in spam filters, too. And then there's the whole thing that e-mail is not very interactive. So when a user goes and fills out an e-mail template, they make a mistake, they send it in, they have to wait for us to respond. Sometimes that can be auto processed. Sometimes it's not. And then they're not really as intuitive as a website is today. Most people who are dealing with interactions over the Internet usually expect a Web interface.

There have been some suggestions on the Mailing List that we basically do both, continue with the ARIN Online and continue doing templates. And the reason this proposal was made wasn't because we hate e-mail templates specifically. It really has got to do with what it costs for us from an operations support and development standpoint to go forward with new development while we have the templates going on. So dual operations is not a cost-free situation. There's ongoing maintenance. Like I said, there's engineering time to fix bugs. Sometimes we do find some esoteric bugs in our Regtool program. Other times there's bugs in people's MIME attachments and debugging those kinds of things can be kind of difficult. When you contrast that to the Web experience, when users do sometimes have problems with Web browsers, and I will admit that happens, they tend to be able to go to another browser. Most platforms have multiple browsers available and that usually solves their problem. We have operation staff that have to keep both systems running. So essentially we have to monitor that. We have to make sure everything's going smoothly and that takes more operation staff to do. And then we have -- even though we have the security measures that aren't highly adopted with the e-mail templates, we still have to go through the security practices for the certificate authorities associated with them, and that takes time and personnel to do.

So there's training support. We have to have help desk staff that understands both systems, and there are differing business rules. Again, on the Web you can usually get things done pretty fast. E-mail templates, there's a lot of back and forth. And when users mix and match both of those things, you can have a lot of frustration going on. We have to update our training materials to support both if we want to do dual operations. And if you think about this from a new user's perspective, coming to ARIN, there's a lot of terminology you have to learn in order to get resources. Our data model, it doesn't exactly match the other RIRs. There's just a lot of learning that has to go on. And when you also say -- oh, by the way, there's two ways to talk to us. That's just adding more to the learning curve.

And there are also development conflicts. As we continue to try to add more services to ARIN Online and to our other systems, we have to accommodate what the old systems are doing, because, again, you can have conflicts. The new systems must accommodate the legacy behavior. But, on the flip side, the legacy systems really don't know about what's going on with the new systems. And there can be conflicts there. We had one recently with what we call the IRR wall, which is our new IRR pilot which we just announced where the templating system doesn't really know that that new system has come online. So it can accidentally wipe out some data that it's not supposed to. So we have to take precautions about that. The old system can also wipe out in-flight X series templates that someone may have actually submitted via the Web as well. We have to take those kinds of precautions.

In addition, we have business process reengineering that we've been doing. We've talked about that at the last meeting. BPR is really our attempt to simplify our processes so when people come to us, their interactions with ARIN are much simpler than they are today. It's also about making our side of the conversation much more efficient. And the legacy systems, really, they don't know anything about BPR. And when we do our analysis, we have to say, well, we can't make that reengineering effort right now because we have these legacy systems that are doing this. So those are the costs. It slows down our development of our new systems.

So if we speak about what we have with ARIN Online, you know, the proposal was as we add these new features to ARIN Online we like to deprecate the duplicate features we have in templates. It's not a full-on flag day where we're cutting off e-mail templates in general. So -- but if you think about what we can do with ARIN Online, the business process re-engineering we have been able to do -- you can see that today with POCs, where they're able to write directly to the database. You actually don't have to open a ticket today when you go to the website to do that, versus the templates. The adoption curve. So we did look at the adoption curve from the online site. That was one of the questions we got. And from the get-go in October of last year when we announced ARIN Online, from the first moment it went live it was actually doing more business than the templates were. We did have the activity dive down in the early part of the year, but if you look at it today, it's far greater than what we see with e-mail templates, and it continues even though both are seeing less activity. And, of course, it only makes sense -- the online experience is basically a method of interacting with a company on the Internet that a lot of people are used to today. They're not used to downloading e-mail templates and changing the e-mail and sending them in. That's not a very common means of doing business today over the Internet -- whereas a website is. And of course you have the immediate feedback of Web forms. Today when you go to ARIN Online, if you're trying to fill out a POC and you get the country wrong, we tell you right then and there you got the country wrong. Versus if you send it in with a template, you may have to go a couple rounds with our template processors or with a human being. There's also what we call the X tickets which can be tracked. So online you have tickets that have status more than just they exist. They can be open. They can be closed. They're in progress.

And that's not just a benefit for the end-user, it's a benefit on our side because we can assign workflow on the back end, who within ARIN is supposed to be handling this ticket at this moment. With the e-mail templates, we don't have that. E-mail templates, essentially once they get created, once the ticket gets created, it simply exists. And of course then there's online help. If a user has an issue when they're using the website, there's the online help system. And of course we also have functionality which users can't get today with the e-mail templates. Today they can log in, look at their networks, they can look at the different things that are associated with them. And real soon we're going to have reporting features where they can actually get via an Excel spreadsheet their reassignments and their network associations.

Speaking to the issue of security, like I said, the templates, we have security mechanisms, but it's not heavily utilized. With ARIN Online, everyone who uses the system has to go through a secure channel and they have to have a password. And it's not a simple password you can put in there. Our password policy is quite strict.So what that does is that mitigates people using templates. You can't do this online, but with templates you can kind of commit fraud with those today. If you find a POC or an ORG or something that's not well guarded, you can get the information to spoof it and you can take it over.

So, as I said, we asked the community: What should we do about this? And that's what we're here to ask today. So what should we do about this? Should we allow the development to be slowed? And that is one possibility. Doesn't mean we can't do it. Someone suggested charging people more for templates. I'm not sure how that would work. But I guess that's one possibility. And the other thing is what do we do about security and when do we start to sunset this. You can ask me now or you can send e-mail to the Mailing List.

John Curran: Microphones are open. I see rear microphone.

Aaron Hughes: Aaron Hughes. First, I did send objection over consult regarding SWIP. I did not understand this was limited to POCs. And that does generally change my opinion on this. However, I just sat down and tried to log in and got "service unavailable. The system is temporarily out of service. Please check back soon. Could not find stateful bean." When I send an e-mail, it works 100 percent of the time. This has got to be reliable before anybody's going to use it.

Andy Newton: Yes, they were having issues today. Generally that site is available 100 percent -- well, 99 percent of the time.

John Curran: It's 100 percent of its available time. Which unfortunately is not all the time.

Andy Newton: I understand your point, but e-mail doesn't always -- does bounce as well. And we do have problems with that. Like I said, we do have to fix bugs with people's e-mail templates as well, their MIME attachments.

Aaron Hughes: I know how to fill out an e-mail template, and I've never in 15 years had a problem with an e-mail template unless I made mistake. But I only tried just one time to log on and I got failure. And that's 100 percent failure and 100 percent success. That 15 years of reliability in e-mail tells me it will continue to work. This tells me it still needs some development.

John Curran: Point taken. Obviously you can't phase out templates until you have a reliable track record on the new system. We have a question from the floor.

Stacy Hughes: Question from Joe Maimon -- or a comment, actually.

Joe likes the e-mail form. It makes a very nice paper trail. He thinks the -- at a minimum it should be kept active and working until disuse shows it otherwise.

John Curran: Okay. Got it. Center rear microphone.

Martin Hannigan: Martin Hannigan, Akamai Technologies. First of all, I'd like to thank you for this effort. I use this and only this to manage all of our IP address space right now. In fact, I appreciate that you are implementing the export, because I think that was upon my request, and that's a function that will be very helpful for us to do audits of our address space. I appreciate Aaron's comments, although I don't know if he monitored his send mail outbound queue for the last 15 years, so I suspect that there were problems that were transparent potentially. And I do understand that this is in development, and I strongly support this effort.

I would say that I hope that you are cognizant of how far you do take this, because I think at some point it becomes a managed service and then the costs become disparate; i.e., the fees are disproportionately spread to support the service based on the utilization. Thank you.

John Curran: Got it. Microphones remain open. Yes, far left mic.

Peter Finocchio: I'm Peter from Cablevision. Ran into an issue recently with assigning point of contacts to ORG IDs. I'm just wondering if you're going to allow that process. Because I was told that I had to use a template to actually assign a point of contact to a new ORG ID that was just -- that I wanted to create. Is that functionality available now, or is it going to?

Andy Newton: I believe we just recently released that feature. I think we call it POC recovery on the website.

Peter Finocchio: Great, thank you.

John Curran: Center rear microphone.

Alex Ryu: Alex working for KDL. I oppose this idea because there are -- if you look at the usage, there is still a lot of people relying on the e-mail system for the template. If the people still use the e-mail system, there should be some kind of reason. So we should choose the protocol system until people don't need it anymore.

John Curran: Got it. Far left microphone. No. Center mic.

Leo Bicknell: Leo Bicknell, ARIN AC, ISC. I to want to applaud the development of this Web interface because I think it will be greatly used and appreciated going forward. And I would like to reiterate a earlier comment that I think the time to deprecate e-mail is when there's some statistic showing that users have voluntarily started using the Web interface and are using the e-mail interface less. That is the time that you know that you've gotten it right enough that we can consider getting rid of e-mail. Until then it's premature.

John Curran: Acknowledged. Microphones remain open.

Stacy Hughes: I have another comment from Joe.

John Curran: Yes.

Stacy Hughes: He says: There is also the possibility that continuing with unsecured templates could become untenable, and in which case the only way to keep offering that service is with PGP or X.509, which could also put it out of wide usage.

John Curran: Microphones are open. Any other comments? I guess I'll ask a question, because I'm kind of steering the ship day-to-day, week-to-week. If and when there's a reliable and stable ARIN Online that has widespread adoption, is there any reason at that point still to consider e-mail templates? In other words, does anyone feel both methods need to be there even if ARIN Online is heavily being used?

Scott Leibrand: Scott Leibrand, Internap I guess at this point. I believe the earlier points from the remote participants, it's along the lines of what I was going after. If we've got a way for whatever is done on the online ticketing system to create an e-mail paper trail, then most of the -- that takes care of most of the problem, in my perspective. So I think it's important that we not go down the road that some online interactions make everything a hostage to the Web's internal systems and instead make sure that the people doing the submitting have a copy of everything that happens. Once that happens and we've got a good system, I think we might be at a position to retire it.

John Curran: But it's all in the cloud. It's all safe.

Scott Leibrand: Yeah, right.

John Curran: Center front.

Rob Seastrom: Rob Seastrom, Afilias and ARIN Advisory Council. In answer to John's question, how adopted is widely adopted and how long would you propose giving this? There's a lot of automated stuff out there that sends e-mail today. And I think we have a substantial outreach issue to deal with to let everybody know there's a countdown clock running if we plan to phase out e-mail templates.

John Curran: How long do you suggest from when the community says we're going to phase out e-mail templates? Because it prevents the database interactions, the cost, the downside. How long do you think it will take with an outreach campaign for everyone to get their systems generating e-mail off?

Rob Seastrom: I think that we should work from the assumption that they are going to be phased out from the information that we know from today. That's just a question of how long. And I think that the number that you should start with is a single-digit number of years and that the first number should not be 1 or 2.

John Curran: Okay. Any other feedback?

Owen DeLong: I'm Owen DeLong from Hurricane Electric and the ARIN Council. I'm not convinced that retiring e-mail templates is all that worthwhile. I think there are ways to make them just yet another way of getting input into the system and having it be processed through a consistent processing mechanism. And I think that that would be a better approach.

John Curran: You would propose that long-term the system have another interface which is e-mail templates which is designed to use the new system but be compatible with the old templates?

Owen DeLong: That's correct. Because, for example, there's a lot of places where I've worked as a consultant and they generate some ARIN templates periodically. I don't know what their volume is today; some of these I haven't been by in five or six years. But I know that they're still using the automated system that I wrote for them that pulls stuff out of the database they maintain and goes, oh, this needs to be an update to ARIN, and sends off the appropriate ARIN updates and SWIPs and whatnot. And it all just happens and they don't even actually realize necessarily among the people that are still there that that's going on.

John Curran: Exciting. Thank you. We have someone down at the end of the table. Scott.

Scott Bradner: Mr. Microphone man, there we go. Two things. One, I agree with what was just said, but also what was said a number of people said earlier: Watch the numbers. If people are not using the e-mail system, it's probably not worth keeping. If they are, then giving an arbitrary deadline to move people off is -- it annoys people. And why -- we don't need to be in the business of annoying people.

John Curran: Okay. Center front mic.

David Farmer: David Farmer, University of Minnesota, ARIN AC. There was a suggestion from the cyberspace that we maybe consider deprecating the insecure templates. I think that should be considered in this whole thing. Raising the security of the system is an important goal. And if that's the thump on the head some people need to move them along, that might be worth thumping.

John Curran: Okay. Sort of a how-to guide for dummies on how to hijack address space using e-mail validation. Might be really useful in the next few years.

Okay, back microphone.

Aaron Hughes: Aaron Hughes again. I would say that one quite useful way to promote the Web service would be to add to the auto responders on the top of the e-mail "did you know you can do this over the Web" along with URL information. Because many of the actual users of those functions don't read ARIN Announce. They're just doing their day-to-day job. And I don't think that Announce is going to reach out to the necessarily correct people to get them to make a change. And once something like that is done, then go back and look at the logs and figure out how much is actually being used.

John Curran: Okay. Center front microphone.

Rob Seastrom: Rob Seastrom again. I agree with Aaron's statement just now. I just wanted to underline that that's not going to get to everybody, including the folks that Owen was talking about, for sending stuff in an automated fashion. Notwithstanding that, the top of the auto responder sounds to me like a splendid place to underline that you are using a deprecated interface that's subject to going away in the future.

John Curran: If not deprecated, at least telling people there's an alternative today.

Stan Barber: Stan Barber. I'm with The Planet. One thing I don't remember from the previous discussion you gave at the last meeting was whether there was going to be programmatic interfaces to this, so XML, something like that. Could you talk about that a minute?

Andrew Newton: You're talking about the SWIP templates, I assume.

Stan Barber: No, I'm talking about ORGs and POCs just like you're talking about now.

Andrew Newton: To my knowledge there's nothing on our roadmap that says we're going to do that. It doesn't mean we won't. Essentially we have to be asked to do it, I guess. We did talk -- so at the last meeting we did talk about SWIP templates specifically, and I don't think we can get away with not offering some sort of automated way. And in fact we have to look seriously at how -- if we weren't going to do it via e-mail templates, how we would transition all that. We do have some ideas, hopefully things that are compatible, and we might be able to extend those to regular forms of doing things with POCs and ORGs, but, again, we have to take a look at it.

Stan Barber: Well, I can tell you as a big hoster, and some people think we are, being able to create ORGs and POCs for our customers when we're delegating space for them using the same infrastructure that we would SWIP stuff to them would be really good. Thank you.

John Curran: Okay. Far right microphone.

Kelly Genessy: Kelly Genessy, Utah Education Network. Have you taken into consideration server maintenance, patching, downtime, full redundancy-type issue? Because right now I can send an e-mail pretty much at 2:00 a.m. on a Sunday morning and I know it's eventually going to get there. But if I try to log into a Web page that was under maintenance, I might not be able to make my change.

Andrew Newton: That's true. You do have the store and forward mechanism of e-mail working for you there. But that's counterbalanced with the fact that you can't, if you want, from a -- from an end-user's perspective that's used to dealing with websites, they can't really use it as an interactive, more intuitive way of getting at the data. I understand what you're saying. Yes, we will have downtime. Even the templates go down. You just don't notice it.

John Curran: Okay. Microphones remain open. Center front.

Kevin Oberman: Kevin Oberman, ESnet. Credit for bringing this up to Jason who happened to mention it a moment ago, but does the ARIN Web interface meet ADA compliance?

Andy Newton: ADAD?

Kevin Oberman: Americans With Disabilities Act.

John Curran: Section 508 and similar?

Andrew Newton: Section 508 and WCAG. Yes. We actually go through great pains. We have an external testing source that helps us out with that.

John Curran: I don't know if your e-mail client does for the templates, though.

Okay. It's now time for our afternoon break, and everyone take an opportunity to take a break. We actually have an info center out there. You can view the ARIN multimedia presentations, get information, see some of the ARIN staff. It's all in the grand foyer. The registration desk and election help desks are out there. The billing help desk is available throughout the meeting by appointment. And, again, if you're voting in the NRO -- for the NRO Numbers Council, that election closes at 5:00 p.m.

We had a question earlier about if I'm voting and I have an e-mail address and multiple organizations for which I am the DMR, can I actually get it all in one login. And the answer is yes. If you're actually using the same e-mail address and it is the same e-mail address for multiple organizations, it will actually show up that way.

Yes. Aaron.

Aaron Hughes: I have to beg to differ. When you sign up as a DMR, it requires that you use an e-mail address at the domain --

John Curran: Correct.

Aaron Hughes: So for each organization you will have a different DMR e-mail address.

John Curran: For some people their multiple DMRs are multiple within an organization. So for them it works. For those people who consult among many firms, almost certainly not. Yes.

If there's no one else, we are now on break for 30 minutes. I look forward to seeing everybody back here at 3:30. Thank you.

(Recess taken at 3:00 p.m.)

Lame Testing

John Curran: We're ahead of schedule. We're going to try to stay on schedule, and so we'll invite Mark Kosters up who will give an update on Lame testing and next steps. Mark.

Mark Kosters: Okay. So one of the things that I wanted to talk about is obviously our LAME testing that ARIN has been doing for a period of time and talk about some of the issues that have come up with it as well as the proposed solution. But before I begin, how many of you guys understand about what DNS is?

(Show of hands.)

All right. That's good. How many people understand what authoritative answer is? Can I ask one of you guys randomly which bit that is in the response packet? It's unfair. Okay. So what I'm going to do is kind of go through this in terms of what the process is now, give you kind of a refresher, go from the process to what ARIN had been testing, the problems that we've seen, and a proposed solution.

So if you don't understand anything about DNS, this is a great time to really delve your head into the laptop, because you're just not going to get it. So -- okay. So let's first start out with what the LAME delegation process is. The first part is we test these things daily. If we detect that a delegation is lame, we continually test it for 30 days. If it was good within that 30-day process, it's off the queue until the next time it's detected as lame. And this has happened quite a bit. But there's definitely cases where LAME delegations continue to be lame. If after the 30 days of testing occurs there's -- the POCs are notified that there's a problem. Okay. Go ahead.

John Curran: One statement you need to make: The definition of lame for servers, for DNS servers, is when you query them, whether they're not there, they're there and they give a no record, or they're there and they give a record without the AA bit.

Mark Kosters: That's on the next slide. So if we're finished with this -- I guess you can read this. We'll go to the next page and actually go through that. So how is lame defined. Thank you very much, John.

If there's no A record for the name server, there is no way you can get there, right, to query for the delegation information. If the name server is nonresponsive, it's not listening on a BIND port. And also, if it is responsive, if it's nonauthoritative for the reverse zone -- basically the A-bit, the authoritative bit, is not set or in many cases the SOA record for the reverse zone, whether or not it's there, it needs to be there.

So when is a name server stripped? That's basically when we say it's lame; it's gone through the 60-day notification process, we go ahead and take it off the delegation. So we go ahead and take care of it and take it off and you can just follow the logic there. So what Leslie did is we've been encountering some issues with this. We're not alone. RIPE has also had some issues with their LAME delegation detection process. And she provided the following text for the Policy Experience Report at the LA meeting at ARIN XXII. We don't really have a clear way of detecting LAME delegation, because people say, well, I know you say it's lame but it's really not because you're getting answers.

And you know what? They're right. There's potential legal liability because these things are working for customers. When we say you're lame, we send the notices. You ignore them because you think they're working, and we go ahead and remove them. That's not so good because then it's not working. When you do that, there's -- operationally there's significant hours spent on both sides taking a look at, okay, what happened here and how can we fix it. Because I'm sure it's kind of surprising to your DNS admins out there, hey, what's going on here? Why isn't this working all of a sudden? Why are my customers complaining? And you're looking at -- first at your own servers, and maybe you'll look at ARIN servers next to see if your delegations are correct. So there's definitely some time there, and of course the phone calls and everything else that goes on with it.

So what we've seen out of this is when we turn off these working delegations, they're kind of sort of not set up correctly. For example, one of the things that people do is they'll set up a delegation on a /16 for the /19 that they do have. And I totally understand it, because that makes it a lot easier. And there's also incorrectly configured DNS servers that people have set up that maybe they thought were set up correctly but were not.

And these things just abound all over the place. And this is not just a problem within the reverse zone, but this is also true of the forward zones as well. There's just a lot of name pollution out there. This all ends up being quite a bit of customer support.

So John has challenged me. And John has challenged me to come up with a better way of defining lame, because if we have a better sort of heuristic in defining lame, then maybe we can actually do some good testing that doesn't incur liability or turning off people's working delegations and so on and so forth. So I went around and asked a lot of people what would you define lame as. And some of the people came back with a traditional version, which we know that doesn't work. Others have said, well, let's think out of the box, because we really can't define lame, but we kind of know what it looks like. So let's go ahead and figure out a better way of doing it.

So there's really three steps. First one is issuing what's called a SOA query for the delegation. If that name server responds to that SOA record, it's good. Even if the authoritative bit is not set on the response, you know you're going to get an answer there. And this is one of the things that we've seen. If that fails, then what you do is you fill out a dotted quad for the delegation and issue a PTR for a query. And you may get a NX domain, RCODE=3 response, saying, hey, this doesn't exist, but the authoritative bit will be set if it's authoritative for that zone. That's another good test. And this came via Paul Vixie, by the way. So thank him if you see him. And if that one doesn't work, then just issue three random PTR queries someplace within that delegation and see if you get a hit. So one time it may be -- well, 3.1.5.192.in-addr.arpa, and another time it might be 5 and another one it might be 254. But, anyways, we'll try what it takes to actually go ahead and figure out if we can get some sort of response. Again, the authoritative bit does not have to be set, but we will at that case have made a fairly good approximation whether or not there's some semblance of someone answering for a PTR query within that block. So -- does that make sense? Is this something that the community says, hey, this is a reasonable way of going forward with the lame testing; we would like you to go implement this? Or should we continue doing what we're doing today?

So the mics are open.

John Curran: Microphones are open. Center front.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC.

Comments on two different directions. One is because this is hard to define, I believe it would be useful for ARIN, whether that's staff or the community or whatever, I'm not sure, but for ARIN to actually define what they expect of people who run name servers in the reverse zone to do. Whether it's you have to be up 24/7, 365 and if you ever miss a packet we kick you to the curb. Or, you know, whatever requirement we want. It would be much easier to tell these people that we removed you because you didn't pass these tests if we told them six months earlier here is the test we are going to run on you and expect you to pass. So I think that's actually one of the big things that has been an omission.

I think the other problem that you're attempting to solve with this definition is people seem to throw into lame what I would consider two problems. Lame to me means that the down-the-tree server responded with a response that didn't make sense from the up-the-tree view. So up the tree you said you're authoritative, and then you said you're not. But it's predicated on a response. Something to say that they don't agree. The problem of servers that are gone, don't respond ever, have been taken down, whatever, servers that are literally missing, is a completely different problem than the lame delegation problem where the two halves don't agree.

I think ARIN needs to address both of those problems. But because servers that aren't there, may not be there, for instance, because ARIN bought half a table from their ISP or any other number of other weird reasons, I think it's a very different problem than the lame problem where the two servers don't agree on what their role is.

John Curran: Center rear microphone.

Tom Daly: Mark, a couple points on this. I was good up until Step No. 3. Step No. 3 concerns me dearly in spite of the relaxed transfer policy, because now somebody could continue to respond from my zone for what is going to become my space during a transfer. And there's no way to necessarily detect that as the delegation changes. So that seems hazardous there. But as a totally separate point, whatever ARIN decides to do for testing, it would be convenient if you had a tool on your website that emulates what your back end is going to do for nightly testing, so that way I can perform a self-test via the ARIN website on my own stuff, that way I don't have to wait for your first notice that I did something wrong.

Mark Kosters: Good point. One of the things I'd -- I'd like to ask you a question. If you go through this transfer process, you've changed the NS set, correct? Right? So at that point when it goes top-down, it doesn't matter. Even if they're still answering authoritatively or semi-authoritatively for that zone, they could be doing that forever and you just don't care because all the people interested in that part of the tree will go to your name servers.

So I guess I'm not seeing what the issue is.

Tom Daly: I'm sorry, I didn't make that clear. If you go back a couple of slides where you're talking about somebody setting up a /16 as authoritative where they really only have a /19, I would like to see you testing for that.

So pick addresses inside and outside of the range that's delegated and make sure that's proper. So that way you don't have somebody artificially answering for a zone they should not be authoritative for.

Mark Kosters: So that's precisely the problem we're having. We're actually turning those people off, even though they're answering for PTR queries within the delegations they do have. And the only one that it's really affecting is those recursive resolvers there that are pointing to that server for anything within that /19. Otherwise they're going -- they're going elsewhere, right, because we only have the NS records for those /24s. So it's a very small set, correct?

Tom Daly: So during the delegation process, what is the TTL of a delegation from ARIN down to a space holder?

Mark Kosters: I'm not sure.

Tom Daly: Is it two days? And so if it's that long that could create operational issues especially for e-mail servers.

John Curran: Okay. Worth looking at.

Tom Daly: I don't know if this is a new corner case that you considered, Mark, but I just thought about it while you were doing your talk. What if we have an organization that considers some portion of their address blocks private and they don't allow you to query that server from the outside but it works perfectly well inside their own network and any testing you do on the outside is going to fail, but it works fine on the inside; so you've thought about that?

Mark Kosters: There are certain known entities that don't have any exposure for their delegations, even though they do work correctly. And we have a flag for that. I didn't bring that up because that does obviously -- it's not tested, so it works. So just in the cases where we're having the public Internet, the delegations are exposed to the Internet and the testing that goes on within those delegations, those are sort of the pain points we're trying to address here.

John Curran: Microphones remain open. If you have a view on whether we should maintain the current definition of lame, and that could generate a lot of potentially withdrawn delegations, or the new definition, please find the microphone. Center front.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. I'm curious looking forward a couple of days or years or whatever it's going to be, presumably the reverse zone will be DNSSEC signed at some point in the future. Have you given any thought to these checks also checking that the DSs and the parent match the sigs and the child and whether or not mismatches count as lame or not?

Mark Kosters: That's a really good question. One thing at a time. To be honest, I do like to solve this. That is a good point to bring up later on. Boy, that adds a lot of complexity -- on multiple fronts. And it's a useful sort of thing to do otherwise. Obviously the downstream's validation doesn't work in the DNSSEC world, so we need to work on that as well.

Leo Bicknell: Again, my concern -- back to my earlier comment -- would be it would be nice particularly here before the root zone is -- or before the root -- before the reverse zones are signed for ARIN to publish, if you give us DS keys, we expect them to validate, and if they don't for 30 days, we're just going to remove them and -- whatever the policy might be. Again, so you know before it happens.

Mark Kosters: Are you talking about the DS keys that we currently are putting within -- obviously their in-addr.arpa is not signed. So we have these trust anchors essentially out there. Are you talking about those?

Leo Bicknell: No. I'm talking about in the future where, for instance, if I have a /16, I'm going to have to give ARIN DS keys to put at the delegation point saying that my signatures on down are valid. Just like you would in a forward DNS. And so one of the checks should be that the key that ARIN has or one of the keys, because there could be multiple keys when they roll and you'll have many other issues, but one of the keys validates the signatures. And if none of the keys that are there validate, a validating resolver is going to refuse to show that to the end-user, it's not the same thing as lame.

But in terms of the broader concept of testing for things that work, it's something that is now broken. Probably the more common case is someone has given you keys and for whatever reason has decided to go back to non-DNSSEC, so they've removed all the keys and signatures from their downstream but you still have keys. That's a different area we've seen in the forward DNS that causes a whole bunch of other issues.

So, again, my concern is not so much that we hash out how you test that, but there's an opportunity where we can actually put the requirements in front of people before they even configure it on their machine. And that ought to greatly increase the chance that everyone agrees on what the definition is.

John Curran: I'm going to be closing the microphones. Center front. Last comment. Second to last comment.

David Farmer: David Farmer, University of Minnesota, ARIN AC. The changes you're proposing, I think, are reasonable. I need to think about them a little longer than five or ten minutes. I do have a couple of suggestions on the process we follow for this. This might make -- once we figure this out, maybe we work with our RIR brethren and come up with a common mechanism here. This might make a great informational RFC.

Mark Kosters: If I could, one of the things I'd like to do, if we get some sort of consensus in the room that this is a good idea, I'd like to expose it to other RIR communities saying this is what ARIN is planning on doing, just so that you know, and keep on going down that path. But, again, I wanted to get -- John and I wanted to get some good feedback on how this is going to work within the -- if the ARIN community liked this idea and going forward with it before we exposed it elsewhere.

David Farmer: And then I was going to say not everybody's day job here is dealing with the DNS, so maybe getting the -- while we deal with the numbers on the router side, and that's what -- and there are people in the room that their day job is DNS, it might be better to get a broader sense of some people that have DNS as their day job.

Mark Kosters: I mentioned a little bit of this before. Obviously I've come from the DNS world, and I did consult a number of luminaries within the DNS world to actually come up with this algorithm. So this is not unknown to them.

John Curran: Okay. And our final comment, Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I'm not really a big fan of redefining lame. I think lame is pretty well-defined. But I do like the idea of applying these criteria to what we do and don't do to remove from the zone file. I would like to see us still informing the resource holders that their delegation is not being correctly handled, even if they think it's working, and be that as it may. I think DNSSEC will actually, when we get that far, help with this somewhat because once people start signing their resources, they're going to have to have their ducks a little more in a row anyway. And the other question is: Are you doing this for ip6.arpa as well?

Mark Kosters: I think that's something to expand upon as well.

John Curran: Thank you, Mark.

(Applause.)

Draft Policy 2009-7: Open Access to IPv6

John Curran: Okay. We're now back on to the -- back on track and back on to the policy portion. The next policy we're going to discuss is Draft Policy 2009-7, which is Open Access to IPv6. And we're going to have Cathy Aronson come up.

Let me do the history. So the history, 2009-7. Original proposal was PP 90 and 29 of May this year. Draft Policy was the 31st of August. Similar topics are under discussion in APNIC, LACNIC and RIPE NCC. The AC shepherds are Cathy Aronson and Owen DeLong. It removes two parts of the ISP IPv6 initial allocation criteria: routing requirement to advertise the single aggregate allocation, and it also removes the requirement to be a known ISP in the ARIN region or have a plan to make 200 assignments in five years. Legal liability risk. You can read the full assessment available online. An extract includes the sentence: While encouraging small businesses or start-ups is important, I believe this policy will improperly encourage and permit fraud in the issuance of small blocks of IPv6 addresses. Staff comments or concerns. Effectively it leaves the only criteria left that you are an ISP with no qualification. And it means that an end-user would have to go through some fairly detailed justification to get an allocation of a -- to get an assignment of any size, but almost immediately you could say they're an ISP and get a justification straight through.

So it's a little bit of an equity question. Resource impact, minimal. That's a change in criteria, and it's actually removing criteria. So it actually makes things easier. That may not be a good thing. But it does make things easier. And that's it for the staff assessment.

Comments on the PPML. 166 posts by 35 people. That's quite a lot of discussion. 15 in favor. Six against. "ARIN should make it as easy and cheap as possible for anyone to get as much unique IPv6 address space as they might need." "There are real ISPs that are small that deserve the minimum allocation of IPv6 just as much as the 200-plusers." "I oppose the policy as written. 200 sites may be too many, but there should be a qualification of number of sites before such a large block is assigned. ""Adoption is slow because the demand isn't there. Saying anyone can get an IPv6 /32 block is not going to magically make the demand rise."

With that, I'll turn it over to Cathy to do the presentation and discussion.

Cathy Aronson: Hi. I don't know where the slides are, but I don't need them right away. So to reiterate a few things that I said a bunch of times at NANOG, for those of you who weren't there, this is a really old policy. The IPv6 policy was a globally coordinated policy among the regions, and it was written a very long time ago. And there was quite a bit of discussion about it at NANOG, and I went about writing a policy or starting to write a policy like the one that we had for the African region before AFRINIC was formed for the Caribbean, and then Stacy and I got to talking and we decided that perhaps we should just make it easier for everybody instead of having a separate policy for the Caribbean. So this policy sort of evolved. These changes evolved out of that. And I don't know how to change this thing. What do I do? Okay. So it modifies the existing policy. Again, it's a really old policy.

Oh, and the other thing I should mention about the really old globally coordinated policy is almost immediately after the policy was passed, several regions changed it. So the 200-site requirement is actually -- I think we're pretty much the only of the three original regions to do this, that still has the 200-site requirement. So basically we would remove entirely "by advertising that connectivity through its single aggregate," which means -- I have a bunch of pros and cons on these things, and then you can yell at me. And then we would also remove the 200 end-site requirement. This is the rationale that was in the policy. I think -- let's see. Anyway, these things have been debated and debated and we just decided that we would put a proposal up here and see what happened.

So the pro list got a lot longer after I was at NANOG, because some of these things weren't actually ever proposed on the list. But, first of all, on some level it promotes IPv6 adoption. It facilitates that kind of innovation. The next three came directly from a panel that just happened at NANOG. Currently, because of the single aggregate requirement, you can't -- you're not supposed to. You sign as an ISP, you sign an agreement with ARIN that says I'll announce a single aggregate, but then you need to do traffic engineering and, guess what, you're going to advertise more than a single aggregate. The current policy doesn't allow, because of the single aggregate requirement, that you can advertise a more specific for anycast, and you can't really do anycast in a whole /32. And it doesn't allow for more specifics if somebody tries to hijack your /32. So those I got from the NANOG.

And the cons from the Mailing List are that it could promote routing table growth because we're no longer requiring that they announce a single aggregate. So does anybody want to say --

John Curran: Microphones are open.

Marla Azinger: Marla Azinger, Frontier Communications, ARIN Advisory Council. I support positively the part about taking the /32 out. It doesn't belong there. So that part I support. And I wish these had been done as separate proposals, because I just don't know if the 200 part should be taken out or not or if it just needs to be replaced with something else. Because on this cons list should also be that legal, highly advised that this wasn't good because it could encourage negative actions by other members in the community.So I'm just concerned about the 200 part. But the take out the /32, the single aggregation, I am all for.

John Curran: Further comments? Center rear mic.

Aaron Hughes: Aaron Hughes. I'm actually looking for clarification from legal on this proposal. I'm just wondering if the exact same text or some similar intent was provided for IPv4 space. Because, to me, it seems like this is trying to protect ARIN resources from people lying, but wouldn't you do the exact same thing for IPv4 as the policy stands today?

John Curran: So we'll get counsel to comment on the open access to IPv6 policy. I see Steve. His comment and the assessment was: Not fatally flawed but not a good idea. Go ahead, Steve.

Steve Ryan: He's much bigger than me, so I figured I'd come over to this microphone.

(Laughter.)

You know, I understand the goals that we're trying to achieve, but if we just give everything to everybody, I don't know that we're meeting a stewardship obligation.

And so I raised from the legal standpoint -- you know, I could think of all sorts of unsavory people that could get their allocation of IPv6 with the policy change this way.

I think -- I'm not going to sit and lay down in the road on this one, but I think you guys need to think through the implications of giving it to everybody, which is the way I read this policy, and maybe incorrectly. But that was my reaction to it.

You know, I understand the goals that we're trying to achieve, but if we just give everything to everybody, I don't know that we're meeting a stewardship obligation. And so I raised from the legal standpoint -- you know, I could think of all sorts of unsavory people that could get their allocation of IPv6 with the policy change this way. I think -- I'm not going to sit and lay down in the road on this one, but I think you guys need to think through the implications of giving it to everybody, which is the way I read this policy, and maybe incorrectly. But that was my reaction to it.

Cathy Aronson: That's why I wrote it.

Aaron Hughes: That being said, my actual statement is, first, I fully support this policy. And, second, I want to make a comment about my real experience, which is that I have recently as a new organization had to acquire IPv4 space before I could get v6, and I was building a v6-only network. I had to come up with justification for v4, which I did, re-engineered my plans to incorporate v4, which I didn't need, and then became a known entity and acquired a /32. So I'm actually now lying to acquire IPv4 space in order to obtain IPv6 as the policy stands today. I support this.

John Curran: Okay. Interesting comment. Front mic.

Dani Roisman: Hello. Dani Roisman with Peak Web. I also wanted to offer my support for the open access. The way I was reading through the policy, the current policies definitely leave a portion of our population stranded, because as LIRs, if you are handing your address space to other folks, if you are a smaller LIR, you cannot ask for a direct assignment as an end-user, because the very first criteria is you must not be an LIR. I think just to -- one thing that also struck home was that there probably needs to be another subsequent proposal that removes the requirement for IPv4. I think I understand why it was in there, but I think somebody should be working on a subsequent proposal for that as well.

Cathy Aronson: But, wait, this removes the known ISP requirement. So it removes the requirement for IPv4.

Dani Roisman: Okay. Great. I didn't know it was part of the ISP.

Cathy Aronson: That's what Aaron was talking about. I have a question for Aaron: Would you be happy with this if it had "known ISP" scratched but still 200 sites?

Aaron Hughes: Absolutely.

Cathy Aronson: But it does remove that requirement.

Dani Roisman: The 200 site -- that's what I was saying. What ends up happening with 200 sites and what was discussed in one of the pros was the smaller LIRs that can't qualify for 200 sites also can't qualify for end-user assignment and they end up in a lurch where they legally can't get any IPv6 unless they choose to lie to ARIN.

John Curran: Far left microphone.

Dan Alexander: Dan Alexander, Comcast and ARIN AC. Cathy, you mentioned earlier that these requirements were removed in some of the other RIR policies, making them a little more liberal. I was just curious -- it might help the room if we all understood -- do the other RIRs have other criteria that they use in place of this? Or are their policies as liberal as this would be if this were to pass as written?

Cathy Aronson: Do other registries want to comment on that? That would be great. That way I don't get it wrong.

Ingrid Wijte: Ingrid, RIPE NCC. We got rid of the 200 end sites quite a while ago really, and about three weeks ago, the routing requirement is gone -- and now the criteria's basically being an LIR and have a plan to make assignments.

John Curran: Okay.

Cathy Aronson: Somebody from APNIC that could comment? I know that they were proposing to add their routing aggregate requirement when I was at the meeting.

John Curran: Let's get someone of authority to speak on this.

Paul Wilson: There was a proposal at the last meeting to strengthen the aggregation requirements by combining the subsequent allocations needed into the single announcement as well. That was going quite the other way, but that proposal didn't succeed.

Cathy Aronson: What about the end-site requirement?

Paul Wilson: We've still got it.

John Curran: Anyone from AFRINIC or LACNIC who would like to speak about their practice in this area? Go ahead.

Ricardo Patara: Ricardo from LACNIC. Our policy also removed the 200 thing. We still have something about routing. We request the ISPs to announce the prefix after one year beyond allocation, and we also request them to provide service using the IPv6 after two years. I understand it's not easy to check, but it's something that is in the policy.

John Curran: Got it. Okay. Center front microphone.

Kevin Oberman: Kevin Oberman, ESnet. I'm split on this proposal. I like half of it; I don't like the other half. I'm really troubled by the fact that these two changes are both in the same proposal. The first change allowing the aggregation doesn't appear to have anything to do with open access to IPv6. It doesn't seem to fit the topic, and I'm sort of baffled why it's here. Though that's the half I favor; I want that one very badly. The second one, I like something in this direction. I like the feel of it. However, it's just entirely too liberal to do all at once, I think.

It may be where we end up. But I think we should make it in slightly smaller steps until we see what the ramifications are going to be. Just suddenly opening the door and saying basically if you can breathe and send us a message, you can get some IPv6 address space, which is pretty much what it will say at that point, just strikes me as perhaps a bit too liberal.

John Curran: Okay. Microphones remain open. Center rear.

John Schnizlein: John Schnizlein. It strikes me that the panel on IPv6 in the NANOG session made very clear that there's a problem with the current policy. So I think everybody in the room agrees with that. The idea that you have to consume some v4, some scarce IPv4 address space in order to get IPv6 unscarce address space is clearly wrong. So that has to get fixed. I am concerned that the removal of the "there can be only one" statement with no limitation at all abrogates the community responsibility to shepherd what is now the only scarce resource, which is slots in the default-free zone.

Cathy Aronson: I'd actually like to comment on that. One of the reasons why this policy -- any number of reasons why it came to be, but one of them was also that we have started a process by which ARIN doesn't dictate routing policy to Internet service providers. So we remove the aggregate requirement because we feel that we shouldn't dictate routing policy to Internet service providers.

John Schnizlein: I understand, and this conversation at the open mic last night provoked John to go to the microphone and explain what the requirement on ARIN is. I think that there's a big difference between there can be only one and there are no constraints. It may be that somewhere in the middle, some policy that accommodates the identified-this-week problems with the existing policy but doesn't throw the gate wide open might be better than just leaving the problem completely unconstrained.

Let's imagine that we don't hit the wall and run out of -- and have the lack of free IPv4 addresses stop growth in the Internet. The way that happens is we get a lot of growth very fast in IPv6 routes. And if you don't constrain that, the fears of the gradual growth that people have worried about, rightly, for some time now, are going to be nothing compared to the rate at which the routers start falling over.

John Curran: Front center mic.

Jason Schiller: Jason Schiller, Verizon, UUNET, NRO NC. I have a clarification for ARIN staff. Based on the comments I've heard from Aaron and John, I'm confused about 6.5.1.1D, which says: Be an existing known ISP in the ARIN region or have a plan for making at least 200 end site assignments to other organizations within five years.My question for ARIN staff is: I am starting a new business. I have no plans to do IPv4. I don't want any IPv4 addresses but already have more than 200 customers lined up for IPv6 transit. Would I be denied a /32 PA?

John Curran: I'll look for Leslie to answer that.

Leslie Nobile: No, you'd be approved because you have the 200 customers. It's the either / or. So, yes, of course, you'd be approved. Because some people don't have 200 customers or a plan for 200 customers.

Cathy Aronson: Well, let Aaron respond to that, then, because --

Aaron Hughes: I have to say even though it's written that way, the way it's executed today is opposite of that.

John Curran: Qualifying? Elaborate.

Aaron Hughes: Request for IPv6 /32 with the intent to hand out all these 200 assignments over five years did not qualify me for a /32 in that particular case for that particular company. Even with this policy in place as it stands today.

John Curran: With a plan that showed --

Cathy Aronson: What it says. 200 sites.

John Curran: -- 200 sites within five years?

Aaron Hughes: Yes. I agree that the text says one thing; I'm just saying in practice I have experienced something different.

Leslie Nobile: And that is probably true. So anyone can say they have a plan, but then you've got to show us something, right? So what is the plan, where are your customers coming from, what are your services and how are you going to do this, et cetera, et cetera. Sometimes it's just we just don't get enough information to know, especially with brand-new start-ups. We have no record whatsoever.

John Curran: Presently the sentence requires us to make sure the plan looks to be valid; that it's a plan that isn't created entirely for the purpose of obtaining address space, but indeed is a valid plan that the organization intends to follow once they actually get the space. Any other questions, Jason?

Jason Schiller: I'm confused whether we have a policy problem or an implementation problem.

John Curran: If right now you apply under that, you'll be asked for the plan for your business that shows that you're going to make at least 200 end site allocations. And as long as that looks like the plan you're actually going to follow and it's not a plan you create entirely for the purpose of obtaining address space, you'll be given space.

Jason Schiller: In that case I'm opposed to this policy because it sounds to me like the bar is sufficiently low. If we want to lower the bar to, say, 100 end sites, I might be okay with that as well. But without any requirement there, it seems to me that the bar is so low that my home network could qualify under this policy, and I've said in the past that I was opposed to modifications where my house would qualify as an ISP. So I think the bar is too low.

John Curran: Okay. Acknowledged. Center rear microphone.

Igor Gashinsky: Igor with Yahoo!. I'm completely for part one of this. I feel it's a hindrance to IPv6 adoption, speaking for myself and my organization. If you want to see content on v6, please remove this. Because the only way you're going to see content on IPv6 is by people ignoring it. That's just a fact for various reasons that we've stated in the NANOG panel. Furthermore, somebody before me was saying that it's ARIN's job to be stewards and make sure that slots in the routing table don't remain filled. Please leave operating, operational problems to operators. Please do not make a policy to tell me how to run my routers. I and the people who connect with me, we will take care of that. ARIN is not responsible for routing; has repeatedly said so. Please let people who run the routers run the routing policy. That is our jobs.

As far as part two, I really wish this policy was split in half so part one could just be passed. And I think part two does require some more discussion, and I'm going to have a question right now: Is the fee schedule for an ISP different than the fee schedule for an end site?

John Curran: Fee schedules for -- well, first, for IPv6 or in general or...

Igor Gashinsky: IPv6 specifically.

John Curran: We've waived IPv6 fees for organizations. That fee waiver is actually due to be extended or expire December 30th. But at present unless you're applying only for IPv6 space, you have no IPv4 resources, you are not paying the IPv6 fee schedule.

Igor Gashinsky: So assuming the waiver expires, lapses, whatnot, and if you're applying only for IPv6 --

John Curran: Then the end-user policy versus the ISP policy is the same as the practice in v4. End-users receive an assignment and pay a one-time fee and then pay a nominal maintenance, whereas ISPs receive an allocation with the expectation they'll come back and make additional allocations and they pay the same amount each year based on the size of total allocated size.

Igor Gashinsky: Couldn't we use that as the criteria; essentially financially disencourage people from being ISPs if they don't need it?

John Curran: At present there is that disincentive if you're paying the fee schedule, yes.

Igor Gashinsky: So in that case, I am for part two given that there is a financial disincentive to -- for Jason's house to be an ISP.

Stacy Hughes: Oh, okay. Joe says: We need to have an end site plan. There needs to be a barrier to entry with end sites.

John Curran: And, Scott, go ahead.

Scott Leibrand: I'm actually speaking for Chris Morrow who is kind enough not to give us Barry White again, but he's not a remote participant so he's not in the remote room. Chris says that single aggregate is bad. Having that in the policy, removing that would be good. He doesn't think that dropping the 200 end site requirement would be a good policy decision.

John Curran: And center front.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. I'll keep it to the first half. We should drop the single aggregate. Doesn't reflect reality and the operators are better poised to react to changes necessary and whatever limits they need to impose over time as router capabilities expand or contract or reach limits or whatever else. So that is simply in the wrong place.

Regarding the second half of this proposal, I agree, having heard situations like Aaron's and others, that the current policy is deeply flawed, particularly in the case where you're trying to build an IPv6-only network.So from that sense I think we're overdue in setting some reasonable criteria of how to build an IPv6-only network.

I think removing all the criteria is a huge problem. And the thing I wanted to point out that I think is different than some other people have is the amount of interest right now in IPv6 is very low. The likelihood someone would start an IPv6-only business today is not great. However, in a very short period of time there will be new drivers for that, like the exhaustion of IPv4 space. And you can make your own assumptions as to what the transition curve from IPv4 to IPv6 is and all that.

I think consensus is it ranges somewhere from steep to vertical. This transition will happen very, very quickly. And were we to remove all the requirements, it is quite likely hundreds or thousands or even tens of thousands of ISPs might try to get IPv6 space under this policy in a month or two, and the policy process can't react that quickly. If this is the wrong policy, we will make a gigantic mess before we can fix it through the normal policy process, leaving perhaps the only alternative for the Board to take emergency action, which is not something that I relish either. I agree completely with the problem of people not being able to qualify with real networks and real plans is a problem we need to address. I do not think removing all the requirements is a rational way to do it. So I don't support the second half of this at all.

I think consensus is it ranges somewhere from steep to vertical. This transition will happen very, very quickly. And were we to remove all the requirements, it is quite likely hundreds or thousands or even tens of thousands of ISPs might try to get IPv6 space under this policy in a month or two, and the policy process can't react that quickly. If this is the wrong policy, we will make a gigantic mess before we can fix it through the normal policy process, leaving perhaps the only alternative for the Board to take emergency action, which is not something that I relish either. I agree completely that the problem of people not being able to qualify with real networks and real plans is a problem we need to address. I do not think removing all the requirements is a rational way to do it. So I don't support the second half of this at all.

John Curran: Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. So I think that the 200 end site requirement is a little too steep. I think that probably some requirement is still somewhat worthwhile. It might be good input to the AC if we can get kind of a range sense from the community when you do your show of hands things, John. Maybe you can ask it. 25, 50, 100, something like that. I don't know what the boundaries should be.

John Curran: Thank you, Owen.

Owen DeLong: No problem. But otherwise I think it's good policy. I think it's pretty noncontroversial that we need to remove the single aggregate provision and I think there's definitely support for moving the boundary at least some.

John Curran: Okay. Center rear mic.

Tom Daly: Tom Daly from Dynamic Network Services. So on part one removing the /32 requirement, just to re-echo everybody, it needs to go away. It's made it practically impossible to do IPv6 anycast in most cases and follow the rules. It encourages in some cases the use of a /32 for anycast and anycast only, and then the island networks that are contributing to the anycast cloud to start using PA space, which is just consuming more resources in the IPv6 domain. We heard about rogue hijacking. We heard about traffic engineering. We've heard about all these things. It highly needs to be removed from the policy.

Going on to the second half, in IPv4 we have other things that we use to determine whether or not someone should receive an allocation or assignment. We talk about whether or not they're multihomed. This could be added here. The other thing is we're talking about whether or not they have IPv4 space already. And the requirement today is that they have IPv4 space or they get IPv4 space. There's no reason that we couldn't tie the IPv6 policy to the same boundaries as the IPv4 space but actually not have to get the IPv4 space. So you have to qualify for the IPv4 allocation but you don't actually have to take it as a starting point.

John Curran: Interesting. Center front microphone.

Kevin Oberman: Kevin Oberman, ESnet. In response to Tom real quickly, because I was asked to respond, the current policy, as was clearly stated a minute ago, does not require that you have IPv4 space before you can get IPv6. So I don't think that's an issue. I'm going to go back to the first half and respond to John's concerns about stewardship in terms of the forwarding tables.

Once again, I still don't see how this is stewardship of anything that ARIN controls. If I've got SEWP II routers in my network today, which of course I've never had, let alone recently, I would find 64k routes excessive. So I think ARIN should go out there and make sure we get it running. That's not an ARIN issue. There will be hardware that does bigger routing, pulls the bigger forwarding tables in the future. And if I'm a network provider and I set the policies to what routes I accept for my peers, I'm not going to accept huge numbers of prefixes from peers because in the aggregate for 2000 home users to have their own /32s, that's -- their own 33s, rather. That sort of thing is just not going to happen because I've got to make my network run. That's the economics of it. And the economics will control it without ARIN's intervention whatsoever.

I will point out there's one large provider to date that will not accept anything longer than a /32 even though ARIN hands out much longer prefixes as a routine matter. I think that policy is probably ill advised, but it's not my policy; it's theirs. If they want to make it, that's their business. And it certainly keeps their network running. Whether it's running profitably, that's their own problem.

John Curran: Center rear microphone.

Igor Gashinsky: Igor with Yahoo! again. Given that a lot of people are all for part one and there clearly needs to be more thought, discussion, whatnot, put into part two, a procedural question of can we split it in two?

Cathy Aronson: The AC will be taking that under advisement.

John Curran: During the polling it's possible to poll separately in some manner if we need to give some advice to the AC.

Cathy Aronson: We can do that.

John Curran: It would be nice for people who believe that the current routing requirement in part one, if you feel strongly that that needs to stay in, and this policy shouldn't pass because that routing requirement is very important, you should find a microphone right now because we haven't heard from you.

Cathy Aronson: I think the other thing, too, is if you feel any -- one way or the other about perhaps more like what LACNIC does, that you have to announce it within a year and you have to do delegations within a certain amount of time instead of the 200 end site thing, I'd like to hear that, too.

John Curran: Center front microphone.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I support the first part of the policy. I will echo the discomfort with no criteria or almost no criteria. The one comment I wanted to make is there was some staff comments about this might create some inequities between providers and end-users. I will assure you that proposals to work on the end-user portion of the IPv6 assignments will be coming. It was a piece of work on the AC's list. We felt there was going to be a lot more policies than actually happened here. So we sort of backed off a little bit on that. But that will come. I personally plan to work on it. So if you have ideas along those routes, please talk to me the next day or two or send e-mail. And then while I agree that the operators are more than capable of setting and defending their own policies for routing, ARIN does have a responsibility to create the hooks for the providers to hang their policies on. So I could take the outcry that ARIN shouldn't set routing policy to mean that we shouldn't set aside groupings of addresses for critical services or other things like that, but then you wouldn't be able to set your policies based on that situation. So I'll leave it at that.

John Curran: I'm going to be closing the microphones very shortly. If you want to speak about this policy, please find a microphone. Okay. Center rear.

Chris Grundemann: Chris Grundemann. I would support splitting the policy into two and I support the first half of the policy. If ARIN wants to preserve routing table slots, I think the best thing they can do is start allocating IPv6 sparsely.

As far as the second half, I have a really hard time believing that 200 users in five years is a major hurdle for any starting ISP. I cut my teeth at a wireless ISP that operated just inside of Colorado in rural areas, and within five years we had a couple thousand customers. This was a small enough ISP that I was the entire network staff. We operated with four employees for well over a year, with 1200 customers. If you don't have a business plan or any kind of a plan to obtain 200 customers in over five years, I'm not sure you're an ISP. So I think that part needs more work at least.

Kevin Loch: Kevin Loch from Carpathia Hosting. I support this policy. I -- the first part, very strongly, like many have expressed. The second part I do have some of the same heartburn about worrying if there is essentially no limit other than electing to call yourself an LIR, that might result in what we might call frivolous applications. So how do we figure out that people are making a good faith effort to actually use this? I believe the key, then, if we did pass this as written would be the economic hurdles that have to be met. The fee schedule, when looking at the ARIN fee page, and it looks like a /32 would be $2,250 a year under the ISP plan, if there were no waivers. It looks like there's currently a 75 percent waiver in 2009. So it would be $500. Even today it should be $500 for an IPv6-only ISP. Is that right?

John Curran: Correct.

Kevin Loch: In addition, I don't believe you can get any ARIN address resources unless you have some sort of legal entity like an LLC or corporation. And there's obviously some legwork and financial and legal effort that needs to be conducted there. It's not great but it is something that might disincentivise a casual basement ISP from --

John Curran: I actually -- I will check, but I don't think there's a requirement to be a separately legally incorporated entity. I believe an individual can apply. Let me check with Leslie. Leslie, do we need an LLC?

Leslie Nobile: You need to be something other than an individual. The policies say that an organization --

John Curran: Organization. Got it.

Leslie Nobile: You have to have some established business.

John Curran: An organization is an organization. Thanks, Leslie. That's good. I'm reassured. Okay. I'm closing the microphones. If you're not in a queue, please don't join the queue. The same for remote attendants. Center front, go ahead.

Kevin Oberman: Kevin Oberman, ESnet. I would point out that in many cases a family is an organization. That meets the requirements of the policy. So I think I'm going to apply for a /32 if this passes on behalf of my family. As far as the first half is concerned, I want to respond. In seriousness, I want to respond to Dave. There's a difference between stewarding the address space to make the implementation of rational policies practical and enforcing policies. When you don't allow deaggregation, you're enforcing policies. When you assign address space from multiple areas for different purposes to allow us as network operators to implement policies to perhaps make critical infrastructure reachable, that's not forcing us to do anything; that is providing us with the capability of doing something, and I think that is absolutely within the realm of what ARIN should be doing.

John Curran: Okay. Center rear microphone.

Mike Dewaele: Mike Dewaele, Caretech Solutions. I just wanted to come up as one of the minnows in the shark tank here. In our business, our business model is slightly different than a standard ISP. Our business supports mainly medical facilities across the country. And our suballocations to our customers are in the range generally, if we're hosting equipment for them, of /27s and /28s. So if I am considered as a known ISP right now, we do do some direct ISP for some facilities, that's fine. But if you were to ask me right now to come up with a business plan based on our business model for 200 end sites, there's no way I could meet that criteria. So I would, as Cathy asked before, support a plan that is more along the lines of the LACNIC where there are time-based criterion to be met.

John Curran: Final comment. Center front.

Jason Schiller: Jason Schiller, UUNET and NRO NC. It occurred to me that maybe some people can't qualify under a justification for 200 end sites in five years and that they're using the known ISP clause as an easy out to justify space. So if we're talking about dividing this policy, potentially we could divide it into the three constituent parts: The advertising a single aggregate would be one part; the known ISP would be a second part; and the 200 end site in five years would be a third part. So I just wanted to offer that up.

John Curran: You're saying that some people might support the policy if it was some combination of those three?

Jason Schiller: Or just maybe separately. Striking one portion of the text but not another portion.

John Curran: You yourself support the policy as is?

John Schiller: As is, no, I don't support the policy.

John Curran: Which portions do you need struck to support the policy?

Jason Schiller: I would support striking "known ISP."

John Curran: Then you could support the policy?

Jason Schiller: If the policy was to strike "known ISP" and nothing else, I would support it.

Cathy Aronson: You don't care about the aggregate thing?

Jason Schiller: I'm saying if the policy read -- strike -- keep the existing policy but strike the text that says "known ISP" in the ARIN region, I could get behind this.

Cathy Aronson: The existing draft policy?

Jason Schiller: No, the existing NRPM policy.

John Curran: Which means you'd like to maintain the requirement to announce as one route?

Jason Schiller: I would prefer that it stay because I think it's an important issue that needs to be addressed. Whether it needs to be addressed in this body or some other body would be fine. But right now there is no other body to address that. But I understand there's watershed movement to remove that, so it will likely get removed.

John Curran: Understood. Thank you. Okay. Thank you, Cathy.

At this time we actually go to using the show of hands in order to provide guidance to the AC and their consideration of this policy. And in order to keep the number of combinatorials simple, one of my jobs is to determine what we'll show hands on. So we're going to do it as the policy as written first. And then based on that we're going to do maybe another one. But first let's do the policy as written. So I want to make sure my polling machine is ready.

On the matter of the Draft Policy 2009-7, Open Access to IPv6, I'm going to do a show of hands. First ask everyone in favor and everyone opposed. Are we ready? We're ready. On the matter of Draft Policy 2009-7, Open Access to IPv6, all those in favor of the policy, raise your hand now. This includes remote participants.

Nice and high. Okay. On the matter of Draft Policy 2009-7, Open Access to IPv6 as written, all those opposed, raise your hand now. Nice and high. Consider this a practice run for tomorrow. Thank you. Tabulations coming our way.

On the matter of 2009-7, number of people in the room and remote participants, 147. In favor, 27; against, 48.

I'm going to ask another question. First of several. The next question is going to be the same draft policy, only instead of removing the requirement to have a plan to address 200 customers, to maintain that in and reduce the number from 200 to 100.

So this policy would remove the routing requirement and would maintain the requirement exactly as written right now to be an ISP, known ISP or to have a plan for addressing 100 customers.

Any questions about what the show of hands is about? Okay. On the matter of --

I'm going to ask another question. First of several. The next question is going to be the same draft policy, only instead of removing the requirement to have a plan to address 200 customers, to maintain that in and reduce the number from 200 to 100. So this policy would remove the routing requirement and would maintain the requirement exactly as written right now to be an ISP, known ISP or to have a plan for addressing 100 customers. Any questions about what the show of hands is about? Okay. On the matter of --

Scott Leibrand: Just to clarify, this would remove the requirement to announce as a single aggregate.

John Curran: Correct. But would maintain the requirement to have a need to be a known ISP or to have a plan to address 100 customers. Another question? Go ahead.

Glenn Wiltse: Glenn Wiltse, Merit. The policy as it is now is 200 --

John Curran: Correct.

Glenn Wiltse: You're saying lower it to 100?

John Curran: I'm saying to -- yes. This would remove the routing requirement to announce a single aggregate and reduce the end-user, the plan to be a known IS- -- yes, Igor.

Igor Gashinsky: Could you please tell us what other numbers you will be putting --

John Curran: Just 100. Just 100, Igor. And then the last query we'll do is we'll do one more show of hands entirely on a policy whose sole change it is to just remove the routing requirement. I see Cathy approaching the mic. Yes, Cathy.

Cathy Aronson: Is it possible to ask about a more LACNIC-style criteria? Just in general?

John Curran: I don't know if we've briefed everyone on what that is and what those bounds would be.

Cathy Aronson: Never mind, then.

John Curran: So I'm going to say I don't think it is a valid show of hands based on the discussion that has occurred.

Jason Schiller: I'm sorry. I'm now confused. We're talking about keeping the policy that's in the NRPM exactly as it is today except replacing 200 with 100; is that correct?

John Curran: No.

Jason Schiller: That is not correct?

John Curran: No, that is not correct. It's to take the Open Access Draft Policy 2009-7, the requirement -- to remove the routing requirement and then to also have it -- rather than striking the known ISP or 200 end sites, to replace it with known ISP or 100 end sites.

Jason Schiller: Thank you.

John Curran: So on the matter of 2009-7 as modified, Open Access to IPv6 with 100 end sites, I'm going to ask all in favor and all opposed. Again, on 2009-7, with 100 end sites, all in favor raise your hand now.

(Show of hands.)

Nice and high. Nice and high. Almost there. Okay. On the matter of 2009-7, as modified, with 100 end sites, all those opposed raise your hand now. Nice and high. Use the other hand if the first one's tired. One hand per person. Almost there. Almost there. Okay. Final tabulation. We're going to ask about only a portion of 2009-7. So the Open Access to IPv6 as modified, again, is a policy that only removes the single routing aggregate requirement. It leaves the current be a known ISP or have a plan to address 200 end sites. So we're doing an Open Access to IPv6 Policy, which whose sole requirement is to drop the single routing requirement in the NRPM at present. Okay. Any questions about what we're polling? This will be the final poll on this policy. All those in favor of 2009-7 as amended to only be the dropping of the routing requirement, raise your hand now. Nice and high.

(Show of hands.)

You're reaching for a beer. Okay. Almost there. Almost. Okay. On the matter of 2009-7 as amended to be only a policy which drops the single aggregate routing requirement, all those opposed, raise your hand.

(Show of hands.)

Nice and high. Okay. Thank you. On a show of hands regarding 2009-7, with the modification to 100 customers, number of participants, remote and in the room, 147. In favor, 42; against, 22.

And I'm waiting on the one which is just on the routing poll. It will be here shortly. On the policy of Open Access to IPv6 as modified to only be removal of the single routing requirement, 147 participants in the room and remote. 64 in favor; 10 against.

Thank you. This information will be provided to the Advisory Council for their consideration. Okay. I'm back. Okay. And this actually concludes the policy portion for today. We've actually addressed the templates presentation earlier and got ample feedback. And now we are into the open microphone portion, which is generally how we end our days here.

Open Microphone

John Curran: So it is now open microphone. Please remember to be courteous. The microphones are open. Remember, please identify yourself when you get to the microphone. There are detailed rules in your folder, if you want to look at them, in terms of appropriate courtesies. So open mic. Go ahead, front and center.

Leo Bicknell: Leo Bicknell, ARIN AC, ISC. I was talking to a couple of people during the break. We noticed something interesting that has occurred over the last two days and wanted to try to get some feedback on it.

If you attended the two-part ARIN at NANOG panel at the NANOG meeting, it seemed the panelists and those that appeared at the mic were in near universal agreement that 2009-1 was extremely difficult to understand.

We had a discussion period earlier today about 2009-1 at which not a single person stood up and voiced concern. So one of two things happened: Either all of these people went home with NANOG, and so they're not here to comment anymore, or they didn't comment for some other reason that's kind of a mystery to us.And in either case I'd like to know that they just went home, because that's really a sign that this is something that probably needed to be addressed, or if they didn't comment for some other reason, I'm really, really curious what that reason might be. So if that policy confused you and you spoke yesterday, why didn't you speak up earlier.

John Curran: Right. Approach the microphones if you want to ask your questions about 2009-1 and why the transfer policy confuses you. We'll stay on this one topic for a moment. Everyone just stand by your mics. Igor, do you want to respond on that topic?

Igor Gashinsky: Yes. Most of us who stayed and were concerned were too hung over to speak in the morning. That's really the answer.

(Laughter.)

I've stated this in the NANOG panel: Please put a flow chart in there that explains to an engineer what's supposed to happen there. Because two different lawyers gave me two different interpretations, and that's not good.

John Curran: Got it. Anyone else want to speak about the topic of the understandability of the transfer policy? Microphones are open for that topic. Yes, center rear mic.

Scott Bradner: Are you going to take the advice of putting in a flow chart?

John Curran: I'm sorry, repeat.

Scott Bradner: Are you going to take the suggestion of putting in a flow chart?

John Curran: Yes, we're going to look at that, see if there's a way to put a flow chart in to make it more understandable.

Scott Bradner: And if there isn't, that's very telling.

(Laughter and applause.)

John Curran: Other people on the transfer policy. Yes?

Cathy Aronson: Cathy Aronson. Because your day job got in the way you weren't able to comment this morning, but you're apparently here now, so do you have -- the fellow who just spoke, do you have a reason why you found the transfer policy to be confusing that you could share with us?

Tom Daly: I'm not exactly sure what it was, but after reading it multiple times over and over again, it seemed that the nuance of removing the M&A activity from the policy just did not come out at me, and it took quite a bit of time to get it through my head. Possibly I was being dense at the time.

John Curran: Okay. Anyone else want to speak on the transfer policy and its understandability?

Igor Gashinsky: That was actually exactly the same thing that our attorney was looking at. He went: Well, you have an M&A; is the other one an "or," an "and," how do they tie together. That was really the confusion. It was the two sections of it that are almost in conflict, supposed to be taken separate, together. That's where the problems were.

John Curran: I see. Okay. Anyone else to speak on the understandability of the transfer policy?

(No response.)

Microphones are open for all topics. Approach the mics. Far left mic.

Martin Hannigan: Hi, John, I'm Martin Hannigan, Akamai Technologies. There was some traffic over the last month on the list, both members and PPML, about some AC noncom issues. And I was hoping you could spend a little bit of time talking about that and what may have happened and how we might address this in the future.

John Curran: Sure. Actually, we're going to wait until the end of the election process and then we're going to talk about that, both on the mailing lList and in subsequent meetings. But I'd rather not discuss within the current election period the particulars because it's not appropriate while the balloting is still about to happen.

Martin Hannigan: Gggrrrr...

John Curran: Yep. Sorry. Trying to be equitable to all. Okay. Center front.

Dani Roisman: Dani Roisman, Peak Web Consulting. I've been involved with conversations about the integrity of the IPv4 routing table and the potential for future abuses, and I haven't heard -- I haven't heard this yet, so apologies if this is happening on a mailing list and I haven't been watching or if we've already discussed and decided not to do this, but the topic is an authoritative routing registry that ties prefix to originating ASN, for example. I know that for recent resource requests, IPv4 resource requests, originating ASN has been added to the template as -- I believe it's an optional field, but that field is not necessarily utilized, at least not that I'm seeing in any way. We noted that there are multiple routing registries in use. Some are free. Some are for pay. Some are run by certain individual ISPs because they use them for their own policy building. But it seems to me that it may be valuable and I'm interested in hearing feedback. You can contact me directly afterwards. Seems it would be valuable in developing an authoritative routing registry we can all point to. I just don't know if it's something that ARIN -- I know ARIN has their own routing registry, but I just don't know what the format is.

John Curran: Let me ask specifically: You're not proposing we create another routing registry; you're proposing that we need to get rid of routing registries so there can be only one?

Dani Roisman: In an ideal world, we would all decide who is the authoritative routing registry and we would have some way to do authentication and share in one happy registration world.

John Curran: ARIN runs a routing registry. Some of our members have said they value it. Some of them say they don't use it at all. ARIN runs one. Merit has a very active routing program. And obviously RIPE NCC. There's a number of them out there. ARIN's open to guidance as to whether or not we should run ours or there should be one less. But it's very hard to envision how to get to a single world routing registry, which is kind of what you're asking for. But people who want to talk about that should definitely hunt you down and talk to you, because it is a problem. Right now we have a multiple set of databases that assert to have this data. Mark, did you want to respond?

Mark Kosters: I'd like to add a few more comments. Mark Kosters, CTO of ARIN. ARIN also mirrors everybody else's, and so there's mirroring that goes on as well. Even though you have these sort of islands of where you get this information is you can actually -- you can get a fairly reasonable -- reasonable set of data. The question -- the problem is that the data in the routing registry right now is weak. Only 50 percent of it is valid. So it's not as useful as what it could be. And it's really you as a community, whether or not you really want to actively maintain it. That's one point. The other point is that there is a new sort of emerging system that's being put into place, and it's called resource certification. And ARIN actually has a pilot of this, as much -- as well as other RIRs, that actually at some point may subsume the routing registry, and that's -- the website for that is rpki-pilot.arin.net. And you're welcome to join. Anyone.

John Curran: That will certainly address the question of who's authoritative regarding announcing a route. It may not tell you the policy attributes of how they're announcing the route, and that's the question long term.

Mark Kosters: To be clear, it's not the number of routing registries; it's really more to the certification, the authority. At this point in time I can place whatever prefix I want into a routing registry whether or not I have the authority to do so.

John Curran: Right. That's very much what RPKI is targeting to address. Microphones remain open. Center rear.

Lea Roberts: Lea Roberts from Stanford University, also on the ARIN AC. I just wanted to put another comment in. There was a sort of casual comment during the discussion on 2009-7 about the benefit of ARIN doing sparse allocation. We talked about that last night, so I thought for the whole meeting or for the whole community here at this meeting -- I'm not sure what the right thing to do is as far as putting something in the suggestion process. I know it's not a policy issue. But I do think it would be really useful rather than worrying about getting the perfect sparse allocation at least increasing the space between IPv6 allocations to be much larger than it is today.

John Curran: Is there anyone who wants to speak against ARIN doing sparse allocation? Okay. Having confirmed that, let me say pretty plainly, before we end the meeting on Friday, we'll get a time line for doing sparse allocation. Okay.

(Applause.)

Microphones remain open.

Lee Howard: Lee Howard, Time Warner Cable and ARIN Board of Trustees. Earlier this week there was a suggestion during one of the IPv6 panels at NANOG that Aaron Hughes write a best current practices document for ISPs. I think he was joking when he said such a -- well, he said such a thing would probably be useful, and I suggested he should write such a thing. And several other people had noticed and said, yeah, you know, something like that might be a really good thing. Maybe it's not a single document. Maybe it's a repository of good ideas. And I wanted to -- as I've gone around and seen a lot of people say, yeah, maybe something should happen in this space, nobody has quite figured out which space that work should happen in. So two questions. One is does the community think this is a good idea, and, two, can ARIN or should ARIN help facilitate that kind of activity?

John Curran: Topic is open. Microphones, front. Jason and then Owen. You have a different topic.

Jason Schiller: Jason Schiller, Verizon, UUNET, NRO NC. I think having a BCP document is a good idea. I don't think it's a document a single person can write. If a single person does write it, it will not be valuable or useful. I think what we need is a process similar to the process that we have here where the community gets together, they write their thoughts on what policy should be. And we discuss it, we take a straw poll, we judge consensus, and then we produce a living document that changes over time. I think Igor and a number of other people have said we should not be writing a document that says what you can and cannot route; they're my routers and I'll do what I want. I think that's fine. I don't think that this has to be a binding document. But I think having a best common practices document would be helpful to many of us to go back to our companies and justify what are good routing practices.

John Curran: Agreed. On the topic of where such document would be written and how, center rear mic -- oh. Do you want to respond to that? Okay. Owen and then center rear mic.

Owen DeLong: Owen DeLong, Hurricane Electric and ARIN Advisory Council. I think it's a great idea to develop this BCP document. I think a good place to get the community involved in developing it would be to set aside a new category or whatever topics are called on wikis. I'm not the greatest wiki editor or knowledgeable person in the world, and I would be happy to work with ARIN on starting to generate that topic on the ARIN IPv6 wiki and starting to put content in there.

John Curran: Center rear microphone.

Chris Grundemann: Chris Grundemann. Echoing what Owen just said, I think the IPv6 wiki on ARIN's website is a good place to start. The fact it doesn't already have a lot of this information means that maybe it needs some coaxing along. Maybe there can be an ARIN-appointed task force -- I don't know what it would be -- to organize the effort and get the ball rolling a little bit more than what's already there.

John Curran: We're trying to do a little bit of that. But I agree we need to do more. On this topic of best practices and routing and where that should be done, other people want to comment on that topic? Aaron.

Aaron Hughes: I think having a repository somewhere is fantastic. And while I believe that ARIN is far more organized in terms of putting documentation online, it would seem to me the better place to start with this would be to work with the program committee at NANOG to try to put something together. And that could be a joint collaborative effort. But I believe if we are to start something as ARIN, it won't have the operational support that it needs to make those documents useful.

John Curran: Good observation. Anyone else want to talk about best practices documents for routing? Okay. Ending that topic, I know we have another topic. I'm assuming you've got a new topic. I'm closing the floor to new topics. So we're just going to finish these last two. Go ahead.

Stacy Hughes: A question from someone who would prefer to remain nameless. And I'll tell you why in a second. His question was: If you are a legacy IPv4 holder, must you sign an RSA to get IPv6 resources? I was pretty sure I knew the answer to this one.

John Curran: If you're a legacy IPv4 resource holder, must you sign an RSA to get IPv6 resources.

Stacy Hughes: Any RSA.

John Curran: To get IPv6 resources, I know you need to sign an RSA. That does not mean that your legacy addresses need to come in under that.

Stacy Hughes: Okay.

John Curran: But you do need to sign an RSA. Is that correct? Let me double-check. That's correct. Okay. Cathy, last topic.

Cathy Aronson: This is me again, Cathy Aronson. Since there didn't seem to be adequate discussion of the LACNIC version of the requirements for IPv6 initial allocation, I thought perhaps I would read them really quickly and you could comment if you wanted. The requirements -- oh, I can't get it out of there; it's too tall for even me.

To qualify for initial allocation of IPv6 address space, an organization must:

One, be an LIR or ISP.

Two, document a detailed plan for the services and IPv6 connectivity to be offered to other organizations, clients, or self-owned related departments, entities, sites to which it will assign /48s.

Announce a single block on the Internet interdomain routing system aggregating the total IPv6 address allocation received within a period of not longer than 12 months.

Offer IPv6 services to clients or self-owned regulated entities including departments and/or sites physically located in the region covered by LACNIC within a period of not longer than 24 months.

And I do understand that we don't need to rehash the single aggregate thing, but I just thought that this might be -- some version of this might be a good alternative to arbitrarily picking 100 or 200 or 25, and I'd really like to know what you think. Thanks.

John Curran: People want to speak about the LACNIC requirement to introduce routing at a certain period of time, please get -- approach the mics. Scott.

Scott Leibrand: Scott Leibrand, ARIN AC. Just hearing that made my head hurt and made me think of 2008-2, the first transfer policy. I think we need something simple. I'm not sure what kind of simple thing is good.

Cathy Aronson: I can say from my experience -- I haven't presented it here in a while. Gert Döring does this IPV routing table thing. There's a significant number of IPv6 prefixes that have not ever been advertised in the table. So I don't know. Anyway...

John Curran: And is this requirement to announce it within 24 months, do you think that makes --

Cathy Aronson: Within 12 months. Announce it within 12 months and --

John Curran: Does that make it more likely that it gets announced than not having a requirement?

Cathy Aronson: Well, I would think that if this is in the -- if this were in our allocation policy, then if it wasn't announced, we could revoke it.

John Curran: That's adventurous. Microphones are open for discussion on this topic.

Matt Petach: This is Matt Petach from Yahoo. I'd like to respond to Cathy's inquiry there. I definitely think it would be of interest to see more pressure on a time-based announce it or lose it/rejustify it. Looking at the numbers from this morning, we were looking at tens of thousands of blocks or equivalent-sized blocks being allocated, looking at very rapid growth in IPv6 allocations in regions, and then you look at the IPv6 table today and you go, Where is all this? So I do think we should consider putting a time-based, if you don't announce it within a period of time ARIN has the ability to go back and essentially reinvestigate the business plan you put forward and say, How far along on this business plan are you? Is this something where maybe three months, they're a little late, you can extend it, but definitely keep the pressure on them to keep moving on it. Thank you.

John Curran: Rear microphone.

Chris Grundemann: Chris Grundemann. We've talked about this IPv4 and legacy space, especially with reclamation. And announcing space is not a requirement of using that space. Meeting global uniqueness does not mean you need a slot on the Internet. I don't think that requirement is valid. The ever popular on the PPML lately, the power grid, that's a perfect case for using IPv6, needing globally unique addresses but not ever wanting to announce it onto the Internet. And I don't think they should be denied giving those addresses. Plus the load on ARIN staff has to be pretty large to go back and check routing tables, where do you check at, how do you verify that they're announcing or not announcing it. It sounds like a nightmare.

John Curran: Cathy, would you like to respond?

Cathy Aronson: I would. This is actually their ISP policy and they're requiring that you actually within 24 months be reallocating /48s. So it wouldn't affect that the end-user or an allocation that you would get necessarily for your business to be unique yet private. This is actually for ISPs. I don't know if that changes your comment.

Chris Grundemann: It does a little bit, I guess. I guess it needs more thought.

John Curran: Center front. If you want to sign it, I will speak it for you.

Chris Morrow: All I know is more. Whatever the baby knows, I know. So this is for Cathy's thing. I think it would be very difficult to go back and say that if you have an address block you have to announce it on the public network. There are lots of big private networks. I have a big private network that you can't see. So do lots of other people. Making it a requirement to announce it I think is a bad move.

John Curran: Okay. Microphones remain open on this topic. This is the final topic of the day. Closing the microphones shortly. Go ahead, Leo.

Leo Bicknell: Leo Bicknell, ISC, ARIN AC. I don't like the word "announce" for many of the reasons that have been discussed. I do like having a requirement that it must be in use in some particular period of time, because that's not something we really have today. Where in use could be announced, that may well qualify, and maybe the simplest thing for ARIN to check. But it may also be in use on your private network or any of those other things. And I actually think that requirements like this could help reduce a large part of the problem that we have seen in the IPv4 world. There are blocks allocated that have never been used, as far as I know, privately or publicly. There are boxes that have been used for some period of time and have now been disused for years. So I think it's not only that you have to use it within 12 or 24 months, but every 12 or 24 months we potentially might see if it's still on the table or ask you if it's still being used or whatever. I think it's actually a useful thing.

The one caution I have with respect to IPv6 right now is there are a lot of large networks that are going down the path of IPv6 enabling their networks and they obtain IPv6 space within an intent to offer service in 12 to 24 to 36 months, depending on whatever. Because we're in this weird start-up phase, I think we need to be a bit careful. It would be rather silly to put in a 12-month requirement and have ARIN staff spend a whole bunch of time asking people why they haven't used it in 12 months when the reality is their vendor delivered the equipment six months late and it's going to be 13 months before they use it. We have a problem with IPv6 right now. But I think the overall concept is something we should do for both IPv4 and IPv6 to help ensure that these resources are actually being used. I don't care if it's public or private, but let's verify that they are continuously being used.

John Curran: Right. They're assigned for some purpose, they should be used for that purpose. I'm closing the microphones. Okay. Queue at the end. Center rear.

Chris Grundemann: Chris Grundemann. After giving it more thought, if it's for ISPs, I think that the customer number requirement does the same thing. I mean, if you have the customer, I mean, that's something that could be verified, if it's SWIP 'd to valid organizations or not, and instead of trying to use an announcement as the bar. If you're going to be an ISP, you're going to have customers. Otherwise you're not an ISP, I don't think. If you have customers, you SWIP to them. And then that's verifiable and you can go from there.

John Curran: Cathy, do you want to respond?

Cathy Aronson: I do agree with that. It's just that all we ever talk about is: Is it 100? Is it 200? We've had this discussion for like 10 years. And the reason that I brought this up is because their requirement is you have customers within 24 months, whether it's one or five or 50. It doesn't matter. But you're announcing it in 12 months and you have customers, visible, SWIP 'd /48s in 24 months. Which I think might be a little bit more reasonable for the smaller guys maybe. I don't know. I'm not an advocate of this one way or the other. I just wanted people to talk about it.

John Curran: Aaron, you're responding directly to that comment?

Aaron Hughes: I have a question to help us think about it a little bit. Is there anything in NRPM that has resource review for IPv6 in place, periodic resource review?

John Curran: Not at present to my knowledge. The NRPM resource review policy allows resource review, but it's not v6-specific. I don't think any of the IPv6 policies mandate resource review. Could be. Easy to add. Find someone you know on the AC and start there.

John Curran: I will double-check. Nate and Leslie, does NRPM 12 only apply to --

Leslie Nobile: I'm back here. I think -- I'm pretty sure that policy -- well, Owen, gosh, you wrote it. Do you remember? Owen, do you remember?

John Curran: I don't believe it's resource-specific.

Leslie Nobile: I don't think it is either. I just think it's just IP address blocks and ASNs.

Owen DeLong: The resource review policy was very deliberately not resource-specific.

Leslie Nobile: So it covers anything.

John Curran: It's certainly available.

Owen DeLong: The only specific exemptions it has are for legacy resources, and that was cryptic in the way it was worded.

John Curran: And final comment on this. Center front mic, go ahead.

David Farmer: I want to thank Cathy for bringing this up. As an AC member, this has helped me quite a bit. I think we've got a lot of work here to do. I think there's some obvious things we're going to move forward on. But there's more -- much more work to be done here. And then I'd like to thank two people real quick. I'd like a round of applause for Leo and for Lea, who are leaving the AC, for their many years of service.

(Applause.)

John Curran: Well earned. Thank you.

Closing Announcements and Adjournment

John Curran: Okay. This concludes our meeting for today. This is the evening you actually have free. To my knowledge. Right? Yes, free. So we are going to resume tomorrow morning. We resume at -- bright and early at 9:00 a.m.

Remember to fill out your surveys, ARIN survey online. If you submit your entry today, you have a chance to win something tomorrow. We have wonderful prizes. I remember thinking when I looked through the prizes that I really wanted to be eligible to enter the survey, but I'm not. So don't lose out on your opportunity. You are. I'd like to thank our sponsors, Arbor Networks and Merit.

(Applause.)

Okay. Breakfast, 8:00 a.m.; meeting, 9:00 a.m. The agenda is in your folder. We will do everything we can, just like today, to stay on track for the start times of the policy proposals.

To the extent possible, we will start all the policy proposals on time. Even if we're running ahead of schedule, I will pull other items up. If for some reason we can't do that, we're going to send announcements out to all the appropriate mailing lists and all the social networks saying we're rearranging.

But for remote participants in particular, or people who want to be here for a particular policy session, we're going to try to do everything we can to make sure we follow the agenda.

Thank you. Enjoy your night off.

Okay. Breakfast, 8:00 a.m.; meeting, 9:00 a.m. The agenda is in your folder. We will do everything we can, just like today, to stay on track for the start times of the policy proposals. To the extent possible, we will start all the policy proposals on time. Even if we're running ahead of schedule, I will pull other items up. If for some reason we can't do that, we're going to send announcements out to all the appropriate mailing lists and all the social networks saying we're rearranging. But for remote participants in particular, or people who want to be here for a particular policy session, we're going to try to do everything we can to make sure we follow the agenda. Thank you. Enjoy your night off.