Table of Contents
- Meeting Called to Order
- Regional PDP Report
- Internet Number Resource Status Report
- 2009-1: Transfer Policy
- RIR Update - APNIC
- IPv4 Distribution Options for the Last Eights
- 2008-7: Identify Invalid WHOIS POC's
- An Analysis of ARIN NetHandles with OriginAS Data
- ARIN Business Process Review
- ARIN Web Accounts Demo
- RIR Update - AFRINIC
- 2009-4: IPv4 Recovery Fund
- Open Microphone
- Closing Announcements and Adjournment
MR. CURRAN: Good morning. Welcome, everyone, to our ARIN meeting in beautiful San Antonio. I'd like to get started. I'm John Curran. I am a member of the Board of Trustees, the acting CEO and President of ARIN. For those who have missed it, I am not the chair of ARIN. I actually relinquished that a while ago, a few weeks back. Paul Vixie, my esteemed colleague, is the chair of ARIN. I'll be running the meeting as the Acting President and CEO. And we have an exciting agenda for us today. So moving right on. Sorry. Who is here? Right, I want to do the introductions of who is here. Yes, I see people here. Thank you.
Wonderful, we have at the head table here we have members of the Board of Trustees and members of the Advisory Council. The Board of Trustees are of course myself, Paul Vixie, Scott Bradner and Timothy Denton. Those are trustee members.
We have also trustees attending here today. Lee Howard. Lee's out there somewhere. Where are you, Lee? Way over there. Thank you. And Bill Woodcock is hiding somewhere out here as well. Thank you, Bill.
We also have the Advisory Council. There's all the names, with the three at the head table are Heather Schiller. Sorry. Yes, Heather's here. I didn't see you over Tim; Heather, Bill Darte and Cathy Aronson. And then we have all the other members of the Advisory Council. I guess would you all raise your hand or stand up so people can find you. Very good. Wonderful. Okay. We have members of the NRO Number Council, Martin Hannigan, Louis Lee, and Jason. Where are you? Jason, Marty, Louis. Louis? Louis is at the meeting somewhere. Maybe he's still doing Riverwalk or something. Okay.
Our colleagues, quite a few representatives from other RIRs are here. AFRINIC: Ernest, are you here? Yes, yes, somewhere. Okay. I saw him earlier. APNIC: Folks from APNIC, raise your hand. There you are, clustered together, sort of group togetherness.
LACNIC: Raul, where are you? Raul? I know Raul is here. I had a good conversation with him last night. From the RIPE NCC, where are our folks from RIPE? Axel and company, very good. Okay.
And of course ARIN staff. ARIN staff, Susan Hamlin, always there. Mary Kay. Leslie. Mark Kosters. And in front of Mark, Bob Stratton. Myself. Nate. Where are you, Nate? There we go. Cathy Handley, Government Affairs. And Richard Jimmerson, is he here?
MR. DAVIS: He is not.
MR. CURRAN: That's right. He's on travel. He's our man about town doing a lot of the ARIN outreach. Yes, we also have a number of folks here this time, because of ARIN's fellowship program. We have a fellowship program that allows people who otherwise wouldn't be able to attend to attend and present their views and also bring back information from ARIN back to the regions that they're from. So the recipients this time: from Canada, John Kuhn from the Government of Ontario. John? Somewhere here. Thank you. From the U.S.A., Steve Dodd, University of Idaho, in the back row. And from the Caribbean; Rudolph Daniel where are you, Rudolph? Somewhere. Yes, right in front of me. Thank you.
This is a very good program. It allows people thank you. It allows people to come who otherwise wouldn't be able to make it, and allows us to continue our efforts for education and communication.
First-timers, welcome all the first-timers. First-timers, raise your hand. Okay. We want to welcome our first-timers.
Yesterday we had a first-timer's lunch where they got to meet representatives of all the organizations in ARIN, the AC, the Board, and also meet the ARIN staff. We did a little presentation and orientation. They're not going to be up on every acronym. We gave them the big glossary of our acronyms, explained assignment and allocation and what an IANA is and an RIR. We even said LIR in case they were talking to someone else from another region. But the new timers are going to, first-timers are going to require a little orientation. It's a very friendly community. Feel free to of course ask anyone from ARIN, but also all the people we just represented are more than happy to help out our first-timers.
We have a prize drawing. So let me get the envelope. Hold on.
First-timers filled out a survey which will give us feedback on how to improve the first-timers’ luncheon, and their surveys are in here. I will ask for a volunteer from the community. Anyone want to draw a name out of a hat? Some volunteer? Aaron Hughes. Thank you, Aaron. Come on up.
Draw one survey, Aaron. Thank you, sir. Thank you. All right. The winner is: Tom Rasor. Tom, are you here? first-timer Tom. You have to be here. For this you must be here to win. Tom Rasor, lht.com. Tom? Oh, come on, Tom. Please don't make me give your prize to someone else. Okay. Going once, going twice. Welcome back, Aaron.
And the winner is: I'm going to say Yiu Lee from Comcast. Yiu Lee. Thank you. Yiu Lee? (Laughter) Okay. Going once, going twice. I was going to say, our First and Last Timers’ luncheon? (Laughter) I'm going to have to read the survey forms, obviously. Thank you, Aaron. We have success. Steve Dodd, University of Idaho; Come on up, Steve. (Applause)
And I have here the survey. What's the prize?
MS. HAMLIN: A ThinkGeek prize package.
MR. CURRAN: Ah, congratulations, Steve. We're going to mail you a ThinkGeek package with a prize package with lots of stuff. Thank you. Very good. Thank you for filling these out, all the first-timers. This does help us a lot and lets us get a better program going.
Okay. We have remote participants, and remote participation in ARIN has improved at every meeting. So we now have a webcast and a live transcript, where all participants can enter in the daily meeting surveys that we have. There is a raffle that we give out prizes. They actually do not have to be here for the remote participation. You can win without being here.
And all the meeting materials are downloadable. With respect to participation, there is a community chat that they can participate in. There's a virtual microphone. Remote participants who participate who want to have something brought to the mic can do so in the chat window. And also on show of hands, remote participants can participate in the show of hands via the chat room for that purpose. So we're trying to really make it possible not that we don't like to have you all here. It's great to have you, but if at a future meeting you can't make it to whatever beautiful, sunny location we're at, you can participate remotely. So thank you very much, remote participants.
Attendance stats. We have 130 participants. We have four from Canada, 112 from the United States, two from the Caribbean, 12 from outside ARIN, 31 new first-timers, and we have 31 remote participants. Very nice attendance.
I'd like to thank our sponsors. Want to really thank our sponsors. Network connectivity is provided by Time Warner Cable Business Class. I also want to thank Rackspace for providing laptops for the ARIN information center, so a round of applause for our sponsors.
Daily meeting survey. Okay. It's time to select our winner. This is going to be the prize: a $50 gift certificate to ThinkGeek. Everyone who filled out the online meeting surveys yesterday is subject to this, and does not have to be present. You will get the prize mailed to you. I have 27 respondents. I'm going to pick a member of the audience. I'm going to pick Leo Bicknell. Come on up, Leo. (Applause)Pick a number from one to 27, and read me the name.
MR. BICKNELL: Donnovan Wint.
MR. CURRAN: The winner is Donnovan Wint of Johnson & Johnson. Donnovan, are you here? Hey, you're a winner. $50 gift certificate to ThinkGeek. Thank you for filling out the survey.
Okay. Surveys are posted online each day. Again, you can be here or remote. You submit your entry between 8:00 AM and 6:00 PM. People who fill out the survey today, you could be like Donnovan tomorrow and get your gift certificate. You must be present, that means here or remote. We have to be able to tell you that you've won. Remote participants are more than welcome.
Okay. And participants packet; all of you have a folder. In that folder you have the meeting guide, the discussion guide, a copy of the NRPM. You have our service level report for how ARIN's done since the last meeting in delivering services. You have the instructions for the survey. You have the IPv6 network information. If you want to use the IPv6 network, you have a handout for that. And you have a map that will get you from here to the social. It's just a short distance away.
Advisory Council topic tables, okay. When we get to lunch, we're going to have various topic tables where we discuss issues, issues that are current to the members. So at lunch think about this. Some of the things you could talk about, ARIN's responsibilities in v6, how to deal with routing that doesn't match ARIN's policy. The Advisory Council has suggested some of these topics, and also any other topics that come up are certainly valid. It’s going to be something to get juices going when we have our lunchtime period.
The Social tonight, 6:00 to 10:00 p.m., at the Southwest School of Art & Craft. It's a barbecue outside with line dancing and a good time. It is a short distance away, so it shouldn't be very hard for people to make it to. And it is going to be a great outdoor, beautiful little event.
Rules and reminders. The chair moderates all discussion of draft policies that everyone can speak and be heard. Please comply with the rules and courtesies in your program. In particular, recognize that we operate going to Robert's Rules of Order as modified for a meeting like this so everyone has a chance to speak. Please don't go up and horde the mic. Let everyone else speak before you come up for a second time. In particular, when you get up, please clearly identify yourself and also please take the time to say whether you're in favor or opposed to the policy so people can understand the perspective you're coming from.
Okay, Agenda overview, today we start with reports this morning. And that's going to be the Regional Policy Development report which will be given by Einar. Then we'll move on to the Internet Number Resource Status report. And we'll have the RIR updates have been slightly reorganized. We'll have an IANA report this morning. And then we'll have later on in the afternoon we'll have ARIN's Business Process Review and we'll have ARIN's Web Accounts Demo. These are in addition to the policy topics that we'll be talking about today.
Today's special presentations: IPv4 distribution options for the last 8s, very important topic, and An Analysis of ARIN NetHandles with OriginAS Data. So some very nice presentations coming up.
So policy discussions. We're going to talk about a few of the policies that are out there. That's a major thrust of the ARIN meetings. This includes 2009-1: Transfer policy, 2008-7: Identify Invalid WHOIS POCs, and 2009-4: IPv4 Recovery Fund. All of these are in your program handouts. So you can actually look and look at the text of these draft policies, something worth reading before they come up for discussion.
IPv6 wireless: If you're using the ARIN wireless SSID, you're a dual stack IPv4, IPv6 network. If you're using ARIN v6, you're a pure IPv6 network with no IPv4. You're living in the leading edge. Have you your choice one way or another. More information is available on our wiki. So feel free to look there if you need any more information.
SWIP of the future BoF: tomorrow at 5:00 PM we're going to have an interactive "birds of a feather" discussion where we talk about the ARIN SWIP process and get feedback as to how you want that to evolve over time. Obviously SWIP is a leading edge, cutting technology, but we're thinking we might want to, going forward, have some more ways to interface with ARIN programmatically. And so this will be a discussion Mark Kosters and team will be giving to get feedback from the community about how you want to interface electronically with ARIN's database.
Okay. Let's get started. I already introduced the head table. So I just want to start off with the first presentation. It's going to be Einar Bohlin, who will do the Regional Policy Development Process Report.
MR. BOHLIN: Thank you, John. I'm Einar Bohlin, the Policy Analyst at ARIN and this is the Regional PDP Report. It's basically an update of what is being discussed at all the five RIRs around the world. I'm presenting it a little differently this time from the last meeting.
This chart has columns and the blue zone is a snapshot from the last ARIN meeting and represents what was being discussed in October of last year. The red column is this meeting, a snapshot of what's going on today; and the green portion is the ARIN, the green is the ARIN portion of the current proposals. So I want to talk about a couple of these things. As you can see, the IPv4 category is still a hot topic.
At the last ARIN meeting, five items from that blue column were the global proposal about the last five /8s from the IANA to the RIRs, which has subsequently been adopted and will occur when the IANA /8 pool depletes. Each RIR will get one /8. In the current IPv4 category, there's a global proposal about what to do with existing policy of allocations from IANA to the RIRs, and it involves reclaiming space and creating a pool that the RIRs can draw from when all those /8s are gone.
And in addition to that topic there are still discussions about transfers. There are already discussions about modifying transfer policy, and there's discussions about at the RIRs about what to do with the last portion of IPv4 space that the RIRs have, when stocks get low maybe things should be changed. Topics in that category include tightening policy, making it harder to get, or making the threshold higher before you can come back to the RIR, and making the allocation time frame shorter so you have to come to the RIR more often. Those are the kinds of things that you can see if you look at all those v4 proposals. We have four of them on the agenda this week.
Moving on to IPv6; this used to be a pretty hot topic, and I wish I had done this slide like this over the years, because it's definitely lower than it's been in the past. We have one here at the ARIN region about community networks. And the bulk of those are about making it easier to get IPv6 space.
We have one directory services proposal that is being discussed at any of the RIRs, and that's here in the ARIN region. I'll talk about that in the next slide.
And moving to ASNs, there's one proposal here in the ARIN region, and I'll also talk about that in the next slide.
This shows the six draft policies that are under discussion here at this ARIN meeting, and that's the left column there. And it shows whether something similar is being discussed at any of the other RIRs.
I talked about the community network proposal. I mentioned that one. Something similar is being discussed in the AFRINIC region. They have a v6 for nonprofits proposal. The second one, Identify Invalid WHOIS POCs, this draft policy actually has evolved somewhat. And I indicated that the APNIC region had adopted this. But what the APNIC region actually adopted was and they've implemented this for a couple of years is not exactly what we're talking about here. The APNIC folks require a contract with the RIR in order to update records, and that's what this proposal used to look like.
So the next four items are all v4 category draft policies. 2009-1 transfer policy has been, starting on the right, adopted in the RIPE region. It's under discussion at LACNIC, and it's in last call for a few more days in the APNIC region.
Depleted v4 reserves is about what to do at the very end of your RIR stock. APNIC and LACNIC have adopted policies where they're reserving space, and they're making the maximum allocation quite small so that there will be a range of v4 space for folks to use when you can't come in and get a /16, for example.
And of course there's the global proposal, which is a little different here in the ARIN region, but it's under discussion at all five of the RIRs. And then last but not least, the IPv4 Recovery Fund, which is a unique ARIN proposal.
Here's some references if you want to see exactly what is under discussion at the different RIRs. You can go to their websites and see what they have.
And the last item there is the policy comparison overview, which is perhaps getting more interesting, because it's a document that currently RIPE is updating as the secretariat of the NRO, RIPE NCC, rather. This is a document where, for example, if you wanted to see what the maximum allocation policy was at all five RIRs, you can go to that section in this document and see a summary, and you can find the answer to that question.
I think that's it. Thank you.
MS. NOBILE: Good morning, everyone. So this is the joint stats we call it for short. It's the statistics of all five of the RIRs, and shows IPv4 and IPv6 allocations and Autonomous System Number assignments. We've gone back 10 years and we show the formatted -- side-by-side format of all the assignments and allocations in the RIR regions, and in addition we show the status of the IPv4 global pool.
So we start with the IPv4 address space, the global pool of addresses. And I'll start with this green pie. And there are 35 /8s out of the 256 that are not available for issuing to the IANA, because they are in use by the ITF. It's broken down. You can see experimental local ID loopback, private use and multicast. So that space is unavailable for the IANA because it's in use by the IETF community. Moving to the left. In the grey box you see the central registry. 91 /8s were issued in the early days, in the '80s and early '90s, to U.S. government contractors. The SRI-NIC, the DoD NIC, the InterNIC. And this is where all the legacy address space resides, Class A, B and C addresses, and much of that was issued within the ARIN region, particularly in the U.S. because that was where the early growth of the Internet was.
So moving down to the blue box, the RIR space. The RIRs in total, the five RIRs together, have been issued 98 /8s by the IANA. If you break that down in the blue boxes, you'll see that APNIC has gotten 30 /8s; RIPE has gotten 28; LACNIC, six; AFRINIC, three; and ARIN, 31.
The grey box just above that shows what left in total in the global IPv4 address pool. There's 32 /8s left out of the 256.
So this looks like the IPv4 address space issued to all customers from the five RIRs. You know, it shows the growth trends up and down, but the thing to note really is that there's been steady growth in all of the regions since about '05, but much of the growth has been in the APNIC region and in the RIPE region.
ARIN, over the past three years, has been pretty flat. We've issued about three /8s. It looks like we're sort of on the same trend at this point. And an interesting thing is RIPE was steadily growing, but last year they issued less than three /8s for the first time in several years. So they actually went down in the amount of space they issued last year of v4 space.
But of course the story is the APNIC region, who issued more than five /8s last year, which is more than any RIR has ever issued in one single year. So the growth is clearly in that region.
This just shows the cumulative total of over the past 10 years of how much space each of the RIRs has issued. So in the past 10 years, RIPE has issued 22.76; ARIN, 21.33; LACNIC, 3.53; AFRINIC, .88; and APNIC 25.54 /8s.
This is ASN assignments. Early on, ARIN was issuing more ASNs than any of the other regions, but that sort of started to change around '05 when RIPE started issuing more ASNs in the region. The other three RIRs are issuing minimal amounts of ASNs, as you can see at the bottom. I forgot to mention this is color-coded. I'm guessing you probably got that by now. This is the cumulative total. This is the total number of ASNs that each of us have issued, each of the five RIRs has issued, and of course RIPE NCC and ARIN have issued more than any of the three RIRs together, in fact.
So moving into IPv6 address space; this is sort of a complicated one. So if you look at the gray pie on the left, that is the total IPv6 address pool. It's a /0. A /3 of that has been taken out and reserved and called for the global unicast space. So that's space that IANA holds to issue to the RIRs, and there's 506 /12s in that space. And in 2006, October 2006, there was a global policy that said that the IANA should issue each of the RIRs a single /12 to work from, so that's shown right over there.
So prior to that the minimum allocation size from IANA to the RIRs was a /23. So between 1999 and 2006 we were getting little bits, /23s, from the IANA to issue to our customers. And can you see RIPE got 15 of the /23s; APNIC got seven; ARIN got five. There were three for special purpose: two for RFCs and one was a RIPE reservation. LACNIC got one and AFRINIC got one.
If you look at the allocations over the past 10 years, the story is that most of the growth in IPv6 has been in the RIPE region. They have issued far more IPv6 addresses to their customers than any of the other RIRs. And early on we thought that was going to be happening in APNIC. We thought that they would be issuing more space. But it has really changed and RIPE is issuing much of the v6 address space today.
This slide shows on the left the total allocations, the total number of allocations made by each of the RIRs. So RIPE, in yellow, has issued 1338; ARIN has issued 547; LACNIC, 177; AFRINIC, 68; and APNIC, 490.
So that's just individual allocations. But if you look at those allocations in terms of number of /32s issued, because /32 is the minimum allocation size -- you can request more space if you can justify it. So when you really look at the individual number of /32s, those numbers change drastically. And RIPE NCC has issued over 33,000 individual /32s; ARIN has issued over 14,000; LACNIC, 186; AFRINIC, 68, which is the same -- meaning that they've issued only /32 allocations to date, nothing larger; and APNIC has issued over 24,000 individual /32s.
So four out of the five RIRs have issued larger than /32 allocations to some of their customers, and RIPE in particular has done that more often.
And these are just links to the RIR stats. We all hold them on our individual site. The NRO site has them. And the raw historical data is on the IANA site.
And that is all I have. Are there any questions? Okay. Thank you.
MR. CURRAN: Okay. Welcome back. We're going to jump right into our policy discussions. So the first policy discussion is Transfer Policy 2009-1. This transfer policy is a board-initiated transfer policy under the PDP emergency policy process.
I'd like to do the -- actually, we usually call someone up to do the history. Einar, do you want to come up and do the history of this as you do for the others?Actually, do you usually do it or does… Sorry. A little bit of change here, because I still have to take the Chairman's hat off and make sure Paul has it, and growing used to my other hat. So I will give these.
History of the proposal. It was done on 24th of March by Board of Trustees emergency PDP action. Discussion period extended through ARIN 23 on 3 April '09.
The staff and legal assessment came back on 21 April, and the current version is still unchanged, 24th March 2009. Not relevant, really, similar proposals. There are transfer policies in other regions. But they're not one-for-one parallels. We do have AC Shepherds for this because we need to get the feedback of the Advisory Council. That's actually part of our emergency process. When the Board takes action, it goes to the -- the AC has time to take a look at it and give feedback.
So Dan Alexander and David Farmer are the AC folks who would be the shepherds that normally present in the policy proposal. Since it's a Board action, I'm actually doing the presentation.
Next slide. So summary of the 2009-1. It defines organization. The Board in the process of doing this added a definition of organization because it needed one to make the policy, which has impacts because organization exists elsewhere in the NRPM. It modifies the structure of the transfer policy section. Pretty much have to do that because we're adding a paragraph. So we change the structure a little bit to allow a place to put a paragraph in and change the section headers.
And the main goal is it changed the policy for designating recipients. The original policy proposal 2008-6, which was the transfer policy adopted by the AC as a result of community feedback and their action, the policy for 2008-6 incorporated into the NRPM had a sunset clause that caused that particular transfer policy provision to expire after three years.
The board's action removed that sunset clause. It required the resource holder and recipients to be in the ARIN region. It changed the applicability from IPv4 only to all numbering resources.
Next slide. The staff assessment and legal assessment that came back. The legal assessment: the proposed policy significantly reduces legal fees and expenses for ARIN. Since this policy as completed can be amended or repealed at any point and sunset provisions have not been routinely utilized to require reevaluation of controversial policies, the absence of the sunset provision is legally preferable.
Staff changes or concerns: it was noted that the definition of organization could have impacts that's unforeseen. And there was some question about the transfers of /24s and /23s because of the text that was contained in 2008-6. There is a little bit of resource impact to make sure we have the procedures appropriately accommodating for the addition of the word "organization." It was intended that this policy could be implemented within 90 days of adoption. So not a huge issue, but one that needs to be paid attention to. We did get a little bit of feedback.
Next page. PPML discussion: So let's see, none in favor, 17 against, 208 posts. Sometimes new policies create a lot of discussion. This one generated ample discussion by the community. 208 posts from 43 different people. Some of the comments were: that we remove the sunset clause and every policy really has a sunset clause implicitly built into them; that there was consensus that we probably should be exclusive to IPv4; that any policy that allows a market by allowing peer-to-peer transfers is a problem; and opposition, because we exercise the emergency powers where the normal process might have sufficed.
Opposition due to the fact that the term "organization" is being defined and that wasn't done as a stand alone process. And people totally lost and trying to figure out whether or not this applies to them changing Internet providers.
So quite a bit of discussion. I guess there's been a lot of discussion between the AC and the Board as well on this. The Board acted because we recognized that 2008-6 had fundamental legal issues that constituted an emergency.
And we've received a lot of feedback. And it is based on that feedback, it's the sense of the Board that we did include more than absolutely necessary to address those issues. That's not to be unexpected. This is the first time we've exercised the emergency policy process of the PDP. And we're going to learn from that, as we always do. What we really want to do is focus the discussion of 2009-1 on the merits of the policy proposal, and based on that that feedback will go to the Board and the AC, because those items that are in 2009-1 still need to be discussed whether or not we get a recommendation from the AC to include them or remove them is based on the feedback from the community here. So I guess that's the end of the discussion. If you could go back to the summary slide for 2009, right there, I will open the microphones up for discussion. So microphones are open for discussion on 2009-1.
MR. DELONG: Owen DeLong, ARIN AC. I think the removal of the sunset clause is probably the most glaring problem in my mind with 2009-1, because a lot of the community that I think accepted 2008-6 did so on the basis that we had to try something but we weren't sure that open transfers were necessarily the right thing. And so we wanted that sunset as kind of a safety valve where we didn't have to go back and get strong community consensus to repeal the policy, but instead the experiment needed really strong consensus to get continued. And removing the sunset really tipped that balance.
MR. CURRAN: Understood. As written, are you for or against 2009-1?
MR. DELONG: Absolutely oppose 2009-1 as written.
MR. CURRAN: If the sunset clause was restored and not struck by 2009-1, would you be in favor of it?
MR. DELONG: You actually need to restore the sunset clause, you would need to remove the definition of organization and you would need to -- what was the other change that was bad? Oh, yeah, limit it back to IPv4 in order for me to support the policy.
MR. CURRAN: Thank you. Okay. Right microphone.
MR. WOODCOCK: Bill Woodcock speaking for myself, not for the board. I was obviously one of the people who worked on drafting the 2009-1 diff from 2008-6. And I think we've all had some time to sort of think about this and get input and track things down.
Personally, I don't care one way or the other about the redefinition of organization. I think, in fact, that may have kind of stemmed from a misunderstanding of staff requirements. So I think you might find that people on the Board are pretty well willing to listen to arguments against that one.
The v4 versus all resources. I sort of feel like it's bad policy to make resource type specific policies. Sort of like saying, well, something only applies to IP addresses that start with an odd number or something like that doesn't really make that much sense, particularly if we're going into a period of using v6 more. But, again, it's not anything I care that much about. It just seems shortsighted.
On the matter of sunset clauses, I think sunset clauses by their nature are just -- are really, really poor idea. It's trying to force your will on the people of the future who will probably have their own reasons for doing things, and it never really works. The people of the future will probably just see you as shortsighted if you try and force them to do something they don't want to do. And if they do want to do it, they'll do it themselves.
MR. CURRAN: Okay. Bill, I guess I -- I'll ask this even though it might be redundant. As written, are you in favor of 2009-1?
MR. WOODCOCK: Yeah.
MR. CURRAN: But you'd be -- if I understand you, you'd be in favor of it even if the organization and the IPv4 specific aspects were dropped?
MR. WOODCOCK: Right. But I would not be in favor of it if the sunset clause went.
MR. CURRAN: Thank you. I'd like to remind everyone. We're going to try to do three minutes at the mic for everyone's comments so we have a chance to have everyone speak. So rear microphone, go ahead.
MR. KARGEL: Good morning. I'm Kevin Kargel with Polar Communications out of North Dakota. I wanted to comment on this. I think this is probably the most important issue here at the conference. I first want to compliment the authors of this policy. I think it is well written. It is concise and quite easy to understand. Having said that, I oppose the policy proposal as written. There are a number of issues. I'm going to try to fit them into the three minutes here.
It is stated right in the policy that resources are not sold. However, guaranteed exclusive license to something in exchange for monetary compensation to me sort of is the definition of sold. And so I think this defines and allows IP addresses to be sold no matter whether or not the policy says that it's not the intent.
MR. CURRAN: Quick question, are you referring to the original 2008-6?
MR. KARGEL: I'm quoting out of the 2009-1 transfer policy on page 6 of the discussion guide.
MR. CURRAN: All right. 2009-1 materially doesn't change the language that 2008-6 adopted allowing such transfers. So I just -- I want to be clear. Even if this policy proposal were withdrawn, you would still have the transfers you're talking about in the existing NRPM.
MR. KARGEL: Correct.
MR. CURRAN: Continue.
MR. KARGEL: And I think that's another issue I think needs to be dealt with.
MR. CURRAN: I wanted to be sure.
MR. KARGEL: Okay. The other issue that is part and parcel of the same whole thing is that transfers, peer-to-peer transfers remove IP addresses from fair distribution with the rest of the community, and I think that stands to create great evils and troubles for the community. I'll step back. It looks like we have a question from the table.
MR. CURRAN: Yes, Cathy.
MS. ARONSON: Hi. We have a question from the audience. Steve Feldman from CNET Networks says question for the board: What was the specific legal risk that 2009-1 is attempting to fix and how does 2009-1 do that?
MR. CURRAN: I will actually -- unless, Paul, you want to answer. I will answer that. It's not that we didn't expect such a question, so might as well answer. Recognize the 2008-6 and 2008-2, two transfer policies were both under discussion, both undergoing rapid change at the same time. The Board was not able to ensure that all the legal review of both changing policies was happening at all steps of the changes. When we received the resulting policy in the review that occurred, we realized that the policy language as actually given to us had transfers from Party A to Party B, not going through ARIN. That turns out to be incongruous with our existing legal filings and existing legal doctrine that we've used in talking about IP address space. And that's a problem.
Additionally, there was an implied ability to transfer both in and out of region, which was not felt to be legally supported. So those two items were changed specifically in 2009-1 to address the legal risks contained in 2008-6. I hope that helped you, Mr. Feldman. Write back in if you have another question.
I want to go to the far mic.
MS. AZINGER: Marla Azinger, Frontier Communications. I support the proposal as it is, but there are a few things. I would prefer to see it only be IPv4. That's shortsighted. I guess it's shortsighted, but I believe it's really only necessary for v4.
The ORG definition. I don't have a problem with it because that's how we've been operating. When we buy out companies, we consolidate. We do it correctly. Yeah, everybody probably should have been doing that, but they haven't. So I hear the concerns.
So I would support actually taking that out of this and making it a completely separate issue and maybe grandfathering everybody now going back, that they don't have to do it, but moving forward, you know what, if you're going to run a business, do it that way. So I would support taking that out and grandfathering, possibly, all the other older companies.
The sunset clause, I think it's a bad idea. I am glad you guys took it out. It's saying you can predict the future. And as much as I like to think I can predict the future, you can't do that. So it just doesn't support anything, honestly.
MR. CURRAN: Center front mic.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. Two different aspects of this that I want to comment on. The first one is if we go back in history, I believe -- this is off the top of my head -- the policy proposal 2007-21 and 22 were remanded by the Board to the AC; one over confusion of a single word, and one over the fact that the policy changed from what was discussed on the mailing list to what was presented in the meeting.
And out of an abundance of caution, the Board felt that it was important that the community all be on the same page with respect to these. I am very concerned here, because what I have heard is that there are significant flaws with 2008-6, but that the Board has adopted it. So if we do not move forward with this policy we have adopted something with significant flaws that the community has not discussed. So I'm very concerned that those issues weren't returned with 2008-6 to be corrected before we implemented a policy. Regarding this fix now, sort of after the fact, I don't support any of the items in the fix except for the fact that the transfer should occur through ARIN.
I believe that was an omission in the original policy. I believe it's very important to us legally. I don't think that goes against any of the community intent with the original policy. So I absolutely support that. I don't think the community supported any of the other things. And some of them, particularly the definition of organization, could really cause some significant trouble in how we implement policy going forward.
MR. CURRAN: Thank you. I don't know if any Board member wants to respond regarding why this one did not get returned but instead got adopted and 2009-1 introduced.
I should, okay. So let me tell you. Basically put, and it's not a very difficult thing to understand, the Board has also been operating for some time under a concern that there is an absence of clear guidance regarding how organizations -- how addresses that aren't being used that are out there that are not being used by anyone, and we have an obligation for efficient use of the entire address space, actually getting back into use, whether that's redeployed through reclamation or redeployed through an open transfer policy, some mechanism. The fact that we didn't have a tangible policy that moved in this direction is a risk to the organization, because the Board has to follow the incorporation of the organization, which says we have to do something to encourage efficient use.
We actually chartered the AC, as you know, with a directive about a year and a half ago, coming on two now, that says we need you to look at mechanisms for this and come up with an answer. It was a fear that given the length of time it took to get to this point that we would be remiss that if we sent this back to the AC and it took another six months or a year and that legal action in between for our failure to act could endanger the organization. That's why.
Okay. Far right microphone.
MR. SEASTROM: Rob Seastrom, ClueTrust and I'm also on the ARIN Advisory Council. And I'd like to expand a little bit on what John just said about the efficient use.
As part of my duties on the ARIN Advisory Council I have been to a couple of trade shows for outreach and talked with folks specifically in the D.C. area and government types. There is widespread misconception about what we could be doing in order to ease the IPv4 exhaustion problem. And a lot of folks in positions of power seem to be under the impression if we were to just go out and reclaim whatever we could get our grubby little hands on from folks who aren't using them, that the situation would be completely solved. And, obviously everybody in this room knows that's not the case.
But if we don't have a transfer policy in place, we give the impression of not having done everything that we could possibly do to mitigate this problem. And there are folks who believe that we should not be the ones who are making this policy; that we should not be doing self-governance; that they believe that this would be a process that would be better served by being run by, for instance, the ITU. And by giving that impression that we're not doing everything that we possibly can, we are bolstering their argument. We're giving them ammunition. I am generally in favor of 2009-1, although I share Leo's and others' concerns that the organization definition is a step away from goodness. Thank you.
MR. CURRAN: Thank you. Center, right up front mic.
MR. SCHILLER: Jason Schiller, UUNET/Verizon, and I'm also on the ASO AC, NRO NC, but I'm speaking on behalf of Verizon at the moment.
Generally I support the aims of what the Board is trying to accomplish, and that is making sure that transfers occur through the ARIN process, making sure there's justified need, making sure documentation is accurate and making sure that documentations don't occur between regions. However, I'm opposed to the policy as written. I think the definition of organization is a significant change, that will significantly change how ARIN operates today, that will negatively impact Verizon as well as a number of other large companies.
In our case we have three fairly separate business units: telecom, wireless, and business; all with three very separate networks, all with three very separate IP allocation assignments, management, routing. For those to be considered a single organization would be a significant challenge. And I suspect that there are many other corporations that would fall into the same boat.
MR. CURRAN: Understood. Thank you. Far right microphone.
MS. ARONSON: Hi. This is a question from the community forum. kc claffy: What does it mean to, quote, not be legally supported to transfer in/out of regions. Transfers aren't legally supported at all, right? Can the Board please post the actual legal reasoning issue rather than 30-second John Curran hand wave.
MR. CURRAN John Curran: I saw the comment. Luckily it's very convenient. The fact of the matter is that the ARIN Board gets advice from counsel and it’s privileged. And the reality of the circumstance is that you don't often take your advice from counsel and post it publicly because sometimes that's the detriment to the organization. It's the board's judgment given advice that the organization would be endangered by this and it's the board's determination and fiduciary duty to actually make that determination. So, alas, we're not posting the legal arguments I regret to say. The Board is doing the thing to protect the organization.
MR. BRADNER: KC, this is Scott Bradner. Two points there. One is transfers aren't legal already. Well, actually, 2008-6 makes them enabled transfers. So it's not a question of whether transfers are enabled or not. They are. The specific legal advice that we got is attorney-client, sure, as you just stated, but just to make clear that we already last year enabled transfers.
MR. CURRAN John Curran: Good point. Thank you, Scott. Center front.
MR. WILLIAMSON: David Williamson, Tellme Networks, a Microsoft subsidiary. I'm against 2009-1 as written. I think I would support a new proposal that was very narrow and focused on fixing the legal forms, specifically just said, you know, include ARIN as part of the transfer process. I think that would have been a wiser choice. At this point this policy bites off more than what is really intended. The redefinition of organization is specifically one that causes a lot of pause. I think other people have already stated it fairly well. But I think the definition as written in 2009-1 flies in the face of operational reality on the ground, and in ways that is entirely unworkable.
MR. CURRAN John Curran: Thank you. Far right microphone.
MR. ALEXANDER: Dan Alexander, ARIN AC. In 2008-6 one of the phrases that was included in the language was that resources would be received under RSA, and that was one of the items that was removed in 9-1. Although, when you read through the language of 9-1, it can almost be assumed that that's an implied situation. I just wanted to make sure, was there a reason that was removed?
MR. CURRAN John Curran: The approach of making an important change necessary to the organization by rewriting a paragraph from scratch leaves a lot to be desired, and in retrospect is probably not the best way to go about it. There's a lot of wisdom gathered from the lesson of 2009-1. I don't think it was intended that the RSA requirement was dropped in any way, shape or form. But because of how this came about, it's subject to risks like that, so we obviously will make sure we correct that based on the feedback.
MS. NOBILE: John, that particular -- I've spoken with Dan about this. Leslie Nobile with ARIN. It's ARIN's business practice to -- for anybody coming to ARIN for a transfer to sign an RSA. You cannot conduct a transfer at ARIN from one party to the other without the new party receiving the resources signing an RSA. So it's a given. It's a business practice. It won't go away. It doesn't have to be written into the policy.
MR. CURRAN: Agreed. It's just that we lost the explicit nature of the prior policy in the rewrite. And whether it's desirable to make it explicit or not, it may not be necessary, but the community certainly understands it better if it's explicit. Thanks.
MR. OBERMAN: Kevin Oberman, ESnet. This redefinition of organization raises interesting thoughts in my mind. We are a network that is funded to provide connectivity to the United States Department of Energy. That's federal government. That's a mighty big organization. The idea of having to deal with address assignments with, say, the folks in the military and the folks in Washington and all those folks gives me some queasy feelings. However, we are legally part of the University of California. So maybe it's the folks down in Berkeley we need to deal with, down the hill from where we are, or maybe the folks in Oakland at the Office of the President.
It gets very strange, very confusing, and particularly in mind of the fact that I'm currently trying to recover some very ancient /24s that were assigned long ago before the word "assigned" was defined and long before ARIN existed, one to a Department of Energy office that no longer exists and one to a high school in Fremont under a K-12 outreach program years ago, this definition of organization makes me wonder if this is suddenly going to become flat-out impossible, incredibly difficult, or in fact a no-op. I'm not really sure.
MR. CURRAN: So I guess as written, with the definition of organization in it, you would be opposed to this policy, obviously.
MR. OBERMAN: I'm not sure what the definition of the policy means to me because I'm not sure whether I am U.S. government or if I am State of California or if I'm the University of California -- nonetheless, my gut feel is I don't really care for this definition.
MR. CURRAN: Got it. Thank you. Microphones remain open but we're going to close them shortly. Far left mic.
MR. POUNSETT: Matt Pounsett, Afilias. I guess I could live with 2009-1. I'm not strongly in favor of it. That opinion would change, though, with I think fixing the organization definition somehow. I can kind of -- I think I can kind of see what the aim was behind creating that definition. But there seem to be a lot of problems that it creates as well. So I think it would be important to either remove or change it significantly in order to fix those.
MR. CURRAN: Okay. You said you're sort of -- you can live with 2009-1 but that would change if "organization" was changed. I want to be clear.
MR. POUNSETT: Change for the positive. I would be much more in favor.
MR. CURRAN: You can live even more.
MR. POUNSETT: Yes.
MR. CURRAN: Okay. Microphones remain open. Far side.
MR. LEIBRAND: Scott Leibrand, ARIN AC. I support most of the comments about the changes defining -- existing definition of organization just doesn't work. I believe it's best to go back to v4 only for transfers. We can go back and do a cleanup to make v6 and v4 policies more similar across the board. I don't think this emergency policy is the place to do such cleanup.
Removing the sunset clause to me is fine. If we were to do a sunset clause, I think it was intended to be three years from IANA depletion. Three years from now is too early. Rather than go into the whole thing, I'm happy with what the Board decided to do there.
With regard to the organization definition, one thing that we haven't discussed that would be a possible alternative to removing it entirely, which I'm fine with, I would also be fine with putting it within the transfer section. Defining it simply for purposes of transfer would be much less onerous than defining it for the entire NRPM.
MR. CURRAN: Cathy, do you have a comment?
MR. CURRAN: Affiliation?
MR. CURRAN: Okay. Thank you. Center rear mic, yes.
MR. WEIL: Jason Weil, Cox Communications. I also don't agree with the definition of organization. There needs to be more thought and more definition and discussion around that definition.
MR. CURRAN: Okay. Cathy, go ahead.
MS. ARONSON: I have a question from Joe Maimon at CHL. How soon could 2009-1 be amended to remove the organization redefinition and the IPv4 application and separate it into other proposals? Were this course taken, could this be adopted soon enough to satisfy the BOT sense of urgency?
MR. CURRAN: Yes, remarkably quickly. The BOT has already considered alternative language that produces things that obviously didn't need to be in 2009-1 the first time.
Far left mic.
MR. HOWARD: Lee Howard, ARIN Board of Trustees and Time Warner Cable. Some people said maybe they would oppose this less if we reverted to only covering IPv4 resources. But 2008-6 was not specific to IPv4. So I want to make sure I understand the feedback from the community.
MR. CURRAN: Okay. Bill?
MR. WOODCOCK: So I believe the 2008-6 said in its title IPv4 emergency transfer. So I think that was rather explicit in the title, not the text.
MR. CURRAN: That's correct. It was in the title, not the text. So it was intent, but the question whether there was language was operative.
Okay. Center front.
MR. WILLIAMSON: David Williamson, Tellme Networks. I've already belabored the point of organization and definition I think, but there's been several ideas brought forward about other ways to define it. Scott's idea is interesting, but I think still unworkable. Just for an example. My own organization is a legally separate but wholly-owned subsidiary of a very large corporation. I don't intend to participate in the transfer market particularly, but if I desire to do so, under Scott's redefinition of organization, I would be operating under the auspices of Microsoft Corporation. I have no idea what their specific IP resources look like.
And one of the points, the nearest manager in common I have with the people who do Microsoft IP management is Steve Ballmer. So it's not exactly convenient in any sort of operational or business manner. Now, clearly, I probably need to go to Microsoft for my IP needs rather than the transfer market, but, still, I think that's just an unworkable definition.
MR. CURRAN: Understood. It would pose a unique opportunity, but understood.
MR. ALEXANDER: Dan Alexander, ARIN AC. Of all the differences that we're discussing, I think the organization one's been pretty clearly stated. But the one thing I'm curious, and I pose this to the room, the two other differences in regard to the sunset clause and the limitation to IPv4 only, are there any non-AC, non-board members in this room that have strong feelings? If they do, I'd like to hear it from the mic.
MR. CURRAN: Yes, to the extent that you haven't spoken on this and you'd like to, please find the microphones. They remain open. So keep going. Far left.
MR. SPRINGER: John Springer, Inland Telephone. I support 2009-1 as written. I would support it more with the organizational definition stuff cleaned up.
MR. CURRAN: Thank you. Center front.
MR. SCHILLER: Jason Schiller, UUNET/Verizon. I just wanted to support David Williams in his difficulties about managing IP addresses. I don't think it's all that unique. I suspect we would have a similar problem.
MR. CURRAN: Got it. Okay. I'm going to close the microphones shortly. If you are going to be participating, come up to the mics. Far side. Yes, Cathy.
MS. ARONSON: I assume we already have kc's affiliation, so even though she didn't send it, it says: Since the Board has now embedded itself into policy making, can Board members please post COI disclosures this week with respect to address ownership transfers, privatization underneath their bios on the ARIN website.
MR. CURRAN: Wonderful question. I guess I'll address it already and say that all of the ARIN members have to -- all the ARIN Board of Trustees members have to do an annual disclosure form that's thorough, very complete, describing all aspects. And that's shared with all the Board members in a review session, so we all are aware of potential COIs. The Chairman of the Board and the CEO of the organization, we're responsible for highlighting any potential conflict-of-interest situations that we see that occur at any point. And, in fact, the Board of Trustees themselves, each trustee, is to recuse themselves if a conflict-of-interest situation emerges.
We're very comfortable with our COI disclosure practices and how well they've worked to date. And those forms, however, are Board of Trustees material, obviously, because otherwise we wouldn't be able to have -- no one wants to go to a level of disclosure such that would be onerous to everyday life.
Do you want to speak?
MR. BRADNER: Just as a point of information, counsel reminds me predominantly people are thinking about the applicability of policy such as 2008-6 and 2009-1 with respect to legacy address space. It is -- the Board has spent a lot of time making sure that disclosures in this area are remarkably clear and lucid. And there is no -- you can see that Board of Trustees have to exclude themselves from anything that would provide them a beneficial interest through policy.
The minutes of the Board meetings, the discussions and the votes, including the abstentions, are all on the record. So probably while we won't be posting the individual forms, we also would say we're very confident that we're keeping the members' interests in front of the Board members' interests. Over there.
MS. WOOLF: Suzanne Woolf, ISC, no longer ARIN AC, so it took me a minute to realize that I could speak as neither Board nor AC.
I oppose 2009-1 as written. At the moment I want to focus, though, just on the sunset clause issue. I understand the argument that a sunset clause is a no-op or is a dangerous precedent, or given that it's a change from previous ways of doing business, there's a concern there. But the reason for proposing it was a deliberate effort to say we are operating in very uncertain waters here, and we know that. And we want to have some idea what we're going to do and have some path forward that people can take, should they desire, if it turns out that not only that there's a -- it's easy to handle the case where there's a consensus that things are not working out. What's harder is handling the case where there is no such consensus and doing the risk analysis around the situation we're in then.
MR. CURRAN: Understood.
MS. WOOLF: I understand the argument against the sunset clause, but that risk analysis is extremely important. What's going to happen without it?
MR. CURRAN: So with this striking the sunset clause, as it does, are you in favor of 2009-1?
MS. WOOLF: With the sunset clause put back? I share the concern about the organization definition also. With those changes, I could support it.
MR. CURRAN: Thank you. I am going to be closing the mics shortly. Please approach the microphones if you wish to speak on this policy proposal.
Okay, far right.
MS. ROBERTS: Lea Roberts, Stanford University, ARIN Advisory Council. I've been struggling with how to phrase what it is that I want to say here, so excuse me if I get kind of clumsy. But I think as someone who has been doing the Internet stuff for a long time, the idea of a transfer policy really was hard for me to accept. It took quite a while for me to come around to the fact that the world ain't like it used to be.
We're in extraordinary times in IPv4. The things that used to work no longer work. And something needed to be done. I don't feel strongly about the sunset clause. I do agree that folding in the organizational change -- the change for the definition of organization was probably not really necessary for this particular exercise of the emergency power. And I also feel -- let's face it, there are IPv4 transfer policies coming in in all the regions, and certainly ARIN has to have one. I totally understand that. But I do think expanding it beyond an IPv4 transfer policy is probably more than necessary for an emergency action.
MR. CURRAN: Microphones are closing. Three, two, one. Microphones are closed. Please don't approach the queues. Last two speakers.
MR. SCHNIZLEIN: John Schnizlein, Internet Society. I think the Board was right to think that it's now urgent to get a transfer policy in ARIN. There is a risk that not dealing with the pending future, when you have no more free addresses to hand out, will create a disaster. So I think that fear is well founded.
I think that the idealistic concerns about avoiding treating addresses as property, idealistic concerns about policies applying to all resources the same way and probably a dozen more are getting in the way of the primary responsibility, which is keeping the records straight. And I would urge that everyone in the community focus on what really matters. In particular, we do not have a problem with IPv6 addresses that would pose a need for transfers.
There are enough that we're not going to run out. That's why we're trying to make that change. So adding in v6, while it may have some elegance, it is avoiding the reality that this transfer stuff has to do with the circumstance when you run out. And we're not going to run out of v6, and we shouldn't pretend so.
MR. CURRAN: Okay. Thank you. And final speaker, center front.
MR. DELONG: Owen DeLong, AC. I'm not going to comment further on the policy. I think I've pretty much said everything I needed to say.
I would like to request that the Chair help us, at least me as a AC member, gather some additional information in that I would hope you would get a show of hands on the individual -- I think there's about seven changes to 2008-6 incorporated in 2009-1, so we can tell which ones the community likes and doesn't like. Thank you.
MR. CURRAN: Wow. So the challenge, Owen, obviously is a show of hands is something we do after we know we've had adequate discussion of the pros and cons of a given issue.
While 2009-1 has touched on some of these, the pros and cons of "organization" definition and how it could be phrased and where it could be alone could be a whole one-hour discussion. So my concern is that we can have a show of hands, but it would not be representative of any particular single decision or single thought of this group.
MR. DELONG: Talking maybe a show of hands like should 2009-1 include the organization redefinition? Should it include the reduction of things to -- or the removal of the IPv4-specific nature of 2008-6, et cetera, et cetera.
MR. CURRAN: Understood. This policy is one that, of course, is subject to the board's review as well as the AC's, because the AC may have to deal with picking up some of these matters. I can see the value of the AC having the pulse of the room on a select list of topics and hope we've had enough discussion that the select list is representative.
So I will say we can have -- let's have a show of hands regarding whether or not there should be a single definition of "organization" in the NRPM. Would that suffice for your purpose? Yes. Scott.
MR. BRADNER: Just a process point. I don't think that would be the relevant -- the correct question. I think the correct question is what is put into 2009-1, do you support that or not, not the definition of organization, not whether this should be a single definition or not, just what's in there now, do you support it or not.
MR. CURRAN: Understood.
Would you support the definition of organization contained in 2009-1 as written? I understand. Okay. So the question -- the first of many such questions. The first of many such questions is a poll, is going to be a show of hands, and this includes remote poll for remote participants, regarding whether or not you would support the definition of organization in 2009-1 as written. A vote of yes is a vote to retain such a definition. A vote of no is to have it removed.
I'm going to ask for a single show of hands. I'm waiting for our tabulation system to get in place. Yes. Yes. Remote participants as well, you may participate.
On the matter of policy proposal 2009-1, do you support the definition of organization staying in as written? Raise your hand nice and high.
SPEAKER: Clarify (inaudible).
MR. CURRAN: As written in the policy proposal. Nice and high.
All those opposed to retaining the definition of organization as written in 2009-1. Raise your hand. Nice and high. This includes remote participants. There's a voting room. Find yourself there and mark away. Very high. Very high. Nice and high.
Okay. Thank you. They're busy doing the tabulation now.
Okay. On the matter of 2009-1, transfer policy, are you in favor of retaining the definition of organization? We have -- out of 112 people in the room and 31 remote participants, we have a total of 0 in favor and 68 total against retaining the definition of organization. This will be supplied to the Board and AC for their consideration.
The other topic contained in this discussion is the sunset clause. Policy proposal 2009-1 removes an existing three-year sunset clause from the open transfer policy that was adopted in 2008-6.
So, as written, 2009-1 removes the expiration, the three-year sunset clause. There's been a lot of discussion about having a sunset clause for this open transfer policy. And I guess it would be helpful to the Board and AC to see what the thought of the people in the room and remote participants would be.
So I'm going to ask for a show of hands. I'm going to ask for everyone in favor of retaining. I'm going to ask for everyone in favor of supporting 2009-1 in removing the sunset clause. A vote of yes says that we'll go with 2009-1 as is and the sunset clause will be removed.
A vote of no says you do not want to go with 2009-1 and its removal of the sunset clause and that you wish to have the sunset clause retained as it exists. A vote of yes supports 2009-1 as written and removes the existing sunset clause.
So we will have a show of hands on this. All in favor of supporting 2009-1 as written with its removal of the sunset clause raise your hand. Nice and high. Remote participants, this is you, too.
Nice and high. This is the exercise part of our program. Part of the Healthy ARIN initiative. Okay. Thank you.
All those opposed to supporting 2009-1 and its removal of the sunset clause, all those opposed to the change in 2009-1, raise your hand now. This includes remote participants. Okay. Thank you.
We need that old computer background noise of tabulations clicking and whirring.
And the results are being calculated now.
On supporting policy proposal 2009-1 and its removal of the sunset clause, the number in favor of that, 24 in the room, three remote participants. Those against the removal of the sunset clause, 19 in the room and one remote participant.
Again, those in favor of supporting 2009-1 as written with respect to removing the sunset clause, three remote and 24 for a total of 27; and those opposed, 19 in the room and one, for total of 20.
Owen, you raised the issue. This will be provided of course to the AC and the board. You raised the issue that there are seven items you thought that maybe would be interesting. I know of two that we've discussed in detail and we've polled them. What other ones do you believe we've missed?
MR. DELONG: IPv4.
MR. CURRAN: Whether it's worth restricting the policy -- whether we support 2009-1 with respect to its IPv4 nature? We have to be careful, because there's an ambiguity of the existing proposal with respect to the title containing IPv4 only and the text not. 2008-6 is ambiguous for that matter.
MR. DELONG: There's certainly a belief by the majority.
MR. CURRAN: Microphone.
MR. DELONG: Sorry. Owen DeLong, ARIN AC. I certainly perceive that there's belief or perception by the community that 8-6 was applicable only to IPv4 and intended to apply to IPv4 only.
It is very clear that 2009-1 implemented as written would expand that scope almost certainly.
MR. CURRAN: Okay. So what you would like to know is you would like to know whether this community supports 2009-1 and its expanded scope or whether or not people are against 2009-1 to go to the more limited scope to v4.
MR. DELONG: Correct.
MR. CURRAN: Is that correct? Okay. Mr. Darte.
MR. DARTE: I would be interested in someone out there who has access to the policies, read the title of 2008-6 exactly as it exists.
MR. CURRAN: From the archive it says IPv4. We can pull it.
MR. DARTE: What is the exact title, if you will?
MR. HOWARD: (Inaudible)
MR. DARTE: Start again.
MR. HOWARD: Emergency Transfer Policy for IPv4 addresses. I looked it up after I asked my previous question. Lee Howard, Board of Trustees.
MR. DARTE: That doesn't seem ambiguous to me.
MR. CURRAN: Okay. Cathy.
MS. ARONSON: We have a comment from the online post. Ed Lewis and kc both said: I think the count against the removal of the sunset clause 2009-1 online was given by Curran as one but there were two.
So in the hands-up room, I guess there were two people against.
MR. CURRAN: I'm going with the tabulation engine, but we'll check it afterwards.
MS. ARONSON: They are saying there were two as there were two.
MR. CURRAN: Mark.
MR. KOSTERS: If you're in the room and vote, vote quickly because the answers come back. You want your answers fairly quickly. And the results were kind of streaming in slowly.
MR. CURRAN: Okay. The instructions for the remote room is type briskly and efficiently to make sure your vote is counted. So noted.
We can make sure that the update is provided to the Board and the AC. Okay. We had clarity from Owen. I was going to do another show of hands, but relevant to that --
MR. BICKNELL: I just have a question on that clarity. Leo Bicknell, ARIN AC. My understanding is 2008-6 has been adopted. How does ARIN staff intend to implement it, IPv4 only or all resources?
MR. CURRAN: Implementation of 2008-6 was intentionally deferred by the Board subsequent to this matter.
MR. BICKNELL: I'm saying if there's ambiguity as to what it did, it's been adopted, that's not a policy process --
MR. CURRAN: Will be implemented for IPv4 only. But, to be clear, because it's not in the policy text, it's going to be an implementation. It doesn't necessarily carry over into the text when it's put into the NRPM, is the difficulty. Far end, Cathy.
MS. ARONSON: That brings up a question for me. Was that in the staff assessment that it was ambiguous for 2008-6? Because it seems like if it had been, we probably would have fixed it.
MR. CURRAN: The texts of these were changing fairly rapidly. I do not believe that was in the staff -- the latest staff assessment was not necessarily done after the latest change to the text by the AC. Similar to the issue we had with the legal comments.
Yes, far left.
MR. POUNSETT: Matt Pounsett, Afilias. The title we've been talking about is not just the title of the proposal; it's the title of the section that's created in NRPM. So there's no way that's ambiguous. It applies to IPv4 only.
MR. CURRAN: I thought it was in the title of the proposal. But if it's in the section, then very plainly it will be implemented that way.
MR. POUNSETT: We need to verify that.
MR. CURRAN: We removed the header. Understood.
Microphones remain open. So, Owen, if I understand the matter you want, you'd like to know how many people support 2009-1 and its non-restriction of numbering resources for transfer as written versus people against the 2009-1 approach.
Yes, Aaron Hughes.
MR. HUGHES: I don't believe the community has enough information to comment on it. Nobody knows what the impact of applying this to every resource is. We haven't discussed transferring ASNs, IPv6, 32-byte ASNs. There's not enough community information to even have a conversation about this.
MR. CURRAN: Discussion. Microphones are open. Have we had enough discussion of that aspect? Yes, far left side.
MR. LEIBRAND: Scott Leibrand, ARIN AC. I think the fact that we don't quite know what it would do to do this is a reason to not do it. But to the point of order of do we have enough information to have a poll on this, I think we do. I think a lot of people are going to be informed by the lack of knowledge of what it would do in their decision on that.
MR. CURRAN: Okay. Would it help -- Mr. Hughes, would you like to respond?
MR. HUGHES: I'm sorry. I meant it's impossible for anybody to understand the impact until it's been discussed. There is no way you can make a vote on this without actually researching the data.
MR. CURRAN: Okay. We'll take the far left, then Bill, then myself. Far left.
MR. POUNSETT: Matt Pounsett, Afilias. To kind of respond to Aaron, because what you're saying is absolutely true, my approach to this particular show of hands would be we haven't discussed this. So there's no way that we could allow 2009-1 to do this.
MR. CURRAN: Bill.
MR. DARTE: Bill Darte. I believe that we should have this show of hands associated with this, because it's clearly -- 2009-1 has changed the character of 2008-6. 2008-6 was clearly IPv4 only. 2009-1, for whatever implications it is, is more than IPv4 only. And so I think that's totally informed at that point to have a show of hands of whether you support the expansion or not.
MR. CURRAN: Okay. Myself and then the front center and then Cathy.
All I wanted to point out is that, as Aaron notes, we haven't necessarily discussed the implications of an open -- of an open resource type approach, IPv4, v6, ASNs.
I don't know if it would help the matter to know that the Board in its discussion of 2009-1 and what it might do to date has realized that the scope went from v4 only to a greater scope, and everything that we're discussing in fixing 2009-1 restores the original scope.
So to the extent that someone thinks an expanded scope, this kind of side effect is desirable, they would really need to find a microphone and argue for it so we could have the discussion that Aaron's talking about.
Center front and then Cathy and rear. Go ahead.
MR. SCHNIZLEIN: John Schnizlein. I think the way you phrased the question when you called the question is really important here. Because the phrasing of in favor of the way it's written ends up having negatives looping all over themselves.
I think the way you should ask the question is: Who favors expanding the scope from v4 only to other number resources. That way we don't get confused about what the vote's about.
MR. CURRAN: Understood. Far left. Yes, Cathy.
MS. ARONSON: I have another audience comment. I guess his name is Joe Maimon from CHL says: Perhaps to clarify that opposition to the clauses includes preference for separation into other proposals and discussions of those clauses.
MR. CURRAN: Yes, most certainly. As noted, this is likely to be heavily realized with pieces going back to the AC, which would probably have consideration and public discussion at a future time.
The question is whether or not we've had enough adequate discussion now to poll the community on some of these items before they're broken out as opposed to after.
MR. SCHILLER: Jason Schiller, UUNET/Verizon. I'd like to ask for clarification from the Board if limiting the scope of this proposal would still address the legal concerns that they had.
MR. CURRAN: The legal concerns are independent of the scope, IPv4 versus numbering resources. It was a side effect of addressing this.
So I do not know whether or not we have adequately discussed this matter. I have heard colleagues from both sides to say we have not addressed this sufficiently to have a discussion regarding sustaining the language in 2009-1.
I actually am going to ask Mr. Bradner. Your thoughts.
MR. BRADNER: I believe the suggestion just made is just right, that the question is whether there's been -- whether there's support for expanding beyond v4, I think that's a perfect way to phrase it.
MR. CURRAN: Okay. Setting aside for a moment 2009-1, existing policy has a scope for the open transfers of being v4 only. The question on the table is: Is the community in favor of expanding the scope of the open transfer policy beyond IPv4 only? That would be the question I would poll. Does anyone object to the phrasing of that?
MR. CURRAN: Is the community in favor of expanding the scope of the existing IPv4-only transfer policy to all numbering resources? Comments on the question?
MR. TEMPLIN: Yes, more for clarification.
MR. CURRAN: Okay.
MR. TEMPLIN: Pete Templin with Texlink Communications. I believe I heard a comment earlier, and this ties in with your statement right there as far as current policy. And I just want to get some clarification. 2008-6, is it accepted?
MR. CURRAN: Yes.
MR. TEMPLIN: Is it implemented?
MR. CURRAN: No.
MR. TEMPLIN: What's the acceptance state?
MR. CURRAN: It is accepted, implementation was deferred by the Board because of the interaction with 2009-1. It is in the NRPM.
MR. TEMPLIN: I don't see it in this document which was included in our folder.
MR. CURRAN: Ah, it's because of the timeliness of the matter. It's possible it did not make it in.
MR. TEMPLIN: Okay.
MR. CURRAN: Lee.
MR. HOWARD: I would like to clarify that response. Lee Howard, Board of Trustees. We have not included it in the NRPM yet because it has not yet been implemented. We did discuss this with staff.
MR. CURRAN: That's right.
MR. HOWARD: And we decided it would be more confusing to the community to include it in the policy manual before it was actually the policy that was implemented.
MR.CURRAN: We're not operating according to it. And so we did not feel as though it was appropriate to include it in the document. It has been adopted by the board. The implementation is held pending the outcome of 2009-1. If you apply for resources today, the NRPM you're holding is what you'll be judged against.
MR. TEMPLIN: So it might get implemented as written or it might get, in fact, rejected?
MR. CURRAN: No, it's going to get implemented as written unless modified as a result of these discussions.
MR. TEMPLIN: So why do we have a 2009-1 and not further modifications to 2008-6?
MR. BRADNER: It's the mechanism by which the Board is suggesting the modifications 2008-6. It's a mechanism.
MR. CURRAN: 2008-6 has been adopted. But you wouldn't want us to actually allow transfers if it turns out we need to change it. Okay? So I'm back to Owen. Does that question answer what you are looking to seek?
MR. DELONG: Yes.
MR. CURRAN: So I'm going to say the question again for clarity. This applies to people in the room and online participants.
Regarding the existing adopted open transfer policy, which currently is restricted to IPv4 only, is the room in favor of opening the scope of that to all number resources?
A vote of yes would be to change it from v4 only to all numbering resources. A vote of no would be against expanding its scope.
So I'm going to ask for a show of hands. I see someone approaching the mic. Yes.
MR. SCHILLER: Jason Schiller, UUNET/Verizon. Would it be useful also to have a show of hands regarding the number of people that feel they're not well enough informed to make a decision?
MR. CURRAN: The hope was that by asking do you want to exchange the -- expand the current scope that those people who didn't feel comfortable would vote in the negative because they haven't had the level of information. However -- however, if people feel as though there's uncertainty on that, then we don't do a poll. It only takes a small contingent here that feels they are not well enough informed for us not to do a poll. Are you one of those contingents? (Laughter)
MR. SCHILLER: Personally, I don't think there's enough information so I would vote no.
MR. CURRAN: You would say you would not have a poll of show of hands?
MR. SCHILLER: No, no. In regard to the question that you asked, do you support or oppose, I would vote that I oppose because I don't think we have enough information.
MR. CURRAN: As would probably many other folks.
MR. SCHILLER: I'm concerned that there may be a large number of people that also feel like they do not have enough information but would neither vote opposed nor vote support.
MR. CURRAN: But you're not one of those people?
MR. SCHILLER: But I'm not one of those people.
MR. CURRAN: Welcome to sit down, thank you. Mr. Hughes. Mr. Hughes, you expressed concern that people did not have enough information to adequately vote. Are you still concerned? Is anyone concerned that there's not enough information to vote on the question that we will poll?
Okay. Show of hands, on the matter of the existing open transfer policy whose scope is currently IPv4 only, we'd like to know whether or not the community in this room and online wish to expand that scope from IPv4 only to all number resources. A vote in yes would be in favor of this. Please vote now. Raise your hand if you're in favor of expanding the scope of the existing open transfer policy from IPv4 to all number resources. All participants. Online participants, type, type, type.
Okay. All those opposed to expanding the scope of the existing IPv4-only open transfer policy. All those opposed to expanding the scope, raise your hand now. Online participants vote now. Nice and high.
We're tabulating. Keep holding.
On the matter of expanding the scope of the existing open transfer policy from IPv4 only to all number resources, number in favor, seven in the room, zero remote participants. Number opposed, 55 in the room and eight remote participants.
This information, of course, will go to the Board and the Advisory Council for their consideration.
Owen, you mentioned seven items that we might want to poll on. We've done three and are beginning to question whether we've had adequate discussion. What others do you think are relevant?
MR. DELONG: (Inaudible)
MR. CURRAN: Wonderful. Thank you. So Owen indicates that that's probably enough information. The others are sufficient. You have sufficient knowledge on already. Okay. Hopefully this is good information for the Board and the Advisory Council.
Noting that it's 10:45, which is past our break time and having determined with psychic power that the break refreshments are indeed now out there, we'll now go to break. We'll take a break. It's a 15-minute break. Please be back in here at 11:00 AM Thank you.
MR. VEGODA: Okay. I'll quickly run through the registry data and automating and securing reverse DNS management. Lovely.
So the RIR communities reached consensus on a global policy for allocating the last five /8s, one to each RIR. It was ratified by the ICANN Board of directors in March. We've implemented the parts of it that can be implemented before we get to the point where we have to do the actual implementation, which is that we've taken five /8s and written them down and said those are the last five /8s we'll be allocating. And we've written that procedure for doing the rest of it. And so now we just wait. That's the next part of the implementation. Which leads to the last IPv4 allocation since the last meeting; each of those went out to each of the RIRs in the pie chart.
We've got 32 left in the pool. The whole pool. The same number that Leslie gave earlier on, which is good. It's good when we all count from the same number. So that's 32. Five of which are in that global policy pool.
And AS numbers. Since the global AS number policy was ratified the summer of last year, actually in the southern hemisphere, in which case it was mid-winter, we have allocated six 16-bit blocks: One to LACNIC, two to ARIN, and three to RIPE NCC. That's numerical, not chronological order. I just thought it looked nicer.
So the difference that you'll see here is that this policy allows us to allocate enough AS numbers for an RIR's needs for the next 12 months. So when an RIR uses more than 1,024 AS numbers or is projected to do over the next 12 months, they can qualify for more than one block of 1024 AS numbers.
For instance, if you used 1,024 -- sorry 1,025 numbers, that was your projection for the next 12 months, would you qualify for two blocks, because the granularity of the pool is 1024, and that accounts for this difference. Basically all it means is that we allocate the same number of blocks and the RIRs use the same amount of blocks but they come back to us once a year instead of coming back multiple times per year.
IETF work. We've been writing lots of drafts. Draft-iana-rfc3330bis is drafts which updates rfc3330, that's basically special IPv4 prefixes, the things you should be thinking about when you create your filter policies and stuff like that.
It was Last Called as an informational. We were asked to make a few changes, including shifting it to BCP, and so it will be Last Called again. That will be going out when all the text that we were promised, suggested text has come in and we've integrated it.
Draft-iana-special-ipv4-registry is an RFC, or it will be, hopefully, an RFC to set aside 192.0.0.0/24 for use as a pool for IETF protocol assignments. So that is basically exactly the same text as was used for the IPv6 special IANA registry. And it's just a different prefix. It's an IPv4 prefix. That's hopefully going to be Last Called fairly soon.
And draft-ietf-mboned-rfc3171, if you're one of those people that uses multicast in your network, this is the document that describes the process for getting that multicast address space.
New views of registry data. So the key thing here is that there are lots of different registries especially for IPv6 where there's a whole series of registries and they're sort of hierarchical but it's very difficult to work out where things are in the hierarchy, even those who are regulars in the IETF and so on. It can get a bit complicated. So we're working on a way of developing a unified view of multiple registries when they are multiple registries for a single address space.
We're doing this -- it's easier now that we've got everything in XML. So I've got examples here. This is a unified view of part of the IPv6 address space. You can see that the light gray text, that's address space that hasn't been allocated. And the black text is address space that has been allocated. Links to all the actual registries. This isn't an IANA registry. This is just a few.
And then you unclick that little box at the bottom and all the unallocated stuff goes away. This is actually -- as a set of tools that we can use -- it's fairly generic. So we can go and stick this in other registries so that we can go and make it clear to people what is left in the registry, which hopefully is useful for anyone who's looking at a registry and trying to work out how much is left, whether they need to do work to expand a registry, that sort of thing.
Finally, automating and securing reverse DNS management. We are implementing a system for securely accepting DNSSEC delegation material, NSECs and DS and stuff like that. Alpha testing happened with the cooperation of the RIRs. They actually did the testing to make sure that it did what it was meant to do. That was reasonably successful.
There are some changes being implemented. Terry Manderson, who I expect lots of you know, who used to be at APNIC, is doing the technical side of the work. He's doing the code and hopefully it will be ready for the IETF meeting in Stockholm where we'll be meeting with the RIRs and giving them all that new code and they can do the beta testing.
I mean, this is something where we have to cooperate with the RIRs, of course, because otherwise it wouldn't work. They've been very helpful in testing all of this for us, so we're very grateful to them, because I think the important thing here isn't just the automation element. It's the fact that we'll have a mechanism for accepting all the DNS sector data so we can go and make it easier for people who want to use DNSSEC on the reverse tree.
And that's it. That's my update. Thank you very much.
Next up we have an exciting presentation. We asked Jean Camp to look into options for identifying distribution for the last of the resources, IPv4 resources, and she has a presentation for us. Thank you.
MS. CAMP: Thank you. I know there has been a lot of discussion about markets. And I am going to give you some other options, and that is my primary interest.
So I did some previous work about adoption, working at what's an available measure, what's a reasonable measure for adoption. Right? I mean, that's not an entirely trivial question. Can the v6 diffusion uncertainty be found? Is there a feasible path which results in short v4-6 co-existence and what are the implications in terms of possible actions. Well, I found, generally, diffusion uncertainty can be bound, but I didn't see a path where there's short v4 and v6 co-existence. Now, that's based on v6 diffusion.
But I must say, as someone who lives in Indiana and has to be careful to drive around to the Amish gentleman on the way to the airport, I was not shocked to learn that there may be a long co-existence of two modes.
So I did not see any feasible path that resulted in less than years and decades of 6 and 4 serious co-existence that is fairly slow 6 uptake. Part of this came from economics and securities: Why don't people adopt 6? There are strong arguments, which I will not argue with you or against you, that it has security bonuses, that it can help with some of the most chronic security problems. Why isn't it getting adopted, and a lot of the findings from economics and security apply here.
So at the end of that I said really there's four options. You can do nothing. You can wait for the government to lead, and I will see there are governments that are ferociously endeavoring to lead. This has been tried and they are trying it. And, you know, gosh darn it, you'll like them and they're here to help. It hasn't been hugely successful, however.
So the RIR lead, the argument was very strongly made that what you need is a market. You need a market. V4 is going to be a shortage. When you have a shortage, the market manages shortages, that's what it does, right?
And then I said, well, maybe there's some other things you can do, to which the, you know, rather pointed question was, and so, you know, what other is there?
So I went to -- I had gone to the IP report, and one of the things it said is that what we're looking for is fairness. Right? And so I am basically going to present some different definitions of fairness.
And here are three things that I offer for your consideration. Only allocate to organizations with a small address space previously allocated. That is, if you're well endowed with before space, you don't get more.
That definition of fairness is to whom much is given, much is expected. Only allocate a given amount of v4 space per year. That is to say, each is given the same. Or provide a minimal routing allocation per organization per year; each is given the same minimal amount. This is that "everybody gets a cup of rice" theory of justice.
So I took these policy requirements from the IPv4, and addressed policies are intended to be applied uniformly and also fairly. But, again, your definition of fair can vary greatly. Addresses are made available from the unallocated pool to meet demands for their use in networks. I felt like that was a pretty uncontestable argument. And the prevailing address policy regime characterizes addresses as a network attribute. That is, it's something that you have on the network. Now, these are things that are not listed as policy requirements. The market requirements.
The market requirements is this, basically. That there is a strong convexity requirement. All that means is that you cannot break up a larger IP block into smaller IP blocks and make money. Right? That is all that it means. That is exactly what it means, because if there's not a strong convexity requirement, what you get is the externality. And the externality in this case is that the people that would be holding and selling these would not be the people who felt the influence of dividing the block up on the routing infrastructure.
The people who are selling it -- that is, this guy sold me -- let's get crazy -- this guy sold me a /28 and promised me it would be routable everywhere in the world. If you don't route it, then I own it and I'm taking you to court. Right. So that is what happens if we don't meet a strong convexity requirement. That is the basic assumption you're working from here. Everything else falls apart.
Now, this falls apart if v4 becomes a gateway technology or critical facility. I'm sure all of you are familiar to some extent with the telecom battles and the idea of open access and open access means, oh, we're selling DSL so you have to give me open access to the copper wire, or we're selling DSL so you have to give me open access to the switching facility, right. And then -- because that's the critical facility. Or if it becomes, for example, a gateway to a larger backbone and everything's happening, the 6 adoption is happening, not on the network, but in subnet.
This also requires avoidance of destructive market behaviors. And I think that we've all seen that avoiding destructive market behaviors requires common beliefs. That is to say that if people believe speculation will be valuable, it will be valuable. I mean, you can sit and argue my feet off and be completely right, but it doesn't matter. If it is believed that speculation will be valuable, there will be a period where speculation is valuable.
So those are not policy requirements. So we got some data. I'll talk about. We made some assumptions. The big assumption we made is that things are consistent over time. As Dwight Eisenhower once said in the heat of a press conference: Times are more like they are now than they have ever been before. Right. So that's what we're assuming. We had a base assumption that IANA splits the remaining blocks equally and we made a bold assertion that WHOIS is roughly correct.
All right. So we took two things. We took the stats file, right, which has an allocation history of ARIN, which says this is when it was allocated and it doesn't tell you who got it. And then we used two WHOISes -- is that the plural of WHOIS? -- and we tried to associate system identifiers to v4. And then we kind of looked to see if there were contests between them.
And then we did some very basic modeling and said when will we run out. And we said, oh, we agree with pretty much everybody else's models. We're talking maybe we'll make it to 12. So that was our sanity check. And then we went back and we said, okay, how is this allocated? Well, there's about 34 really big players of which I'm sure all are represented in this room. There are another 103 fairly large players, and then as you get down to smaller allocations, you get larger numbers. For example, somebody said there was a school in Fremont that had a /24, high school in Fremont, that had this mysterious allocation. So that's all the elementary schools and everybody else.
So the first thing we said is to whom much is asked, to whom much is given, nothing else is given. So all of this data is based on one basic observation: If you don't have much and you give it away in big chunks, you run out. Right.
And based on that very simple observation, we have three basically ideas that we're offering. If you want to embrace the convexity requirements, then that's one choice of assumptions.
These are different sets of assumptions that you can embrace. And they will yield a v4 that is a different kind of thing as opposed to a piece of property. Right. And it will have a different function. So basically we said: Organizations above a certain threshold receive no additional addresses. So why would you come up with that if you're not just some wild Marxist? Well, actually, there are some very good reasons. Not to talk about it, larger organizations request very large blocks. Right? By definition, when they run out and they need more, they really need more, right? It's not the high school; they're not getting another computer in the office.
Larger organizations have a lot more networking expertise. Not only in aggregate. But they tend to be much more capable of attracting expertise. And then if you bring someone in to a large organization, a large networking organization, they can get mentored, right. They will develop the expertise of running large networks. They have experience in translation at large scale. Basically, they have the capacity. They have motivation which is kind of a tricky word here. They have the motivation to make sure that there's not disruption, because they've done basically the best, right, by definition. These are companies that have gotten the most utilization out of 4.
But they have motivation, traditionally, as businesses. Not as bad people. Not to allow people to enter their business domain and compete with them. Right. Just like cellular networks don't -- cellular phone companies don't like the idea of additional cellular phone companies. So they don't want a lot of spectrum to be made available for that purpose. And traditional radio stations do not jump up and down when more spectrum is allocated to, is available in a crowded market.
The desire to prevent entry of competitors is a fundamental motivation of every business, and if full allocation of v4 can prevent entry for two or three years, that is a tremendous benefit. And there are a huge other number of sources of reasons and I'll recommend you to previous work on that.
So how do you model something like this? How do you say, all right, let's pretend? So what we did was we said, again, times are more like they are now than they ever have been before, we took the history, we had an allocation. We took the historical allocation and said what if this policy had been in place over time. And then we generated a new curve. We shifted it back up to the present date and then stapled that curve with the new slope onto it basically. We did a curve fitting for a curve under this supposed policy regime. Does that make sense? Then we added it back to get to our starting point. And then we used our projected curve. So everybody's either in agreement, asleep or checking their e-mail.
So even if we used a fairly large threshold, we wouldn't run out until 2024. If we just said -- and why does that happen? That happens because when you give away an 8 you've given away a lot of IP space. And if you just something like 95 percent, 90 percent of the requests are very small.
So if you throw out the large requests, you get a much longer lifetime. Now, there's a rather radical assumption here, and that is the people who have large allocations adopt v6. That is, they do what you want them to do. They do not, for example, enter some secondary market for v4. They don't go and buy some bankrupt teleco for v4. Although, that would be a way of giving back.
And they don't push for multiple smaller allocations, right? That's the huge assumption here. The assumption is that because they're identifiable organizations you can regulate that internally, and so that you would notice if they didn't. So in a way it's taking advantage of the relative size of this community. And the other issue is that you're hoping that the purpose of the policy would be to get them to implement v6.
So using /20 as a threshold, because that's pretty small and we would just assume one organization per /20, exhaustion approaches 2045 and we all hope that v4 is not a topic in 2045. So if you have a lower threshold, you can -- if you have a lower threshold and large carriers participate, why would they participate in this? Well, they would participate in this because they would have long-term interests for very large growth of the network. They would participate in this because there is a tendency to advocate good citizenship at the engineering level.
And they would participate because you try to make them. And these are expiration dates that anybody can live with. This isn't 2015. So when you start talking about a threshold of /20, now you can reasonably cross your arms and say: Well, you can't get any smaller than that. You know. You can't -- it just doesn't get smaller than that, right? So maybe what we ought to do is say: All right, these companies will not just go away. They won't say, oh, I can't get a /8, so what I'm going to do is invest in v6, right, because that's the bet.
I'm just going to come back and keep asking every year. All right. So let's look and say: Provide any organization that requests an allocation exactly one minimal route. So this is another place where we have a new definition of fairness. Not each according to their need or according to their capacity. But everybody gets the same thing. I don't care if you're hungry, honey, you get the same slice of cake everybody else gets.
And the idea is that larger companies have greater network capacity. The move from v4 is not going to be trivial. It requires engineering. And you can't start that move at a high school in Fremont, right? So it's kind of a pushdown idea.
You can see here a strong historical anomaly where kind of everybody got moved into ARIN, right? Like thump, all the organizations that have previous allocation got moved under the ARIN rubric, and that pretty much ends in ‘98. So we started looking at data at ‘98.
You can multiply the number of organizations and allocations, again assuming that the allocations. You select the allocation size as minimally routable. Now, when you look at a market, you are making an explicit claim about what a v4 address block is.
A v4 address block is a transferrable, priceable item of property. If you look at this, you're making a very different assertion, and that is to say v4 is a backstop technology which will enable you to interact with all parts of the Internet using translation technologies at appropriate points. These are very different statements about the nature of a v4 address, and I'm just making explicit the choices about this, to try to say these are really different definitions. This isn't just about playing with numbers. This is about what is this thing we are talking about, what do we want it to be in the future.
Okay. So we just use organizational count. Oh, and you can't see my whole slide. Looks great on my screen. And you can see we can break it down even with fairly large allocations to 2016, right, which is breathing room. Which is not next year. Although, these were January numbers. And if you make it really tiny so that you might get thrown out of the rounding table, you can go a long time. So it depends on what choice you want.
Now, the other thing is just to decide, right? Just like when TCP became dominant. Wait, what was that? That was the '80s. That was way back when they said we're going to use IP on everything, right? Deal with it.
It's a predetermined exhaustion date. Okay.
MR. BRADNER: '95.
MS. CAMP: '95?
MS. CAMP: All right. Well we'll have this argument later. Do I hear '96? Oh, sorry.
SPEAKER: Can you talk about the (inaudible)?
MS. CAMP: '82. Yes, that's what I'm talking about. '82. Pick a date. Guess what, we run out that day, December 31st or -- it's basically -- and I know you all know what this program is, the H-1B visa model, right? Everybody knows this program.
You pick a year. You divide the pool and you say: You know what, this is how much we're allocating this year, and we are going to run out in 2030. And you decide as an organization your end date. One of the questions there is how small can you go? Right? If you start giving out /24s, you have a long time. You can get lots of /24s. Lots and lots of them.
How many allocations are you getting per year per average and are those going to increase? Who would be refused? The nice thing is if you're willing to go into smaller amounts, you can definitely make this decision later than others, right? This is one you could wait until you're six months before and say you know what? We're actually going to run out in 10 years and you get a /24, congratulations. And here's a cup.
I mean, yeah, you could get really small and go for 100 years if you want to, because there's about 2,000 last year organizational requests, right? Many of them are small, though. Many requests are small. Whenever somebody comes in and they're like I want a /8, everybody notices them. Whoa. But if you look at the size allocations and again you assume this is a huge assumption, but I don't think it is as strong an assumption as convexity because it is actually maintained within this community, okay? That's one reason.
And, two, it is organizations are to some degree observable, right? So if you assume that instead of continuing large requests, individuals take -- accept the small request and then take the larger v6 or their own technology, right? I mean they may say, no, we're going to do -- we've got this unaddressed technology from MIT and that's what we're going to use. We're just going to use our own back end to distribute this.
You have to make that assumption for this to work, that they don't -- that you don't get one request from: All right, just to pick on these guys, because I know them, some of them anyway, they're policy dudes. So you don't get one request from Comcast Alabama, one request from Comcast Alaska, one request from Comcast Arkansas, one request from Comcast -- you get the idea.
So assuming you don't game it like that. Even if you made it run over 30 years, 95 percent of the request historically could be met. But not the big request.
And you just could not meet them. So this is my point. The RIR or LIR decisions you could choose to manage exhaustion many ways. How you manage the exhaustion will not only determine the transition but it will determine the nature of a v4 address. And when you look at what do you want a v4 address to be, you have some choices.
Do you want it to be a critical facility? Now, it is my opinion that if you just exhaust, and then companies are coming forward with requests, that is what it's going to become. But it's not something I would advocate. But having been at -- get on the list. Ask Milton Muller if he thinks it will become a critical facility. I believe he asserts this is the best governance mechanism. It's one with a long history. It's one we kind of know how to do, right, in the policy world.
A traded good. Is it a thing? It better be a thing with highly convex characteristics. Or is it a high-level interconnection backbone technology that is used either to aggregate at a high level or to translate to regions or services that are not moved to v6 yet.
So that's one of the things. And one of the interesting things -- so I have been lurking on the policy list, and I saw this huge discussion about: Well, the manager says it's free so let's get an A-type. And so I looked at Class A -- remember, A, B, C, and everything was free and people were just asking for addresses.
And I think that I found that manager. I think he was at Ford. You know, they're like a top 15 holder of v4 addresses. Right? So I think that has happened. I mean, maybe Ford secretly connects all of Detroit, I don't know, or...
Then you have issues, and this was not an issue when I started writing the paper, of bankruptcy. This may be decided out from under you. If the judge says that, you know, this is an asset that will be sold in order to pay off the debts of this bankrupt company, it will be an asset that will be sold in order to pay off the debts of the bankrupt company.
And I think that that is, in terms of policy, a very real risk that I haven't heard any discussion about. But there may be a tremendous kind of historical implicit knowledge about how that was dealt with, for example, during the boom. But I think that is one of the reasons that I would think a policy to reclaim unused v4 space would be particularly critical given the number and rate of bankruptcies in the U.S.
So that's it. And I welcome your questions and comments.
MR. HANSLEY: James Hansley, SkyPort Global Communications. We're a satellite communications provider. And going over your presentation, I have one question for you, actually.
If I heard you correctly, what you were saying was it's advantageous the way it's going to lose the v4 addresses in order to push the new players that are coming out onto the market to v6 because that's the way it's going. Did I hear you correctly?
MS. CAMP: Yes, and to rate limit v4 both to ensure backward compatibility and to push new entrants. So if somebody comes up and they say I have huge funding, I found the VC that's still giving away money and I'm going to staff release and I need a /8, you say: Well, here's what you get and hire better engineers, basically.
Although, it was absolutely not part of this work. But if I can just shamelessly opine, and I have the mic, so I will, one of the things I would do is set up student labs and give them away. Say, here's a lab in a box. Download this. Install it. And run the lab. Run the setup v6. Run the v6 and how to handle v6 with a denial of service attack. And then go to -- I mean, if you go to 100 universities to give away CS and engineering degrees, you've basically covered everybody. There's not that many of them. And you could have -- if you manage to extend the life for 10 years, you'd have two basically generations of students who would come out with this comfort level and knowledge. So I think there are a lot of things that could be done.
MR. HUGHES: Aaron Hughes. I really love radical ideas. I really do. This one, I think the foundation, the basic idea that your expertise lies in your large ISPs and they give the most pushback is true. But the reason they give the most pushback is because there's a basic fundamental business problem with adding dual-stack to very large networks.
And the general principle that we're built on is a hierarchy where you have service providers handing to customers. If something like this were to hypothetically be in place, what you would have is a flood of organization requests to Delaware and everybody requesting --
MS. CAMP: Alabama, Arkansas, yeah, exactly.
MR. HUGHES: And of course massive table bloat and so on, and we destroy our routing architecture much, much faster than we would now.
Also, people aren't really -- the customer really doesn't care where they get the space from, right? They just care that there's no space available. So I can't see any way to implement something like this where it would work in the practical world.
I think it would just add more complications to people than having to educate themselves well enough to be able to then follow these processes, cause more work for everybody and the end result is that nobody gets routed anywhere.
Secondly, I think that the companies that can implement v6 are the medium-sized companies. They're the people that are small enough where they can make an architecture decision, work with their VP of operations, talk about impact in a small group, and then go actually do it.
The larger organizations as we all know are like massive moving ships. When you start to talk about billions of dollars in changes, it's no longer simple. You can't just start go configuring on the router.
MS. CAMP: I think I'm going to disagree with your expertise point. Yes, that's where the expertise is. But I acknowledge you also deal with something medium-sized companies don't deal with, and that is a lot of customers connecting to the Internet and calling you up and saying things like: My printer doesn't work. Why doesn't my printer work.
Not only do they not care what kind of connectivity they get, they mostly don't know. And one of the things about v4 that has made it I think so resilient is you can actually type the address in your box. You know your third cousin twice removed can bring up the window and type those numbers in correctly.
And so I'm not implying it's simple. I'm just saying if you want -- you know, the changeover is going to be harsh. The large service providers have -- you either meet their demand or you meet a lot of little demand. And if you want to make the assumption that convexity is true, then -- I don't have any proof. Neither one of us standing here knows if the market's going to be highly convex. And if it will work and it's smooth and it turns out, yes, that's the demand curve. It looks like this, right.
And so, I mean, I hear what you're saying and I think it's a choice.
MR. HUGHES: The simplest example of a massive problem is imagining telling that person, what's my IP address of my printer, that they need to then go get an ASN, go get a /24, configure their router, and announce it to the provider so they can reach the Internet.
MS. CAMP: They won't. They'll go to the provider who can say: All right. Here's your IP address. Now I'm going to read you a whole bunch of numbers. Maybe I'll just e-mail it to you, and it's a 6 address. And they won't know that they've changed.
So, I mean, I'm not pretending that the market is perfect. But I'm saying you've got to -- when you make this decision, you're making some very fundamental decisions, too.
MR. HOWARD: Lee Howard, ARIN Board of Trustees and also Time Warner Cable. And both of those roles inform my comment and question.
First of all, thank you very much for this. I think it's really helpful and useful to look at a variety of different approaches, and I think that you've covered several that haven't been given anywhere near the kind of consideration that we ought to be paying attention to. So that really helps a lot, thank you.
Now, but I noticed that you modeled based on ARIN's historical request rate.
MS. CAMP: After '98.
MR. HOWARD: And I'm sort of responding or sort of carrying on some of what Aaron was saying -- Aaron, not ARIN -- that if large ISPs get very small blocks and cannot allocate v4 to their customers, then those customers are likely to become requesters to the extent that IPv6 does not meet their needs. And there are things we haven't figured out how to do in v6 yet or at least how to do in a mixed Internet; that's some v4 and v6. So have you modeled how that change in demand would affect the run-out dates?
MS. CAMP: No, I haven't, because I assume that individual consumers will not ask for small routable chunks. And certainly the difference between this and a strict kind of exhaustion model is that you can choose how soon you deal with it and on what scale you deal with it, right.
Do you deal with it in Vermont and Massachusetts in a year and figure out how it works there? Or do you deal with it across your entire network simultaneously in two years?
I mean, the problems for dealing customer-facing v6 are not going to -- you can put them off. You can put them off as long as you want. You can deal with them as you would like. You can wait until full allocation and then hope you don't have to deal with it: Oh, it's Wednesday, time to deal.
Or you can say: I want to deal with it in this managed way.
MR. HOWARD: I'm not sure I followed that. I think your implication -- let me change that.
MS. CAMP: That you're going to run out, that's my implication.
MR. HOWARD: I infer from that that you expect that there are ISPs who will not do any planning until they're out of v4. Did I infer incorrectly?
MS. CAMP: You inferred completely correctly. I believe that there are people who in management and senior positions that are doing no planning whatsoever. I'm just going to go out on a limb there. And I think it's a safer thing to say than it was two years ago.
MR. HOWARD: I can't speak for every large ISP, but I don't think it's the case that there are many large ISPs who are not planning.
MR. CURRAN: Just a little detail, between this presentation and the Q&A session of this presentation, right after that is lunch. And to prevent us from showing up to arrive at cold food, I am going to be closing the microphone shortly. So if you wish to talk about this presentation, please approach the mics quickly because we'll be closing them very shortly.
MS. CAMP: And that was the most gracious "you're wrong" I've ever heard in my life.
MR. SEASTROM: Rob Seastrom with ClueTrust, and I'm also on the ARIN Advisory Council. I appreciate you coming in and giving this presentation. I thought it gave us interesting stuff to chew on and consider.
Since you seem to be advocating an artificial shortage imposed before actual depletion, I was wondering if you had modeled or considered how much ARIN membership costs would have to be raised up, by what factor, how many times, in order to cover the costs of ensuing litigation that this would no doubt bring about?
MS. CAMP: No, I haven't looked at the cost of litigation when there's exhaustion and people start saying: Oh, well, I should get that because you're not using it. I mean, you could make that assertion about any policy choice. I'm saying to you, you have a choice. You can knowingly continue at full speed and run into a brick wall, or you cannot.
MR. SEASTROM: I think on the contrary, credit card holders and other holders of debt routinely make the decision to not try to recover that debt, even though it's owed to them, on the basis that you can't get blood out of a turnip.
And if we're actually well and truly out of IP address space, it's very easy to make the decision with counsel, hey, we're not going to waste money going after this, whereas if there's an artificial shortage that's imposed, I think the odds are far greater for just an incredible tempest of legal activity.
MS. CAMP: And I would bet money you've never been an expert witness, if you think this kind of strict rationality applies to litigation.
MR. SEASTROM: I've been a party to many lawsuits.
MS. CAMP: If you think the community is not going to accept this, and 140 organizations are going to stand up and sue ARIN, well, then, yes, those are the 140 organizations that have the most v4 and that have the most to win by delaying adoption of v6 so that other people cannot enter the market and compete with them. To be honest. I'm sure they have lawyers.
MR. SEASTROM: I respectfully disagree with that correlation, but thank you.
MR. CURRAN: We have a remote participant. Go ahead.
MS. ARONSON: This is from Joe Maimon at CHL. He says: I assume the underlying topic could be called rationing. To force large organizations to move to IPv6 sooner than smaller organizations to scavenge their internal resource, to assign dollar values to IPv4 addresses are all extremely beneficial -- been efficient to mid-size and small organizations at the detriment of all large organizations.
Since in the past every advantage of the free pool has been given to large organizations as evidenced by the fees, it may be time to have them step up to the plate and take one for the team.
Is Jean expressing these viewpoints or is the thinking different?
MS. CAMP: I said my definition of fairness could be each according to need, which is what we have now, so those with great need get great consideration, or to whom much is given, much is expected. And I think that's what he's expressing, although I don't know how large versus medium versus small organizations have been treated in ARIN, and I have no -- not only do I have no comment, I have no information. I have no opinion.
And then the other argument is each is given the same. And so, yes, there are different definitions of fairness, just like there's different definitions of what is a v4 address.
MR. CURRAN: Okay. I am closing the mic. If you're at the mic or in line, you're okay. Otherwise, you're not. We'll have to approach after the session. So no additional people queueing up, thank you.
MR. SCHILLER: Jason Schiller, UUNET/Verizon. I wanted to make a comment on rationing. The problem that we're really trying to solve is not preventing IANA from running out of addresses or preventing the RIRs from running out of addresses. The problem that we're trying to solve is when end sites, end users, ISPs, those people that need addresses can no longer get them.
By creating a situation where you ration the addresses, you certainly do lengthen the time that IANA will have addresses sitting in a pool to be available.
But what you're actually doing is you're increasing the amount of pain people are experiencing and you're shortening the time with which they will start experiencing that pain.
So I think it's clear, to me at least, anyway, that any form of rationing will overall increase the pain and cause the effects of depletion to be felt by many sooner. So that's my concern with that sort of an approach. I wonder what your response to that would be.
MS. CAMP: Well, this is essentially the same point that was made here is that: Look, what you're saying is we have to have this pain now as opposed to all dealing with it later and hoping that everything is convex and that the market works perfectly and that everything works out so we don't feel any pain.
My response to that is, yes, as a community you get to decide, are we going to do this in a managed way? Are we going to -- are we going to ask parties to lead and who are we going to ask to lead?
MR. POUNSETT: Matt Pounsett from Afilias. I guess the stuff I had to say fits in closely with some of that as well. My approach, I was approaching it from a slightly different way, to say that run-out doesn't occur when IANA runs out of addresses or one of the RIRs runs out of addresses. Run-out occurs when somebody who needs addresses can't get them.
And if we're talking about rationing in such a way that large ISPs are unable to get the addresses they need to turn out customers and so on, then we're creating a situation where people don't have -- people who are trying to get access to the Internet don't have it. Those people in turn are then going to go and try and find some other way to do it by creating new organizations, and requesting addresses directly, something along those lines. And so it sounds like we wind up with this situation where we're essentially -- we're going to break the Internet for a lot of people really soon as opposed to giving those people and their organizations or the organizations sort of above them in the Internet hierarchy an opportunity to fix things before it gets broken. And while it's an interesting idea, I think, I'm not sure I see how it's practical.
MS. CAMP: Okay. So from kind of an organizational-theory point of view the idea is that you give the people who are probably most capable of fixing it and dealing with it the motivation, because right now -- I didn't say that about large organizations are motivated to keep IPv4 and keep other people from competing with them because I think they're bad.
I mean, I'm constantly producing carbon dioxide, and it's not because I support global warming. It's because -- it's because that's what organizations do. I mean, the goal of the corporation is to maximize return to their shareholders. And we've all seen this happen in every kind of network that -- and not even in networks, right? In software and cereal boxes and everything else, if there's an asset that's limited and it can be used to prevent entry into your market, you use that asset to prevent entry into your market.
And you're saying, well, you're advocating -- I am advocating -- I'm not advocating a shortage, I'm noticing that there's a shortage and saying here are different ways you can deal with it. So thank you.
MR. KITCHENS: Doug Kitchens, Suddenlink Communications. First, I want to thank you for putting this data together. It's good to see it in a trend like this where we can come up with various ideas.
That being said, I'm certainly not a Marxist on this. I do believe there is a way to, as you said, motivate the larger ISPs so that the mid- and large-size ISPs are upstream providers to a lot of the smaller ISPs, universities and such, as well.
I'm not opposed to putting a threshold on the size. I think it should be something medium, if we went that route. Maybe /15, /16 something in that neighborhood, at the greatest, or maybe I should say the least. I don't think we should get any smaller than that.
But perhaps putting some pressure and giving smaller allocations is not a bad thing. But if we just stop the larger ISPs from getting any more, I believe we put in a situation to where that hinders their growth and as well their ability to help with the situation.
MS. CAMP: Yes. Thanks. That is exactly -- I mean, I couldn't agree with you more. As a community, I am encouraging you and myself to the extent that I am part of it to think about what happens in two years and do you want it to happen in 10 years? And how long do you want to take and how your contingency plan would differ.
And, I mean, it's about managing a shortage and managing a transition with the realization the exhaustion is coming. I am not pro-shortage. It's just it exists. It's there. And the choice is how to deal with it and when to deal with it, and, therefore, at what scale to deal with it.
And I think you're going to see -- are the ISPs planning? Yes, they're planning. There's two sets of planners. There's the planners in the network department that are like this is how we're going to make it work, and then there's the planners on K Street, and they might have very different views of how these plans should happen.
Everybody knows what that means, right? K Street is a street where all the lobbying firms and like the Software Business Alliance and all of those firms have offices on K Street in D.C., in Washington, D.C. It's the big lobbying street. So if you want to quit your job and become a lobbyist, that's where you mail your resume to.
MR. ALEXANDER: Dan Alexander, Comcast Cable and ARIN Advisory Council. I'd just point out that you make very good points. But I would just say that the transfer policy of 2009-1 isn't the only policy discussions that we have been having lately, and we are trying to address things through some of the means you've actually recommended. 2008-5, which was passed last year, was for dedicated blocks for v6 deployment.
The global policy that was discussed earlier about the remaining /8 to each of the RIRs, and actually this is a very good groundwork discussion for tomorrow, because 2009-2 actually discusses the idea of rationing when we reach that end situation. So this is actually kind of a very good primer for tomorrow's discussion.
MS. CAMP: Thank you. One of the reasons that this kind of rationing might in some way be acceptable at a level is if you could go back and say: Look, I might not have had your support previously to move forward on v6 because we're shooting ourselves in the head or the foot or some body part, because none of our competitors are doing it.
And if you take a large scale or a class of organizations, and maybe it's not strictly size, and say these are the competitors and these are the rules you're all playing by as opposed to waiting for somebody to step up to the plate and take the sacrifice that it takes to be a real leader, it might be easier. And that's my hope. And thank you for your time.
MR. CURRAN: Thank you.
MR. CURRAN: Next. So we're going to get started. I rearranged the agenda from your program a little bit. Because the next item on the agenda is 2008-7, which is a WHOIS cleanup proposal, I thought it might be useful to get a couple of quick slides from Leslie describing what we're presently doing with WHOIS cleanup and then we can compare and contrast that. So, Leslie, if you want to come up.
MS. NOBILE: I took this banner right from our WHOIS, from our web page. We're doing a WHOIS spring cleaning. And we are basically asking customers to come in and clean up their POC and ORG data. This is based on feedback and input from the community that we've been reading and hearing about for quite some time. We started this project just about 10 days ago; we started sending e-mails.
Anyway, we're doing it in different phases. Phase one is we're going to start with all the direct allocations and assignments. That would include IPv4 and IPv6 and Autonomous System Numbers and includes the legacy because much of the legacy is direct assignments and allocations.
We're sending e-mails, and we are sending a total of 33,000 with this round. And that encompasses almost 43,000 distinct POCs. That is admins and tech abuse and not all POCs associated with an ORG.
The way we thought we would do this is send one mail to each of the organizations and include all of the points of contact associated with that ORG in the one mail. And we're including templates and information on how to update the record. Our theory is if a resource tech is long gone, if we had sent the mail directly to him we would have got it bounced back but we would never have known. As long as we send to all POCs or admin, they'll say he's not here, this is the new guy. That's how we're planning to do this.
It actually seems to be working pretty well. We're doing 2,000 e-mails per week. That's about as much as we can handle because of the response and trying to maintain our regular work. We're doing 665 each Monday, Wednesday and Friday.
We think it will take us about four months to complete this phase, which is just the directs. So I just started looking at the phase two down the road. Reassignments. And we looked at how many reassignments are actually in the database. And we thought we'll start toward the end of the summer, and there's a lot of reassignments. There are 31,378 reallocations and 327,000 plus detailed reassignments. So it's about 400,000 that we would have to deal with. So we're not quite sure how we're going to handle that because we have eight people in registration services staff. And just not sure how that's going to work. But we're going to get through phase one, then we'll figure out phase two.
I have some stats. We've only been doing this for 10 days. So far we've sent only 2095 messages. We've gotten back 160 new POC templates. Pretty much every time we send out an e-mail we get back a bunch of templates and we've gotten about 250 bounced messages that we can track. We can't track all of them but the ones coming back into the account looks like there's about 250. And there are some templates coming in through the web services, the online web services. And we're not able to actually track those because they lose the subject line and the subject line is what our identifier is for our e-mails. But we know some are coming our way. We looked at stats and we were getting like 10 or 20 POC templates each week through the online services. And as soon as we sent the e-mail that number went up to like 27, 30 something. So we saw an increase. We're seeing an increase. We know they're coming in that way as well.
And I think that's all I have. Are there questions?
MS. NOBILE: Okay. Thanks.
MR. VIXIE: Thank you.
Okay. We're now going to move into Draft Policy 2008-7, which is Identifying Invalid WHOIS Points of Contact. Marla is going to be presenting. We'll go through the overview of the presentation.
The stats on this policy proposal are coming. So history. Originally proposed in August 2008. It's been to the Nassau and Bahamas, the ARIN 22 meeting and the Bridgetown, Barbados policy meetings we had down there.
Draft policy with staff and legal assessment, current revision was the 2nd of April. There's a similar proposal in APNIC. Not relevant to the other regions.
The AC shepherds: Marla and Heather. Summary. The policy asks for an annual re-registration of all POCs in WHOIS. Points of contact who don't respond are marked unresponsive. Staff may remove invalid points of contact from the database. Staff maintains a list of number resources that lack valid points of contact. Data will be available under the same policy as the WHOIS policy criteria.
Staff assessment. Legal indicated some risk. It's possible those delisted will threaten to file litigation to be relisted. However, if we have a properly promulgated policy, it will not pose any trust or legal concerns.
Staff comments and concerns: Yes. One is that a list of resources specifically that have no valid contacts is sort of a dream come true to hijackers and spammers because they know these are not being used. If we make the information available to the community, you're going to see straight routes for them. May increase workload. So presently we are talking about the workload involved in just doing 43,000 contacts on a one-time cleanup effort with the current WHOIS cleanup initiative.
And we don't know how we'd handle all the reallocations and reassignments. To do that, with all the reallocations and reassignments and to do it annually moves this initiative into the realm of probably not only dedicated staff but multiple dedicated staff, if this is a high priority.
And then resource impact: Yes. A significant amount of resources. We're not sure this could be accommodated under the current funding that we have if it's truly an annual and not one-time event.
I think that's it. Next slide. Oh, discussion. Thank you. PPML summary. On the PPML, 54 posts by 18 people. Six in favor, one against. Support because of curiosity about the number of net blocks with no valid point of contact.
Definitely intention to get ARIN to get more aggressive about getting fake entries out of WHOIS. And people indicating that we've gone decades without this and we shouldn't have to jump into an expensive and labor-intensive process.
So with that I'll turn it over to Marla. Come on up.
MS. AZINGER: The first item, it's a disclaimer, because I have slides in here that I amalgamated PPML responses and tried to put together the best effort what responses questions and answers were. So if I get something wrong, I apologize. And when the mic's open, please feel free for corrections.
Okay. So the AC shepherds: Me, Marla, and then Heather Schiller. And we did this a little different. We took three different people, and Heather and myself, and these three other people helped comprise a team. And we had ARIN make a special mailing list for us and we all worked together to try and put several different proposals together.
So there were four different proposals that we had. It looked like too much of the similarities and just a little bit of nitpicking of different opinions. So this team actually worked together very well to get through those differences and come to compromises of what they believed would be a good proposal.
So the new revised text. This is the new revised text. The review of the bullet points that John went over actually pulled it out pretty good.
During ARIN's annual WHOIS POC validation an e-mail will be sent to every POC in the database. Each POC will have a maximum of 60 days to respond with an affirmative that their WHOIS contact information is correct and complete. Unresponsive POC e-mail addresses shall be marked as such in the database. If ARIN's staff deems the POC to be completely and permanently abandoned or otherwise illegitimate, the record shall be deleted. ARIN will maintain and make readily available to the community a current list of number resources with no valid POC. This data will be subject to the current POC WHOIS policy.
So this is my amalgamation effort. One of the concerns was hijacking. And normally I wouldn't put all this in my details, but I know there's several -- around 28 people viewing this on the Internet and watching it from afar. I wanted to make sure you all could actually see and hear what I was saying.
Hijacking: It is already a problem today. We're all aware of that. And providing a list of resources with the records is essentially a list of resources at risk, which will allow providers to have something to check against before they route the prefixes. So there's a double-edged sword on this one: It can be good and it can be bad. This is also why the phrase "otherwise illegitimate" was deliberately and intentionally inserted into this version of the proposal.
The workload: There were several that just believe this is what ARIN should be doing anyway. And if it does cost them to add staff, then maybe we as a community should look at saying yes, spend money on hiring another person to the ARIN staff to help get this done. Okay. Bulk WHOIS was another concern. ARIN has operational details of going through the bulk WHOIS process at this link that I put in here which includes a requirement to sign an AUP. Other sections of existing policy do not include operational details or further requirements for the bulk WHOIS process. The authors believe the process of signing the bulk WHOIS agreement to be an operational process on the part of ARIN staff and not part of policy.
Threat of lawsuit: Reading the views that counsel doesn't really see there's going to be a problem if we have proper policy in place to support what we're doing. So the only person that can really speak best to whether or not the way this policy is written right now has a real legal threat would be our legal counsel. So if he does see an issue with it, I would hope he'd get up to the mic at open mic to say so.
Resource impact: It will take new development and time to get this process in place. However, the potential benefit to the community is also significant.
I'll let you know when we're done. Sorry.
Frequency: The proposal -- the people that worked on it settled on annual. PPML has lots of different inputs, different ideas how often and how frequent. And they kind of took the middle road which was to do it annually.
And no abandon criteria. Correct. There's no abandon criteria. What the definition of "abandoned" is belongs to the ARIN staff as operational details which does not belong in policy but in operations manual. Someone asked what if only the e-mail address is invalid. POC is in violation of the contract they signed with ARIN that requires they supply complete POC data. In other words, get an e-mail. ARIN staff, as usual, would work with them to help this get accomplished.
Operational detail: Some of the concerns raised address operational aspects and operational aspects do not belong in policy. And anyone can make operational suggestions to staff using the ACSP, and the link's right there as well.
Just so you know, Chris Grundemann is online, in the chat room, and he's willing to answer questions also that come out of this since he was one of the primary authors for this proposal.
MR. TEMPLIN: Pete "anal retentive" Templin with Texlink Communications. Could you go back to Feedback No. 4, please. Just for clarification, spelling does count. Under "Threat of Lawsuit," is that the Advisory Council or legal counsel?
MS. AZINGER: All right. Mr. Steve Ryan over there. Let's be really specific.
MR. TEMPLIN: Thank you.
MR. RYAN: Let me follow it up. When I read this policy, I thought -- when I read this policy initially -- I apologize. I'm the legal counsel. I'm Steve Ryan. I work for ARIN.
When I read this policy, as a lawyer I misunderstood it. I thought it meant that we were striking these records from the WHOIS, period, and that's what I wrote the threat of a lawsuit.
I now understand more appropriately that it appears that we're only striking the POC language. I don't think there's any threat of a lawsuit because we're striking the POC language.
So this policy itself doesn't pose the threat of litigation. Striking them from the WHOIS, again, creates that risk, which is okay with me as long as we're doing it in a principled and appropriate way and we're adhering to policy.
MR. VIXIE: Right-hand mic.
MR. WOODCOCK: I think Steve's clarification there may have -- Bill Woodcock, speaking for myself, not the board. I think Steve's clarification there may have just addressed one of my major points, which I was going to ask how this -- it seems like striking WHOIS information is sort of a slippery slope towards reclamation and makes a distinction, a new distinction. But if we're not actually striking the organizational details from the WHOIS, just the point of contact that proved to be invalid, then, yeah, I don't see any issue with that.
It seems like it's worth noting that this differs from the current $100 database fee roundtrip confirmation thing in that this affects legacy holders, whereas that does not.
So there are legacy holders right now who are perfectly happy with their non-relationship with ARIN who will presumably have a negative response to this if and when they find out about it. And so we should probably at least be consciously aware of that in the discussion of it.
And I guess my only other thing about this is that if the point is to make the quality of the WHOIS higher, removing data from the WHOIS which may or may not be valid data but just wasn't at the time it was tested, might not actually be increasing the quality of the data in the WHOIS overall.
So I think it's -- if you're viewing that as a punitive measure, it's maybe putting the hurt in the wrong place. Putting the hurt on the people who are counting on the WHOIS to have some sort of data in it. I don't know. It strikes me that we don't have a lot of sticks in between nothing and reclamation and that removing WHOIS data may not be a stick aimed in the right direction. That's all I have to say.
MR. VIXIE: We have two questions remote.
MR. ANDERSEN: (Inaudible)
MR. VIXIE: The mic's not on.
MR. BRADNER: Please turn on the microphone. Because the guy behind you is controlling the microphone. This microphone.
MR. ANDERSEN: So from Ed Lewis from Neustar. I like the way it is written for hackers because it gives information for those defending against hijacks. If the staff workload is too high, then I like the optimization of using other activity -- e.g., legitimate template submission -- as a proxy for asking active POCs. A clean WHOIS benefits the membership that relies on the entries.
And a second -- actually, there's a third one. Second question from Jo Rhett of Silicon Valley Colocation. The benefit of a clean WHOIS far outweighs the risk of hijack. The risk of hijack is directly linear with the ability to filter against rogue netblocks. There's no disadvantage. Let's do this.
And a third from actually Joe Maimon of CHL is: Bulk WHOIS verification is steppingstone to scavenging/reclamation done by ARIN.
MS. AZINGER: I guess they're expecting an answer on that slippery slope. I think anybody could go, yeah, that kind of makes sense, because if there's no POCs there responding and they're all invalid, one might make the conclusion that it's quite possibly that address space isn't being used. So, yeah, ARIN might even take further steps to try to figure out: Hey, is this in use? And if it's not, reclaim it. But that is not the intent. But could that slope occur? Yeah, it kind of even makes sense actually when you say it out loud. But, yeah, okay.
MR. VIXIE: Anything else from the remote?
MR. ANDERSEN: Nothing right now.
MR. VIXIE: Center microphone.
MR. DELONG: Owen DeLong, ARIN AC. I support the policy as written. I think that the concern about hijackers is I won't say completely invalid, but I will say somewhat misguided. The hijackers are having no trouble finding these addresses as it stands.
Those who run routers would like to put in filters in place. On the other hand, they have a great deal of difficulty in identifying such netblocks and I think this would serve the community very well. I think it will encourage people to keep their POC data much more accurate, because I think people will start filtering netblocks that don't have valid POC data. And I think overall that is a good thing.
MR. VIXIE: Owen, thank you. Can you remind, did you say you support this policy as written?
MR. DELONG: I support the policy as written.
MR. VIXIE: Thank you.
MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. I support the policy as written. However, based on the staff's impact, there's two suggestions I would like to make out loud. One is if someone has come back to ARIN in the last year for, say, new resources or otherwise made lots of contact with ARIN and possibly even submitted current POCs in those templates, I don't really see a reason to bother them again for at least 18 months. And I realize that's probably the small fraction of the 400,000 people that need to be contacted. But it would take a few people out of that list.
The second comment I would make is I think probably there is a lot of cruft people want cleaned up because of years of buildup. And so I suspect the first pass through this is going to be an order of magnitude more difficult than subsequent passes. And if the staff impact is extreme so that that is difficult, I would absolutely support having the first pass be, for instance, a two-year window instead of a one-year window, and then start one-year re-verifications after that. So if we don't think we can get it done in a year, I think it's okay for us as a community to give the staff a little bit of leeway, particularly on the first pass. But I do support it as written.
MS. AZINGER: Leslie, can I put you on the spot. Do you think it would require two years to do a first pass?
MS. NOBILE: So the one we're doing right now is sending out 33,000 e-mails. And it's going to take us four months. That's with direct. Direct allocations and assignments. We've got over 400,000 reassignments. The policy says all POCs, which would include all reassignments. So I could see that going well into two years or longer.
MS. AZINGER: Thank you.
MR. VIXIE: Right-hand mic.
MR. WOODCOCK: It's maybe not completely apropos. Bill Woodcock. DHS asked PCH to provide a budget for what it would do, what it would cost to do an independent verification of POC contact info for the ARIN region a year and a half, two years ago, and we came out with two years for the first pass and about five people to do the labor. That was assuming phone calls to follow up with anybody who didn't answer e-mail.
A question I had: Have you thought about the question of automated e-mail replies? Will automated e-mail replies from ticket systems be counted as sufficient response, or do you need a human to reply?
MS. AZINGER: I want to say they discussed that and said yes, automated would be valid. But I have to check. Sorry. I can post it to PPML with an answer.
MR. WOODCOCK: Obviously, if you wanted each POC --
MS. AZINGER: I haven't heard them ping up yet.
MR. WOODCOCK: You'd want each POC to be checked once only regardless of how many resources that POC was associated with, right? Okay.
MS. AZINGER: Yeah.
MR. VIXIE: Any more questions? From the remote.
MR. ANDERSEN: We have two remote. From Chris Grundemann: I have a clarification on the removal of data from WHOIS. The policy as written only marks unresponsive POCs as unresponsive. It does not remove them. It does allow for ARIN staff to remove POC records that they deem completely illegitimate. This is intended to be POCs to which ARIN staff have made multiple attempts to contact with multiple methods.
Want to do both at the same time?
Then Jo Rhett again from Silicon Valley Colocation: I would normally agree with Leo, but on this I do not. There is a difference between can send mail to ARIN and answers mail to this address. I'd like to see us test the latter.
MR. VIXIE: If you're going to speak to this proposal, I would ask you to please queue up now. I'd like to close the microphone and get on with -- so on the right-hand side.
MR. FLAIM: Yes, Bobby Flaim, FBI and ARIN Government Working Group. I think the proposal is very good and the idea in the fact that we're trying to clean up the WHOIS and get more accurate information as an agency that relies on the WHOIS as one of its tools. And I would echo with what Bill Woodcock said in so far as if you're relying on that information, I think we need a point of contact. If you delete it altogether, then it kind of hurts us more than helps us.
So I think it's great. I just think that we need to resolve the issue as just putting unresponsive and deleting the whole POC altogether, that we would just want to go a step further, whether it be you're in violation of an RSA and there will be repercussions of that or you can leave the POC in there and on the side mark it unresponsive so you have both there. Because any type of information in the WHOIS is always a clue, whether it be false or inaccurate, at least that gives us a starting point even with the point of contact.
MS. AZINGER: I have to be nitty. Don't walk away from the mic. I have to be nitty. I'm curious, because I don't know. How would having a completely invalid, untouchable name help?
SPEAKER: The FBI might have expertise in finding people that ARIN folks don't?
MS. AZINGER: Can you answer the question? I'm sorry.
MR. FLAIM: No. I mean, every little thing, even if it's a false name, we can obviously check our own databases and see if that false name is in there if it relates to any other case, it relies to any other investigation. And that might give us a clue or a starting point, where if there's nothing in there there would be no starting point.
MS. AZINGER: So it realistically would help the FBI in their matters, then. That's good to know.
MR. VIXIE: Just to note, the microphones are closed on this topic. Right-hand side.
MS. DRYDEN: Thank you. My name is Heather Dryden and I'm working with the Canadian Ministry of Industry and I'm also part now of the ARIN Government Working Group. I wanted to comment particularly on what was actually just discussed immediately prior to my speaking, and that would be the prospect of deleting entirely that record.
I would want to be assured that sufficient consideration has been given to the impacts of doing that. Bobby talked about the impacts on law enforcement, and Canadian law enforcement certainly would have the same concern in that regard.
MS. AZINGER: Thank you.
MR. VIXIE: Any -- Bill, I closed the microphones. No, go ahead.
MR. DARTE: (Inaudible) ARIN AC. I was going to say whether you removed the POC information that's there or the record in its entirety doesn't necessarily mean that you couldn't keep a record of that in case inquiries were necessary later on, it seems to me.
MS. AZINGER: I think, Bill, though, by talking with the FBI with other past stuff, that's one more step they'd have to take to get that list. Sorry. Speaking for you because I know I've talked to you in the past about different issues.
MR. VIXIE: Thank you, Marla. So a couple of reminders. You know that ARIN is not a direct democracy. And we're about to ask for a show of hands that is not so much intended to be a vote up or down on whether this policy will succeed as it is to be guidance to the ARIN Advisory Council, who really needs to know a lot in order to sort of guide their decision as to ultimately whether to forward this policy to the board.
So that having been said, we have a couple of tally takers. And I'm going to ask -- wait. One other reminder. This policy is frozen. Things are frozen before the meeting. So what you're being asked to comment on is not some version of the policy as you may have been modifying it in your head while listening to this discussion, but the version that is printed in your handbooks. So I'd like to have a show of hands. First I'll ask for those in favor of the policy as written and then I'll be asking for those opposed to it.
And so let's start with those in favor. And as John used to say when he had my job, hold them high. Thank you very much. You may put your hands down. All those opposed to the policy as written, please so indicate. That's a wrap. Thank you.
MS. AZINGER: Can we do clarification to see how many people would be in favor of changing it to two years and changing it so it's marked invalid and not completely deleted?
MR. VIXIE: We have two additional questions. First we want to know if the period is two years, initially, and I know the discussion was two years initially and then one year after that, assuming that we get caught up and it's easier the second time. But the question is specifically if we're going to take two years to do this, does that -- let me see here. Nate, come here.
Sorry, I'm new here. So looking for people who would be in favor of this policy if it were modified to have a two-year first period rather than a one-year first period as written. So those in favor hold your hands.
Okay. Thank you. Those who still would be opposed to it even if it were -- yeah, you get the idea. Okay. Thank you. Marla, remind me the second question you wanted posed?
MS. AZINGER: Being marked invalid. Not completely deleted.
MR. VIXIE: So in the discussion it was pointed out that we don't have to delete things we can leave them there in case the fact that it's invalid is nevertheless interesting information. So if the policy were changed in that way, please raise your hand indicating that you would support it.
And those who would be opposed even in the case where old information was to be marked invalid.
Okay. Thank you.
I have been advised to identify myself. As I said, I'm new here. I'm not John Curran, so if you're taking notes online based on this audio feed, this is Paul Vixie speaking.
While I wait for the number to come forward, I just want to say this is one of many things that seems like a really simple problem until you try to solve it. And then all these hairy corner conditions come out. Everybody wants clean WHOIS. Not everybody is going to understand exactly what that's going to mean. We've apparently given Mr. Stratton a hairball to untangle.
Yeah, it's a hairball. We have 95 in the room and 16 remote. And so of that as written, without modification, I'm just going to give you the totals. Doesn't really matter who was in the room and who was remote.
We had 48 in favor and 12 opposed. Now, as modified, to have a two-year period instead of as written, it was 36 in favor and 10 against. As modified for keeping the old contact information but marking it invalid, we had 53 in favor and nobody against.
Had I wanted to make Stratton's job even harder I would have said what if both of those changes were made. But, frankly, we're not going there.
An Analysis of ARIN NetHandles with OriginAS Data Co-authored by Okhee Kim, Kotikapaludi Sriram, Oliver Borchert, Patrick Gleichmann, and Doug Montgomery
MR. CURRAN: Okay. So back to our agenda. We actually have an exciting presentation coming up. Next item on the agenda is an analysis of some of the ARIN data based on OriginAS. We have Dr. Sriram.
DR. SRIRAM: Kotikapaludi Sriram: My name is Sriram from the National Institute of Standards and Technology. This is joint work with my colleagues at NIST. What we'll be looking at today, a couple of things. According to the agenda it's Analysis of ARIN NetHandles with OriginAS information in them.
I will also present in addition briefly some analysis that we have done for the registry data in general, the RIR, inetnum, aut-num, NetHandle, ASHandle, those objects, as well as the routes registered in the RIR/IRR or the standalone IRRs. So we'll go into both of those areas today.
The problem statement, we'll begin with that. We'll look at the ARIN NetHandle OriginAS analysis and then we'll look at the analysis of global registries. And so through this process we'll also be looking at comparisons with announced BGP information; namely, what prefixes go with what origins in the BGP updates that we see on the network.
The problem statement is currently we know that the registry data is considered to be inaccurate and incomplete. However, in spite of its weakness, it is used for local route filtering and also for debugging purposes.
And to our knowledge there hasn't been a comprehensive investigation into the quality of this data. So we have been doing this for the past couple of years. The purpose is to try to report on the quality of the registry data, compare it with what's announced in BGP, and based on that feedback hope that the routing data quality improves so that we can have robustness mechanisms, BGP robust mechanisms that rely on them and have those mechanisms work effectively.
I want to mention earlier at NANOG 45 we gave a presentation on performance of these robustness mechanisms which depend on this type of data. So I would like to refer you to that presentation NANOG 45, if you are interested in understanding the types of BGP robust mechanisms that are being discussed and researched and how they may be impacted from the quality of this data and how they would impact -- improve substantially if the quality of the registry data can be improved.
This shows the registry data object count by source; namely, ARIN, APNIC, et cetera. A lot of numbers here. But I just want to point out a couple of key numbers here. It shows comparisons between June of 2007 and October of 2008. The increases in the various registered object numbers.
The numbers in green are ARIN SWIP NetHandles and ASHandles, and the numbers in blue are the RPSL information.
Couple of things I want to point out is that ARIN has grown the NetHandles by about 300,000, from 1.6 million to 1.9 million, about 19 percent increase over this period of 16 months.
And there are RPSL route objects, too, in ARIN, and they have grown from about 7,000 to 8,000, 12 percent increase. Now, of course, other registries, for example, RIPE has a large number of routes registered, over 89,000 of them in October of '08. So ARIN is lacking in registration of route objects. But that's being compensated to some extent by the inclusion of OriginAS information in the NetHandles. And that is growing. I'll show that in a moment. We'll see the chart as well as analysis of NetHandles with Origin in them in a moment.
So this is still some general information regarding the different types of registered objects. This shows the distribution of the prefix length for different registries: RPSL and SWIP in ARIN. A couple of things to observe here are that we have these local peaks at /16, /24 and /29, in terms of prefixes registration in RPSL or SWIP. Also we notice that ARIN, SWIP and RIPE, inetnums track very closely with each other. And the key here is that the peak is at /29.
If you compared that with the prefix distribution in the route IRRs the peak is at /24. That's reasonable because people don't intend to route a lot of more specifics than /24s.
This shows, if you just take the standalone IRRs, including ARIN, RIPE, IRRs associated with ARIN, RIPE, the major IRRs, if you exclude those and just take the standalone IRRs, which are (inaudible) in the Merit Network website, they have about 497,000 route objects registered. 33 percent of them belong to ARIN prefixes. So that's a fairly good number there, route objects related to ARIN prefixes but registered elsewhere in the IRRs. APNIC also has a large percentage. RIPE has a small percentage but that is because the RIPE IRR by itself is of reasonably good quality.
This shows the NetHandle growth over time. It started in May of 2007 and now in April of 2009 it has grown from almost 0 to about 100,000 now. The total number, if you look at the ones that had multi-homed, meaning that the NetHandle has two or more origins in them, that is quite a small number, about 1 percent of the overall.
If you look at the -- now we'll start to get into comparing the quality, start looking at some comparisons between what is registered versus what is announced. If we look at the registry data from October 18th, there are 1.9 million NetHandles. And there are about 73,000 NetHandles with Origin information in them. So that represents 4 percent of the total NetHandles.
And if we look at the BGP updates over an overlapping period, say, from June '08 to November '08, there are about more than half a million, 530,000, prefix origins.
So those are unique prefix origins. So in terms of the primary purpose of NetHandles with OriginAS being the possibility of validating an observed prefix origin with the prefix origin registered in the NetHandle, we see that there is -- in terms of numbers, we are falling significantly short: 530,000 compared to only 73,000 NetHandles with OriginAS.
Now, some of these NetHandles -- this is just an additional observation. There are a small number of NetHandles which have some kind of a replication. It's the same -- they're different NetHandles, but they have the same NetRange and OriginAS information in them, but that number is small. And that seems to be happening when there is reassignment of the NetHandle. So the NetRange remains the same. The OriginAS remains the same, but the NetHandle ID changes. But that's a small number.
If you look at the NetHandles and look at how many origins are there in each NetHandle, the majority of them do have a single OriginAS. However, there are multiple OriginAS, substantial, in a good number of them.
Many of those could be legitimate multi-origin prefixes. However, in some cases it could be that the prefix owner is simply registering all these prefixes from all ASs that they own without necessarily intending to originate those prefixes from those ASs. And also in some cases they may have put the prefix to a different AS but the previous registrations have not been deleted.
Another point of observation is that if you lay out all the ASs on the X axis and the number of NetHandles with Origin on the Y axis, you will notice that there are about these ten spikes. There are about 10 ASs which seem to account for the bulk of the NetHandle registrations for the prefixes.
Here we are comparing the distribution of the prefix length in the NetHandle compared to what is announced in BGP through trace data. Again, we see that there's a very large peak at /29 for the NetHandles with Origin in them.
And comparing that with BGP trace data, the trace data has the peak at /24. This itself gives you an indication that because the bulk of these NetHandles have /29, they're not going to be readily useful for validating an update. When you receive an update you want to compare it with information in NetHandle with regard to the OriginAS, it's not going to be particularly useful.
Now, I will come back to that question in a moment and look at it in more detail and see what can be done to improve that. If you look at the distribution of ARIN NetRange address block allocations, this is additional information or observation that says that a few of these ARIN prefixes, a few of these prefixes actually belong to LACNIC. So the NetHandle is in ARIN but the prefix seems to belong to LACNIC.
But the bulk of them, the bulk of the prefixes do belong to ARIN. Now, we also look for consistency, meaning not only look at the NetHandle with the origin by itself. Also pick up the ASHandle that corresponds to that OriginAS in the NetHandle and see if the ASHandle is consistent with the NetHandle in terms of the kind of things that were mentioned in the previous two talks.
We look at mntner, we look at orgID, We look at the contact information. If they match, we call them consistent. Otherwise they are not consistent.
So if you go back to the previous slide and just look at the distribution of that with respect to what seems to be consistent and what's not, the majority of these NetHandles with Origin are not consistent, meaning that the NetHandle orgID or point of contact information do not match with the corresponding ASHandle.
Only a small percentage are there in which the origin is consistent, meaning that the NetHandle and the ASHandle are consistent.
Now, from here things do get a little bit more interesting in terms of comparing this data with what's seen in BGP or what is registered in the IRRs in general. Here we're looking at the NetHandles with Origin and comparing them with the route objects in RPSL, the various IRRs, including the RABDs and so on.
Here we are showing the percentage. So a large percentage, 79 percent, of the NetHandles -- the prefixes in the NetHandles are aware -- they do (inaudible) in the route objects with less specific. The route object is less specific than the NetHandle. So what this indicates to us is that if you just use the route objects, you might perform fairly well in terms of being able to compare those with what is announced, as opposed to making use of information from the NetHandles. So a comment at the bottom of this slide is for origin validation, ARIN RPSL route objects provide superior coverage than NetHandles with OriginAS.
So here we're only comparing the -- we're just looking at the ARIN IRR, the ARIN RPSL route objects, and checking to see if they would cover the prefix in the NetHandles. Yes, indeed 79 percent of the NetHandles, there is a corresponding route object where the route is registered and the prefix is there in a more, in a less specific form which is good. And we can do a quality analysis of that once again moving on. So this is again interesting. Here we are comparing ARIN NetHandles with OriginAS with what is observed in BGP trace data. Here 7 percent are unobserved and 5 percent are exact match, NetHandle and the BGP trace data. The prefix origins is -- it's an exact match. And in 1 percent it's more specific that is announced. However, in 87 percent it is less specific that is announced. So what this tells us is that if we look the other way from the trace data back into the NetHandle database, only the 5 percent and the 1 percent only, that 6 percent is usable in terms of trying to validate the prefix origin in the update. The other 87 percent, what is happening is that those are more specifics and we have a less specific in the update. And it is hard to look at all the more specifics and do a tracking to validate the update.
So the 87 percent is not quite useful, but the 5 and the 1, only 6 percent is useful. And of course this next slide closely correlates with that. The number of prefixes that are of length, 25 or more, we have 82 percent of those in ARIN NetHandles, whereas in what is announced in BGP and if we filter it based on ARIN address space, only 3 1/2 percent are prefixes greater than 25. And generally announced prefix origins only 5.5 percent of the prefixes are length greater than 25.
Once again based on the prefix length because of the predominance of /25 or more in ARIN NetHandles, the usability once again diminishes. Here we are showing the, if you consolidate, so you get the suspicion there are these 80,000 or 100,000 NetHandles. But if you consolidate, if you take prefixes and see if there is a super-prefix, less specific that is also there in the NetHandles with the same origin. So we can do that kind of a consolidation. So after that consolidation you get about 39,000, but even those 39,000, what happens is that when you compared them with what was is announced in trace data, they don't -- they are still too specific, what is announced is less specific.
Now, so that's about the ARIN NetHandles. We look at the global registry quality in general. Here we take the various objects, registered objects, NetHandle or aut-num, ASHandle or -- I'm sorry, NetHandle or inetnum, ASHandle or aut-num and the route objects, and we try to maintain -- compare the mntner object, for example, the mntner attribute, or orgID, or the contact information. And if they match across these different objects, then we would call them consistent, fully or partially consistent, or not consistent.
So we have consistency quality checks in terms of these types of comparisons. And it has -- it does well in RPSL in RIPE particularly because RIPE has this RTSS for security, indeed where those have to match in order to make these registrations possible for the user.
So this gives us some detailed data, but if you look at the next one, here we are showing the percentages of route objects for various registries: ARIN RPSL, RIPE, APNIC, stand alone IRRs. So what we see here is RIPE does quite well in terms of what is fully consistent in the registries between the route, the inetnum and the aut-num. Close to 70 percent are consistent, and another 22 percent are prefix consistent. And small numbers are not consistent or not registered.In comparison in ARIN RPSL, first of all, the number is pretty small. The number of IRR route objects in ARIN RPSL is about 10,000 compared to 80,000 in RIPE RPSL. But besides that, there's a good percentage, good percent in ARIN that are consistent.
But that is not adequate. It would be good to have a larger percentage that are fully consistent. And based on the previous two talks hopefully after the point of contact information is improved, because that is one of the things we use for checking consistency. ARIN, after those efforts bear fruit, the consistency for ARIN should also improve, but what is also highly desired is that the number of route registrations also increase in ARIN and that would be helpful.
So this is -- the next few slides are just a quick study on looking at the trace data and figure out what seems to be stable in trace data.
So if the prefix origin pairs remained in the RIBs for -- stably for 48 hours or more, we would call it stable. Otherwise, it is unstable. And this was over a period of six months of trace data. So if you look at that and separate the prefix origins observed into stable and unstable categories and then -- and for each of those you look at what is fully consistent, partially consistent, et cetera, in the registries, we get these plots.
So the big spike for APNIC and ARIN, the big spike at stable and not registered, what that means is that we see a lot of these prefix origins stable in history. But if you look in the registry there's no corresponding route registration.
Relatively, RIPE does well. So if you have -- here we are only looking at the RPSL route object in the corresponding IRRs of these registries. But if you broaden out and look outside, meaning if you -- you go to the standalone IRRs -- namely, the Merit Network database -- and look at all the IRRs, in that case you have many more route registrations available even for ARIN. So ARIN only had -- ARIN IRR has only about 10,000, 9- or 10,000 route objects. But outside in the standalone IRRs, ARIN prefixes have a large number of route registrations. So if we take advantage of that. It's slightly improves but it's not significantly. Still about 55 percent of stably announced prefix origins are not registered, even in the IRRs in general.
Another thing to observe is that we've noticed a large numbering of prefix origin pairs are registered but they're never announced. So globally there are on the order of half a million prefix origin pairs or routes that are registered. And in ARIN alone there are perhaps about 200,000 prefix origins that are registered, if you look at all the global IRRs. However 110,000 of them are never registered. So we started to question why are they registered but never announced.
So then we looked like one level higher; namely, we took the prefix and looked for super prefixes or less specific prefixes. And in a large number of cases, about 40 percent of these never announced prefix origins, the super prefixes announced with the same origin, and about close to 60 percent are announced with a different origin.
So what that means is that maybe the ISPs -- when the customers register their prefixes and the ISPs, it appears that they're doing some aggregation and reorigination. However, they have not cared to register the aggregate prefix. So that's one possibility.
And on the side where the prefix is announced with a different origin, the possibilities could be that they are stale, the information could be stale, or just that the prefixes registered with multiple origins by the owner. So, again, similar numbers for global prefixes.
To conclude, we would like to state that ARIN NetHandles with OriginAS, they are dominantly four prefix length greater than or equal to 25; however, announced prefixes are dominantly of length 24 percent. As you saw on that slide, the percentages are quite high. I mean, these two percentages are kind of on the opposite end of the spectrum.
And that is why as it stands the ARIN RPSL route about 10k of them. There are only about 10k of them. They could be in fact more useful than the NetHandles with OriginAS even though there are 100,000 of them.
So routes exist in standalone RABD but not enough even for ARIN prefixes. But there are not enough and they lack in consistency, whereas we have learned through informal communication that Verizon alone has about 60 different IDs. So we're looking for IDs to match. We're looking for point of contact or technical contact to match, and the consistency is failing.
For these various reasons we have not seen the kind of performance we'd like to see, but it would be greatly helpful if the IRRs/ISPs can encourage or support route -- more route registrations and encourage using consistent orgIDs and also support SIDR RPKI trials and testing. Thank you.
MS. ARONSON: Cathy Aronson, ARIN AC. I'm assuming, maybe I missed it, that this is v4?
DR. SRIRAM: Yes.
MS. ARONSON: Have you looked at v6 at all in any of these registries and the same information -- I'm sure there's not a significant amount of data, but it would be interesting to see.
DR. SRIRAM: Yes. Separately do a study for v6 even though the numbers are small, correct?
MS. ARONSON: Correct.
MR. SRIRAM: Point well taken. We'll do it.
MR. HUGHES: Aaron Hughes. Thank you very much for the analysis. It's quite useful. One of the fundamental issues about keeping this data accurate is an organizational business problem in that if you're, generally speaking, an allocations and assignment person and updating WHOIS data, you're not creating IRR objects for routing.
And while RIPE requests OriginAS in allocation data, this region does not. So people who work in assignments and allocations wouldn't put the OriginAS information in there. It just so happens I think that most objects don't move around too much, which is what makes the RIPE data fairly accurate.
And in this region it's particularly hard to get your peers to update IRR information. As an entity it's not too hard to keep your customers accurate, but getting peers to do it is like pulling teeth. And if you even suggest that you might apply a filter, they'll go, well, you're just not going to receive those routes, which also makes it difficult.
One comment on Cathy's note for the v6 information. I'm pretty sure I was the first person to e-mail ARIN and say: Hey, guys, I'm about ready to automate something for SWIP data; can you change your process so it's not manual? So I imagine there is very little to no accurate data in there since I'm pretty sure maybe three months ago when I did that I was the only one asking for that kind of service.
DR. SRIRAM: Thanks for the question. Any other questions or comments? Thank you very much.
MR. CURRAN: Okay. We have now two presentations on some initiatives inside at ARIN. One of them is on our business process update. So I'll turn it to Erika. Thank you.
MS. GOEDRICH: So my name is Erika, and I'm the Requirements Analyst at ARIN. And it's kind of odd to be up here not talking to you about elections, which I normally do. But I'm here to talk about business process reengineering.
And the reason for that is over the 10-plus years that we've been around, we've kind of -- our processes have been built where we've sort of added components and pieces to our system without necessarily taking a look at the big picture overall, and that's both in terms of our systems as well as the organization as a whole. It might be limited to just one department without taking into account how it affects the other departments. And so now that we're moving our services online so that you can manage your records and do all your transactions online, we're actually taking a minute to step back and say: Hey, can we improve our business processes as well.
So what is a business process, exactly? It's a collection of interrelated tasks that takes input and creates an output that is a value to the business and produces a specific result for the customer.
We're taking a look at work flow which is basically who does what and when.
And it was Dr. W. Edwards Deming -- he was a leader in the quality movement -- who said: If you can't describe what you're doing in a process, you don't know what you're doing. So we sat down and we said, okay, do we know what we're doing? Let's map out what our current processes are.
And when we started to undertake this, we went ahead -- I had several coworkers send this flow chart to me. It's a guide to understanding how flow charts work. And personally I think, if you see there's two boxes in the lower left-hand corner, that they just sort of end. And as you know flow charts, they're not supposed to do that. So I think there's two arrows that need to be added. Let's go drink.
But in all seriousness, what we did is we have what we call an Idea Room at ARIN. And it's a conference room that has actually four white boards. It's all around, it's white boards. We called all the service departments in -- financial services, registration services and member services -- and started to map out some of our processes.
This was one of our first -- the first process that we did. And you can see it was a little bit loud. We have arrows going everywhere. Shortly after doing this we realized we needed some help. We brought in a consultant, who luckily has better handwriting than I do, and also we got used to how to do this and things have definitely become more efficient.
After we do that, we then turn it into swim lanes, which I think is easier to understand than flow charts are. Along the left-hand side you have your different actors identified. The different squares represent the tasks that go on, and then you can actually see where handoffs occur because that's where it crosses from one actor to the next with the arrows. And so shows the actors, the tasks, the handoffs and the interactions between them.
So our progress report for going through our as-is processes, so far we've completed 23 and 6 are in progress, and we should have those finished I would say by the latest middle of next week. Once we get back and finalize those.
They've been starting but we just need to go ahead and finalize those. So what comes next? Next we have to do an as-is assessment, where we're looking at the current processes and saying what's good about them, what should we keep and what's not so good that we should either improve, replace or just get rid of altogether.
The thing that we have to keep in mind is that we have a lot of interconnections between the systems and processes, and we can't do everything at once, obviously. So we're taking a phased approach. And we need to keep those interfaces with the other systems and the dependencies with other processes in mind as we're going through this.
So some of the questions that we're going to be asking as we go through the as is assessment: Are there too many actors? Is the most appropriate actor handling the task? Are there too many handoffs and too much back and forth with the customer?
One of the processes that we mapped out has 137 different steps with 16 go-backs to you, the customer. Which I think it's a little bit rough. So we need to take a look at that.
Do the handoffs that happen introduce error, expense or delay? We want to determine where the bottlenecks are. Are things happening sequentially as opposed to where most steps or tasks could be going on at once? Are exceptions holding up the norm? Are there policies and rules in place, not just the NRPM policies but also our internal policies and rules that are causing issues or that we also need to keep in mind when developing the new processes?
Are there any non-value-added steps such as rekeying data or reconciliation between different reports to make sure it's right? Duplication and redundancy, are there manual activities that could be automated?
Lack of shared data, and are there any data structures that have inconsistent format structures or semantics. And then the as-is assessment also goes into hand-in-hand with developing the to-be process. And if you remember at the beginning what I described a business process as, in a related task that takes one or more kinds of input and creates an output that is a value to the business and achieves the specific result for the customer. So the question we want to ask is how do we want to organize our activities so we can minimize input, maximize outputs and maximize the value to you as well as to us.
So we're looking to increase efficiency and effectiveness, control agility and process compliance. Make sure everybody's following the same path through it.
We want to improve communication and cooperation, both within our departments at ARIN as well as with you, our customers as well as improved handoffs in the customer service that we provide to you. And we want to provide visibility into our process pipeline which allows us to do some operational forecasting and measurable results and allows for continuous improvement.
So that is what is on our plates, moving forward with business processes and taking a look at those.
MR. HOWARD: If I may, I wanted to suggest that this is probably the best explanation of business process engineering I've ever seen. And for network engineers who don't usually speak manager, this may just have justified the cost of sending you here.
MS. GOEDRICH: Thank you.
MR. CURRAN: Thank you very much, Erika. Obviously it's an important initiative, and one of the reasons it's particularly important is we're looking at what we can do for automation for ARIN, including self-service and online service. And when you take processes that have 136 handoff points and attempt to automate them, you don't actually achieve anything; you end up with 136 automated handoff points and no real progress.
MR. CURRAN: We're going to talk a little bit about what we're doing with ARIN online. But these two initiatives, one is fixing our processes and the other one is getting you closer to your data and making it so you can do more without having to involve people, let you do a little bit of direct control of your data.
So Andy has a demo. Come on up, Andy.
MR. NEWTON: As John said, this is the counter side to what Erika just presented about the business process reengineering. This is a part where we tried to implement it in software or parts of it in software. So this is our third presentation on our new capabilities on the website, which we're calling ARIN Online.
We initially launched the 1.x software back in October. And the major features we had in there are the wizards that allowed you to create and maintain POCs and ORGs. And if you haven't logged on to the website and gotten yourself a web account, then you ought to do that because it's really very easy to do with ORGs and POCs that way. Once you create the account you get to link to your ORG. It's a very good way of keeping things organized.
We also do fraud reporting. You can submit a fraud report via the online system, and what all that does is behind the scenes creates an e-mail for you. The legacy system is where you have an e-mail template that you have to fill out and mail in to hostmaster. The 1.x software is just doing that for you behind the scenes.
The 2.0 software, which is what we're currently working on, will have three new features. The first is ticket tracking. And then we will have an Ask ARIN feature and a Message Center. Now, the ticket tracking, we introduced a new series of tickets we're calling X series tickets. And I'll get into what they're about, but they allow more tracking of the tickets. But just like the old e-mail, you can send comments in any time. You can have file attachments, so all the old functionality is still there, it's just all via the web.
Our first endeavor to using the X series tickets was a feature we're calling Ask ARIN. What essentially -- what that is it's an area on the website when you log in you'll be able to ask some general questions and it will go to the appropriate department within ARIN, and it's broken down into nine categories. You can ask a question and it creates a ticket for you and you can go back and forth with ARIN staff until the question is answered to your satisfaction.
And then corresponding to that is a message center that we put in there. And it's linked to your e-mail address. You can receive the messages in the message center via your e-mail, where you can turn that feature off if you want. But that also links back into the tickets as well.
Along with all that, along with all the stuff we're putting on the public side of the website, we have new tools on the back end for our ARIN staff, which is also going to help drive the business process reengineering. But it's a strategy to consolidate a lot of our tools, which we're in desperate -- systems all in one place. We're not there yet, but we're getting there.
But this is what's going to enable us to do the business process reengineering. It's going to be one place for all the tickets to be viewed and you can have staff link to other tickets and so forth.
And of course it's going to be web based so we can have a richer experience with the ticket flow.
Now, you might be asking, you know, if you haven't logged on you might not understand what the difference is between all these ticketings, all these different types of tickets.
Essentially we have three different types of tickets now. There are the old legacy tickets, which if you've ever sent e-mail to firstname.lastname@example.org, you would have seen a response come back and the subject line would have been this ARIN-date.number. And those are what we called the legacy tickets. They are just e-mail. And once created, they simply exist. We don't delete them. So but they don't really have a status as far as e-mail is concerned.
Then there's the AOL 1.x software, which creates W and F series tickets; W for the POCs and ORGs, and then F for the fraud reports. Those look very much like the legacy tickets except there's a -F or a -W right before the incrementing sequence number.
But, again, as I said, what that does on the back side is it's really just filling out a template for you and e-mailing it to hostmaster on your behalf. So, again, it has the same characteristics of the legacy tickets where it's e-mail and simply, once it's created, it just exists.
Then we have the new X series tickets which we're going to introduce. These look like the F or W series except for F or W it's X. However, these will have a status associated with them whether the ticket's open, whether the ticket's closed, who is supposed to be responding to the ticket.
We can assign them to certain staff members, or we can assign them to roles within the staff. And it will all tie back into our back office workflow, which is part of the business process reengineering. And, of course, we can track them that way and we can also link them to duplicate tickets and there are all sorts of things we can do on the back end.
So let me bring up the website. I'll switch into Bill Gates mode here and demo software that has not been released. It's always very exciting.
So, again, this has not been released yet. If you go to the website you're not going to be able to do some of these things. But let me log in and show you how some of this works. Again, when you log in you're going to see the old POC -- first off, you'll see the new menu items. We have the Message Center right here. And then we have the Track Tickets and the Ask ARIN menu items. Those are the new things you'll see. But you'll have the old information as well. We haven't taken this stuff away. You can still manage your POCs if you want to. Can you modify them, create new POCs. You also have your organizational data and you can go in there and look at the ORGs that you are linked to because you are linked to the POC. But none of that has changed.
However, if you go to the Message Center, what you'll see is that ARIN can actually put some messages in your, I guess you want to call it an in-box. And a lot of times this will be a response from a ticket, and in the future it may be more than that. We may have sending you invoice reminders and so forth. We haven't gotten into the true requirements on some of that yet. But that's what we intend this to be. So here's basically a message that you might see.
Then there's the Track Tickets feature, where you will hopefully be able to see all the tickets you entered. Now these are, again, the X series tickets. But you can see here that this particular user has two tickets, one that's closed and one that's open, and just clicking on that you can go view the ticket. And obviously that's a bug. So...Let's see if this one works. Pre-release. So this is what happens when you compile software on a Sunday.
Anyway, so as exciting as that is -- then there's the Ask ARIN feature where you can go in and you can basically open a ticket with a general question about -- we have things divided up in nine categories, and you can ask a general question to ARIN and it will create a ticket for you and staff can respond to it.
Now, let me log out here and actually log in as the person I like to log in the most, which is my boss, Mark Kosters. When he's at lunch, I go in his office and look at his passwords all written down on that sticky note. By the way, it's kept right next to the sticky note with his credit card number, if anyone wants to know. There we go. So here I'm logged in as Mark. And I'm going to go to the Message Center. And when the software does get released for the first time and you do have the Message Center capability, this is going to be the first thing you notice. You're not going to have any active messages. You saw when I logged in before someone had messages up. You'll get this thing that says you have no active messages. There is an e-mail preference. Some people prefer to receive these notifications via e-mail as well and what that e-mail will do is say: Hey, you've got a message, click here, and bring you to the Message Center. Some people want to turn that off. So we've provided a preference for that. And you can change it at will if you want.
So let me go to the Track Tickets. If you go look at the tickets, when you log in for the first time, Track Tickets feature, most of you aren't going to have any X series tickets here. So this is what you'll see. You'll just see a page saying: You don't have any tickets at this time. And then when you do submit tickets, here's the type of tickets that you will see.
So nothing special there. Now, let me take advantage of the Ask ARIN feature. So here we have the Ask ARIN feature. And, again, this is the first endeavor into the X series tickets, and let me ask a question of the ARIN staff. I'll ask a WHOIS question. Which name? What protocol? I've been told that -- I can't see here -- that the WHOIS protocol name is nickname. Is this true? And so I hit Submit and you'll notice that there's a ticket number here with an X on it. It's an X series ticket and Erika is down here answering the question. But what I'll do, I'll switch to our back office management system to show you what's going on.
The staff will actually have their own management interface where they can view the tasks that have been assigned to them. The unassigned tasks are the tasks assigned to their roles depending on what department it's in and what subgroup within their department. You can see here I have a task assigned to me about someone who asked a question about the CRISP and IRIS protocols. Apparently no one wanted to answer that except for me. I go to the unassigned ticket list, there's a bunch of tickets that have been unassigned, and then I can go to the unassigned group and see who has been assigned what.
And that is it. Have you responded to the ticket, Erika?
I can look at the ticket and see what she's doing. All right. If I go back over here, log in as Mark on the public website, hit Refresh, and I'll see that I actually have over here in the Message Center there's a 1 by it, which means I have one unread message. I click on it. I have an active message that says: Hey, you got a response from this ticket. Click on that, and here's the ticket in detail. Where I asked the question, you know, I've been told WHOIS protocol is nickname. Is this true? And Erika responds yes, please read RFC 3912. And it says -- basically the information here says this is from me and that now the ball's back in my court if I want to respond to it. And I can close the ticket right here. That's a satisfactory answer. I'm going to go ahead and close the ticket. And that is it for the demo. I can log out. Or I don't have to. Let me switch back to the presentation.
When is this software going to be available? It will available real soon now. We're looking for a mid to late May launch of this software. It's in QA right now. And hopefully we'll have it up by then. We're on track for that.
That's not the end of it, though. The 2.0 will be followed by 2.2 and 2.3 and all that stuff. And essentially what we're going to try to do is transition all of the ARIN interfaces, all the ARIN tickets to X series tickets that can be tracked. So the first up after the Ask ARIN is the POC and ORG. So the current POC and ORGs will move over to X series tickets and you'll be able to see it in the ticket track and comment and respond, and ARIN staff will be able to comment and respond. And it will all be there right in the history.
Then we'll move into doing initial network allocations and renewals, et cetera, and all those other types of tickets we have. We're also going to put payments and billing information on the online system. We're going to do DNS management so you can be able to log in and tell us which name servers are used for which networks you have.
And then one of the things we get a lot of is requests for resource reports. A lot of people want reports on what resources they have with ARIN. So we'll have features online where you don't have to call in, you can just go to the website and ask for a resource report and it will be e-mailed to you. There's a whole lot more we are actually planning on putting in. Now, again, this is the third presentation we've done on this. I actually wanted to spend a little bit of time talking about the engineering that goes into this kind of stuff. Anyone who has ever done this will tell you this is kind of complex and ambitious.
What we're trying to do is we're trying to take a lot of functionality that exists in a lot of different software, put it into one place and get it all to work together. Well, to do that, we had to go out and add some new tools to our toolbox, because we had to increase our development staff for a short period of time to do this. So we have more developers and we needed ways to get them to work together without stepping on each other's toes.
So what we've done is we've decentralized a lot of the development resources. This allows developers to work independently of each other without like, again, I said, stepping on each other's toes. Once you did that you also have to make sure that the work they're doing is valid. We have a lot of unit and integration testing going on, and unlike a lot of unit tests which just tests logic, we're actually doing testing all the way from the web layer in putting values into the website all the way back into the database. So we know that once someone puts something into the website, it actually gets persisted into the database.
And we have a continuous integration server which actually goes out and makes sure that the software that we are developing, the different types of software we're developing, when they all have to link together, they do it right. And we know ahead of time that when problems occur as opposed to waiting until we have to drop to QA and discovering that things don't work. In fact, we're going to improve on that process and get the database layer involved in the continuous integration.
We've adapted methods from the Agile process. Agile really just means doing what really is required to get your software development to work. But there are some things in there that are specific, so we do scrums every day with both QA and the development staff. And we formalized a lot of our build processes and things like DDL and so forth so that any one software developer or operations engineer knows -- will be able to handle the common problems. And you don't have a lot of knowledge tied up in one person because you know they may be at home sick with the swine flu or something like that.
Of course you have to have QA. We have a QA department, Tim Maureen and Charlie, all back at the office right now entering bugs for the 2.0 software, and they're doing a great job. And that is it. Any questions?
MR. ANDERSEN: We have two remote questions. First on behalf of Ted Mittelstaedt of Internet Partners, Inc.: Is the 2.0 system templated on an existing open source ticketing project or is it rolled from scratch? And if it's JBoss, would it be possible once the 2.0 system is completed and debugged to submit the template code to the JBoss project for inclusion in their example section?
MR. NEWTON: The software we're using is open source. It is JBoss. The JBoss stack, we've actually established JBoss stack from the top all the way to the bottom. We use the JBoss application server. We have JBoss's Seam web framework and we also use their business -- what they call the Business Process -- BPM, Business Process Method or Methodology. It's called jBPM, is their implementation of it. And that is basically what keeps a state machine persistent in the database. I don't think there's anything we can contribute in that regard back to the JBoss effort. We do submit bugs to Red Hat when we find them. Haven't really found a whole lot of them.
There are things that we may contribute back to the community. The formalization of the DDL uses a thing called MIGRATEdb, an open source project which kind of went dormant a while back. We've actually gone in and added new features to it to get it to work the way we needed it to. We may look at that.
The things that made sense to contribute back to the community we can look at. As far as JBoss specifically, I don't think there's anything we have.
MR. ANDERSEN: The second question from Jo Rhett, Silicon Valley Colocation. Any chance of a rough interface so we can build our own tools to submit tickets directly?
MR. NEWTON: Very good question. Yes, we have thought about this. And in fact there's a BoF tomorrow regarding the future of SWIP. And one of the things we'll be talking about in there is a REST interface. I'll let Mark make any general comments about other REST interfaces for the rest of the system, but we have looked at that and obviously automating that kind of stuff is a -- something we'd like to do for the future even though we don't have a specific plan for it.
MR. KOSTERS: This is Mark, CTO of ARIN. One of the things I like to do is reiterate one of the plugs that Andy put out, that this BoF tomorrow night is really important in terms of we want to hear from you what we ought to do in terms of automation, especially when it comes to SWIP and turning that in and whether or not there's a better way of doing so. And if so we'd like to hear from you.
MR. CURRAN: Thank you, Mark. As people know, in the past we haven't always given a good view inside ARIN and what's going on and how it all works. We're trying to change that a little bit and give you some insight into the investments we're making to try to improve these structures supporting all this. We are doing a major push. We'll talk more about it at a member's meeting on Wednesday when we talk about the investments we're making in the organization.
But as you can see, we're trying to bring our systems up to a set of standards and a set of infrastructure with some good processes that will give us a framework that will really let us go forward. It hasn't been something we've been able to really talk about probably until this year.
So I thank you very much for those presentations.
MR. CURRAN: We'll need the people from next door to be here. We'll send some folks next door to get them. Okay. We're now on the afternoon. I still hear lots of people. We're going to start, because we're going to be on time.
So the next item on the agenda is -- after our break is the IPv4 Recovery Fund policy proposal 2009-4. And this is to present this policy proposal and get feedback from the community.
2009-4, the history: Was proposed on the 21st of November 2008. And it's been through Bridgetown, Barbados, policy meeting we had. And the draft policy with staff and legal assessment was done 23rd of March, and the current version is 9 April. So it's the policy proposal you have in your packet. This doesn't have a comparable in any of the other regions. The AC Shepherds are Cathy Aronson and Bill Darte.
So summary: Requestors who qualify for all IPv4 address space may place binding bids for the approved address space. ARIN can qualify financial incentives to organizations -- can offer financial incentives to qualified organizations to return unused or unneeded addresses. The policy takes effect upon exhaustion of the IANA /8 free pool.
Staff assessment: Legal risk. Counsel notes that nothing in our articles of incorporation or bylaws prevents this policy. However, it's a significant shift in ARIN's activities by requiring ARIN to build business capabilities and undertake legal risks that are quite different from our existing business and expertise. That's literally this opens up some areas that may not be well understood, and we may not be able to see until we enter.
Staff issues: What if the requester doesn't pay? Good open question. Cost recovery needs to be clearly defined. And this doesn't address cross-region or out-of-region bidders and how we handle that. This would be a significant impact because pretty much this would need significant systems investment: guidelines, policies, reporting, registration procedures, fee schedule, and the implementation of all of that.
It's 18 person months. That means it would be -- it wouldn't be 18 clock months, but it would be several months before we could ramp this up. We'd obviously have to do that in order to be ready for when that IANA trigger condition occurs.
Okay. PPML discussion: Generated a little bit of PPML discussion. 18 posts. Sorry, 58 posts from 18 people. Three in favor. Four against.
I think that, regardless of the exact mechanisms of transfer or bidding, ARIN should operate as a listing -- voluntary listing service as done in the real estate industry.
ARIN's goals should be make the database as accurate as possible, and little else; take the time and money that would be spent playing matchmaker and use it to validate POC data or promote v6 instead.
And why don't we just combine 2004 and -- 2009-4 and 2009-2? ARIN could use the remaining stock of address space and sell it to the highest bidder via the policy in 2009-4.
Some of the innovative comments we received. At this point I'm going to turn it over to Leo to do the presentation. Thank you, Leo.
MR. BICKNELL: Hello. My name is Leo Bicknell, and I'm going to talk to you about 2009-4. And this proposal I want you to, for a moment, think different, to borrow the Apple slogan.
What I tried to do was approach the problem of the end of the free pool and the various issues with transferring IPv4 resources from a little bit of a different point of view. So what this proposal does is it provides an alternative to a straight transfer policy. And by that I'm referring to some of the things we've talked about in the past, 2008-2, 2008-6, and even 2009-1. And in viewing this differently I was then able to accomplish a few different goals. One of the most important was to lower the total risk to all participants. I think all of the other proposals are focused on lowering the risk to ARIN and may in some cases subject community members to additional risk, and so this was to look at a more holistic view.
Some other things are to leverage ARIN's staff experience, work hard to maintain the transparency that has been a core part of ARIN's process. Minimize changes to the existing ARIN process. While this is kind of a new thing, you'll see that from an external view of the organization, I'm trying to keep things the same as before. Make it easy to understand as a result. Provide some controls for deaggregation and such. And, lastly, ensure a smooth transition from v4 to v6.
The first thing I want to do is I want to go through a brief little thing on how this works. Unfortunately, due to the way this proposal is structured, it is a little difficult to read it on paper and get a complete picture of how it works. I'm hoping with a couple of diagrams here I can really shed some light on how this is envisioned. So what I'm going to do first is just illustrate how a request is processed today to familiarize yourself with the diagram I'm going to use.
Today you would make a request to ARIN for IPv4 resources and ARIN may ask you some questions and check your diagrams and all the things that we're familiar with. And at the end of that process ARIN is going to hand you back some IPv4 resources. So this is the process that we're all familiar with.
Let's see how that changes with this policy. So what happens with this policy is same as before, you send in a request to ARIN for IPv4 resources and ARIN's going to look at that just as before, check your network documentation and all the things that they do today. Nothing's changed. And, however, instead of sending you back an IPv4 resource, they're going to send you back an approval saying that your documentation is good and ask you to place a bid for the recovery of an IPv4 resource.
You'll then go out and look at the ARIN website for historical information on the pricing of IPv4 resources based on what past bids have been and what transactions have closed at. And based on that you will make a bid for how much you're willing to pay to recover the prefix. And this is a binding bid. So in this case I'm using completely made-up numbers. I don't expect anybody is going to sell a resource for $5. Didn't want to argue over prices. But in this example we're going to show a $5 bid for a resource.
Now, the first thing that I want to carefully illustrate is this a completely made-up slide. The numbers don't mean anything. But this is how ARIN's staff may actually end up viewing this on the back end. And although the diagram shows one bidder, because if I try to make a diagram with 400 bidders, you couldn't understand it.
ARIN staff is going to get bids from lots of people. They get hundreds of requests a day, a week, I don't know the exact number. But these people are all going to bid. So they're going to look at a summary of, by prefix size, how many people bid and what their bid amounts were.
Now what's going to happen is ARIN has collected this large number of requests and bid information and we're going to introduce a resource holder, you can now see at the bottom of the screen. This resource holder -- I'll use an example -- might be, for instance, an end-user organization which today has to meet a 50 percent usage threshold under the policy.
And perhaps they're using, say, 60 percent of their resources. So they're fully compliant with existing ARIN policy. However, they are in fact only using 60 percent of their resources. So they may well be willing to transfer 30 percent of their resources away in return for some compensation for their trouble of renumbering in order to do good things for the Internet.
So what ARIN is going to do here is ARIN's going to look at all those bids and publish a offer -- for instance, in this case I'm putting $3 on it; again a made-up number -- that ARIN will, say, pay $3 if you are willing to return to ARIN a /16, let's say. And ARIN will probably put that on the ARIN website. But there's nothing in this policy to operationally restrict it to the ARIN website. They could e-mail it to POCs. They could put an ad in the Wall Street Journal. Whatever is operationally effective here to contact people should be done. So ARIN will make this offer. And the offer goes to all resource holders, not a specific resource holder -- again, on the picture I can only show one, so we're going to track one specific resource holder.
So what happens is a particular resource holder, the one in my picture, is going to say yes, I want to take advantage of this. I want $3 and I will return a resource. So ARIN is then going to go off and check that there is some sort of contract in place to cover this and it's going to double-check that they own the resource in question and agree to the deal. So at that point ARIN will send them a check for the $3 and this particular resource holder will return that resource to the pool of resources.
Again, there's only -- there's more than one resource holder so what ARIN is going to look at is again a summary of address space they've recovered. This again is sort of the staff behind the scenes picture of this, at the end of a day, a week, a month, whatever. They're going to look at this table of we've recovered these resources, we had to pay so much money to get them returned to ARIN back into this recovered pool of addresses.
And they're then going to take that information and decide who has the best bid to get the resource in the policy that is described as both trying to stick with first-come, first-served, but if that does not work because the bids aren't high enough, then to move on to the highest bidder.
So what's going to happen then and in this example the particular requester at the top is going to be the winner in this case, just to complete the picture, is ARIN's going to go to them and say it cost us $3 to recover the resource that you bid on.
The bid is in fact binding. This is one of the aspects of the policy. When they bid $5, way back at time two, that $5 bid was a binding bid for 60 days. So if ARIN comes back within 60 days and provides them a resource at $5 or less, they are required by the contract, when they bid, to take that bid.
So this is the first of a couple of protections against ARIN getting stuck with a resource. That's been a concern by many people on the list.
The bidder is then going to send a check to ARIN to cover the $3 that it actually cost for the resource, and finally we're right back where the policy ends up today. You're going to get your spiffy new IPv4 resource that you can go off and use for whatever it is you use IP addresses for.
A second thing I want to illustrate real quick in terms of ARIN getting stuck with address space, is what I've done here is simply copied the number of recovered address blocks and the number of bids from the previous two made-up tables.
What I want to illustrate here is this policy enables ARIN to go recover space only to the extent that there are bids. If ARIN doesn't have a bid, ARIN isn't going to go recover space. So ARIN has only gotten this space because someone has bid on it. So they ought to be able to send it back out to a bidder to be used. So it's unlikely they'd get stuck with space. The reality, though, is going forward, if you think about the situation, we're going to have more and more efficient utilization of address space.
So over time we should collect lots of bidders and have fewer and fewer people willing to relinquish resources. Also, in the event that somebody doesn't want to take resources, they renege on that binding bid, in all likelihood ARIN can go down to someone else on the bid list and transfer that source down to them.
I think the actual operational case of ARIN getting stuck with a resource that no one wants is extraordinarily unlikely and can be largely prevented by staff carefully monitoring how many bids there are as they go do their recovery activity.
You might say: Why is this important? Why should we do something different than a traditional transfer policy? Well, there are four key points that I think make this key policy different -- and, of course, in my opinion better because, well, I wrote it -- than a traditional transfer policy.
The first is the way ARIN enforces the community rules is via contracts. We find the RSA. The RSA says you have to adhere to all of ARIN's policies and procedures and all that. We're not the government. We can't just say this is law and if you don't do it we're going to throw you in jail. It doesn't work that way. We enforce things via a contract. And one of the problems in a traditional transfer policy is that the two parties who are transferring address space find themselves via a variety of mechanisms outside of ARIN.
And so the question becomes what if those two parties write a contract that is somehow contrary to our rules? Because after that transaction is complete, ARIN is going to get involved and be asked to transfer the WHOIS record, update the data to the new owners there. And potentially, if you look at this triangle, there could in fact be three different contracts involved here. It's not hard to construct a situation where those three interactions take place under three different contracts. That, to me, just seems to be a bit of a messy situation and should a dispute ensue, a recipe for lots of confusion. The confusion presented by this policy is that both parties are going to deal directly with ARIN. So we go from three contracts to two, and in fact those two contracts are likely to be things that already exist, things like the ARIN RSA that we're already very familiar in and know how they work.
The second thing in a traditional transfer policy is that those who need address space and those who have it have to somehow find each other. And we've heard a whole lot of different ways this could happen. eBay comes up. 2008-2 had in it the concept of an ARIN listing service which has been talked about elsewhere. You could plead at NANOG that you really need something. We've even talked about the fact that brokers might show up on the scene and take care of this for you.
Well, it seems to me a simpler solution is just go to ARIN. We already have mind-share on this. We've spent, what, 13 years, 12 years, I forget exactly, saying to the world: If you need addresses in the North American region, go to ARIN, and this policy completely continues that. There is no mixed message to the public and the community as to what is a legitimate and illegitimate address. If you're not dealing with ARIN, it's not okay. The other thing about this particular structure that I think's important is if you have two entities finding each other, those two entities become linked. You probably have all dealt with this in real estate transactions or business transactions. You sign an MOU, you go through the motions, you complete a transaction. Right. Once that process starts, you are linked. If one of the two parties involved gets hung up -- for instance, they didn't bring their checkbook or they don't have their documentation in order or whatever -- the other party gets stuck as well. You end up beholden to the person you have decided to do a deal with.
In this particular case, because the two parties are dealing with ARIN, they can be decoupled. Remember, ARIN is dealing with hundreds or thousands of people who want IP space, and hundreds or thousands of people who want to relinquish IP space at any one point in time. So if one of those transactions gets held up, it doesn't need to have a ripple effect out the other side of the process.
The third thing is in a traditional transfer policy, to me there is a prime place for fraud to take place. And that is the people who perpetrate fraud like to perpetrate fraud on those who are uninformed. The guy selling fake Rolexes sells them on a street corner in New York City. He doesn't walk into Tiffany's to the jewelry counter and try to sell them to the trained watch guy, because he is going to spot they're fake. The people who do this kind of activity look for the uninformed who they can swindle, essentially. Well, in a traditional transfer policy, remember that party A and party B are going to find themselves completely outside of ARIN potentially. Somebody's going to put an ad on eBay and say: I've got this and we can complete the transfer through the ARIN process.
This to me provides a prime case for fraud to happen. While many of the people in this room are very familiar with the ARIN process, you probably have customers who may come to ARIN once every five or 10 years and get a block and otherwise not deal with addressing matters. And I am definitely afraid that there will be situations where those folks can be taken advantage of by those who want to do bad things. And, again, the solution's kind of the same thing that happened before, by dealing with ARIN -- it's like the guy dealing with the Tiffany's watch guy -- ARIN's experienced in this.
Leslie stood up and told us about how some of the people have tried to swindle ARIN in the past. And they've gotten pretty good at detecting when people submit false information. And they're really the only entity in the entire community that has direct experience today with dealing with those sorts of bad actors.
Lastly, I want to talk about aggregation. And, no, that's not a misspelling; we're usually talking about deaggregation. This proposal does provide some limits on deaggregation. But I actually want to talk about the other side of it which has not been present in any proposal to date. I've put up a proposal of a set of eight Class Cs, if you want to think of them that way, and different corporations that may own those resources. Now, under this proposal, ARIN may go out and offer $2 for the return of a /24 network. That's well and good. People will see that, and some number of corporations will stand up and say: That's what I want to do. I'll return my address space. The problem is what you're left with you still can't aggregate. And, you know, if you look at a traditional transfer policy, the likelihood that somebody's going to buy two netblocks that happen to be adjacent and happen to be on the right bit boundary to aggregate them, well, that's kind of a little farfetched.
But ARIN is in very much a unique position here, because after those networks have returned the space, ARIN can actually look at the picture that's on the screen today and realize that Corporation B is standing in the way of being able to do something better with the address space.
So we can envision a conversation that goes like this: ARIN may call them up and say, Corporation B, can you return your space? Maybe they didn't see the advertisement in the Wall Street Journal. Maybe they didn't read the ARIN website. Maybe their e-mail goes into a black hole. So let's call them directly and see if we can't do anything. Well, in all likelihood they did see the e-mail and they don't want to do anything. They're using their space. They can't give it up.
ARIN can make an offer here that nobody else can do. ARIN can effectively pay for the return of that netblock and then immediately reissue them a new netblock.
So in this case I show that ARIN may offer a dollar in this case to renumber in the alternate space. And in this case I show you a corporation that's willing to take up that offer. So what happens here is that Corporation B gets renumbered by ARIN, thus creating a block that is able to be aggregated. So now ARIN is able to take this free block and aggregate it up in a larger block and offer that /22, in this particular case, to someone who needs IP resources.
I'm not going to stand here before you and say this proposal is going to allow ARIN to put back together a /8 and make life good. But the reality is we all know there are I think three or four or however many /8s of swamp space given out back in the day and there's an awful lot of /24s that most people have written off as there's absolutely no way to aggregate back together.
And I submit that this proposal actually provides a mechanism where some of those could be aggregated at least to a small scale, maybe into /22s, /21s, something like that, and make a small improvement in the table size during this process.
So, to summarize, there are four key differences in this proposal. It directly maintains ARIN's policies via contract. It eliminates dependencies between the buyer and the seller. It leverages ARIN's experience to control bad actors. And it provides a mechanism for aggregation. And I suspect there will be probably a question or two.
MR. RYAN: I'm Steve Ryan. I'm ARIN's counsel. And the quote that was put up on the legal assessment doesn't begin to tell you how profoundly concerned I am about this policy. If I divide the policy into two aspects, there's a part of it that I think would be very good for the community, the details of which have to be worked out very carefully, which is to provide a listing service so that buyers and sellers can find each other.
Along with a listing service a profoundly helpful thing would be if we provided standard language that if people used, it would be recognized in a standard way both by ARIN and by buyers and sellers as having been carefully enumerated and vetted and banged around in a room like this.
That said, I will recommend that the remainder of this policy not -- even if the community were to pass it, I would recommend that it would breach the fiduciary duty of the Board to accept it.
I want to be clear why I'm concerned about this so that as you go into it -- I think it's helpful if -- Leo, actually, if you can give an answer to it, I wanted to give you the opportunity to rather than just come up at the end and say, you know, we can't do this. But let me say what the problems are.
First of all, as I understood the policy, at least the first time I read it, it calls for staff to speculate and to go in to buy things in the market and hold onto those assets and then sell them on another day. I disagree with us having the expertise to speculate and buy.
Second, the amounts of money that are going to go through this account will make us look like a real estate brokerage house during the condo madness sale where we could be clearing hundreds of thousands of dollars on a transaction.
Let's say it's a /16 that's very attractive and it's going to be a six-figure number. And so ARIN would then have economic responsibilities to accept those and then wire transfer them out and be the closing attorney, if you will, looking at whether this all agrees. And I know we're going to get sued over that. I know we're not going to do it 100 percent correctly.
I also know that there's going to be a disappointed buyer who is going to be looking at what he hoped to get by being a bottom-crawling, you know, carp and bidding on something and someday he's going to say, well, there was an opportunity for you to sell that to me or for me to get that but you didn't do it because you're incompetent in how you did it, which may or may not be true, by the way, but it's a great country and you can be sued.
So I don't want to deal with this issue of us being the financial transactor here. I think it's profoundly risky. We have a 50-person organization and a budget of under $15 million or approximately $15 million. I see huge financial and legal risks in this area that I believe we'd be much better off if we bifurcated, used the very good thinking you've done for a listserv and/or standard terms and that activity. If this is justified, it would only be justified, frankly, after we've profoundly worked out the bugs of just being a help to the community in that area.
That's a legal -- the legal judgment is I will die in the road before I will agree to this.
MR. BICKNELL: I'll respond to part of that. I've got three items. The first one I think is actually the easiest. I think describing ARIN as speculating is not an accurate description, in that this isn't like for instance a commodities market where you might go buy pork bellies and hope a week from now someone shows up wanting bacon.
In this case, ARIN is going to get binding bids ahead of time. They're not going to buy something without having already pre-identified a buyer. There is no speculation in ARIN wondering will there be a buyer in the future. They already have a binding contract with the buyer before they even go start to do anything.
So I think the word "speculation" there is wrong. It's not to say that there isn't any risk. Clearly this is a continuously shifting sand of prices change and buyers and sellers come and go.
But I think that there are ample protections in the policy. I see three different layers that would prevent what I would consider speculation from being a problem.
Regarding the other two, there was some discussion on the list about how the money flowed. I admit that I probably did not give that the detailed thought that I should have given in this policy. But I also think that there have been some interesting proposals on the list.
This particular proposal right now requires ARIN to pay for the return of a resource before it receives the money from the buyer. And, granted, those are only hopefully a day or so apart. But that's still a net negative that has to be funded.
People on the list have proposed things, for instance, deposits up front. Or you know having to put the money in with your bid and getting a refund of the amount that was not used.
I think there are a number of economic ways to solve that, and I would hope we could address that without fundamentally changing how the policy goes together.
That said, I do agree with counsel that this is increased risk to ARIN. I'm not going to try to argue that point. My perspective on this is that while it is a small increased risk to ARIN, it is a huge decrease in risk to all of you and everyone else who may participate in this system. My view is it's a method through ARIN and greatly reduces it to all of us. But the side effect of that is slightly increased risk to ARIN as an organization.
MR. VIXIE: Question, please.
MR. ANDERSEN: Steve Feldman asks: Is this proposal intended to supersede 2008-6 and 2009-1? And, if not, how would you see them co-existing?
MR. BICKNELL: When this proposal was written, 2008-6 was still a proposal and 2009-1 did not exist. So it was intended when it was written to be standalone as if those two did not exist. I have had some initial conversations with a few people as to how it may exist or not co-exist with those proposals and I don't think we've really reached a conclusion yet. That was the perspective of how it was written and that's something that needs to be considered.
MR. VIXIE: Left-hand side.
MR. SPRINGER: John Springer, Inland Telephone. Leo, where do you see the cost for things like title, liability insurance, and fitness for use being borne? Would those be borne by the seller or by ARIN or by the buyer?
MR. BICKNELL: Something really extremely difficult both to write down and to show you in a presentation is the cost recovery section. You can see there was a great deal of discussion about that online. And I think the easiest way to describe that is that every six months at the meeting the ARIN treasurer stands up and gives a treasurer's report on ARIN's financial state, and part of that is sort of the cash reserves in the bank.
My intention is that this proposal not increase or decrease this. This proposal is supposed to be self-funding. And I had some other examples, but, for instance, to go back to my example, if it cost ARIN to retrieve a resource $3 and ARIN was able to determine that in terms of additional staff they hired and insurance that they had to purchase and all of those other things that go into doing this activity, that it cost $1 to recover that resource, then ARIN would charge the ultimate recipient $4.
The total cost would be recovered of this activity, whatever that cost is. Whether that's insurance, a person, their PC to do the work, whatever it is.
So to directly answer your question, the cost would be borne by the receiver of the resource.
MR. VIXIE: Next question.
MR. ANDERSEN It's a comment from Ted Mittelstaedt on behalf of the Internet Partners, Inc.: I'm concerned that this policy would encourage ARIN to scavenge IPv4 from existing assignments from contactable POCs instead of scavenging blocks from abandoned IPv4 because it would more or less -- because it would be less work for ARIN.
I would be much more comfortable with this language if -- sorry. I would be much more comfortable with this if language could be added that would require ARIN to only advertise for address space from POCs after all reasonable efforts have been made to glean IPv4 resources from the existing abandoned and questionable resources that are listed in WHOIS. Other than that, I do prefer if paid reclamation efforts are made that they're done through ARIN via mechanisms like this policy rather than third-party to third-party. And while I mostly agree with the lawyer's assessment, I do strongly feel that this proposal -- if this proposal is modified into a listing service, this essentially allows third-party to third-party transactions that we -- and that we make it clear that only third-party to third-party transactions that are vetted through ARIN in advance will be deemed by ARIN as valid.
MR. VIXIE: Cathy.
MS. ARONSON: Hi. Cathy Aronson, ARIN AC. And also I have two parts to my comment. One is just as me and the other one as the shepherd, one of the shepherds of the policy.
The first thing is when we've talked about this, if you go to the guy who is using 60 percent of his address space and you want to get that other 40 percent, that could cause an interesting amount of deaggregation that really isn't included in this.
And as the shepherd, we kind of knew -- no surprise -- that Steve was going to say what he said. But we still wanted to present this, because we still really feel that the feedback that we've been getting will be a useful mechanism to move forward with a listing service or whatever we end up having, even if we don't end up with the money exchange and we really don't want Steve down on the side of the road.
But we really want your feedback.
MR. BICKNELL: On the deaggregation front I didn't cover that in the presentation. There is text in the policy. And it punts back to ARIN staff. And I don't mean that to be a copout. I mean that because I actually think the community's opinions on this as we run out of v4 addresses and transition to v6 are going to evolve rather rapidly.
So there's actually a two-part question to that. What if ARIN is able to retrieve a /16 as an example but only has bids for two /17s? That's allowed under this policy. They have bids covering the full amount of space they're going to recover. And it leaves to ARIN's discretion whether that deaggregation is a good thing. I would hope that ARIN would not recover a /8 and turn it into /24s. But I also leave open the possibility that 10 years from now we may see that as a really good thing.
And then Cathy presents the other part of the problem, if I have a /8 and I only want to sell a /24 of it. I would hope, at least early on, ARIN staff would walk away from that as that's not good for the community. There may reach a point many years from where we actually think that's a beneficial activity.
We certainly can codify that in more detail if need be. But I think whether it was staff or counsel in the assessment pointed out that this is an entirely new activity for ARIN, and I could not agree more with that. I think this is as close to re-chartering ARIN as you could get without re-chartering ARIN.
And so I think some of this would require some operational experience and would expect this policy would certainly be slightly amended both operationally and policy-wise should it be implemented.
MR. VIXIE: Another question from the remote and then Scott.
MR. ANDERSEN: Joe Maimon, CHL: Is the system designed to supplant, obviate, or obsolete any result in transfer market that may emerge due to 2008-6/2009-1? Some down signs if that is the intent, address reputation. Not all numbers may be valued the same by those who would use them. Transfers aggregate -- sorry, transfers arranged between parties allow for exchange of benefits or considerations other than financial. Would this system -- would this system intend to obviate or obsolete transfers?
Furthermore, without an actual market, how would either requester determine what bid number to use effectively and how would a returner determine what number is fair market value without an operating market. And if there is a healthy or operating market, what goal does the system serve? And if the end result of those systems are in play, then wouldn't that just in effect be a let-the-market-decide scenario?
MR. BICKNELL: Two-part quick answer to that. First part, as I already said, this was developed with 2008-6 not yet adopted and 2009-1 not existing. So it was sort of assuming those didn't exist. We need to consider that now.
The second piece of that is there's a transparency section in this that may be interested to those who both want to know how bids would work and how you would study this going forward. It requires ARIN staff no less than once a month, every 30 days, although sooner if they can do it, to publish data on transfers in both directions through these policies.
So if you are looking for historical bid information, historical actual transaction prices, this policy requires ARIN staff to publish data on that so that you can go to the ARIN website and track that over time and determine what the prices are.
MR. VIXIE: Scott.
MR. BRADNER: This group, this community has expressed a very strong feeling in the past that all transfers of any type would include a needs-based analysis for the recipient. That seems to be missing from this. Did I miss that?
MR. BICKNELL: No, in the first request that is submitted to ARIN, the person who needs resources is going to submit the exact same request they submit today and is going to have to meet all of the exact same policy needs-based criteria they meet today.
The process is unchanged until the point where ARIN would give them an IPv4 resource. At that point, under this policy, they would give them a form to bid on what they've been approved on. So all of the needs-based criteria as they exist today are 100 percent preserved.
MR. VIXIE: I want to say there's quite a few here. We have two more remote participants and seven standing.
MR. ANDERSEN: Three more.
MR. VIXIE: Three more. So unless you're counsel walking toward a microphone, then they're closed. This is it. You like that? I didn't mean to make anybody mad. Get up to a microphone if you can hurry.
MR. ANDERSEN: Ed Lewis from Neustar: How is this playing on ARIN staff expertise as stated in the first slide? ARIN hasn't been in the middle of operations, business or technical, of the Internet. It's a place to register who uses what. This puts ARIN in the middle. ARIN isn't warehousing IP number resources; it tracks them.
MR. BICKNELL: My comment on ARIN expertise was not on their expertise in this particular policy. It was that I believe ARIN is probably the best expertise in identifying people submitting fraudulent IP requests. They have seen them. They have dealt with them. They probably deal with them on a daily basis. And, thus, should people want to fraudulently buy and sell resources in the future, they are uniquely positioned to handle those cases.
MR. VIXIE: Stan, at the left.
MR. BARBER: Hi. I'm Stan Barber. I'm from The Planet. One of the questions that I have -- that's the name of the company. I didn't invent it.
One of the questions I have about this policy really relates to my experience at The Planet and other companies I've worked for where over time IP space has become tainted because of the way it's been abused by its users.
One of the concerns that I would have is how ARIN would be in a position to actually evaluate that and how that criterion would be established. Because obviously a buyer would not want to receive IP space that would effectively be useless to them because of spam blacklistings and other such things. So how would you address that?
MR. BICKNELL: I've been asked to paraphrase the question because the remote participants are not getting all of the audio. So the question was: What about IP space that is tainted that is maybe on various black lists and spam filters and other services and how would ARIN deal with that?
And quite simply this policy does not attempt to deal with that. I think generically that's a problem with any policy that allows IP space to move from one individual to another. And we actually even see that today where a customer quits an ISP, a new customer comes along and gets SWIPed the exact same block and runs into the various problems you're describing.
Unfortunately this policy doesn't do anything to address that one way or another. It may be a way as we move to paid transfers under any scheme that we need to do additional work.
MR. VIXIE: Let's take another remote, then we'll go to right-hand microphone.
MR. ANDERSEN: Martin Levy of Hurricane Electric writes: Why would ARIN take on the whole business process when others are in that business, such as eBay? Can't ARIN just provide an approval process towards a prospective buyer and a prospective seller? Approval would be equivalent to existing processes within ARIN.
MR. BICKNELL: I hope I illustrated that in the presentation. So I'm not going to go back through all that again.
MR. DANIEL: Rudy Daniel, ICD development, Caribbean. I'm wondering once the -- if I go and bid on a resource, when I do get it, does it then become -- do I then regard it as a financial asset to myself? And then what then happens to the original intent that resources are not owned?
MR. BICKNELL: Kind of the same comment I just made. Regardless of the scheme by which we use to transfer addresses that we've had several proposals, when money and addresses change hands, accountants may decide they're an asset. I'm not an accountant. I don't know the rules for that. But I think it is a generic problem to transfers and not a specific problem to this proposal.
MR. VIXIE: Another remote, then we'll hear from the left-hand microphone.
MR. ANDERSEN: Jo Rhett of SV Colo says: Can Leo please explain in detail how this is really going to help aggregation. I've read and reread the slides and I just don't see how this is going to work in reality. I am against putting ARIN in the middle and, thus, this proposal, unless there is some true value and possible aggregation.
MR. BICKNELL: Well, the slides are up online. So if the remote folks haven't looked at that, you can definitely go through the example there. And you've got to make your own assessment. It is a very hard thing to consider. I certainly know several individuals who own swamp Class Cs because they were Internet geeks back in the day and you could get one for free and life was good. I in fact know several individuals who have them and aren't using them today. They aren't routed anywhere.
And so I actually think for any number of reasons, not just because of those examples but because of businesses that have come and gone and moved on, you know, how many ISPs got a swamp Class C back in the day and now we're getting /8s so they've got three of them sitting in a corner.
They may well be willing to return those small chunks of resources for the good of the community, even getting a price to pay for their trouble of doing it, right? They're going to pay their lawyer to look at a contract and whatever else.
And so and ARIN also has -- Leslie may be able to comment. There are holes in what we consider the swamp space. It wasn't 100 percent allocated. There are existing little holes here and there for various reasons of how things worked.
So, again, I don't think we're going to put a /8 back together. I think it is entirely practical to consider that we could take things like swamp /24s and turn them into /23s, /22s, maybe even /21s depending on how things work.
MR. VIXIE: I think you're going to get challenged on the e-mail list to explain how much inventory ARIN would have to maintain in order to do that reaggregation before handing things back out. But please don't answer that now.
Left-hand, and then center.
MR. DURAND: Alain Durand, I have two comments. First one is I think a direct relationship between the two parties, the seller and the buyer, with ARIN in the middle, in some cases may actually be a property and not a bug, because there could be some transfers that do not necessarily involve just money, and they might be fairly complex contracts that need to be set up in between the buyer and the seller. So everything has to be a dollar amount transaction going through ARIN. You actually prevent those kind of transfers.
That's my number one comment. My number two comment, I would like to ask a question to the people from ARIN board, maybe the president of ARIN, what is today's budget of ARIN?
MR. CURRAN: I'll answer. So today's budget of ARIN; we're actually going to have a detailed presentation from the treasurer in a couple of days, but order of magnitude approximately $12 million annual in terms of expenses. And we always strive for slightly more in terms of receipts. Though this year we're extending a bit on engineering, so that's not the case.
MR. DURAND: Thank you. What I'm concerned is that this presentation that Leo made, very nice presentation, but may give a false sense of safety by having numbers like $2 or $5. Counsel was talking about a prefix might go for six figures. But what if a /8 goes into the system and we are not talking about six figures but eight figures or nine figures or even more, who knows.
So I'm very, very concerned that this could transform ARIN into a money-making industry. And this is something that as a member of the community I would find very dangerous.
MR. CURRAN: Paul, can I respond?
MR. VIXIE: Go ahead, John.
MR. CURRAN: I will note that I do agree with you that Leo's slides, example slides and amounts get very exciting if you move the digits to the right and add six zeros. Yes.
MR. BICKNELL: Just for the remote participants again, your first concern was about the fact that a traditional transfer policy may allow for two parties to have a contract that includes things other than monetary considerations, maybe much more complex. And, yeah, I agree. It's a difference between the two schemes.
MR. VIXIE: Center microphone.
MR. TEMPLIN: Pete Templin, Texlink Communications. Mr. Ryan, thank you for your comments to begin this discussion, very eye-opening and enlightening.
My concern is essentially at a higher level. How do we know what sort of transfer arrangements will be considered legally acceptable for ARIN? Because as I see it, we can only entertain two, maybe three more rounds of proposals before the game is up. Am I correct? Because we really only have --
MR. BICKNELL: Speaking only as myself, I think you're optimistic on the number of rounds we could sustain. I think the time frame is shorter than that.
MR. TEMPLIN: I fear we may come up and spin our wheels having debated policy, debated proposals, put them for 35 days before an ARIN meeting, come to the meeting, big shotgun wound to the proposal, back to the drawing Board and very quickly it's D-Day. So what can we do to make this proposal or some proposal or some proposal we've not yet even seen work? Or is it just a matter it is what it is?
MR. BICKNELL: I'll partially answer that; some other people may want to jump in. But as an AC member, under the new PDP the AC is empowered to make good, technically sound and something else policy -- I forget what. But in any event --
(Laughter) We're empowered to make good policy. And --
MR. BICKNELL: Sorry?
SPEAKER: To propose.
MR. BICKNELL: To propose. To the extent that the community can clearly articulate what they would like and counsel agrees that that's not a legal risk, I believe the AC can work quite quickly to make that happen. I think traditionally the largest problem from my own point of view is the community has not been quite clear.
We've often described it as a third of the people who want transfers, a third of the people who do, and a third of the people who haven't made up their mind. That doesn't leave us with a great place to go.
MR. TEMPLIN: Regardless, it leaves you with an iterative process in which you articulate policy and at which point you get legal input that says that's not going to -- I can't in good conscious approve it and you are back to the drawing board. How do we get an understanding that allows us to break the iterative process?
MR. VIXIE: Excuse me. To the extent that you are referring to the need for a transfer policy, I want to point out again, the AC passed one, the Board approved one. Its implementation is suspended at the moment, but 2008-6 is in -- it is policy. So we do have one. We're not continuing to iterate other than the fine-tuning that's going on in 2009-1.
To the extent that you feel we have to have some sort of a market-based listing service or something like that, as Leo is proposing, that's really a question about the nature of the PDP rather than about the nature of this proposal.
I encourage you to bring that to open mic.
MR. HOWARD: This is Lee Howard. I also want to suggest -- I don't know if it's realistic to say, Steve, can you give us a list of all possibilities that would be acceptable? (Laughter)
MR. VIXIE: Center.
MR. MILLER: Joe Miller with United Telephone. I'm speaking for myself and my company, United Telephone, in opposing this policy. I'm going to quote from the policy, the last sentence of 4.X.2, it says: ARIN will use the bids from section 4.X.3 to determine the value of returned resources.
It seems to me like you guys are setting up a market for IPv4 and at the same time you're setting yourselves up as the market maker. And I think that that's beyond the scope of ARIN's mission, and I think that it's to the detriment of the community.
I think as the IPv4 space exhausts itself, that there's going to be a difficult transition for everybody. I think we all agree on that. But what's going to happen with this policy in place is that there's going to be the haves and the have-nots.
And that's a big problem, especially in medium population centers where you may have an 800-pound gorilla competing with a couple of local providers. Who is going to win in that scenario? The 800-pound gorilla. And they can outbid the entire budget of the local ISPs.
I also think that it slows IPv6 adoption where it's needed most. I think the big guys have to step up to the plate and show some initiative here. I don't think that the small guys, as much as we want to adopt IPv6, we still have to have an IPv6 provider to do that. And I also think that with the transfer policy that's currently part of the policy, it may encourage direct selling to the designated transferee.
If you get creative, you can think of ways to combine the two policies to take advantage of the situation and set up direct transactions.
MR. VIXIE: Thank you. Left-hand side.
MR. KUJAWSKI: Adam Kujawski with Hostway. One of my concerns is that this might actually create a way for spammers to launder their IP space by getting new space on this open market spamming from it, tainting it, selling it back into the market, buying additional space to replace it. So that's one concern.
The other is without a direct contract between the buyer and seller, what's to prevent the seller from continuing to, say, announce their IP space after it's been officially transferred to the buyer. Kind of like selling somebody your car but you keep the key for yourself. ARIN might be exposed to a lot of liability since they're the ones kind of in the middle of that.
MR. BICKNELL: Two different issues there, for the remote participants. The first one was a question about what's to keep a spammer or other bad actor from obtaining space, using it for a relatively short period of time, returning it back and then requesting more space.
And that is a very tricky problem under any of these proposals. The mechanism in this proposal that would attempt to control it, and I'm not sure it would be 100 percent effective, but I think partially effective, is that you do have to go through the normal justification process today for address space. So, for instance, I think ARIN's staff is pretty good at rooting out, you know, I would like a /16 but I have one mail server that I'm going to rotate through that, please. They don't like those kinds of requests. So there are some mechanisms to limit certain types of bad activities, but that's definitely a problem when there's a paid transfer scenario. And I think it can happen in several of the others as well.
Your second problem about the seller hanging on to the space, there are a number of pieces of due diligence that need to happen in here. And this goes back to my point about looking at the total risk to the system versus the risk to ARIN. So, for instance, I would hope that if ARIN recovered an IP block, one of the things they would do in that transaction is they would look at a couple of commonly available route servers and see that that it is no longer routed on the Internet. And if it is still routed, say we're not sending you your check yet. You're still using it. You're not done with it, we can't complete the transaction.
I would hope in a 2009-1 or other 2008-6 scenario that people would be doing that on their own, doing their own due diligence, but in that case it's up to all of your customers who need IP space to know they've got to go do that.
That's a case that, yes, it's a little bit of extra work that ARIN has to go check that, but they can develop that as an automated procedure. They can do it every day. They can be really good at it as opposed to people who might buy an IP block once every five years.
MR. VIXIE: Center mic.
MR. KARGEL: Kevin Kargel with Polar Communications. Just a couple of points on this. I'm actually speaking in opposition to this proposal; when I left I was thinking about speaking in support of the proposal. But there are a couple of things. I like that this stands the possibility of maintaining opacity between the principal parties which offers a lot of safety and protection to the community. If the two parties are free to negotiate outside of ARIN and create side deals, there's a lot of danger in that.
Whether this policy or some other, I think we really need to stand firm and maintain the opacity in the presale stages. The property language issues I think are another thing. And everything that I've been following, it's been vigorously maintained that IP addresses are not property. Now we're starting to talk of property with buyers and sellers. As soon as you call it property, now it turns into something that's regulatable and taxable by government. That opens up whole new arenas of danger. We really need to avoid that if we possibly can.
The last danger of trying to be as brief as I can here is that in the aggregation section, with the dollars that are involved, there are some very powerful big players that are going to get in and they're going to -- and they're going to have a lot more resources to do things than the smaller guys, with some very minor policy tweaks, some innocuous policy tweaks. I can see the small players that are sitting in the middle of a block being forced to move and forced to renumber by virtue of eminent domain, just as the same sort of things happens in real estate deals.
And I really think that -- that's just another concern that we have to watch for. Thank you.
MR. SCHNIZLEIN: We meet at last. John Schnizlein, the Internet Society. Thank you for accommodating my turn at the mic. This is a proposal to set up ARIN as a market maker. So let's just use the valid terminology. I have two points.
One is that the stated current policy that ARIN recovers unused space is, it seems to me, in conflict with and would be obviously in conflict with, the party who might want to make an ask in this system. That is, the party who might want to return address space in exchange for compensation. Because when they expose to ARIN that they have an amount of space for which they're willing to accept dollars instead, it seems to me clearly trigger a valid question as to whether that is recoverable space. And so by having ARIN as the market maker rather than some third-party, like eBay, you put ARIN -- ARIN's policies in conflict with themselves, and I think raises the liability concerns that the lawyer expressed quite high very quickly because both sides in any argument would have valid cause if you had those inconsistent policies.
So the second point is that making ARIN the market maker for a resource that ARIN attempts to manage for a region of the globe seems to be creating not only a market maker but a monopoly market maker. Monopoly market makers get special treatment under the law of most countries, because they have to be regulated. And so now you're inviting the cost and litigation difficulty of ARIN operating as a regulated monopoly.
MR. VIXIE: Thank you, John.
MR. RYAN: This is Steve Ryan. I'm going to help you on this one. This wouldn't be a monopoly because you wouldn't be required to go here. So there would be always be the opportunity to effectuate transfers between A and B.
Under the proposed 2009-1 language that was uncontroversial this morning, the only way transfers will occur when it becomes effective is A transfers to ARIN, ARIN transfers to B. But the terms between A and B would not necessarily be known by ARIN. In other words, we would neither know nor care what those terms are. But we would effectuate the transfer of the right to use the numbers, not the ownership of the numbers. So in that regard I don't think we'd be a monopoly. I agree with you that we'd be a market maker and the market making activity as opposed to a listing service is dangerous.
MR. SCHNIZLEIN: I get -- I concluded that if we resolved the process as proposed in this proposal that there was a presumption that this was instead of transfers between the parties, because that is the motivation, and if it were instead of transfers between the parties, then I think we bring in monopoly.
MR. BICKNELL: I'd actually like to go back to your first point about the possible conflict between ARIN's own policies. I think it is easy when we talk about transfer policies to envision the /8 that is completely unused and somebody's going to make a fortune selling it. But I think the actual, far more common case is folks who are using their address space and in fact likely using it to current guidelines but not using all of it. I point no further than the fact that end users today only have to meet a 50 percent threshold to be valid under ARIN's policies.
So if you have a /16 and you're using a /17 of it, you are fully in compliance with ARIN policies. That doesn't mean you wouldn't necessarily be willing to for the right price transfer away the other /17.
So I don't actually think the common case is a case where ARIN would be going against its own policies. It's a case where you would be recovering things, essentially demanding a higher degree of efficiency than is done today.
So I think that is a concern, because I'm sure that case does exist at least once. But I don't think it is the predominant situation. That's just my guess.
MR. VIXIE: Thank you, Leo.
It is time once again for me to remind you that ARIN is not a direct democracy. Members elect the AC. The AC deliberates. They use many inputs including their experience, education, their conscience and your show of support or opposition as well as that that they encounter on the mailing list.
I also want to remind you that what we're asking for is a show of support of the policy as it is printed in your handbook, not as you may have been silently editing it to go along with the various comments that you've heard.
So considering draft policy 2009-4, can I see a show of hands for those who are in support of this policy as written?
Those opposed to the policy as written? Okay. Hold them high. We're counting them.
Thank you. Okay, from my own hearing of the very interesting discussion, I have to say I can't think of any subsidiary questions about, gee, would you support it if this or that were changed, but it does seem to me that there's a lot of interest in this, and even though Leo's e-mail server is down due to a power outage in our building right now, I apologize for that.
Not yours? Then send him mail, let him know your thoughts on this. If you encourage him to change this proposal and resubmit it in some different format, he's likely to do that.
I should point out that corporate counsel is not given to displays of emotion, and if he says that he is willing to run out in front of a moving vehicle and die on the road, then it probably means that this proposal would have to change quite a lot before that state of affairs might change.
So there are 117 people. A combination of in the room and on the call, on the remote participants' call: there are two in favor and 48 against. So thank you, John.
MR. CURRAN: Okay. That concludes our policies for today. We do have one more thing we generally end each day at, and that is the open mic session. So this is open microphone.
Remember meeting courtesies and rules of discussion. Try not to rehash policy proposals already discussed. That's something we -- because the AC already has their feedback. They're going to have to act on that. We ask if it's a policy proposal or one on the agenda coming up, try to leave them for the appropriate time. The floor is open for any and all other topics, and I'll turn it over to our most capable Chair to moderate.
MR. VIXIE: The first question is for you.
MR. CURRAN: The first question comes to me anonymously: What is the ARIN Government Working Group, because we heard it mentioned twice.
That's actually a very good question. ARIN has reached out and made sure that government representatives who want to understand ARIN and how we work, how our policies operate, how we form policies make sure that ARIN is accessible to them. We've had a number of government folks who have taken us up on that and they come to ARIN and they get a session where we do effectively orientation.
We explain how we work and how we do things, how WHOIS works, how our databases are operated, to help them have a better understanding of us.
And so that was done when the new timers were having theirs, we had another group that was effectively having their new timers. The fact of the matter is policy items of course come to the floor. In fact, you heard the folks identify themselves when they were here at ARIN and part of ARIN Government Working Group understand that while we may do education sessions targeted for them, it's a completely consensus community-based policy, so it's not a separate group doing policy. It's a group here that will participate here, listen to us and try to share the thoughts as far as what they have to deal with in their own organizations. So a very good question. Glad to address that.
Now, turn it back over to you Paul.
MR. VIXIE: Thank you, John. So open mic is not limited to any of the current or past or even future policy proposals. Certainly you could use this time in that way. You could use it in any other way if you have questions about things that are not policy, including the operations of ARIN or the PDP or budget or charter or anything that would sort of normally not fit in the fairly well-structured agenda of this meeting.
This is your opportunity. While you puzzle over whether you can think of anything like that, we do have a remote question.
MR. ANDERSEN: Yes, Chris Grundemann for the Board: What action is needed to call for the implementation of 2008-6 as written and as adopted? I believe he means now.
MR. VIXIE: Okay. Scott would like to speak to this.
MR. BRADNER: It is my opinion that the Board should discuss it at our meeting tomorrow morning and bring an answer to that question tomorrow, first thing tomorrow morning.
MR. VIXIE: I very much agree with that.
Please come on up to the microphones. Don't be shy. I will be closing the microphones in a couple of minutes. Wait. We have more remote. But was Leo at the mic first?
MR. ANDERSEN: They actually typed it a few minutes ago. Joe Maimon of CHL asks: Once I can go to eBay and find a seller, why should I consider ARIN policies to be relevant? What does ARIN expect to do in its big bag of sticks to enforce their policies? Can the market take on a life of itself so as to render ARIN irrelevant?
My other concern is I fear, expect that there will be a mainstream political firestorm if and when run-out occurs and people are feeling pain. I believe it would be beneficial to be able to show due diligence in the face of looming shortages. Is this a valid concern shared by others and in drafting policy?
MR. VIXIE: I believe that's a question for the room. Just raise your hand if this is a valid concern shared by others.
MR. CURRAN: Let me just say that ARIN has certain policies. If people violate those policies, we have the right to revoke space. The revocation of space that occurs in violation of ARIN's transfer policy will be our answer to that. The Board will make those decisions, but counsel will make recommendations for revocation when people do not follow the policies.
Now, when the newly adopted policy becomes effective, which will be in the near future, I think a Court would look with even less favor on parties violating the rules of the community or the contracts that they've signed with us in that regard.
MR. VIXIE: I think that's an authoritative answer to what the Board thinks. I don't think the Board would be ready to take a different position.
MR. CURRAN: I would like to solicit for comments from the -- sorry. Whoever it was that asked -- if there is more work that we could do to be further duly diligent, let us know what you think it is.
MR. VIXIE: My question to this question would it make ARIN relevant, I certainly think not because ARIN is an extremely useful body and is likely to continue being a useful body long after the last IPv4 address has been handed out or routed or deaggregated or whatever.
We're not good at contemplating our own destruction. No organization really is. I see continued relevance, and echo what Lee just said. If we can be more duly diligent, please let us know how. Let's go to Leo.
MR. BICKNELL: Leo Bicknell wearing my ARIN hat. I'd want to remind people on the record that based on the best predictions that man can create, it is not impossible that we'll run out of IPv4 resources and 16-bit ASNs in calendar 2010. That is within the error-bar range of the projections.
And given that anything we do is likely to take staff some time to codify and put PDFs on the website and all that kind of stuff, we are nearly out of time. That came up in the last discussion. And particularly as an AC member, the discussion in the room and on PPML is often dominated by a few loudmouths like myself.
But we really do appreciate everyone's thoughts and such on this. And if you are not willing to come to the mic and you're not willing to post on PPML, I just want to remind you that all of the AC members' e-mail addresses are listed on the AC web page and you are most welcome to pick any of us that you think are nonthreatening and send us e-mail, because we are looking for your good input to help us produce good policy.
MR. VIXIE: Thank you, Leo. I would like to ask those who intend to speak during this open mic period to get up and queue to the microphones. I'll be closing them soon. We have another remote participant.
MR. ANDERSEN: Ted Mittelstaedt: Leo mentioned several issues that were endemic to any kind of transfer policy. I'm sure there are others. Leo mentioned the use of IP numbers being owned versus rented and IP addresses being dirty as a result of prior use. I think it would be useful if the Board could issue a statement that to the best of its ability and perhaps with input from the ARIN list that would list all of these major problems that are endemic to any transfer policy and ARIN's official position on them.
After such a statement was made from that point on, any transfer policy proposal would need to list all of these issues and whether they address them or not. I think it would also be useful if the Board could list all of the legal pitfalls of any transfer policy. With the same requirement for new transfer policy proposals, the main point of this would be so that the community doesn't continue to rehash the same issues over and over that are not specific to a transfer policy every time a new policy proposal comes up.
MR. VIXIE: Steve Ryan, could you just wave your hand to see if it's possible to exhaustively list all of the legal pitfalls.
Thank you for that. Center microphone.
MR. FARMER: David Farmer, ARIN AC. So we've had an event, the use of the emergency policy process. And my understanding it's the first time it's ever been used. Does the Board and does the community think it might be a really good idea to review how it went and how we might improve that process? I think it's an important process. But the first time you do anything there's probably things that need to be learned.
MR. VIXIE: As John stated this morning, the Board learned quite a bit from this invocation of the emergency policy process.
MR. CURRAN: Ow.
MR. VIXIE: Ow. We're certainly looking at how it should be used differently or perhaps how it should be changed so it will be used differently in the future. I suppose we can get into the details of that right here and now. But since the Board is working on it, I would request I guess that you give us some time to think about it and make a proposal? John.
MR. CURRAN: Hi. John here. The Board actually sat down with the Advisory Council yesterday morning and had some discussion about the use of the emergency policy process and some lessons learned, and I think that before we open it up to wide community session regarding all the things that might change, I think we should do one incremental round, taking that discussion that we went with the AC, showing the results. I think there's further refinements that will always be possible. But this is an area where a couple of broad strokes are needed first to get us onto the right place before we worry about the fine-tuning. So I'd like to have one cycle of that first.
MR. VIXIE: Just to note, the microphones are going to close in about 30 seconds. You have time to walk to them from your seats, but not much more time than that. Any more remote participants? Scott would like to make a comment.
MR. BRADNER: Not a remote participant, but I want to agree that the Board has learned a little humility in this exercise, not as much as people would like, but we're trying. As the responsible party for some of this, I certainly have.
We tried in putting this process together, including the emergency thing, to do it in a way which was least likely to go outside of the realm of what ARIN's mission is, which is a bottoms-up policy process. But we erred in a way that we didn't foresee. And we do -- if we don't learn from that, then we don't deserve to be reappointed.
MR. VIXIE: Right-hand microphone.
MR. DANIEL: Rudy Daniel, IPv4 development in the Caribbean region and ARIN Fellowship member. So what I'd really like to do now is to say that I really do appreciate being under the ARIN Fellowship. I have been facilitated to come to my very first ARIN meeting here, although I have met with ARIN a couple times before in other circumstances. So it has been extremely useful and totally illuminating. So thank you very much to the AC and the Board. Thank you.
MR. VIXIE: Let me thank you. You had to distinguish yourself before this fellowship came to you and then you've distinguished yourself again by coming here. So thank you.
MR. HANNIGAN: Martin Hannigan, transfer warrior. I again continue to hear the naysayers that there is no market, and I'm here to again assure you that there is a market. Whether you believe that's gray or black or white, it's there. And it's morphing. They're watching us right now. They're reading PPML. They're changing their business plans to adapt and they're anticipating things that we're going to do. The people that need IP address space are not only us but the spammers and the people engaging in fraudulent activity all over the world. And it's their source of income, and they're going to react to these policy changes and trials just as we are, and they're going to adapt.
I also wanted to address something that Jean Camp said. She mentioned that if someone came to ARIN with a lot of venture-backed money and they needed a /8 under one of the regimes, she proposed they wouldn't be able to get some space. But I assure you if I showed up here needing a /8 and I had that much money behind me and that much need, if I didn't get it from ARIN, I'd get it from someplace, whether I bought it on the black market or not, because that's an awful lot of money and an awful lot of requirement. The needs aren't going to go away based on how big I am or small I am. So that's something to consider.
But I think that one of the things I would be interested in proposing some policy for myself and perhaps maybe some others are or are thinking about is closing some of these holes that are being exploited. They're not necessarily exploits of the transfer process, they're basically business-oriented exploits where companies are being acquired because they hold legacy space. Is that a violation of ARIN policy? I don't really think so. Is leasing your space out to another entity a violation of ARIN policy? I don't know. But these are the morphs and things that are taking place now and happening right out from under us, and I think it's hurting us all. Thank you.
MR. VIXIE: John would like to comment.
MR. CURRAN: Marty, to agree. To the extent that the community sees something going on, a practice that they think might be unclear, might be detrimental to our administration of number resources, then that's definitely places we need policy proposals to clarify what our practices are.
The organization staff work with the policies we're given, and in some cases we've had people say: Why are you allowing that? Why are you doing that? Well, it's hard to look at the policy and say no sometimes because it's not clearly something that is prohibited. So to that extent, if there are things going on that people think should not be happening and it's unclear in the policies, that's exactly why meetings like this are here.
Now, there's a second case which is to the extent things are going on that you think are prohibited by policies but we don't seem to be acting on them, there is a -- go click on the ARIN website under number resources, click on fraud reporting, and fill that out. We act on those requests. We investigate and we do process. I encourage clarity. And when there is clarity, to do something. We ask that. We encourage reporting. Thank you.
MR. VIXIE: Just a moment, Owen. So responding to Marty and following up on what John said. There are some abuses that have been alleged. There are tall tales that are told; maybe they're not so tall. The usual form factor of a policy that will come along and improve that and make that type of abuse harder is one that will cause something that is not currently a form of fraud to become a form of fraud. Because fraud is something we have some pretty good sticks for beating back.
So if you hear somebody say, gee, good policy in this area would be welcome, that's what we're looking for, I suspect. And the Board, although we do have some emergency policy powers, we're really not in the policy business. Policy comes from the community. So that's why we look to you and say: Could we please have policy that would accomplish these needs.
Owen, the microphones were closed, but since it's you...
MR. DELONG: I have a rebuttal question for John actually in response to his statement. As I understood what you just said, John, the staff is aware of situations where addresses are being issued because they don't have policy to prohibit it even though they think it's contrary to community intent. If that is the case --
MR. CURRAN: No, not at all.
MR. DELONG: If that were the case, I would hope that staff would have a mechanism for communicating that to the community or at least the AC.
MR. CURRAN: The challenges -- we have circumstances where a transfer request comes in. Company A buys Company B. Company B doesn't necessarily look like it's operating but could be. And so there's nothing upon looking, there's nothing that says we have a bad situation. It's possible the community knows we have a bad situation, because they have information that's not on the request forms or not on what's submitted to ARIN.
You might know more about it. Like when someone tries to route something, you might have some more information. There's fraud reporting on the website for just that purpose. Got it?
MR. VIXIE: That concludes open mic for today. So I give you back to John.
MR. CURRAN: Okay. A wonderful day. We're now at the end of today. We've got a couple of quick announcements and some very important ones at that.
First, I'd like to again thank our sponsors. Time Warner Cable and Rackspace.
Reminders, Breakfast 8:00 AM tomorrow outside. Meeting, 9:00 AM., here. So it should be very easy to find.
SWIP of the Future BoF: You got a little preview of that when we talked about ARIN online and what we're doing on the back-end side of the information systems. Now we want to talk about how we interface to those people who want automatic linkages. Very important discussion for those who have viewpoints to share with us so we can shape our direction accordingly. Between 5:00 and 6:00 PM tomorrow evening.
Social tonight: Tonight, 6:00 PM, at the Southwest School of Art & Craft, which is a few short blocks away. There are instructions in your packet on how to get there. I'm told it's wet outside. Thank you. There is a 40 percent of severe thunderstorms. We have umbrellas for those people walking over and want to get there with a little bit of protection. Umbrellas are available down at the registration desk. Not a problem. We've also arranged a bus now, even though it's a very short distance. If you really want to stay dry, there's a bus that will start at 5:45 on Soledad Street and run every 10 and 15 minutes. Because of the distance between the locations, it's literally going to be back and forth every 10 minutes. It should be very fast.
So the social itself is indoor and outdoor. There's enough room indoor for everyone. There are outdoor options if it should end up being a little drier, because they said the storms may end tonight at some point.
MR. CURRAN: Very good. And, as I said, it's going to be a lot of fun. Some line dancing, food, drinks. Should be a wonderful time.
That's it. Thank you. Happy trails.
(Adjourned at 5:01 p.m.)