ARIN XX Public Policy Meeting Draft Transcript - 17 October 2007
"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."
MR. PLZAK: This is ARIN XX, and I'm going to go through a set of announcements and so forth, so let's get started on that. And first of all this is what we're going to be talking about real quickly. And so -- we've had about 203 people registered for our meeting. There were about 452 registered for the NANOG meeting. We've got a crossover this time of about a 139. It's a growing number; it works real well, so I think we'll keep on doing this. In regards to this ARIN meeting, we have 78 first-timers, so first-timers welcome. Please come back. (Applause)
MR. PLZAK: Okay, here's a breakdown of attendance. Ten people from four provinces of Canada, 162 people from 30 states in the District of Columbia, one person from the Caribbean portion of the ARIN region, and we have 40 people from outside ARIN representing 15 countries. And, welcome first-time attendees. We had a -- once yesterday they get to meet the elected representatives, i.e., the Advisory Council and also the Address Council persons, met with ARIN staff, we had -- all had lunch together, and they've learned something about ARIN. And they also were asked to fill out a survey and so there's a going to be a prize for that -- filling out that survey and completing it, so Susan would come up with the bag. I would ask someone in the audience who was not at the meeting -- at the lunch yesterday, and is not a member of an RIR staff to please come up and draw from the bag. And the giveaway is an IronKey Flash Drive. So, you're a member of an RIR staff?
MR. VEST: Not me. (Laughter)
MR. PLZAK: So Axel, did you fire him? Okay. (Laughter)
MR. VEST: ANY?
MR. PLZAK: RIR.
MR. VEST: I pick any?
MR. PLZAK: Any. (Laughter)
MR. PLZAK: All right, draw this. (Laughter)
MR. PLZAK: Drawn. (Applause & laughter)
MR. WOODCOCK: And if you were, you aren't now, oh.
MR. PLZAK: Yeah. (Laughter)
MR. PLZAK: Okay, ah.
MR. VEST: Yes.
MR. PLZAK: Brian Murphy? There he is, uh-huh. (Applause)
MR. PLZAK: A speech is not required here, Brian, but you are welcome to come to the mike during policy discussions. If you come up here, I've got a little goody for you.
MR. MURPHY: Thank you very much.
MR. PLZAK: Welcome. Okay. Let's welcome our Postel Network Operators Scholarship awardee, Ayitey Bulley, are you in here? Okay, let's look at your meeting reference materials and other goodies. Oops, backup. You got a bag, and inside that bag you've got a folder, and inside that folder is a number of things. We are asking for you to complete surveys. There is a brochure on elections, and also a sheet on using PGP with ARIN. If you recall, we recently implemented PGP capability, and also a copy of the ARIN service level commitment report that was -- has been asked for by the community. On the right side, you see -- invitation to come to the Cyber Café. We will again be having the prize wheel, so as you fill out surveys during the course of the week, you'll be asked to go try your chance there. We have a "Welcome to ARIN XX" member packet brochure. You also will find a copy of the IRPEP, and you'll also find a copy of the Number Policy Resource Manual. Also in your bag, just so that if you feel the urge you have to have something to eat, there's a bag of M&Ms. And also you have the ARIN XX tee-shirt, and this is the tenth year of ARIN and ARIN's birthday is in December, and we're not McDonalds, we haven't done a "Billion Served," but ARIN's done a lot of things over ten years and so there's some statistics on the back of the shirt. So, anyway, happy tenth anniversary to ARIN, so happy tenth anniversary to all of you. (Applause)
MR. PLZAK: Okay, let's introduce the Board of Trustees, John, Scott, Lee, Paul, Bill, Bill, and me. And of course not a member of the Board of Trustees, but providing advice is our general counsel, Steve Ryan, who is in the corner. The Advisory Council, here are the 15 hot chili peppers.
SPEAKER: Hear that.
MR. PLZAK: They are all here, and I won't name them off. If they could all just quickly raise their hands or stand, so you guys get an idea where they are. They are here to help you, assist you, and please take advantage of them. I'll leave it up to you to decide what advantage is. (Laughter)
MR. PLZAK: The Number Council, three people, Sandy, Marty, and Louis. This is Sandy's last meeting as a member of the Number Council and he is over there in that corner. And we will have -- we're discussing shortly, the election to replace him. RIR colleagues, AFRINIC, Earnest and Harry; Sunny and Jeff from APNIC; Pablo and Ricardo from LACNIC, and five people from RIPE? No, six -- see, Tom you're around there. Okay, and the ARIN staff. Difference this time is we have a new director of engineering, the Chief Technology Officer for ARIN, Mark Kosters. (Applause)
MR. PLZAK: Bob is not here, he was here earlier in the week, but he had to go back -- back home but the rest of us are all here. So let's thank our sponsor One Connect IP. (Applause)
MR. PLZAK: And of course, you, we can't do this without you. Cyber Café. -- we've got the help desk, Internet access material, Internet access, we've got ARIN materials, we've got presentations. If you've never visited a Cyber Café., do so; there's a lot going on there, it's a good place to congregate and meet and get information. It's back by popular demand -- the Prize Wheel. And you'll be asked to be filling out surveys and at every break or thereabouts, there's going to be a drawing, and not everybody is going to win. So, there are eight lucky winners over the course of two days. However, and as I said not everyone's going to win, so we do have a consolation prize. So, all non-winning entries are placed into a raffle and there'll be one name drawn during the Friday morning announcements. You must be present. So, what this means is, is that if you enter the raffle on today and say you win this afternoon, because you entered that one, and you did that survey, but you filled out all the surveys you didn't, you are a non-winner for all those other events, so you would be eligible for the consolation prize. So, you fill out the consolation prize survey and the consolation prize is an iPod Shuffle. So to take a look at the prize pyramid, for answering all these surveys, go out to the Cyber Café. and good luck to all. Help desks: Besides the registration services and billing help desk, we've added a new one -- an Advisory Council information desk. It will be managed -- manned Wednesday and Thursday during the breaks -- morning and afternoon breaks -- and also during the lunch hour. There will be at least two Advisory Council members there. It's a good chance for you to meet up with the Advisory Council and just get to know them. They are there to help you. Also because this is an election meeting, we have an election help desk as well at the Cyber Café. Ours are as appointed billing will do theirs via, appointment only. Please complete the meeting survey and we have a raffle prize for completing this survey as well. One entry per person, and so one lucky winner of a four gigabyte iPod Nano with video screen, and one lucky winner of a four-port broadband VPN Router, which is added on as courtesy of Shaw Communications. So, we actually have two lucky winners. Well, thank you Shaw for donating that. (Applause)
MR. PLZAK: And tonight, Los Amigos Roundup is a social. It's a ranch on the Sandia Indian reservation. We have food and beverage. It's a buffet dinner, open bar, and for entertainment we have DJ and dance groups. We've got a bonfire; we've got some sand volleyball. For those of you at the ARIN meeting in Orlando, you can remember playing volleyball in the sand there, so you get a chance to do a reprise in the desert sands of New Mexico. And also, if you weren't here for the balloon festival, this is your opportunity to go on a tethered hot air balloon ride. Bring your camera along; you will be able to get some very, very good pictures. So, please join us tonight and more information will be forthcoming during the day, as far as what goes on. And here's a rules reminder. At this point I'd like to turn it over to the chair for a brief discussion of the rules.
MR. CURRAN: Thank you, Ray. Ah, I see these pretty pictures. I'm going to guess each one has a meaning. Next slide?
MR. PLZAK: No, that's it.
MR. CURRAN: That's it? (Laughter)
MR. CURRAN: Well, I guess not. (Laughter)
MR. CURRAN: Well, I will try to translate the rules. We conduct the business under Robert's Rules of Order and what that means is that for each one of these, you are to keep your comments germane to the topic at hand. You address your comments to the entire -- myself, or the entire membership, there's no personal attacks on each other. You are to, you know, use the microphones, identify yourself when you are the microphones. Please recognize the fact that I will maintain decorum. Please limit your comments on the matter to a short period of time -- 3 minutes is our standing rule for comments on a policy proposal. If you need to respond later, you can get back up to the microphones and respond later, but we have a number of policy proposals out there and those policy proposals all need to have adequate discussion. Additionally, when you approach the microphones, in addition to giving your name and your affiliation, or organization, please state whether you are in favor or opposed to the policy proposal. This is important information. Again, all of this gets to the Board and the Advisory Council and lets us understand where the membership feels about a given policy proposal. I ask that everyone respect these rules and will maintain decorum. If necessary, if I ask you to step down from the microphone, please move briskly. That's it, thank you.
MR. PLZAK: Thank you, John. So, let's get our kicks on Route 66, and on to ARIN XX. Welcome to Albuquerque. At this time I would like to turn the microphone over to the general counsel for a brief report. He's got about 4 or 5 minutes, which I think he is used to, having been in court a few times.
MR. RYAN: Thank you, and good morning. Couple of things -- first of all, the name of our institution, ARIN, is trademarked and recently ARIN filed its first ever affirmative litigation. We filed a pretty serious lawsuit for trademark infringement and other violations of law to recover our name. I'm very pleased to tell you that the domain name arin.com is back in the family. We've always been arin.net and someone had set up a WHOIS related business at arin.com and we have now successfully recovered that and voluntarily dismissed the lawsuit as a result of that. So, I want to sort of say to people who are cyber-squatting on our name, we're coming for you. There is a series of people out there who are using the ARIN name inappropriately and this was the first and perhaps the most important of those activities to recover our name. Second, you may have noticed a modest, small issue on the mailing list that we proposed a Legacy RSA and I know that that's creating some heat and light. Let me just say that on Friday morning, in the open policy time, people will get to express their opinions to each of you about the terms of the Legacy RSA and the thought about it. But let me say where -- where we are on this issue. We have an RSA. I think we are on RSA Version 9, if I'm correct that over time has changed and morphed, but is our standard RSA. And so, as an organization we have almost 12,000 contracts with members of the community -- sometimes, we have multiple contacts with one company. So, the registration services agreement changes and morphs over time. This is a different document. If you lay the two documents side-by-side, if you take the current RSA or even an earlier version of the RSA and lay it side-by-side with the Legacy RSA you'll see very quickly that the terms are quite different. And that's because the terms under which we're seeking to have Legacy holders decide to stabilize contractually through an RSA their relationship with ARIN is laid out there. And the Board is doing something here that we have not done with the RSA. Normally you don't ask people how they would like to contract with you. You don't, you know, debate that. You have to write a contract and an agreement that's based on the policies of the organization. In this particular case with the Legacy RSA, we have announced this -- almost, if you will, in Washington-speak -- and I'm a Washington lawyer -- almost like an administrative procedure act rulemaking, where we've shown you what the intention of the body is, but we're eliciting comments from people. So, those comments that are made either to me indirectly, in other words, I'm open for business for the next three days to meet with people who'd like to talk with someone about it and I'll be sitting either, here in the back row -- if I get here early enough I get the back row, this morning I was late I got the front row -- I invite you to talk to me, I invite you to talk to other board members, I invite you to write to the list and let's see how good a product we can come up with that meets both the needs of the community and of the Legacy address holders. With regards to the content of the Legacy RSA, I think its best left for you to read. Don't necessarily -- there maybe other lawyers in this room but I'm the lawyer who can tell you what the intent of the document is and can work with you on that. So, on the Legacy RSA, look forward to working with those of you who have strong opinions about that. Let me say that we're seeking Legacy RSA holders who are in this service region. If you read that it's not the worldwide Legacy address RSA, you know, based on our experience, may be one of the RIRs will want to do something, it could be very different than what we do, but basically we're looking for people within our own service region. So if there are any questions that's my current legal report, let me just add one final note. In the Montreal meeting, we were sued by someone for $45 million in an antitrust violation and I was able to report to you at subsequent meetings that we had achieved a dismissal of that case. I can now tell you that that case has been dismissed at the court of appeals. The matter is over. ARIN prevailed in that matter. I am very, very pleased with that result. So, while we're not in the business of law suits, we will respond to any aggressive legal action against us, as you would expect, as a fiduciary of the community's activity in this area. I'll take any questions quickly. When I say I'll take questions, I'm not asking if you -- you hate the Legacy RSA wait till Friday. If you want to ask a question about it you're more than permitted to ask a question about it. And I will rule whether your thing is a question or an opinion. (Laughter)
MR. RYAN: Thank you.
MR. CURRAN: Microphones are open.
MR. RYAN: Thank you very much. (Applause)
MR. PLZAK: Okay, so on to the first order of business on the agenda, which is the NRO NC election -- the Number Resource Organization, Number Council elections. And we've got one open seat. It's a 3-year term, will begin on 1st of January, 2008. Who can vote? It's all registered ARIN XX attendees and the voting period is open today, from 9:00 to 5:00 Eastern Time, which means it's from 7:00 this morning to 3 o'clock this afternoon, local time. The election headquarters is online, as all of our elections, is done electronically. So, the election headquarters has a voting booth, has the candidate biographies, and has statements of support. So, here are the candidates. Vikas is the only one that is not here to present a statement, the other four are here and now I'll be calling them up in alphabetical order. And so, let's start with the candidate biographies. First is Andrew Dul. Here is a statement of motivation and his short biography. I am not going to read it to you because Andrew will be coming up here to talk to you. So Andrew, if you're in the room, please come up, you have about 3 minutes.
MR. DUL: Good morning everyone, welcome to Albuquerque as well. As many of you know, I have been an active member in the ARIN community for -- I had to look back at my calendar because someone asked me this question earlier in the week -- over 7 years now. And it's been a privilege to be working with everyone here in the room to create this community that I think is really valuable and we are changing the way that, you know, not only that Internet as governance works, if you want to use that term, but also the way that Internet community cooperates together. So, just a few brief comments about myself and why I'd like to serve on the NRO NC. As many of you know, I have in the past served on the ARIN Advisory Council. I think that's a good experience base that allows me to take that also into the bridge between the RIRs and ICANN, which is what the NRO NC is. I believe I have a balanced experience. In the past, I have represented not only a service provider, a large enterprise, but I currently represent a rather small enterprise. So, a balanced background I think is important to represent all members of the ARIN region in this global forum. The most important thing that I'd like to say is that global cooperation in the next couple of years is going to be extremely critical. With IPv6 coming -- coming to its time of -- it's got to come or something else is going to happen, we need to really think about what the global impacts are of our policies, not only the global policies, but, the globally coordinated policies as we've been talking about recently. How those will impact not only our businesses, but the routing table as well as the financial impacts of what would happen if we aren't able to provide number resources appropriately to individuals and organizations that need to operate in the Internet space. And last the -- the IPv6 transition is going to be a very challenging one for a number of reasons, and I'd like to take the analogy of a large multi-variable equation and try to figure out -- solve what the answer is and I think that that's what we're facing is a large matrix of many decisions. And unfortunately, I think, what will end up happening is we will have to choose a path and drive down that path and have to deal with the consequences of that decision as they come on, because at this point I think we are continually spinning our wheels, trying to solve this equation that may not be solvable without moving down the road and moving toward deployment. So, I'd appreciate your vote and most of all, take the opportunity to express your opinion in voting. Thank you very much.
MR. PLZAK: Thank you, Andrew. As I said, Vikas is not here. His motivation to serve is stated here. He says, "My primary objective would be give back to the Internet community. Currently I'm involved with ARIN as a customer who would like to contribute more by supporting and executing the NRO NC's objectives." His brief biography -- he is currently director of engineering Wireless, Covad Communications. Previously he was a director of Internet engineering and a founding team member of NextWeb. He is responsible for architecting one of the nation's largest pre-WIMAX networks during the period 2000 to 2006. And he has more than 10 years of experience in the Internet wireless industry. And unfortunately he could not be here with us today, but I will say this, you should not count that against him. He has -- his statements are here as I said. Next is Jason Schiller. Jason, if you are here? And you see Jason carrying up his laptop. He is not giving you a Power Point presentation, that's -- it's his notes; and he also has about three minutes.
MR. SCHILLER: Good morning, my name is Jason Schiller. I'm a senior Internet network engineer for Verizon Business; formerly UUNET and I have had a lot of industry involvement. I have been an active participant in the ARIN public policy process. I read PPML, I've proposed policy. I've studied the problems of IPv6 multihoming and routing table scale concerns and I have given a number of presentations at NANOG as well as GROW on this topic. I've been involved in IETF, a number of working groups and am a member of the Routing and Addressing Directorate. And we're tasked at examining the routing table problem and solutions base. I also have experience ranging from enterprise LAN, enterprise WAN, all the way up to carrier grade ISP. As an engineer, I have a strong technical background, and you can see this from some of the projects I've completed, such as re-architecting our BGP topology in each of our continental networks. I have architected and designed our IPv6 network, our Latin American network, and our multicast network and also set routing policy standards. The reason why I want to run is, because, I think there a number of important issues surrounding IPv4 exhaustion and IPv6 adoption that we need to solve. Issues like should we have a soft landing or should it be business as usual? Should we attempt to engineer an equitable run out? Should we give all the RIRs the same amount of space or should we give them a amount of space that's roughly the same amount of time of allocations and assignments? Should RIRs give out smaller fragments once large blocks are no longer available and what's the impact on the routing system? And should we try to extend the life of IPv4 by trying to make it more difficult to get the addresses, or does by making it more difficult to get the addresses cause a premature exhaustion, as networks find they can't get v4 addresses, even though they are still available? I understand these issues. I understand the tradeoffs. I understand the technical implications of these decisions. As such I am well suited to act as an information conduit between the community, the ASO AC, the NRO NC, and to coordinate with the other RIRs. I can process global policy proposals and maintain the open process and I'm well-suited to advise the ICANN Board Members on a number of resources as I understand the technical implications of these decisions. I wanted to thank you again for your time and your consideration and please do vote. (Applause)
MR. PLZAK: Thank you Jason. Now I would like to call on Michael Smith. Ah, there he is. And you've got about three minutes, Michael.
MR. SMITH: Good morning everyone. I'm Mike Smith, as you can see; I'm the CTO of Adhost Internet. We're actually a colocation and hosting company in Seattle. We don't host ads, we don't host spam, we don't host porn, but the name dates from 1995, when you had to be first in the phonebook, so that's why we're Adhost. I could stand up here for three minutes and just say IPv6 over and over again. That's kind of what my focus is. Adhost is actually in the global routing table with our /32 and I think the next three years are going to be critical for implementation and understanding about the IPv6 in the community. My focus is mostly on the smaller providers -- enterprises and users who don't really have an understanding of what they are going to need to do, to be able to implement IPv6 and what they are going to do when IPv4 runs out; and that's really all I have. I thank you very much. (Applause)
MR. PLZAK: Thank you, Michael. And Sam Weiler; Sam, and you have about three minutes as well.
MR. WEILER: Good morning. Some of you may have seen Steve Ryan talk yesterday morning, talking about threats to the model of Internet governance that we're currently using. I think that the NRO is going to have a much broader role in the next few years than it has recently -- largely, in explaining that to the world and making the case that what we're doing here is not only a credible and adequate way of doing what we are doing but is in fact superior to what some people are proposing. I think I'll bring a different voice to that process than one that we often get in this forum. Most of my career has been spent working for end-users of address space, particularly Legacy address space, not for carrier class networks. And those of you who have followed what I have been doing in ARIN and in ICANN the last five years, may have noticed that I have particular passion for making sure that those voices -- those smaller voices aren't lost to those of the big players, to the PTTs and to the carriers. If elected, you can count on me to continue to be an active participant in this world. I have been active in the IETF for over ten years, I've been active in the ICANN and the RIRs for about five years. I would very much appreciate your vote. (Applause)
MR. PLZAK: Thank you Sam. So, a little exercise. If you are not a member of an RIR staff and that's all the RIR staffs, I would ask you to please stand?
SPEAKER: Including the head table?
MR. PLZAK: No, the head table doesn't count. They can still stay down.
MR. PLZAK: Okay, now why would I have you do this? Because, who can vote? (Laughter)
MR. PLZAK: You can. So please do so. Thank you. Voting procedures are three easy steps, you can find them at election headquarters at this URL or if you want to talk to someone, Erika will be manning the Election Help Desk in the Cyber Café. So, very simple, you register or log in, you vote only once, only for one person, and you confirm your vote; one, two, three. So, again a reminder, the polls are open and they will close at 3:00 'o clock p.m. local time. So, I'm not going to go through this -- the instructions are on the website, and Erika can provide clarification. There are handouts that also describe this. And as I said the handouts in your meeting folder, please take time to read it. But above all please vote. And again, go to the election Help Desk if you have questions. And with that I'll say, thank you. Okay, now, let's move on to the next item of the agenda. First of all, there is -- anybody have any questions bout the election procedures at all?
MR. PLZAK: Okay, so the next item on the agenda is the Regional Policy Development Process Report, and now it will be presented by Einar.
MR. BOHLIN: Good morning, my name is Einar Bohlin, I'm the policy analyst at ARIN. And this is the regional policy report. It's essentially -- policy and proposal activity at the other RIRs since the last ARIN meeting. And before I start, I want to mention that every RIR has a PDP, and they are very similar, in that they have fundamental core components of posting to a list for discussion, presentation at a meeting, consensus evaluation, last call, ratification and adoption. So, on the following slides, I've got status of the proposals and that kind of tells you where they are at in the PDP for the region -- that will be indicated. All right, the first category of proposal is IPv4 and the first proposal here is the end policy for IANA IPv4 allocations to RIRs. And it's a global proposal, and of course it's going to be discussed here -- at the ARIN meeting. And essentially this one is to reserve the last 5/8s at the IANA, and when the IANA is -- has run out of /8s to issue one of those to each of the RIRs. And the second proposal here is very similar and it would reserve 10/8s and when the IANA pool has run out issue two to each of the RIRs. More v4 discussion, the first one there is IPv4 address transfers and this is the -- in the APNIC region, this would allow members to transfer address space from one member to another. And it was presented at the recent APNIC meeting and it's going back to the list for more discussion. The second one is IP assignment sizes for end- users and it would establish that /24 is the minimum prefix size for multi-homed customers. The third item here is 12 month allocation period. We have that on our agenda this week as well. And that policy is for allocations to ISP's and it's going to be adopted in those three regions. The eGLOP in LACNIC region is back on the list for more discussion. And this one is kind of complicated and directing that resource assignments to end-users. The RIPE, NCC does not issue assignments directly to end- users, they have to go through a member LIR. So, when an end-user switches LIRs there is sometime some confusion about the relationship between the end-user and RIPE -- well, actually there isn't one yet, so this would establish that relationship. In v6 discussions, we move our requirement to announce a single block. In the LACNIC region of proposal was submitted that would -- that would allow ISP's to receive allocations to pull it up and announce subnets of their v6 prefix. It was presented at the last meeting and it's going back -- it went back to list for more discussion. And end sites can request allocations. What this means is that in the current IPv6 criteria, you have to be an LIR or ISP and not be an end site. And in the LACNIC and RIPE region they have removed the requirement that you not be an end site, so that you can go to those RIRs and request an allocation, if you are -- for example at University or something like that. At the bottom of slide here, a manned IPv6 assignment and utilization requirements. Of course here in the ARIN region we have adopted and implemented this policy. Basically utilization for a v6 bases based on the.94 HD-Ratio, and the issuances of -- or the assignment of /56 is to customers. And in the different -- at the RIR listed, it's going out slightly different way. In the AFRINIC region they have adopted the change to the HD-Ratio, but there is still this assigning /48s. APNIC adopted similar proposals -- similar policy that ARIN has. LACNIC is also going with the.94 HD- Ratio, and the RIPE region, this is fairly close to adoption, it's in the -- it's in the -- it's finished last call and it's in the ratification process. Lot of v6 discussions, IPv6 has been adopted in AFRINIC and APNIC, and it's been discussed at LACNIC and RIPE. That's /48 directly from the RIR to the end-user. Removal of plan to assign 200 /48s, this is also on our agenda this week. When the AFRINIC -- when AFRINIC was created they adopted a basic v6 policy set, and when they worked on that set, they removed this piece. So AFRINIC has never had this as the part of their initial criteria. It's been adopted in the RIPE and LACNIC region, and it wasn't presented at APNIC, I think it's still under discussion. Second IPv6 allocations, /32 to do something bigger, this is -- if you are an ISP and you went to the RIR or to LACNIC and got a /32, perhaps a couple of years ago, and to test it out and use it -- see what v6 was about. Well, if you are large ISP and you actually discover that you want or need more than a /32, you can go back and exchange a 32 and request something larger. It's kind of mulligan proposal. Removal of in term status is under review at LACNIC, a ULA-central is kind of still being discussed. This is the one where half the ULA space is pretty close to being unique. This ULA central is actually unique, /48 space. Of course there is the global proposal for assigning ASNs from the IANA to RIRs. It was adopted in the RIPE region, it's in last call in AFRINIC and APNIC, and it's close to being adopted in LACNIC and it's on the agenda in a few minutes actually. AFRINIC is modifying their policy development process. They are talking about adding a moderator group, which is kind of a small AC. It would act much as -- much like the ARIN Advisory Council in evaluating consensus. And finally this is -- the point and this is to make you aware what's going on outside the ARIN region. This document -- this is the -- the RIR comparative policy overview is reference document. And essentially what it is updated approximately quarterly by the NRO secretariat. And if you are interested for example and what the IPv6 initial allocation policy is for the different -- the five different RIRs, you can go to this document, look at the v6 initial allocations criteria and it's got all five listed right there. It's got v4 policy, ASN policy et cetera. Here are references links for -- where proposals can be found at the different at the RIRs. Thank you. (Applause)
MR. PLZAK: Okay, as I mentioned during the opening remarks, we have members here from all of the other four RIRs. Does anyone have any questions regarding the policy discussions in the other regions -- you would like some clarifications or would like to comment on at this time, because I'm sure that they would be more than happy to address them with you? Ah, we have a person.
MS. LYNCH: Not a question for the other RIRs, but -- Lucy Lynch, Internet Society -- the presentation that was just given the scorecard, will that presentation be available somewhere? It's not upon the website?
MR. PLZAK: It should be up on the website shortly, if its not there already.
MS. LYNCH: Okay, thanks.
MR. PLZAK: And by the way -- I wouldn't necessarily call it a scorecard as much as I would call it a summary.
MS. LYNCH: Snapshot whatever, it was a very useful presentation and I might take that -- thanks.
MR. PLZAK: Okay. For the information of the all the first timers, this is a regular feature of all ARIN meetings, and the fact that occurs very early in the public policy meeting, in the first morning about the same time as it did -- in the agenda suggested now. Comment please? Oh, its just adjusting microphone. (Laughter)
MR. PLZAK: Okay, anybody else? Okay. As another reminder the other RIR staffs are here and feel free to engage in a conversation in the hallway, in the break, Cyber Café. or at the social, or in the bar, you know, I'm sure if you buy them a few drinks, they will tell you a lot. So, anyway how much of that has to do with Public Policy, I don't know. (Laughter)
MR. PLZAK: Okay, next we are going to give another one of the reports, which is The Internet Number Resources Status Report. This will be done by Leslie Nobile, Director of Registration Services. Leslie?
MS. NOBILE: Thanks, good morning everyone. Okay, operating this thing, okay. This is the NRO Joint Stats Report. This is -- the statistics of all five of the Regional Internet Registries, in a side-by-side format for comparison purposes. Excuse me -- it's updated four times a year, this was updated recently 30th September, so it's recent data. So, this is the IPv4 address space, the distribution of the IPv4 address space that is 256/8s as you know. I'm going to start at the bottom with the central registry that is the pre-RIR space, the earlier registries the SRI NIC, DDN NIC. Most of the Legacy space resides within that block. And it is global space, it's registered all over the world, but much of it does reside within the ARIN region, particularly the U.S. because of the early growth of the internet here in the U.S. There are 44 /8s left for IANA to reserve to -- I think -- sorry, reserved for the RIRs to issue to their customers. There is about -- let's see 32 -- 36/8s held in special use by the IETF and IANA. And then if you look at the top of this circle of the pie, we start with AFRINIC, go down to RIPE NCC, that is the /8 space that has been issued by IANA to RIRs. We are -- some are still issuing from that space, it's all our historical allocations from IANA, including space for issuing from IANA. So this goes back to 1999 that is about as much as we could fit. So, from 1999 to 2000 we have tracked the growth of v4 allocations. From the RIRs to their ISP customers, this is only ISPs and LIRs, this does not include end-user assignments. If we were to add end-user assignment the charts -- the difference in the charts would be negligible, there are not a lot of assignments being made. So, it's basically up and down but the thing that we do see is that in the recent years IPv4 allocations are growing in all five of the regions, particularly in the APNIC region. In fact I meant to mention earlier in the first slide that this year so far IANA has issued 7/8s to the RIRs. APNIC have 5 of them, LACNIC got 2 and RIPE got 2 so far this year. So this is just another way of looking at the first slide, it's just the cumulative total over the last nine years of the /8 space that we are issuing to our customers to our ISP customers. And as you can see for the first time -- actually, this is probably the second time, APNIC and RIPE actually have cumulatively issued more space than the other three RIRs. This is ASN assignments, again growth trends up and down. Really there was a lot of growth in the ARIN region earlier on, but that has leveled off in recent years. And actually I have to tell you that this title is incorrect and I have been meaning to correct it, and I haven't. This is ASN assignments to all customers. This includes our end-user customers as well. ARIN issues quite a few ASNs to end-user customers. So this is to all of our customers based. As it's leveled off in the ARIN region it seems to be growing in the RIPE region, they are issuing more ASNs over the last several years. Cumulative total seems slight, but just cumulatively over the last 9 years. ARIN has issued most of the ASNs, but RIPE is catching up quickly, as you can see. V6 allocations -- again this is a crazy slide -- we started issuing v6 in 1999. There was some steady growth in other regions over the years. But then it started going up and down and all over the place -- the one thing that's clear is the RIPE region is issuing most of the IPv6 address space at this point in time. Over the last year that you will see, 2007 ARIN has issued quite a few v6 allocations; this is only on v6 allocations. We also have an end-user policy, end-user assignments, v6 end-user assignments are we are issuing quite a few of these as well, although it's not on this slide. And cumulative totals again you see RIPE has issued most of the v6 space within their region at this point in time. Although APNIC -- actually all the regions are growing are well, issuing more and more. This is just the links to the RIR statistics, and the RIR status is on the NRO websites and the RIR websites. And then the raw data can be had at the ICANN and IANA websites. So, if you are interested in tracking in any of these that where it is. And I have nothing else. Are there any questions? No? Okay, thank you.
MR. PLZAK: Thank you. (Applause)
MR. PLZAK: Regarding that report -- that report is given at ARIN -- even ARIN meeting and actually it's given out at every RIR meeting. And portions of that or perhaps most of that is also given at every ICANN meeting to the ICANN Board during the ASO report. And lot of people just gloss over that and look at it, but they actually -- if you haven't really been -- been paying attention to it, you really should because, that is where the real issues of upcoming events is really located. And so the statistics are available. The RIRs do on a daily basis update their statistics regarding the allocation of a number of resources for that day. And there are a few researchers that have surfaced that use of statistics quite regularly, but feel free to use them to do whatever analysis that you may wish to do so, as you are going forward. So, it's very important fuel if you will for discussions -- is based upon these numbers.
MR. PLZAK: So with that we are now up to policy proposal 2007-19. It is the IANA Policy for Allocation of ASN Blocks to RIRs. This is a global policy proposal, which means that all five RIRs have got to ratify or adopt it. And then basically what they are doing by their adoption of these policies is making a recommendation to the ICANN Board will be made to via the executive committee of the NRO to the Address Council of the ASO then to the ICANN -- one to the ICANN Board that has become a global policy. So, a little bit of background on it. It was introduced on the PPML on the 25th of July this year. And the Executive Council -- excuse me, the Advisory Council, deemed it or designated a formal proposal on the 28th August of this year. This is the first public policy meeting discussion of it. The text of it has not been revised. The proposal text is in your meeting packet and it is also at the URL shown on the screen. Brief description: ARIN staff understands that this proposal, with great policy for IANA and RIRs regarding all the allocations of Autonomous System Numbers. Block size is 1,024, allocations for a 12-month need until 31st December, 2009 allocations are 2-byte and 4-byte blocks are separate. The RIRs will request additional ASNs when either at 80 percent or less than 2 months need. The shepherds for this proposal are Dan and Heather. Basically, there have been two posts by one person. Nobody was for it or against it -- and there have been no discussions of this proposal, as a formal proposal on the list. However, prior to the formal proposal there were four post by -- being designated for another -- four posts by four people with two of those four being in favor of it. And so from a legal perspective, Counsel has no legal concerns regarding this policy. Counsel believes policies allocating resources based on usage and need are consistent with the operating philosophy of the RIR community. Other policy proposal inconsistent with this philosophy should be subject to greater scrutiny and this was rendered in October of this year. Staff comments, first of all, the additional allocation section indicates an RIR can receive an additional ASN allocation when the RIR has assigned or allocated 80 percent of the previously received ASN block. After December 31, 2009 there will be no distinction between 2-byte AS numbers, and 4-byte AS numbers as a -- per policy. Those that previously received ASN block literally mean the most recent ASN block even if it was a 2-byte only block or does it mean 80 percent above the most recent 4-byte block and the most recent 2-byte block. If it's the latter one would -- if it's the latter, one ASN block would never be audited since it would be never be the most recent ASN block allocated. And this would be inserted into Section 10 of the NRPM. And from an assessment of implementation: Staff usage is minimal, we could do it 30 to 90 days after the Board of Trustees ratifies it. Actually, it would actually be after the ICANN Board of Directors ratifies it assuming there is been no change to this language, okay? The implementation requirements would be a guideline change in some staff training. And so now I would like to call on Axel Pawlik to present the proposal, and then we will have a discussion, but by the Chair. Axel? (Discussion off the record)
MR. PAWLIK: Good morning, everybody. I got up very early this morning and I switched this presentation from I think APNIC to ARIN and I found the wrong number and now we have the right number there 2007-19. This is a very boring proposal, it's -- (Laughter)
MR. PAWLIK: -- it's a government policy though so -- per definition that is very important. For the first time, I think, you see this very nice slide that basically lays out how global proposals go. They go through regional communities and if they get adopted in all the regional communities than the NRO Executive Council tosses it over the fence to the Address Council. The Address Council verifies that it has been going properly through all other regions, and everybody who has an interest, or stakeholders could have said something about it. And if the Address Council finds it okay, then they toss it over the next fence to the ICANN Board and the ICANN Board would hopefully adopt it. So, that's the plan. I've proposed this in all of the other four RIRs regions. Normally the RIR staff don't have any role in policy proposals. However, we think this is a gap that needs to be filled just so it's basically good housekeeping in bringing this forward. There is no problem we do --we do receive end blocks as you know. There is a documented policy, we have that for v4 and v6 and this is, you know, something we just want to have on the records -- easy enough. You've heard about the proposal, basically it is about giving the RIRs 1,024 ASNs per block to give them when we have -- yeah, that's a good point actually from staff here. When we have assigned or allocated 80 percent of the previous to receive ASN blocks -- and I'm adding the "s" here I think that makes sense -- basically would get as many blocks as we need for 12 months and 4-byte and 2-byte blocks ASN blocks to be treated 57 separately. When we started this great road show of presenting this, we looked at the statistics at the RIPE NCC. We saw that at the time a block would last one block of 1,024, as hence would lasts about half a year, just I know that. So, we would get as RIPE NCC at that time two blocks per request. A new request we would get when 20 percent would be left to be assigned. The last interaction we had with IANA on ASNs, took place within two hours so I think two months time an ample buffer there -- that's great. We did make a very small modification and to be totally truthful I'm not quite sure whether that is included in the ARIN draft here. Basically we said the RIRs should assign or allocate -- 80 percent should have assigned or allocated 80 percent of the previously received blocks. That gives a chance to APNIC basically to allocate blocks to the IANA -- straightforward.
MR. CURRAN: Microphones -- microphones are open at this time. Any comments on the policy proposal? Microphones are open.
MR. PAWLIK: Thank you.
MR. CURRAN: Thank you, Axel. (Applause) (Discussion off the record)
MR. CURRAN: Good morning. As I said the discussion and the presentation and the mailing list all go as input to the IANA Address Council, so that they can do their job of making informed recommendations for policy. The microphones remain open on this particular proposal. If any one would like to speak to it -- Okay, seeing no further conversations, I'm actually going to do what we call a show of hands, which is the process by which we gauge the feeling of the room on this particular policy proposal. So, I'm going to ask the question in two pieces, I'm first going to ask for everyone in favor to raise their hands, and then I'm going to ask for everyone opposed to raise their hands. So, on the matter of policy proposal 2007-19 IANA Policy for Allocation of ASN Blocks to RIRs, all those in favor of this policy proposal please raise your hand now. Nice and high. Keep your hands up, we get better at this as we go along, but -- okay, we have a count, thank you. All those opposed to advancing policy proposal 2007-19, IANA Policy for Allocation of ASN Blocks to RIRs, please raise your hand now. All those opposed? Thank you, okay, I'm waiting for the count. Okay, on the matter of policy proposal 2007-19, total number of people in the room is identified to be 168, number in favor 87, number against 0. Thank you for participating. (Applause)
MR. PLZAK: This information will be provided to the Advisory Council and they will be using it as part of their determination of consensus on this.
MR. PLZAK:Next step is the first of the RIR updates and that's going to be presented by Ernest from AFRINIC. Ernest, are you here? Ah, there he is. (Pause)
MR. BYARUHANGA:: Good morning. My name is Ernest, and I'll give you a brief update about AFRINIC and our recent activities. We briefly look at the membership -- membership growth and resource allocation growth, then briefly talk about our IPv6 campaigns, and related membership fees. And then I look at my AFRINIC, which is a new membership where best both of our members to manage their allocations and other registration information. Then we shall look at briefly the policies that we've implemented recently in our region and those that are under discussion. And a brief update about recent public policy meetings and the upcoming ones. This is an overview of the total growth in membership from the time we've started our RIR operations in 2005. And as you can see from about 2005 to now, we have approximately more than 300 members. That's excluding the legacy members that were brought over from the RIRs, who do not pay us any membership fees and any service fees. So, the membership has been steadily on the increase ever since we started our servicing in that region. The increase in membership has also resulted, of course, in a steady increase in number of resources allocated in the community. And as you can see these slide shows a four-year comparison of the total IPv4 addresses that we've been allocating in that region. And as you can see from the time we started operations in about 2005 up to 2007, the trend of IPv4 allocation, there has been about four times, the total number has been allocated in 2007 compared to 2005. So, this clearly shows the impact that's AFRINIC has had in the penetration of the Internet in the region. And next we look at the IPv6 campaign, and of course, noting that the AFRINIC Board has realized that the IPv4 exhaustion is biting hard, and has definitely been think about it. And in view of that, it took a resolution, which rates that noting the eminent exhaustion of the available pool of IPv4 address space, the AFRINIC budges off that efforts to draw the public's attention to the problem and potential solutions such as IPv6 should be intensified and instructs the staff to take appropriate actions in this regard. So, a few things were done for survival, the Board reviewed the schedule of IPv6 fees. I'll talk about that later in the coming slide. And we are forced to attend a few events about IPv6 like the InfoTech conference that was held in Mauritius in which we participated, and also gave a press conference about IPv6 and Ipv4 address exhaustion. And we also send an informative letter to all members on the exhaustion of IPv4 addresses, and on the importance of switching and implementing to IPv6. We also launched an IPv6 information page or portal. We've followed what LACNIC did, and I started something like that, although it's not yet fully informative, but it's online. And we are also planning to do more and IPv6 training in 2009, and the remained after 2008 to cover all the countries in our region. About the training, we've been doing more IPv6 and LIR, which is member training in our region, and I've covered many countries so far this year, including Nigeria, Tanzania, Ivory Coast, Angola, South Africa and other countries, and by the end of the year, we shall be looking at going to Algeria and Tunisia. I mentioned briefly about the changes in the IPv6 fees schedule, and the changes that the Board agreed on is that for already established LIRs, those are Local Internet Registry with IPv4 allocations. They are not bared any extra membership fees or service fees for any IPv6 address space that they hold. And for new members that want IPv6 addresses only, there's a 50 percent discount on the initial setup fee, and a 100 percent discount on the first year's membership fees. And also there is a tip at IPv6 membership fee schedule for IPv6 only members, that is 75, 50 and 25 percent discount on their membership fees for their first three subsequent years. Then we also had a memorandum of understanding with research and education networks in our region. And we decided that -- the Board decided that 50 percent of this signup fees for these -- such institutions be waived. That such institutions have to be not for profit education networks, and they must also plan to offer IPv6 services within the community. There is also an IPv6 -- sorry about that -- there's a new fee schedule that has been proposed by the Board, and has been sent out to the community and is awaiting comments right now. It's not yet implemented and I think if all goes well, it should be implemented sometime next year. This shows a growth in the IPv6 allocations in our region. And as you can see it's been steadily increasing, probably due to the awareness and campaigns that we've been doing in the community. And that map shows the areas in green where we've been -- we've been already, where we've done a IPv6 workshops. Next, we look at MyAFRINIC. MyAFRINIC is a portal, a Web-based portal that allows our members to easily interact with AFRINIC, and manage their registration related information. Some of their functions that are involved in this portal -- is managing of course the Internet number resources, v4, v6 as numbers. Our vast delegations are billing, contacts, new member registration, and many other functions that might be proposed from time to time by the community. So, we did a trial and final testing, and we launched it in our AFRINIC-7 meeting recently had in Durban. There was a live demonstration, and right now it is already active. Oh, next to look at the policies that we've recently implemented. IPv6 provider independent address assignments to end-sites upon critical infrastructure, was implemented. Then the change of the allocation and the assignment period or planning window from 24 to 12 months was also implemented. And the change of the IPv6 HD ratio from 0.80 to 0.94 was also implemented. These are the policies that were also presented at the AFRINIC-7 meeting that we recently had in Durban. And as already mentioned by IANA, this is already a repetition, but quickly go through them. The policy development process, there's a slight change in the policy development process where a moderator group is going to be introduced. This policy raised consensus. Then the global policy for AS number-block allocations from IANA to the RIRs, which Axel just presented a few minutes ago, was also presented by Axel also, at our meeting in Durban. And there was consensus on it. Then some few changes to a few clauses in the current IPv4 address allocation and assignment policy, which was presented by Jordie. The few suggestions that Jordie had made in this policy, were not accepted by the community. So the policy went back to the mailing list for further discussions. Then the global policy for allocation of the remaining IPv4 address space, a rich consensus although their value -- a few values for parameters for "N," that is the number of /8s was not quickly I grade upon. Then IPv6 we had (off mike) there and a discussion, and in the end, policy for NIPv4 allocations areas also under discussion. A brief update from the AFRINIC-7 meeting that was recently held, we have about -- we had about 150 people attending mainly from South Africa, Nigeria, Ghana, Kenya, Mauritius, and Santiago. A 22 percent rise is 14 percent Telcos, and 11 percent from government institutions. We had also a few policies -- a few things like the policy makers did and we had any intensive three-day IPv6 training. We normally have two days. Here of course, five policies are presented as mentioned earlier they reached consensus. One was presented only for discussion and informational purposes, and one didn't not reach consensus. Outcome -- yeah, the policy (off mike) reached consensus of course, and the policy makers did, there are many discussions, there were also lot of discussion, there was a wrong tempo, and it was agreed that to create more awareness in the Internet governance, the IGF and of course, there were few discussions around the IGF in Rio, and the community agreed in a few priorities that should be set by those for presenting AFRINIC or the IGF. And there was anti-spam working group, which was also setup, and of course, few other discussions around IPv6, and creating more awareness in the community around the deployment of IPv6. You are all come to our next public policy meeting which is going to be held in Morocco. That would be from May 31 to June 6 to be held back-to-back with the AFNOG. AFNOG is just like the equivalent NANOG, here, and we shall have an IPv6, in terms of training again. And there'll also the INET meeting and a few other meetings for some entities from that region. Thank you very much. If there are any questions, I'll be happy to take them.
MR. CURRAN: Any questions? Thank you. (Applause)
MR. PLZAK: Thank you Ernest. We are ahead of schedule. So we will take a break now. Please be back in here at about 25 minutes past 10 and then we will begin the first Panel of the morning which will be discussing IP markets. So please come back. (Recess)
MR. PLZAK: We are on the first, probably -- excuse me -- the only panel discussion of this meeting which deals with a subject of IP markets. This is a panel that will be chaired by Paul Vixie. I will let Paul introduce the panel and take care of moderating, discussion, and so forth. So if those that are outside and standing could please cease their conversations and sit down it would be greatly appreciated. Thank you. Paul, it is yours.
MR. VIXIE: Hello everyone, thank you for coming. We have an-hour-and-a-half, which according to my estimate, of the interest in this topic, might be way too little. It is not a fairly long panel, but looking at the PPML and the NANOG list and everywhere else that this gets discussed, it is clear that the interest in the topic is high. So we have quite a distinguished panel for you. Obviously, the owner John, he will be representing himself and his own views, rather than the shackles of representing the essence of the board today. And off goes the badge. Steve Ryan, being a lawyer, cannot shirk the shackles, he will be representing the essence of the board. Ben Edelman, a consultant to the board, will be trying to describe some of the economics. Steve Ryan will be talking about the law. John will be talking about John. And we also have Tony Li, thank you Tony.
SPEAKER: Paul, can you pretend to like the microphone a little bit more. We really can't hear you at the back.
MR. VIXIE: Sorry. We also have Tony Li from Cisco and other router vendors. He is here to talk about routing physics which, believe it or not, significantly underlie the question of IP markets. So my purpose with this panel will be to try to educate the community, get us all on the same page, give us a -- sort of a framework to debate within, kind of, in the hope that reasonable people cannot disagree about matters of fact, but also because we have some important decisions to make and we have made them with a lot of assertions and maybe even some personal comments, and that is getting us nowhere. And I would like to make those important decisions as and informed, and if possible collegial community. So before I turn it over to the panelists, so that they can each make a 10 to 15 minute opening statement, I want to tell you some things that I know. And I guess I will begin by saying what Randy said yesterday. Randy Bush said yesterday that we were not supposed to get here. The -- when the IPv4 address lifetime was noted to be finite back in the mid-'90s, and the top minds in the IETF community got together and sort of started thinking about what to do about it. What was in those top minds was very much that we should skate easily into the future, without a flag day without a period during which everybody had to upgrade to everything. And you know, the ideal would be that we would -- we would not use all of the IPv4 address space. So as I have watched various estimates of the address lifetime and I have watched the different ones converge and it is very clear to me. Everybody is pretty much planning on using the last address, every one of them is going to get put in play. I am assuming that, since there is a lot of capital represented behind those decisions, that there is some kind of planning for what you are going to do after you have used the last address. There may even be some competition, we have heard the term 'run on the bank' used to describe the, you know, how those last addresses will get handed out. So we were not supposed to reach that point. And a little bit of digging over on a website at Sun, I found a paper by Bob Briton. You know, you have to understand IPv6 was not the only proposal that was offered. There were a number of competing proposals from various people who each had, you know, some vision about how we could move into the future. And you can see it, kind of, like a beauty contest, where everybody got up there, and said, this is what I think we should do, isn't it great. And a choice was made by the IESG or I -- the -- whoever -- however these things work, and that choice was made on a certain basis, certain promises were made. That is a little bit like, not just a beauty contest but a political campaign. You know, I am going to pick the person who tells me I will have two chickens in every pot, kind of thing. So the winner of the beauty contest had this to say during the beauty contest. The key transition objective is to allow IPv6 and IPv4 hosts to interoperate. Let's get on to the -- transition mechanisms provide a number of features including incremental upgrade and deployment. Individual IPv4 hosts and routers may be upgraded to v6, one at a time without requiring any other host or routers to be upgraded at the same time. New IPv6 hosts and routers can be installed one by one. Low start-up costs addressing the structure that embeds technique for encapsulating header translation, finishes by saying the IPMG transition mechanisms ensure that v6 hosts can interoperate with v4 hosts anywhere in the Internet up until the time when v4 addresses run out. And allows v6 and v4 hosts within a limited scope to interoperate indefinitely after that. This feature protects the huge investment that users have made in v4 and ensures that v6 does not render v4 obsolete. Hosts that need only a limited connectivity range, for example, printers need never be upgraded to v6. Okay, you can understand why the people who are evaluating the contestants in those beauty contests looked at that and said, "Wow, if you can deliver that then you are the proposal we want." We don't have that. I don't think that we are going to get that. I don't think we ever could have had that. And I think that if the judges in the beauty contest had really looked at this premise and had sort of asked for a much deeper vision, a much more explicit vision about how this was all going to come to pass, they might have been able to determine that this was in the vein of an empty campaign promise. So that does not mean we get to go back and say, well v6 is a failure, let's think about something else. It does not mean that we -- that wishing will not make it so. We are stuck with v6 the way it is, we are going to move to it, in my opinion, we are going to run out of IPv4 addresses, we are going to live in a world where IANA has no more to hand out, but people still want them. So the topic of this panel is IP Markets? Some of the questions that have been bandied in every room of this meeting, and mainly last, and so forth are -- is a market in IP address space inevitable. And then somehow as if you could separate this next question from the first one, is it desirable. And it is easy to have a knee-jerk reaction and come you with what you think are the obvious answers to that. But it is a fairly deep topic, and given that it has its -- that the answers, in my opinion, have their roots in the law, economics, physics, and sort of history and culture. I found the four people best qualified in my opinion to represent those four ends of the spectrum. I guess, the format here will be that I am going to ask each of these guys to present for 10 minutes, hopefully not more than 15. I won't be brittle, but I will sort of give the hint rather than the hook if that's not going well. We should have about half an hour for Q and A at the end. I would ask you to hold your Q and A until all of the panelists have had a chance to give their opening remarks. And then I will get back up and moderate. I think we are going to start with John, then we'll do Ben, Tony and let the lawyer talk last. (Laughter)
MR. CURRAN: Could you -- going to do it from here or from the podium?
MR. VIXIE: Either way.
MR. CURRAN: I'll do it from here, I'm just a panelist. I actually agreed to be on this panel even though I really do try not to speak at member meetings on a particular topic, because the job of Chair can be confusing. The reason I agreed to be on this is because I am working on a whole bunch of assumptions and they effect how I do my job, what I end up recommending for ARIN, and I want to share those assumptions. And quite frankly this is an education process for me. I am trying to share these assumptions because some of them might be wrong and I know that there's a lot of people in the community here who can fix my faulty assumptions, okay. But I want to lay them on the table because I really haven't done that. Background, I have been doing this like a lot of people in the room, been doing this 1990 or so. And I actually get to sit on the IPMG gang along with Scott and some others who are also here. And I recognize as -- the campaign promise that we were charged with was a high one, and it was very difficult to achieve, and some would say impossible. So here is my working set of assumptions on legacy address space. The fact of the matter is that, as we all know, address space is just numbers that is all it is. And when the earliest work in the Internet protocol was being done, lots of people who participated got address assignments, they got them in a whole variety of manner in predecessor organizations to ARIN and the other RIRs for that matter. They got them because they needed them. And back then, by the way, we had a pretty simple way of assigning them, it was presider, so it was, class A, class B, class C, /8, /16, /24. Lots of those organizations were instrumental in making the Internet here a success, and I think that should be recognized and honored. By the same token, it is important to realize that there wasn't a lot of formulas back then. I was involved in some of this activity because of BBN. There was a wide range of very informal communication that ended up making address assignments happen. At this point, the community is looking at IPv4 and seeing that the generally available free pool will deplete at some point, okay. It is not the end of the world, but we are going to go into a different phase than we are operating today. This is causing a lot of attention to the legacy address space assignments. And in some ways that is appropriate. In the mid-'90s we realized that address space was going to be an issue, we instituted CIDER. And CIDER said, you don't get a class A, B, or C, you get a block appropriately sized for your need, your need and your foreseeable need. And some could say that is a change of policy, pretty significant one, you don't get a big block, you get a block that is sized based on need, it is a needs-based system. So when we made that change, some of that actually got institutionalized in some documents, RFC 2008/RFC 2050. When you look at 2050, there is a very interesting sentence at the back, there is a couple of sentences. And it basically says that the need from address block, needs to be ongoing if the -- you are going to continue to hold the address block. It says, if the requirements are no longer met, that assignment can be invalidated by the IANA. Now, the co-office of the 2050 -- actually some of them are here, but we don't have all of them with us anymore. And so the interesting statement to say if you don't have the need anymore, your block can be invalid, your block assignment can be invalidated and returned to the IANA. The way it works is the IANA is supposed to reclaim the block and then the RIR is supposed to see if they can find the holder and say, by the way, your block has been reclaimed. It is of interesting set of phrases at the back of 2050. I don't know whether or not we ever had a social contract that allowed those sentences to be enforced. Even the day they were written, and they went through many of the RIR communities, and they went through the IETF. I honestly don't know whether or not they were something that would be considered the will of the community. But there is a statement that is in 2050 that we all are supposed to honor, that says we are a needs-based system, and we continue to be a needs-based system. And any block is subject to that. So combine these facts, combine the fact that we're approaching the end of the free pool. Combine the fact that for quite some time, we've been on a needs-based assignment program. And then combine the fact that the legacy blocks were assigned based on need, but may not have been a best fit when they were assigned and may not still be in use. This has caused a lot of discussion. And I tell the discussion ranges everywhere from -- it's not ARIN's job to deal with this to, I'm going to meet outside at 10 o'clock at night with pitchforks and torches, please join me while we hunt down legacy holders. And that wide range of use may not be constructive for us. The -- we've asked legacy holders who aren't using their address space to return it. That's certainly compatible with this philosophy. If you don't have the need, you can voluntarily return it. In case, we haven't done it yet today, I'd like to point out Stanford renumbered out of their /8. Once again, I want to thank them for that. There are people who have turned in legacy address space. The reality is that we may not be able to persuade people -- people who have legacy blocks, who have them under use, that's wonderful. It's the folks who have legacy blocks and aren't making using of them at all, and as someone referred it to me the other day, have salted them away for the day when they have value, that's of interest to the community. That's of interest to the community because frankly we might want that address space back in use, in use being used for networking. I will try to keep my -- wrap up my comments briefly. I believe that ARIN needs to recognize that legacy address space holders have for one reason or another, a valid right to their block. They received an assignment, it's their assignment. Having said that, I think we need to facilitate a set of policies that encourage legacy block holders who wish to move their block to someone who can make better use of it. Now, we got to be very careful. I see Tony Li at the end of the table there, and he knows -- he's forgotten far more about routing than I ever knew. And there are huge implications, because when you facilitate getting legacy block holders who wish to put their block back to the community, when you actually make that happen, if you make a mistake, then you can create a lot of fragmentation, and a lot of churn, and a lot of routing issues. This panel is going to talk about some aspects of that, but I do not think that people should think that this is an easy topic. It is not an easy topic. There may be a way to get the 80 percent of the benefit for 20 percent of the cost. There may be a way to do it with respect to the legacy community. If we make a mistake, we alienate the legacy community who, quite frankly, just wants to be able to make sure their blocks are put to better use. There's no -- they're not trying to harm the community. We alienate the legacy community if we go too far on one side or we create a circumstance where potentially, we create runaway circumstances in the management of IPv4 space that we may not be able to control. So it's a very difficult problem. I think there are solutions out there. I think this panel will explore some of it. And that's my opening remarks.
MR. VIXIE: Thank you, John. Ben.
MR. EDELMAN: Thanks. Let me introduce myself briefly for those of you who I don't already know. I've met some of you in prior lives when working at ICANN meetings and otherwise. But I now find myself as a professor at Harvard Business School, largely studying market places, principally electronic market places, advertising marketplaces, travel marketplaces, the market for online trust certification verification, and here addressing, and incidentally, routing. These are great projects for me as an academic but also intensely useful. And with that in mind, I will try to give some comments intended to actually be useful in thinking through what an economist might be able to offer in this decision-making process. I've written down six goals that I think most of us share, maybe, all of us share, that would be great. And let me just go through them because then we can assess possible responses according to how well they serve these goals. Number 1 goal is preserving v4 availability for those who need it. If you contact ARIN and request a v4 address, it would be nice if there is something ARIN can do to help you other than tell you, sorry, we don't have any more of those. Just in terms of keeping the trains running for the many people who, quite reasonably and understandably, do depend on v4 availability right now, and realistically are going to want it to be available somehow, going into the future. Second, encouraging reclamation from those who don't need their v4 space or at least don't need all of what they have. And as John says, that could be, for example, because they are legacy address holders who received a larger block than they now need. In principle, it could be someone else who has more space than they need. For example, there could be some company that received an RSA block from ARIN, yet went out of business, that happens sometimes, it wouldn't be bad to see that space be reclaimed and put to use by someone who needs it. Number 3, facilitating migration to v6. We don't think we're going to be running v4, 50 years from now. And it would be nice if whatever policy we come to terms with is a policy that helps us get from here to there. Four, keeping routing feasible, certainly anything that breaks routing in a big way is a policy that wouldn't be of much use. And so we'd want to bear that in mind in whatever we do. Five, keeping WHOIS working and other ARIN services. Certainly, it's possible to imagine a black market of transfers that don't result in correct WHOIS data. That would be unfortunate, we'd like WHOIS to be accurate and that's quite a reasonable objective to have going forward. And number 6, final goal that I think most folks share, preventing a black market, generally, both because it would mean inaccurate WHOIS and for other problems that it might create. If you needed v4 space and bought it at a black market, you might find that what you thought you had bought wasn't really available to you. For example, the folks you had bought it from had sold it to several people or maybe didn't have it at all in the first place. All kinds of funny things could happen in the black market and it's hard to think that many ARIN constituents want to be subject to that kind of mess. A market that doesn't have those problems, a transfer system that doesn't have those problems surely would be preferable to one that does, leaving open exactly how the transfers would work or whether we'd want any transfers at all. So would paid transfers facilitate these objectives? Well, maybe, some more than others. There is certainly a tension as to some of them. Before I go through some of the specific tensions, let me just point out for those who are thinking of "markets" as being absolute bastions of capitalism with no rules whatsoever where people buy and sell /32s or /29s. You know, that's not quite what I have in mind, at least. I have in mind what I tend to call a paid transfer policy which would look a lot like the current transfer policy except that you could transfer to anyone, not just someone buying your whole company. And there would still be the same sorts of rules that would apply right now, both to new allocations and in principle, to transfers. For example, you'd need to show need, you'd need to show utilization of any blocks that you already have, you'd need to show a plan for utilization of the new block. There would be a minimum block size; the obvious default is to keep the minimum block size the same as the current minimum block size. We're talking about changing one policy, the transfer policy. That doesn't mean you'd have to change the minimum allocation size. We could change it up or down, but there's no reason why you'd need to change it at the same time as implementing a paid transfer policy. And we could add other requirements, too. For example, yesterday, RS on the AC very sensibly suggested a required holding period, that you shouldn't be able to sell off or transfer away addresses you just received. Because really, if you got some v4 space last week and now we see you transferring it away, it doesn't look like you made serious beneficial use of the v4 space. Looks like you are just in this for speculation, and it's not obvious that that's something we want to encourage. There are plenty of other commodities to speculate, and maybe, this isn't one where we want those folks. Separately, a required holding period as RS suggested, could prevent at least an acceleration of the race to the bank as we near exhaustion. There wouldn't be much point in asking for space you didn't need, just before exhaustion with the plan of selling it off a month after exhaustion, if it turned out you were going to be required to hold that space for two years or three years or some other period, by which point who is to say where prices of v4 might have gone. So that's just to say there are plenty of levers for adjusting a paid transfer policy to make it compatible with the reasonable policy objectives of the ARIN community. And just because there is one version of a paid transfer policy that we wouldn't like, that doesn't mean there is not some way to tweak it in order to make it accommodate the reasonable policy objectives that most of us seem to share. I've written down three specific concerns that I've heard repeatedly in talking about paid transfers and I wanted to just give some brief remarks on each of them. Number 1, as to the implication of paid transfers on routing, the natural worry is that paid transfers would be transfers of very small blocks and that the explosion of announcements of many very small blocks would lead to a massive growth of the routing table and a routing collapse or other serious routing problems. I think that's probably true if you allowed transfer of very small blocks. But one benefit of having a "white-market" rather than a gray-market or a black- market is that you no more have to allow transfers of small blocks than you currently allow initial allocations of small blocks. If it's not allowed, then it's not allowed. And so you wouldn't necessarily expect that such a policy would produce disproportionate growth or convex growth in the routing table. Now if we let the v4 Internet continue to grow, by finding more v4 space and allocating it out to operators, that will mean growth of the routing table, of course. But it's the same kind of growth we'd get if some big legacy operators happened to offer large /8s to ARIN, which would then be given out back to the community through the usual process. So some growth in the routing table, yes. But it's not clear that with a properly set minimum allocation size, that has to be an explosive growth. At least, not clear to me. We'll see what other people say. Number 2, that paid transfer policy for v4 addresses could delay transition to v6. If we keep v4 working too well, then, people won't move to v6. That's kind of an odd worry to me because if we found ourselves with 100 /8s in the IANA free pool rather than 46, I don't think we'd be sad about that. We'd be happy to hear that exhaustion is that much further away. But I do credit that we might need some Flag- Day-type event, or in any case, a big kick in the pants to get folks to realize, hey, it's time to do something about v6. And the more we soften that blow -- the more we soften that blow, the less likely it is that people will wake up one morning and say, gee, you know, it's very, very hard to get a v4 address and so I better move to v6. If it's only moderately hard, they might not feel the impetus to move to v6. So there is a real tension here, a tension between serving the communities' short run interests and having v4 available on easy terms that aren't to onerous, and the community's long-term interest in moving eventually towards v6. The final concern that I've heard, and I do take this one pretty seriously too, is a suggestion that a paid transfer policy could set an unfavorable precedent. If you can pay for the transfer of v4 space, does that mean you could pay for the transfer of v6 space? I think the answer there has to be affirmed, no, that we're implementing, we might implement --we discuss implementing a paid v4 transfer policy only because it is necessary to accommodate those goals and objectives that I set out earlier in my remarks. We don't think that paid transfers of Internet number resources are the way to go in general. That's an outlet the community has said, that's not what the RFCs say. And anyone who takes this discussion to suggest that they should be selling off their v6 space, I think is seriously mistaken. Well, all that aside, there are some clear benefits to a paid transfer policy, you'd allow v4 to keep working for longer, folks who need v4 could come to ARIN and at least for a price, get it. They might not like the price, but being able to get it for some price surely seems like a more palatable option that being told you can't have it for any price. I'd rather find the last pint of ice cream in the grocery store cost $10 than find that there is no ice cream at all in the grocery store. Let it be my decision. Thanks very much and I really look forward to a discussion; anybody who wants to flag me down in the hallway, this is what I'm here for and great fun, I look forward to it.
MR. VIXIE: Thank you, Ben. Next up will be Tony Li.
MR. LI: Thank you. Good morning, my name is Tony Li. I'm currently with Cisco systems. Please note that my comments this morning really are my personal opinion, not those representing my employer. They have their own opinions, I don't know what they are even. I'm not here to play my router is bigger than your router. There are lots of people who want to play that game. I think that's inappropriate. I do want to talk about the implications, the physics, if you will, of creating this market. Yes, we can have a paid transfer market and when we do this, it is inevitably going to have some effect on the routing table. Depending on, exactly, the physics of this market, it may or may not motivate de-aggregation. Keeping a minimum prefix size seems like, certainly a warranted thing. However, that alone does not seem like it is sufficient to preclude routing table bloat. What would happen if every holder of every /8 suddenly decided to sell off all their asset as /24s? Does anybody want to carry 16 million routes? I have a problem with that. I think there are some issues. And how fast does that happen? Conceivably, that could happen next year. Is your router ready for that? The physics, here, is pretty simple. Moore's law, states a simple thing about -- it is an observation about the growth of silicon. Basically silicon capacity grows about 2x every two years, at a constant cost. Now, if we accept already that ISPs are going to have to replace the routers, just as is the matter of technology refresh. And that Moore's law is going to apply to that, that we will get some benefit automatically through that. However, it's possible that if we get a rapid growth in the routing table, we could exceed that. Right now, the routing table is growing about 1.3x every two years. Well, within Moore's law. However, it has exceeded Moore's law for brief periods in the past. There is nothing to constrain it to say that that won't happen again. And a sudden explosion due to the creation of a marketplace, regardless of the color of that marketplace could exceed that growth rate again. And Moore's law primarily talks about the capacity of those parts. What it does not talk about is about the speed of those parts. And in particular, what's really interesting is memory speeds. Memory speeds in your laptop right now grow about 1.2x every two years. That is the RAM that you buy, that stick of RAM only gets a little bit faster, the clock speed on it only gets a little bit faster every couple of years. In fact, it's getting faster not as quickly as we're growing the routing table today, right, 1.2x is less than 1.3x. Why is this relevant? Well, when your router gets a full BGP update, we have to take all of that information and write it to memory. The longer it takes us to write it to memory, the longer it takes BGP to converge. Since, we're growing the table already faster than the memory speeds are growing; we're seeing BGP converge more slowly. Those of you who've been around for a while know that convergence does seem to take longer and longer every single year. This primarily affects the BGP routing table itself, it's the -- what's sometimes called the BRIB and also the main routing table within your routers. Now there are ways to engineer around this. You can compensate for this by adding more banks of memory. But this is completely a nonstandard, non-uniform and not off-the-shelf common part approach and it does not scale very well for very long, it gets very painful. Now, between this and the capacity, we quickly get into an interesting problem. If the growth rate goes up, then we have to do some interesting and more challenging hardware. And that can cause the costs of the hardware to go up very, very rapidly. If you start doing full custom hardware, then routers can double, triple in price from where they are today without very difficult problem. So the real question then, is what is the growth rate going to be and what is the steady state going to end up to be? I have a problem; I don't want to try to guess the speed of a land rush, okay. The market can create that land rush and without any kind of kind of back pressure on the speed of the growth on the routing table, we cannot begin to hope that that speed is something that we're going to be able to deal with. The good news is that if there is an open market, there is some upper bound to the size of the routing table. It's hard to see how the IPv4 routing table can get past 4 billion routes. (Laughter)
MR. LI: Okay, so how do we create back pressure? Well, the economics of this is painful. Every prefix holder who would actually want to have themselves routed actually ends up with their prefix in a bunch of routers out somewhere in the DFZ. By rights, the prefix holder should pay all of the transit providers in the DFZ, and other providers who are actually going to carry that route for the privilege of being in that routing table, right. If I insert a prefix, I'm causing cost to everybody else along the way. I should go out and pay all those people. Now, we've never done that because that's just frankly impractical. It's -- go out and pay everyone else for your lifeblood. But that is the correct quid pro quo for doing things. How do we do this? Well, there are several ways we could abstract and make this market simpler. We need this back pressure market so that we get some kind of sanity on the growth rate. To do this, one possible way, ARIN could act as a broker. It could be the middleman which sits in the middle, where a prefix holder comes to ARIN; ARIN somehow pays the relevant transit providers. I don't know how that would be set up but that's one possible approach. Another crazy approach might be to have ARIN create a market for routing table slots. Prefix holders pay, do you have routing table slots, the members agree to carry all the things in those slots, there you go. How many slots that would have to be decided by the members. How do we do this? I leave that open to you. I can tell you that we have a problem here. I don't have a good solution for you; we just need to address it somehow.
MR. VIXIE: Thank you, Tony. Last up will be Steve Ryan.
MR. RYAN: I'm a trial lawyer, I don't sit down when I talk. (Laughter)
MR. RYAN: I'm not that tall either, so it's hard to tell, so I'm standing now. So I'm actually not going to take 15 minutes. Believe it or not, I took an hour yesterday, and some of you had to listen to me then. Let me do a couple of issues. The first issue I want to talk about is that as a lawyer, this organization has 11,500 to 12,000 contracts that are out there that have certain legal presumptions in them. And since I'm a catholic, I'll talk about theology. There's a catholic theology and you believe certain things. Well, our contracts believe certain things and they've written them down. So if you look at the RSA right now, the -- not the legacy one, but the one that's been signed by 11,500 companies, it says that they are purchasing a service and that no one owns the IP. Okay, I want to -- I did cover this yesterday, but I want to emphasize it in this room for those who weren't there. The service bundle that people buy, if -- to make it clear is a whole series of services that ARIN provides. This room is one of those services. And somebody might say, well, hell, Ryan, all I want is the service of -- related to and I want a unique IP number. And the answer is we don't disaggregate and sell things a la carte. This is not the cafeteria where you decide that you want asparagus rather than green beans and you're willing to pay $0.50 more. You're getting a bundle. And it that service, as defined in the RSA, our services like being listed in the WHOIS, which is important for each of the persons and important for the community, the reverse DNS lookup, the variety of services are sold that way. So I want everybody here, as they listen to people talk about a market to distinguish right now, that I think you have to decide are you talking about a market where it's the transfer of the services to another party or are people arguing that we're going to fundamentally change the nature of what this thing is and say, it's owned, I own the IP number. Right now, the community says, you don't own the number. ARIN doesn't own the /8 that it's distributing from. The IANA doesn't quote -- well, I suppose, it maybe a more interesting issue for the IANA, I won't go there. But the difference between ownership of the IP number, like a Ford LTD is not what we're talking about unless you want to put that on the table, okay. So when other people propose a market, all right, they come up with a policy proposal for a market. I want everybody to be sensitized to this binary choice that has to be made. Are we talking about a market that says, I own the thing, the IP number, just like a Ford LTD or do I own the right to the services that are included there? And the way I've argued this in court to try and explain it to judges is that -- and I'm not going to here because we're on film. I usually take out my credit card, judges, generally can't see you credit card number and it's safer, but I'm not going to do it here. But imagine that I have a credit card here. There is a number on the credit card. I'm not entitled to the unique number on the credit card. I'm entitled to the service of the credit card. If the company wants to send me a new card with a different number, for any reason, for their reason, if you read their contract, which is much more difficult to read, by the way than the very clean and beautiful RSA that we have -- (Laughter)
MR. RYAN: You would find that they can switch that card out and change that number at any point. So what we're offering is a unique service that's related to the uniqueness of your number and the services that go there, which we call the services. So, point 1, I got to make sure that you don't allow anybody who is proposing a market to not make clear which market they're talking about, okay. Second, transition, lawyers worry about, in the immortal words of Lloyd George, leaping a chasm in two bounds. If we have a current legal regime that we have had substantially agreed upon by the community as evidenced by the 11,500 contracts, it's very hard to say six months from now, we're going to go to a marketplace where those rights will be different, because it really skews what's going to happen in the next six months. Are we going to continue to allocate at prices that frankly are less than one decent-sized router that Tony's company sells, the biggest amount of money that anybody is paying, in essence, is a very low amount for IP addresses right now. We've given those IP addresses out based on need and we have sustained this organization, the total budget of this organization is quite small. We never monetized ARIN or any of the other RIRs the way VeriSign monetized itself. I'm not casting aspersions, this is a neutral statement. But we haven't gone into the business model of aggrandizement. So I don't think there's any intention to do so. But you have to look at these sort of issues. How do you do the transition period? It's not even enough to come up with an elegant model of what the market would be. You have to tell me how I physically change 11,500 contracts into that. Is it simply that I change the transfer policy, which can be read back into the contracts? We have to grapple with the mechanics of how to do this, because we have an existing legal regime that is very important to transition correctly. The third issue, going back to that service issue, I'm very interested, and I would appeal to any legacy holder, I'm collecting as much legacy documentation as I can. And I'll agree to accept it in a redacted form so it's not specific to a company. I'm trying to figure out what anybody would argue was the promise made to legacy holders in the correspondence and/or documentation or in a government contract for the contractor who is dealing with legacy holders. I'm looking for a paper that would illustrate the rights that were given. In other words, everybody could get up and say, well, I think I have a right as a legacy holder to services for free and perpetuity from somebody. Well, I'd like to see the paper that helps me understand that lawyers are creatures of looking at documents that people created previously. It's the only profession where plagiarism is patronized as opposed to going punished. But we need to look at that. And let me just tell you. I want you to go home and talk to your general counsel at your company, if you're a legacy holder and you think you're going into a market where your v4 space may become very valuable, and that may be. One of the interesting issues I've thought about, for the first time, frankly, in the last couple of days, from a SOX standpoint, if you're a public company, may be, you better put that asset on the books before you try and sell it. Or when you make your first sale at a price, do you then have an asset that you have to value on your balance sheet? So there is a lot of funny issues that begin to run around as you start to think about the application of markets to other laws in this particular area. So for example, I would bet that no company and some of the great companies have legacy address blocks. I bet none of them have valued that on their balance sheet. I bet there is not a nickel attributed on the balance sheet to a IPv4 block. So these are the kinds of issues that may send the Ryan children to another year of college for which I'm grateful. (Laughter)
MR. RYAN: But it also, I think, illustrates, how complex a problem it is to take us from one model, which is the model of giving it to people who demonstrate that they need it and can utilize it at a very low price, at a very low price. And let's talk, in my last minute, and my last remark is about government regulation. Most markets in the United States are regulated by someone. So for example, in the insurance market, the 1952 McCarran Ferguson Act allocated most of the governance of the insurance industry to the states, but the state insurance commissioner, therefore, regulates it. In the United States, a lot of the technology issues about bandwidth and about spectrum are regulated by the FCC. The FTC has the ability, the Federal Trade Commission, has the ability to address unfair business practices. The point I want to make is, somebody in government is going to also decide that they have a regulatory right to regulate this market. In fact, I would actually argue that any business practice that the community comes up with and individual companies come up with would be subject to Section 5 of the FTC Act. So we're going to step into an area in the ARIN service region. Ray, do we have 19 sovereign nations, or 22, how many do we have? Remind me, I forget the number. So we have a number, almost two -- you know, we have -- or 20 different sovereigns who may choose to regulate this issue in their own way. In other words, one of the interesting things about the Internet is that while it is -- I mean, an amazing engineering feat. And the standard setting non-governmental operations bodies have done such a wonderful job of creating something of tremendous value to the people of the world, you know, this is going to be highly regulated in some ways depending upon how political people look at it. So I just wanted to add those thoughts and then give back the rest of the time so that other panelists could react and so you will have more time for yourselves.
MR. VIXIE: Thank you, Steve. When I was the president of PaX a couple of years ago, we would routinely get a letter from Santa Clara County asking who owns all that equipment that is in your data center and what is it worth and how can we collect 1 percent of its value every year because it is real property on which we wish to tax. It'd be very interesting if IP addresses or the right to use IP addresses becomes an asset on people's books that they have to pay property taxes on. And that's the kind of implication that I have been, sort of, listening to, kind of, in the shadows of the discussions people want to have. It's been observed by a number of folks that an IP address market already exists, that these blocks are routinely transferred in exchange for money using shell companies and there's all kinds of dodges that the people have said that they've heard of although no one has said, yes, I use that one, but everyone has heard that this has been done. And so the refrain is there's already an IP address market and ARIN can keep its head in the sand or not. I'm not sure that's true, because the implications of a fully white-market where these things are assets and you're paying taxes on them and your company evaluation can go up and down based on some sort of a commodities exchange in IP address right to use. That may not be what people want; it may be that a gray market is as far as the community wants to push. Now, in the discussion this morning of the Legacy RSA, Steve said, by the way, we're on revision 9 of the RSA, the non-legacy RSA. And it's easy to see, if we've gotten up to version 9 that there may be a version 10 out there in the future or even a version 11. It could continue to evolve. It maybe that the community, through the public policy process and the members through electing, you know, the AC and electing the board, will determine that we need an RSA that people can voluntarily upgrade to that allows transfer. You've heard up here some of the issues that I think will need to be carefully studied and considered before the community asks that that be done. I -- these are the interesting times that I mentioned in the ancient Chinese curse. It would have been much better if we would all have slid right into v6 and not have to deal with these issues. The community and the technology is just not prepared to go through the transition that we are going to go through. So we have about a half an hour. And I'm hoping to hear from folks. Primarily, I'd like to hear questions of the panelists to expand on the remarks they've made. As a secondary issue, if we have, you know, time, we have no interest in questioning the panel, but you have your own views that you'd like to share, then, you know, that is not as interesting to me. On the other hand, if you're going to, and I see Randy Bush at the microphone, I was not directing this at you, in particular, but if you're going to raise your own views rather than ask questions, get to the back of the line and then when you raise your own views, please say something here that you have not already said on the PPML, people heard you there, they don't need to hear you again here saying the same thing. Please say something different. So before we go to the microphones, I'd like to just ask the panel, does anybody -- has anybody been inspired by the comments of your fellow panelists to amend your remarks or question your fellow panelists about anything?
MR. CURRAN: I think we've talked long enough.
MR. VIXIE: Okay, Randy, you are first.
MR. BUSH: Randy Bush, IIJ. Thanks for telling me what I can say, and what I cannot say, Paul -- membership I am sure he really appreciates that. Is that a bug or a feature? (Laughter)
MR. BUSH: Thanks for telling me what I can and cannot say, Paul, membership really appreciates prior censorship. The Internet is a cooperative place or has been. It would be nice if we could try not to make enemies of each other and enemies of legacy holders et cetera, Steve. This is a cooperative place. Let's try for a win-win solution, not an adversarial solution. Tony, which do you think is more -- significantly more likely to cause routing table growth? NATv4, because you know, v6 doesn't catch on, NAT-PT because v6 catches on and everybody needs a bit of v4 space to run NAT-PT, or marketplace ignorant to that transfer. Just as he said. I see transfer as how those people are going to end up with the small bits of address space they need, which is what is going to drive it. But we as technologists haven't given them any other path out. So, the question is really what social or business mechanism is going to let them run their networks? And what's the real driver is they need those little slices and dices because they are going to run PT or 44.
MR. LI: Randy, first I think we became adversarial about 1992. CIDRD was clear example. As far as what's going to blow up the routing tables fastest. I don't see that NAT matters one with what flavor of NAT that you are going to use. You are going to run your network behind a stub, and you need to have enough unique addresses to run your NAT box regardless of what's behind that. As far as, you know, transition to v6, anybody's guess. With us handing out lots of /48s flat, we could easily blow up the v6 routing table too, because the policies there aren't any different.
MR. CURRAN: All right -- respond to Randy as well. I don't know how much of my comments you -- my initial presentation you heard, Randy, but I agree a 100 percent with the facts of the matter that it doesn't have to be a us versus them situation. Many of the people in this room are legacy holders. We are all one internet community. It is not clear to me that the policies and procedures, the documents, the RFCs, even going back to CIDR and 2050 necessarily were applicable to anyone who received a legacy block, because they postdated them. Now, it is true that those people who got legacy blocks probably had some social obligations, but we don't really have a clear record of that. So, we are one community, and I do not believe -- I don't believe it's in anyone's interest to attempt to force in either direction an answer on the other.
MR. BUSH: Thank you.
MR. DARTE: Hi, I'm Bill Darte. I'm on the ARIN AC, but I'm just speaking for myself and Washington University in St. Louis. So my -- my question is, I hear the regulation characteristics that were espoused for white markets that would control the deaggregation and the expansion of route tables et cetera. I'd like to understand how you think that that would -- that would be real control, when if people wanted smaller blocks, they could simply go to like, gray or black market to get those pieces of small address space that they want that were not within the policy of the white market. And I do think that the real regulation could come from government, of course, but the real short-term regulation is what Tony referred to is in the -- in the routing community themselves, they'd be able to filter out things that were inappropriately small as route tables got bigger and bigger, and so being able to put those together. So the question is how do you actually facilitate the control that you'd like, in the white market?
MR. EDELMAN: I think that's a very fair question. I've looked at a variety of laws and rules, some of which get taken seriously and some of which don't. Your question really gets to the core of that. How do we make sure that this rule that transfers are supposed to go through the official white market, not through some other market, a gray market, is a rule that the community complies with and takes seriously. One thing that you see across countries, across rules, across legal regimes, is that a rule that most people can follow most of the time, is a rule that's more likely to be taken seriously. A rule that is perceived to have real benefits to a community is a rule that more people are likely to take seriously. Conversely, a rule that most people need to break just in order to get done what they need to get done, is a rule that is not likely to be taken seriously. So to operationalize that, if the white market is satisfying most of the needs of most operators, and they can get most of what they need most of the time, plus they understand that if everyone else didn't do it, then we'd have a real mess on our hands, you would think most people would continue to comply with it. On the other hand, if the rule is too far from what people need in order to just run their networks and do their jobs, then you'd find that your authority tends to collapse, and it's harder to get from here to there. That's just to say, don't overplay your hand. If you can keep the WHOIS data accurate, for example, so that everyone knows you should be able to look in WHOIS to find out where a net block is being used, who is using it, and who has authority to use it, then, any transfer that doesn't result in accurate WHOIS data is sort of a pariah. It's all the way out there, it's not the way things are supposed to be. But if we let WHOIS deteriorate, where a third of WHOIS records are inaccurate, then there is no longer any strong incentive, and you might as well just do whatever gray or black market transfer you want, let WHOIS be wrong. But hey, WHOIS is wrong for a lot's of things, so it's just not a big deal.
MR. VIXIE: I want to add -- in addition to the accusation that ARIN has it's head in the sand, but not allowing transfers and, you know, ignoring the market that currently exists, I would say that you could characterize some of the complaints or accusations about ARIN's alleged misbehavior with regard to the IP market as overplaying our hand. And I think it's -- it's important to realize the reason that ARIN and board and so forth keep saying that IP addresses aren't property is -- that's what every bit of our constitution says. Our bylaws say it, our RSAs say it, 2050 says it, everything says that. That can be changed. But that's the current situation. So we are not exactly trying to prevent a market as much as saying this is the current situation. We are doing the best we can with the current situation. Now we are talking about changing it. Let's make sure that we remember which time we are talking about the current situation, and which time we are talking about the perspective situation. Far right microphone.
MR. ALEXANDER: Dan Alexander. I am with Comcast, and on the ARIN AC. But this is really just a personal query. I'm not arguing that there is a number of ways a market system could be put in place, and there's lots of different ways we can do it. But I think the general opinion is, once that does happen, it opens the door for government involvement and regulation, because we're not just talking about one -- any one particular government or economy, this is a world system. So once this regulation and government involvement comes into play, I'm curious of any of the panel's opinions. Do you think that in a predominantly v6 world, you can close that door and will have any resemblance of an open, you know, an open community type consensus once that door has been already opened?
MR. CURRAN: I think that there is a lot of discussion about markets and markets for IP addresses because of the situation that we face today with IPv4. If we were 70 percent through the IPv6 transition, which we most certainly are not, but if we were, you probably wouldn't have a lot of people discussing markets, because while there is some demand for IPv6 address space, we've done very well in making it available. And the reality is that the value of uniqueness and unique numbers for v6, there's a lot of them in IPv6. So it's not a question of I have to have a number, it's just, do I get a PI number or a provider-assigned or provider-independent. I don't think we'd be having a discussion on markets in the v6 scenario or v6 standalone internet. Because we are here talking now about getting through that transition, there's a lot of discussion about whether a market will make the current pressing circumstance of the depletion of the free-pool more tolerable to the community with a few enough side-effects. So, I think truly this is a temporary situation. You want to take a 20 year, 50 year world view, I do believe that long-term you wouldn't necessarily see a market, because of almost no demand in a pure v6 world. The reality is that if your provider is willing to accept a provider-independent block for you connecting, your neighbor might have 65,000 of them. He can give you one. Okay. There's such an abundance. And if your provider won't accept a provider-independent block, it doesn't matter if you go to the market or not. So, because of the assignment sizes and the number of prefixes we're giving in v6, per se the address- block may not have a lot of value, and there may not be a sustainable market 20 years out.
MR. VIXIE: Tony, what about the market you are proposing? You see that going away if v4 depletion is behind us and v6 is with us?
MR. LI: No. V6 is simply v4 with bigger addresses. If you go to a bigger address you still have -- and even if the individual prefix doesn't have value, the routing table slot is still expensive. In fact, for the v6 slot, it's more expensive.
MR. VIXIE: How does that get recovered? How is there any back-pressure?
MR. LI: We cannot support a full routing table full of /48's. It's three times ten to the fourteenth routes.
MR. VIXIE: That's a lot of routes. Center microphone.
MR. DURAND: I'm Alain Durand, Comcast. This notion of a market for v4 address is sometimes presented as a panacea to delay the day where we will run out of v4 and when we can just be happy and not worry so much about what's after. The question I have is from an economical perspective. To have a market you need to have supply and demand. I have no worries about the demand side. Every body here wants to go have v4 addresses. The question is more on the supply side. There have been empirical evidence that small and medium size block have been traded more or less openly. But what about large block? If I am here to get a large assignment because I have a lot of customers and I need to grow this, I will be looking for a large block. So the question is, have you seen any evidence that legacy holder who have large blocks will actually be wiling to trade them as large block and not simply slice them as small chunks? And if not, then what are the consequences on their balance in this community? Is it not solving what essentially will help small and medium size guys to keep growing in v4 at the detriment of larger networks, who will not be able to grow because they cannot get assignments of the size that they need?
MR. VIXIE: Anyone?
MR. EDELMAN: As you say, it does seem that the price for a large block might have to be disproportionately high, that is convexly higher. You might find that if you needed a /8, gee, that's going to cost you more than 256 times the price of a /16, because the supply is just not there. On the other hand, that is directly in tangent with, I think, Tony's worry for example, and some remarks that Paul and John gave us earlier, worrying about growth of the routing table, worrying about carving up blocks into very small blocks. So different people worrying about different things, it's not to say all the bad things couldn't all happen simultaneously. But the prevailing wisdom among most people talking seems to be, you are going to want to cut up these blocks into as small pieces as you can and use them for whatever smaller purposes. If you need a very large block, maybe you are the kind of guy who should be moving to v6 sooner, or I guess perhaps putting services behind a NAT. It doesn't seem like there's a big future for operators who need more and more /8's to run their business.
MR. CURRAN: Just to be clear. Since the value of the address is to allow you to connect to the public internet, and a lot of organizations don't feel they have to number all their hosts, just their DMZ's or their firewall works, a /30 allows an organization to get connected, and that's valuable. A /26, /24 may not for a single organization add more value, they are more valuable to an ISP who can slice them up into pieces and let lots of people connect. But if you are holding on to a block and somehow you are allowed to transfer it in whole to an ISP or break it up into lots of little slices, so lots of little entities can propose using that block slice to connect to their ISP of choice, okay. If that's actually allowed, it's almost inevitable you will get far more value out of many /30's for example than you would from the entire block. Now, there's two corollaries to this. The first one is, there's no back-pressure in the system I just proposed. There is no filters that are preventing people from accepting those. We all know filtering may prevent that, but we don't have a good track record industry-wide, and you are asking people to have filters when they can't serve the customer without dropping the filter. And all of us have a different view what happens there. My view is the filters won't survive; people will connect customers because they want to connect customers. The other assumption there is that when you add that route, because you have that /30 PA piece, that there is no incremental cost that's directly attributable that you can go back to the customer and say, yeah, you can get a /30 or a /24 from the market, but you are going to have to pay to have it routed. What Tony discusses is exactly that. Right now we have a -- we have the potential for a market in addresses, but we don't have a present market in the routing table entries. And the systems are tied pretty tightly. If you let the fragmentation of IPv4 space occur, and you don't have an answer that involves policy filters or a natural push-back by having a market in routing table entries, you've sort of let one-half of the system spin out of control with no governor from the other half. So, it's envisioned that people will do the natural economic thing, get their maximum utility value out of the resource, and break it up as far as the system let's them break it up. Does that answer your question? A little bit, okay.
MR. VIXIE: Bill.
MR. MANNING: Bill Manning, native English speaker, tempered by California public school education. So I don't understand all the words. First of all, I'm thinking of the little Bedouin shepherd who found the Dead Sea scrolls, and found out that he could get the most money by tearing them into one centimeter increments. The value of those one centimeter increments to him was very high. The value of the entire scroll was much higher later on. We've been talking about markets. I would like the panel to describe need. When I hear need-based, I think, I need the whole set, I need the numbers to -- as a resource, as a commodity to buy or sell, or I need the numbers to move IP datagrams. What does "need" mean to the panel?
MR. CURRAN: I'll go first, as soon as my mike works. I subscribe to the need -- the definition of need that's described in the concepts in 2050, which is that your documented need of a resource is your ability to use it to number network components for purposes of carrying traffic. Okay. So that's kind of a conceptual area that goes behind a lot of the policies, when we ask you why do you need these addresses in the next six months. There are other people who say there were other needs like, I need this because my investment fund will do very well if I buy it now and sell it later. That's not the concept of need I'm using, Bill. I'm using 2050's concept.
MR. VIXIE: Right-hand microphone.
MR. WOODCOCK: Bill Woodcock. Not speaking for the board. So, since the 1980s, Neocon, Bizdev, people who have read too much Ayn Rand as small children have been putting a lot of energy into convincing us of the benefits of unregulated markets not in our backyard. And as a Californian, I lived through one of the United States' very few experiments with doing that in our backyard, the energy crisis where in speculators were allowed to trade in energy rather than allowing the energy to go to the market, the utility market for the people who have the actual need. I recognize that there are vast differences between electrical power and IP addresses. I also recognize that, Ben, for instance, when he is talking about a market, is speaking in much more nuanced terms than this idea that we've all been beat over the head with, since Reaganomics. But I think probably the vast majority of the people in this room, when they hear market, are not thinking exact continuation of our current allocation policies, just ARIN's run out of space so you get it from somebody else. I think probably a lot of people have got the idea, oh, that means anybody who wants to can buy or sell to anybody who wants to at any price that they mutually agree upon regardless of whether that's, you know, Enron II and the subsidiary of Enron II double booking trades back and forth until the prices got high. I wonder if you guys could talk a little bit more about the difference between the utility value and the speculative value and how it is that we would continue to keep addresses available at or near the utility value, that is the value that corresponds with how much -- as ISP's were able to make from having them.
MR. VIXIE: Ben.
MR. EDELMAN: The speculative value should reflect something like the expected long-run utility value. It's hard to see that a speculative value could ultimately reflect the value other than what the asset is expected to be worth. But, as a long-lived asset, a v4 address should last for as long as anyone is using v4. You might find that the future income stream from a v4 address could be a lot, and could lead to a surprisingly high value if you wanted to buy one address or one block of addresses from a seller. Now tempering all of that is the fact that there's quite a bit of supply. Assuming that our transfer rules didn't in some way limit supply in a -- in a very striking and overwhelming way, there would be lots of "sellers," lot's of existing blocks potentially coming to market. Think of the big corporate legacy operators who might like to get a boost in their annual income. So if there are many sellers competing to sell, you might think the price will go way down, and sure enough, in some markets we have had that experience, think tradable pollution rights in California. Now there are ways you can screw-up paid transfers, you can screw-up electricity as California did in various ways through loopholes and laundering and speculators. Often if your rules get more complicated, there are more ways to manipulate them, think the tax code and folks who find loopholes there. A nice simple set of rules is easier to debug, and easier to make sure you haven't left too many gaps, conflicts, or ambiguities. But I certainly credit your instinct to say that not all markets have worked perfectly over time. Here the fact that there is a stock of v4 addresses that the existing operators all have, everyone can keep using their existing v4 addresses that helps a lot. That's quite different from electricity where you need new electricity each hour, even each minute, and so prices really can go crazy. There are aspects of this marketplace then to make it much easier to design and somewhat harder to screw-up than others, especially electricity. And that, you know, makes me feel more comfortable with it. If we were dealing with something as hard as electricity, it might well be above my pay grade.
MR. KAPELA: Thank you Paul. Anton Kapela. Just wanted to turn a more technical question up to the panel, and I don't know if more than Tony might want to respond. But anyone who feels able, please do. We've taken, it seems, for granted today that we have these awesome pre-populated FIBs, TCAM. We haven't had to think about Soup-1A type issues for a long time, right. No one has a flow router and a core. Do you see any movement, any change in this great place we are at right now? Do you see that moving to something where maybe we are not fully pre-populated, maybe there are caveats, maybe certain things aren't pre-populated. Maybe at the edge where enterprises might interconnect, where the number of routes is orders of magnitude large than in the makeup of the flow traffic. Maybe this would change. Maybe a million routes in the table is no big deal if it's all in DRAM and they have 10 active connections all day long. What -- do you guys see anything, anything there?
MR. LI: I live in the core, and I don't see anything changing very much there. What's going to happen to the edge is anybody's guess, especially if you look at the VPN ways -- ways that VPNs get used, and also the way that certain enterprises want to do other strange things internally. I don't think those are really appropriate topics here, because really it's not part of the internet at that point, right. That's behind the front door of the enterprise.
MR. KAPELA: Sure. With regards to the edge, of course, so in the core you would think that our standard way of doing things is not going to change regardless of how large the table over grows?
MR. LI: I'm not seeing anything that's likely to change radically. We have a routing architecture that is largely hierarchical. I'm not seeing any new proposals that would substantially alter that in any significant way.
MR. KAPELA: Thank you.
MR. VIXIE: Okay. The queues are closed. We are down to our last eight minutes here. I'm going to try and step through the rest in the order that you queued.
MR. SMITH: Mike Smith. I'm curious first on the Enron note, it's interesting because I'm from Washington State. And as a provider of power during that period, we are just now finishing settling all of the lawsuits in the public utility districts, so the provider is not without danger in that kind of environment. And then my question is do you think that continued emphasis on trying to extend the IPv4 pool through policies and procedures is going to invite any kind of regulatory pressure from all of these different governments that are involved in the Enron region?
MR. VIXIE: That's a lawsuit question.
MR. RYAN: Well, I'm very proud by the way to say that I represented the Western Power interest that beat Enron for a $1 billion, and I was the lawyer who did that case. So, I'm very, very proud of that. But, wish I'd had a contingency fee on it, and in which case I wouldn't be here. The -- I want to convince people here that governments will regulate existing -- using existing laws and/or will create new ones to address our industry. And that may not be bad. I must say, while the United States government could screw up a one-car funeral, its policies in the internet area have been particularly wise I think. And I don't know if the audience agrees with me. But generally, the Department of Commerce stewardship of the internet space through the white paper and the green paper and the process that was created, I think has enabled this room to exist, for example. And so government regulation is not necessarily always a bad thing. I know that there is an instinct in the internet community to be against government regulation. I think that's a good instinct. But in this area we are going to be subject to government regulation, we are under government scrutiny right now, and that ain't all bad.
MR. VIXIE: Far left.
MR. DARTE: Yeah, it seems to me that the issues of regulation and the utility versus speculative value of IP addresses et cetera -- by the way, I'm Bill Darte, ARIN AC again. It seems to me, all of those things become more and more important the longer and longer this interregnum between the two empires exist. And so it seems to me that what needs to be concurrent with any kind of market control or other mechanisms that we propose, is a series of initiatives, policies that help us drive towards the IPv6 world, and to shorten the time span that IPv4 markets need to operate as best as possible. So I'd be interested in what the panel thinks initiatives in this area ought to be.
MR. CURRAN: Someone before me, ahead.
MR. EDELMAN: I think the individual microeconomic incentives behind v6 deployment are quite troubling. You wouldn't want to be the only guy with the fax machine, and you also wouldn't want to be the only person running v6, it wouldn't get you very far. And until we can find ways to jumpstart it, to get the cycle going, we are going to face real challenges in v6 deployment. As an economist, I think its both fascinating and potentially an area where I could try to think of some clever ideas. If there were an opportunity to get a gold star on your ARIN badge, if you had registered from a v6 end-user device and connected to ARIN's registration server and acquired a record, how many people could get that gold star with less then 10 minutes of work for the next meeting? That wouldn't be a bad -- a bad attempt to try, and it might make some interesting discussion at the first break. If there is one, we might try next time.
MR. VIXIE: The man at the back.
MR. VEST: Tom Vest, consultant, I guess I count as a reg employee. Actually, I wanted to interrogate a couple of things that Ben said. Early on you said that one objection you'd heard was that the success of an IPv4 market might actually delay the adoption of v6, and you kind of -- you explained that away by saying, if we actually -- the market creates many, many more /8's that that's got to be counted as success. But I think actually that's not the way it would delay potentially, but rather by creating a kind of moral hazard, if we unencumber the v4 address space with all of the -- from all of the obligations and responsibilities and policy compliance duties and things like that that apply to the addresses now, that'll create a kind of a non-monetary value for many people that will continue to make v4 attractive relative to v6 potentially forever. I think again, the only way to avoid that is to -- another thing you said was about not overplaying -- the RIR is not overplaying their hands. So, again, the other -- the flip side of that is allowing the white market to because so gray that there is no distinction. There are also plenty of markets where there is nothing but a gray or black market, because there is no authority with -- with clear enforcement power to both establish and enforce the rules. And in order for -- it seems to me, in order for a market to achieve the good things that had been discussed briefly here -- things like maintaining WHOIS, maintaining some discipline perhaps on a routing bloat, things like that, the mechanisms for the market would have to be very -- very substantially stronger than anything that any of the RIRs command today. So, in effect, a advocacy for a white market is advocacy implicitly for a much strengthened RIR system with a lot more enforcement power. So I think again there is a lot of tension in the community between willingness -- I think actually there's quite a lot of no consensus at all between communities that would like to see it much more decentralized --
MR. VIXIE: Tom, a question please.
MR. VEST: That was it. Basically, can you reconcile these contentions when you are actually suggesting that the RIR should become -- should beef up to be able to command this kind of endorsement powers?
MR. VIXIE: Ben, just -- I guess a point of order here. We have been allocated a new block of time. Instead of eating for 90 minutes starting now, we are going to eat for 60 minutes starting about a half-an-hour from now. So the queues are reopened. If anybody has other questions please reenter the queue. We are going to hear from Ben, and then John on this question.
MR. EDELMAN: I think you're right Tom in pointing out that there is new pressure for RIRs to offer more services. Services to keep a white market white, and to assure that rules are followed, but also in the alternative view of the world where there is no white market and where transfers remain as forbidden as they are under current policy. There too, there would be pressure for a much more work from RIRs in seeing to it, that when the policy says you cannot transfer, in fact you cannot transfer. There is going to be work for RIRs to do in this interim period, either way. And so, you know, if the worry is we're going to need to hire 10 more people, I might just agree with you. Or they need to hire some more people no matter what, because there is going to be plenty of work to go round.
MR. VIXIE: John.
MR. CURRAN: I just want to comment on one item, because I've actually heard this in the halls, and you can look at this either way. There is a side effect of -- there is a market side effect with respect to motivation to move to v6 that could be created, and some people say it doesn't matter. Depending on your view of v6 and its attraction, this is either a big issue or small issue or not an issue. But here is the concern. It is true that if you change the present circumstances, the present circumstances say the free pool runs out, the RIR pools run out, and things get very exciting, if you're still using just v4. Okay. If you change that to, the free pools runs out, the RIR pools run out, and there may be an accepted manner for you get an additional v4 block at some cost, through some mechanism TBD. Well, then it's not quite the end. It becomes a lot softer. And that means anything that establishes a white continuing ongoing market, sort of implies that you can keep going with v4, just the costs increase. That's an interesting proposition to put on the table when we haven't seen a lot of traction in v6. Some people will say that's horrible, because that will remove the effort. Some folks say the reason why we haven't done v6 are very well-documented technical issues, and when those are fixed, people will move. So, it's the side effect we need to think about. And one -- there are answers to that side effects. Some people propose certain limitations, such as it's not going to be open. It's a constrained market, there is constrained buyers and sellers. But we do need to think about that, because we could be taking some amount of wind out of the sail to move to v6, (off mike). That was one aspect of what you talked about, I just wanted to comment on that.
MR. VIXIE: Owen.
MR. DELONG: Owen Delong, Juniper Networks. The question I have is in this constrained market idea, is there is some point where we could actually set the prefixed boundary that given the amount of likely unused legacy space that is out there, we would not pretty much see routers overwhelmed in a very bad way.
MR. VIXIE: I will say, I regard that as a tuning parameter, and several people in there presentations said that we would want to tune that in order to control the churn-rate and the rate of new entries in the routing table.
MR. DELONG: I've got to ask you (off mike)?
MR. CURRAN: Well, ironically, if Tony had his way and you were somehow paying for the route entry, then you don't need to tune that parameter.
MR. DELONG: That's true.
MR. CURRAN: Okay? Because you've got a matching system that absorbs pressure and gives back pressure. Mind you, you've got to have that system in place first though. In the absence of that, it's only these artificial boundaries that create any back pressure on the tables.
MR. VIXIE: Tony, did you have something to add?
MR. LI: No, John covered it perfectly.
MR. VIXIE: Ben.
MR. EDELMAN: Here is the thought experiment that I do. What if each of our legacy /8s was kind enough to give us back a /9 next month? All right. They -- each renumber in a hurry; they've been doing it all along, and November 1st they all announced it, so we've got a bunch of effective /8s that come in. Would we be all that worried about giving out that space in the usual way, extending exhaustion, to be sure, like, giving it out as /22s and /20s just as we do now. I think the answer is no one would be too worried about it. We'd have the space, we'd give it out in the usual way and that would be that. If so, a paid transfer policy that allows transfer into the same size blocks seems like it should create about the same kind of pressure in terms of new routing entries.
MR. DELONG: If I may rebut that?
MR. VIXIE: If you're clarifying your question because we answered the wrong one, yes. Otherwise go to the back of the queue.
MR. DELONG: I'll go to the back of the queue.
MR. VIXIE: Thank you.
MR. HAIM: Tony Hain, I've actually got a two part question, and it's unfortunate because it's a economic and a legal question. But -- the economic part of the question is all of the discussion to this point has been about buying and selling and doing formal transfers. There hasn't been much discussion about just leasing out a subcomponent of what you've already been allocated. Now, how does that impact the economic system, and the legal part of the question is, in a global fairness context, you know, the views are often skewed in this community. Right, because ARIN is perceived to be resource rich, and in other communities it's "unfair." So, how it is a global political system impact the legal discussion that's happened, so far.
MR. VIXIE: Ben.
SPEAKER: Not me.
MR. VIXIE: Ben, then John.
MR. EDELMAN: Okay, so as to leasing, you know, there is some economic substance behind the lease in particular, who has the residual claim to the asset at the end of the lease, if it turns out the asset is worth much more. Imagine a BMW. Get a run on BMW is everyone really wants then it's the leasers who enjoys the higher price not the leasee. So, there is some economic substance that distinguishes a lease from a purchase. Here, I guess there might be someone who wants just a one-year interest in routable space but doesn't need the economic substance behind it. Gee, you know, I haven't put much thought into how you'd architect all of that. I guess, you could have a box on the transfer form that you sent to ARIN, saying change the WHOIS for just the next 12 months and then on the following day, change it back. But that all seems a little bit goofy to me that the basic instinct I would have is, you know, we have a, we might have a paid transfer policy. It would allow paid transfers and that's that. If you want to do something else -- sorry, that's not what the policy allows, and maybe you should -- you should look into some other way to structure the transaction.
MR. VIXIE: Tony, did that answer your question?
MR. HAIM: Yeah. I think half of it. I mean -- I think your policy discussion needs to include the concept that people might be trying to do these leases whether or not policy allows it.
MR. VIXIE: John.
MR. CURRAN: I just want to -- the idea of -- we have enough problem keeping track of allocations and assignments, and the idea of adding leases to the mix presumes there is some reason why they are transitory in nature. And I guess, I don't necessarily appreciate the -- I'm not sure I appreciate the value it adds to the community for the complexity it introduces.
MR. HAIM: Yeah, one would presume that it actually is trying to provide a value to the community, you know, as opposed to be the holder of the block who is looking at next year I can get more for it.
MR. VIXIE: Brian.
MR. DICKSON: I guess that I'm not sure if it was a question or an observation or a proposal but --
SPEAKER: Who are you?
MR. DICKSON: Brian Dickson with Afilias. The idea that I had was decoupling the supply side from the demand side, by getting it through ARIN, so that bid market would be for only what would be qualified as an assignment to a recipient. And on the other side of things, somebody had a legacy block. We would only be able to return that to ARIN in exchange for whatever the current bid/ask evaluation would be that would allow ARIN to continue to allocate resources and act as a intelligent buying pool effectively for the community, and would allow -- that would effectively allow back pressure into the otherwise direct market, making it an indirect market.
MR. VIXIE: All right. I have a question for the panel that I want to address after -- do you have any responses to Brian?
MR. EDELMAN: I think it's an interesting suggestion. It's not one I've spent too much time thinking about. There certainly are some thought experiments that are provocative. If you had a legacy address holder who came to ARIN today, and said we can renumber out of a /8, and into a, you know a /20. But, we'd like you to pay us $5,000, and you try to negotiate with them and they say no, no, no, $5,000 we mean it. We know it's not very much. Send us the check and then we'll send you the /8 and we'll vacate it. I think ARIN would be pretty crazy not to do it and yet it's hard to see how you get from here to there. It is just so striking to have ARIN as the middleman in that transaction. I would suspect that most people in the room would be more comfortable with the transaction that involved money flowing from a, would be, you know, a buyer to a seller, to put it bluntly, than with ARIN serving as a holding pan in the way that you anticipate. It isn't to say that there might not be some benefits, but it seems like an even bigger change from what we've been doing, and I guess that's why I haven't spent too much time thinking about it today.
MR. DICKSON: I think the distinction is that on the recipient side, it would still be based on actual need as we've defined it as opposed to disproportionate acquisition.
MR. VIXIE: I think that all the transfer policies that have been mentioned in the possible transfer economies are still based on need for the buyer as it were would still have to qualify on the basis of need as defined by 2050. So that's not a new idea in this room. But I have a question, I guess primarily for Ben, although John has an opinion on almost everything. I'm sure he can share it. As we contemplate the idea of transfer economy for IP address right to use, are any of you thinking in terms of kind of a stable long-term market where v4 survives as an economic force, and that we somehow use the market power to cleanup the routing table, make it smaller, make the blocks bigger, make people who can somehow live with PA, live with it instead of whining for PI, like I do. And just bypass the need for v6 and live in v4, or are we all sort of looking at the v4 market as essentially a transition tool for making the transition from v4 to v6 survivable.
MR. PLZAK: Ben and John, then Tony, if you have something?
MR. EDELMAN: I think you can tell either one of those stories, and they both work as stories. You can tell a story where in fact, due to the 30-second v4 addresses is enough when folks conserve in the right way, and when we bring enough supply to the market. Then you can tell a different story of each person having multiple cell phones and refrigerators and WHOIS to say all of which need publicly routable individual addresses, in which case clearly v4 can't get us from here to there. I don't think myself gray haired enough to tell the community which one of those two is right. But I do think that the v4 transfer policy could help the community get through what would otherwise be an unnecessarily painful crunch. So, I find myself feeling good about transfers mostly because they can get us in either of those two directions according to what the community ultimately wants to do.
MR. VIXIE: Okay, what have you got to say?
MR. CURRAN: You've asked for a couple of issues, and I'm going to -- I'm going to first say, I tried to look ways out, and I'm going to play 20 years out. At a point in time when there is a, the ability to use v6 to connect to the internet, which means a lot of the internet went dual-stack or NAT-PT is running and working or something. But when we are connecting new customers to the internet with v6, the whole question of provider assigned versus provider independent comes down not to whether or not I'm connecting you to the Internet, but simply are you connecting with your own prefix, are you connecting with mine, and I may have a cost of routing your prefix. So, the ability to get unique addresses in v6, quite frankly, could be done -- someone I have enormous respect for, a decade ago, suggested that all those registries stuff should be replaced with a web form and a click box that says give me the next prefix. We can't do that in v4. But realistically, if it weren't for the routing issue, there is no reason you couldn't do that in v6, 20 years from now. Okay? If Tony actually has a system that allows providers to exchange the pressure that's caused by routing in a routing table entry market, then it's not as critical where you get your v6 prefixes from, at all. So, I see a world that's a very different world we're heading into long term, because I do believe actually the providers will figure out how to settle amongst themselves for v6 routing table entries. The real question is in the meantime, as we go from here to there, can we pull it off with v4? My assertion is no. As much as I've seen NATs and I see a whole bunch of other things, I do not believe you can keep the internet running on v4. I think the pressures that will occur for fragmentation of the v4 space are enormous and will result in routing table growth, not that nice, linear one we've been seeing, but something that resembles a much deeper slope, where instead of connecting 300 customers for one block that I got from ARIN I'm connecting two customers for the block I got from Fred, and I've got to go get another block to get the next two customers online. You could see a 10-20-30x increase in the routing table, if there is no back pressure. So I don't think you can keep v4 running, and I'm worried that a market just facilitates a circumstance where if you tried to keep v4 running via our market, you'll get deaggregation and unbelievable routing growth.
MR. VIXIE: So, Tony, you once characterized v6 as being too little, too soon. What do you think now?
MR. LI: It's even less way too soon. (Laughter)
MR. LI: So, I'm old enough to tell you that I've never seen a network technology actually get turned off with the exception of NCP, January 1st, 1983. Since then, everything just continues indefinitely. You do a credit card transaction today, and your credit card passes through an x.25 network. Now, there is no such thing as networking technology that actually gets de-deployed. So v4 is going to continue, whether we like it or not. And the market is necessary to make sure that we have a nice smooth transition to a longer term. Now, can we continue to grow the network? That becomes much more challenging. As we run through the v4 addresses, we're going to see a transition to more and more NATs. If you add enough NATs, and play enough proxy games and enough application gateways, could you continue to grow? I think you could, but it gets increasingly ugly. I don't think anyone really wants to go down that path forever. However, I don't see anyone actually turning off v4 services anytime soon. And let's see I forgot John's point, but there was something in there about making, having something managed that -- well, never mind. It is not going to go away, having a market, a market in place is a good transition mechanism to v6; it's also good for keeping things surviving. So, either way, it makes sense.
MR. VIXIE: Okay, it's 17 minutes after the hour. I'm reclosing the queues so, far left.
MR. LEIBRAND: Scott Leibrand with Internap. Back to Tony's question about leasing. Aren't we doing that today? Isn't it called swipping? I don't see a whole lot of reason why that won't continue and why providers won't charge their customers based on the amount of IP space that they're getting from their providers, and charge them on a monthly basis or bundle it as a part of the contract and to have a hidden charge for it. And I would also posit that doing it that way really reduces the demands on the routing system. So if you have the ability to transfer blocks of the size that are currently allocated, and then have ISPs assign 32s to their customers, and the customers do NAT, I never have to see all those routes in the routing table. So would -- what do you see the interactions between providers leasing or i.e. swipping space to their customers, versus providers acquiring space via transfer, versus customers acquiring space via transfer, PI space? And do you think that that will have a large bearing on the dynamics of the system? And then, in a larger sense, do we need to be seriously considering the difference between allocations, and assignments, when we're allowing our transfers? I'm not sure I completely understand it with legacy space, what's an allocation and what's an assignment, and whether the -- I mean I know AT&T has 12/8 and reassigns that to customers, but I'm not sure if every /8 is the same way. And when we transfer space, I think the ability or inability to reassign that to customers is going to be important and also has some bearing on the fee structure that we're going to charge the legacies for those blocks.
MR. VIXIE: John.
MR. CURRAN: Okay. So, talking about not markets in general but talking about legacy address space, and speaking most certainly only of my personal opinion, which might surprise some people since I'm going to say things that are probably contrary to expectation. The legacy address blocks are in some cases very well utilized by the people holding them. They're doing what they were designed to do. They're connected to network infrastructure and they're making stuff happen. In some cases they're not, or a piece of them isn't, you know. Or in some cases, 128 pieces are and 128 pieces adjacent aren't, and it's a mess, okay? But the reality is that the legacy address blocks have value because they're used to connect to infrastructure. I think that you asked a question about the reassignability in allocations versus assignments. I think that it is important to recognize that we want to set up a system, whereby a legacy address block holder, who knows they don't need part of their block or all of their block, but let's say part, for now, can somehow put that into the system, so it can be used for someone who does need it, and I'm going to say who needs it for networking, not our arbitrage. Because RFC 2050 doesn't say this is arbitrage, it says, you need it to actually put it into use for networking. There is no reason once those blocks have moved to someone who need them, for infrastructure that they should be treated any differently than any other address block holding. Okay? So, if someone's got a /16 out there that's a legacy assignment, and they find out, yeah, I don't actually need the last quarter of it. I get a /18 that I'm never going to use. And somehow this community facilitates that /18, making it to someone who is going to use it. I don't see any reason that the ISP that picks up that /18 shouldn't be able to make full use of it. What I'm arguing for is that in fact we should look at a way to do that that encourages transfers to people who need address space, but not encourages the formation of an open market, which encourages people transferring for the sole reason of market consequences. And if we can come up with a method of doing that, we put the controls on it such that these transfers from legacy people don't result in explosive fragmentation of the legacy blocks as they move across. There is a couple ways of doing that. But if we approach legacy holders, and say you obviously know you don't want to use pieces of this. We have a way that you can transfer them to someone who does, and you will be happy, and they'll be happy, and we've got enough rules that we won't destroy the routing table in the process. Why wouldn't we allow that transfer?
MR. VIXIE: Thank you, John. I want to clarify that when I heard this proposal, it was in light of after someone signs the legacy RSA agreement, then they might be able to transfer it in this way. So, if anybody is listening to John and saying, well, if that's coming, then I'm not doing, I'm not going to sign this LSA, then you're mishearing him. Do you want to clarify your question, did he answer the wrong one?
MR. LEIBRAND: I believe that he answered the right one, and I want to clarify my question to state that I agree that we should be doing what you just outlined, and I think we need to seriously consider encouraging sale to LIRs, and only transfers to end users who are PI worthy, who would qualify for PI otherwise.
MR. VIXIE: Interesting. Center.
MR. DUL: Well, Andrew Dul, Perkins Coie. My question goes along with Tony Hain's, half of the question that I don't think we really answered was about the social implications of our market, and the -- what would happen if a market was instituted in one region, but not in another, and what effect would a market have on the digital divide that exists today, or could exist, and will exist further into the future?
MR. EDELMAN: Sure, it's two separate paths there. First, what if one region allows paid transfers and another region doesn't. Well, you'd expect some rules in any RIR that does allow paid transfers, in particular, as to who is entitled to come with a showing of need. You presumably need to be within the service area. If you had someone from Asia coming saying they wanted addresses from ARIN, they'd be said -- they'd be told no-no, the correct way for you to get those addresses is it's over there. It's someone else's, not us. So it seems like the buyer in a paid transfer arrangement needs to be a buyer who is a part of the service area of an RIR, that allows the paid transfers. How about the seller? The most natural way to do it, it seems to me, is that the seller also would need to be in a service area. So you'd keep the transfers within the service area. Now, maybe you could relax that. And there might be some reasons why you'd want to. Any RIR might say, well, we're happy to take supply from anywhere. Anyone who wants to sell to our operators, they all need addresses. Any one who wants to come and help with that is welcome to. It certainly is connected to your digital divide concern though, and the obvious concern just to put it right out there, is that there are some countries where people need money more than in other countries. A dollar might be worth more in terms of how much food you can get with it, how much, you know, how much connectivity you can get, how badly you want that dollar. And it wouldn't shock me if countries where the per capita GDP is lower are the same countries where they are more willing to give up all kinds of resources in exchange for money. They get some money. They'd be able to buy new routers or big flat panels or food, pizza, whatever it is you want, you'd get it with the money. So it's not as if they're getting a truly rotten deal. Later, I guess some folks might regret having sold off their addresses, too low -- too soon, and at prices that are too low, if the prices go up higher. And on the other hand, they might be pleased to see that prices come down, and they can buy back the addresses they'd sold and make money on the deal. You know, when you start thinking about the speculative angle of it, it's all quite unseemly, because we don't like speculation, but the short of it is, if someone says they need the money more than they need the addresses, and they can find another way to run their network without those addresses, I don't see a huge problem with it personally, even through, you know, it's not, like, it's my first choice. It's not something you'd love or you'd be thrilled to tell your grandchildren about.
MR. CURRAN: I want to respond to the economist. You pointed out that if you create a market then the addresses go where the money goes and you end up with a lot of strange side effects. And there is no way to predict who ends up, but the theory is you get the economic value. I'm dead set against the market. I don't like not being able to see that outcome, because I don't think addresses are property. And I think that it's the type of thing that we want to make sure we get maximum effective utilization. The difference between our market and our transfer policy is that we can say a transfer policy moves them from some one who's got them, they're legacy, they're not using them, to someone who claims he is going to deploy them in network infrastructure. And you can do that without creating a market, and still get the legacy blocks from lying fallow into some productive use. Without creating a market, but still having a transfer policy.
MS. CLAFFY: I guess, this is a related question. I'm sorry that counsel has left, because he made a comment about U.S. policy and the internet arena which he --
SPEAKER: Who are you?
MS. CLAFFY: I'm sorry. KC Claffy from CAIDA, the Ivory Tower. (Laughter)
MS. CLAFFY: Where almost as scary stuff is going on inside there as it is out here. I find it interesting in this notion that the U.S. policies in internet space have been judged to be successful. U.S. regulatory and deregulatory policies. And if ARIN is going to use that as a premise to move forward with discussion of policy with the IP addresses, I wonder, if we can get a document that sort of outlines the metrics by which we are judging those policies to be successful, that is, say, when we deregulated the backbone in 1994, and when we deregulated the domain names in 1990 something. But the metrics by which those polices are judged to be successful and the measurements by which we say that we have achieved the success of those metrics. I think that would be useful in sort of defining what are the goals of the market solution in this phase, whichever kind of market solution you want to define, and what measurements will we use to determine that we are achieving those goals. So, I think that will be useful. I heard the counsel sort of phrase the policies, the U.S. policies, but it's not my -- it's not my experience that everybody has consensus on that. And I take Tony's point that the last time that we innovated in the network layer, that is the last time we tried to do something, like, what we're doing with IPv6, NCP 1983 the network architecture was not only under control of the U.S. Government, it was under control of the U.S. Military. So, that makes the questions of how you're going to effect such an innovation using the markets, but I'm all ears, if we had some data to support the claim.
MR. VIXIE: Thank you, kc. I want to say we're down to our last minute, and I'm going to use it. So gentlemen, I'm sorry I didn't close the queues before you got into them. So, counsel was representing its own personal view when he said that the U.S. Government policy has been remarkably successful. I think he is, it's not that he isn't representing ARIN's view, but that he is comparing it to the other parts of the U.S. government history where our government policy has been spectacularly less successful than the more or less hands off approach that was taken here. So, I recommend that KC track him down and ask him what he meant and ask him for data. I want to say it's 12:30. I want to say that when the idea of an IP address market first came up, I considered myself an expert qualified to render rapid judgment on what was good and bad, and what should be done, and I also thought the issues were very simple. In the process of sort of listening to all the different mailing lists and presentations in the process of talking to my panel, I have learned that I don't know a damn thing about this. It is amazingly complicated. There are no easy answers. I want to ask you to join me in thanking the panel, and thank you very much. (Applause) (Whereupon, at 12:31 p.m., a luncheon recess was taken.)
MR. PLZAK: Welcome back from lunch, and I think we had a very interesting morning, and we have a, definitely a very interesting afternoon ahead of us. To begin with we have two discussions or presentations on routing, and I'm going to turn the microphone over to Cathy Aronson, and she'll take it from there. Cathy?
MS. ARONSON: Hi. We have a -- I had started out trying to make this panel on -- it didn't quite workout the way I anticipated. So, I thought it would be really useful to get some folks to come in, and talk to us about what are the real scaling issues in the routing system. And what are the things that are being done to perhaps solve this -- those issues so that as we go forward, maybe you know, when we deaggregate our /8s into this /24s the whole world won't and -- and we also have a -- we have two people speaking half-an-hour each. And then we'll have a discussion and we also have some other folks in the audience who are really involved in this, this whole development process in the routing table on the RIB and FIB and everything, who will be available as well to come to the mics, and perhaps help answer the question which is really neat. S, first of all we have Jason Schiller, he is the senior Internet network engineer at Verizon Business UUNET. He has up here earlier, so, I won't go on and on, but he architects and designs the network there, so let's have Jason. He is going to talk about the problem, you know, the RIB and FIB and the routing table size and that sort of thing. Thanks.
MR. SCHILLER: Good afternoon. So, I've given similar presentations like this a number of times, and there are lot of people who have given comments, and feedbacks. The one person in particular, I want to recognize is Sven, who is a colleague of mine at Verizon Business, who's crunched all these numbers for me and help me put together the graphs, and even did so, while he was recovering from an operation last week, so I wanted to recognize him. The first point I wanted to make here is; looking back at the history of IPv6, and if we look RFC- 1887, which was back in '85 a lot of people believed hierarchy was going to solve the routing problems. And I just want to read a couple of snippets from RFC-1887. "Benefits of encoding some topological information on IPv6 addresses, to significantly reduce routing protocol overhead; the anticipated need additional levels of hierarchy in the Internet-addressing to support network growth; the recommended mapping between Internet topological entities, i.e. service providers and service subscribers; and IPv6 addressing and routing components." There's lot more text that's like, this but basically this is why people thought in the early days of v6 that ISPs would -- there would be a small number of ISPs that had all the addresses, and their customers would get addresses out of their PA space. This has led ARIN in their policy manual to have some text about IPv6 good stewardship, and about how aggregation is of the utmost importance with regard to IPv6. Unfortunately, that's not the reality we live in today. There are various factors that contribute towards routing table growth and de-aggregation; provider independence; multi-homing; traffic engineering; acquisitions and mergers; joining two networks together to have discontiguous space, and then other things that also cause the routing table to bloat that I'll go into later. Nearly all the RIRs have passed an IPv6 provider independent policy. A lot of people have said this has prevented IPv6 adoption, auto numbering is difficult even with stateless autoconfig, and we simply can't have provider lock-in. Another big factor is people want to multi-home, and they think that if they can get their own /48, and people will listen to it, then multi-homing will just work. The problem is that this sets the precedent for de-aggregation, and that de-aggregation is acceptable to soft things like provider independence in multi-homing. The way multi-homing typically works -- ere I have an example of a multi-home customer that's got a /23, that's part of a Verizon Business /12 aggregate. They advertise the /23 to both of their upstream providers, who in turn advertise the /23 to the rest of the Internet, polluting the routing table with extra routes. If they want to do traffic engineering, typically, what they'll do is, they'll slice and daze their network space. In this case the customer has decided to draw additional traffic to the UUNET circuit. So, what they've done is they have advertised a more specific /24 to UUNET, and advertised the covering /23 to both providers. Basically, what this does is the rest of the Internet that's closer to AT&T for the top half of the 23, will go towards AT&T, the rest of the Internet that's closer to Verizon Business for the top half will go through Verizon Business. But for the bottom slash, the bottom half of the /23, all the traffic will go through Verizon. As you can see this is putting yet further more routes in the routing table, and the more control they want, they more they'll slice up their prefixes. The operators basically have spoken, and they've said you know, there really isn't a good, known de- aggregation solution for multi-homing and TE, and there is only a 1000 prefixes in the routing table. We're only growing at a 100 prefixes a year, in 2 years, we'll have 1200, it's not a big deal, let's just deaggregate. My concern is, what does a long-term to commitment -- to de-aggregation really mean? And are we looking at how big the routing table might get, and if we think that vendors can keep up with that? We've seen this problem in IPv4, we've had routers meltdown because routing tables in FIBs had gotten too big, do we want to repeat that -- those problems? So, what is the impact of the routing table on the hardware? Well, it consumes state in the RIB, the Routing Information Base. It consume state in FIB, the Forwarding Information Base. It affects the forwarding rate because the FIB lookup is a function of, standing across all of the memory size and speed of the FIB, and it affects convergence; BGP path selection; rewriting the information in the RIB, and then pushing the information from the RIB down to the FIB. So, one of the things people have suggested is in order to solve this problem, let's just commit to building bigger routers, let's try and optimize RIB and FIB storage, and let's just hope that technology is always available and frankly, is five years ahead of the curve of what we need. Because what's going to happen is you want to deploy the equipment, let it -- depreciate the network of five years, and then at the end of that time do a cycle of upgrades, and rinse and repeat as necessary. So, how bad is the problem with IPv6? Well, I wanted to just give a slide to talk about how big the v6 base is? I don't think that this is really useful in determining how big the problem is, because frankly we don't route every /32 in IPv4 today, but it gives you an idea of the scale. We have 2 /32 IP addresses in the v4, 4 billion. If you look at /24s thinking that that's the smallest routable unit we have got 16 million. If you look at v6, instead and you think that the routable base is /64s, then we have 2 billion-billion /64s. It's a 137 billion times larger than the number of 24s. So, mission accomplished, we have more addresses, great. (Laughter)
MR. SCHILLER: The problem is I don't think we figured out how to deal with those addresses. So, what I'd like to do is look at how big the routing table would be today if everybody did dual stack. Now, I understand there is going to be ramp up period, but let's put that aside for a moment. Let's just assume, we wake tomorrow morning, the Internet is dual stack, and we can project how big the v6 routing table would be from the v4 routing table. We can locate the number of routes in Internet. We can look at the number of routs in the Internet, we can look at the number of intentional deaggregates, the number of active AS's and extrapolate how big the v6 table would be. And then what we can do is we can look at the current growth of these things, and project out into the future how big the routing table will be. So, the way the math basically works is you look at the v4 routing table and you break it up into aggregates, deaggregates that are from growth of assignments of non contiguous space. Customer gets a /24, two years later they have outgrown it, they get a second /24 that's non contiguous -- versus deaggregates that are for traffic engineering or otherwise intentional. They have a /22, they break it up into multiple /24s. So, if you look at the Tony Bates CIDR Report, you can see the number of prefixes in the Internet table, and how many CIDR aggregates you can aggregate it down to. If you take the difference of those two you can find out how many intentional deaggregates -- in this case about 86.4 thousand. So, if we assume everyone does dual stack tomorrow, we've got our 240K IPv4 Internet routes. We throw on top of that one IPv6 route for each autonomous system that's active in the system, that's 26K AS's, 26K v6 aggregates. You throw on top of that all of the intentional, more specifics for multi-homing assuming you do the same style multi-homing in v6 as you do in v4. And then you can add to that another 50-150K for internal more specifics for a tier one ISP for v4. And also the internal more specifics of v6 customers and you add this all up, and you get somewhere between the 443K and 623K. That's an awfully large and scary number for a lot of the equipment that's currently deployed in the Internet. There is a number of things that this extrapolation doesn't account for. The first is s single autonomous system that's advertising multiple prefixes. The assumption is if you gave them a larger aggregate they will advertise just a single aggregate. For example, you might have a single AS that has two different stub locations, one on the East coast, one on the West coast advertising to you non- continuous /24s. The assumption that I make is if I give them a single /23 they'll announce only a slash/23. But as their stub networks that are not inter-connected clearly they can't make that work. THE second thing it doesn't take into account is all of the /24s that are announced to the Internet. The assumption is if these people get a /48 or /56 they'll only make one announcement into the Internet. What's likely is that they reason why they are only making a single announcement today is because no one will accept a more specific than a 24. If you give them a 48 that might be very different. The third thing is all of the networks that hide behind NAT addresses that are using multiple NATS for traffic engineering, if they think v6 eliminates NAT they might need a different TE mechanism. Fourthly, all of the extra addresses that might occur from IPv4 fragmentation, we talked earlier about a market, we talked about breaking up legacy space, routing at a smaller aggregates, that's not in these projections, and neither is all of the new IPv6 only networks. A lot of people are talking about toasters with addresses, and cars with addresses. That's not in my growth curve at all. And lastly non Internet routes are not in the growth curve either, VPN routes for example. So here is an example of a graph of one of the data points I looked at. The line on the top with the red curve, that's basically the IPv4 Internet growth in blue, with the red projection. The curve below that is the intentional more specifics. I also graphed the number of AS's, and that appears to be linear as opposed to exponential for the Internet growth. And by adding the two of those together you can look at how big the v6 Internet would be if everyone went dual stack. Add to that to the v4 Internet, and here I have two separate curves. What I've done is basically typically tier one ISPs have between 50 and 150K internal more specific routes. The higher line is assuming that you are closer to that 150K range today; the lower line is assuming that you are closer to the 50K range. But you are going to be somewhere between these two curves considering how many routes you'd have in your total routing table. Internet v4, Internet v6, internal v4, internal v6. So here is the table of scary numbers, basically what I've looked at is how big the v4, v6 Internet would be and how big the v4, v6, routing table would be of a tier one ISP now 5, 7, 10, and 14 years out. The reason why it shows 5, 7, 10, and 14 years is, if you have a 5-year-refresh cycle that shows you how big a router has to be today for you to be able to buy it, deploy it for it to live in the network. I'm --I've also chosen 7 years because there is also some lead time in terms of certification, and deployment. So we'd like to depreciate our equipment over five years, but by the time we certify and deploy it, it's is closer to seven. So the point here is, if you are buying equipment today you want it to be big enough to live in the network for five years. That has to be a million routes, and then five years from now it's 1.9 million routes. And you know, the real question is can the vendors plan to be five years ahead for the foreseeable future? And as I referred to earlier, certification and deployment plans may push out the timeline a little bit. Also vendor timelines lengthen things because it may take them two years to react to change in the market. It might take them two years to deploy new gear, to build new gear. So the question is do we really want to embark on a routing-table growth, hardware-size escalation race for the foreseeable future. And is it possible that the growth could be so rapid that operators are going to be required to shorten their lifecycles. In fact they might start a new deployment of equipment and before they are finished have to start another new deployment. And what is the impact of scaling the routers on cost, power, and cooling? And what happens if suddenly the curve does get steeper? I mean their future growth is literally unbounded, it could become very, very steep. So some of the concerns I've had in response to this is you know, don't worry about it, vendors will build the box larger enough when it's needed. Well, I'm sorry that it just doesn't give me the warm fuzzy inside. Other people have said this problem only affects a small number of ISPs and maybe the Internet would be better without them. Well, if, you know, four or eight of the largest ISPs melt down because the routing table gets too big, those customers and their routes will go somewhere, and someone else will inherit this problem. Another thing I hear is lots of smart people are working on this for the large ISPs and they'll be affected first, and they'll solve the problem for everyone. I'm glad you guys think that highly about me. (Laughter)
MR. SCHILLER: And other people have said Moore's Law will make the problem go away -- just give it time, and the equipment will scale beyond the routing table. But we heard from Tony this morning that, you know, that might not always be the case. So, really my conclusion here is, if you look at the marketing literature for your vendors, look at how many routes they can support, and look at my 7-year projection or come up with your own 7-year projection or 5-year or whatever your lifecycle is -- I think right now the vendors are just short of where I need them to be, which is a very scary place. And the numbers that they are quoting are for v4 routing only, when you turn on v6 which takes up more space certainly it gets worse. When you turn on firewall filters, unicast RPF, certainly it gets worse. And even if they can build a box big enough it's not clear to me that they can keep pace with the growth if it suddenly changes. So, we really need to investigate architectural solutions.
MR. CURRAN: Any question?
MS. ARONSON: Go ahead, Geoff.
MR. HUSTON: Geoff Huston, APNIC. Jason one very quick question. To what extent do your numbers and your projections about those number as they relate to forwarding machinery implicitly assume we keep on doing the same kind of technologies we are doing today? In other words even though your router might already have 10 egress points, your FIB, contains 250,000 entries, each of which are earning points 1 in 10 ways. In other words to what extent are you assuming it's just what we are doing today, and to what extent is there the capability of changing the way in which we think about the relationship between routing and forwarding? How would do that impact your numbers?
MR. SCHILLER: Yeah, I think that's a very good point. What I'm looking at is the growth as it is today, and the technology as its deployed today. I've talked to some of my vendors; there certainly is the possibility of doing some FIB optimization, doing some round-path selection optimization. There might be some gains in that space -- I'm not a coder, I don't know how much room there is in that space. I get the impression from Tony Li and the others that there is not a lot of gains that we've made, a lot of them already. But I think there's your things in terms of compression, and being more efficient with the algorithms. I think what you are talking about Geoff is doing something that's actually a departure and different from what we are doing today, something that's architecturally different. And certainly we need that, and it needs to be architecturally different either in the box or it needs to be architecturally different in terms of the protocol something like a locator, ID separation perhaps. It might allow us to move the state to a different location or store in a way that is less expensive. Did I answer your question?
MR. HUSTON: Okay.
MS. ARONSON: We'll take one more and then we'll take some more after John's done.
MR. GAGLIANO: Roque Gagliano from Intel. I got a question about the traffic engineering issue. How much of the -- how many of those routes now we've seen the deaggregated for traffic engineering could we save if got the right BGP community lists. For example I was looking MCI -- I'm sorry UUNET Verizon community list, I couldn't get it, but if you got the right community and we do the right training for the people to understand. And then they can get most of the benefit of the de-aggregation just by using BGP communities are not de- aggregating. So, I think there is a lot of -- we can gain some if you do that. I don't know what in your experience --
MR. SCHILLER: Can you be a little bit more specific; I'm not sure what you mean about --
MR. GAGLIANO: But the thing is --
MR. SCHILLER: -- by using the right communities?
MR. GAGLIANO: Well, if when I'd announce those nonspecific blocs, if I announce that the community is going to like, I want transit provider A just to not to announce this community to Asia, just to Europe. The other one just to America et cetera, I can get the traffic engineering, I can get my links to be balanced without having to deaggregate.
MR. SCHILLER: Okay, I --
MR. GAGLIANO: I think there is a lot of educational issue too, and we see that de-aggregation is not the same in different part of the world, and that's also something that I think we should work on each region -- to work on why Latin American de-aggregation is four times bigger than in other regions, et cetera.
MR. SCHILLER: Okay, I think I understand the question; I'm going to repeat it just to make sure I'm on the same page as you. I think the question is why can't we use communities to link more specific routes but to limit the scope of where those more specific routes lead to? And I think the answer to that question is right now the diameter of the Internet is very shallow. Geoff has done some work on this; I think it's like 3.5. And in order to make this useful you have to link it to your upstream, and you have to link it at least one hop beyond that. So, what you end up doing is nearly leaking your route to the entire default free zone which is where the pain really is in terms of the number of routes, and the number of paths. So, I think that there is probably not a lot of benefit in that functionality, and I think the benefit is going to diminish over time as more -- as the Internet becomes more richly interconnected, I believe the AS path length will decrease.
MS. ARONSON: Okay, so now we're going to John Scudder who is a distinguished standard engineer at Juniper who works on routing protocols and standards architecture with this focus on BGP. He is going to talk about some of the solutions, and you know, what router vendors are doing to try to solve this problem. Thanks.
MR. SCUDDER: Thanks, and actually I'm going to talk about what router vendors and researchers and others are looking at. So, when I agreed to give an overview of what's the solution space for this stuff in half an hour, I hadn't quite appreciated what I was biting off. So, hopefully we'll get through this together, and I know that there is you know, a number of people in the audience that probably know more about this than me. I just ask that you to refrain from rushing the podium until you know; I have gotten through the slides. So just to try to you know, sum-up Jason's slides in one you know, pithy sense what's the problem? It's that the routing table is growing. And so what I'm going to try to do is just give a flying overview of you know, what do we know about how we might address this issue, and, you know, I've got 30 minutes, I don't know everything, so its just probably going to be incomplete, I certainly am I'm going to you know, gloss over massive and important details. But what I'm trying to do is you know, identify key characteristics that we know about. What are the tradeoffs, what are near term prospects for this stuff, you know, actually affecting the way, de-aggregation affects us and you know, please remember this is all you know, my opinion as of today. So, just as a preview, here is basically what it looks to me like the options are. There is, there -- what Jason was talking about which I sum up as you know, stay the course, do what our industry has done for you know, the last 20 yesteryears and,you know, use PIs, and do hole-punching for multi-homing, and when you need bigger hardware, go out and buy bigger hardware, I hope you can. And, oh yeah we'll work on the routing protocols too. And then there's been a lot of action around this idea of having a locator ID split. And I'm going to provide an overview of what I see that as being -- and there is sort of two man sub flavors. One is doing network-based stuff and those who are at Dino's NANOG talk know a lot more about that. And you can also do this in the host, and you know, probably many people in this room are familiar with Shim6 as one example. And then there is I will very briefly touch on some other options you know, geographic addressing as one and there is some others. Okay, so moving right along and we're talking just for a short time about you know, okay, so what we can do by just, you know, building bigger hardware? And the answer is that well, okay there are some products on the market now that support FIBs that, you know, as Jason said, almost seemed to meet his requirements. And in talking with, you know, hardware engineers at various vendors, it seems like they think that these things can expected to scale up in a manner that you know, matches or modestly exceeds that, you know, exponential curve that Jason had on his slides. Now, know well that I'm assuming, you know, it's matching that curve, not any possible future curve. You know, there are certainly disadvantage, you know, "buts" here. The -- you know one is, you know, there is a bunch of legacy hardware out there, and you know, it costs money to upgrade that. And these big FIB things are not available all across the product line where you may necessarily need them. They will be, but they are not now. And any you know, Jason has already pointed out the points about you know, you need the stuff five years ahead of time. You know, we also need to think about the control plan and Tony made this point this morning. You can probably address this by just going out and you know, similar for the FIB problem buying bigger route engines. And this is slightly less scary than the FIB have insofar as route engines basically look like commodity computers you know, that have been repackaged. We can also look at incrementally improving the routing protocols chiefly BGP, and there has been a fair amount of discussion about this recently in the IGF, and other forums. And my own gut feeling is, and this is just a gut feeling that you know, probably with sufficient effort, we can see a modest you know, sort of 2x, 3x improvement in the update rate that we have now. This no magic bullet though because if you are on an exponential curve, 2x or 3x moves you back a couple of years, but it doesn't really change any other fundamentals. And finally, a couple of words about you know, how does BGP degrade? Well, performance-wise it has kind of a nice degradation property, which is that you know convergence slows down but your network doesn't fall off a cliff. AS you know memory-wise it's not so nice, and you really need to make sure that you are -- your hardware can support the routing table that you need at all times, because if it doesn't it'll fall over. Okay so for each of these things I'm going to try and do a short evaluation of you know, kind of like what are the present context I seem them, and this is of course subjective. As I see it the pros of doing things like we do them now is well, we know how things work, and it's how they worked, and we kind of understand it. And the short- term risk is relatively low in so far as you know, going out and buying a bigger one as something that's pretty easy to understand as long as there is bigger one available to buy. You know, there is some significant cons. You don't get really anything new, you just get the same old same old that you know, you've known and loved or hated for years now. And I think an important one is you know, as Jason pointed out there is a real risk if you, you know, need hardware and it's not shipping. Because hardware doesn't turn in the dime, or hardware development doesn't. I think the biggest risk is really the one that says what if our projection is wrong. You know, what if that smooth curve that Jason presented because curve fitting routines all this give you smooth curves, has a knee in it some place. And the panels for discussing that this morning, and saying you know, gee we have a market in v4 addresses, maybe we'll see an interesting knee in the growth curve. And it's just you know, hardware is not going to save us from that. If that happens that would be really bad. Okay, so let's move on from there and talk about Locator/ID split. And this was a challenge to try to pack a -- this information into a short talk. So Locator/ID split is basically an instance of this very powerful principle, that any problem in computer science can probably be solved at another layer of interaction. And you know, we've seen a lot of very successful application of this principle in our industry. And there is also the less known piece of the code which is you get new problems with your new layer of interaction, you know, to replace the old problems that you got bored with. So what is Locator/ID split? There is a bazillion different proposal. There is no possible way for me to cover you know, even one of them in-depth much less all of them and I'll refer to representative examples as I'm going to on because you need examples. But I really want to emphasize that I'm, you know, neither pleasing nor cursing any particular thing. I'm rather trying to talk about sort of a whole class of solutions here. So we've got sort of two main subclasses of how do you do this. You can do it in the network, you know, and with you know, underlying, you know, goal number being one being leave the host alone, it's really hard to upgrade host. And we don't have the time or the, you know, the will to go out, and swap out the network layer. And then there is the sort of flip side that says actually it's possible to change host software and you know, we're really realistically at the beginning of a transition right now to a new network layer and if there was ever a time it's now, certainly now would be better than later. And just to lay down a sort of the basic principles you know, so I talk about Locator and ID. What is a Locator? What's an ID? Probably many of you've heard this before but basically the notion is that in any communication, any network communication there is really typically two things that different parties in the communication want to know about. The host really want to know what is the -- what's my identity, what's the identity of the host I'm talking to? I don't really care where he is, you know, from a host point of view you throw a packet into the Internet, and it comes out the other end and vice versa. The Internet is just a straw, it's a, you know, a series of tubes. And the tubes go where ever they go. From the network's point of view the network really -- what it wants to know is what is the location of the parties in the communication? I just wanted to know how to get the packet there I don't really care who is on the other end; this is basically the end principle at work. And if you think of this in terms of PI addresses and PA addresses; PI addresses basically look like identifiers, in so far as, you know, the people who have those addresses want to be able to you know, take their network, move it, you know, to a different provider and still have the same addresses. So it's location insensitive, where as a locator really looks like a PA address, it's an aggregateable thing, and it has very good scaling properties. So, right now the basic issue that that we have in the Internet architecture is that IP addresses are both of these things, all tangled together into one. So, if I would put in this help, hopefully I've motivated the answer which is that if you split it up you can have the routers look at the locator piece, and they don't have to care about the identifier piece and vice versa for the host. And why is this good for routers? Well, it means that the routing system then scales like a perfectly aggregateable system which you know; we know that if we could perfectly aggregate the whole Internet then you know, we wouldn't need to be having this conversation. All right, well in practical terms if we want to have a proposal to actually put this into use, we need to have a way of carrying identifiers, and locators in packets. The host want to see the identifiers, the routers want to see the locators, so how to do that? There are generally two ways of doing it, there is you know, Map-n-encap. It say you know, encapsulate the thing that has identifiers, and you know, the identifiers are really just IP addresses but you look at them architecturally, and say okay that's pretty much an identifier for my purposes. Inside another IP header that has IP addresses that you think of as locators. There is also kind of a mapping and rewrite approach which you may be a familiar with as GSE or 8+8 as an example. Or you say no instead of adding another encapsulation header what I'm going to do is take part of address and rewrite it. Semantically these are really pretty close to each other although if you allow the rewritten header to get all the way through to the host then that implies changes in the host stack. Really, the most important from my point of view, most important question to be solved, and I'll revisit this couple of times. In any of these proposals is where do the mappings come from, and how do you get them and you know, what are the details of that? The basic picture and I'll come to an example soon that shows this happening is that when a tunnel router gets a packet it needs to figure out you know, it sees the identifier and says well, what's the locator for this thing? The idea is you lookup that identifier in a mapping service, you get back a locator and then away you go. I'd love to tell you exactly what a mapping service is, how it works, how it scales but I can't, because we don't really know yet. There's a lot of proposals, lot of active work in this area, and we really don't have what I would call a solid understanding of, you know, what the gashes in the scaling aspects are. And unfortunately this is really crucially important I think to the long-term success of any such proposal. So, here is an example and it's you know, highly simplified and cartoony example compared to the ones for example in Dino's talk the other day. But hopefully it'll serve to you know, at least make concrete some of the things that I've talked about so far. So, in my example, I've got two sides and they re both playing the "map-n-encap" game. And so that means that the sites within themselves are addressed with a, you know, some kind of provider independent address which is not routed in the clouds in the middle. The clouds in the middle don't have the, you know, 1.2.3 or 4.5.6.nets in their routing tables. The sides have also have an external address which is just taken from the PA block of their respective provider, and you know, so it has all the nice good aggregation properties. So, what happens when the host in left wants to send a packet to the host in the right? And first it does a DNS lookup for the host on the right, I haven't shown it, gets back, you know, the address. I want to talk to foo.example.com, so okay I'm going to send packets to 22.214.171.124. And so it makes up a packet, and puts out stuff in headers. So far this is exactly 100 percent what happens today. And then it takes that packet, and sends it though a site and it get to the border router website. And by the way this border router, it could be within the site, it could live as the provider edge router. It could be elsewhere, there is, you know, a lot of variance possible on this but for -- in my examples; I'm just going to stick with having it via the site border. So, this is really when the magic happens. And the site border router says oh, look I want to send I've got a packet, I need to deliver it to this destination identifier, I of course don't have a route for you know, that identifier in my routing table because it's not routed. I'm going to go and talk to the mapping service, and find out what the mapping service can tell me about where that thing is located. The mapping service comes back with a locator, it says oh, yeah, 10.42.0.1 is where you want to send that so the border router tacks on another header, encapsulates it into a tunnel essentially with that destination locator as the destination address. Send it through the Internet where it's routed exactly as it is today, and it arrives at the egress. The egress guy looks at it and says, wait this is my address; I must be supposed to decapsulate this, stips off the outer header, looks at the inner header. Says oh, 126.96.36.199 that's local to me, I can deliver it, does so. So the really nice thing to absorb here is that the two end point host didn't have to do anything else anything special at all. They just work like they worked today, you know, you could you know, take your PC, and put it behind one of these sites, and it ought to work. Also all the stuff in the middle didn't have to change. It's only the little bits in the edge that had to you know, have this special sauce. So do another couple of examples now and these should go quicker. And so you know, how you asked does this give us provider independence because you know, Jason talked a little bit about how, you know, provider independence and multi- homing are really are all of what's --what are the drivers so we need to be able to support these equipments. Well the only thing that's different in this diagram versus the previous one is that the egress router on the right has a different provider assigned address everything else stayed exactly the same. And therefore when the guy in the left wants to send a packet to the guy in the right even though the site on the right has moved it all goes exactly the same expect that the mapping service returns a different map entry. And it all works the same otherwise. And the point to note there is that you know, the guy in the right at least in concept went and changed you know, one address and one device, and updated the map and that was it. And finally how does this work with multi-homing? Hopefully I'm getting the idea across by this point work the same again; expect the map returns -- two different choices. The guy in the left somehow chooses one of them, there is various different ways for how the map might provide hints for which one want to choose and the packet is again delivered just as it is today. Okay great, so there is a couple of things that work kind of differently in this world order even though you know, it provides the allusion of everything working the same to the host and to the core. Things aren't really working quite the same. One thing that's different is traffic engineering ends up working kind of different. The destination site gets you know, all though through different mechanisms gets about the same capabilities that it has now, you know, with BGP-based multi-homing and TE, which is that it can express oh, you know, please reach me this way unless you know, this is my primary connection, this is my back up or it can say please loadshare, it can express those kinds of semantics. So the destination more or less neither wins nor looses although it gets kind of nicer ways to express its policy. The source site actually gains more capabilities in that -- since it has visibility into all the -- the connections provided by the destination site, it can, if it chooses override the destination site policy, you know, I don't really express an opinion, whether that's good or bad as just you know, how it is. The ISP kind of loses out as far as I can tell in that -- they, you know, since the actual destination site, you know, which is not currently visible on the routing, is hit, and it appears as, you know, either the source chooses one or the other provider assigned address. The ISP network doesn't have -- kind of as much power to do it own traffic engineering, and you know, if people want to understand this better, they should go ask Jason, because he understands it better than me. Okay, the second thing that's really quite different between, you know, the current model and this model is, how fairly detection happens. And it's basically a question of control-driven versus data-driven. Today, if a multi-home site loses a connection, that fact gets precluded out through the -- through a BGP withdrawal, and eventually nobody sends traffic that way because they don't have a route. On the other hand in the locator ID world, where your -- line of mapping, there is no failure signaling in the control plane, or that's idea, because you want to cut down on the rate piece of the -- rate time state equation. So, this is important for scaling. Well, what this means is that you know, if a multi-homing attachment is lost, then the people talking to that multi-homed network will, you know, they send a packet and eventually they'll get back, you know, some indication that the packet wasn't delivered -- maybe an ICMP unreachable and then they have to adapt. So, control-driven versus data-driven, what does this mean? Not entirely sure. So, I prefer to hold questions for the end, but, if you have a -- if you have like -- if I read a factual error, please correct me now.
MR. FARINACCI: Well, I wanted to make two corrections. Locator addresses are available to ISP. So, they do know where the sites are. Dino at Cisco, sorry. So ISPs do have those -- visibility of the sites, they don't have visibility of the EIDs, but they have the visibility of the locators for the sites. So that's one point.
MR. SCUDDER: I agree with that, but I think that the point that I've made, kind of have stands and if you want debate it further, we should probably do it at the end. So -- and your second clarification?
MR. FARINACCI: Second clarification is -- you don't rely on ICMP unreachables for locator reachability. The data -- there is data plane in band signaling of the locator reachability. So, as long as packets return from the other side, you know which locators are up or down.
MR. SCUDDER: Okay and so yeah, it's ICMP or you know, some other data-driven form. I guess the real point I wanted to make, and I promised you, I'd get details wrong. So, I wouldn't want to disappoint. The real point is that it's -- in one case it's control-driven, and one case is data-driven. I think we can probably agree on that? Okay, so our next point of disagreement will be how does mapping work? So, basically, you just got two traces, you can, you know, the ingress router can go and fetch mapping information from some remote database, you know, on-demand or it can have it all three loaded. One is called pull and one is called push. In the pull case, you know, since you're fetching it from a remote thing, and only need to really keep in cache the stuff that you are actually using. You have much less state on the ingress router, this is good. On the other hand, you inevitably have latency in -- when you go and fetch that information. Maybe not so good, you know, turning into some kind of performance impact seen by the end-user of the servers. In the push model, you go and pre-populate everything that's you know, means that you can afford everything as you get the packet. But on the other hand, the mapping database that you are pre-populating is almost certain to be, you know, in the sort of end state for this thing was fully deployed is almost certain to be larger than the current routing table -- probably much larger. So, in terms of this helping as with scaling, which is what I am talking about after all, it's really not clear at all that that would be the right thing to do. And you know, people are working on hybrid approaches, you know, notably that I'm aware of LISP Cons, which is kind of trying to do, you know, get the best of both worlds. So -- and here's the thing that now worries me the most is kind of how do we get from here to there? And this going to be, you know, a very simple cartoon just to illustrate that this is actually kind of hard. On the left side, you know, we've got now instead of being a thing that's doing some "map-n-encap," it's just a plain old Internet site. On the right side, we've got something that's playing the new game. And so remember that means that 188.8.131.52 is not injected into the global routing table, because we are trying to make the global routing table scale. So we've entered the left, does a DNS look up, gets back to destination address, makes up a packet to send just like in the previous examples. It arrives at the border router, just like in the previous examples, but now because this is a plane old Internet site, it doesn't know about this mapping game. It has no idea that it's supposed to go and look up and locator during encapsulation. So, what does it do with this packet? Well, it has nothing in the routing table, communication doesn't work. This is a problem that has to be solved if we're to actually get from here to there. And I think there is some good idea starting to float around about how to do it, but I think that they haven't been tested, haven't been worked out very well, and really, we need a lot more work in this area. So, here's my subjective of evaluation of where we stand. There is one really good pro on these kinds of approaches, which is that co-routing scales very, very valid. You know, it sort of asymptotical approach is perfect. That's really good news for people that are worried about scaling their co-routers. And there's some other good news. You know, you could enable the use of -- increased use of multi-homing, we like people to use our services more -- it makes traffic engineering more transparent. And interestingly, if we actually had the stuff deployed, we would be able to get much denser utilization out of the address space, because you don't have to worry so much about aligning your identifiers on topological boundaries as you currently deal with your IP address blocks. And that if we had it deployed today, it could push out v4 depletion. The deploy today, is the problem part with that. There is of course, a list of cons, and I'd like to point out that most of these cons, probably exist because of you know, my second last bullet, which is to say, this is still research. So you know, in a sense it's probably unfair to be picking on research, you know, in comparison to fielded technology. But so be it. Right now, the concerns are that -- well, depending on what flavor of mapping we pick, there are concerns about scaling, there are other concerns about performance. There is also other concerns about performance like, you know, do we really have big (off mike) all over the Internet? Is data-driven fairly detection, really going to work? Stuff like that -- I don't think we have a good handle on the security model yet, because you know, if you change your Internet model, you're going to introduce some interesting new attack vectors, I don't think we understand the mapping service very well yet. I talked a little bit about providers losing some TE capabilities. And finally, I talked about being concerned about the transition plan and Dino wants to make another point. Dino?
MR. FARINACCI: Dino at Cisco. Just one comment on providers lose TE capabilities. They certainly do and they also lose the disadvantage of polluting everybody else's routing table. So -- but they do gain -- they do have TE capabilities at the expense of no one. Okay, so let's be clear on that?
MR. SCUDDER: Right. So -- yeah, we are talking about trade-offs here and finding out there is no free lunch, it actually, you know, we had to pay for our free lunch today even. Okay, so my time is running short, so I'm going to try to really fly through the rest of this. A lot of the stuff in the host-based based locator idea is really very similar to what I presented previously. It's just that instead of trying to have the special sauce inside the router, you push it all the way back into the host stack, and from that point of view, you could even imagine, you know, enlist by whatever implementation that leaved all the way back in the host and it would look about like the same thing as this. So, to some extent this is an arbitrary distinction, but there's -- there's really one important difference, I think between the two, and that is that -- if you push it up all the way back into the host, there is potentially more scope for doing an incremental transition in that the host, you know, is now the thing that's in control of trying to send a packet to the other end. If the other end doesn't respond, then the host can say, oh, you must not understand my, you know, new cute locator ID thing. I'm just going to fall back to regular IP communication, although I'm going to lose some of my new capabilities by doing so. For example multi-homing isn't going to work as great as it was supposed to. So, you know, pros and cons layout kind of similar. I think the one potential additional pro is, I see there being a little more of a possible incremental transition plan, but this fact that the -- and it seems like a economical example by the way of this, the fact that you only get, you know, the benefits of multi-homing, for example, if the hosts on both ends understand the trick, really raises the question of, you know, are you ever going to be, you know, do the motivations really exist to get people to shift over to this new world order? And finally just to hit some other ideas, there is this -- you know, the notion of geographical addressing has been around, you know, approximately forever. You know, I started in this industry in 1990 and I think it was around then that I first heard about it or not much after. And the ideas that multiple providers and the geography decide, okay, we are all going out into the same aggregate block and we will exchange more specifics at a metricExchange. There have been, like a said a ton of proposals, and they never seem to go anywhere and I think we needed to ask ourselves if there is a reason for that. As far as I can tell, the pros and cons layout like this the pros are, if everybody did geographical addressing, you know, somehow you, you know, push the reset button on the Internet and renumbered everything then we would have, you know, just come asymptotically close to perfect aggregation, and that would be nice, although we can't really do it. And also very nicely, this is a deployment only thing. You don't have to worry about -- you don't have to upgrade your router, you don't have to upgrade your host, you don't have to upgrade anything except you have to upgrade your entire network architecture. And also finally, you can do this in a complimentary fashion with other solutions and you can, you know, you have all the transition you want, you know, for all I know somebody somewhere in the world is doing this right now. It is strictly a thing done by consenting adults within their own metro areas, they are consequence. And probably, the -- you know, the biggest one is that it merely requires you to re-spin your entire business model and your network architecture and tier in every metro therein, with everyone. Also traffic engineering really doesn't work so great because, you know, to get all this scaling goodness, you are not going to leak your more specifics outside of the metro area. Well, right now, traffic engineering basically works by leaking more specifics. And it's not attractive for customers to spin multiple geographies, so when you add all that up, it kind of looks like it works best for the customers that didn't need PI addresses anyway. So, it probably doesn't solve the right piece of the problem and I see Tony going to the microphone because I've gored his ox now, so I believe --
MR. HAIN: Just on that very last point.
MR. SCUDDER: Okay, and your name is?
MR. HAIN: Yeah, Tony Hain. It depends on your context of what "need PI" means and if the definition is need a slot in the global default-free zone then I would agree, but if your definition is, I need to be independent of my providers within my region, I'm a small business and I still need to independent then that's a different definition. So, I would just quibble with the wording of the last bullet, everything else you said was fine.
MR. SCUDDER: Okay. Yeah, I was kind of going with the former definition and I will reemphasize the third bullet on here which is that you can do this and still think about doing other things as well. And finally just to kind of, you know, clean the floor of any other things. There is a lot of other stuff floating around. Everything else that I am aware of has the characteristic that it's really cool but not incrementally deployable, which is far as I can tell in today's -- you know, in the real world means that it's DOA, although I love to hear about something that is incrementally deployable and really cool. And finally, we have sort of the, you know, where we started out with, you know, policy regarding IPv6, which was to say, no, no, we are not going to have PI because it's pollution, it's bad and just can't do it. And that -- if we could actually hold the line on that then we would have perfect aggregation and again, no worries, but there is one little conference, which is that as far as I can tell, it's unacceptable to, you know, your customers, and that also seems to make it DOA. So, trying to sum up this long wrangling talk -- it kind of seems like there is two things on the table and actually they're not competitives (sic), they're both necessary. One is that we really need to continue to scale up hardware, scale up protocols because we have a network to run, and you know, it needs to be run this year, next year or the year after that, and so on. And the locator ID stuff well, it's -- really looks kind of cool, my own personal guess and you know, people may differ, but my own guess is that if, you know, somebody handed me and everyone else here stone tablets with, you know, holy writ on them that said exactly, you know, what the protocols were and all the bugs had already been worked out. It would take something like, you know, five years of implementation, qualification, deployment, to really get good coverage throughout the Internet. Since I'm not aware of any, you know, holy specs and stone tablets being available it probably would be longer than that, and it's my gut feeling. And you know, there are key issues still unsolved here, so you know, the -- I think that one has to say the jury is still out about, you know, how well it's going to work in the end. And there are some other approaches I touched on, but they seem to require unacceptable tradeoffs. So just in closing, I'd say it looks like the current architecture is going to be with us for a while, like it or not, and this really has a policy implication which is that, you know, where you -- and I think the, you know, panelists this morning touched on it. It's been touched on at various times that we really need to have continued management of router table growth. There is -- you know, we can't rely on just saying, oh, you know, just build bigger routers, whatever. That works as long as we have a nice smooth curve and we have a nice smooth curve now because there have been policies in place that exert certain kinds of back pressure and there is economic back pressures also on table growth, you know, take that away and you could see a kneel like that and unfortunately router vendors are not in the business of actually delivering magic. The locator ID stuff is really promising and I really encourage people to take a good look at it and engage in the -- the routing research group and just to repeat this is all sort of my humble opinion as of, you know, 2:30 today. And I'm sure I've missed things and thank you very much for your time and forbearance, and I think we can take questions now.
MS. ARONSON: Now, go ahead Thomas.
MR. NARTEN: This is Thomas Narten from IBM. I just one quick -- one question John. At the beginning you sort of -- you -- where you outlined the risk, the one that you mentioned was, if there this is sharp uptick in the rate of growth of the router tables and the question I have for you is, would you care to elaborate a little more on what you define by -- what do you mean by sharp and how do you see things playing out at the v4 conventional free pool exhaust?
MR. SCUDDER: As for what I define as sharp, I don't really want to quantify that. What I mean to say is that, you know, it's kind of what I laid out earlier is being that, you know, kind of the state of the art is about a million right now. In talking with hardware engineers it looks to me like, you know, what I'm hearing is that 10 million is achievable within a few years, if we you know, start exceeding that envelope or we, you know, do that for too many hardware generations, then that's what sharp would mean and I can't really get any more specific than that. As for the second part of your question, you know, what do I foresee from, you know, the endgame playing out, I think that the panel this morning, you know, was a lot more, erudite and coherent than I could be on that and basically what they said as far as I could sum up is maybe the router tables could grow really fast or maybe not.
MR. NARTEN: Well, I guess, maybe I -- you've -- I've already heard your answer, because your theme here seems to be, you know, stay the course, things are -- we shouldn't worry too much. Now --
MR. SCUDDER: No, that wasn't my -- that wasn't what I meant to communicate so I'm sorry if I did. What I meant to communicate is we -- I don't think we have any other choice in the near-term other than to build bigger routers and deploy them, because it actually takes time to complete research, do fieldable implementations, qualify them and field them. So I don't think it's an either-or choice.
MR. NARTEN: Okay.
MS. ARONSON: Now, we're going to go head with Dino and -- Dino and then we're going to have to stop.
MR. FARINACCI: Dino at Cisco. With respect to your comments on, we can just throw hardware at the problem, which I think is true to a certain extent, but I want everybody to keep in mind that where you put a box where you need high speed interfaces, density, system bandwidth you probably need large routing tables. There are places where you don't need the system performance and it's not clear that the chips that are going to be built in those line cards and those systems that provide less density and less high speed interconnects and stuff. We will need to have larger routing tables, but they forced to if we deaggregate. So as we go out towards the edges, if the DFZ zone is still there and those lower powered chips don't have large routing tables are large capacity, we're going to have a problem.
MR. SCHILLER: Yeah, furthermore, there is an economic piece as well. If you need to by bigger routers because you need more ports or you need more bandwidth, that's kind of a problem that you'd like to have because that means you have more customers or your current set of customers is pushing more traffic which means you're generating more revenue. If you just need to upgrade devices because you need more memory for the routing table, that doesn't necessarily generate revenue because it might be an existing customer that's just deaggregating more or it might be one of your peer's customers that's deaggregating.
MR. SCUDDER: Yeah, absolutely and just to reiterate, you know, vendors like to build families of products at different price points and if this family of products has to have a million table route entries across it the price point's going to be pretty much the same.
MR. CURRAN: I actually, have a remote participant question and it's for Jason who gave his presentation earlier. You're up here Jason somewhere. Okay, good. Vince Fuller asks, "Since you started tracking these numbers of potential routing entries has this changed over the last year? In other words, from a year ago versus now, is the answers you're getting in terms of total routing table size significantly changed?"
MR. SCHILLER: Sir, I've been looking at this for about a year and a half. In the early part of this year, it did decline a little bit, but seems like we're back on the original growth curve that we were prior to that decline, so there was one little artifact where growth dropped off and that was the sample that we did in last March, but that seems to have corrected itself.
MR. CURRAN: Okay, thank you. That's it.
MS. ARONSON: Thanks. (Applause)
MR. PLZAK: Okay, we are onto the first policy discussion this afternoon 2007-16 IPv4, Soft Landing. It was introduced in the 11th of May of this year, designated a formal proposal on the 28th of August. The reason for delay is that the AC and the author worked together for a while. This is the first discussion of the proposal, in a meeting I should say, and it has not been revised since it was formally introduced. The proposal text meeting packet at URL (off mike) to provide for a defined transition away from IPv4 address space towards IPv6 address space by imposing increasingly stricter requirements on new address allocations. The shepherds are Bill Darte and Paul Andersen. PPML discussion, since it was a formal proposal, 24 votes by 10 people, four, for, one against. You see some comments there, but prior to this being a formal proposal. There are about 21 votes by 12 people with three in favor and one against. This was being measured from about the 1st of July this year. The Counsel sees no liability risk as of October of this year. Some staff comments, policy is to apply only to the general IPv4 ISP policy. Does this policy also apply to other ISP additional policies like multiple discreet networks and cable? Does this policy supersede the ISP additional request policy and on any ISP additional request policies, if so, this should be clearly stated. In the policy statement the author discusses utilization rates and refers to SWIP and RWHOIS. These terms should be removed because they are not necessarily relevant to all customers. Those are the signs smaller than /28s or orbits that manage dynamic address pools, Voice over IP and so forth. In the policy statement the author refers to specific fields in the template, this should be removed since those template fields would changed over time and a general question of fairness comes up when you consider that ISPs will now be faced with too much, with much more difficulty in their panning IP address space from ARIN while end users will feel no effect or change at all. Phases 0 through 3 no comments on that and the NRPM changes are as shown here. From an implementation assessment, probably take us about three to six months to do this effort. The board of trustees would ratify it. Implementation requirements, significant staff training, some template changes, we need some new registration services tools built and we need to do some guidelines changes and this would also difficultly increase our processing time, so our turnaround time would increase. And so now, I like to call David Conrad the author of the proposal to please come forward. David? (Discussion off the record)
MR. CONRAD: So I'm not going to be giving a PowerPoint presentation. I will be giving a keynote presentation. So as I just about go through this quickly because there has been a lot of discussion on this and I don't want to waste much time so that the other proposals can be gone into. I am David Conrad. I am not affiliated with anyone for the purpose of this presentation, that's my mail address. (Discussion off the record)
MR. CONRAD: So a very quick quiz. You're driving towards an invisible brick wall at 60 miles an hour, what do you do, what do you do? A, accelerate, it will encourage brick wall removal. (Laughter)
MR. CONRAD: B, set cruise control and close your eyes, well, it will hit the wall at once. C, slow down, maybe figure out if we should be getting out of the car at some point. Soft landing is an attempt to actually look at getting out of the car. Yeah, this stuff you all know about, two to five years left of IPv4 depending on your point of view and which data you look at. It will probably take longer to get significant deployment of v6. The idea behind Soft Landing is that maybe we should actually look at slowing down somehow and firmly encouraging transition. A summary of the proposal, I put it together in this table, I send out an e-mail a long time ago, didn't really get any comments on it. I noticed there were a couple of boo-boos on it -- oops, this one actually I hoped it's more accurate. I don't know, I can't read what I write myself. So I won't go into these in any detail. I added colors for people who happened to not have -- to be color challenged, but in essence the basic idea behind this proposal is to try to create some road bumps in the road so that people will take running out of IPv4 space a little more seriously than they have in the past. The goal is not to impose unreasonable restrictions on any ISP to disallow them from being able to get IP address space before there is actual run out. The idea is to try to encourage people to take a greater look at their infrastructure, a greater look at the transition plans necessary to get people to migrate. The mechanism I thought that would be best to actually do that would actually be to increase the efficiency requirements that are documented right there. And also actually require people to provide additional documentation about what they actually plan to do in dealing with the future. The only caveat on that is when we get below 10/8's. I actually put in the requirement that if you want IPv4 address space you need to made IPv6 address space available. Some of the concerns that I see in e-mail, these aren't all of them. These are the ones that I actually, had answers to because the other ones I -- doesn't have answers to, so "anything that prolongs v4 delays v6." My response to that is that yeah, that maybe true because we all know human nature tends to differ studying for a test to the night before the test; however, in the environment that we're actually working in which is a global environment that has a lot of people who we perhaps don't want paying attention to the things we do. Not doing anything is a politically dangerous move. It will encourage and insight people to help us whether we want it or not. I did get the complaint that their proposal is too complicated, yet I know it is somewhat complicated -- it's hard for me to get in my head, but it is sort of -- I actually simplified it a lot from the original version. The comment was that it isn't fair because it only applies to ARIN. I mentioned an e-mail, my intent is that to actually, propose something essentially similar to this than all the other RIRs. I did not want to do this as a global policy because I actually believe there should -- there can and it is appropriate for there to be variations in the other regions. "It isn't fair ISPs versus end users." My response to that was, well, ISPs consume the vast amount of address space. I am happy to create a separate one for end users that is basically along the same lines, but you know, going for the 90 percent, 10 percent rule and that one of the complaints was that the thresholds are arbitrary. That is true. My intent was to actually, take the current consumption patterns and aim for about 18 months between thresholds. Of course, that will vary depending -- you know, if this actually works the way it is supposed to, then the time between thresholds will actually extend because consumption is being reduced. Well, they're not, that actually occurs is anyone's guess. Response to the ARIN Staff Assessment comments -- does this policy apply to the other additional policies, 4.5 which is the multiple site? I believe, yes, it does. NPRM 4.2.6, which is the cable. The second bullet specifically which describes the elucidation, yes, it applies to that. Again, the point is to try to encourage people to take this stuff seriously by making them take notice basically by kicking upside the head and say, hey, things are changing. You need to actually something about it, and that should apply -- I believe, that should apply across the entire spectrum of address space consumers for ISPs and arguably end users. Question 2 actually, confused me a bit because it seemed to reiterate question 1, so I just said yes. SWIP and RWHOIS, yeah, okay, I will remove those. The only reason I put them in there was because they were in the existing NPRM template fields. Yeah, fine, whatever. And ISP versus end user fairness, I already talked about that. Yeah, I will address that if people feel there is a need for it. So, conclusions -- having a longer runway can really help prevent the "oopsies", you know, increasing the efficiency should lengthen the runway. It should allow for more time for transition. One of the goals of this policy of proposal is to try to break the chicken and egg, you know, the end users don't want v6, ISPs don't want to do something the end users aren't going to pay for. This is an attempt to actually say, well, so there is this other community you have to worry about ISPs and that is actually yourselves and you know, hopefully it could slowdown some of the government help in the particular area of address space management. So, I guess I'm open for questions.
MR. CURRAN: Microphones are open. (Laughter)
MR. CONRAD: Marla, do I present? Okay, I can direct. Marla?
MS. AZINGER: Marla Azinger, Frontier Communications. I don't support it as written. Let me tell you why. I appreciate the spirit of the proposal completely and the hard work that you've been putting into it, I think it's awesome. But what I -- oh, and one of the other things that I like that you have in here, is requiring v6 deployment plans but I would say everybody should be providing that, not just if I have the current revision, it just says "end users," I believe in there, not for everybody.
MR. CONRAD: It's actually anyone -- any ISP that requests address space.
MS. AZINGER: Okay.
MR. CONRAD: The intent is -- my intent was that it should apply across the board.
MS. AZINGER: It should be across the board.
MR. CONRAD: It should be across the board, yeah.
MS. AZINGER: Okay, okay. That's the point that I'm trying to get.
MR. CONRAD: If that's not clear, I can clarify it.
MS. AZINGER: Each phase that you put includes a 100 percent utilization of all previous IP4 allocations, and a 100 percent utilization of all addresses is not realistic, since some will be sitting in pools that fluctuate. Also, some will be geographically assigned and while they may not be a 100 percent on the day of the new request, they may be used up in just 6 months later down the road. Also, you have into account that old addresses get recycled. So if you're doing your job right -- yeah, you see where I'm going? So a 100 percent, I don't think I'd ever get because I recycle my addresses.
MR. CONRAD: I understand that completely, and in fact in my original version, actually had utilization lower than a 100 percent. However, I was told by ARIN's staff that the existing requirement is a 100 percent for previously allocated blocks and that -- that person right there is the one who told me. So, if you have an issue with that --
MS. AZINGER: Okay, well, I'm already -- yeah, well, I hate to say it, but the facts are that it doesn't quite come out that way.
MR. CONRAD: Right.
MS. AZINGER: So if it says that, I'm sorry, there is a gap.
MR. CONRAD: Right. So actually one of the suggestions that I got and Alain actually made this suggestion, is that I revise the proposal so that it's -- it says essentially what the NPRM says now. Instead of making it explicit at a 100 percent just say whatever the NPRM says as it exists now. That doesn't actually address your concern, but I think it would remove that as a objection from this proposal.
MS. AZINGER: And I guess ARIN staff, they can -- because I have to come back for addresses and they go through my stuff like crazy. I do not get of easy by any means, so I just -- I think it's very important that people understand that a 100 percent of -- because you recycle.
MR. CONRAD: Right, I understand.
MS. AZINGER: At least I recycle. I hope you're all recycling. The other thing is, if you consider that ISPs will not be phased, and the ARIN staff actual assessment address (off mike), we need to consider that ISPs will now be faced with much more difficulty in obtaining IP address space from ARIN while end users will feel an effect on the change of dollar, plus if this only happening here in the ARIN region, then that puts us behind, possibly at a disadvantage, compared to other regions. So those are my concerns.
MR. CONRAD: Right. I had mentioned within the presentation, in the case of the other RIRs, I'm going to propose something and obviously, you know, if this proposal were to pass and -- yeah, and later on the other RIRs don't pass something essentially similar, ARIN can just revoke it.
MS. AZINGER: Well, why wouldn't you just say implementation is dependent on other RIRs passing it?
MR. CONRAD: Because that would -- that could result in a significant delay in implementation. That's the same problem --
MS. AZINGER: But it also would be a delay in us -- if we start doing and others don't, it already puts our efforts for it at a disadvantage.
MR. CONRAD: Well that gets into sort of the -- one of the concerns that people have expressed with regards to global policy implementation. The reality is that -- yeah, if this were to pass here, the likelihood that say, AFRINIC, would be coming back for address space, in-between the time when this would pass here and something similar would pass in AFRINIC, could be sufficient that it, you know, there would be no significant impact on the consumption within the ARIN region, all right? Yeah, I'm happy to take that as input --
MS. AZINGER: Okay.
MR. CONRAD: -- and with regards to the end user versus ISP then, as I said I'm happy to do similar a proposal on the context of end users as well.
MS. AZINGER: Thank you, sure.
MR. CONRAD: Thank you. Mr. Bush?
MR. BUSH: The last Mr. Bush died in 1976. Randy Bush, IIJ. In the last couple of months, I've actually kind of started to understand why this and the proposal Roque will speak to might be reasonable. So I've a question -- is, could you speak to the compatibility of the two proposals?
MR. CONRAD: That would -- well, with the -- the --
MR. BUSH: We haven't got a short term for it. Let's call it the --
MR. CONRAD: -- the countdown proposal.
MR. BUSH: -- let's call it the -- oh, okay, good. We have a short term for it --
MR. CONRAD: Right.
MR. BUSH: -- the countdown proposal, which is gaining some momentum --
MR. CONRAD: Uh-huh.
MR. BUSH: --- and I don't see a direct conflict between them and in fact I see them working well together and I'm wondering if you also see that?
MR. CONRAD: Yeah, I -- the only potential impact would be that I might need to juggle around the thresholds a bit because of the sort of reservation of one or two times five /8s for the RIRs, depending on whether or not that -- those global proposals pass. I'd be happy to include something in -- some sort of language like that in there.
MR. BUSH: If you or Izumi San happened to be in the same room some time? (Laughter)
MR. CONRAD: That never happens. (Laughter)
MR. BUSH: Definitely not.
MR. CURRAN: Randy? Are you for or against the proposal?
MR. BUSH: Pardon?
MR. CURRAN: Are you for or against the proposal?
MR. BUSH: Well, watch out, I have a conflict of interest. I am the co-chair of the APNIC policy SIG. So, let me explicitly take that hat off. I -- and that's the equivalent of I don't know what here. The -- did make sense. I'll help -- in my role with that hat on, I'll actually help Roque explain what happened in APNIC, but essentially there's momentum there for the countdown proposal. I had one /8 per RIR. I know it's against (off mike) but some prudent planning, you know, we could try it, what the hell. And I think there are people actually working on v6 deployment and the other vendors actually slowly trying to get to v6 and, you know, it's hard to motivate management. I don't think these things will cause any further delay than we've got already, but will allow the people who have to deploy, a window to let the cost go down a little.
MR. BUSH: It's -- to be honest I believe v6 should be deployed along with everybody else, but I do have to honestly ask when somebody who's a little resource shy, and of course, that's a very few people these days, we're all awash in money, you know, the costs of moving will go down. So, this lets people give us some more -- little breathing room. And prudence, what the hell, we should try it for once in a while. Thank you.
MR. CURRAN: A very long yes, but I got it. (Laughter)
MR. CURRAN: Ed?
MR. LEWIS: Ed Lewis, NeuStar. Once I figured that this had nothing to do with IANA, I liked it again. (Laughter)
MR. LEWIS: Actually, it's the same comment that Randy was just making too. I just realized that this policy and the two that are following this are not in conflict, they can be done independently of each other. I also do like the fact that this could be only in the ARIN region and if it makes it different here from other regions, I'm not so concerned about that, when I'm in the ARIN meeting. But I think it's a good policy for ARIN to follow. It shows that we're seeing v6 coming, we're making aware -- people aware of this, and I think we should go ahead and do this here regardless of what happens at IANA's policy of getting things to the RIRs or what other regions think about the same policy. So, yeah, I'm for it.
MR. CONRAD: Mr. McFadden? (Laughter)
MR. McFADDEN: Mark McFadden, BT Americas. First of all, I want to say that I agree with Marla about the comments about how this gets implemented globally and I think that there is a sort of a fairness issue -- a fairness equity issue that has to be addressed there. And I don't think it's as simple as washing away and saying, well, let's adopt it here and then if the other ones don't do it, well, we'll reject it. I think we have to think more carefully about how to do that. And secondly I have two questions. The first is really a simple one. How long is the runway going to be?
MR. CONRAD: I'm sorry, how long is --
MR. McFADDEN: How long will the runway be when you get done?
MR. CONRAD: Oh, I am thinking 6,000 feet.
MR. McFADDEN: So -- (Laughter)
MR. CONRAD: How do I answer that?
MR. McFADDEN: So here's the deal -- when you're not doing your day job, have you -- or have you forced Geoff to model what the implications of this policy would be? Okay, perhaps not Geoff -- model what the implications of this policy would be in terms of time because in terms of supporting it, if what you've gained is us here is 18 months, frankly the amount of time that it takes you to get it implemented makes me less interested. If what you've gained here is 6 years, then I think it's worth discussing. If you haven't modeled that or you don't have a crystal ball, then we have to think very carefully about -- well we would think very carefully, sort of like Ed said, about how this intersects with the other proposals. So that's my first question, how long is the runway?
MR. CONRAD: And that was the easy one. (Laughter)
MR. CONRAD: Geoff did -- you want to comment?
MR. HUSTON: It's modelable. It will take about weeks or 4 weeks to assemble the data. You actually -- It's quite a difficult problem to model, but not impossible.
MR. McFADDEN: Okay.
MR. CONRAD: Mike, I actually did a couple of cuts at modeling this and discovered that, you know, strangely enough, the actual results depend a lot on what assumptions you make. (Laughter)
MR. McFADDEN: Okay.
SPEAKER: Be my guest.
MR. McFADDEN: I'll sit down and try to get over that answer. (Laughter)
MR. McFADDEN: The other thing that I see in the details of the proposal is that when you measure utilization for each one of the thresholds, you've dropped back to a percentage rather than a density ratio as the mechanism by which you decide whether or not the thresholds -- the utilization requirement's been made. Is that a conscious decision -- I mean, what was the idea behind --
MR. CONRAD: We don't do density ratio for v4, right?
MR. McFADDEN: Well, I know we don't, but there have been proposals to do it and I was just wondering if you had thought about it, or that -- just rejected it out of hand because we don't do it in the past.
MR. CONRAD: You know, to be honest I -- one of my goals was to try to minimize the amount of change in the --
MR. McFADDEN: Okay.
MR. CONRAD: -- existing policy evaluation --
MR. McFADDEN: That's a good enough answer right there.
MR. CONRAD: Okay.
MR. CURRAN: Are you for or against the proposal?
MR. McFADDEN: I -- for me to be for the proposal, I would have to have Marla's concerns addressed about the how the proposal moved through the global RIR policy development processes.
MR. CURRAN: If the proposal were -- if it was impossible to determine whether or not it would ever be implemented in other regions, would you be for it?
MR. McFADDEN: I'll change your question. If this were an ARIN only policy, I would not be for it.
MR. CURRAN: Okay, thank you.
MR. CONRAD: Okay. Alain?
MR. DURAND: Alain Durand, ComCast. I'd like to make public some of the comments that we had earlier at lunch. I am for the spirit of this proposal but I am against the way it's written right now. You mentioned earlier that this is again some bumps on the road to wake up people, so that they don't study for the exam just the night before. And I fully subscribe to this vision. The problems I have is, some of those bumps may be very high and in some networks going from 80 percent to 85 or 90 percent, may or may not be possible, and could come with a really very high operational cost, so those bumps may prove to be actually fatal and it could be a point where because of a certain network architecture that was put in place long time ago, but may not change, that we'll be in situation where there will be addresses. We will satisfy all of the criterias that for some operation reason, we would not be able to go to this present stage of utilization. So, I would love to support the proposal, but will insist on the documentation that you're making progress on IPv6 because at the end of the day this is where you want to go, you want to get people to move on to IPv6. But throughout the part that really talks about utilization, because that's a very direct impact on the operational aspect of running the business and it may take quite a lot of time to go there and we may just not have that much time before the free pool exhausts.
MR. CURRAN: Understood with respect to the utilization. As written, would you be for it, or against it, if it didn't change?
MR. DURAND: So as written, I would be against.
MR. CURRAN: Okay.
MR. CONRAD: And just to -- Alain and Dan and I had lunch, and one of my responses or questions was, so the goal of this soft landing is to extend the runway a bit perhaps, but to actually just kick people upside their head and say, you know, what are you doing for v6 transition, what are you doing for the run out of v4? And the question that I have is, you know, if one of these thresholds is fatal is, that the difference between the threshold -- the amount of time between when that threshold applies and if the policy were not accepted, the eventual run out of address space is at time different significant. And Alain (off mike) said, yes it might be, and I understand that. So I actually -- and thank the chair's indulgence, you know, I guess the question that I would have is how many of the people who have actually read the proposal see the thresholds as being unreasonable in there -- not the thresholds, the percentage utilizations as being unreasonable in their expectations, you just -- completely, you know, informal and --
MR. CURRAN: Let me structure it a little just --
MR. CONRAD: Please.
MR. CURRAN: The question on the table -- I'm going to ask for a show of hands -- is -- and I'm going to double check with you, so you've got to be very careful. I'm going to ask for a show of hands and it's how many people would like to see the thresholds removed from the --
MR. CURRAN: Now -- what would you say, help phrase it?
MR. CONRAD: My question is whether or not the -- how to put this exquisitely simply. Is the time differential of the threshold -- the imposed threshold or the imposed utilization of the thresholds significant as compared to running out of v4 space completely. Is that correct?
MR. CURRAN: And I'm not sure the audience is going to be able to understand that question with enough intelligent debate; we just show hands. We'll like -- I really -- can you try one more time?
MR. CONRAD: Well, let's go with your approach. (Laughter)
MR. CURRAN: How many people would like to the utilization thresholds removed?
MR. CONRAD: Removed, yes.
MR. CURRAN: Okay.
MR. CONRAD: Let's try it that way.
MR. CURRAN: So we're gong to ask for a simple sow of hands, okay. And the topic is simple enough that we don't require a debate on it, which is why I'm allowing it in the middle of the proposal discussion. The show of hands would be -- I'm going ask first for everyone in favor of having the utilization requirements removed from the proposal and then everyone opposed to having the utilization requirements removed from the proposal. So it's a simple show of hands on that topic. Does anyone -- anyone have -- okay, I see Randy in the back. Randy, you'd like the order reversed?
MR. BUSH: Yeah, so I can (off mike) negative.
MR. CURRAN: Okay. (Laughter)
MR. CURRAN: So, Randy would like it switched and without objection -- any objection? No -- we're going to ask a simple question. We'll be asking the question, if you believe there should be utilization requirements in the proposal, raise your hand, and then if you don't believe there should be utilization requirements, raise your hand. Everyone understand the question? Any further -- any further questions on the topic about to go, before show of hands?
MR. BICKNELL: Yes, might he go back to the flag with the table?
MR. CURRAN: Oh, so we can see what those are. Okay, so we're talking about potentially striking the second line.
MR. BICKNELL: Actually it's striking line -- these three lines.
MR. CURRAN: The -- these three lines, right, I'm sorry.
SPEAKER: Which three? (Laughter)
MR. CONRAD: Please, these three. (Laughter)
MR. CURRAN: They would be removing the three --
MR. CONRAD: The ones with the percent signs.
MR. CURRAN: The utilization criteria, lines two, three and four of the proposal summary. Okay. Yes, Thomas.
MR. NARTEN: Well, can I -- may be it's just me, but one question I have about utilization requirement is, is it to have 100 percent utilization of previous allocations or just efficient utilization of one hundred percent of those allocations?
MR. CONRAD: Whatever is in the NPRM will be reflected in the revised version of this document. So I don't actually know offhand what it says. Leslie might.
MR. NARTEN: But then presumably what's in the NPRM would not be a change from what's in the NPRM.
MR. CONRAD: Well, that's for the past allocations.
MR. NARTEN: All right.
MR. CURRAN: He's not intending to change the NPRM language in this aspect.
MR. NARTEN: NRPM.
MR. CURRAN: Thank you.
MR. CONRAD: Whatever. (Laughter)
SPEAKER: RRR. (Laughter)
MR. CURRAN: Okay, we're going to ask the question. First, who believes that utilization requirement -- sorry?
MR. BICKNELL: Could we ask them the -- each of the percentages separately because there may be differences in what we --
MR. CURRAN: No. (Laughter)
MR. CURRAN: I understand your request perfectly well. No. Okay, how many people believe that the proposal should have utilization requirements, raise your hand. Very high, please. Keep them nice and high. A good census takes 10 years, folks, hold it nice and high. (Laughter)
MR. CURRAN: I -- we have a count, thank you. How many people believe that utilization requirements should not be in the policy proposal? Raise your hand. Nice and high; almost there, keep going. We have a count, thank you. And it's coming up now. You can keep presenting and I'll give you the number when it's here.
MR. CONRAD: Okay. Actually I suspect I would be encouraging the queues to close at some point.
SPEAKER: Yeah, we're about done.
MR. CONRAD: Is it something relevant to -- okay.
MR. BUSH: I just asked two people who said no, why when they objected to specific numbers (off mike), not the philosophy.
MR. BRADNER: What Randy said was --
MR. CONRAD: It's all right, I could hear it.
MR. BRADNER: What Randy said was --
MR. CURRAN: Microphone?
MR. BRADNER: He said there were two people who voted no, who objected to the specific numbers, not the general philosophy.
MR. CONRAD: Oh, okay.
MR. BUSH: No the -- the numbers -- or in other words, it was possibly a poorly asked question. I said to some people, why no -- that it was because -- and they said it's because of the specific numbers, not the philosophy.
MR. CONRAD: Right.
MR. BUSH: And I believe what I heard from your question was, should there be limits, not those limits.
MR. CONRAD: Right, should there be limits.
MR. BUSH: So possibly you might rephrase?
MR. CONRAD: I actually -- I actually --
MR. BUSH: (off mike).
MR. BRADNER: And I would say that your original question was just that. Are the -- are the limits too strict, rather than should there be limits at all.
MR. CONRAD: Right, and for the sake of the other folks who are proposing in this session, I think we should move on. I think I have received sufficient input that I need to revise this section. I'll take discussion to the (off mike).
MR. CURRAN: For people who want to know the call the vote has provided; 154 people in the room, 33 in favor of the proposal having utilization requirements, 29 against the proposal, having utilization requirements.
MR. CONRAD: So, Tony?
MR. HAIN: Tony Hain. Trying to recall exactly what my point was. (Laughter)
MR. CONRAD: That's the nice thing about waiting long enough.
MR. HAIN: Yeah, no -- in fact my point was exactly about time. You've got thresholds in here that are based on hard numbers, but you're basing those hard numbers off of your perception of time and so with -- I understand that is a simplification, you know, or an attempt at simplification. But this at maybe a place where you actually want a little more complication and say, given historic run rates, the thresholds are X, whatever X is, of the percentage of the pool that's left, you know, so people can start to judge time because the question that Alain was essentially asking was, you know, is this threshold going to impact me or not. You with these numbers are actually encouraging a run on the bank, because I'm going to get to the point where I don't want to get to 10, so when it gets to 12, I'm going to run and grab as much as I can, because I can't afford 10 because it will kill me. I can't (off mike), you know, the -- the thresholds you've put in here are 10, and it really doesn't matter what those numbers are, all right? It's whatever numbers you put there, somebody will be in the place where they can't fill that, they'll have to get in before it.
MR. CONRAD: Uh-huh.
MR. HAIN: And so you caused that run to happen earlier. With hard numbers, it gives people an easy way to know when to do that.
MR. CONRAD: Right, the other side of that point however, is that if you define things in terms of time then you can easily get into a situation where if you do have a run on the bank, the later thresholds --
MR. HAIN: They distort the patterns? Right.
MR. CONRAD: -- just have been completely blown away. So the reason that I actually chose, you know, numeric thresholds in the amount of the free pool is to actually allow people -- to allow the flexibility that the time would actually be a variable as opposed to the amount of address space. You know, it's either one hand or the other. And I do understand the point about triggering the run on the bank; however, we have a fine ARIN staff who will protect us against that.
MR. HAIN: Oh, I am sure they will do everything that they can possibly do.
MR. CONRAD: Exactly.
MR. LEIBRAND: The question is what can they possibly do?
MR. CONRAD: Sorry, don't know your name.
MR. LEIBRAND: Scott Leibrand, the Internap.
MR. CONRAD: Oh, hi, Scott.
MR. LEIBRAND: I would argue against some of the previous arguments that say that this is a bad thing to do unless everyone else does it. I would argue that most of the staff in here is encouraging people to do the right thing. And that we should be encouraging people to do the right thing in our region, whether or not the other regions -- I love that this be adopted everywhere but as you can probably tell, I support the proposal. I think that until we get to 10/8s, most of these requirements are a small change to existing policy that's going to have a big impact in getting management aware that we have to be doing something specifically with regards to documenting plans and such. And I think that we should definitely do this even if the other regions don't, specifically so that we can get those benefits. And if we do want to put in any language about if other regions don't do this, then we're not going to do X, I think the only thing that should change are some of the specific numbers with regards to utilization and the rest of the policy proposal is something good for us to do regardless. Yes, I'm in favor of the policy proposal as written. I am in favor of adopting policy proposal in the absence of other regions adopting it and I would argue that if we're going to try to do global coordination we should be very limited in our tweaks to the proposal, if other regions don't adopt.
MR. CONRAD: Okay, since Leo is occupied -- go ahead.
MR. DICKSON: I think -- Brian Dickson with Afilias. I think my concern on the most recent utilization percentage is currently the -- across the board is 80 percent, if I understand?
MR. CONRAD: The current phase zero which by the way is the Michael Dillon memorial phase, because we didn't like the name of the phase zero, is actually trying to document the existing requirements.
MR. DICKSON: Correct. I think the concern is that changing those percentages at all sizes of new requests does not accurately reflect the ability to achieve efficient utilization. On a very small block, your efficiency granularity is extreme, if you got a, you know, /22 or something like that, you're only going to be 75 or a 100 percent, for example. And we want to make it more efficient for the larger blocks obviously but I don't think that we want to use the same benchmark for every size of allocation, so I would be in favor of a two- dimensional thing where it's the size of the block in each phase that has a different percentage.
MR. CONRAD: I'll send Michael Dillon with his complaints about complexity to you. (Laughter)
MR. DICKSON: It's only complex if it's not easy to understand. If it is easy to understand it isn't complex.
MR. CURRAN: As written, are you for or against it?
MR. DICKSON: As written, marginally against or abstained.
MR. CONRAD: Okay, Leo.
MR. BICKNELL: Leo Bicknell, ISC and NNAC. I am for the concept. I have some concerns about the exact numbers and in that vein, I stood up when Geoff said he could model this and I'm glad he can and I'd like to see some data. But my specific comment on that was going to be, someone earlier mentioned time, you know, how long will this extend the time and I don't think that's terribly interesting. When I'm flying around in the plane and want to land, I only care that the runway is long enough that I can stop before that last picture you had and that distance may in fact be quite different whether I'm flying in a Cessna or a 747 and so probably the kind of interesting thing from the modelers, would be to say, if we set these thresholds we'll get 50 percent of the planes on the ground safely. And if we set it to these thresholds, we'll get 80 percent of the planes on the ground safely. (Laughter)
MR. BICKNELL: Because whether that takes 6 months, or 6 years, doesn't really matter, we want them all on the ground safely.
SPEAKER: Pardon me?
MR. HUSTON: Geoff Huston, APNIC, I'll only take a couple of seconds. When you model this stuff, you go back over the last "N" months and you model demand, and you basically say, under what policy conditions did we give it, how much space are they going to burn through, and then you just push it forward, right? That's all you get, you don't get thousands of feet, you don't get tons of fuel or plane, sorry. (Laughter)
MR. CURRAN: We're going to close the mics just to make sure they're closed.
MR. SHACKLEFORD: I'm sorry, I thought you were just --
MR. CONRAD: No, not for long.
MR. SHACKLEFORD: Yeah. (Laughter)
MR. SHACKLEFORD: Scott Shackleford, COX Communications. I do not support the policy as written. I respect the spirit of it. However, I don't think that the energy and effort that would be imposed on ARIN staff is necessarily worth the potential gains as written. I also think that it might encourage an element of dishonesty in the community for people to work their numbers to show, you know, be at a 100 percent or whatever percentage of utilization is decided upon, if it's ratcheted up, excuse me, even if it's for all the right reasons, I don't necessarily think that people are going to be honest if they realize that they have to show greater efficiency. And with what I've seen, ARIN staff being taxed all the more with this proposal, they're certainly not going to have the resources to do any audits or any checks. I mean, there is a large degree of trust amongst ARIN and the community, just showing utilization. So I'm not for that's written. I do -- go ahead.
MR. CONRAD: Okay, would your opinion change if the utilization requirements were removed?
MR. SHACKLEFORD: I thought about that, and just standing here from up the wall, I can't come to a conclusion. I mean, respectfully, is it much of a policy if you remove those? Because that's a large of it, right?
MR. CONRAD: It would impose requirements of documentation. You'd have to document your plans with regards to migration and utilization of non-RFC 1918 for infrastructure and v6 deployment plans and that sort of thing.
MR. SHACKLEFORD: I don't know, I'd have to think about it. I don't have an answer right now.
MR. CONRAD: Okay, didn't want to put you on the spot.
MR. SHACKLEFORD: Thank you.
MR. KESSENS: So, I'm David Kessens, Nokia Siemens Networks. First a comment, I also observed that Michael Dillon thought this thing was complex. And I had something like, if he thinks its complex, that must be really, really complex. So that's the first comment. The other thing that I have a bit of a problem with is that, yes, I think the spirit is good. I mean, we do want people to move to something else, especially if we run out of -- some of the important resource to keep the Internet growing. But I'm not sure whether it's really our task to couple those things and tell people they have to move. I don't -- I think that's really overstepping our authority. It's like people are warned enough. I mean, we know the statistics that Geoff is publishing. We know that we're going to run into this wall. People have gotten the warning and people have a chance to migrate, make their plans in time. If they don't do that, then they have a problem on their own. I think we're way too much behaving like in governments trying to protect its citizens and that usually results in, actually, things you really don't want to end up in.
MR. CURRAN: So are you in favor or opposed?
MR. KESSENS: I'm not in favor because I think this proposal is way too -- sound way too much like protecting people for their own stupid mistakes. And I think people should have their chance to make their mistakes. And people should also have their chance to do the right thing and take advantage of that.
MR. CONRAD: My personal response to that is that the problem is that the mistakes that others would make in this phase actually affect everyone since it is a globally limited resource. And, you know, if somebody isn't doing the right thing, then it's going to impact, pretty much, everyone else. I mean, I understand what you're saying, I understand the point that you're making. But I guess my feeling is that, you know, if you are in need of an IPv4 address space, when there is essentially no address space left, then you're going to need to prove that you're doing something that justifies the community allocating address space to you.
MR. KESSENS: I just don't see why somebody should not be allowed to say that, I bet my future increase use of nets, double nets, triple nets, whatever.
MR. CONRAD: Then you don't need more address space.
MR. KESSENS: And you need -- no address space to address your nets? I don't -- I just don't --
MR. CONRAD: I understand your point.
MR. KESSENS: Yeah, I basically don't see it's our task to tell people how they're going to deal post -- the availability of IPv4 addresses from -- from their accessories.
MR. CURRAN: Okay, microphones are closed. Any comments from the head table? No, okay, thank you very much. Thank you, David. (Applause)
MR. CURRAN: We're actually going to rearrange things slightly. Ray is going to talk about that now.
MR. PLZAK: Okay, what we're going to do now is have Sunny come up and give the APNIC update. Then we'll do our break. And then after the break, we'll pick up policies 7-18 and 7-23. So Sunny, if you're ready, please?
MR. CHENDI: Okay, my name is Srinivas Chendi from APNIC. Since we're heading to the tea break, I'll just keep it short. Most of it is done by Einar in the morning, so I'm not going to go through, really what proposals were discussed in our region and reached consensus and which one not. I think you will hear those proposals here after the tea break as well. So, I get into the business of what we're going to do and what we actually doing -- did in 2007 and going to focus more in 2008. We just -- we completed our fourth member survey, member survey and stakeholders survey which was done confidentially by KPMG as usual. It was done by face-to-face. They actually went -- visited our members and did an interview with them face-to-face as well as written e-mails sent directly to KPMG. Also, we provided an online survey form that they can fill it in, which the responses will go directly to the KPMG as well. In the past results, we had 90 percent of items auctioned, as our members requested us to do. And 99 -- 39 percent of those are completed. The fourth survey, which was done in 2006, which was launched in 2006 and completed in March 2007. The top ten resource priorities that our members and stakeholders would like us to take on in 2008, which we already started, some of them in 2007, and almost nearly completion, probably by our next meeting in Taipei. So, the first -- I'll go through them in order of preference that they nominated. The first one is technical research and development activities. What they meant by that is for us to put forward some consumption rates, some timelines which Geoffrey has already done in regards to IPv4 timeline. We're also looking at putting some research in forward (off mike) BGP analysis. We have collaborated some research facilities with Cisco and Voit-JP in Japan. We're looking at providing more feedback into standards and governance activities by these activities. Streamline resource requests and allocation processes. We do agree in our resource request, our process for applying resource is bit harsh, bit hard for our members. So we have started a project called Client First. What we're looking at is a simplified process where our members don't have to really go through, for applying database objects when they request resources. So this is the Client First project, which we're aiming to release this by end of December this year. In this we actually ask our members whether they want just membership or they want board membership and resources, regarding their interest. And they can choose which way they want to go. And if they go for the Internet numbers and membership, they can actually apply for all the resources at a time if the wish to or they can select the resources. And they don't have to, like in the current practice; they don't have to create any database objects prior to applying for resources. This will be -- all the information will be gathered in the form and the hostmaster -- edition, based on the edition they create automatically all these objects and they inform the member. Increase accessibility of APNIC meetings and policy process. I believe all the RIRs are doing this, but we also Webcast and have transcripts available for all our meetings online. And during the meeting, we actually have video streaming live transcripts happening. Jabber Chat, since our region is very diverse, our members can participate using a chat-based application and they post questions on to the chat. Some of our staff will be monitoring those chats and they'll ask to the -- they'll pass it on to our SIG chairs to ask questions in the policy sessions. And also -- we also have --some sessions are also covered by audio. This will be available, we actually send announcements of these before the meeting and after the meetings during the sessions to all the people who subscribed to the mailing list so they know which session is happening at what stage and they can join and participate remotely. Represent the needs of ISP community in governments. Well, we are actually -- just look at that. We're doing activities with ISOC, in collaboration with ISOC. The latest one we did is in India in our APNIC 24 meeting. We have a joint session. We invited government authorities and regulators and ISPs. It was a closed session. It was successfully attended. This sort of things we are planning to do in future as well. We're trying to do one in the next meeting too. Hopefully it will be successful as well. We participate in NRO, ITU, IGF and ICANN meetings and we express our interest, our members interest in those meetings. We also, from time to time, monitor our -- monitor the government reports in our region and we provide responses to those. The most important one that we did is from the Indian Government on IP addressing and IPv6 transition and we provided our feedback and ISP Association of India actually encouraged that. And we, I think, we going to do that more, we going to monitor those things. Expand training activities in scope, geographical coverage and online options. We targeted -- for 2007, we targeted 70 training events in our region. So far, as of today we completed 53 of them. And we are actually online -- on target to complete all 70 training events. We delivered these courses in 30 locations so far. And we actually visited those economies we never ever have visited because of the interest and because of the sponsorships we got from the economies like Laos, Cambodia, Vietnam, Fiji, PNG; Papua New Guinea, Guam and Bhutan. I think the Bhutan was the latest one that we just completed. We're also looking at providing online facilities for our members because some of the economies we just cannot reach or we have just less membership, member organizations from that economy. So we implemented e-learning, we produced two modules on that and we're looking at having more modules and we're working along with RIPE NCC in this. We collaboratively design these modules and try to implement those at the same time so that both the communities can have these available. We're also looking at providing web class, so our participants can -- we can conduct the training in our own facilities and they can participate remotely which will, I think encourage more participation from the remote regions. Improve the APNIC website. Again, we do understand that our website is very complex to find the information. Sometimes even for our staff, you know, we juggle between the headings, you know, where it is. So, what we did is in the previous meeting, we, in APNIC 23, we did a usability study. We actually conducted a survey, online survey and a usability study, face-to-face with our members and stakeholders. And we gone through those and we know what we have to do now. And so we actually going to implement a CMS system that will encourage the authors to take the ownership of their information and try to keep up-to-date with the guidance of our editorial control process. So, there will be a full version control and we can keep the relevant information that our membership want to really see on our website and what they want to -- how they want to navigate through. Support ISP education in the AP region. We have actually introduced quite a lot of -- quite a few new courses like IPv6 workshop, hands-on workshop, a four-day workshop. We go and we conduct those workshops, its becoming very successful in our region. A lot of ISPs are actually coming forward requesting those kind of workshops. We used to DNS hands-on workshop. But this one is taking over that one, the DNS one. We're also thinking of providing a hands-on workshop on security, Internet security and everything. We invited some experts to our secretariat so they can train our staff, we can prepare a curriculum for that. We are hoping to release this -- this workshop probably in 2008 along with -- we're also in discussion to provide MPLS course but that's really not decided, we're still discussing and probably will be decided in the next meeting. We have various MoUs with our Internet Service Providers in our region and what these MoUs, what they dictate is they provide in-kind sponsorship for us. So we can go and train -- we can go more often and conduct these workshops in our region, as well as, we just completed our Train the Trainers workshop in APNIC so we can have more trainers available and go and do these workshops at different locations at the same time. This is one of the activity that our memberships really encouraged us to do and we're continue doing this activity. So far we have deployed about 26 footprints of various root servers in collaboration with the root operators in our region as you can see on the map. The latest one we deployed is in Manila in July 2007, I-root server footprint and in Suva, Fiji, F-root server footprint in April 2007. And we have some applications we're going through now for the 2008. I think Pakistan wanted to have a I-root server in their country as well, probably in Islamabad, we're looking at that one. And we have some more interests coming up from other economies which we will be looking at through 2008. This is our membership thing. This is a very good activity that we're providing, bringing the root servers to their home base so if any disruptions happen anywhere, you know, they can still be online. Just two more points before I go on. Resource certification, I think you are all aware of this. We're going to implement probably early 2008. What it does is whenever we allocate resources to our members we attest a certification to that so they are the legal holder of that resources. And they can request the router's resources through the upstreams. We're also trying to provide a functionality in MyAPNIC. MyAPNIC is our member portal that they can actually -- when they subject-allocate or assign to their members, their customers; they can also do the same what the RIR -- what the APNIC is doing. So just by a click of a button, they can make the allocation, suballocation. At the same time; they can issue a certificate, attach a certificate to that and forward it their customers. The development work is still undergoing. If you have any questions or if you'd like to know more about it, you can talk to Geoff Huston for this. Expand external communication and outreach activities. Well, because of the diverse region we have and also the various languages that they speak in our region, I think we really need to focus on this one to encourage participation as well to engage them with us. So, we identified our own staff who are capable of doing liaison activities for us, who can speak the local language. So some of the staff at APNIC are actually in the dual roles, they are hostmaster cum liaison. So, they go and represent APNIC in the events happening in those region. They go and participate in the trainings, they go and conduct the trainings for them which is -- in a way, we're putting more focus and releasing information that they require at the given time of those events. Our next meeting will in be Taipei from 25th to 29th February 2008 along with Apricot 2008. You all are welcome to attend that. And our future meetings going to be the APNIC 26 in Christchurch, New Zealand, that's 25th to 29th August 2008. And the following one, again with -- in collaboration with Apricot 2009 in Manila, Philippines. Thank you and I got just one last thing from Paul Wilson. "For you as an Internet user, what is a critical Internet resource? Can you list your top three in this category?" and please e-mail him or post him on LinkedIn. Thank you.
MR. CURRAN: Thank you. Any questions? We've plenty of time. Okay. Thank you very much.
MR. CHENDI: Thank you. (Applause)
MR. PLZAK: Okay, a couple of -- another drawing -- wow -- okay, well, coming at me. Okay, I'll get through this yet. Prize Wheel, Raffles two names drawn this break. Don't forget the consolation prize when you lose. And the election desk is now closed, polls closed. And so we have the three other help desks open. And take a break; be back here in 15 minutes please. The clock on the wall will be the starter. (Recess)
2007-18: Global Policy for the Allocation of the Remaining IPv4 Address Space and 2007-23: End Policy for IANA IPv4 allocations to RIRs
MR. PLZAK: Okay, we're adjustments to the agenda. We will begin, first of all, we have two policy proposals, the 7-18 and 7-23 which overlap considerably. So what we're going to do with these two proposals is that each proposal will be presented first. So without any discussion until the second proposal is presented. So it'll be one proposal presentation, a second proposal presentation and then the chair will open the floor for discussion. Then the chair will determine how to -- which questions to ask based upon discussion.
SPEAKER: An input from the proposal authors.
MR. PLZAK: And input from the proposal authors as well. Okay, then, depending upon time, we may do one or more two proposals here today. Overnight, we will work and readjust the schedule, and we'll have a new revised agenda for tomorrow morning. It's in our ever running intent to keep us moving forward. So let's get started. The first proposal to be presented will be proposal 2007-18, the global policy for the allocation of the remaining IPv4 address space; this is a global proposal. Introduced in July of this year in -- the first discussion, not revised since it was designated as a formal proposal, text is as shown. "The ARIN staff understands this proposal is a global proposal. It would reserve a certain number of /8s in the IANA pool to be allocated to the RIRs when the remaining IANA /8s run out. The suggested reserve is 25 /8s, five for each RIR. When the IANA cannot fulfill the last RIR request, they will give what they can to that RIR. The IANA will then allocate five /8s to each RIR." Matt and Bill are the shepherds. There have been 38 posts by 23 people since this was posted as a formal proposal, 1 for, 9 against; there's a couple of comments for you. With it revised for "N" equals 2, 5 posts by 4 people with 1 in favor. Prior to the formal proposal, there were 38 posts by 23 people, three in favor and seven against. Legal assessment, counsel says in October of this year, "these two policies," referring to this one in 2007-23, "address the same issue, the global policy of what allocation should be made and when regarding the last unissued IPv4 /8s from the IANA. Based on legal considerations, counsel has serious concerns about the implications of adopting either proposal 18." He doesn't have similar concerns about -23. "-23 describes a policy to allocate equally the last 5 blocks of unissued /8s, providing one to each of the RIRs. This is a rationing mechanism to allocate the last /8s." "18 describes much more aggressive policy, which would allocate the last 25 blocks providing 5 to each RIR." "The first proposal, -23 is more consistent with the current legal underpinnings of the RIR system, while -- substitutes a new basis of allocation, equally between the RIRs who have very different rates of utilization and need. The substitution of utilizing RIR equality instead of utilization based on allocation may have significant legal implications for ARIN."
MR. CURRAN: I have a point of order.
MR. PLZAK: Yes.
MR. CURRAN: I have a point of order. So I want to get back to the legal assessment on the prior page. I believe there might be one or two typos on this page. So I'm going to ask at the first bullet, at the end of the first bullet, it says, second to last sentence, "based on legal considerations, counsel has serious concerns about the implications of adopting 2007-18."
MR. PLZAK: 7-18.
MR. CURRAN: 2007-18. "Counsel does not have similar concerns about 2007-23." Does that not belong there?
MR. RYAN: That's correct, the sentence is correct as read. One policy gets rid of --
MR. CURRAN: Microphone, sorry.
MR. RYAN: Unless I mixed the numbers. Let me just talk about them, there's two policies, one says, the last five blocks will be allocated, one each to the RIRs. I believe, that is policy 23, if my numbering is correct. I do not have a legal concern about 23, because you have to have some mechanism to allocate the last ones. The -- this proposal 18, which is the one that I believe is read that 25 of the last /8s would be allocated, 5 each, and that is the one that I believe I have a legal concern about.
MR. CURRAN: Got it, so -- and then the second, the last paragraph, "the first policy proposal, 2007-23 is more consistent with the current legal underpinnings of the RIR while 2007-18" --
MR. RYAN: 18, that's right.
MR. CURRAN: Okay, "substitutes a new basis of allocation." Okay, I just want to be clear, thank you.
MR. RYAN: My apologies, there is a typo.
MR. CURRAN: Okay, continue.
MR. PLZAK: Okay, "currently, if ARIN is legally challenged about its allocation policies and the underlying global policy, all current policies are based in need and utilization. Since the take-up rate in each RIR is very different, the allocation policy proposed in 2007-23 undermines the current rationale of need and utilization based allocation, and it is inconsistent with all prior ARIN global allocation policies." "Adoption of 2007-23 discriminates against the ARIN service region, it could reduce the amount of IPv4 resources available and instead shift these resources to other continents, with less actual need than ARIN region. This will, in my opinion, raise fiduciary responsibility issues for ARIN's Board, it may lead to counsel cautioning the Board members regarding adoption of global policy that has an intentionally discriminatory impact against or adverse to ARIN's service region."
MR. RYAN: So that should be 18, right? I've mixed the numbers in or whoever retyped it or I typed it. It's -- the one where it's 25 /8s is the one I'm concerned about, which is 18.
MR. PLZAK: Which is 18. Right, okay.
SPEAKER: Turn on this microphone.
MR. PLZAK: Mic please.
MR. CURRAN: Keep this microphone on, thank you. I think we understand what you're saying and they should both be 18, got it.
MR. PLZAK: Staff comments, as of October, this year, "this policy conflicts with the spirit of RFC 2050 in which fairness and efficiency of allocation by IANA to the RIRs is cited." "If additional addresses are made available to IANA at some point after the exhaustion phase is triggered, this policy would need to be revised before IANA could do anything with the addresses." This would go into section 10. Impact, minimal to 90 days after actually the global policy ratification by the ICANN Board and will require some guidelines change and staff training. So Roque, would you please come up and make this presentation, and then we would have the next presentation.
MR. GAGLIANO: Hello, hi. Well, thank you. My name is Roque Gagliano. I work for ANTEL, Uruguay, ISP in Uruguay. I'm also the coordinator for the IX in Latin America. And I'm the coauthor of this policy with Francisco Obispo from Venezuela, Hytham -- I'm going to pronounce it wrong, I know, Haitham EL Nakhal, he from Egypt and Didier Allain Kla, and he's from Cte d'Ivoire. So we are from different countries and different regions. So some previous information, the -- well, we don't know what it's the issue, the IANA IPv4 pool is exhausting. So I didn't bring any graph about that. I guess, the IANA people is going to work with that later on today -- later on during this event. And therefore, I mean, conditions are changing for the allocation of IPv4 addresses. We -- there's a prediction, and also, we're all familiar with Geoff Huston's data. The exhaustion of the free pool is going to take place somewhere in the first semester of 2010. However, to understand on the -- based on the current policy, not all the RIR's going to receive a last allocation at that time. So the actual last allocation on that different RIR's going to receive may vary, okay. So not everybody is going to get its last allocation in September -- oh, sorry, May or April, 2010. So this is a global policy, and I'm going to describe a little bit about the process, and I know this morning, Axel did it. So thank you very much and I don't have the fancy graph that he show. And I know I may make some mistakes. So the process is described in an NRO document, basically the idea is a common text need to be ratified by each RIRs by the method of their choice or by the PDP process. And I know most of you think the PDP processes are very similar. Yes they are, but you have to be trained on that, and every RIR has different forms to fill to get the policy in their system. Every RIR has different procedure and dates and dates to submit changes, et cetera. So it's not an easy process for somebody who's not, for example, on their staff, et cetera, to understand. So I appreciate the help that I've received from the -- every RIR staff to kind of understand how their system work. And I know I made some mistakes on the way, so thank you very much.
MR. CURRAN: Thank you. (Applause)
MR. CURRAN: We're going to hold discussion of these until after the presentation of both. We have two policy proposals. We're going to have them both presented and discussed as that was the author's request.
MR. GAGLIANO: This -- after the -- this common text is ratified by every single RIRs, then it goes to the NRO exec committee, and I'm -- do a recommendation to the ASO Address Council has six days, and then goes to the ICANN Board. So I'm just showing the processes, and I just showing that everything goes well. So the process is pretty long. So what's the current policy? What's in place today? What does that policy says? The policy says, RIRs may request additional /8s if available space is less than 50 percent of one /8. An interesting thing is that IANA shall -- is going to allocate /8 blocks for the necessary space for 18 months. So that's the current policy. However, there is an agreement between RIRs that even though they're entitled to several /8s, they will only accept two /8 per -- each time that they request an allocation from IANA. Again, this is an agreement between the RIRs and it doesn't mean that they're going to -- always going to get two. They may get one if they only need one. But if you think about the last 18 months, for example, APNIC got eight /8s. So if we move to 2009 and this agreement doesn't stand, APNIC can get 8-10 /8 in allocation, we don't know. So what are we proposing? We're proposing changing this global policy. So the policy only applied for what -- how the addresses are allocated from the IANA to the RIRs. And we are proposing a two-phase approach. The first phase is just business as usual, and that's going to continue until a certain amount of -- a certain amount of /8 are available on the free pool. So when that activate the second phase what's called "Phase 2," when an equal size final allocation and that size, we're defining by a arbitrary "N" number, is made to each one of the RIRs. Okay, so we got an equal size allocation as the second phase. And we also start with, and that's a final allocation. So that's sure, I mean, what we're saying is if there is free -- if there is free address pool available afterwards, IANA will not allocate those. So probably we will need another discussion and another policy about how to deal with that, which is not bad. So this -- let's get with an example, and there has been some controversy in other RIRs mailing list. Let's say that the IANA pool sometimes has 11 free /8s and we set the number n to 2. Which means 10 /8s should be allocated in the last allocation. So let's say RIR 1 requests for two /8s, again the free pool is set to 11, and qualifies for that. So IANA have two allocate two /8s which makes the free pool to go to 9. So there's not enough free pool space to give to each RIR. So we have a problem. So we know what we wanted to go -- to do, but we would have to make sure how do we write it on a text. So we have our first policy text which was not -- actually introduced in -- sorry, in ARIN, it was just introduced in LACNIC, which basically mention a formula with a integer value, et cetera. But then we realize that it was a little bit complicated, and probably this -- just want to make it more simple. And we come out with the idea of actually, what we can do is to reserve the last allocation at the moment of approval of the proposal. So when we get the IANA file, the text file with all the /8 allocation, at the time we approve this proposal, the 10 /8s will be reserved, 2 for each RIRs and then they will now be part of the free pool. So that means, on the day we approve this policy or the ICANN will approve this policy and implementation, the pool will be reduced. But actually, by reserve, there's a space for the last allocation. That said, it means that IANA will allocate IPv4 address until it cannot do any longer, because the pool is empty. And again, the pool doesn't consider the ones in our reserve. And finally in the Phase 2, IANA will allocate the "N" reserve units to each RIRs and this -- the allocation of the last request. We're going to see how does this work. So let's say at the day of -- we approve this policy, the IANA pool is 30 /8s and we set "n" equals 2. So what happen is at the time the policy is approved, 10 /8s are named as reserve, not allocated, but just as reserve. And the free pool that time goes down to 20. So we start -- IANA continue allocating business as usual, Phase 1, as we do right now at this time. And when it gets, for example, to one /8, IANA receives a request for two /8. But its pool just have one free. So at that time Phase 2 is activated. IANA has to inform NRO on the activation of the second phase. And what IANA has -- what IANA is going to do is going to is going to allocate three /8s to the RIRs and request the last allocation and two /8s to the rest of RIRs. Okay, so this 1 RIR -- then, is going to get a little bit more than the rest. But that's because it just happened to be the one asking for the last allocation. So that's the idea, then, of our policy. And when we thought about this, back in April-March, we believed that we wanted to have two kind of discussion, we wanted a separate discussion of two things, one was the policy principle, the idea of this policy, okay, and the other discussion was the size of the allocation, okay. So that's what we thought at the beginning, but it didn't come out exactly this, way because actually the two topics are also mixed. So our first proposal was set up a high value, actually it was "n" equals 5, and that's because we want to -- something what we were looking for was to incentivate (sic) conservation policies. And we believe that policies like the one that was presented by David today could be and has, if each RIRs got bigger enough block as a last allocation, that could allow them to have policies that says, when we get the last allocation, blah, blah, blah, blah, blah. But suddenly, I mean, in the discussions we had in several RIRs we realized -- and there was a lot of -- except -- this is about the size, and it looks to be too big. And the concept itself was not discussed. It was just discuss the size. So what I wanted to focus today is to understand why do we need this policy? So the question, the first question I ask is do we really need a new policy. So the current policy doesn't bring RIR certainty if they're going to get a last IPv4 allocation request. And we're going to think about what's happening with the current allocation similar to what's the dancing -- sorry, the -- I'll read it -- I write it down, the music chair game, and that's a comment on -- Randy made of the APNIC -- of the APNIC list. So while VIR is -- all the RIRs dancing around these chairs and the chairs are, you know, once at a time they're leaving and we know at the end it's going to be one chair, and one of them is going to get it. But we don't know which one. So if it actually -- if we were today in 2010 and today was April -- let's say today was 2010, actually ARIN's last allocation will have been October 2009, because ARIN last allocation was in October 2006. AFRINIC last allocation was in 2005, et cetera, et cetera, so we don't know -- there's several different possibilities and scenario on what's going to happen. And that's particularly problematic for smaller RIRs And why is that? That's specially problematic because the more RIRs are younger in the RIR season, their available blocks, their available addresses in the blocks, it's much smaller. They don't have most -- almost any legacy holders, and for them to play in the black, gray, white market, it's going to be very, very challenge. And we don't know either if the current gentleman agreement between RIRs is going to be -- still be there. So we don't know what going to happen, so there's a lot of uncertainty. Also the current policy and we saw that today with several comments -- make it harder to implement just conservative policies. So the thing is we have proved one of this -- I do believe that this policy -- they go in hand with what they will propose and they're very, very compatible in the sense that we can have conservative policies than enhance -- than promote IPv6 than it's tied to the last allocation. And I've seen proposals in the -- for example in APNIC region when they talk about reserving space for critical infrastructure, reserving space for ISPs, et cetera and that can be done for example if we know that it's going to get a last allocation. If we don't know that, what people are trying to do is to make sure that you have the resources. And the third issue -- it's also that -- I think we need to discuss this, I think that this is an -- this is the right community to discuss this issue. This is the RIR community, and getting a global consensus on what to do with the rest of the IANA free pool is very healthy for our community -- for our global community. And we know that there's going to be a -- pressure on the central pool is going to increase and we know that this issue -- and we talked about that during the NANOG meeting -- the ARIN Counsel talked about that -- then this topic is also in the agenda of other constituencies like the IGF, ICANN et cetera. So I think it's very important and us as a community to get together and give a clear message of what's going to happen with the rest of the IANA free pool. The last thing is that we've got to remember that there's 44 /8, remember this time. So -- and we know -- I just explained the process, so the process take time. So if we want to do something, if we think this is important it's also the time to do something about it. So next question; are we breaking anything? Well, this proposal has not almost nothing -- got consequences. We're not enhancing -- we're not enhancing the break of any --
SPEAKER: I know.
MR. GAGLIANO: We're not getting bigger -- the IPv4, routing table, nothing like that. So that said, the other question that came out in the May release is, we are pushing forward the day of the -- exhaustion day from 2010 -- early 2010, perhaps some much time earlier. Well, that's not necessarily true. Especially depends which RIR you are. But also depends on the size of the last allocation. If we take "n" equals 2 probably most of the RIRs are going to get just as much space as they would get with the current policy, okay. Then there was concern -- some concern especially in the APNIC region about what's RIR shopping, which means that if we got a stock of IPv4 addresses in certain, RIRs, bigger companies are going to just set up some nonexistent company there and get some addresses. But actually this issue is just independent or (off mike) to the -- to how the -- the last allocations are made. They're going to be somewhere and the companies that want to do that, they're still going to -- can do it. And also we got to remember that, you know, the market's going to be there. We got to understand -- and this is going to be all in the same bucket as the legacy holder on the IPv4 market, and we talk before. So I don't think it's relevant. I don't think we're going to have that problem. And finally the -- I want to talk about what the staff mentioned about RFC 2050. Actually, RFC 2050 is the best among -- practice only if we take the abstracts, it says on the document, describe the IP assignment made by the original registry to their customer so it actually does not apply in here. So next question. Why an equal size allocation. Well, first of all, it's simple and straightforward to implement. You know, it stop us to discuss, you know, who is big, who is small, how big, how small, et cetera, and if we do it and with the right size, most of the RIR's going to get the same amount of addresses than they will with the current allocation. So there's no problem there. And also we don't want to chop /8. You know, we don't want to start telling ARIN, okay, we need for these small RIRs we just want them to have a /10 and then this big one is going to get a /7 or a -- so after we discuss, why do we need this discussion, and we understand what's the concept behind -- the second discussion is what should be the size of the last allocation. And if you check some of the previous slide, our first proposal was five /8 per RIRs. After discussing this and we already discussed this in three RIRs, we came out and we needed to change that number and we discussed that -- and it's our group, and we saw that perhaps the most appropriate number would be "n" equals 2. But actually the number itself is going to be a compromise number. Now, we have to agree on that in a global base. And again this is a global issue, so it affects it that relative of how it's seen in a lot of places. And of course, I mean, the number itself, it's kind of arbitrary too. So why "n" equals 2, "n" equals 2, because today is what -- an assignment is. Today the agreement is that two /8 has the maximum assignment so we thought about, okay, let's just continue with that. Also, with "n" equals 2 there's not going to be a significant address (off mike) in the different RIRs and that's one of the fears that it was shown when I talk about RIR shopping. Finally, a "n" equals 2 is going to allow RIRs to do some of the conservation policies, maybe a smaller space would just not be big enough to implement those policies. And again, as most of the RIRs -- probably four of them are going to get the same allocation as with the current policy, it doesn't -- it removes the fear about moving the day forward. So again, we introduced use this policy in April 2007 in the LACNIC region and we went there to their meeting in Isla Margarita, and we reached a really large consensus on -- I'm not going to say "unanimously," but it was really, really big, and the policy is waiting for the board approval. The consensus there was with "n" equals 5, the regional policy. In APNIC region, well, the other proposal was also deviated, and I know the co-chair is around there, but what I want to emphasize is that we -- there was a vote on the concept of the policy, and we can say that there was a positive reaction on discussing this issue, and this policy went back to the mailing list and it's being discussed on the mailing list. Then in AFRINIC we did reach consensus of our policy, but it was agreed, and the policy was going to go back for a last call in the mailing list to discuss the value of the "n" number. And ARIN -- I'm here and perhaps it's going to be next week. So we have two policies, 2007-18 and 2007-23, where we both agree -- and that's something we talked today, this will be -- that we'll also be in the need of a global policy with equal last allocation for each RIRs The size of the last allocation is the only important difference, and we will -- we both would like to reach consensus on the policy principles moving details of the implementation to the mailing list. So what's next? So what we're looking for here is looking for -- is to -- to talk about and discuss and get feedback from the community about the need and the principle of this policy. So we are planning to go back, because further discussion needs to take place, to go back to the mailing list to discuss the details of the text and also the size of the last allocation. We hopefully get -- plan to get consensus, probably the next year and probably get approval from ICANN early 2009. In summary, we are proposing a new global policy. We believe this process is an opportunity for the RIR community to give an united global message on this issue, and maintaining the current policy, just doing nothing, brings an unpredictable end to the IANA free pool and what we are proposing is two /8 for each RIRs. Thank you and I'll take question after the other presentation. (Applause)
MR. GAGLIANO: Where should I sit?
SPEAKER: You can sit right here.
MR. PLZAK: Okay, 2007-23 and policy for IANA IPv4 allocations through RIR's global proposal. Where the staff comments and the legal comments are the same as the previous proposal, I'm going to go right by and just note that. So introduced in August of this year, and as in the formal proposal in August as well; the text has not been revised since then. We understand this policy would have an IANA allocated single /8 each of the five RIRs at the point when IANA pool -- free pool hits five /8. Shepherds are Dan and RS. One for, none against out of three polls, by two people. Those are comments. Prior to this being a formal proposal there were eight polls by five people with two in favor and one against. Legal assessment is identical wording as corrected and discussed in the previous discussion. And three comments -- item three (off mike) will project an IANA exhaustion date the RIRs do not generally make predictions about address space that are particular about the IANA pool, since they have no control over these resources. This policy conflicts with the 2050, which is the same as before and the NRPM change would go into section 10. Thirty to 90 days after ratification by the ICANN board, not the ARIN board, minimal change to guidelines and staff training and so I will now ask Izumi to please give us her presentation.
MS. OKUTANI: So good afternoon everyone, my name is Izumi Okutani, and I work for a national internet registry in Japan called JPNIC, pretty much the national version of what ARIN does to the community. And my proposal is taking a little bit of a different approach from what Roque has proposed but basically proposing the same framework; how we should distribute the last pieces of IANA IPv4 allocations to RIRs. Well, this slide I'm just going to skip, because I'm sure everyone on this room is aware of the situation. So facing the v4 exhaustion that's expected to come up in a few years, we can think of a number of different types of issues, such as, okay, how should we efficiently utilize already distributed v4 addresses especially legacy address space or issues such as what was discussed in the morning panel, like what we should do after the address space runs out. But what we'd like to focus here is what we should do before the actual v4 address space runs out for IANA pool as well as for RIRs. And we think the necessary measures we should take for before the exhaustion actually takes place is pretty obvious, you know, when you list it here. So we should clearly define how we are going to distribute the last few pieces of address blocks so that we won't have any disagreement at the time of exhaustion. And also reduce the last-minute surprises as much as possible. And keep the community well-informed of the situation so that people wouldn't come up to ARIN saying, "Oh, we didn't know about this. And you know, we're running short of address space in our infrastructure. We're in trouble." So we should -- it's important that, you know, we keep everyone informed about the situation. And for those necessary measures, we see the current problem is, first, there's no clear agreement on how we are going to distribute the last pieces of IANA blocks to RIRs. Well, people might say, "Okay, we can just continue with the current scheme and distribute on the consumption base." And yes, I think that's one way of thinking and approach, fair enough. But I think it's important that we clearly, explicitly agree that we will carry out under the current scheme onto the very end rather than just unconsciously continuing with what we do at the moment. And with our case, we think it's better to come up with a different scheme on allocating the last few pieces of IANA blocks. And the reason for this is that the size of the last allocation that an RIR will receive from IANA depends on the timing of the request that this particular RIR would make. So it would make it more difficult for RIRs to plan how they are going to distribute the remaining pool that they have to the community. I will explain this in a little bit more details in my next few slides. And there's no official information for the communities on how much remaining pool is available for both IANA and RIRs. I think already, based on personal efforts, there are very reliable projections made available. But -- and I'm sure everyone who attends these meetings and active members of the community is aware of the dates. But others who simply just sometimes look at ARIN's website, maybe they don't know that such a projection exists in the first place. So I think we should do more activities to reach for wider members of the Internet community than we do at the moment. And our proposal consists of three elements. Originally, four, but we removed the parts -- the second part. So we now have three elements. The first part is the same scheme that Roque has proposed earlier to equally distribute the last few pieces of IANA blocks to RIRs. And in our case, we're proposing to allocate a single /8 each to RIRs. And the second part, the part that says number 3, it should be completely left up to each RIR communities to define their regional policy after IED. By IED, we mean IANA exhaustion date, the date that IANA pool will be exhausted. And this might be quite obvious to everyone. And this is -- this may in fact be the actual practice at the moment. But we want to make sure that this is shared. And I think there will be stronger needs to have more diversity on the policy for each RIR region, once the v4 is close to running out. For example, maybe in a region where there is plenty of IPv4 address space available, maybe the issue will be to promote the transfer to IPv6. Whereas in a region where the v4 Internet itself is still in the developing stage, maybe they need more focus on ensuring that as many people as possible is able to receive v4 address space. So we think that it's important to emphasize that these kind of regional diversity is tolerated and allowed. And the third point is that RIR should be -- should provide an official projection of IED. And by official, we don't really mean anything heavy as to RIR should come up with their own projections, but simply quoting that the existing projection as a reliable source of information and keeping the community informed through their website. And, well, in the meetings like this, I think RIRs are doing a good job. But I think there should be more outreach about the situation to the community. And regarding the first point, distributing a single /8 to each RIRs, I'd like to explain the difference between adopting no policy whatsoever and applying this policy. So first, if we don't apply any policy whatsoever, we can think of three different cases on how much address space that an RIR, in this case, in this example, ARIN can receive. The first case is that ARIN can request -- can receive the address -- the full address space that it has requested. So for example, if there are five /8s available and another RIR comes and request and ARIN requests for two /8s, they are able to receive what they've requested because there were pools available. The second case is that ARIN was able to receive only a part of the address space that they've requested. So two RIRs have made a request before ARIN. So by the time ARIN makes a request, even though ARIN wanted to have two /8s, they were only able to receive one out of two that they needed. And the third case -- sorry, I think I reversed it. So going to the next slide, the third case is ARIN is not able to receive any address space that it's requested because all the RIRs have requested by the time ARIN tried to request, so getting no blocks. So as you can see from these three different cases, the size that ARIN will be able to receive as the last allocation from IANA can vary from zero to more than -- well, I've written two /8s, but then I aware that they're potentially able to request for more than two. So it would make it more difficult for ARIN or other RIRs to plan the remaining pool to their respective communities because how much pool they have will not fix until the very end. Alternatively, this proposal will allow each RIR to receive a single /8. So we know what to expect. And they -- each RIRs can plan the distribution of the remaining pool within their community based on knowing what they can get. So this is a visual example of what we are going to have by applying no policy. So if they already have a certain amount of free pool, they wouldn't know how much additional pool that they're able to receive from IANA as the last block. If they are not able to get any or they can get more than two /8s, they don't know. But by applying this policy, they're sure to know that they're able to receive a single /8. So they can pace up their distribution or allocation based on knowing how much they would be able to receive. And that's the idea behind our proposal. Thank you very much. (Applause)
MR. CURRAN: Okay, microphones are open. So microphones are open for this topic on the two policy proposals. Remember to state your name, your affiliation, and whether you're in favor. Now, I'm going to warn people in advance. The policy proposal authors and shepherds we got together and they asked how they wanted this presented for a show of hands. So when we get to that point, we're first going to be asking in general whether we want a distribution algorithm. And then we're going to be asking in particular whether we're for -- pro or con a proposal where "n" equals 1. So -- but we're going to talk about these proposals together. It would be nice when you speak up to the mike if you say, "I am for a proposal such as this that allocates these," and in particular, whether you're for it in the case of "n" equals 1. So starting at the far microphone.
MR. LEWIS: Ed Lewis, NeuStar. When you say "n" equals 1, that's what is in 23?
MR. CURRAN: That is what is in 23, yes.
MR. LEWIS: Okay. And I'm for this idea. I like the idea of the last shot even in distribution. I like it only if it's per RIR because it keeps the hoarding effect down from anyone having more than enough. And the concerns about if the slowest burning RIR gets that last one and may have it for a long time, that could happen anyway. If we don't have this, they could wind up with it anyway just by luck. So I really like the idea because this -- it's kind of like the last -- this is the end of a period, the games coming to an end. It's kind of ceremonial for the larger RIRs, the faster burning RIRs. I think you want to make sure that people know this is coming down to the end. And I'm not getting concerned about one having too much and having maybe six months' or a year's worth of supply more because they've been burning slower up to then.
MR. CURRAN: And how do you feel about values of "n" such as 5 or 2?
MR. LEWIS: 5 and 2, I think are bad. I think I want to have it as -- I want to keep the hoarding effect down as much as possible.
MR. CURRAN: Okay, thank you. Yes, responses, go ahead.
MR. GAGLIANO: Yeah. And I don't want people to miss the point and this is a global proposal. So we need to get consensus on a global base. So the question for me, if we remove "n" equal 5 but if we go to "n" equal 2 in the question and looking at how the global consensus look like at this moment, if there is a fairly good global consensus for "n" equal 2, what would you opinion about that? Would you agree on that?
MR. LEWIS: I really -- it's hard. Okay, I understand the question. But in the ARIN region, I would vote for a 1. It's an ARIN region question. This is the ARIN region policy process. I can't say that I would ever support 2 or 5 because my real concern is the hoarding. If any one or if the -- let's say the slowest burning RIR gets 5 and has that for three years, there will be people clamoring to get into that region to grab that space. I think we don't want -- we don't really want to have that. I'm not so much worried if it's like 18 months or a year. But if it's 2 or 5 or worse, to me, worse, I don't think it's -- we'd have too much people running around the globe trying to find that last amount of space.
MR. CURRAN: Okay, thank you. Center microphone.
MR. DICKSON: Brain Dickson, Afilias. I'm not in favor of integer values of "n" (Laughter)
MR. DICKSON: It's an odd suggestion, but fractional values of "n" may work better. What we're talking about is projecting the exhaustion and then figuring out how to allocate that out, but we're trying to do it with a fixed size of /8. If we do a projection on how much time there is left and what the projected burn rate is for the five RIRs, and at some point say, "This is the last period. Allocate all of the remaining space. Aggregate it as much as possible, but break it up down to a level of /10 or /12," that way it's completely fair based on the actual usage rate at the time the decision is made. But it ends all discussion and makes it very simple for implementation.
MR. CURRAN: Okay, responses.
MR. GAGLIANO: Well, first of all -- I mean I think it's an idea. And I would like to see it writing down in a text, you know, because that -- makes it -- the implementation is kind of challenging. But it brings out the concept of fairness, you know. And if we want to discuss what's fair and what's not, you know, it's a whole new door that we are opening. And again, what we are trying to do is to get a (off mike) as an RIR global community. Now, we can get together and get -- and find an agreement and show them this global process work. And I think then going to that path looking at the time we have is going to open an endless discussion and we won't be able to make it. So my point is I -- there's several issues in what you mentioned. First of all, what's fair and what's not. How many IP addresses does ARIN has per Internet user? How many addresses Africa has per Internet users? How many addresses Africa is going to need, for example, when the new fiber comes to the east coast? How many IPs are they going to need when finally we have broadband in that region? And probably, who's going to first run out and how to implement v6? So that's one thing and the other thing is I think we should go with something that is easy to understand and we can do it in a short term. Again, looking at the dates, if we get consensus in this, we would be able to looking at an approval from the ICANN board on early 2009. And that's pretty close on the exhaustion that we're talking about. If nothing changes with a gentleman agreement, if something changes all our statistics, all our assumption doesn't work.
MR. CURRAN: Okay. Any follow-up or clarifications?
MR. DICKSON: The follow-up clarification would be that I would stipulate that the actual decision would not be based on projections today, but based on the projections at the date that the policy gets implemented. And the date that policy gets implemented is when the carving actually occurs, which is fair. It's based on a projection of how much time is left. Everybody has the same amount of time.
MR. GAGLIANO: But the problem is those projection change on time. So when you do the projection, when you want to do it, maybe you don't have the addresses in order to implement the projection. So it's -- you have so many variables there. And you got to write it down in the text and it's challenging.
MR. CURRAN: As written, I believe you would not support the proposals as written? For "n" values of 1 or greater, just to sort of keep it in the context as they were written.
MR. DICKSON: Abstain.
MR. CURRAN: Okay.
MR. DICKSON: Sorry.
MR. CURRAN: Far microphone.
MR. HAIN: Tony Hain, Cisco. I support, you know, 23 as written. I would support value of 1, absolutely agree with that. I would not object to a value of 2. I would object to a value any greater than 2. That said, I don't see David Conrad. I've been trying to -- oh, there he is over there, okay. We need a little bit of data cleanup. I would not be -- personally, I would not want to be the recipient of one /8. I think that particular /8 being counted as one of the last five would be problematic. And, you know, there may be some other cases like that that we need to clean up the data before we get below 10 because that last set of five may not be particularly useful.
MR. CURRAN: Okay. Would someone want to respond or clarify that point? Leo.
MR. VEGODA: Yeah, Leo Vegoda with David, ICANN. Yeah, 1 /8 is definitely going to be a little bit problematic. I made a little lightning talk about this yesterday or day before. And there's at least five or six of these problematic /8s. And there's probably a whole bunch of others which just not noticed. And there's an article that I wrote about this in the latest IPJ. But saying there needs to be some data clear-up, we can go and annotate -- I can do this this afternoon. I can put next to the entry in the IANA IPv4 registry, "This one's really horrible." But it doesn't help. So how can we clean it up because -- I mean David and I do a fair bit of travel already. But we probably don't want to go around everyone's private networks renumbering them.
MR. CURRAN: Okay. I recognize there might be some uncertainty on when the threshold's reached. I have Ray responding and then you can respond.
MR. PLZAK: What I want to do is add some clarification to this gentleman's agreement and it's been mentioned several times. What this gentleman's agreement is is that the RIRs agreed that regardless of the size of the allocation that they were entitled to, at the time they would receive only two. This doesn't preclude them from coming back very shortly later and asking for more. So in the example of the eight for APNIC, that they took two and they could be back very shortly and maybe ask three or four more times for address space. It's not a substitute.
MR. CURRAN: Understood. Okay, do you want to respond to the point made earlier?
MS. OKUTANI: Yes. Regarding that point that Tony has made, I can totally understand your sentiment. And just as a clarification, I suppose this -- it would be the problem that would exist anyways regardless of the method of distribution. Is my understanding correct?
MR. CURRAN: Would Leo or David like to respond? Anyone else like to respond? Okay, Randy.
MR. BUSH: Regarding the dirty /8s, why don't we assign them as the next assignment to the region that made them dirty? (Laughter) (Applause)
MR. CURRAN: Interesting idea. Okay, I'm going to continue on points at the microphone. I have Randy over here.
MR. BUSH: Since you asked, I think I finally began to understand and have sympathy with these proposals. I think it was mentioned that there was consensus for 1 in APNIC region. And I think that's quite reasonable. I would like to -- but Steve Ryan, in his usual lawyer 300 cannonball blast, came out and said why it was horrible at -- at five /8s per. And how does he feel about one /8 per?
MR. CURRAN: Steve, microphone.
MR. RYAN: As a point of privilege, Randy, why don't you try practicing the nice that you talked about earlier, okay. With regard to the 1, I don't have a legal objection to it because there has to be a way to allocate near the end, which is not inconsistent with all of the prior methods. It seems to me that the 1 -- there can't be a legal objection to it. You could have a policy objection. But I have no legal objection to it. I do continue to object to the 5. And I don't know about the cannonball blast, but it is my legal objection.
MR. CURRAN: Randy would like to respond. Hold please. Randy.
MR. BUSH: I don't think anybody's projecting a proposing 5. So --
MR. CURRAN: Okay, all right. Yes.
MR. GAGLIANO: Yeah, I would like to ask the counsel about 2, if he has any legal issues. The legal (off mike) and he mentioned maintains for 2.
MR. RYAN: So I think I've indicated why I believe that there is no legal objection at 1 and there is a serious legal objection at 5. I think it becomes a matter of slicing the salami. It's a lot better for -- in my judgment to be considering your proposal as amended at 2 than it was at 5. And I think it becomes a policy preference at that point between the 1 and the 2 as opposed to having a standing legal objection to it. I think the standing legal objection is anything over 2 because then you're getting into real numbers in terms of the allocation.
MR. CURRAN: Okay. We have far microphone, then center.
MR. SPRUNK: Stephen Sprunk, Polycom. Yeah, as far as support or oppose, I definitely support 1 and I definitely oppose 5. As far as 2, I would only support that if, you know, the other four RIRs all approve that and we were the last holdout. I wouldn't want to go forward with that, but I don't want to -- in the spirit of global cooperation, I wouldn't want to stand in the way and be the one keeping it from happening. I do have one other question though. Are there any other substantial differences between the two proposals besides just the value of "n"?
MR. CURRAN: Good question. Differences between the proposals besides the value of "n"
MS. OKUTANI: Our motivations are slightly different. But other than that, the actual implementation, no, there is no large difference apart from the number.
MR. GAGLIANO: Well, my understanding is a little bit different there. We don't include that statistic part. So we just think that's an operational issue, not policy issue. And secondly, the way it is -- the text is written, the way that it's going to be implemented. We do the reservation at the beginning in order to save us for the problem at the end, that problem than, you know, if you start allocating, you get an allocational request. You're still in Phase 1. You need to answer that allocation. And so you may get to Phase 2 with not enough /8s to give. For example, you may get to Phase 2 with three /8. So you will not be able to give one to each one -- to each RIR. So that's why we came out with this reservation idea. And -- yeah.
MR. CURRAN: Okay. Hopefully that clarifies. All right, center microphone, Jason.
MR. SCHILLER: Jason Schiller, UUNET, Verizon Business. I'm undecided on this policy. I think at the moment I'm favoring towards against. And I guess it's because of the definition of fairness, some of the things that you'd referred to earlier. It's really not clear to me what we're trying to do here in terms of making the run-out more fairer. And I have a clarifying question just to make sure that I understand the process. If "n" equals 1, the sixth /8 would be the last one that's assigned through the normal process. If AFRINIC was to get the sixth /8, then immediately IANA would turn around and give the last five /8s, one to each RIR. So AFRINIC would have two /8s, which would be, I don't know what, six years worth of space. And ARIN, if they ran out the next day, would get a /8, which would be, what, three months worth of space? If that's the case, I really have difficulty understanding why we want to engineer the run-out this way and why we think this is more fair than first come, first served.
MR. CURRAN: Response.
MS. OKUTANI: Yeah. With our case, our focus is not so much in fairness. We want to increase the predictability of the remaining address pool. So I do understand your point, but this is not the motivation behind our proposal with our site. And I'm sure Roque would have a different opinion.
MR. GAGLIANO: I agree. I don't talk about fairness. Fairness was raised by the comment on the ARIN staff for the first time. And I think what we're trying to get is let's get predictability on what's going to happen. And I'll tell you, with the current policy, ARIN may get zero and Africa two, yes.
MR. SCHILLER: So as to predictability, I think when we get within three months of the last assignment, if we're paying attention to this, it will be very predictable when we're going to run out. So I'm not sure why adding a three-month buffer onto the sliding window makes it anymore predictable.
MR. CURRAN: Okay. Do you want to respond?
MR. GAGLIANO: I didn't get exactly the --
MR. SCHILLER: So right now the scenario is we don't know when the run-out is going to happen. But we take five /8s and we put them into reserve. We still don't know --
MR. GAGLIANO: Five or 10?
MR. CURRAN: Five or 10, with "n" equals two?
MR. SCHILLER: Okay. Let me start with five just for this example. So we take five /8s and we put them into reserve. We don't know when the run-out is going to happen until we get down to five /8s. And at that point, ARIN knows we have about three months. Is that anymore predictable than watching the run-out as it's happening? Because I'm sure when we're three months away from the run-out, we can see the writing on the wall. I hope we're smart enough to be able to detect that.
MR. GAGLIANO: Okay, I got it. The answer is yes because, for example, there is discussion in different regions. Different regions want to set some policies about how to allocate that remaining /8. Maybe they want to get smaller, let's say -- allocation size for that /8. Maybe they want to get some soft landing. Maybe they want to reserve for critical infrastructure. But that -- the core allocation policy does not -- they don't do it because of some of the comment we receive here just because the other -- it's kind of like reward for utilization right now. So yes in that sense. On the other sense, it's also more predictable not only for us who are here in this room but for people who are outside this room and outside our community.
MR. CURRAN: Okay. Any further follow-ups? You've had --
MR. SCHILLER: Yeah, I just don't see how three months gives us a chance to change policy or to extend the runway or to give us more time to do something different than just run out.
MR. CURRAN: I'm --
MR. SCHILLER: And I guess my other concern is if you make it longer, then the inequity between the amount of time each of the RIRs has becomes greater. So -- and any of the legal issues.
MR. CURRAN: I'm only going to respond with respect to what I've heard. But one of the policies noted that if those five were reserved in advance, there may be RIRs that have distinct policies for how those work. ARIN could be one of the RIRs that has a distinct policy for how its last /8 works, which might not lead to a three-month completion. It's just what I understand from what I've heard. Yes, other respondents. Randy. Yes, Randy. Microphone please, far mic.
MR. BUSH: There we go. Randy Bush, IIJ. There was, I believe, as my aging neurons tell me, consensus in APNIC that APNIC would develop a special policy for that last bit. So regions -- you tell me something. Is that correct? Is my memory correct?
MS. OKUTANI: Yeah.
MR. BUSH: Yeah. Then -- so this is already being worked.
MR. CURRAN: And so to further respond to Jason, obviously, you couldn't develop that policy and know you'd be making use of it if you didn't have the reservation that you would get when we got to the threshold.
MR. BUSH: Bingo.
MR. CURRAN: Okay. So we have center rear mic.
MR. PATARA: Yeah. My name is Ricardo Patara. I'm from LACNIC. I was asked just to make a short statement. It is not my question.
MR. CURRAN: Of course.
MR. PATARA: LACNIC, and I mean its board and its community, think these policies are very interesting one, and also believe it's going in the right direction. And it's good not only for LACNIC or AFNIC as someone might think. It is also very good for every RIR at once. It's give more predictable future, how the end of IPv4 could be. Just a short statement.
MR. CURRAN: Okay, thank you. Follow-up, yeah.
MS. OKUTANI: Can I just clarify that earlier comment made on predictability?
MR. CURRAN: Sure.
MS. OKUTANI: If you consider predictability as the projection of one -- when the address space will run out, yes, I think the point is right. It doesn't really increase the predictability; the space will run out anyways. So the predictability we mean by this is that by knowing how much space is available, we know how we can distribute the remaining space. That's the kind of predictability that we are seeking; just a clarification comment.
MR. GAGLIANO: It could be we know that we're going to get something.
MR. CURRAN: Right. Rear far microphone.
MR. RICH: Yurie Rich, Command Information, I support these policies. As to the exact number, I don't know, I'm -- I guess, I'm not smart enough to determine that, but I would say that the -- I'm sure no solution is going to be the perfect solution. But if the world continues to work as it normally does, people will wait until the last minute to make change. And if we don't implement something, we won't have put into this process another step that notifies users that the end is coming. We could just end in a position where there just isn't anymore and then people have to scramble and fire drill and -- I think we need to be more responsible than that.
MR. CURRAN: Okay, I'm going to closing the microphones, please approach the microphones briskly if you need to comment. The far microphone Randy.
MR. BUSH: Randy Bush, IIJ. What we're talking about is that everybody has a chair as the Titanic sinks, that we're not playing musical chairs, okay. And in fact, yes, it's true that everybody's chair will not sink at equal rates. I don't want to go around measuring everybody's butt, right. I don't think it's worthwhile. I would note that it's likely that the inequity in burn rate is actually inversely proportional to the ease at which folk in that region will have to move to IPv6.
MR. CURRAN: Okay. Microphones are closed, center microphone.
MR. DICKSON: Brian Dickson, Afilias, again. Let me ask a question then about the idea of everybody getting at least one /8 and possibly more at the same time as a final allocation. The timing of such an allocation would have to be based on the run rate of the slowest user of space by moving back the clock to when their last /8 would be used up. If we move the clock back to that point in time, give everybody -- everybody's going to need at least one /8 from that point forward. Many will need more than an entire /8 possibly two /8s, maybe a fraction of a /8.
MR. CURRAN: I'll let the group respond, but I believe the trigger event that they wish to trigger, the allocation of the address blocks is based on a certain point of the available space not based on the run rates at all. Truly when the IANA's available pool is at a certain condition, we allocate the remainder; not based on run rate, based on hitting a certain free pool level, is that correct?
MR. GAGLIANO: Yeah, that's correct. I mean, the problem is (off mike) that kind of policy choose is going to have what we call, you know -- it's going to get like a real competition, it's going to be like Indy 500, you know, and that's my problem also with that kind of stuff. And yeah, what we are trying to say is -- we're -- the Phase 2 of our proposal gets activated when the remaining pool gets empty and that's when we allocate reserve space.
MR. CURRAN: Based on that understanding, do you support the proposals?
MR. DICKSON: Still abstain. I'm going to propose some detail --
MR. CURRAN: Okay.
MR. DICKSON: -- on the list.
MR. CURRAN: Far microphone. Last comment.
MR. ALEXANDER: Dan Alexander, Comcast and ARIN AC. I'm going to take both hats off and just give my personal opinion on this, because the comments in regards "n" being an integer or what should this number be. When we're talking about the large RIRs, we're really talking about a matter of months. So at that point, we're kind of splitting hairs here. And the ones who will really -- gain by this or be helped by this are the smaller RIRs. So at that point I say, "give it to them," and give them a couple of years, let them buy their time, because for a large RIR, that's going to go through an 8 and 3 months this is irrelevant. So I have no problem with one and I'm not even opposed to 2.
MR. CURRAN: Okay. Good comments. At this time we are going to wrap up discussion and we're going to move to a show of hands. I've been asked to -- asked this question in a very particular manner, we're going to have a show of hands, first for the whether or not you support a policy proposal for this distribution and that would be with values of "n" equals 1 or greater. You're -- so you're literally supporting the concept that we have such a distribution or not. When that is done, I'm going to ask separately for a particular vote on the policy proposal which has "n" equals 1 all in favor and all opposed, okay. Does everyone understand what I'll be asking? Okay, thank you. Okay.
MR. HOWARD: Would you repeat the question that you may ask --
MR. CURRAN: I will when I ask it.
MR. HOWARD: Could you repeat one more time before you ask it?
MR. CURRAN: Okay.
MR. HOWARD: It is not clear to me.
MR. CURRAN: Okay, thank you, Lee. It's not clear so we'll have to have a clear show of hands, so -- we're going to ask for -- first, everyone in favor of a policy proposal which allocates the remaining space in some manner between the RIRs which would represent either of these policy proposals. I'm going to ask for everyone in favor of that, and then I'm going to ask for everyone opposed. I am then going to ask on the particular policy proposal of /23, which is similar to the previous question only it is exactly with "n" equals 1 i.e. with five /8s being allocated.
MR. GAGLIANO: Are you going to ask for the other one too or just --
MR. CURRAN: No, I am not going to ask -- and I'm going to ask only for whether or not the organization is in favor of a even distribution system of some kind, okay. Yes, I'm sorry, far microphone.
SPEAKER: (Off mike)
MR. CURRAN: Far microphone.
MR. DURAND: Hello.
MR. CURRAN: Yes.
MR. DURAND: I'm afraid that your first question is a little bit ambiguous and loaded, because you could do with "n" equals 5 and the result will be very, very different, so I'm opposed to your first question.
MR. CURRAN: Okay --
MR. DURAND: -- if you were to rephrase your first question with considering that "n" should be 1 or 2 and no more then that would be a fair question.
MR. CURRAN: Okay. This is actually a very important topic, and how we ask the question can skew the result, so I actually am -- I'm going to turn to the policy advocates, how would you like the question asked?
MR. GAGLIANO: I think that what we want is to -- just to ask if we are in favor of the framework and I was -- I mean -- we discussed it -- we are in favor of such a proposal, and we know that the two options that are on the table today is "n" equals 1 and 2, and we know that both proposals has to go back to the list, because they -- the text has to be revised, and so I will be in favor not to go vote the particular one, but to vote the principle and if -- I don't think that's --
MS. OKUTANI: So Roque, if what you mean is to give the choice between 1 or 2 and not more then I agree with your comments, but if "n" is totally open -- it could be 3 or 6 then I don't think we should ask that question.
MR. CURRAN: So how's the --
MR. BUSH: John.
MR. CURRAN: Yes, recognized Randy.
MR. BUSH: Speaking as APNIC policy SIG co chair --
MR. CURRAN: Noted.
MR. BUSH: -- Randy Bush. It would be very helpful if we're trying to progress this multi region if you phrase the vote analogously to the way we did, because then we don't have to meet in the caucus afterwards.
MR. CURRAN: Elucidate --
MR. BUSH: And that was two separate votes. One, philosophically for this approach or not. Secondly, 1 or 2.
MR. GAGLIANO: Yeah, Randy, this 1 or 2 is not the same one policy against the other one, because there are also some small text differences that we --
MR. CURRAN: I think that there --
MR. BUSH: You can go and have dinner and argue the text differences out.
MR. GAGLIANO: Yeah, I know.
MR. CURRAN: Randy, thank you for that input. I think -- and I'm -- does anyone object to having a simple question that says, "Are you philosophically for this approach with the value of "n" being 1 or 2?" All in favor, all opposed. That would at least allow us to understand whether we should pursue this concept, okay. So we're going to ask for that vote. (Laughter)
MR. CURRAN: All those in favor of a philosophical approach to distribution as described by these proposals with "n" equals 1 or 2, raise your hand, nice and high. We have a count, thank you. All those opposed to the philosophy of this distribution with "n" equals 1 or 2 raise your hand. Nice and high. We have a vote, thank you. If you request, I will ask for another show of hands, you --
MR. GAGLIANO: Yeah.
MR. CURRAN: It's -- both of your -- both proposals on the table, if you request I will ask a show of hands specifically for "n" equals 1, if you don't request, I will not ask.
MS. OKUTANI: I'm fine with it.
MR. CURRAN: You're fine?
MR. GAGLIANO: I'm fine.
MR. CURRAN: Thank you. Okay, thank you everyone, we have the numbers. So the results of the straw poll; number of people in the room, 147. Are you philosophically in favor of a distribution system as described with "n" equals 1 or "n" equals 2? In favor, 69, against, 10, thank you very much.
SPEAKER: Thank you. (Applause)
MR. PLZAK: Okay, we're not going to do anything else more on the agenda today in terms of policy proposals, so reminders -- tomorrow practice is at 8:00, the meeting will start at 9:00. The agenda which is in your meeting program will obviously be revised so we'll do that overnight. Tonight is the social, it starts at 7:00. The balloon will not be rising tonight, because of the wind. Sorry about that. But for those of you in the room that are pilots they will know that and tell you that there are advisories about those things happening around this part of the country from time to time. So for that we humbly apologize. Anyway -- so at 17:30, go to the meeting registration desk and pick up your social badge, that's so you can be social and then at 6:00 the buses will depart. Bus will be in the front of the hotel, okay. Beginning at 8:00, the first bus will return and buses will return periodically with the last bus leaving at 22:00 hours or 10:00 o'clock, okay. So 8:00 o'clock, first bus returns, 10:00 o'clock, the last bus returns, and in between there will be buses going back. Okay, complete the survey and earn a raffle entry get a couple of winners ahead of us and let's thank our sponsor, it's been a good day for him. (Applause)
MR. PLZAK: And thank yourselves, because you're the ones that make this possible. And so we will see you tonight. And hopefully, you can make it back here tomorrow morning.
(Whereupon, at 5:19 p.m., the PROCEEDINGS were adjourned.)