Your IP address could not be determined at this time.

ARIN XXI Public Policy Meeting Draft Transcript - Monday, 7 April 2008

"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."

Table of Contents

Meeting Called to Order

MR. PLZAK: Good morning. Hey, we're awake. Good. Welcome to Denver. Welcome to ARIN XXI. The characters you see on the slide are actually part of the public art of Denver. If you wander around Denver, you will see all these things someplace out in the open, so if you get a chance to get out and away, avail yourself of it. We'll be showing you more of these figures as we go through the presentation this morning. So first of all, who's here? Well, we have the Board of Trustees, John Curran, Scott Bradner. Lee Howard is not here today; he had a last-minute personal matter he had to deal with. I'm here. Bill Manning, somewhere out there. Paul Vixie, up here, and Bill Woodcock, out there someplace. Ah, there he is. Okay, we have the Advisory Council, they are all here. So if I could have them all stand up please. And later on I'll tell you how I can find them.

MS. ARONSON: We're all right here.

MR. PLZAK: No, when you're not in this room sitting at a stage where they can actually throw stuff at you, they still will have to be able to find you. Anyway, so they are all here. I'm not going to go through the names, but please take advantage and talk with them. They want to talk with you. The NRO Numbers Council, three people, would they stand please? Jason, Marty, and Louis Lee. Okay. And all the RIR colleagues, you don't have to stand, but there's a lot of them here. We had an RIR board meeting -- not a real meeting, it was a workshop, if you will, on Saturday, so we've got people here from all the boards. All the RIR CEOs are here, so this is your chance to talk to people from the other regions to get a better feel and idea of what's going on in the other regions. And staff is here, all the directors, would they stand, please? And they also would like to meet and talk with you. And we do have one new addition to the staff, and that's Cathy Handley. She's our Executive Director for Government Affairs and Public Policy. She used to work with the Department of Commerce.

So let's welcome our first-timers. (Applause) They met the members of the board and the chair of the board and the chair of the AC and people from the Numbers Council staff yesterday at a first-timers luncheon, and they learned some things about ARIN and went through things yesterday. And they now get a chance to win something, so they completed a survey and so now we have a drawing for a prize. So you've got to be present to win. So Tom Byrnes -- Jim Byrnes? Okay. Jennifer Wagner. Too much foosball, I think. Ah, here she is. (Applause) And here it comes. No, it's not coffee. And it is a set of speakers. Jason. Okay, going on with who's here. Here's our attendance stats. We had 155 people registered, distributed as shown. Also, we've had 35 remote participants registered, and we have 55 people as first-timers. So welcome. Our sponsor, WildBlue. (Applause)

Now, you've all received a packet when you checked in at the registration desk. It's got a lot of things in it, and on the right-hand side, you'll see the discussion guide, which has the policy proposals and the policy process in it. You'll find a copy of the Number Resource Manual. You'll find the meeting program. And you also will find an errata sheet to two of the policy proposals. This reflects changes that were made after the policy proposal text was published. You'll see a little flyer, that says, "Get a Handle on IPv6." We did the pre-game show for it yesterday, and the main event will be on Tuesday. This will be an IPv6-only network. Give you an opportunity to go out and see if you can find sites that are -- which sites are IPv6 only. For example, you can go to the ARIN IPv6 site and see ARIN's WHOIS and so forth there, and anybody else you want to check out and see what your competitors are doing, it's a good opportunity. On the left-hand side, you see some information about other things that are going on. One of the things is we have Project X, which actually is a -- I'll go into it a little while later, but it's a demo of what we're working on for the improved website for interaction. You'll also see a call for reminding you you have a duty to vote and participate in the ARIN 2008 elections, and we've also included an update on our service levels. We have a service level commitment, and we periodically report to the community how we're doing. So if you have questions on any of those matters and so forth, please grab a member of the staff and we'd be glad to talk with you more about it. So the IPv6, the pre-game show was a success. A reminder is that the event -- the main event is from 5:00 to 6:00. As we said in the announcement, anybody that participates, we will have a small little goodie to give you. And you also should have a ticket, probably available soon, which is your ticket to the Project Live X demo. It'll take place in this room at 1:00 both today and tomorrow. That's the last half-hour of the lunch period.

Now, as always, we have the Cyber Café. This is your place to take a break, get connected. You can watch presentations there and you can get information, which leads me to surveys. We will be asking you questions throughout the meeting, and we do this in the form of little paper surveys. And to help you to be motivated to participate, we bribe you, because everyone that submits a survey gets put into a drawing for prizes, and there is a prize drawing at each morning and afternoon break. There are two names drawn at each break. You must be present to win. If your name is drawn, then you either get the chance to play the Wheel of Fortune or Plinko to determine what prize that you're going to win. At the end, we will have a meeting survey, and the prize for that is an Optimus Mini Three Keyboard. We'll announce the winner of the meeting survey on April 18th on the ARIN website. So there are a lot of opportunities for you to participate in surveys and give us feedback and information that we're looking for. But there are a lot of people that aren't going to win anything. Well, it ain't over until the swag is in the bag, guys. So we have a consolation prize. Any first-timer or Cyber Café. entry or meeting survey person that didn't win a prize at the appropriate drawing is placed into a drawing for a consolation prize. The consolation prize is this Apple TV. In the end, you can win by losing, okay? How about an "ah" to go with that "oh?" Beautiful. Okay. So that winner will also be announced on the 18th of April on the ARIN website.

We have three help desks. We have the billing help desk, the registration services help desk, and the Advisory Council will be conducting a help desk as well, and the dates and times are shown there. The registration services and Advisory Council, in addition to regular hours, are also available by appointment as is the billing is only by appointment. And if you want to make an appointment, send e-mail to the appropriate place. But, I've said before, if you want to find an AC member at lunch, that's a good time to get them, when they're feeding, you know, at the waterhole and so forth. Well, we tagged them. So at lunch, each AC member will have a tag sitting like this on a pole at the table where they're sitting, so if you would like to sit down at lunch with an AC member to discuss something, this is how you find them. Okay? It's a good chance for you to network with the AC and to provide your input into the policy process, your feelings, and so forth, so please have a good lunch with an AC member. They're friendly, they don't bite. Well, not all of them, not much. And those that do, not much. But bottom line is, they're here for you.

So foosball last night, third place trophy went to Scott and Scott. The second place trophy went to Oscar and Tom. The first place trophy went to Phil and Nick. (Applause) And the most coveted trophy, bringing up the rear, went to Nigel and Bernadette. (Applause) So congratulations to all of our trophy winners, and we hope you all come back next year. For those of you that want to practice up a little bit for next year, there will be foosball tables at the social for you to sharpen your skills a little more, or to seek revenge for that bad shot that happened where someone did something to you. So the social is "Death for Dinner." We're going to paint the town red. It's going to be a murder mystery. So was it Richard in the Cyber Café. with a Cat 5 Cable. Find out tonight. There's going to be food and beverage. There will be a buffet dinner, two open bars. We'll have a signature cocktail called the "Crime of Passion." For entertainment, we'll have a DJ and dancing. We have a game room. We'll have the "Death for Dinner" murder mystery play. And for those of you that are interested in basketball, I believe we're going to have a big-screen TV there for you to watch the Final Four. So something for everybody, I hope. We hope you're there tonight. It's a good chance to network with the people that are here at the meeting and have a good time.

On to the business of the meeting. We have rules. They're explained in your meeting packet. And I'm not going to go through them, just remember there's 10 of them. It's designed to give everyone the rights that they have, which is the right to speak, the right to be heard. So it's just as important for you to have the freedom to express yourself, but it's just as important for the person who's expressing themselves to be heard. And that's what these rules are designed to do, and the chair will enforce them. Let's look at what's going on. We'll have our regular reports from the RIRs, global stats, a Regional Policy Development Process Report, reports from the NRO Executive Council, the IETF activity report, and a report from IANA. Looking at the agenda, there are three proposals that are related to the IPv4 depletion. There are two that are related to IPv6; plus, there's also the IPv6 main event tomorrow afternoon at 5:00. We've got three other proposals that don't fit into those two categories. And we've got some special reports -- one on Internet governance activities, one's a result of a IPv6 penetration study. As most of you are aware, a while back, we conducted a survey of how IPv6 is being used, and this will be the report of the results of that survey. Then we have an interesting talk this morning about the adoption through the lens of economic security, IPv6. And then Tuesday afternoon will be a discussion led by Scott on the revised IRPEP. And a reminder, Wednesday morning is the members meeting. It's open to all. So don't miss the Project X Live Demo. Don't miss the IPv6 Main Event. And don't miss the social tonight. So at the head table this morning, we've got John, Scott -- in for Lee is Paul Vixie down there, not to be confused with the other Paul who has the privilege of sitting next to Cathy, and Dan.

Regional PDP Report

MR. PLZAK: And so now on with the show. And the first item of business is the Regional Policy Development Report. That will be presented by Einar.

MR. BOHLIN: Thank you, Ray. Good morning, everyone. I'm Einar Bohlin, the policy analyst at ARIN. And this is the Regional PDP Report, the Policy Development Process Report.

MR. BRADNER: Pretend you like the microphone.

MR. BOHLIN: Thank you. This is a worldwide look at all the proposal activity at all 5 RIRs, and so there's about 25 right now, different proposal themes. We've got it broken down into four categories: ASN, other, IPv4, and v6. And within those themes, we have some sub-themes or sub-topics. So I'll just go quickly through these. The ASN proposal is the global proposal about allocations from the IANA to the RIRs. And I think, it's recently been sent to the ICANN board, and the next step for that is the ICANN board to review it and adopt it. The other category is things such as directory services or policy development processes. In the v4 category, there are about -- well, there's nine proposals. The number in parenthesis are ARIN proposals that we're going to see here at this meeting this week, so if I go back to Other for a second, there are two proposals in that category, there are four proposals in the v4 depletion category, which is about the run-out of the IANA free pool. One of those proposals that we don't have, just to mention, was that APNIC recently, and it concerned the creation of an additional /8 to add kind of to the RFC 1918 private network space. And in the APNIC region that was discussed, and it was ultimately abandoned, and they suggested that it go more through the IETF process perhaps. There was a proposal also at the APNIC region about the minimum allocation size, and it looks like they're moving their minimum down to a /22. If we go to v6, the most number of proposals is about the topic of promoting the adoption of IPv6. We have two of those on our agenda this week. A couple other ones in there, there's two at the RIPE -- in the RIPE region, one of them would have the RIPE NCC allocate v6 space to every existing LIR, and it would also -- there's another proposal that would have the RIPE NCC assign v6 base to every INET number holder. And that's kind of RIPE-speak, so translate that into ARIN language, it would have -- a similar proposal would have ARIN assign v6 space to everyone in WHOIS, and allocate v6 space to everyone in WHOIS. I think that's it for this slide.

These are the eight policy proposals that are on the agenda this week. The purpose of this slide is to show you what kind of discussion, if any, might be happening outside the ARIN region. So for example, the top proposal there is the global proposal about the end of the IANA free pool. And it's a global proposal and it's under discussion at all five RIRs. The second proposal there, the transfer policy proposal, has a similar proposal in the APNIC region and the RIPE region, and they are discussing this idea in LACNIC, although there is no formal proposal as of yet. The third item is the cooperative distribution of the end of the IPv4 free pool. This is sort of an inter-RIR proposal. It would require at least two RIRs to adopt it for it to work, and it was recently presented at APNIC and abandoned. It will be presented at AFRINIC and at the next RIPE meeting. And the rest of the proposals, the other five there, are ARIN-only proposals. They're not really being discussed outside of our region. Here's some references. If you want to see really what's being discussed at the other RIRs, you can go to these sites and find a list of their proposals and what state they're in, are they under discussion, last call, withdrawn, abandoned, et cetera, and I'd like to point out the last item there, which is the policy comparison overview. The other day, somebody asked me what was the minimum allocation size at LACNIC? And I sent them to the LACNIC site. And then I remembered a better thing to do, when they called me and they said they found that, what's the minimum size for RIPE, I thought a better thing to send them to is this comparison document. Because if you want to be able to compare RIRs' policies very easily, you can go to this document and see, for example, all five RIRs' minimum allocation size or their initial allocation criteria. It's a very nice document, and we update that about four times a year. Thank you.

MR. PLZAK: Anyone have any questions of Einar? Okay, thanks, Einar.

Internet Number Resource Status Report

MR. PLZAK: The next report is the Internet Number Resource Status Report, presented by Leslie.

MS. NOBILE: Good morning, everyone. This is the NRO Joint Status Report. It is all five of the RIRs, who compile their statistics together and show them in a side-by-side format, as well as giving current status on v4, v6, and ASN numbers. It's prepared quarterly, so this was just updated on the 31st of March. We're going to start by looking at the total IPv4 address space and the status of each of the /8s. If you look at the left, the doughnut or the pie on the left, that's the total space. I'd start with a green, the not available space, there's 35 /8s held by IANA and the ITF for special purpose. There's 16 multicast, 16 experimental, and one each for private use, loopback, and local identification. If you go up to the left, you'll see central registry space. Ninety-one /8s were issued prior to the establishment of the RIRs. This was issued by the DODNIC, the SRINIC, the early days of IANA. Moving down to the blue, the RIRs in total have 89 /8s issued to them that they are currently issuing to their customers or have issued. So if you look at the bottom pie, the breakout of how the /8s to the RIRs are broken up, you can see how many /8s each of the RIRs have currently or have issued previously. Moving to the gray part of the pie, which is probably most interesting for most people, it shows that there's currently 41 /8s left in the IANA reserves. That is space that the IANA will issue to the RIRs for the RIRs to issue to their customers. So 41 left out of 256. This slide shows the IPv4 allocations from the RIRs to their customers, to the LIRs, and it's allocations only, not assignments. We started in '99. We took a slice from '99 through 2007, and you can see the growth trends up and down. The thing to take out of this, for me anyway, is the growth currently is in the APNIC region. APNIC and RIPE have been issuing more IPv4 space than any of the other three RIRs, particularly APNIC over the last year. They issued more than 4 /8s to their customers. That's the first time any of the RIRs have issued that much space. This is just this first quarter. We broke it out because it was getting lost in the previous slides, so this just basically supports what we've seen since 2007, with APNIC issuing much of the v4 space.

This is another way of looking at that slide. It's a cumulative total since 1999, how much space each of the RIRs have allocated to their customers, to their ISP LIR customers. And you'll notice that since '99, this cumulative total, APNIC and RIPE both have issued more space than ARIN. Previously, it was flip-flopped and ARIN had issued more v4 space, but at this point, the other two RIRs, the two larger RIRs, are issuing more space. This is the ASN assignments from RIRs. It says to LIRs -- this is actually incorrect. I have to get this changed. I'm sorry. It's to all of our customers. It's ASN assignments to all customers. It's end-users and ISPs. Again, up and down, ARIN was previously issuing quite a few ASNs. We've pretty much become static over the past few years, but the RIPE region has increased their ASN assignments, and the other regions, pretty static. A little bit of growth in APNIC and LACNIC as far as ASN assignments go. Again, this is just the first quarter, pretty much supports the previous slide. And this is the cumulative total, so ASN assignments. ARIN has issued more ASNs than any of the RIRs, but RIPE is following close behind.

This is a look at the total IPv6 address space. We started on the very left with the total pool. A /3 of the space is actually global unicast space that the IANA holds in reserve. That consists of 506 /12s. If you look to the right, each of the RIRs received a /12 in October 2006 as a result of a global policy. In addition, from that little blue slice, if you look below, prior to getting these /12s, the IANA was issuing /23s to each of the RIRs on an as-needed basis. So you can see that RIPE had gotten 15 /23s, APNIC 7, ARIN 5, AFRINIC 1, LACNIC 1, and 3 had been reserved or set aside for special purpose. Most of this space, most of these /23s, came from the larger /12s. When IANA did issue us the space, they gave us each a /12 based on what we had been previously issued in 23s.

This slide shows our allocations to our LIRs' ISPs, since '99, which was when we first started issuing v6 space, and again, kind of up-and-down growth. There was steady growth for a while and then a little bit of a decrease in some of the regions, but the large green bar is showing where much of the demand is for IPv6, and that is in the RIPE region. We're also seeing, though, an increase in LACNIC. If you look from 2005, 2006, and 2007, there's been quite a bit of growth in v6. In the LACNIC region and ARIN in 2007, we basically -- we more than doubled the amount of allocations we issued in v6 over 2006. So we've seen quite an increase in our requests in our region. Again, just the first quarter of 2008, with RIPE NCC issuing quite a bit of the v6 allocations. And this is the cumulative total. So we did two things here. On the left pie, it pretty much supports what we showed, cumulative total of number of allocations. And it's pretty consistent with what we saw, RIPE issuing more, APNIC and ARIN pretty even in the number of allocations, followed by LACNIC and AFRINIC. But when you look on the right, we actually counted the number of /32s that have been allocated, and when you look at that, it's pretty clear that RIPE and APNIC are issuing very large allocations, much larger than the typical minimum allocation size of /32, so there's many times when they're issuing /25s, /22s, /28s, and that counts for those large green and yellow areas. AFRINIC, LACNIC, and ARIN have issued very few allocations larger than a /32.

All of these stats are on the websites here. The raw data is on the links below, and the RIR stats, this presentation, is kept on the NRO site. And that's all I have. Are there any questions?

MR. LEWIS: (inaudible) numbers in the future (inaudible).

SPEAKER: Get closer to the mic.

MR. LEWIS: (inaudible) also associated with (inaudible).

MR. PLZAK: Just to be clear, Ed. You want to see the legacy address space broken out by region where it's residing?

MR. LEWIS: Right, (inaudible) years ago and I think each RIR should (inaudible).

MR. PLZAK: Well, the ERX project was revolved around distributing the DNS responsibility. Okay. But I just want to make sure that what you want to see, by region, is the legacy address space that's resident in that region.

MR. LEWIS: Right.

MR. PLZAK: Okay.

MS. NOBILE: Thank you.

RIR Update - AFRINIC

MR. PLZAK: We're zooming right along. Adiel, you're up. Next is the first of the RIR reports. This is the AFRINIC report presented by its CEO. And so, bon jour, mon ami.

MR. AKPLOGAN: Thank you, Ray. I will quickly take you through our activity report. It's a brief report on what happened in our region during the last few months. Since we started our activity, training has been one of our priorities, because we need to raise more awareness among our community around IP resource management, so this is how the map of the region looked like in terms of training coverage. What you have in orange is a country where we already had training activity. And our training program has evolved also a bit. We have added some other technical training such as DNSSEC and IPv6 to our training program. So we have LIR, IPv6, and our DNSSEC training. What we have in green are countries where we are planning to have training this year. We already started, actually. A few of them are becoming orange, also. So mainly, our goal is to cover the whole continent both on LIR training, and more importantly, IPv6 training. The result of this training activity and awareness activity is also seen in the growth in our membership, growth in terms of membership, also growth in term of allocation in the region. So since 2005, that we start our activity, we have more than 100 percent growth in our membership. Those new members are mainly new operators, but also people who were using IP address from their upstream provider and now are moving to become LIRs. And this remark is being accentuated this year. We are also seeing a very big growth since 2008.

This chart shows the IPv6 growth in the region since 2005, again, since AFRINIC started activity. This is up to December 2007. This year, we have allocated about 10 new IPv6 prefixes in the region, which also shows the interest that we are getting in the region in terms of IPv6. But one of the issues which is still there is the real usage of the IPv6 that have been allocated by AFRINIC. We are now at around 30 percent announcement of the prefixes allocated from the region, which is not that bad, but we want to -- we are working to increase this number by providing a direct support to LIR on how they can set up just like in (inaudible) how they can work with their upstream to announce their prefixes.

We have also reviewed our fee schedules since last year. We have -- for instance, for IPv6, we have renewed the waiver of the fee for IPv6 allocations to already existing LIR. We have also rearranged the fee for new LIR. That's our only IPv6 user. This category is mainly for legacy IPv4 holders that want now to have IPv6 address so they have to become LIR, and we have also set up a special fee structure for them. We had also some discussion with the academic and research sector in our region. And we have applied since 2008, January, a discount for allocation and mainly assignment to education and research network. More generally, we have reviewed also our fee schedule for LIR, mainly reducing for small area.

For those of you who were at the Durbin meeting, we have launched our LIR portal, "MyAFRINIC," which is an online tool to allow members to access and manage our resource. Since then, we have had success in the usage because up to now, we have about 200 people registered to use MyAFRINIC, which is way more than 60 percent of our membership, all our members. This portal also allows members to pay their bill online directly by credit card, and we are working now to improve this first version of MyAFRINIC and add (inaudible) future, which has been asked by users. But globally, it is helping, and where it's helping also is the new member process, because the MyAFRINIC portal improved the new member process, which makes a few thing automated. And since January, we have noticed that the membership, at least the request to become a member, has grown, and it will probably have an effect in our growth.

Policy in our region, a few policies have been ratified recently by the board. The new policy development process, we have now reviewed our policy development process to make it simpler, and have -- one of the main things we have set up is the moderator group, which is a group of people volunteering from the community that show -- moderate the discussion online and also try to initiate policy and help members to participate to the policy development process. The global policy about ASN allocation from IANA to RIR has also been ratified by the board. Two policies have been withdrawn from the discussion. The global policy for allocation of the remaining IPv4 space, the first version of this policy has been withdrawn, but the new one has been introduced on the mailing list recently. There are two policies that -- for that, the use of the latest /8 block from IANA to RIR. There is still the IPv6 (inaudible) central policy which is still on, not withdrawn yet, so that is it. I know that there are a few policies that are coming before our meeting in Rabat next month. That is it.

A few information about our upcoming meeting. The next meeting will be in Rabat from the 31st of May to the 6th of June. It is a meeting that we have every year back-to-back with AfNOG, which is the African Network Operator Group. Our second meeting this year will be in Addis Ababa, Ethiopia. And it will be back-to-back with our fourth African IPv6 Day, and it's scheduled to be from the 8th to the 12th November of this year, so you are all invited to that meeting. That's it. Is there any question? I will be happy to answer. No. Thank you. (Applause)

IPv6 Penetration Study

MR. PLZAK: We are way ahead of schedule. So kc, are you ready? You have a lot of time, so you can talk real slow. Okay, how many of you would like to see kc get her speech rate down to 100 words per minute?

MS. CLAFFY: I know. Me, too.

MR. PLZAK: So this is a -- I'll let kc explain the purpose of the survey and so forth, but some very interesting results, I think, that you're going to see here, and some interesting insights that she has to offer. kc?

MS. CLAFFY: How many people in the room filled out the survey? Okay, so the survey may not at all reflect the statistics of the people in the room if we've surveyed you. How many organizations represented here are profit versus non-profit? Profit first. I mean by design, not by implementation. Okay, so that's still less than half. So as Ray said, ARIN and I put together a survey a month ago, sent it out, gave two weeks for responses. We thought if you weren't going to respond in two weeks, you probably weren't going to respond, so the good news is we did get some empirical data. The bad news is I kind of learned that we need to rewrite the survey better. But the good news is, you guys really taught us how to write a survey because you put a lot of responses in the "Other," make a comment here, that really explain how we should have written the questions differently, if we should have written the questions differently.

So the survey was sent out March 10th, got responses by March 24th, so again, we didn't have a lot of time to do analysis on this stuff. But fortunately, the survey software that ARIN used, called "Survey Monkey," does a lot of the work for you. So we sort of extracted the big picture of questions that we could extract, and more importantly, as I mentioned before, we got a lot of better ideas about how to rewrite this survey to get better answers next time. So 347 people responded. Only 247 or so made it back past question 5, that actually has an allocation from ARIN or participating IPv6. So I will just go through an overview of the survey. I already went through the dates and the goals. I'll give a demographics of who was responding to the survey and again, the two goals were sort of captures from date on penetration. Now, you guys may be aware that a few -- last year, Brad and the measurement group at CAIDA tried to do our own measurements, active measurements of IPv6 reach ability, and Brad may have posters. Brad, do you have posters? Brad's busy. Do you have posters? So we did some posters that we'll hand out that is similar to the AS core posters that we've done in the past, but we compare our IPv4 measurement to the IPv6 measurement. Unfortunately, it turns out to be pretty hard to measure IPv6, as you all are probably well aware, more than I am even, the same ways that you measure V4, because the address space is enormous and you don't really have a set of target destinations to do "probing to," "given to," but we did "probing to" all the prefixes that were allocated by ARIN. So that's sort of the measurement side, and to be honest, the results of how many people were at a point in v6 from observable measurements that we could take from outside, from the periphery. Where we measured was kind of disappointing, so we spoke with ARIN and decided maybe there's some other way we can get measurement data or empirical data about IPv6 deployment. Because we're pretty sure there's deployment out there, we just can't see from ICMP or whatever tracer kind of activity we're doing. So that's one of the goals of this survey, and the other one is just to capture community input on what are the hurdles to deploying v6 if you're not deploying. I've done informal surveys over the last two years when I come to the meetings and ask you guys in the hallway, okay, what's really going on? Why aren't you deploying v6? And I can't say there are a lot of surprises in the responses to this survey. Some of them codified what I had learned from you guys before, put some empirical data underneath it, and there were a couple of things that hadn't captured before.

Who responded to the survey? So we had 75 percent of the respondents, again, this is the 350 number, the big number, 75 percent were in profit and 26 percent were non-profit, and we broke down the profit and non-profit further into these categories listed here. So a vast majority of non-profit is obviously the dot-coms, but there were representatives of others in there. And again, some of these questions, we will word better next time, because you have some things like some government in the for-profit category, but that means they're serving the government, serving government customers, because the question was ambiguous. And then non-profit, again, the vast majority of the non-profit respondents were education,.edu sites, and then some.gov sites and some other folks.

So this is the sort of gun-shy picture of who's deploying v6 and what kind of v6 are they deploying if they're participating in v6 now? And if they're not, but they're planning to, how far in the future are they planning to deploy v6? So the kinds of v6 deployment we queried about were: Are you doing it internally? Are you participating in IPv6 peering? Are you providing transit? DNS services? Supporting desktops v6? Supporting web services, hosting services, e-mail services, and cable? So we ordered this in order of who's actually deploying v6 now. And the other bars in this chart are deploying it in the next six months, the next one year, one to two years, more than two years, and then no plans to deploy it at all. So here's the unsurprising part of this: If you are participating in v6 deployment, you're probably just doing it internally right now and testing it on your own just to make sure things are working. And we allowed people to respond in free form, you know, later on in the survey, if you're not deploying v6 or if you've participated in one kind of deployment, but haven't extended it to providing it to the outsiders, why not? And a lot of the responses were, well, we don't have upstream transit, or there's business logistics we haven't been able to figure out to get the coordination with other ISPs, but internally we're deploying and everything's working. I was surprised. There were quite a few people that were participating internally. Again, this is the kind of stuff we're never going to capture with measurements that CAIDA's able to do from the outside. Peering, a little bit less, but still quite a bit of peering. Transit, even less, and then the hosting. That is the content providers, DNS host content services, DNS hosting, desktop web services were the middle tier of participation and deployment. And then the very last people who were even thinking about v6 at all is anybody that serves residential end-users or, really, the little guy. I guess I kind of would have answered that if somebody pressed me on the issue, but it's pretty stark data here. In fact, that cable DSL, the little purple in the cable DSL, is really survey noise, and you should just assume that the answer is zero there. Nobody who provides cable and DSL services to end-users is thinking about IPv6. The one person who responded there is a university who provides DSL customer service to home customers. He may be in the room. They may be in the room. And then I went through and tried to figure out which parameters matter. Are you more likely to deploy v6 if you were in one of these subcategories: One, profit or non-profit; two, size of your company; number three, if you're an ISP or an end user, an end receiver of the allocation? Does anybody have any guesses about whether any of these parameters matter? And if so, which ones? You can't say if I told you last night, by the way, but anybody who I didn't talk to last night. No? Nobody has any idea? Come on, you guys are on the pulse of the Internet here. If you don't know -- all right, that's good. That's good we did a survey.

So we divided these three parameters, right, profit/non-profit, size or your company, and whether you're an ISP or not, whether you're providing network provision service. And then I divided them into this graph. So these three separate sets of bar charts here are really the three separate parameters. On the left, profit or non-profit. Now, in this graph, unlike the other graph, we're just -- the top is 100 percent. We didn't plot the actual absolute values. However, we put the absolute value in parenthesis at the bottom that you can barely see, and it's order of 200 respondents total. Again, 100 of them had no IPv6 allocation and never got past question 5. Here, I see that profit/non-profit actually matters. You're twice as likely to deploy IPv6 if you're a non-profit, and that includes .edu sites. So I was actually surprised to see a lot more educational IPv6 deployment than I expected and government, which I was not so surprised by, because I know about the DoD mandate and such, and in fact, that was cited in the responses as to why we're deploying IPv6. In the second one, it looks like there's no real correlation between the size of your company and whether you're likely to deploy v6, and the third one also, it seems kind of iffy. To be honest, I don't trust the amount of data that we had here, especially in later questions, but it looks like not too much of a difference whether you're an end user, that is an end receiver of an allocation from ARIN or a network service provider on whether you're deploying IPv6. I'm sorry, that was for internal IPv6, so that was the very left-most bar on the first bar chart that I showed you. The second type of deployment we wanted to look at, too. In terms of deploying IPv6 transit, are you more likely to deploy IPv6 if you're profit, non-profit, small, big -- small, medium, big company, or a network service provider or an end user, end receiver of an allocation? Okay, and again, interestingly enough, the results are consistent here. You're more choice is more likely to be deploying IPv6 transit if you're a non-profit. Size of your company doesn't seem to make a big difference, and whether you're an ISP or not doesn't seem to make any statistical difference there. Third, web IPv6. Do you have an IPv6 reachable website, assuming you had IPv6 transit? So a lot of people would say I have an IPv6 reachable website, but I don't have transit for it. Again, consistent. In fact, very consistent with the internal deployment, more than twice as likely to deploy if you're a non-profit. Size of your company doesn't seem to have much of an impact, although small and large companies are more likely to be playing than the medium-sized companies. And ISPs and end user, again, I wouldn't trust that data because of the low number of respondents. Cable/DSL, again, stark difference here. Again, nobody's thinking about providing cable and DSL deployment for IPv6. Now, maybe that makes sense because those are the eyeballs and the eyeballs don't really need to be supported until the content's out there, and maybe that's consistent with what John Curran thinks is going to happen in the deployment transition, I don't know. None of this stuff, by the way, is inconsistent with his Internet draft on when people should deploy anything, so we might be on track with John's plan.

If you're not deploying v6 or if you tried it and you stopped deploying v6, what are the hurdles that you consider in your deployment? Now here, we let people pick more than one, check more than one box, right, but just order them in the rank order of how many people checked the box. Now, a lot of these categories you might merge into one, like we don't have a business case for it. There are a lot of things underneath the number 1 that you might argue about business case, but let's -- like user demand, but we'll go through this. The biggest category by far is business case, and in 2005, when I gave a talk up here about this similar thing, I called it incentive. The two real reasons that people aren't deploying v6 is they don't have incentive and they don't have capital. Now, the slide I shot up two and a half years ago was of the for-profit companies that were deploying v6, and I showed all the numbers in red that said, look, these guys aren't even making positive earnings. So why do we think they're going to spend their money on IPv6? That is particularly consistent with what we're seeing here, which is that in fact, the for-profit companies are not as likely to be deploying v6 as the non-profit companies. Business Case No. 1, vendor support, back office, and we've got quite a few detailed responses on what that means, what vendor support they're not getting. So that might be useful for ARIN to codify a list of things that the ARIN members say are not being supported by the vendors. No. 3 surprised me because I guess maybe it's the kind of people I talk to at ARIN, but I didn't get a lot of education as the reason that we weren't deploying -- as a hurdle to deploying v6. Now, you could argue that education isn't really incentive because you could put a person on at the top and get them trained up, or education might be capital because if you thought it were important, if you had a business case, you could buy a person. But nonetheless, education was on here quite a bit, more than it can be written off as negligible. So there might be a role for ARIN there, too, although my perception is that ARIN's pushing pretty hard on the outreach. User demand is really business case. Upstream transit is, again, to the extent that you can point to a third party and say, hey, it's not my fault, they're not giving me what I need to do. IPv6, there's quite a bit of that. Dual stack interoperability, multi-homing, so those two were really technical issues. And again, the lesser of the hurdles, or the technical hurdles. That may not surprise folks. Allocation policy, very few number of people that said the allocation policy is the reason I can't get an IPv6 allocation, and some of the people that did say that wrote in the free field that they really haven't tried in a year. So I know that ARIN has been responsive to the fact that allocation was considered difficult a couple of years ago, and so this needs to be retaken with folks who have tried recently, I think. And then performance, meaning IPv6 performance, on my routers isn't as strong as IPv4. That's hard to believe at this point, because plenty of people responded in the free form fields that performance is not a problem at all. And then, again, hurdles to getting an allocation. If you haven't even gotten an allocation yet, why not? No. 1, really you could call it incentive. It's not a priority, we haven't gotten around to it yet. No. 2, we don't have the infrastructure to support it. You could really call that incentive, too, or business case. Same with "Do not see the need." No. 4 is upstream transit doesn't support v6. No. 5 is the economics. And No. 6 is the policy issue, cannot get an allocation. And then there were a bunch of things in "Other" that really when you drill down and look at them, they belong in one of the other categories. People just didn't want to commit. And then there were a bunch of free form.

And I really want to thank, I guess not the people in the room, because very few of you filled out this survey, but next time we do this survey, please fill it out and please feel free to put comments in the "Other" thing because those were really helpful. And also, if you want questions answered that you didn't see reflected in this survey, in these survey responses, talk to me or Nate or send mail or we can discuss it on the ARIN discuss list on what you would like to see answered. But here, let me tell you three of the interesting quotes. This one sort of really had me stop dead in my tracks because it's quite consistent with what some of you guys have been telling me in the hallway, and yet I never see it up on stage. I never see it set up on stage. "We've actually seen a decline in the perceived need for v6 over the last few years. Very few have bothered with implementation. Those like us who previously had started to contemplate plans have basically shelved them because there isn't a push for it from users or upstream ISPs. There isn't a demand for its services." I think that's a typo and it's over IPv6, "Other technologies seem to have diminished the need; NAT, virtual hosting, too many other projects that have a much higher priority. The only place with any sense of gloom and doom about not implementing IPv6, quite frankly, is on the ARIN PPML list. I don't get the same urgency from any of my colleagues at other institutions or from our providers. It's that simple." Respondent No. 8. And then let me just do the other side of that, which talks immediately about the technical issues, the vendor support issues. "Management support for v6 is in name only right now. Sure, v6 addresses an ACLs supported in IOS, but you have to purchase the expensive, advanced IP services images, not the regular base one. Even then, supports from command line only, no GUI support for an IT guy who wears multiple hats, who can't all be command line jockeys. Lastly," and then we go jump right back to incentive, "why should I go to the trouble of implementing IPv6 if none of the big guys has yet? If neither CISCO, Microsoft, Intel believe in IPv6 enough to have quad-As published, why should I?" And then the last of the quotes that I pulled out, "Our customer base is all either not ready or not capable of v6. Our back one is ready, but the business drivers are not present." Very consistent with what I have been hearing for the last couple of years and what you guys would probably say. And that's all I have for reporting on this survey. I guess I can open it up to questions. And the "Survey Monkey" software is really pretty nice because you can filter on who answered yes to this question and what did those people answer to this next set of questions. So I can even answer more questions that you might have now without doing another survey, probably.

MR. HUGHES: Hi kc, Aaron Hughes. One comment about the size of company, and I think it's actually relevant about why lots of companies don't have quad-A records. Your.org, and I think Google, did a study on this where they inserted a .gif that was v6 and they found that .038 percent of users have broken v6 and look up the quad-A record and can't get to the site, which may not be a big deal for a lot of us small sites, but for someone like Google, .038 percent would cause a lot of screaming.

MS. CLAFFY: Yeah. A few billion dollars, right? A minute? Right. Yeah.

MR. HUGHES: I just think it's relevant for the size of company issue. In fact, Steve Wilcox did a presentation on it at GPF last week as to why they weren't adding quad-A records.

MS. CLAFFY: As to why?

MR. HUGHES: Why they weren't adding quad-A records to "www." Instead, they created IPv6.google.com because of that brokenness.

MS. CLAFFY: Yeah, it's interesting. I guess there's an IPv6.google.com you can reach now only if you have IPv6 connectivity. Do folks know about that? And you can't reach it over IPv4. And Google actually had a workshop that you may have seen about, they put it all -- the video all online. Vint Cerf was the MC. It was sited from Circle ID as a blog kind of thing. And I actually found it a pretty interesting workshop because the guy who was in charge of, like, getting Google working, the Google IPv6 working, Lorenzo, who was at RIPE for many years, actually, got up and just was into the faces of the people that were trying to push IPv6 deployment, saying do you seriously want me to put up an IPv6 service that's really billions of dollars an hour, or whatever, millions of dollars an hour -- he didn't have numbers on that -- and tell my upper management, that oh, yeah, we need to be on the blazing trail and make sure this stuff is out because if we lead, others will follow? It's not a good argument, it turns out, with upper management at Google.

MR. LEIBRAND: Scott Leibrand. ARIN AC Internap. I'd like to challenge your interpretation of the cable/DSL stuff.

MS. CLAFFY: Oh, good.

MR. LEIBRAND: I got the impression from my vague recollection of the survey that we were asking everyone if they were deploying cable and DSL, not asking cable and DSL providers if they were deploying v6. And I think the distinction is that you have a whole bunch of people who just don't do cable and DSL, so those numbers look really low; whereas if you were to look at the companies that actually do cable and DSL and see whether they're doing v6, I think you'd get a picture that doesn't lead to your interpretation of cable and DSL providers are not going to v6, but rather just the fact that cable and DSL providers didn't respond to the survey.

MS. CLAFFY: Fair enough. Exactly. And we could drill down to a little more of that. Yeah, that's a very good point.

SPEAKER: The first graph just wasn't normalized --

MS. CLAFFY: Well, yeah. That's true, the first graph wasn't normalized, but I'm not sure that really -- I mean, he still has a point. We did not drill down to find out which cable/DSL companies --

SPEAKER: Right. Is that one (inaudible)?

MR. BRADNER: Use the microphone, Bill, for people out there in audioland.

MS. CLAFFY: He's saying this is not normalized. So really, this is the number of respondents. But I accept what you're saying is that we didn't drill down first and say, are you a cable/DSL provider, and then have you answer these questions. What we said was are you doing IPv6 at all, no matter who you are, if you're a university, no matter who you are, are you providing cable/DSL services over IPv6? Now that may be a bizarre question to be asking in the aggregate. You may want to only be asking that question of cable/DSL providers. And again, we learned a lot about how to do this survey better, but this still looks pretty negligible to me. If there are cable and DSL providers in the room who would like to provide some empirical data to this discussion, it would be welcome. Yes?

MR. GROVES: Hi. I wanted to make a comment -- oh, sorry, my name is Rich Groves. I'm with Microsoft. I wanted to make a comment on your performance as a disincentive portion of the survey. Internally at Microsoft, we've seen quite a bit of performance issues based on IPv6 extension headers, on any transit traffic across any box that we have internally, whether it be Brand Name X, that's what I'll just say, so I'm surprised.

MS. CLAFFY: You're surprised that it's so low?

MR. GROVES: I'm surprised that it's so low.

MS. CLAFFY: Yes, I think that you're dealing with a small sample of people who have actually deployed with v6 or gotten to the point where they can measure a performance issue. That would be my guess now. Because a bunch of performance issues will not happen internally that will happen once you let anybody else get involved. Right. Yes?

MR. DeLONG: Owen DeLong, Juniper Network. (inaudible) participated actually more in the survey since I represent multiple organizations who have differing levels of IPv6 (inaudible) due to (inaudible). I was only able to (inaudible). So is there a way that we can deal with that?

MS. CLAFFY: That's a great idea. That's a great idea. We'll do that. Well, you mean you couldn't fill it out twice?

MR. DeLONG: Right.

MS. CLAFFY: Yeah, all right. Fair enough. Next? Yes?

MR. SHANNON: Tim Shannon from DISA. Were any of your respondents concerned about security? I don't see it on the form.

MS. CLAFFY: There was one free form response that mentioned security, and yes, I don't think we got it in the --

MR. SHANNON: So what you're saying is --

MS. CLAFFY: There were -- I think there were a couple of responses that mentioned security.

MR. SHANNON: But it doesn't seem to be a big hurdle.

MS. CLAFFY: Well, it would be in vendor support back office. People said security in IPv6 is not nearly up to IPv4 capabilities. So that's where it would fall into there. Yes, we did have to do some consolidation, so it wasn't -- security wasn't isolated as a reason enough as much as the bottom one on this slide. So we aggregated.

MR. SHANNON: All right. Thank you.

MR. HUGHES: Just a comment on topic. I did quite a bit of consulting adding v6, and I find that people start to get very afraid when you talk about adding v6 dual stack into their LAN environments where they're "NATed." They decide that when you tell them they actually need to patch their boxes and these machines are going to be publicly accessible, et cetera, they have high concerns about security even though they're already effectively reachable.

MS. CLAFFY: Yes. I mean, I guess, you know, some of the patterns of what we're seeing with v6, and particularly the fact that non-profit government and edu is more likely to deploy it first and put the investment and resources in, is not so far off from the IPv4. It's exactly how IPv4 was supplied. It was government and education first, and we tested it out on us. We got some security stuff built in before Commerce was willing to come in. So we may be seeing some of that pattern happen in IPv6 for the same reasons. Is that it? Okay. So definitely come talk to me if you think -- if there's other stuff you think of later in the day, or talk to Nate. He and I are working on this together. Thank you. (Applause)

2007-21: PIv6 for legacy holders with RSA and efficient use

MR. PLZAK: In our never-ending quest to keep you paying attention to agenda, we're going to make a shuffle. We're going to now have a discussion of Policy Proposal 2007-21, PIv6 space for legacy holders with RSA. And so if I can get the slides up here. Thank you, Erika. So here's a brief history of the proposal. It was introduced in July of last year, and you can see what has happened so far. It had been adopted, but the board, when they looked at it, remanded it back to the AC to facilitate further discussion regarding a policy text. The policy text is in the meeting packet. Since then, it has been revised and has had a new staff and legal assessment, and the current version is as of the 11th of March. The table on the lower right-hand side is something we've decided to include in these summaries, which shows you the relationship of this policy to any other relevant discussions in the other regions. And as you can see, this policy is only being discussed in the ARIN region. So the understanding of the proposal is that it makes direct assignments of IPv6 space available to any organization with an efficiently utilized v4 assignment or allocation covered by an RSA. The shepherds for this are Suzanne Woolf and Owen DeLong. From the assessment of the staff, legal liability, none. Staff doesn't have any real issues or concerns over implementation, some software tools. We could do it within 30 to 90 days after ratification by the board. Not much discussion. Nobody in favor. Nobody against it. No real comments, even though there were seven posts by two people. So with that, I'll turn it over to Scott for the presentation, and then John will take on the discussion.

MR. LEIBRAND: I'm going to go over this fairly quickly because we did this last time, so I'll just give the overview. The problem as it was presented is that current policy allows you to get a IPv6 PI assignment only if you qualify for an IPv4 /22. Many legacy networks with 23s and 24s don't qualify for 22s. Without changes to the policy, these networks are discouraged from adopting v6 and encouraged to stick with their v4 where they've got PI instead of having to go with PAv6. Other considerations into the way we wrote this, there's still a lot of legacy assignments not covered by the RSA. Some of those may not be efficiently utilized, so therefore, the policy change is the blue part, which would be to allow an additional "or" clause to allow you to get IPv6 PI space if you demonstrate efficient utilization of all of your IPv4 assignments and allocations, each of which must be covered by a current ARIN RSA. That could be the regular RSA or the legacy RSA. The rationale for that is to stop discouraging IPv6 adoption by early v4 adopters, encourage efficient use of legacy space and return of unneeded space by requiring the efficient use clause, and encourage adoption of the legacy RSA by requiring an RSA on the v4 space before you can use it to get v6.

The history is the interesting part. As Ray already mentioned, we presented this at Albuquerque. A loophole was found in the text. It said "a" allocations instead of "all" allocations. We attempted to fix that on the floor of the meeting. During last call -- actually, right after the meeting, I looked at that a little bit more and said even that change doesn't quite close the loophole quite. So I posted a revised text to PPML, but these changes were not included in the version sent to the board or the version last call, I can't remember exactly, but there were discrepancies in the text, so the board remanded it back to the AC. The AC basically decided that because of the changes, we should bring it back to the meeting and make sure that this is still what everyone agreed to and there's no substantial changes and no change in the community consensus. So the question is, does anyone have any questions or comments on the proposal as a whole or on the changes to the wording since last time, and is there still consensus for this?

MR. OBERMAN: Kevin Oberman with ESnet. I'm a little curious about the numbers on how many people posted about this comments, because I did post a question about it, received a number of answers from several different people, so I don't know how there could have only been two people who posted comments to PPML on this. But in any case --

MR. LEIBRAND: I think that was after a certain cutoff date.

MR. OBERMAN: That may be. In any case, several people -- I posted a question as to whether the statement must be covered by a current ARIN RSA meant just the RSA or the LRSA. Several people responded to me saying that, gee, they found that confusing, too, but they thought it meant most, including one from the AC who said that's what the AC thought.

MR. LEIBRAND: I believe I responded to you as well, and that is indeed the intent.

MR. OBERMAN: And I think that could trivially be clarified by changing the "a" current to "any" current just to make it really clear we mean RSA, LRSA, or any other RSA that ARIN may decide to use down the road.

MR. LEIBRAND: The problem we got into last time was with changing the text of the proposal on the floor of the meeting, so we've been explicitly instructed that the proposal text is frozen at this point. Scott has a clarification to that.

MR. BRADNER: The proposal text is frozen as in that we can't change it on the fly. That doesn't mean that you can't advise the AC that this wording would be better and the AC can consider that when they meet.

MR. OBERMAN: I would hope the AC would consider this, because it clearly does confuse some people, I think.

MR. LEIBRAND: So you want to change "a" current ARIN RSA to "any" current ARIN RSA?

MR. OBERMAN: Yes, just so it clearly covers the LRSA and any other RSA that ARIN may come up with down the road.

MR. LEIBRAND: Okay. I think that's a -- my personal opinion is that's a minor enough change that that's probably something we can do after this meeting when the ARIN AC meets to discuss it and then that can go to last call. Thank you for the suggestion.

MR. OBERMAN: Clearly, this is a trivial change, it's just a very minor clarification.

MR. LEIBRAND: Yes. Thank you.

SPEAKER: (inaudible) are you speaking for or against it?

MR. OBERMAN: Excuse me, I forgot about that minor detail. I have not yet reached a decision on this, but probably for it.

MR. CURRAN: Microphones are open. Any other discussion on 2007-21? No? Thank you very much. (Applause) Good morning, everyone. In order that the AC can better do its job, I am often asked to coordinate a show of hands, which gives the AC some judgment as to the support of the proposal that they'll use in making their judgment to recommend it to the Board of Trustees. We did discuss what is a predominantly editorial change, and I think people recognize that that is something that can be accommodated in the process. So I'm going to ask for a show of hands for people who support this policy proposal. Then I'm going to ask for a show of hands for people who oppose the policy proposal. Is everyone ready? I see my counters are gathered. Yes. All those in favor of advancing Policy Proposal 2007-21, please raise your hand. Nice and high. Nice and high, almost done. Don't give up yet. We have a count. Okay. All those opposed, please raise your hand. All those opposed, raise your hand. Okay. Thank you. On the matter of 2007-21, number of people in the room, 131. In favor, 63. Against, 2. Thank you very much.

MR. PLZAK: We are going to now have the break. And so we'll take the coffee break, and you'll be called back in the room when you hear the bell tolling. So the bell will be tolling for thee.

IPv6 Adoption Through the Lens of Economics of Security

MR. PLZAK: Hello. Computer. There we go. Welcome back. Okay. From now until lunch, we're going to have a presentation by Jean Camp. And I'll let her give you some background as far as what's going on. She's from Indiana University. And so, Jean? It's all yours.

MS. CAMP: Thanks. Can I hold this?

MR. PLZAK: It's on a wire. Hey, have we got a cordless mic? Grab one.

MS. CAMP: I'm just really --

SPEAKER: Just talk. Just talk.

MS. CAMP: Hello? Yeah. I'm just really bad at standing still and talking at the same time. So I decided to do a study of IPv6 diffusion. This is about -- it's maybe the beginning of the academic year. I have not been as deeply involved in this as you have, but I thought, oh, this is interesting. IPv6 is going to run out, so let's look at a diffusion study and see what it tells us. And I looked around. There were a lot of arguments, but there weren't many studies. And obviously, because that's -- there's not a lot of diffusion, so there's not a lot of data. So what we did was we did -- we went to ARIN's site, and there's route views and there's all these great sources of information, and we looked at -- we started with 60 months of data, and I'm sure you're all shocked at my finding. Is everybody shocked that IPv4 is going to exhaustion? Completion, I'm sorry. IPv4 completion will occur before -- I know, you're all shocked. And I'll give you a minute to stand up and recover. But I think that the range of this and the reasons for this, that I'm asserting for this, all come from economics of security, because you have some of the same problems. There are -- I was talking to kc in the back about why people don't secure their machines. So in my neighborhood, now all my neighbors have kind of secured their wireless, but they never patch their machines. These are the same people that are going out and buying a Prius to stop global warming, and they wash out their cat food cans. I mean, these are good people, right? But they're not -- they are. I mean, what's grosser than washing out your cat food can? Don't answer. (Laughter) And -- but they don't secure their machines and they're perfectly happy to be part of, you know, spam and botnets, because they don't see it. So I see some of the same problems when I looked at this diffusion. So one of the big problems is, as kc said, and I'm sure you're all aware, incentive alignment. What's in it for me?

But there's a lot of other things going on. I think that there are network effects. When I say network effects, I mean that in the economic term, not -- think of -- so network effects mostly come from the studies of the railroads' diffusion, the diffusion of railroads. So network externalities, and externality is just something that's not included in the price. So one of the early concepts of externalities is if your railroad ran by my wheat field, and it was steam powered and caught my wheat field on fire, that was a negative externality. And some parallels, I want to talk a little bit about the literature in patching, the literature in privacy, and how people look at security cost versus benefits. And I'm sure I don't need to tell you to interrupt if you have a question. So network effects, there are intrinsic benefits. That is my benefit. So if I buy a computer and I never connected to the network, I can do presentations, I can analyze data. Right? I can do -- before there were networks, there were big computers that would do complex models. There is an intrinsic value in a computer. You can buy a computer now, at home, not connected to the Internet, and use it to play games and have a wonderful time. So the intrinsic benefits are those benefits that are derived from a good -- basically, even if nobody else adopts it. And I think -- I saw a lot of that in kc's slide where she said, what are you using internally? Instead of NATs, we're using all these other things. We like having individually addressable devices. For some companies, you know, I don't know -- I'm doing this workshop on insider threats, and if you're interested in that, please give me your card. There are still, you know, openings. The -- you get these things where the people who run their networks are saying, well, we have this perfect firewall, and inside we have our NATs, and we know every device that's inside and we trust them. And out there is the scary, bad Internet. Now, I'm not arguing this is the case, I'm saying you have a lot of people whose company's mental model is that, right? So for companies who've moved beyond that, who realize they don't know where the boundary is, they need to know when you attach a new device, like, for example, oh, why would I think of a picture frame? And they need to be aware of the devices on their own networks. That's a benefit they get even if nobody else adopts it.

Network benefits are from IPv6 adoption. That's the benefit I get if you adopt it. And it seems that, in IPv6, that while you can have the intrinsic benefits, the network benefits accrue to late adopters. Right? Who had the first fax machine and how useful was it -- is basically the question we have here. And if I invest tremendously in securing my machine, if every Tuesday, every second Tuesday, I sit down and I patch my machine, I get benefits. I get benefits that protect my passwords. I don't have a key logger. I have less spyware. But you know what? My neighbor gets the benefit that I'm not spamming him. And you get the benefit that I'm not participating in a distributed denial of service attack. Okay? So not everybody who could benefit from patching adopts patching. Not everybody who could benefit from IPv6 adopts IPv6. How applicable are the findings? How can we take some of the findings about why people don't patch and bring them to diffusion issues of IPv6? So I think a huge amount of it is visibility, but it's also perceived benefit. One of the problems with patching is the externality part. Right? I patch, I benefit. But you benefit, too, and you don't pay me. You can pay me; I'll accept payments. I keep a nice network at home. But, there's no structure for you to pay me. So Andy Osmet said, what we need are either subsidies -- we need to say, if you're going to patch, you need to be subsidized. We need mandates: Patch or else. Right? And you need to actually stop bundling. So one reason users don't patch is -- so maybe you want that security patch, but you don't want to break iTunes. Or you like the way you busted iTunes. Or you don't want to install this new helpful spyware. So unbundling is one way to help patching, is to give people only the security patches, and not the security patches and all the other stuff you're trying to force them to adopt. Lucianne Soleil said what we have is a lack of standardization. When you get a patch, you don't know what you're getting. So if you buy an IPv6 product, is it absolutely the case that you know what you're getting? Do you know how interoperable it will be? Do you know what options have been implemented? There is a need for testing. I talked to the guy who runs patching for IBM. He says, we get a patch, we take three weeks. We know we're vulnerable for three weeks, because it is better to be vulnerable for three weeks than it is to put a patch on our entire network and break everything. Right? I mean, that's a choice to be vulnerable. Also, every network is unique, and there's a tremendous concern for local technical hacks. Right?

Michael Froomkin talks about privacy. The risks are invisible. How many people counted the cameras that they passed on the way here? Right? I mean, yes, your privacy was decreased. How many of you saw any kind of data protection statement with any camera? You didn't see the camera, right? What are you going to say? Enter this space, you will be videotaped. You have to sign a release at a conference. You could be having a discussion in an airport that you think is private. So the risks to privacy are invisible. I ran this experiment on this kind of security enhancing human interface thing called Net Trust. It's really cool; I love it. And I ran it with a bunch of -- I ran it with CS undergraduates and they liked it. And then I ran it with some community members and they all said -- they filled out the surveys and they said I never share information on the Internet. Never. And then, at the bottom, they were like, oh, yes, I shop all the time. I shop for my grandchildren. I shop for my, you know, my nephews, and my sister has this website. And, you know, as a researcher, you have to accept that that's their perception. Although as a person, you want to go up and hit them with something and say how do you think they know where to ship it if you don't tell them who you are? I mean, they think they're totally private, and they're not doing anything, and they're not taking any risk at all. Just because they're shopping on the Internet is not -- there's no privacy issue there. They only enter their credit card where they want to. Similarly, I -- the risks aren't very visible. What is going to happen at IPv4 -- should I say completion or exhaustion?

SPEAKER: Depletion.

MS. CAMP: Depletion? Do we like -- is that? I just don't want to pick any -- I mean, I'm happy to pick some fights, but I don't want to pick any involuntarily. So the risks are invisible. I -- gosh, they'll run out of IPv4 addresses somehow, and that won't hurt me. Right? Yeah, sure that means that maybe heavy-handed regulation or there'll be big market distortions or we'll have more serious problems, but they're invisible and unknown. The costs are immediate. If I don't shop on the Internet -- and I love Bloomington, Indiana -- if I don't shop on the Internet, I'm going to have to drive to Chicago to shop. Right? That is an immediate, visible issue. And then there are other parallels in privacy. So how many people here regularly read privacy policies? I do. I do. And do you know why I do? Because it's my research, and I publish some of the things I say. And then I'll go to my student's -- the popular student websites, I'll read the privacy policies, and they're all like, they don't do that. But it's a lemons market. I mean, even if I read the privacy policy, you don't know what they actually do. You can read a privacy policy. You don't know the jurisdiction. I mean, if you read many of these privacy policies, they're masteries of wordsmith. We may share information. We might. Over tea and watercress. But merchants can't prove their privacy policies. They can't prove they won't change. Network service providers, you can't prove the value of IPv6. You can't walk up to me and say, all right, for every machine you put on IPv6, you are going to get to $27.14, in the next 7 years, with a 3 percent -- you can't prove it. There is a lack of information in both cases.

So Aquisti did this thing -- so, everybody knows future risks are discounted, right? I mean, so you have an immediate risk and you have a future risk. And there's -- you know, a dollar, in the same way a dollar today is worth more than a dollar next week, even absent currency rate changes, a risk today is more risky than a risk next week. So it's normal to discount risk. But if you look at privacy risks, not only do people discount them over time, but the farther off it is, the more they discount it. Right? So it's called -- a "hyperbolic discounting" means you discount the risk at a rate that increases. So people are discounting these risks, but it's like, oh, that's, you know, that's a long time from now. That's -- we're not worried about that. And the risk of depletion, or any kind of security risk -- security risks certainly see this. Right? I'm not going to be subject to identity theft because -- and then you insert some magical thinking, is actually what we're talking about here. And in general, costs are visible. People find the standard complicated. They worry that there's a lack of interoperability. That if I buy -- if I use your IPv6 stack, will it work with my IPv6 stack? The thing about a technology that's not widely diffused is it's not hugely mature across a wide range of network situations. And what's going to happen if I do this? Will my routing table explode? Will there be routing storms? What'll it cost? And then there's a huge other benefit that's very easy to overlook, that is very well-documented, and that is, you lose tacit knowledge. Everybody here is proud of what -- of knowing how to do what they do. Right? We're all proud of our knowledge and our abilities. And one of the things you have to think about when you have diffusion in and a new technology, is you're telling people that their mastery over the old technology is no longer either potentially as valuable or even valuable. So you have, what, two generations of IPv4 network engineers. And you're saying, no, we're going to get rid of that. All that NAT stuff you learned, that horrible semester you spent in EE327 or whatever it was, you don't need that, so. And similarly, the costs are visible; the benefits are invisible. There can be a long-term advantage in tacit knowledge. You'll be the first one on your block to know how to really configure IPv6. But it's uncertain. Overall network benefit -- might be security. You can't capture that. You can't capture that by adopting it early. And new commercial opportunities aren't quantifiable. What is the commercial opportunity in ubiquitous computing for in-home health care of an increasingly elder population? Who knows? Right now, it's in a research stage. And it's a place where you're going to have a lot of devices. And you may or may not want them to be network addressable.

So I am going to do the ultimate academic duck and cover, and tell you I am giving you this number with a reference, so don't ask me about it. Rowe estimates IPv6 adoption would cost about 25 billion over 25 years. I think that's kind of low. I'm just going to go way out on a limb here and say that doesn't seem like that much. And he talks about personnel costs, again, the tacit knowledge. What you know, it's not valuable anymore. Sorry. But we've got this cool new standard. And the discrepancy between cost and expected benefits burns early adopters. So this is all security things. IPv6 can also increase security vulnerabilities. So Andy Osmet, who I referenced before, says there's a problem -- is milk like -- is code like milk? Does it curdle? Does it -- as code gets older, is it more and more and more broken and stinky? Or is it like wine? You want to have old code that has been tested and proven. So his finding is that milk is like wine. I mean, no, milk is not like wine. Don't get confused and get drunk for breakfast and blame me. Okay. Code is like wine, that as you mature your code base, you get a lot fewer errors. And you get a lot fewer vulnerabilities in the code per line of code, and you also get a lot less misconfiguration due to inexperience. People just learn how to use it. Right? And if you're an early adopter, you're getting early code. You're getting the early code base. You're getting this year's -- you know, Cabernet. So I decided to look at diffusion, and I'd like to say, before I put these graphs up, that a picture is worth a thousand words. And these pictures are worth a thousand caveats because the data is very sparse, and I will feel completely free to agree with you that it is not entirely a guess. Okay? So we looked at two kinds of models. One, kc graciously -- and I didn't know she was going to do this -- started with the survey. But what you'd normally do is you go across -- you know, an industry. So if you want to look at fax machines, you say, oh, let's look at firm-specific diffusion. You compare characteristics of adopters and then late adopters. But that usually requires a pretty significant level of adoption. And then there's an S-curve macroeconomic model which takes aggregates over time. It implicitly integrates network effects and different types of adopters, and it's much better at a macro level. The Probit model, you need to have a lot of data, basically. You look at what industry you're in, you look at firm -- all the things she looked at. So she did that. And it's very hard to do with small numbers, to try to do some real correlations. And also, when we actually looked at the data, we found there were basically two firms. There was .gov and .net. Right? Governments adopted it, some network services adopted it, and everything else was drowned out. Now, if you want to go back to economics of security, the good part of it means the people who are arguably most informed about IPv6 -- that is, the network service providers -- are the people who are adopting it. Right? Compare that to something like screensavers with spyware. Right? The network service providers aren't adopting those; home users are adopting it. So the fact that home users aren't in the lead is not really a problem. We're saying that the most informed parties are least concerned about the uncertainty, which is absolutely what you want. The negative is how do you determine what factors are really driving adoption. It's a little early in the adoption cycle for that. So the S-curve model is nice. It's not really an S, because obviously, you don't go back in time. It's more like a kind of a transistor response curve. And it says there's a non-constant rate of adoption. And that imbeds improvements in technology quality. That says if you adopt IPv6 this moment, if you adopted next year, you could get improved quality. So it talks about tacit knowledge innovators, in fact, early adopters and then laggers, and the assumption is there'll be some refuseniks. I mean, wire line telephony never got to 99 percent in the United States. Right? So I'm sure there are businesses without fax machines. I haven't ever worked with one. So here was the question I started with. Given current adoption rates, when might IPv6 have real domestic market penetration?

So we did three things. We did kind of a best fit, which turned out -- you know, kind of pessimistic because it assumes there is no exogenous influence on the demand for IPv6. Well, my understanding is that around 2011, 2012, right, there's going to be a tremendous exogenous influence on the demand for IPv6 because there won't be any IPv4. Right? I mean, this is like the demand for synthetic rubber. The demand for synthetic rubber was nothing until there was this unfortunate little horrible, tragic global war thing and we didn't have natural war -- natural rubbers, and then synthetic rubber. Best case assumes a tipping point, and it's the most optimistic we can do given current data. I mean, this is -- I'll tell you how we used the data and -- you know, no making things up. So we did two datasets. The first, we did IP addresses and routes, and we compared routes as advertised. And then we did system numbers, because I thought that was a better comparison. Right? I mean, routes, you can have more IPv6 routes for fewer systems. Does that make sense? So we did the route comparison first, and then we did the system numbers. And it's true that you can't resolve a real world uncertainty with models, but you can bound uncertainty, and you can say something about what is happening and what the limits are. So the bounds are pretty big, I'm warning you in advance. We have some very large error bars. And -- but I think you might find it interesting. So the route count was your standard model. What we found was at about 4 percent, our secondary coefficient started to dominate; it went a little linear. And it occurs in -- and serious adoption occurs in about 2019. Now the thing is, the route -- I was happy with this because I thought 2019 was pretty good, but the data's not that clean. And also, this -- you see how it's low at the bottom? That's the coefficient of innovators. And then this, as it goes exponential there, that is the coefficient of followers. That is a really high coefficient, historically. That is incredibly high compared to things like fax machines, automobiles, even e-mail. Okay? But even with that, it's maybe too little, too late. You know, my understanding is at the current rate of adoption, IPv6 will be 20 percent diffused in 18 years. Now, because of that second coefficient, which is really high, you could say 80 percent in 22 years. This is not going to make anybody dance with happiness. The analysis doesn't address possible exogenous forces. Right? And so I list two forces that are completely defendable here. That is, IPv6 depletion. Right? Good. Depletion. And then supply pull -- what?

SPEAKER: You mean v4 depletion.

MS. CAMP: Sorry, v4 depletion. That's not as bad as getting drunk in the morning by confusing milk with wine. IPv4 depletion, and then there's this demand push which can give you an exogenous force. And there's a supply pull, and the DoD says they are going to adopt IPv6. And that's a case of supply pull. So if you look at, for example -- so, there's a case study about how IBM diffused the fax machine. They used it internally and then they demanded their suppliers use it. Okay. That is a kind of exogenous force we're talking about. So if you say -- you know, the DoD really does adopt by 2010, and we also looked at 2012, and -- you know, there's -- and we all learn to get along, it still doesn't occur until 2019. And in fact, some of the -- I did the route data, and then I took later data and did the ASN data, and there was a little drop, a very small drop, that would make that not fit. So -- but the forcing function says let's make the DoD -- let's say the DoD adopts and we have a big push. Right? So we have a supply pull, we have everything. Then the most optimistic that can be extrapolated from the current data is 80 percent in 8 years. And if you want to say anything less than eight years, you are just totally making things up. Okay? And this is very optimistic. And one of the things I thought about after this is, well, let's look at IPv4, IPv6 routes over time. You can see at the end, there's a little upturn. So basically, we're saying, in our most optimistic, we fit the curve so that that gives us our followers' coefficient. And this is very, very optimistic. And then we said -- this is since I presented this last, so -- the ASN count with the best fit. So we did -- we have a very good follower coefficient.

We did a best estimate with curve fit, and we found that the result was somewhere between 40 years and 220 years. Which is why I didn't use error bars, because you'd just have a big line with error bars all the way across it and you couldn't see what was going on. So these are our estimates, standard deviation one way or the other. So I think we were all comfortable in knowing that in the next 220 years, IPv6 was going to be adopted. But that made me say which months matter? So let's go back to the fax machine. The first fax machine was demonstrated in the United Kingdom in the 19th century -- the first telephotography was done, the first thing that we would recognize as a fax machine. So the early demonstration was at the -- you know, the Proceedings, the National Academy of Sciences in the UK. The first machine that did a fax was in 1902. And then the first transcontinental fax was around '56. So what if what I'm doing with this data is the Internet equivalent of modeling from 1859? Right? This could be a problem. So what we did was we said, well, you see the little bump there? The negative? This causes data problems. This is part of the data problem. So I looked at the data -- 6bone project termination, I think? Does that seem reasonable? And this is -- honestly, that actually is a guess, because I'm just saying the data went down, and at the same time, this happened. So I'm, you now, just -- but I think it's reasonable. So what if we truncated the data to the five-month window? Because 6bone said, okay, there are public IPv6 addresses, we can say this is where adoption's starting because we are working in Internet time. So maybe I was looking at the last century. So let's cut it -- let's use the ASN count -- let's cut it to the last six months and vary the follower coefficient. Remember, there's this coefficient, which is the innovator coefficient; and this coefficient, which is the follower coefficient. If you were in my class, I'd throw something at you for not -- so it's best estimate with curved fit, best possible results are on the left, is the coefficient, right? So we have the follower coefficient plus one standard deviation. All right? That's the best possible -- truncated the data, six years. We still got six years, which is not entirely optimal. And then we went the other way and we said, okay, 70 years, which is better than 220. Right? We're in this century. So the route data, the worst case, gave us about 20 years. But then we looked at the route data and we said there's a real problem because I was comparing -- you know, maybe not apples to oranges -- maybe, I don't know, cows to rabbits, in terms of their proliferation -- worst case, 20 years. Best case, eight years. And that eight years means you truncate the data, you do one standard deviation of the coefficient, and you have an exogenous force. So you know -- and the autonomous networks, the individual networks, no duplicates. So it's arguably a better fit because we're comparing -- you know, apples and apples. That gives us a worst case of 200 years. So -- and then I went back and I said this is mental. So what's going on that you would get this kind of number? We dropped the data up to the -- and we dropped the dataset, and then we did -- you can get by doing one standard deviation of the coefficient; that is, you'll get 200 years. But this 2014 means truncating the data to six months and doing one standard deviation of coefficient larger. That is to say, if you push for less than six years, I don't see how you could do it. I mean, this is standard deviation, best possible picture, we get six years. And is it the case that we will still be allocating IPv4 addresses in six years? Yeah? I mean, the question is will you have -- will ARIN have a nice -- so I think that this illustrates a problem.

Why so long? Is this a market failure, or a technical failure, which is a great slide bullet to have for libertarian engineers. I just love putting that up there. Thank you for indulging me. Misaligned incentive structure. Right? At the individual level, you have the loss of tacit knowledge and expertise, and you have testing costs at the institutional and individual level. There can be a lack of information. Network externalities argue against early adoption. Maybe it will be six years, but six years says there's a tipping point, and we are almost there. Are we almost at a tipping point? Right? That, I can't answer. That -- you can answer that better than I can. What is the tipping point? So why so long? Well, the market's not really good at rationally addressing long-term risk versus near-term cost. Right? There has been study after study after study that says -- you know, if you go -- if you have an office and you put in a gym and on-site day care, you're going to make your money back by massive increased employee loyalty and reduced sick time. Does everybody here work in a place with a gym and on-site day care? I mean, this is not unique. The incentive alignment at the institutional level also isn't great, because there are some counterincentives to adopt. Do you want to test, in your company, the new software? Right? You know, do you want this year's Cab or do you want to wait until somebody else tests it? You want there to be a little more adoption. In fact, if there is, as some people say, the ability to lock out new entrants, it would be absolutely mental of you to adopt. Now, I don't know if that's true. That is not -- I'm just saying if that is perceived, then you could be seen as acting against shareholder interest. And in that case, there's a direct map to the use of security. Right? What does security get used for? Does it get used to prevent your machine from being a botnet? No, it gets used to make sure you don't use somebody else's printer cartridge. Right? Am I right? So what can you do? Well, you can do government support of adoption. I'm just saying these are things that have been tried in security. Right?

Subsidies can decrease adoption cost. You can increase incentives for production. You can support production. You can demand -- so like IBM did with the fax, they said, all right, we're going to use the fax internally, and then our suppliers have to use the fax. Could you get Wal-Mart to use IPv6? Do you think Wal-Mart and their suppliers -- would that make a difference? Right? I mean, maybe the DoD isn't where you want to push. But maybe it is. The DoD could do the same thing. They can do fines, tax credits, tech support for technical standards and requirements. There are many things you can do. This is my understanding in the state of the world from the literature. I have not done any studies on IPv6 diffusion in China. And if anybody wants to run up after this talk and say here's your funding, do that. I'll do that. But what they're doing is they're doing incentives, they're doing funding, they're doing contractual obligations in government contracts. You know, there are other areas where you get contractual obligations. You must pay union wages. You must not outsource more than X percent. You must have an environmental impact statement. You could see, you must have 10 percent of your machines, your devices, IPv6 ready.

So there's a great 2004 final report on the IPv6 task force, and I had to quote this, "Imperceptible." That's a great word, "imperceptible." On a global scale, I have been -- I came into this kind of neutral, like, IPv6, IPv4 with workarounds. I mean, maybe I'm being like the atheist at the revival, but I'll say, I didn't really care. But I have come to -- it is now my opinion that IPv6 adoption benefits outweigh costs hugely because of innovation potential for all the devices. But in the U.S. and Europe, particularly the IPv4 infrastructure says we're going to have a high switching cost, we've got people who've got the IPv4 addresses, we've got the least incentive, and -- let me see, is this an American or international? Should I skip this? I'll skip this. I'll be polite. So the U.S. IPv6 adoption rate's not comparable to the international rate. If I could get this same data, if I could get some good data on China and Korea, I think that would be a good comparison. High switching cost and low perceived benefits, right? I think that government support could include -- encourage more timely adoption, but maybe not. I mean, did you notice I didn't say government support will encourage more timely adoption? Because I haven't necessarily seen that happening in security. Right? What's encouraged adoption in security? Two things: Visa and MasterCard saying you've got to do this on your website, and insurance, cyberinsurance. The insurance companies say here's the list of things you want to do if you want to be insured. So what should government do? And IPv4 depletion will vary. Here are some questions that come from an economics kind of policy background. How much can you unbundle IPv6? Can you have 10 years of saying this is going to be strictly renumbering, everything else is going to work, you're not going to have any -- I'm sorry, you're not going to have any of the features? Or will the rejection of the features and the unbundling of the features hurt adoption? So I think that's an open question. Emerging services. There are huge emerging services. How many people read that paper about the pacemaker? You know, they use Bluetooth for the pacemaker, so they encrypt the signals going, but they don't use device authentication. So you can't read the signal when I tell your pacemaker to stop. Isn't that a helpful security feature? I mean, it seems like there are a lot of IPv strengths if you don't unbundle, if you kept it fully bundled, and there's a tremendous need. Why not pay adopters? Why not? They're doing something that's a benefit. You don't have to just give them money. Right? You can certify individual IPv6 engineers. So look at what CISSP did. CISSP, they developed an exam. They said this is what you have to know about security. And then they went out and they said -- you know, Jean Spafford (?), here is your certification because you are such a senior security person. Right? And they gave it away to the best people until people wanted it. So that -- I mean, that model has worked. And also, usability matters. Okay? Network engineers are people, too. All right? And you can do -- I know, isn't that sweet?

You could do some formal studies of IPv6 configuration. Why is it that all these users have bad IPv6 configuration? Look, it's true, sometimes it's because people are stupid. Like the warning on the toothpick thing: Don't stick it in your eye. All right? That's for stupid people. But we're not talking about people who are sticking toothpicks in their eye. We're talking about investing seriously in usability as a way to assist the engineers with the transactions -- with the transition and the consumers with the adoptions. Take interaction design as seriously as you take issues of pricing, because a bad interaction is a price increase. Right? And also, again, you have this tacit knowledge feature, that you don't want people to feel like -- you know, we're taking away all your old knowledge and now, oh -- you know, everybody likes to feel thwarted, right? So these are things from InfoSeCon, which is Computer Security and Economics. While there've been some total cost of ownership case studies, what's the mobility cost? What's the security cost? I mean, I would say that right now, individuals are just waking up to the risk, not only of insider threat, but the risk in other infrastructures. So in Spain, they had actual train crashes. Did you guys read about this? Because they didn't authenticate their switches. You can't -- you know, you don't want to NAT the train switches in Spain. Right? Every train switch. They had a teenager who figured out he could change them with his remote control. He rewired his remote control and he would walk to school and he'd change it. Look, isn't that cool? Can you see yourself doing that when you were 14? Come on, admit it. You were 14. Yeah, well. And then two trains ran into each other. This is not -- you know, you can see this is not good.

There are -- people are becoming more aware of the security cost in the physical infrastructure. And, of course, pricing with coexistence. You've got to plan for pricing transition. You can build a market and that market can be absolutely self-sustaining, and prevent instead of enable adoption. Right? And if you do build a market, what are you going to build the market in? What's really scarce? Right? Are the addresses scarce? Are the entries scarce? How are you going to price? And who prices and who clears, and what's the bundle of rights that you get? These are not easy questions. So if you -- I referenced a lot of work. I referenced Osmet, Anderson. There's some nice, wonderfully readable stuff http://infosecon.net, (inaudible) InfoSec and eCon stuck together. And then these are the two students who have been working on this with me. So I hope my time wasn't too horribly off.

MR. CURRAN: Plenty of time. You even have time for questions. Microphones are open.

MS. CAMP: Who wants to debate the statement, "Network engineers are people, too?"

MR. CURRAN: Center microphone in the back.

MR. HUGHES: Hi, Aaron Hughes here. A couple of comments. One -- you know, the fax machine was a very different kind of thing because we still had the postal mail service. Nobody was saying -- you know, in three years, postal mail's going to stop working, so you need to adopt the fax machine. And I assure you, if postal mail stopped, everybody would buy a fax machine. In this case, we have that kind of incentive where, I think -- the graphs that you're doing are based on not running out of v4 space, and when that day happens, people will adopt because they really won't have much of a choice. And there are a ton of incentives out there. Government incentives right now include things like being able to be on the GSA Schedule, still taking those dollars. That's a nice one. I don't see that they've implemented a lot of dual stacking. I certainly don't see a lot of quad-A records out there on government sites. But I do see on the contracts now: Check this box, yes, you're able to supply v6 or you're v6 compliant. And in terms of commercial incentives right now, a big one I see out there is free transit. There's a couple of big IPv6 providers giving free transit. Happy to move those bits. Peering requirements go down. I can peer with larger providers on v6 than I can peer with on v4. And I also think that it's a fairly simple thing to implement v6 unbundled. It's easy to dual stack and not add quad-A records until the end. That's it.

MS. CAMP: And so I think many of those are at least fairly recent. And I think that's one reason why we could do the truncated data. But still, if you want to get to six years, you're going to have to have a significant -- you know, we're talking entire standard deviation to have that kind of --

MR. HAIN: Tony Hain, Cisco. I have some foggy brain cells that recall a similar thread of conversation of why IPv4 would never take off, that SNA would rule the world. And I was wondering if you'd had a chance to go back and review some of the discussions from the early '90s about why SNA would continue to rule the world, and look at that and see what kind of real rate happened in terms of the transition from SNA to v4, as one place of comparison. And another, it looked like all of your conversation is about the routing system, and the transition of the routing system, which --

MS. CAMP: Yes.

MR. HAIN: Could occur fairly quickly if people chose to do it. So you know, it's a choice question. I wonder how much of that is actually driven by the IN systems (?) and the diffusion curve in the IN systems, which I don't think you have covered here much at all. And, in fact, if we start -- if we say, if it's an IN system-driven thing, then the diffusion of the IN systems actually started about six years ago, seven years ago. So maybe we've got a running start on your curve that is buried in where we're looking. And so there's a couple of places I think would be good to look at in terms of comparing to a historical event. You know, comparing to the fax machine is actually comparing to the IN system, and you don't really get the network effect until you get the IN system. Comparing the routing is a little different. And I think that actually goes more to the SNA question, and how do you actually -- you know, flip that over. That was a fairly short curve, as I recall. It was less than 10 years.

MS. CAMP: Thanks. No, I just wanted to say I think there are other things, like if you look at DRAM adoptions, because there, you're not talking about adopting a different thing. So the fax machine was really a substitute for couriers, not for U.S. Mail. Couriers were so expensive. But when we did the long tail, shortening the tail is what got a quicker diffusion. So if we lengthen the tail, we're going to get larger final diffusion numbers.

MR. CURRAN: Yes, Paul.

MR. WILSON: Hi.

SPEAKER: Is that working?

MR. WILSON: Paul Wilson from APNIC. I just wanted to comment on a couple things. One was the part of your presentation in which you said, as a lot of people do, that there are special incentives for IPv6 in Asian countries, and that Asian countries have been demonstration sites or successful in some way in v6 deployment. That's not really true anymore. The Japanese government did have specific tax incentives for a while on IPv6 -- some aspects of IPv6 adoption -- but they don't anymore, so I'm told. And I'm not aware of any other country where those sorts of incentives exist. There has been a lot of promotion of the importance of IPv6 as something that should be adopted in the national interest in those countries. And it's true to say that in many countries of the region, the government actually is influential. So the government will say something like that and people will listen. However, the adoption codes are still not reflecting that, and I hear as many people in my part of the world say, as I do here, that v6 adoption is something that people will do when they have to do it. And they're ready for it, they're smart enough to know about it, and to do a little bit of planning, and that planning may be underestimated.

But it actually is a conscious decision that we really don't have to do it yet. And so, as I say, I think the address allocation curves are not showing anything special in the Asia-Pacific region with being like other parts of the world, up and down, no -- from year to year -- no revolutionary allocation rates happening yet at all. I wanted to just make one other point, which is about how you're doing these projections. And I think the curves are interesting, but -- I just mean, the curves' reality doesn't follow -- a curve -- you try to fit a curve to reality. And I'm just again, wondering what sort of parallels you might look at in terms of actually trying to test your curves against similar situations. So maybe there's a parallel that can't be tested historically yet, but it may be that others have done work in this area. And I see on TV in the hotel here that there's a fair bit of promotion at the moment about the deprecation of analogue TV in the U.S. That, I guess, will come -- it's different in that it will come at a particular date. But there must be, at the moment, I guess, some interesting speculation going on as to how many people are buying the little analogue conversion boxes. And -- you know, that being one way to transition versus, say, another, more expensive way, which is to buy yourself a big flat-screen TV and do it properly. And maybe there are some parallels there. But as has been said before, I'm not sure that faxes, for instance, are necessarily a good parallel. We might look at other more recent technology changes. And one that came up in conversation with Ben Edelman last night was this current transition we're seeing to flat-screen monitors from CRTs. And, I mean, I would say that the transition that we're seeing there -- and that's completely optional -- is extremely rapid. And I don't know if anyone's tried to lay their CRT monitor on their footpath, likely, but no one picks them up if you do.

MS. CAMP: If you look at the -- all right. There was a Nobel Prize in economics for the guy who proved that railroads were the same as canals, and that if we hadn't had the transcontinental railroad, we would've had the transcontinental canal. So you know, economics can go to these kind of insane extremes of believing that the technology itself doesn't matter. And I -- you know, I mean, obviously -- you know, the great canal through Death Valley wasn't going to happen. But that being said, this diffusion curve has been very widely tested. Yes, it's a -- you know, it's this classic diffusion model. And it's not just faxes, it's e-mail, it's the adoption of FTP, it's the adoption of IP4, it's the adoption of -- you know, Beanie Babies and Pet Rocks, and anything else kind of follows this pattern fairly well. And I'm not saying that in six years, we're going to have this adoption. I'm saying that if you use a very well proven model, and the data that are available, you're not going to get to adoption before depletion unless you have this -- a miracle occurs. Right? And then you can also look at other -- what I would call exogenously-driven adoptions, like synthetic rubber. You know? When the Allies no longer had access to rubber plantations, did a great job with synthetic rubber. The diffusion of radar in the military, right? If organizations come up against extreme necessity, they will certainly diffuse quickly. But it's not like IPv4 will stop working. And your television is going to stop working if you are only using over-the-air broadcast. And there are going to be a lot of people with analogue TVs because -- I don't know if you've seen this ad, this is one of my favorite ads, although my favorite ad is the bipolar medication.

But we won't go there -- because the entire ad is a list of terrible things that will happen to you if you take it. Your cable company is taking care of you. Your TV will still work. So even when you have mandates, you have market participants that enable and profit off of people not adopting the mandates.

MR. CURRAN: Okay. Center microphone.

MR. POUNSETT: Matt Pounsett. I'm from the .ca Registry and the ARIN Advisory Council. I'm not sure how much this influenced the graphs that you're -- or the curves that you're using, but there seem to be a lot of stress on loss of tacit knowledge, which I don't think is really a factor here. There's a fair bit of new knowledge that people need to deal with IPv6 versus IPv4, but most of what people know about IPv4 continues to be useful in the IPv6 world. To use an analogy from a -- you know, different place: If we we're all mechanics, we're moving from one type of car to another, not from cars to planes. There really is -- yeah, there really isn't a lot of loss of knowledge there. So I'm not sure if that affected the curves you're using much, or not, but it doesn't really seem, to me, to be a factor.

MS. CAMP: So it didn't affect the curves we're using. What affected the curves we're using tremendously is our start date. And if you picked an exogenous forcing function -- which what we picked as our forcing function -- which is to say, we just say it happens, and then add that as an asserted point -- is DoD adoption at different time periods. And one of the reasons I started to stress tacit knowledge is -- kc said, in the question and answer to kc, somebody gave a number of how much it could cost Google. You know, Google has IPv6, but you can't reach it because people are misconfiguring. And the people who are adopting now are the leaders. So you know, it's not hard to learn how to read either, but we still have one in five illiterate adults in the U.S. It's not necessarily the difficulty of obtaining the knowledge. So my emphasis in this particular day on tacit knowledge was a response to the question and answer and the previous information. But no, it did not affect the curves at all.

SPEAKER: All right.

MS. CAMP: So I appreciate your thoughts on it.

MR. CURRAN: Okay. Far right microphone? Leo.

MR. BICKNELL: Leo Bicknell, ARIN AC, ISC. A comment and a request for a future presentation. So the comment would be, I think perhaps relying on the public data that you seem to have relied on may be a disservice to the actual efforts that are going on. Because a number of large companies are doing an awful lot to look at IPv6 and consider deployment, and are specifically not doing it in a way that is visible externally to those companies. Specifically, when you look at large cable and DSL providers, there's a perception, if you look from the outside, that they're not doing a whole lot. And if you talk with them, they're doing a whole lot internally, they're just not ready to release it yet. So if you look at routes or -- you know, number of systems you can reach, or any of those metrics, the numbers for them are zero today. But that doesn't mean that they don't have a plan that in a year or 2 or 5, it could well be 20 or 30 million subscribers. So I think the public data has a bit of a problem in that respect, that it's underreporting certain segments of the ISP population. And I think perhaps a way to get around that -- and this is kind of the request for a future presentation -- is I've seen some interesting graphs -- I know one was in Forbes magazine because it's the one I can find online -- where people have taken these sorts of curves and displayed them for a technology over time.

How long did it take us to get the telephone, the washing machine, the fax machine, the DVD player, Internet? And the one thing I noticed about all of these things is the technology that was invented in 1900 has a very flat curve. And often -- you know, for the telephone line, it took 80 years to get to 95 percent penetration. When you look at the IPv4 Internet compared to that, it's a nearly vertical line on the same time scale. And technology, as it comes later and later, whether we're talking Blu-ray versus DVD, or any of these things, gets more and more vertical. And so the interesting thing, to me, would be to take a graph like that and look at the change in the rate of the adoption. And then project what is likely to be the rate for IPv6, which should be even steeper based on that metric.

SPEAKER: (inaudible).

MR. BICKNELL: That too. Obviously, it can't go on forever. But it would make things like your 70- or 200-year thing even more absurd when viewed in that model. And there's no one right answer here. But that might help eliminate some of the error bar function going on here.

MS. CAMP: Well, I agree that network service industries should absolutely share more data so that people can make more informed decisions. And I'm going to go ahead and say that -- you know, the California Disclosure Law, before it got passed, the lobbyists were saying, oh, we don't ever lose data, we don't need this kind of data notification act. You just don't appreciate how good we are. And then after the law was passed, the lobbyists were like, well, people are bothered. They get these things three a day, you know? So more -- without good information, it's hard to make good decisions, and I agree that that information is probably flawed. But for somebody who studies 19th century technology, that 70-year made sense. And I was talking to one of my colleagues who does diffusion studies, who basically said, six years, eight years, what -- did you check your software? Can I see these numbers? You know, because the 6 and 8 years is absolutely Internet time, and I agree with you that we see the difference between a 60-year and a 6-year, so it is possible. But I put -- I wanted to put the other standard deviation there, because I didn't want to say, oh, and if we have one standard deviation towards happiness will be in six years without showing you an idea about how much error there was in this public data. And I think more data would be great. I think it could help more -- if you could get, like, one of the ISACs, which are industry-specific, to share within this industry, IPv6 data. I mean, maybe you already do that but you didn't share it with me. That might be a great help, because these incident security analysis centers have really improved investment in security, so.

MR. CURRAN: Okay. Far left microphone. Bill.

MR. MANNING: Bill Manning, ARIN Board of Trustees, EP.net, and USC, and two or three other hats. Very interesting presentation. Thank you. I have a couple of questions, one of which is, you treat IPv6 diffusion as a homogenous activity across all industry sectors, which is not the case. It would be interesting to see it actually broken down by certain types of sectors, because I think that in some sectors, diffusion has gone much, much faster and is much more broadly deployed than in other sectors. So that would be something that would be interesting, to see if you could break that down. The second was, I heard conflicting data coming out of your mouth.

MS. CAMP: That's called uncertainty. I mean, I didn't want to put this up and say, and then God came down and carved this diffusion curve. You know, I wanted to really give you a sense of the things that I felt like I could assert, and those things that I felt I couldn't.

MR. MANNING: So let me drill down a little bit here, because Scott's actually there, so he's responsible for v6 if anybody is. All right.

MS. CAMP: Busted.

MR. MANNING: When does IPv4 -- what was the term you used -- exhaust, deplete, become no longer useful?

MS. CAMP: I understand that there -- I understood after I first wrote this -- and I have really just finished this, I mean, this -- and I wouldn't say I'm finished with it -- that I said -- that I kept saying exhaustion. And then in fact, Vint Cerf said to me don't say exhaustion. And I was like, oh -- you know, so I realized that I'm trying to use the word that doesn't pick unnecessary fights.

MR. MANNING: Right. We're not killing the last tuna here. Right? We're not making IPv4 extinct. You have also said that it's going to continue on and be useful for some period of time. And so the dividing line is to where you actually draw the start of the transition away from IPv4, and when IPv4 becomes statistically nonsignificant. That was not clear to me where that occurs, and what the characterization of where you put that line. Why did you pick it?

MS. CAMP: Oh. I picked the line so -- first of all, when we used a long tail, we got a very, very slow diffusion. And then I tried to -- so you get 220 years, you've got to say, 'Pbththth!'. Right? I mean, some findings just don't pass the moist noise of derision test. And so there must -- you know, there's got to be something else happening, and so how do you deal with this? One, you look at the diffusion. So that was my example of the IBM thing, is that you don't do fax machines from 1900, maybe we shouldn't be doing IPv6 from 2004. And that is why I picked -- when the 6bone went kind of -- dropped off, because for one thing, there was a definite drop in the data that appeared to correlate with that. And that seemed to be a very bad -- it was causing problems. It was causing -- and that's part of what was causing our huge tail. So that's why I chose that. I looked at the data, and I tried to look at the larger environment, and make an informed choice. So the data that I think we have is the innovator data, which is why the follower data has such large uncertainty. And if a year from now, we have a nice upturn -- you know, I showed you the graph and it has a little upturn -- if we have a really nice upturn, that uncertainty is going to significantly decrease. And I agree with you: How do you know when you start? Well, one thing we did is we just ran a bunch of simulations and saw which ones, like I said, passed the 'Pbththth!' test.

MR. CURRAN: Okay. We actually have a question from the table up here. Paul Vixie.

MR. VIXIE: Yes, I do. I'm wanting clarification on an implication of what you said. It certainly seems that, from what you've said, you can justify that the longer IPv4 lasts, the longer it will be before serious deployment of v6 begins. And that sounds like a no brainer in this audience. But I heard a nonlinear relationship, where if we find a way to squeak another -- you know, N = six months of life out it, I don't know, markets or revocations, or -- you know, whatever it is, that could push serious deployment of v6 off by more than six months.

MS. CAMP: Okay. So I did not mean to say the longer v4 lasts, the longer IPv6 adoption will take. I meant to say there is not a mandate and -- a mandated time. There is no mandate that says IPv4 is going to stop working on this date. There is not a Year 2000 crisis. There's not a transition to -- where'd he go -- transition to digital TV date. And that is the kind of thing that would be an exogenous event that would force IPv6 adoption. However, it's also the kind of thing that could have so many unintended consequences. You just don't want to do it. And it could also just be impossible, right? I mean, what you could do is say we're going to do this, and then you just -- you know, create a set of non-interoperable subnets. So I don't want you to think I advocated that. I was just saying in general, the existence of a firm mandate enhances diffusion of an item. And I do think that the more hopeful scenarios which -- you know, 6 and 8 years is very optimistic, but if we're -- if we could plan for -- you know, 12 to 15 -- you know, what's your transition plan? What's your target? If you're planning for there to be a sudden, hard, swift change, you're going to have a different plan than if you're planning, oh, we're going to have to live with this transition for six years. And I guess my point there is if you do something -- all right, so, like creating a market in IPv4 addresses and very strong property rights, are you going to be delaying the adoption of IPv6? So that was a question I was asking about what you do to keep supporting IPv4 can have implications. And you've got to seriously think through these implications, because you have different transition policies for a 4-year transition, an 8-year transition, a 12-year transition, and internal coexistence. Right?

MR. CURRAN: Microphones remain open for just a couple more minutes. Center rear.

MR. CASSIMIRE: Thank you. Nigel Cassimire, CTU. I have a simple question of clarification, I suppose. Between your optimistic and pessimistic scenarios, if you look at the diffusion curve, is most of the difference taken up in getting to that tipping point? Was it the time taken in getting to that tipping point? Or is there any significant difference in the rate of rise when you look at the curve? So for example, the optimistic and pessimistic, once we hit that knee of the curve and heading up, is there any significant change in gradient between optimistic and -- in terms of time -- you know, over that elapsed time? If I make myself clear.

MS. CAMP: No, I think you said what is -- what dominates, the coefficient of followers or the point at which that coefficient becomes dominant? And mostly the coefficient of followers dominates. That's the -- the uncertainty in that coefficient is what creates this crazy decades' difference. Now, if you do have a forcing and tipping, that is really what dominates. And that is why you can say, well, because we don't know what the coefficient is, the tipping point doesn't make that much of a difference. What makes a difference is after you've reached that tipping point, what happens then?

MR. CURRAN: Okay. I am closing the microphones. If anyone needs to speak, get to a microphone right now.

MR. OBERMAN: Kevin Oberman with ESnet. The example you stated of a forced transition of digital TV I find highly questionable, because that date has been moved repeatedly by the FCC, until they could set it at a date when, coincidentally, the tipping point had already passed and we had major market penetration of digital TV. And I'm quite sure that if we did not have reasonably affordable digital TVs today, and a fairly large market penetration, it would be delayed again until 2012, 2015, 2088, whenever.

SPEAKER: Good point.

MS. CAMP: Yeah, that's true. But the question is, did those earlier deadlines help it make it 2008, right? And plus, as I understand, right, at one point, there were competitors to IPv4. Right? And they just said, you're off. This was a long time ago, but.

MR. CURRAN: Thank you very -- oh, microphones are closed. Thank you very much.

MS. CAMP: Thank you.

MR. PLZAK: Okay. We're back, and we'll get some more slides up here. Okay. First of all, before I talk about this, we're making an agenda change. An announcement is being sent to the PPML regarding this agenda change. We are moving the discussion of Policy Proposal 2008-2, the Transfer Proposal, to this afternoon. It will occur at 3:30 p.m. Mountain Time, which is right after the coffee break. So please make that note. And for those remote participants that are watching and listening to me right now, please make that note, that the Policy Proposal 2008-2 will be discussed at 3:30 p.m. Mountain Time today. So now, we're getting ready for lunch. So remember about taking a break in the Cyber Café, and make sure you keep on doing those surveys. We had a couple winners. In fact, one of the persons that won this morning actually won his dream prize. He said I think I'll enter so I can win this, and he actually won it. So must be a good guy. Reminder: The help desks are open. And remember how I told you to find an AC member. We tagged them, so just look for this. They're here for you. So let's thank our sponsor for this morning. (Applause)

MR. PLZAK: Okay. Security reminder: Take your valuables with you. This room will not be secure over the lunch room. I'll see you at 1:30 after lunch. And don't forget, at 1:00 in here, you can see a live demo of Project X.

MR. PLZAK: All right, remember. Tonight is Death for Dinner. We're going to paint the town red. And remember the mystery. Was it Richard in the Cyber Café with a Cat 5 cable? Or was it Bill Darte and Leo Bicknell rapidly approaching the stage? Anyway, food and beverage, entertainment to include Final Four basketball. And for those who wish to attempt it, the signature cocktail, the Crime of Passion. Although some would say that's what happens here every day. So social transportation and badge. Attendees will need to have your name badge to get transportation to the social and to enter the venue. If you don't have your name badge, you don't get in. Buses will load at 5:45 p.m. And beginning at 7:00 p.m., a shuttle will be available to take you back to the hotel, and it will work on a periodic basis. The last bus will come back to the hotel leaving the social at about 10:00 p.m. After that, you're on your own to walk, crawl, or however means of locomotion you take to get back. Reminder, we do have rules of debate. They are in your meeting packet. And at the head table today this afternoon, we have John, Bill, Paul, Marla, Leo, Bill, and me.

2007-27: Cooperative distribution of the end of the IPv4 free pool

MR. PLZAK: And so, on to the first item this afternoon. In the reordered agenda, we're going to have a discussion of Policy Proposal 2007-27, the cooperative distribution of the end of the IPv4 free pool. Anyway, this was introduced on PPML in November of last year, and this is the first meeting in which it's going to be presented. This is an inter-RIR proposal, in that the same language it's being proposed in all regions. It is under discussion in the AFRINIC and RIPE NCC region. In fact, it has not yet been introduced in LACNIC region, and it has been discussed and abandoned in the APNIC region. The understanding of the proposal is that it establishes a mechanism for the allocation of IPv4 address blocks among RIRs after the IANA global pool of addresses has been depleted. The shepherds are Bill and Leo. Staff assessment of legal liability risk is none. Staff comments, issues, concerns -- yes, there are several. Inter-RIR policy is needed. It needs to be identical in status. It's difficult to implement predicting depletion which RIR does what. And also, staff feels that this could unfairly impact AFRINIC and LACNIC. We would see this as a major resource impact taking somewhere up to about 180 days to put into effect. Primarily from the inter-RIR coordination, it's going to be asked to be done to set up procedures to make this work. Some discussion on the PPML. Three in favor, none against. And so I will now turn it over to Tony Hain to give the presentation, and John will lead the discussion.

MR. HAIN: Good afternoon. It's always challenging to be the first speaker after lunch because everybody's dozing as we get going. So hopefully, this will be a little bit entertaining. If it's as lively as it was at APNIC, everybody will wake up again. So the problem statement here is what exactly is going to happen at the point where IANA has run out of space and one or more of the RIRs have run out of space, but some RIRs still have space? There's a fundamental assumption in the discussions about transfer policies and markets, that you kind of instantly go from the historical model of the RIRs managing based on need to a market with or without some needs-based override on it.

But there's this weird intervening state which will actually influence the formation of the market and/or possibly keep it from getting established the way it should, because in some regions, the resource will still be free, where in other regions it might not be. One of the other issues that plays into this is that the RIR membership is not captive to their native home RIR that they deal with today. And so just because you happen to be a member of ARIN doesn't mean you have to stay a member of ARIN. If ARIN has moved out of space, you can become a member of whichever registry still has space. You know, according to whatever their rules are. But this actually firmly establishes the process of RIR shopping.

Today, RIR shopping is discouraged and certainly watched to see if it's occurring, but if we don't do something about this intervening state where there's free resources in some regions and not in others, the process for RIR shopping will become the norm. So that's the fundamental issue that needs to be dealt with. So the proposal that I put forward says that once a registry has gotten to the point of effectively being out of space, it becomes a virtual LIR of whoever has the most space. Essentially, whoever has the most space left becomes IANA for all intents and purposes and has the central resource at that point. This goes on until you get to the point where there's just not enough resource left for any individual organization to hand things out, and you effectively just wind down the space. The complexity that was raised -- I hadn't heard much discussion about that before, so I'd like to see exactly where that complexity arises from. But -- you know, it was throwing some dates and numbers out there as a straw man for discussion, and there wasn't a lot of discussion in any of the regions to date as to exactly what would make sense in terms of numbers. The numbers that are in there are certainly negotiable. The advantage: The existing relationships between members and their RIR are retained. It distributes the workload to the existing regions, so processing and updating and verifying need and all of that occurs in the same regions it does today. Rather -- you know, that's opposed to the alternative where you do nothing and then the workload for processing and verifying and all of that moves to wherever the space is, as opposed to wherever the current customer base is. The disadvantage is it precludes the RIR that happens to be holding space from receiving revenue from new members that might appear. So that's pretty much the entire presentation that I had. If you want to open that up for --

MR. CURRAN: Microphones are open for questions.

MS. ARONSON: Hi, Cathy Aronson, ARIN Advisory Council. I can only speak for the registries that I used to get address space from, which were ARIN, RIPE, and APNIC, but they actually require you to do business in their region in order to get address space in their region. So I couldn't just go to one of them if I didn't have a presence in their region and get address space.

MR. HAIN: So you've never heard of shell companies?

MS. ARONSON: I've never heard of?

MR. HAIN: Shell companies.

MS. ARONSON: Well, yeah.

MR. HAIN: It's real simple to set up a company or buy a company that exists in a region.

MS. ARONSON: Well, there's lots of different ways to commit fraud, but --

MR. HAIN: Well.

MS. ARONSON: The policy doesn't allow you -- well, all right.

MR. HAIN: You get back to the fundamental point. The historical practice ends as soon as the first registry runs out of space. Right? Whatever you've done in the past doesn't matter anymore because you've now gone to a state that's outside that scope. And the fact that people don't go set up shell companies and commit "fraud" is because you don't have to right now. When you get to that point, if it's cheaper to go buy a company in the region than it is to go buy the space on the open market, you're going to do that.

MR. CURRAN: Okay, the microphones remain open. Right side.

MR. ALEXANDER: Dan Alexander, ARIN AC. I was just curious of your thoughts. Given what you're trying to accomplish here and looking at the presentation that Leslie gave this morning as far as the burn rates of /8s, if we're talking about borrowing an /8 from one registry to supply another, aren't we talking about the feasibility of this proposal would account for just a couple of months in a sense.

MR. HAIN: Actually, I think it's a weird state because we're not actually talking about /8s here. We're talking about -- you know, smaller sections than that.

MR. ALEXANDER: If one registry can go through four or five /8s within a year and a smaller registry has one leftover /8, this proposal doesn't necessarily stretch anything out more than a couple of months.

MR. HAIN: No. In fact, it causes it to go the other way around. Because if you didn't live under this policy, you just let things go the way they are and one of the registries that happened to have a very low burn rate had -- say, one or two /8s left and they have a very low burn rate, there's going to be a free resource sitting there for a very long time causing this effective black market, whatever you want to call it, of people going in and buying shell companies within that region to get space. Right? Whereas if you implemented this policy, you're going to burn through the space effectively within a few months, you know -- cause the global situation to be consistent as opposed to -- you know, if we do nothing, you'll have inconsistencies across the world, where this causes the world to be consistent with each other.

MR. ALEXANDER: The only other point I'd make is instead of consistency, shouldn't each RIR be left up -- shouldn't this be left up to their own decision as to what to do with the space that's been allocated to them?

MR. HAIN: That presumes that it's theirs.

MR. ALEXANDER: The resources have been allocated to them to provide for their region. This is in essence providing a means for one RIR to borrow from another.

MR. HAIN: It does --

MR. ALEXANDER: I was trying to say it nicely.

MR. HAIN: Essentially, it's going to happen that the space is going to go wherever the space wants to go. Right? And whatever processes have to happen that are not straightforward will happen. The space will go somewhere else. Okay?

MR. ALEXANDER: I don't disagree with that, it just should -- I'm just offering the opinion that maybe it should be left up to that RIR -- particular RIR -- to decide what they want to do with their resources.

MR. CURRAN: Okay. Microphones remain open. Far right.

MR. LEWIS: Ed Lewis, NeuStar. I have at least two fundamental problems with this. One is that the RIRs are supposed to be independent of each other -- regional registers -- and you're kind of tying them together now. The second fundamental problem I have is this is kind of creating a swamp space again, because now the space that went to one RIR is going to be distributed all over the world, and we'll have the early registration transfer process and all these other things going on that we had with the old, like, 192, 198 /8s.

MR. HAIN: It doesn't actually create it. It just accelerates the distribution. But what it does is consolidates that. So instead of having 45 companies go to the region that has space and create real swamp space that's undocumented, you end up with a consolidated set of requests coming in from each region so you can account for what happened. If you do nothing, the market will cause a swamp. If you do something, you can at least account for it and consolidate it and manage it to some degree.

MR. LEWIS: Yeah, it's granted that the swamp space may appear anyway. But this is really, I think, codifying it and saying this is going to be -- the last RIR out there standing is going to be having a swamp space to manage. And that probably would be a bad thing for them to do. If they're losing out on all the membership revenue that they would have gotten had it gone to their members, they're suffering more than the other RIRs.

MR. HAIN: That's hard to predict.

MR. LEWIS: Everything is.

MR. CURRAN: Okay, center microphone, rear.

MR. DURAND: Alain Durand, Comcast. The fact that there be different policies in the end and different registries, I look at this as a feature rather than a bug. And to give an example, yesterday at the open policy discussion, it was talking about a proposal to do something special in the end. For example, to reserve addresses for IPv6 employment if you need some small blocks of v4. And some of the comments that I have received during the discussion and after was that while in some regions there are more bits and pieces left than before. In some other regions, there are less. So the actual proportion of, for example, your last /8, you may want to dedicate to special usage purposes, may be different. And there were some other examples given where in some region, they may want to do things differently than in the other region. And I really look at this as a property and not a bug.

MR. CURRAN: Okay, microphones remain open. Center rear.

MR. SCHILLER: Jason Schiller, Verizon Business NRO NC. Just to follow up in Alain's point, the question I have is, in the event that this region or other regions decides to have a policy that we do something special with the last /8 or the last N/8s, how would this policy impact that? In other words, do you envision that the last /8, if it's designated for special use, would be hands off with regards to this policy and we'd only be talking about reshuffling the last space minus the N/8s that are left that are reserved for special use? Or would this policy also delve into the special use /8 and shuffle those around as well?

MR. HAIN: I didn't --

MR. SCHILLER: Did you understand the question?

MR. HAIN: I understand the question. I didn't intend for it to do any -- have any impact on the special use case. The market realities may cause different effects than what I intended. But -- you know, I understand the point. And it wasn't intended to discuss that, and maybe the wording should have said -- you know, excluding special use /8s if they occur.

MR. CURRAN: Microphones remain open. Any other comments on this policy proposal?

MR. LEIBRAND: Scott Leibrand, ARIN AC. Is the intent here to set up an automatic forced redistribution according to the formula, or is it to allow somehow the RIRs to share space in a "cooperative manner"? It seems to be like it does the former, although the title is the latter.

MR. HAIN: It's intended to do the latter in that if you -- ARIN, happen to run out of space and you go to some other region that has space and they deny your request, just as ARIN would deny someone else's request if the same event happens. It's not a forced redistribution of the space. It's a setup, a mechanism for recognition that this needs to occur. And this state will exist. Some mechanism needs to deal with the state. We have no mechanism for dealing with that state.

MR. LEIBRAND: So the -- that leaves the door open for if there are policy differences, if APNIC wants to say to ARIN that, okay, we'll give you space, but only if you use it in such and such a way because your policies are different than ours. They can hash that out between themselves.

MR. HAIN: In fact, I specifically chose the language become a LIR because you have to follow LIR policies within the region of whatever region that happens to have the space. That was the intent.

MR. LEIBRAND: I understand.

MR. HAIN: I might not have spelled it out as well as I should have, but that was specifically what I was thinking, is that you become a virtual LIR member of that region and follow its policies at that point.

MR. CURRAN: Center rear microphone.

MR. SCHILLER: Jason Schiller, Verizon Business, NRO NC. If the last RIR standing has less than a three-month supply, is this policy no longer effective, or is it possible that another RIR who reaches less than a 30-day supply can come in and take all or part of their remaining space?

MR. HAIN: That was part of the discussion I expected to have prior to having this go to presentation to the various regions, and nobody raised the question. So the exact details and the hard numbers I think really need to have some serious thought. I was really just throwing out a stake in the ground for discussion, and there really wasn't a lot of discussion, but that's certainly a good issue to get nailed down.

MR. SCHILLER: Thank you.

MR. CURRAN: Comment from the front table.

MR. DARTE: This is Bill Darte, ARIN AC. The whole point of whether it's forced or cooperative or whatever, this is a coordinated policy proposal, right? So presumably that if all the RIRs signed on and adopted this policy, that would be a cooperative relationship established, right?

MR. HAIN: It certainly is, although it doesn't require all of the RIRs to participate. It's just a matter of those who choose to participate follow whatever the procedure is that gets defined as part of this process. There's one more at the end of the table there.

MR. PLZAK: So just to be clear, what you just said was that in order for this to operate, only two RIRs have to agree to this, and the other three could do whatever they want?

MR. HAIN: Yes. One has to be the donor and the other has to be the recipient. But only two are required.

MR. PLZAK: My question is a bit more specific. Well, actually now, you raised another point. But the point is that it takes two to tango here, obviously. But does only -- if three people choose not to adopt this policy, then they are not affected in any way or shape by the way the remaining two RIRs are sharing their space? And if somebody -- and then corollary to that, if somebody says, gee, I want to sign up and do this and then later on they say, well, no, we don't want to do this anymore, is there an opt out?

MR. HAIN: There isn't an opt out in this particular policy proposal, but another policy proposal could certainly cause an opt out function.

SPEAKER: You've got another one.

MR. CURRAN: Go ahead, Bill.

MR. MANNING: Bill Manning, Board of Trustees and a member. This looks like a degenerate case of a transfer policy.

MR. CURRAN: And your point is?

MR. MANNING: There are attributes about this particular proposal which do not show up in other transfer policies. And there are things in other transfer policies that don't show up here. If we're going to have something that allows transfer to occur, maybe we should harmonize those.

MR. HAIN: It certainly would be reasonable to think about that. I was looking at it more from the perspective of your central resource -- IANA has gone away -- and where's the resource at that point. But it could be looked at from the other direction of it's just a transfer policy and the transfer happens to be larger aggregates than smaller pieces. And therefore, whatever transfer policy -- so I'm not opposed to that. That wasn't the model that it was built on.

MR. CURRAN: Okay, center front.

MR. LEIBRAND: Scott Leibrand, ARIN AC. To Bill's question, I don't think this is overlapping in any significant degree to the transfer policies that I've seen discussed, in that this involves space that the RIRs have that has not yet been allocated. All the transfer policies deal with space that has been allocated to an LIR or end user. So I think, if I understand it correctly, this policy deals with the time between IANA exhaustion and RIR exhaustion. And the transfer policies primarily are beneficial after RIR exhaustion, so I think they're -- I don't think they conflict in any real sense. The only area that they kind of overlap is in terms of setting up inter-RIR transfers, but I think even so, that's between individual members of individual -- of each RIR.

MR. CURRAN: Do you want to respond, Bill?

MR. MANNING: Yeah, I'd like to respond to that. In this particular instance, I happen to be the Bill registry, and you can be the Scott registry. Apologies to Mr. Bradner. And I've run out. I can't get any more from the IANA. The IANA doesn't have any. I've run out. My customers need them. You've got them. What this appears to be proposing is a transfer of resource from the Scott registry to the Bill registry, which is not substantially different than the transfer of resources from the Verizon business registry to the Sprint registry.

MR. LEIBRAND: I will acknowledge to you that they both use the same English verb "transfer." However, I believe the difference is in who does the transferring. RIR-to-RIR transfers would fall under this policy. LIR-to-LIR and end user transfers would fall under --

MR. MANNING: Why are RIRs distinctly different from their customers in the registry functions they perform?

MR. LEIBRAND: I suspect the main reason for that is around money.

MR. CURRAN: So in order to bring clarity to this, given the difference -- the similarity you reserved -- Bill, Mr. Manning, would you be in favor of this as is or against it?

MR. MANNING: Wearing my membership hat, I would be against this proposal.

MR. CURRAN: Center rear microphone?

MR. SCHILLER: Jason Schiller, Verizon Business UUNET. I'm just trying to understand basically the intention of this policy. And if I can reiterate for a moment, what you're saying is the ARIN members, assuming ARIN runs out of space, the ARIN membership is going to go set up global shop if they're not already global entities and get the addresses that they need from the other regions or the last region that's standing. So basically, from the point of view of how allocations and assignments are made, there's going to be no difference between that happening or the ability for these addresses to be transferred between regions. Is that correct?

MR. HAIN: There shouldn't be in terms of the end user receiving space. The workload and processing and documentation will be significantly different. And that's actually one of the fundamental motivators, is to try to keep that understanding of the historical customer need and evaluation process where it exists today rather than have it move around the world as the space moves.

MR. SCHILLER: So that brings me to the question of have we asked the staffs of the different regions whether they would prefer to suddenly get inundated by requests if they're the last region standing with space, or if they would prefer for this function to be distributed among their peers?

MR. HAIN: That's actually -- the fundamental of this proposal is to ask that question.

MR. SCHILLER: Have we had a staff response from any of the regions?

MR. HAIN: The only staff response I've seen is the one that occurred here, where it appeared to be a significant amount of work to get organized. There wasn't a discussion about staff response in APNIC.

MR. SCHILLER: Are there staffs of any other regions that can comment?

MR. HAIN: Point of information: are there any members of any of the RIRs, board or staff, who would like to speak about issues involved with implementing this policy?

MR. CURRAN: Wow, see how quiet it is? Some board members are really smart. There's no impact. I see Paul Wilson rising to the occasion.

MR. WILSON: Yeah, thanks. We didn't do a detailed evaluation, but I think the consensus would be that the ARIN's evaluation of a heavy workload, was it, would definitely apply. There seems to be a lot involved with implementing this. Since I'm here, there was a comment at our meeting about the effect of this and the prospect that we as a registry might implement policies that constrain -- voluntarily constrain the supply or right of allocation of address space from APNIC to our members, for our own reasons. If there was consensus to do such a thing that would make our address space last longer, which might be decided by consensus to be a good thing, but this type of policy would possibly provide a big disincentive to be doing that.

MR. HAIN: It wasn't intended -- it was intended to become effectively an LIR member; therefore, they'd fall under your LIR rules, whatever those might be. If the language isn't clear enough on that point, then I understand. That was the intent, that they fall under whatever rules the region has as another LIR member.

MR. WILSON: Well, I agree with you. That does seem to address the concern, but didn't seem to be clear. Thanks.

MR. CURRAN: All right. Center front microphone. The microphones remain open.

MR. FARMER: David Farmer, University of Minnesota. I would have a question of while I agree and I have no doubt it will be a lot of work, how does that compare to the other alternatives? I think there's a lot of work involved in this time frame no matter what. And so it's not about whether there's a lot of work. It's about which of the alternatives may or may be more or less work, and which of the alternatives allow for an understanding of where things ended up when it's all said and done.

MR. CURRAN: Okay. Given the policy where it's stated, would you be for or against it?

MR. FARMER: Undecided.

MR. CURRAN: Okay. Thank you. Closing the microphones. If you wish to speak for or against this, please find a microphone immediately. Center rear.

MR. SCHILLER: Jason Schiller, Verizon Business UUNET. And I'm sorry for being up here again, but I really want to make sure my point was clear, and I think maybe it wasn't heard. If AFRINIC is the last region that has space and they're accepting all of the requests that normally five RIRs would support, how comfortable are they with ramping up and supporting that? That was sort of the point I was getting at when I was thinking in terms of how much pain will there be if this policy was not implemented.

MR. HAIN: Which I think is actually the point about what are the alternatives. And if the policy is not implemented, they have to ramp up. And then as soon as their space is gone, they ramp down back to normal state. And that process -- actually, the ramp down could be more painful than the ramp up.

MR. CURRAN: Jason, given what you've learned, are you for or against this policy?

MR. SCHILLER: I think that it's very clear that this policy needs more discussion and more work. So in its current state, I am not for this policy.

MR. CURRAN: Okay, thank you. I'm closing the microphones. So no one else up at the mic now? Right mic.

MR. PERSIKO: Mark Persiko, Level 3 Communications. Has any thought been given or any metrics been made about the impact to the slowing of adoption of IPv6, or the growth in the global routing table that would result?

MR. HAIN: I guess I don't understand the question. Try again.

MR. PERSIKO: It sounds as if you allow one registry to allocate on behalf of another's space, could that result in too much multi-homing, or things happening to the global routing table that are unforeseen?

MR. HAIN: In fact, I think it helps that problem, because if I need space -- say I've run out. I come to ARIN. ARIN's run out. ARIN goes on my behalf and gets a block that I need, as opposed to me having to set up 10 shell companies and get small pieces -- you know, because I can't get big pieces all at once -- you know, as a new member. I have to set up several little companies, so the routing table problem would actually be worse if we don't do something like this.

MR. PERSIKO: Okay.

MR. CURRAN: Okay, thank you everyone. Thank you, Tony. (Applause) Okay, everyone. Again, I come up here from time to time to ask people to express their thoughts on policy proposals so that the ARIN Advisory Council can have that for their consideration. So on the matter of this policy proposal, we are going to ask for a show of hands. And I'm going to ask all those in favor and then all those opposed. We'll also count the number of people in the room and supply that to the AC as well. So let me make sure that my team is ready. And we're going to now put up the slide that shows the policy proposal and its number. Very good. Okay, so this is on the matter of Policy Proposal 2007-27, Cooperative Distribution at the End of the IPv4 Free Pool. I'm going to ask for a show of hands. All those in favor of advancing 2007-27, please raise your hand now. Nice and high. Okay, thank you. All those opposed to advancing Policy Proposal 2007-27, raise your hand. Nice and high. Okay, thank you. Do we have a count? On the matter of Policy Proposal 2007-27, the number of people in the room, 129. Number of people in favor, 1. Number of people against, 35. This will be provided to the AC. Thank you.

MR. LEIBRAND: John?

MR. CURRAN: Yes.

MR. LEIBRAND: Scott Leibrand, ARIN AC. I think it would be useful to the AC to know how many people think we should abandon the proposal versus work with the author to continue working on it. Would that be a question you'd like to ask?

MR. CURRAN: Certainly we can do that. So you actually gave three states, because it's an implied do nothing. There's a do nothing, work with the author, or abandon the proposal. I guess what you really want to know is should you abandon it or not. Okay? So I'm going to ask a single question, and a vote in favor, a vote of aye by raising your hand, indicates that you think the AC should abandon this policy proposal. A vote against means -- a vote of no means, no, the AC should continue work or work with the author on it. So again, a vote of raising your hands aye is a vote for abandonment. Everyone ready? All those who feel the ARIN Advisory Council should abandon this policy proposal, raise your hand. Nice and high. Thank you. All those who believe that the ARIN Advisory Council should not abandon this proposal, please raise your hand. Okay, thank you. On the matter of Policy Proposal 2007-27, abandonment of the proposal, number of people in the room, 129. That's good. Everyone is still here. All those in favor of abandoning, 12. All those against abandoning, 25. This will be provided to the AC for consideration.

2008-3: Community Networks IPv6 Allocation

MR. PLZAK: Now we move on to Policy Proposal 2008-3, Community Networks IPv6 Allocation. This was proposed in February this year, and you can see the rest of the history. This is only being discussed in the ARIN region. There is an errata document to this proposal text and it's in your meeting packet. The understanding is that this would make IPv6 allocations available to qualified community networks. The shepherds are Lea and Stacy. Council sees no liability risk. Staff's main concern was the definition of a community network. We need to know how to vet the applicants. The resource impact is seen as moderate, because it would require some registration software and template changes, so about 90 days. So this is the discussion on the PPML. Six favor, three against, three supporting the idea. You can see the comments. And so now for the presentation. Okay, here comes Josh. Okay, so here's forward. Here's backwards. Also present here is Sasha to I guess provide the assistance or whatever, or to push Josh aside. We can throw spears. I don't know, but he's here, too.

MR. KING: He's here to help me answer some questions, I guess. So I am Josh King from Acorn Active Media Foundation. And this proposal sort of grew out of an application to receive IPv6 space by a community network that I'm affiliated with. And upon discussion with ARIN, it was determined that as a community network, that we didn't fit under any current policies for receiving IPv6 space, but we couldn't get space for a variety of reasons from our upstream provider. And so it was suggested that we pursue a policy proposal.

So this is our first experience with this entire process, so mainly we're just sort of throwing the idea out there and hoping to get some feedback on ways that the policy could be revised or improved in the future. So the policy is for providing IPv6 space for community networks. As it says in the proposal text, it defines a community network as a network established to provide services to a certain geographical area as a supplement or alternative to a traditional ISP. They constitute a class of systems that is generally organized by the residents of a particular city, town, village, rural area, or other area for the purposes of providing benefit or enriching that area through both providing local content and Internet connectivity. They are somewhat difficult to define because they are usually organized around a variety of different kinds of technologies and layouts, several different kinds of organizations, which are usually either non-profits in and of themselves, or they're at least run in a non-profit fashion. Many times they are not incorporated or they're fiscally sponsored projects of other non-profit organizations. And they're operated for the general benefit of the residents of the service area.

So in an attempt to sort of define what this is, I'm going to provide some examples of community networks. The one pictured is the one that I'm affiliated in the town that I live, the Champaign-Urbana wireless Internet project that deploys open service mesh hardware to residences and businesses. It's a fiscally sponsored project, incorporated, but not an independent 501(c)(3). It doesn't -- like most community networks, it doesn't get any revenue from the members of the network. Generally speaking, they're encouraged to -- if they see the network, to put up their own networking hardware on their house, which then automatically configures itself to connect to the network. Some others are in like neighboring Homer, Illinois, which is just a small rural village that is just an independent volunteer project partially supported by the village where there isn't much Internet connectivity available in that area. And so they're just trying to provide for the residents of that village. The Seattle wireless network is one of the oldest in this country, and they're not even an incorporated entity. But they're extremely active with their community and have regular meetings. And their function is as much educational as it is to provide actual service.

NYC Wireless in New York, this is just a portion of their network diagram, but it's a large network that's a non-profit organization attempting to provide services to areas of downtown New York City. And they're very well-organized. This is a network, the Tribal Digital Village network on the Mesa Verde Indian Reservation near San Diego, California, that uses a variety of technologies to provide Internet access to all of the residents of the residences on the reservation, even though the available Internet connectivity is -- I think about 16 miles away is the closest. Il-Sanceville (?) in Montreal is another one that they developed their own software in-house for creating their own wireless network. But the ones in this country are far smaller than the ones that are in Europe. This is just a tiny part of one of the -- it's just a tiny part of the Freifunk network in Berlin, Germany. There are also metro scale community wireless networks in many other towns, many other cities in Germany that are already in the process of deploying IPv6 on their networks. There's the Vienna network, which is comprised of several thousand nodes that provide Internet access for free throughout most of the urban Vienna area. They're already using IPv6. They've got similarly sized networks in Grotz, Austria, and several other cities whose names I can't really pronounce. There's Athens, Greece. The Athens wireless network, which is a completely ownerless network. There's absolutely no central authority for the organization of the network. There's just a common set of software and hardware that they deploy in order to connect to the network. The network in -- how do you pronounce that -- Djursland, Denmark, covers an area of, well, 2,500 square miles -- 2,500 square kilometers providing Internet access to all of the residents of that city. And there's the Czech free network, which is also completely -- there's a central authority, but it's very loosely organized and it uses a variety of technologies. Everything from 802.11 wireless to people throwing coaxial cables from one house to the next through their windows. And it actually covers most of the country, as I understand.

One notable feature about these networks is that they're also moving in directions to support roaming mobile devices throughout. So the same software that runs some of the largest networks that I've showed you has been ported just recently to the iPhone. There's also the Open MoCo (?) Project, which is creating an open smart phone that is capable of running that software. My laptop can run that software, so you would be able to take that and roam from one end of the network to the next. Now, the reason that these networks need IPv6 addresses is that while many of them already support IPv6 networks internally and are capable of doing that externally, and there are a number of advantages to doing that, it can drastically simplify the network management and architecture by making each of the thousands of nodes in the network externally routable. While we have that capability, we just don't have enough addresses. It also allows for things like external people to be able to call in voice over IP phone calls to a certain house, which is something that is very difficult to do in current mesh networks with the complicated routing. It also -- things like IPv6 any casting and mobile IPv6 are things that are very easy to -- make it easy to implement things like roaming and mobility throughout a network. And most importantly, these networks want to be able to deploy this technology so that eventually when IPv6 becomes more prevalent, that they have a well-tested implementation in order to serve their communities. The reason that they generally can't get IPv6 allocations right now is because their upstream providers either do not support IPv6 yet or there have been providers that have been traditionally reluctant to deal with this strange phenomena of community networks by providing them with affordable address space. They don't quite fit into the traditional model of LIR versus end user because they're not a traditional end user because they provide connectivity and services to other individuals and organizations. But it's not really a traditional LIR because it's very difficult to define exactly what a customer is in a community network which has an open model of participation and is decentralized as far as tracking its various users.

So it's interesting to note that RIPE in Europe has already started allocating IPv6 addresses to community networks in Europe. And so we're just trying to -- we feel that there's sufficient reason to be able to acquire IPv6 space in this country, and there are probably a number of ways to approach this problem. And we're just sort of trying to search for a solution to this. So that's about it.

MR. CURRAN: Thank you. Microphones are open for comments on this policy. Yes, Bill Manning.

MR. MANNING: There is historical precedent for this. The amateur packet radio network is geographically constrained to the planet. It's net 44. It's been around for a long, long time. So there is precedent.

MR. CURRAN: So Bill, citing that there is a packet radio network net 44 means you, in light of that, would be for or against this policy?

MR. MANNING: I'm going to wait for the rest of the microphones and then I'll vote with everyone else, or not, as the case may be.

MR. CURRAN: Okay. Now, try to constrain comments to enlighten discussion. So to the extent that you have something, just let me know. Yes, Bill.

MR. DARTE: Yeah, Bill Darte, ARIN AC. So my question is, what is it that you really want here? Do you want us to -- the community here to adopt this proposal or are you really looking for just feedback?

MR. KING: Well, judging from feedback that we received on the list fairly late in the process, it seems like there may be some revisions that might need to be made to the proposal, I suppose. I don't know if that's something that could be done purely in the AC process or if --

MR. CURRAN: Is it predominantly administrative or does it substantially change the functioning and the dynamics of the proposal?

MR. KING: It's predominantly sort of qualifications as far as what constitutes a community network. Such as, there's been discussion as far as whether to more stringently define it as particular types of non-profit organizations that would qualify for this kind of thing.

MR. CURRAN: Okay. Do you want to respond?

MR. DARTE: Well, I just want to make sure. So you really are not looking for a nod to create this as policy at this point. You do want feedback. I mean, you acknowledge that what feedback you've already received on PPML suggests that you should change this, and that's what you're looking to do? Because that makes a big difference to the Advisory Council and to the community, I think, about what it is your objective is right now.

MR. KING: Well, I guess I'm not familiar enough with the process. I understand that there are some minor revisions that can be made, like, during the AC process or the last call process. And so I'm not entirely sure whether the scope of the changes would -- you know, warrant going right back to the drawing board or whether that would involve going on. I guess it may depend on people's feedback here.

MR. CURRAN: Okay. Bill, as written, would you be in favor or against the proposal?

MR. DARTE: I'm just trying to be terribly objective as an Advisory Council member here, so I'll wait to hear what everybody has to say.

MR. CURRAN: It's possible if we all want clear objectives and no one actually has an opinion, one person can swing this. That's great. Okay, center rear microphone.

MR. DIVINS: Dave Divins, ServerVault. I have a question regarding how this would physically work with the ownerless state. It's kind of really three questions. Who would actually -- in an ownerless ad hoc manner, who would actually be the one requesting the space? How would they redistribute that space to those people? And how do you prevent a single area from having kind of competing networks where they -- you know, multiple people in that same area request space because they're -- you know, the competing ad hoc network? It seems that you would need a much more strict definition of who you're actually assigning addresses to.

SPEAKER: Sometimes they go away (inaudible).

MR. DIVINS: Who do you actually give the resources to and what -- you know, who manages those resources? And -- you know, if you have a community that's -- you know, from 1st Street to 5th Avenue, does 5th Avenue to 7th Avenue get to be a different community that can get their own /32 or whatever it is? Without a much more strict definition of a network with a management structure, I don't know how this could be feasible. I mean, I'm actually pro -- you know, this concept, but I just think you need to have a little more strict definitions than just a community of people. That's really it.

MR. CURRAN: Okay. Any response?

MR. KING: Well, I mean, I would agree that, of course, there has to be some entity that is assigned the address space. Some organization of some kind. I didn't mean to introduce confusion by pointing out, like, the Athens wireless. I was just trying to point out sort of, like, the wide spectrum of community wireless networks. But I'm not actually advocating a completely ownerless model as far as allocating address space is concerned. I do agree that there needs to be an organization, an entity, that is responsible for that address space allocation. As far as, like, competing networks within a certain community, I mean, it comes down to trying to define the geographical boundaries of a particular community, particularly when you have networks that exist within a single neighborhood and networks that stretch over entire geographical regions. I would say that although there isn't a hard-and-fast limit written into the proposal, that what we have generally seen with community networks that are currently in existence is a tendency to cooperate and aggregate their networks together rather than having multiple competing networks in a single community. Because you don't have customers, per se. Generally, they have an open policy where anyone who wants to participate in the network is capable of joining it. I won't say it's impossible for there to be two or more competing community networks in a metro scale area, but it's not something that I've ever seen amongst community networks that exist now.

MR. CURRAN: Dave, does that clarify your --

MR. DIVINS: Yes, it does. Thank you.

MR. CURRAN: Okay. Far microphone right side.

MR. DeLONG: Owen DeLong, speaking solely as an individual at this point. First, I'd like to kind of put Leslie on the spot because I don't understand why these community networks would not necessarily meet the LIR criteria for getting IPv6 space.

MR. CURRAN: Okay, so let's pause on that. So a point of information, Leslie, are you here? Sorry. If you could speak to why existing policy for LIR does not necessarily work for these entities.

MS. NOBILE: One of the requirements -- one of the criteria right now in the LIR policy says that you have to plan to announce the single aggregate. And they cannot do that. And that is one of the key criteria spelled out.

MR. CURRAN: Okay. Got it.

MR. DeLONG: So I'm opposed to the policy as written, and I think that we should instead alter the LIR criteria to provide perhaps necessary exemptions to meet the needs of the community networks.

MR. CURRAN: Front and center microphone.

MS. YILMAZ: Filiz Yilmaz, RIPE NCC. There were some examples of those networks that you gave from our region. I just want to make a clarification. They sound like they qualified through some kind of IP version 6 PI policy in our region. Actually, as of today, we don't have a PI policy at all in the RIPE region. So that's what I wanted to make a clarification.

MR. CURRAN: Good clarification. Center rear microphone.

MR. SEASTROM: Rob Seastrom, ARIN Advisory Council. I really like community networks. I like community networks so much that I co-founded one. And I was the first president of it. And one of the things that we learned when doing that is that the more you look like something that an organization is familiar with doing business with, the more likely you are to have a smooth ride in doing business with them. We incorporated. We became a 501(c)(12), which is a rural telephone co-op. Yeah, it takes money to do that. So you have to have some people -- you know, putting some money into the situation. I say "we." I'm not affiliated with them anymore, but they still exist. We buy transit. We have some routers. You know, it's not complete anarchy. We have a standard set of products. You know, we offer T1s to people's houses. I think somebody on the ARIN board is a customer of this co-op. So what I'm saying is that it's possible to meet all of the requirements that ARIN puts up, but you need to rise above the level of the extremely anarchic no sort of structure kind of community network. And I think that if you get people together who are interested in doing organization without bureaucracy, with the intention of serving your constituency, you can do that without losing the essential flavor of the community network that you have. We certainly managed to pull that off for eight years. So I am opposed to the proposal while being very much in favor of you guys doing whatever you need to do in order to get your space because I think that honestly, this is a step away from goodness in terms of being able to do appropriate stewardship of number resources when you create a very nebulous class of LIR.

MR. CURRAN: Okay. Response?

MR. KING: Well, first of all, just out of curiosity, I'm just wondering what community network you're --

MR. SEASTROM: That's Cambridge Bandwidth Consortium, Cambridge, Massachusetts.

MR. KING: Cool. Sorry, I was just curious. It sounds like your community network is extremely organized compared to most of the ones that I know of.

MR. SEASTROM: It's very chaotic internally. We manage to keep the flavor going by being disorganized.

MR. KING: So you're saying that these community networks should endeavor to sort of aggregate more funds in infrastructure in order to qualify under the LIR policy?

MR. SEASTROM: Let me give you an example in another business area. Okay? If you decide that you want to get a good price on gasoline and you approach a company that's a fuel terminal, which is -- you know, sort of like ARIN, and you want to buy gasoline wholesale by the tanker truckload, but your method of storing it is barrels in your friend's garage and in your garage, and maybe a few of them stuck out back under a tarp, there's going to be all sorts of questions. All sorts of weird -- well -- you know, you don't meet the fire code for this. You don't -- you know, there's all these hang-ups that you have. On the other hand, if you were to find yourself the most derelict gas station that you possibly could and rent it for a pittance because it's in a horrible business location, and have a tank in the ground where the tanker truck can come in and dump the fuel into, then they say, oh -- you know, well, okay, fine. Can you pay for it? Okay, good. And then the truck comes up and dumps gas and then you have your inexpensive fuel supply. So likewise, if you make an attempt to fit the mold -- and this is not just for ARIN -- this is for if you needed to buy transit from somebody. If you needed to buy a loop to the other side of a mountain that you can't get wireless past or something like that, the more you look like what the other company -- the other organization is expecting to do business with, the less of a rocky road you have.

MR. CURRAN: Okay, thank you, R.S. If anyone else wants to speak on this proposal, please come to the microphones quickly. I'll be closing them. I'd like to take front center and then far left. Front center first.

MR. FARMER: David Farmer, University of Minnesota. I'll just say I'm opposed to the proposal as written. However, there needs to be a way to accommodate community networks. I'm very supportive of that. On the mailing list, issues of the financial issues came up as well. And I would like to encourage that some mechanism to deal with that be created. I also think finding a way to shepherd the community networks through the ARIN process and someone doing outreach to that group of people is a necessary thing for ARIN to do as well. However, both of these are not really policy issues.

MR. CURRAN: Understood.

MR. FARMER: I would be opposed -- as I said, I'm opposed to the policy and written. We need to find accommodations though.

MR. CURRAN: Okay, thank you. I am closing the microphones for additional comments. Only the people remaining in queue at the mics. Yes, far left side.

MR. WEILER: Sam Weiler. I'm still confused about why the existing policy is not good enough. And I heard from Leslie the thing about not announcing a single aggregate, though I didn't hear that from the presenter. Where is the breakdown?

MR. KING: Well, there are a number of issues with announcing a single aggregate. For some community networks, that may be something that's possible, but most community networks have -- they often get banned for multiple uplinks. They're fairly decentralized, in that one part of the network may or may not be connected to another part of the network depending on -- you know, who has their wireless node on -- given the part of the day or whatever. So -- and oftentimes community networks in different geographical regions cooperate with each other and interoperate over things like VPN's and stuff like that. So just in the initial proposal that we proposed for getting an address allocation, we decided that we would not be able to advertise the aggregate. Maybe there are community networks that are cohesive enough that they're able to do that, and then maybe they would qualify under the LIR policy.

MR. WEILER: Clarify? So it's more that than anything about organizational structure?

MR. KING: Sorry, could you say that again?

MR. WEILER: We heard from the floor some opposition based on basically organizational structure. And it sounds like that's not the problem that is really being faced.

MR. KING: I'm sorry, you mean that -- I guess I'm not really sure what you mean. Like, as far as the -- that that isn't the primary issue with the policy? That, like, the problem with this policy as it stands is the organizational structure? Well, I don't know. There's been a lot of discussion about restricting the organizational structure. It seems like the possible kinds of organizations that could qualify as community networks -- basically to attempt to keep from having a policy that is so wide open that it's open for abuse, which may be necessary. I don't know.

MR. WEILER: Thank you.

MR. CURRAN: I want the center rear microphone.

MR. SCHILLER: Jason Schiller, Verizon Business, UUNET, NRO NC, Kilo-Bravo-Two-Romeo-Tango, Quebec. I'd like to follow up on Sam's comments about advertising a single aggregate. And I'm not sure I still grasp what the issue here is. And I think what I heard was that you might have multiple transit providers and the network could become partitioned, or maybe it's not always contiguous because somebody can't run their access point and their washing machine at the same time. I don't know. If that's the case, then why don't you coalesce all of the nodes that are close to the one transit provider and consider that one community network, and coalesce the nodes close to another transit provider and consider that one community network, and get space like any other end site would get space? And if they need to talk to each other, well, that can all be done through the miracle of routing, or you can set up VPNs and they can talk directly, securely. I'm not sure I understand what the issue is here.

MR. KING: Well, part of the technology and sort of the goal of many of the networks that I pointed out is that through the sort of mesh routing that they do, that they're able to -- I mean, that's sort of one of the features, that they're able to talk to each other over a large aggregate LAN and be able to provide services on that LAN independent of any kind of upstream connectivity, and also provide the kind of redundancy and things that are available from being able to utilize whichever upstream provider happens to be available. So if one goes down, all of the traffic in the entire network that can reach it is able to route out to that. And they're also working on things like bandwidth multiplexing between multiple upstream connections, where users on network would be able to take advantage of all of the bandwidth available to a network from multiple upstream providers at one time. And there are also community networks that use radically different models on how they utilize their Internet connectivity. There's a network called BG Wireless, I believe, in Serbia that is a large interconnected community network, but they're only periodically connected to the Internet, that they are almost entirely about their Internet services and the file sharing and game playing and -- you know, local websites and things that are on there. And then, say, every Saturday afternoon between 1:00 and 3:00, they open the floodgates to the Internet and people access their network services, and then they shut it off again. So I mean, it's just eliminating one of the major features of the software that most of these networks use by sort of limiting and partitioning the networks.

MR. SCHILLER: Well, I'm not sure I understood the comment. Routing is hard, so we need it to be on one broadcast domain? That's kind of what I'm hearing.

MR. KING: Well, I mean, are you saying that you can -- like, are you suggesting that the different sections of community network talk to each other by routing out through their upstream provider?

MR. SCHILLER: Or directly.

MR. KING: Just directly through the interconnects?

MR. SCHILLER: Both or either, yes. I mean, you can run some sort of interior gateway routing protocol, and you can exchange different prefixes over that. They don't have to be a contiguous single broadcast domain. And you can route different prefixes to your different upstream providers if you desire. Or you can route a single aggregate to all of your upstreams -- assuming the network is actually contiguous and can deliver traffic for the entire aggregate. So I'm not sure how this network's requirements are different than any other networks. Whether it's an end site or a Tier 1 ISP. I mean, yeah, I do agree with you. It sucks when you partition your network. But -- you know, everyone deals with it. You build in redundancy and you plan for failures. And I would think with the equipment being as close in proximity as it is, especially with the ability of wireless, that redundancy should be a fairly easy thing for you.

MR. CURRAN: So given that, you remain opposed?

MR. SCHILLER: Well, I still don't understand why a community network needs special dispensation to not advertise a single aggregate. And until I can understand the technical reasons behind that, I'm skeptical as to why we need a special policy for it.

MR. CURRAN: Thank you. Front and center microphone.

MS. SCHILLER: I want to say -- Heather Schiller, Verizon Business. And I agree with most of what everyone else has already said, particularly R.S. and Jason. Community networks, as far as I can see, the thing that's special is that your customers -- the line where you say because often no real customers -- well, your customers are real. They just might be dynamic and they might not be there all the time. And maybe you have fewer customers than other service providers, but you still have customers. They're still real. You provide connectivity. And I point out that -- you know, community networks, you're in the same boat that other small providers are in when it comes to this policy. And so in the past, people have argued that the problem is really with the requirement to be offering services to 200 customers, and not so much the stipulation about announcing a single aggregate. Because there are plenty of other providers who are smaller, other end users who are in the same boat. And that's a multi-homing problem that needs to get solved and fixed in some other mechanism and forum. I'm very concerned about the concept that they're ownerless. What we were talking about before, where -- who's responsible for these resources and what happens if that person goes away? And some of the -- I was trying to find the legal comments to see what Steve had to say about that. In ARIN, the concept is that the resources are held by the organization. And if you don't have the organization strongly defined or who is responsible for that organization, you can get into some problems. And I'm concerned about that part of it. Also, reluctant service providers. If they're reluctant to provide you with v6 services, you showing up with your own block isn't going to make them any more inclined to be providing v6. Yeah, you may be able to do it on your own between your own nodes and whatever, but getting your own space isn't going to necessarily help or change that. And I would like to know why this policy -- if you have all of these concerns, which we've addressed a lot of -- but this policy was written specifically for v6. So how are you solving this in v4?

MR. KING: Through a -- well, through not being able to use a lot of the features that -- well, I mean, among other things --

MS. SCHILLER: Very directly, are you able to obtain v4 resources from ARIN for these community networks without having a particular blurb in policy that defines community networks and gives them --

MR. CURRAN: How do you presently obtain IPv4 space?

MS. SCHILLER: Right.

MR. KING: From our upstream providers.

MS. SCHILLER: And you can do the same thing in v6?

MR. CURRAN: Heather, given that, are you for or against the --

MS. SCHILLER: I'm still against. I think I said that at the beginning.

MR. CURRAN: Okay. Would you like to do any response and then anything?

MR. KING: I guess I'll briefly say -- again that I didn't mean to imply that these networks are all ownerless. I mean, for instance, the network that I am involved with, the Champaign-Urbana Wireless Internet Foundation, we own and operate the network. Like, we are the ones that have the access to the accounts to run all of the nodes. What we allow people to do is to buy a node and put our software on it. And if they put our software on it with our access information in order so it can connect to our network, then they are able to get connectivity through the network. But the network itself is not ownerless. Some of the devices are owned by the individual people. But the network itself is owned by the organization.

MR. CURRAN: Okay, thank you. I'd like to thank you for your presentation. (Applause)

MR. CURRAN: It's been pointed out that there's an upcoming International Summit For Community Wireless Networks. You folks have some handouts for that, for people who wish to attend. If you're interested in this topic, seek them out and they can give you a pass that lets you get to that summit, the International Summit for Community Wireless Networks. Thank you. As always, I come up here and we have a policy proposal that the AC's going to have to do something with. As such, it would be nice to have community input to help them in their judgment. So I am going to ask for a show of hands on advancing this policy proposal. And I'm going to ask for all in favor and then all opposed. So I am waiting for my very capable polling staff to be in place. And seeing that, I'd like to have the text of the policy proposal up, but I can live without it. So the topic itself is Policy Proposal 2008-3, Community Networks IPv6 Allocation, and I'm going to ask all those in favor of advancing Policy Proposal 2008-3, please raise your hand now. Thank you. All those opposed to advancing Policy Proposal 2008-3, please raise your hand now. Nice and high. Thank you. Ah, yes, at the microphone?

MS. ARONSON: I'd like to, if we could -- could we ask Scott's who's in favor of abandoning the question?

MR. CURRAN: I'm very happy to do so.

MS. ARONSON: Thank you, sir.

MR. CURRAN: Of course. So on the topic of advancing Policy Proposal 2008-3, the number of people in the room, 129.

MR. PLZAK: You said abandoning --

MR. CURRAN: Oh, sorry. On the topic of advancing -- thank you, Ray -- advancing Policy Proposal 2008-3, number of people in the room, 129. Those in favor of advancing it, 4. Those opposed, 40. I'm going to ask, at the request to -- for another show of hands regarding abandonment of this policy proposal. What?

SPEAKER: As opposed to?

MR. CURRAN: As opposing to continue work, obviously. If it's not abandoned, it will still be in their work queue and they'll need to deal with it. So when I ask the question, a vote of yes, by raising your hands, says you wish ARIN to abandon this policy proposal. So a raise of your hands for the aye vote is a vote for abandonment. So on the matter of Policy Proposal 2008-3, Community Networks IPv6 Allocation, all those in favor of abandoning this policy proposal, please raise your hand now. Okay. All those opposed to abandoning Policy Proposal 2008-3, raise your hand now. Okay, thank you. On the topic of abandoning Policy Proposal 2008-3, number of people in the room, 129. Number in favor of abandoning the proposal, 17. Number opposed, 34. Thank you.

Internet Governance Activities

MR. PLZAK: Now we're going to move to a report on internet governance activities, presented by Lynn. And here she is --

MS. ST. AMOUR: I just got the break message. So just one slide on the Internet Society, for those of you who don't know who we are. We were established in 1992 by Internet pioneers, notably Vint Cerf and Bob Kahn, and Vint actually served as the first executive director of the organization. We have over 28,000 individual members, almost half of those are actually formally organized through chapters worldwide. And there are over 90 organization members. We have regional bureaus established, at the moment, in Africa, Latin America, and the Caribbean, and South and Southeast Asia, with others coming online over the next year or two. And our mission is to promote the open development, evolution, and use of the Internet across the world. I'm going to talk about the IGF and if a little bit later, one or two other forums that are coming up that have a role in the Internet governance space, and also talk about why I think it's important for communities like RIRs, IETF, ISOC -- like many of the other organizations that you all participate in -- to pay attention to this area. It's not an area that we naturally gravitate to. It's probably not even an area many of us even value, but it is truly, truly important.

So this whole Internet governance topic actually began and had its origins in the World Summit on the Information Society -- to use a process that began back in about 2001 -- was a formal U.N. summit. It was actually initially scoped to address the issues of the digital divide, but very, very quickly began to focus on Internet governance. Internet governance at that point largely -- and largely still now -- was defined on management of the Internet as addressed through things such as the route servers, IP address assignment, technical standards, and specifically, the work of IANA and ICANN. So that was the genesis of the Internet Governance Forum. The Internet Governance Forum is one specialized forum to address Internet governance, but it is not by any means, in my opinion, the most important, and it certainly is not the only one. Forums such as this, where people are developing policies that actually help the deployment of the Internet are, in my opinion, much more vital to the development of the Internet, and to addressing the issues of Internet governance than an annual forum. But the IGF was established as a multi-stakeholder forum. It's open to participation by all. It's for dialogue on Internet matters; it's non-binding, it's not -- it's non-duplicative, which means it's not meant to address areas or activities that are actually covered in other Internet organizations, and it's non-binding.

It has the equivalent of what is a program committee, called the Multi-Stakeholder Advisory Group, the MAG. It's actually appointed by the U.N. Secretary General's Office, through a secretariat, which is also run through the U.N. It has, at this point in time, about 40 members. Half of those are appointed by governments, and half are drawn from the civil society and business communities. The Internet communities, which are also sometimes called the Internet technical communities -- and that is not a new structure, it's just a convenient label for all sorts of organizations, whether they're business, commercial, not-for-profit, standards organizations, as they actually participate in the development and deployment and management of some of the critical Internet resources. So ISOC, IETF, the RIRs largely roll up under civil society within this process.

And there's some statistics on the 2007 IGF, which was held in Rio. Over 2,000 participants: Roughly 300 businesses, 550 to 600 governments, and the rest from civil society. As I said earlier, the IGF is an important platform and channel. It's not the only one. The point on the bottom -- which is we get out what we put in, is something I want to address a little bit later in the presentation. So why is the IGF important? From our prospective, it's important because it's an evolving model of engagement, particularly as it reflects back to governments. Governments typically talk to governments. There are not a lot of forums for participation between governments and certainly civil society and private sector, all participating as equals. And any of you who participated in the WSIS or WGIG processes know that the Internet community organizations were actually barred from participating in many of the forums. There were recognized periods of time when you could speak. We had a relatively small percentage of time compared to the time the governments had. And the difference in IGF is that everybody participates as equals, without all those heavy hierarchical or government processes. It's an extremely important opportunity for us to expose governments to the Internet model, to the principles that have developed the Internet, and to the principles we want to continue to espouse as we move forward.

The IGF focuses largely on community building, and it's based on interest or topical issues, not on regional issues or regional bodies, and not in a government or political context. It focuses on sharing best practices, whether that's on capacity building or skills development, and it also is an opportunity to compare and contrast regulatory, technical, and social processes as they actually work to advance the Internet. Why is it unique? I covered some of this a few moments ago. There are no formal negotiations, no arranged seating, and no lengthy policy statements that have been prepared weeks in advance from which governments that you might want to engage in discussion are not able to stray from or, frankly, engage openly. It does encourage frank discussion among equals. The key is that it focuses on a more open exchange of views. It's very clear when you participate in those forums that there is much more learning, much more dialogue, much more engagement ongoing on the issues than there were in the more traditional intergovernmental settings or forums. So Internet communities and the IGF -- so, I second support of the IGF and it's predecessors since their very inception, as have many of the other Internet communities.

The RIRs have all been very, very active, both individually as RIRs, as well as through the NRO. IETF and IAB have participated at appropriate points, as has ICANN. We hear repeatedly that the participation of members from the technical community has always been extremely helpful. We've been constructive, thoughtful. We clearly understand what the Internet is about and how the Internet works, which is certainly a unique value in many of those forums. And luckily, it's getting a little bit less unique, but not nearly enough. We clearly believe that there's value in an open multi-stakeholder forum that encourages dialogue. I think one of the things we all need to focus on -- it is equally as good a platform for us about communicating our messages to other communities, with a special emphasis on governments, as it is about us helping in an educational capacity or helping address the issues they -- largely this has been very much driven by governments -- they believe is important.

So I think we need to work to continue to work to push that balance forward and make it clear that that forum is ours as it is theirs. IGF continues to evolve. It was originally chartered for five years. This December 2008 will be the third IGF. What happens after the fifth remains to be seen. There's a growing belief among some elements of the community that the IGF isn't -- it certainly has been successful in that nothing bad has come out of the IGF. There are people that believe, however, that it's also not produced as much as it needs to be. I invite all the RIRs and folks that are here in this room to step up and comment on any of these comments, but I think our general position is if it's encouraging debate and dialogue and discussion, that's as far as we want it to go. We're not looking for recommendations or statements of principles.

We're certainly not looking for formal summaries to come out of the IGF. That puts it, frankly, much more into an intergovernmental space, and will be treated as advisory by many parties across the world. And we actually don't think that that forum is the right forum, nor is it robust enough. So the bottom comment actually says that while it is a convenient place for a lot of these issues, I actually don't think it is the most important. I think forums such as this, where the people that actually deploy and develop the Internet get together in a bottom-up, open manner, develop policies and processes that support their users and their regional requirements. And that these venues are, frankly, more important in terms of aiding the Internet in its future deployment than an annual forum. And that is not to downplay the importance of that, it's just that it is not, by far, the only show in town. There's a number of links on this slide here. The IGF 2008 is in Hyderabad, India. The preparations this year have begun much earlier than past years. That's all good news. It has, though, moved some of the deadlines up with respect to such things as call for workshop proposals. That's the end of this month.

There are numerous discussions still open with respect to how the Multi-Advisory Group, the MAG Group, is actually constituted. They did agree that there should be a turnover each year. Their proposal is that a third of that turnover happens this year, but the mechanisms for replacing that are not yet known. It still, though, remains with the United Nations Secretary General's Office. The MAG has become more transparent. They used to have open community sessions and then -- for a day or so, would meet in private sessions for two days. Those sessions are still closed, but they are in fact publishing minutes and much more detail of the deliberations than previously. As I said, there are a number of URLs there if you want more information on either the main topics or the structure or any of the other preparations underway. Some of the key challenges for the IGF 2008, I mentioned a moment ago about maintaining participation -- at some level, the IGF has actually been very successful. I think we need to make sure that we don't walk away from that thinking this is just a talk shop, and therefore, we don't need to participate. I think our absence there, whether that's private sector or it's civil society or it's technical community forums, will certainly harm the forum. I think it will actually harm the Internet.

Frankly, it will leave those governments that feel strongly -- and they usually have contrary views to what we have about what makes a healthy Internet and healthy Internet processes -- frankly, it will leave them talking to themselves, which some people might argue would be a good thing, but I actually think there's a lot of danger in that. Members of the Internet technical community had a very significant role in shaping the IGF, trying to keep a balance between discussions on what they call critical Internet resources, like the address allocation, group servers, et cetera, before v6, and really focus on the issues that bring the Internet to the next billion people, and the billion people after that. That's focusing on things such as enabling access, openness, security, capacity building. Nitin Desai has been the chair of IGF and he was the chair of the Working Group on Internet Governance, the WGIG prior. His take on what the IGF's strength is that it actually brings together people who generally meet separately, again, in an informal manner which encourages dialogue. One of the things we'd like to do is to mobilize friends of the Internet. Those that understand the Internet model, want to work to promote it, and specifically to encourage participation in Asia. It is one of the reasons for this rotation in the IGF, and it's just an excellent opportunity to pull people in and get them to participate in the development of the Internet. I'll go here first.

There are a number of other Internet governance activities, so in terms of giving a quick tour of the things that happened -- there are a whole series of events happening in the second part of May that have to do with WSIS -- again, the World Summit Information Society -- activities. There are a number of commitments that were taken through that process, and this is a periodic report -- or periodic review of those activities. There's also the World Telecom Policy Forum, in the ITU in 2009. Some very, very key topics there. Things like Internet-related public policy issues, next generation networks. A number of us, including ARIN members, actually participate in that forum and in various parts of ITU, normally the standards and the development sectors. And again, if you have access to or visibility into those proceedings, I encourage you all to participate. The last bullet actually talks about the United Nations reviving something called Enhanced Cooperation.

In the WSIS process, there was an effort called Enhanced Cooperation, which was actually meant to keep the issue of management of the Internet on the table in a way that they hadn't been able to do through the two formal WSIS summits. That process basically was meant to encourage governments and other entities that are active in managing critical Internet resources to continue to participate on matters of Internet policies. Nitin Desai held a series of consultations with entities across the various communities, prepared a report for the U.N. Secretary General nearly two years ago, which has not been made public, but as we understand it, was basically favorable to many of the processes that take place within the Internet community. There's a new U.N. Secretary General, and they have just, in the last three weeks, sent a memo out which, uncharacteristically for the United Nations, was actually pretty direct, asking not only entities within the U.N. system, but entities outside of the U.N. system, to submit an annual performance report stating what they've actually done in the area of enhance cooperation. So ISOC received one, the IETF received one through ISOC, the NRO received one, OECD, ICANN, W3C, and we're in the process of trying to understand amongst the Internet community what their preferred response is to that. And I think, by and large, every one of them says what we do every day and what the Internet model is is built on enhanced cooperation. We will respond to the request, but basically by saying this is what we do, here are our materials. Look at our website here. Here are some other documents we've published for other purposes. That we are not going to respond as though we have an obligation to report to the United Nations on our activities having to do with Internet governance.

And again, I'll ask -- you know, any of the other communities that have specifically received one of these letters, if they want to stand up and comment on that later, then please do. I want to come back to this slide on the OECD ministerial this summer. It was a follow-up to the 1998 ministerial on eCommerce that the OECD had. They asked ISOC to form a group of Internet technical bodies, specifically to provide input to the ministerial, through a formal paper, as well as to prepare a day on the future of the Internet. So we're doing that again with IETF, IAB, W3C, ICANN, ETCI, NRO -- oh, I think most of the RIRs are actually participating as well, independently -- there are 13 other organizations. And I think that's actually -- you know, very, very significant that the technical community has been asked to submit a formal paper into the ministerial, as well as looking for input into many different areas having to do with technical developments. A number of these people, in particular RIPE NCC, I know, worked with the OECD very closely on a recent v6 paper.

There are some additional papers being developed. And this is our opportunity to make our points in a very credible organization with respect to what we think are key developmental areas for the Internet. And so we've got a very good participation. This process has been ongoing for roughly eight or nine months. There is a draft memorandum in preparation through that community, and it will be submitted as formal input to the ministerial. So where this matters to you. And then the next one is where this matters to all of us. But the RIRs are recognized as key players in the open Internet collaborative model, and I think that's important not just in terms of -- you know, a great display of what it means to participate in this type of model. It also stands as a very good counterpoint, if you will, for those people who might like a more centralized governmental approach to Internet governance. So apart from everything we do here in these forums specific to IP address allocation policy, or V4, v6 issues, the fact that these forums come together across the world and actually solicit input on issues of policy at an end user level, and a very open, accessible process, stands as an incredible model, truly an incredible model of how Internet governance can be done. And -- you know, it is just extremely important that we all recognize that even beyond the sort of policies that you might actually pass in any one meeting. So I said in one of the earlier slides that I think we need to take advantage of the IGF and other opportunities to explain to people how the Internet model works.

The only other alternative is to wait for generational change and -- you know, who knows what could happen between now and then. So as governments look to understand current Internet challenges, today the one that's the Internet challenge du jour is v4, v6. I think it's very, very important that we stand up and show the Internet model at its very best. Traditionally, that means we've put parochial interests aside and stood up and have done what is right for the Internet, for the stability, security, and continued deployment of the Internet worldwide. And ARIN in fact has a remarkable track record of doing that. You gave away a large part of your service region to two new RIRs, and then you actually helped them get up and running. You know, that truly is incredible. So we said now that the big challenge is the deployment of v6 as the v4 supply nears its end. The world is clearly looking for the RIRs to be effective in the role, and yet we all know that this is only one piece of making v6 deployment successful. There are many other players, many other entities, many other triggers, many other processes, that will actually determine whether or not v6 is successfully deployed or not. But in this room, many of us have multiple hats. I would encourage us all to take those hats and go back to these other forum and figure out what the right triggers are that are going to make v6 deployment happen. It's clear that you all continue to rise to the challenge. ISOC will certainly help you.

The IETF, the IAB, as you all know, are getting much more active in this space. ISOC is taking much more action as well. We've certainly expanded our organization. We, for the first time, have our own standards and technology department as opposed to relying on the IAB for that support. And that makes an enormous difference. You actually get to direct their activities Monday through Friday, not be fit in in a volunteer mode somewhere downstream. So it's made a tremendous impact. And you'll start to see a lot more in terms of ISOC looking for what are the key leverage points. No only for things like v6 deployment, but for other technologies. DNSSEC is another one. There are a lot of good technologies that are identified for deployment that don't get deployed because end-users don't know to ask for them and the market doesn't deliver them because they're not hearing a demand. And, quite frankly, quite often, there's not actually an economic model for that. So we need to find a way to actually encourage the right things to happen. None of us are responsible for deploying -- you know, those new technologies on the Internet. So we'll require some new models. Certainly, it will require all of us, I think, stretching out how we think about our roles and what are the things that we can leverage as we actually seek to get appropriate deployment of key technologies. So key challenges for all of us: Education, education, education. Promoting the Internet model and principles in support of a common and open Internet. We all live that so much, I think we forget what that means. We forget that that's not quite so evident to people outside of these circles.

The Internet community has worked on various maps over the year to try and show the organizations that are involved and relative responsibilities. And we're all comfortable working within that model. You show it to most government representatives and they just want to know who's the manager. You know, where's the hierarchy? Who oversees all this? Who says -- you know, go deploy 'X'? And we know that doesn't work that way, but there's a big bridge between the comfort level we have with the Internet model and what they understand as kind of traditional models. I think that another challenge for all of us is to work together, obviously, constructively, which I think we do very well, but without abandoning our own unique mandates or force-fitting ourselves into other's models or reacting to other pressures. Virtually all of the communities that have sprung up through the IETF have come up organically through expressed needs or identifying work that needed to be done, and finding the right place to house that. And I think we need to continue to evolve in that same manner. We all need to execute as well as we can in our various capacities, manage key challenges that come up before v6 space is being watched very, very closely. I think one of the things we need to recognize is that all of the opportunities to argue for increased participation by governments will be exploited. They will be exploited. We have seen multiple examples of quotes being taken out of context, and using that to try and argue again for -- usually, again, it ends up with greater intergovernmental involvement or more centralized management. So that was it. That was a really quick tour. Any comments from any of the folks in the room that have actually participated in these various forums?

MR. CURRAN: Microphones are open, folks. Anyone who wants to add their comments or have any questions for Lynn? Yes?

MR. BURKOV: Dmitry Burkov, RIPE NCC. Lynn, in your presentation, you missed, maybe not well-known, but enough important for governance discussion on NTIA midterm review. And what's your opinion as a participant on the last meeting, in February, about the future? Because as it seems that on IGF and other ITU activities, it will be a key point for the next year. And the second one, during this discussion in midterm year, have you -- a lot of participants mentioned also IANA services agreement?

MS. ST. AMOUR: Mentioned what?

MR. BURKOV: IANA services agreement. It's the second part of NTIA -- hidden part of NTIA. Thank you.

MR. CURRAN: Thank you.

MS. ST. AMOUR: So the question was two parts. One was the joint project agreement, which is the agreement between the U.S. government and ICANN. And the second question actually had to do with IANA, which in fact is not part of the JPA, although quite often, the two are conflated. So the current JPA between ICANN and the U.S. government is set to expire in 2009. And the U.S. government had an open consultation. It was triggered last fall and completed this February. ISOC's position, and I think that was pretty consistent for most of the other Internet organizations, was that ICANN has made remarkable progress with respect to transparency and performance against 10 key measures. In fact, the ICANN Board had assigned themselves, as well, but we felt it was premature to ask the U.S. Government to release ICANN from the JPA, and that we encouraged ICANN to continue to address several issues within their processes and to use the next 18 months to do that. Separate to the IANA services agreement -- you know, we'd all like the U.S. Government out of the route. On the other hand, I don't think anybody really knows of a better model.

The model most people move to most directly is some intergovernmental organization or something closer to the U.N. And most -- again I'm talking largely about the broader, sort of, Internet community and the private sector -- don't support that as a model. They really want it to stay within private sector leadership. So that's basically ISOC's position. We would prefer that the U.S. Government not have their singular role. We don't know of a better model today. We want to work with ICANN to understand what their long-term model looks like, both as it relates to the JPA and as it relates to their IANA responsibilities. And that we hope that they put a very open transparent process in place over the next 18 months to address that.

MR. CURRAN: Anyone who has any further comments or questions, please approach the mics very quickly. I'll be closing them shortly.

MR. WOODCOCK: So a question about containment.

MR. CURRAN: Name? Who are you?

MR. WOODCOCK: Bill Woodcock.

MS. ST. AMOUR: Bill Woodcock.

MR. WOODCOCK: Sorry. Containment versus constructive engagement in the ITU? There are a lot of very smart people in this room, but they're all very busy with actual day jobs that take a good 60 or 70 hours a week, and so, is there -- do you believe that there's any good that can come out of the ITU if a reasonable amount of energy were invested in attempting to turn it around or reform it, or whatever? Or do you feel that it's better to just ignore them and let them disappear?

MS. ST. AMOUR: Well, that's a loaded question. Or two or three. I don't think we can continue to face off to the ITU just looking in a containment manner. And the ITU, it's a very great organization, it's a big difference we talk about ITUD for development or the standards activities. ITU development is very valued and very well-respected, particularly in developing countries. And they spend an enormous amount of time and effort on developmental issues, but I don't think anybody would suggest that that should go away. I'm sure there are lots of suggestions on how to make it more effective and better, but not that it should go away. As it relates to a lot of the activities in the technical spaces -- standard space -- ITUT, that actually gets much more complex. But for those of you that are sitting here in large multinationals, you actually have participants in the ITU. So it doesn't need to be this room and this group of people that participate there. I think we need to participate, I think we need to participate actively. I would like them to understand the Internet model much more completely and feel much more comfortable with it. The IETF actually engages pretty broadly, through liaisons, with the ITUT activities.

MR. WOODCOCK: (inaudible) imagine of that?

MS. ST. AMOUR: Of that engagement?

MR. WOODCOCK: Uh-huh. Like, if we got everything we wanted, what would that look like?

MS. ST. AMOUR: So one would question -- you know, when everything is over IP, what does an ITUT do? You know, I -- it's a conversation -- I don't want this to be meant it is -- you know, we're all declaring the ITU should go out of business because everything going to be over IP and they are not needed. That will not be helpful to any of our discussions in the forums. I don't think we know that answer yet. I think governments and companies should help to address that. I mean, it doesn't feel like a satisfactory answer, but I don't know how to be more specific.

MR. CURRAN: I am closing the microphones, so final question?

MR. DURAND: All right. Alain Durand. I would like to say that some of the things that you're doing with community have a great impact in what discussion is happening at IGF, because what is really at stake is the model of the governments of the Internet has brought, in the process, that we are experimenting here. And things, for example, like how to handle the remaining of the IPv4 space. What to do, for example, with the last /8, or having original policies that may be different but somehow working to the same goal. There are elements that play very well when we go to IGF, and we have criticism that, oh, this Internet governance model does not work. We could have elements to actually prove that, no, it does work.

MR. CURRAN: Good point. I'd like to thank Lynn for speaking. (Applause)

MS. ST. AMOUR: Thank you.

MR. PLZAK: We are coming up a little bit behind schedule, but not to be concerned. So we're going to take a break in the Cyber Café, get connected, watch some presentations, get some information. And make sure you do the survey. Help desks are still open. And Mickey says, let's be back here at 15 minutes before 4:00, by this clock. (Recess)

MR. PLZAK: Let's get started. Sitting at the head table, we have John, Bill -- Paul's someplace -- Stacy, Scott, Alec, and me. Okay. Alec, you didn't get the same response as Stacy got.

2008-2: IPv4 Transfer Policy Proposal

MR. PLZAK: Okay. Moving on, we are now moving on to Policy Proposal 2008-2, IPv4 Transfer Policy Proposal, introduced in February of this year. The staff and legal assessment was done at the end of March. There is a similar proposal in the APNIC and RIPE NCC regions. I will say similar because they do differ greatly from this proposal, and there has been no introduction of any type of a similar proposal in either the AFRINIC or LACNIC regions. The proposal text is in your meeting packet. General understanding of this proposal is to allow an organization to transfer excess IPv4 addresses to an organization with a need for addresses, and creates a listing service. The shepherds are Scott Leibrand and Stacy Taylor. Counsel says liability risk, yes, but what he's saying here is that there's also risk if you don't to it, or do something like this. Okay, so there's a risk either way. It's continued fees, I guess. Staff comments: Language about may/should versus must/will, business failures and nebulous terms should be removed. Resources being transferred have to be rejustified per current policy. There's an audit exemption that conflicts with the RSA. Staff implementation, probably about 180 days. We've got to do some changes to software, templates, create the listing service, and so forth. And a lot of posts on the PPML about this one, generally seven in favor, three against, two undecided. Here's some comments that you could read. We did a poll on the PPML, using a poll, our polling mechanism, asking five questions. Starting from the bottom and working back, would you be at this meeting in Denver in person, and by far by and large, most of the respondents said no, they would not. Participating remotely? Again, most of the people said they would not. Then going back up to the top, do you feel that a proposal to change the current transfer policy should exist? One hundred thirty-two said they're undecided. The next largest number was yes, something should be done, and you can see the rest. Do you feel that you've been informed enough on the pros and cons of what a change in the policy would have in our Internet community? And 100 said yes, 172 -- so almost 2-to-1 said no. Do you feel informed enough in general to make a decision regarding a change to the current policy? And again, not overwhelming, but more no than yes. So with that, I believe Matt is going to do the presenting. And then John will lead the discussion, or moderate the discussion. While we wait for Matt, could we go back one slide?

SPEAKER: Yes.

MR. PLZAK: I'd like to wave to those 74 people out there participating remotely.

SPEAKER: Give them a hand.

MR. CURRAN: Should have remote participants. They claim that they'll be out there. ARIN welcomes remote participation. In this discussion, if you're a remote participant, questions are also welcome. So to the remote audience, I just -- it's very important to know you're part of ARIN. We welcome this participation, and that includes questions during this Q&A session. Thank you.

MR. PLZAK: Okay. Matt?

MR. POUNSETT: Give me one moment while I clean this up. Okay, getting closer.

SPEAKER: Good enough.

MR. POUNSETT: All right. Hi, I'm Matt Pounsett, one of the members of the Advisory Council, and I was foolish enough to volunteer to stand up here and talk to you about this policy proposal we've written. Now, though, since it's a fairly short policy proposal, and relatively uncomplicated, I figure we'll get through this pretty fast. So how did we end up here? As a lot of people know, the ARIN Advisory Council was asked by the Board of Trustees to consider all sorts of different ways that we might approach the issues of IPv4 depletion, promotion and transition to IPv6. We've talked about a lot of different things in that area, and one of the things that occurred to us would be a good idea would be to write something like this, primarily to provide a focus of discussion around these issues. So what we ended up with was this proposal, which we feel is the best we could come up with for moving in this particular direction. Whether we choose to move in this particular direction or not is another question.

So why this proposal in particular? Given that there's a lot of similar activity under way in other regions, that we felt it would be a good idea to make sure that whatever was proposed in this region both came from the constituents in this region, and much more importantly, reflected the requirements of this region and sort of our way of doing things. And we also felt it would be a good idea for this to come from a group like the Advisory Council, just because the development of this required quite a number of resources that wouldn't necessarily have been available to the average individual member. We used a lot of input from legal, from Ben Edelman, the economist that ARIN has hired, and spent a lot of time in meetings and discussions to come up with this proposal. The AC is not unanimous that this is the way we should be going. As I said, we felt that if we're going in this direction, this is the best we could come up with to go that way, to approach the problem. But we're not all unanimous that this is the way we should be going. And there is still dissension with the AC over various points as well within the policy.

So what's actually in it? The current policy we have right now essentially only allows for transfers of resources between organizations that have bought assets that use the resources, so buying an entire company, buying a network or customer base, things along those lines. Essentially what we propose in this at a very high level is to also allow transfers between organizations simply based on the receiving organization having a need for the address space and a willingness to trade something with the organization that's transferring it to them. So why allow it in the first place? This provides a continued source of IPv4 addresses for organizations that are going to have a hard time moving to IPv6 right away, either because they're just not nimble enough or they don't have the right skills or enough money or whatever their reason. And then on the other side, it provides incentive for people who have IP resources that they can easily migrate away from, either to IPv6, or by more efficiently using the addresses in their network. It provides an incentive for them to free up that address space and allow others to use it.

So to kind of point out where this falls into things, we have this spectrum of transfer policies. So at the extremes, we have no transfers allowed whatsoever, and at the other extreme, unrestricted transfers; people can trade addresses between themselves as much as they like. Our current policy is very close to the top of this, and only allows transfers with asset acquisitions, as I mentioned. This policy proposal we feel fits a little bit in the middle, allowing limited paid transfers outside of acquisitions of companies. And for an example toward the other extreme, for anyone who's been following it, there's a proposal in the APNIC region which allows transfers under many more cases than 2008-2 does. So what are the restrictions that we have in this policy? The transferor, the transferee, and the resources have to be and stay in the region. So we, for example, wouldn't allow an organization that is based in the RIPE region to pay for a transfer from an organization within the ARIN region. So this essentially prevents RIR shopping. It means that any differences in the restrictions on transfer policies in different RIRs will have less of an effect on what actually happens to these resources. The resources involved must be under an RSA. We're quite specific in the policy that it can be any RSA that ARIN currently recognizes. So this ensures that the transferor actually has the right to transfer these resources. In particular, there are legacy resources out there which are not necessarily entirely clear who has the right to use them at the moment. So this sort of protects those who are trying to get resources, to make sure that anything that they're paying to transfer, the transferor definitely has the right to transfer it to them. We included limits on deaggregation. The main reason behind that is to help prevent speeding up routing table growth. Some other restrictions: Transferees must qualify for the resources, so this essentially continues the need-based distribution of resources, to prevent us from significantly changing the requirements that we have now for people to receive resources. Somebody can't be both a transferee and a transferor. Once somebody has paid to receive IPv4 resources, they can't then turn around and transfer them out to someone else. Essentially, this eliminates the possibility of middlemen and speculation, so that people can't try and hoard resources; people can't use this policy to try and get large numbers of resources, hold on to them, and try and just simply make money off of trading in them.

We have a minimum holding time in there, so if an organization receives resources and then later decides that they don't need them anymore, they're restricted in how soon they can transfer those out. And again, this is to prevent speculation. So as I mentioned, the AC feels there are definitely still good points and bad points to this. Everyone has very differing opinions on that. So I'm going to cover over the pros and cons of this policy as we see it. But I've separated this up into actually three different groups. So the main set of pros, which cover the whole general topic as well as this particular policy proposal. The cons, we split up into one group, cons against a liberalized transfer policy in general. So these are aspects of this type of policy, not necessarily aspects to this specific policy, and then a group of cons specific to this policy and the way it's written. So the set of pros. Taking on something like this helps to demonstrate to the broader community that we are continuing to try and be good stewards of these resources, knowing that as IPv4 is depleted, these sorts of transfers are going to tend to happen anyway. Taking a step to put some controls on that is a demonstration that we're continuing to be stewards of this resource even after ARIN no longer has resources to hand out itself. Both parties involved in a transfer benefit from a redistribution. Somebody who needs resources gets them; somebody who can use the money and doesn't need the resources any more can get some sort of benefit that way. And overall, it's expected that this would reduce the total industry cost for a transition to IPv6, basically by allowing some organizations to put it off a little bit and not have to spend quite as much on their own transition. It creates incentives for people to renumber inefficiently used resources.

We know there are a lot of legacy allocations in particular, which were handed out under a different set of rules and therefore aren't necessarily as efficiently utilized as recently allocated resources. And so this creates an incentive for people to clean that up a bit if they're not using all those resources. After depletion, this would continue to allow new networks to acquire resources to run dual stack and communicate with the existing IPv4 network. Once ARIN no longer has addresses to hand out, if these sorts of transfers aren't possible, then new networks would have a much harder time speaking to IPv4. It promotes more accuracy in the WHOIS by reducing the number of unauthorized transfers. It maintains the accuracy of the data we have now, and as well, it's expected that with people signing an RSA that haven't previously, for example, it will bring up to date old WHOIS records that may not be accurate any more. It limits the need for expensive enforcement of the current limits on transfers. As I mentioned, a lot of people expect that these sorts of transfers are going to take place anyway, and having ARIN try to police that if we weren't allowing these sorts of transfers could be expensive. So cons to the concept in general. Potentially creates a false sense of security relating to the lifetime of IPv4. People might read this as being a way to extend IPv4, and therefore not feel that transitioning to IPv6 is quite as urgent. It attempts to solve a non-problem. IPv6 is available for people to grow into, and so why should they need to transfer anything anyway? It assumes that a problem will exist with a black market, which hasn't really been proven. Again, as I mentioned, a lot of people do assume that these sorts of transfers are going to happen anyway, but nobody really knows for certain if that's the case.

The perpetuation of IPv4 increases the use of things like NAT, proxies, dynamic addressing, things that generally add complexity to networks. It reduces the focus and resources directed to adoption of IPv6. It increases legal risk and complicates ARIN's position regarding addresses as property. I think that's pretty well self-explanatory. And this is an opposite view of one of the pros that I listed, that this significant a change to policies may encourage people who are not big fans of the RIR system to use it as an excuse to review the whole thing, because of the possible appearance that we are fundamentally changing the way we allow people to receive resources. Cons specific to 2008-2 itself. There are very restrictive rules on deaggregation, which might lead to some arbitrary decisions by staff, simply because the rules are not very clearly spelled out. There's a six-month limit on requiring transferees, people receiving resources, which basically says that they can't receive more resources within a six-month period. However, if they're unable to find someone who can transfer them a full six months' supply, then they may still run into problems. The complex restrictions within this policy might push people to going out to other RIRs, despite restrictions on doing that. So in addition to the pros and cons I've listed, there are also some sort of open issues that we think are still here, things that either haven't been dealt with satisfactorily or that are just not handled at all. The big one here is that the policy specifies a listing service but doesn't do anything to define it. The listing service essentially would be one way for people to list their desire to get resources, and to list resources that they're willing to transfer away.

As I said, the policy says that ARIN should provide a listing service, which would not necessarily be the only one, but again, it's not specific about anything about how that would work. In the long term, we think we need to have some more discussions with staff about what that might look like, and how much of the operation of that would need to be in policy versus just making operational decisions. The level of transparency and reporting with regard to the final transaction value for any transfer isn't there. It's arguable that there's some benefit to having the ability to report on how much a particular size of address block would be worth, but right now, there's no way to require people to report that back to ARIN, and so no way to report on it to the public. There's more work needed on the safe harbor section, which is section 8.3.7. The intent behind that section was to essentially allow somebody the ability to safely transfer away resources. Without it, if somebody puts up resources for listing, they'd be afraid that ARIN's going to see that I'm not using these resources anymore and come and audit me, say that I'm not using them, and take them away before I can transfer them. So the safe harbor section was intended to allow an organization to have a grace period there where they can move out of whatever resources they would like to trade, list them, have a reasonable period of time to trade those resources before running the risk of ARIN coming and taking them back. The problem, as we see it, is that it also potentially creates some loopholes for people to be able to do things like post a set of resources that they're not using for trade specifically to not get audited on them, but then just never quite find anybody to trade them to. And as well, there is the staff concern about a conflict with the RSA that would need to be addressed. And then there's striking a balance between simplicity of the policy and reasonable restrictions on transfers. There is a lot of complexity here, but a lot of it we felt was necessary in order to prevent this from just becoming a complete free-for-all in transfers. So that's essentially what we have to say about this. I haven't covered every single point of the policy. I've just tried to cover sort of the major ideas, or some of the more key ideas and points of contention, but there is a lot more there still that might be up for discussion.

MR. CURRAN: So at this time, we actually have open microphones for discussion of Policy 2008-2. Leo, you're marginally faster. Go.

MR. BICKNELL: Hi. Leo Bicknell, ARIN AC and ISC. And speaking for neither, only as myself, I am opposed to the policy as written. I believe that one of the largest dangers with this policy, and in fact with any transfer policy, is that by directly putting a monetary value on IP resources, we are going to attract a different level of interest, in that one of the key provisions in this policy is to maintain the current technical criteria, this notion of pre-qualifying. And I notice that ARIN has almost 3,000 members. There are 1,300 people on PPML, based on the earlier survey results. There tend to be about 125 people participating in the room today. And my concern would be, once that money's involved, and once those additional parties who are not showing up to the process today are interested, they are likely to show up and participate, and to participate based on purely financial motives. And if I look at other standards bodies -- for instance, JDAC, ISO, even the ITU or the IETF, money has had a very significant influence in them, and in many cases moved them away from good technical standards. So I worry that that will occur in the ARIN region as well. And the second problem that I have with this sort of policy in general is I think it really does take focus away from IPv6 deployment. It draws real resources in the terms of engineer money and time. It increases the problem of conversion, because people are still deploying more v6 items. And I think it really dilutes the message that the board was trying to sound, that v6 is our future.

MR. CURRAN: Okay, thank you. Any response? Front center microphone?

MR. VEST: Tom Vest, RIPE NCC consultant. A couple of questions, actually. I'll pose them to you as questions. Can you give us a sense of the percentage of ARIN allocated -- or notionally ARIN regional space which is not covered by RSA right now?

MR. CURRAN: So a point of information. That would probably be Leslie. Are you -- the question is, do we know what percentage is not covered by RSA? I don't know if we have that offhand. You'll work on it?

MR. VEST: If not percentages, then rough numbers.

MR. CURRAN: She'll work on that.

MR. VEST: In some sense, you're defining a large set of mechanisms which will apply to people who are RSA signatories, and you're counting on transactions to stay within that framework, where there are incentives and sanctions and things which attend to all RSA signatories. However, none of those apply to non-signatories. If a very large share of address space is currently in possession of people for whom none of these rules apply, they may well choose to join in, but it seems to me equally plausible that they will not wish to join in, and wish to market their resources independent of this process. I think that's a serious concern.

MR. CURRAN: And as a result of that concern, you'd be for or against it?

MR. VEST: Oh, I started to say, I profoundly disagree with the very idea, in all the regions. But so a second question: Suppose the optimistic assumptions about how resource transfer proposals would work ideally turn out to be wrong, turn out to not pan out, turn out that legal challenges start moving resources into the domain of private property, that compliance with other policy provisions, including WHOIS and things like that, starts to drop off? Basically, the things that we hope don't happen start to happen. Can you envision some mechanism for reversing or revising this policy, for putting the genie back in the bottle? Or is in fact the resource transfer initiative a one-way trip?

MR. POUNSETT: That's difficult for me to ask. I think that's getting a little bit into legal or economic precedent, which is definitely outside of the things that I can claim to be expert on. But personally, as a layperson in that area, I would be surprised, once those precedents start to be set, if the genie could be put back.

MR. VEST: Yeah, I would think so. Again, so in effect, the notion of an enduring policy community which has the ability to monitor the world -- what's going on to attempt to adjust, adapt to changing circumstance, and to improve on things or to correct mistakes in the future -- in this matter, those things would generally not apply. I agree.

MR. CURRAN: Let me ask you to respond directly, Tom, because I want to be clear for the audience. So to the extent that this policy creates a set of processes and functions that the greater community follows to effect transfers, those who follow these procedures would be paying enough attention to them to acknowledge the authority to have those procedures set and revised by this organization. Or are you contemplating that once this was done, a set of transfers would occur, and even the ability to change this would leave ARIN's control because of some other factors?

MR. VEST: If in fact optimistic assumptions about the enduring special status of address resources as not property, but rather as common pooled resources -- if that starts to be undermined by whatever legal challenges, then in fact, I think that something that becomes private property becomes -- disposition of that becomes the sole interest of the owner, and the policy community no longer has, I think, substantial claim on how they --

MR. CURRAN: So your concern is that potentially this would create additional focus on the question of addresses might be considered property as opposed to --

MR. VEST: No. Actually, mostly what I'm concerned about is the ability of the policy community to continue to be able to perform its duty to be able to revise, correct, and improve on policies over time in response to observation of changing circumstances.

MR. CURRAN: Got it, okay.

MR. VEST: That's enough for now.

MR. CURRAN: Okay.

MR. POUNSETT: Can I just -- let me advance the slide. I kind of held this slide in reserve in case it became necessary. There are a couple of things that the AC needs to know in relation to this. The first thing in particular that we're interested in knowing is whether people like the idea of this type of policy. Thinking back to one of my first slides, but the very high-level idea of allowing people to transfer resources in exchange for some value, and based on some set of restrictions. That's number one, the thing we're interested in knowing. In addition to that, if you're generally in favor of that, we would also like to know if you're for or against particular aspects, or whatever particular aspects of this proposal you stand up to speak about. And so we'd please ask you to mention both those things when you come up to speak.

MR. CURRAN: So front microphone?

MR. GIBBARD: Hi, I'm Steve Gibbard, and to answer the questions on Matt's slide there, I suspect that some sort of market, whether regulated or unregulated, is inevitable. And I guess I'm thoroughly undecided about whether this is the right way to do it or not. I had a couple of questions. First of all, if you could provide a little more detail on the restrictions you had in mind on deaggregation, and also what the thinking was in terms of how to balance the efficient use of space versus routing table size.

MR. POUNSETT: I'm sorry, I missed part of that last bit.

MR. GIBBARD: First, if you could provide a bit more -- you said there were some restrictions in this on deaggregation, and if you could provide a bit more detail on that. And also, what the thinking among those drafting the policy was about the importance of the efficient use of space versus routing table size.

MR. POUNSETT: Okay. In terms of deaggregation, the restrictions that we placed in there were intended to allow people to renumber into smaller sections of the address space that they have. And by necessity, that means they're going to have to deaggregate something in order to trade away resources. And so it was necessary to allow some deaggregation. But then the rules that have been placed in there were meant to try and limit -- you know, how that's done. I'm sorry, I can't remember the section number now.

MR. LEIBRAND: I can speak to that.

MR. POUNSETT: Scott.

MR. CURRAN: Yeah, go ahead, Scott.

MR. LEIBRAND: As you may have guessed, I was one of the ones that helped draft a lot of this. There's that allowing deaggregation for purposes of getting into a smaller block. There is a restriction on the opposing side for transferees, the recipients of the block, that's already been alluded to, that says you can get a block at most every six months. That block can be big enough to meet 12 months-plus of your need, rounding up to the nearest CIDR block, but you can't go back for another block for six months. That prevents people from, every quarter or every project, going and getting a new block transferred to them, which then would result in unavoidable deaggregation. In addition, on the transferor's side, there is the provision to allow ARIN staff to permit a certain level of deaggregation as needed. The intent there is that if a situation exists where most of the supply of blocks is of the large-block size, for example, legacies, /8s and /16s or some subnet of those, and most of the demand for block is of the small variety, say /22s and /20s, that ARIN staff would have the discretion to allow some level of deaggregation as needed to make sure that the relative price is fair across that entire spectrum. We chose not to allow unrestricted deaggregation there because of the concern that people, for shortsighted, unsound reasons would just go ahead and deaggregate everything as much as they can, thinking they'd get more money out of it. And that would be irreversible. So those are the restrictions on deaggregation as they're in the proposal. Now, your second question was about efficient use versus --

MR. GIBBARD: Versus routing table size. I assume the reason that you're trying to restrict deaggregation is to keep the routing tables under control.

MR. LEIBRAND: Yes, but we also recognize that each and every network that needs to advertise space on the Internet is going to use a routing table slot, and that routing table slot being smaller is more likely in the future because of attempts at conservation, but we anticipate that the rate of routing table growth will continue at approximately the level it continues now, unavoidably. What we're trying to avoid is accelerating that by forcing unnecessary deaggregation through economic pressures, and instead allow it to continue on what's approximately the current curve, which so far has been something that people can deal with.

MR. GIBBARD: Thanks.

MR. CURRAN: In light of that, Steve, are you still undecided or are there specific elements you'd like to speak against or for?

MR. GIBBARD: I'm still just looking for information.

MR. CURRAN: Thank you. Center mic, back, rear.

MR. SEASTROM: Rob Seastrom, ARIN Advisory Council and other. I am in favor of the general notion of a transfer policy which would exist where there hasn't been one before, although I pick a little bit of a nit with the notion that it's relaxed, because we're actually putting in a very big framework here. I'd like to point out, Tom mentioned markets and people making trades for stuff -- that's going on right now.

I personally hold some SRI NIC-issued address space. I have been approached about that address space. I know other people who have been approached about other address space. And any kind of transfer that would have happened of that address space would have been off the books, meaning that it would not have been reflected properly in WHOIS. I believe that there is a compelling interest in keeping the WHOIS data as accurate as it can be, and realizing that it is much less accurate than it should be right now. So to that end, I am in favor of having a transfer policy that legitimate organizations, regardless of whether they currently believe that they are within or outside the scope of the registration service agreements, will elect to do the transfers under as a method of keeping their risks lower -- the same reason that you might buy a used car at CarMax rather than from somebody with an advertisement in the paper.

Now, in the case of specific 2008-2 policy elements, I have been the person who has been banging the table loudest, I guess, about not deaggregating. And I understand that deaggregation over time, as Scott pointed out, especially as assignments get smaller, is inevitable. And I think that we're looking at a time very soon when the smallest allocation you can get is going to be smaller than a /24. Now, that said, I believe that the larger aggregates represent a unique resource, meaning that when they are given to large organizations, or transferred with monetary incentive to larger organizations that will announce them as a single aggregate, that will reduce damage to the routing table that would otherwise have happened had their requirements been filled out of many smaller pieces. And so I want to be extremely cautious about breaking up larger blocks. Even in cases where there are market liquidity issues, maybe the right thing to do with some of the very large blocks that might come back is to not deaggregate them more than a few bits. And there were discussions about the economics. I talked with Scott about this. I talked with Ben at length about this. And I'm not concerned about organizations that make a sensible economic decision and decide to break things up. What I'm concerned about is what we affectionately call jack moves from the pointy-haired boss who says, well -- you know, of course stuff costs more in little containers.

Take a look at the little can of Coke versus the two-liter bottle. We'll deaggregate these /8s and these /24s and put it on the market. Done deal. And they're the people who make the decisions in the organizations, so I want to make sure that whatever we put through has incentives to not do that. I'm very concerned about that. Now, in summary, after having rambled on about that, I --

MR. CURRAN: In short summary.

MR. SEASTROM: In very short summary, I'd like to point out that we could really go on tweaking this for a very long time, like months to years, and that having some sort of framework in place is exceedingly important as we approach the date where the ICANN or the IANA free pool runs out.

MR. CURRAN: Okay.

MR. SEASTROM: And the sentiment that was expressed by von Clausewitz and by Voltaire and by Sergei Gorshkov was that better is the enemy of good enough, and that we ought to think very carefully before we try turning the knobs too much.

MR. CURRAN: Thank you, R.S. Any response or comments?

MR. POUNSETT: I guess just one thing, to something you mentioned near the end, as just kind of a counterpoint that I heard somebody else bring up, the idea that deaggregating large blocks in order to sell them as smaller blocks might be very financially attractive. And somebody made the suggestion in a discussion a couple days ago that smaller blocks actually aren't worth more per address, that the people who need the very large blocks will be likely willing to pay enough to keep the cost per address much higher in a /8 than it would be in a /24, for example.

MR. SEASTROM: I believe that once there's history out there, that will be absolutely borne out. I'm concerned about what people do, ill-considered, at the very beginning.

MR. CURRAN: Far microphone, yes?

MR. DURAND: Alain Durand. I'm very scared about all of this, so I'm not really sure if I'm pro or against, but I have a number of points which I would like to make. I'm concerned that a transfer policy is essentially not going to address the right problem. It seems to me that the goal here is to use things that we were allocating before, and prolong the life of before, when in my opinion the goal should be more to ease the adoption of v6. And we are somehow missing the point here, because if a large company, which is a lot of IP addresses, tried to get on the market and tried to get to /8 or smaller than that, it's going to be really, really hard, because there's not that many of them. So I'm afraid that there is not going to be enough liquidity for large blocks to make the system viable. And we are seeing some of the statistics which were published recently that a lot of the addresses that were consumed by ARIN in the last couple years were consumed by large organizations.

So if we design a system that does not work for a large organization, in my personal opinion, we fail. So that's the number one point I wanted to make. Number two: I'm afraid that we are going to create a new set of issues that we don't really know how to deal with. One issue is, what's going to happen in between registries, inter-registry transfer? If we have registries with very different sets of policies, and some have very, very low criteria, and some have strict criteria, it may be possible that somebody may simply go to the registry that has the least constraint. And maybe that ARIN may not recognize this, and that another registry, for example, APNIC, may have less constraint, may recognize the transfer. And then we have an inconsistent WHOIS database. And it's a bit of a problem. I'm worried about costs, and cost as a buy-off of entry for new players. If prices that I've heard come really true, like $100+ for an IP address, maybe even more than that, this is a very serious cost. And I can imagine a new entrant going to his representative, going to the national regulators, or even to the ITU, and saying this is not fair. The incumbents are putting barriers of entry for the new players. And this entire bottom-up process that we have created here might be overhauled by regulators and ITU. I point to the presentation that we had from ISOC about IFG and all those earlier on. I'm also afraid that -- I'm just finishing on this one -- I'm afraid that this is going to delay the adoption of v6 by sending the wrong message that we have many years of supply of v4, and essentially diverting the energy out of where it should be. But bottom line of this is, I'm afraid that we are going to let the genie out of the bottle, and there is going to be very little way to put it back.

MR. CURRAN: And in summary, you would be still undecided? Even though you have these concerns, you are not against this proposal?

MR. DURAND: I'm not 100 percent against this proposal, because if we have to have a transfer policy at all, I rather like this one rather than the one we have in the APNIC region.

MR. CURRAN: Thank you.

MR. POUNSETT: What about -- how do you feel about the concept of a transfer policy in general, not just this specific proposal?

MR. DURAND: If we could avoid it, we will be in a much better place.

MR. POUNSETT: Okay.

MR. CURRAN: Okay, thank you. There's a number of people at the microphones. I just want to warn people I will be curtailing your speaking to a short period of time and a few number of points. So try to keep your conversations to two minutes or so, given the number of speakers we have. Yes?

MR. VEST: Tom Vest again, for NCC. Interesting follow-up on my question about the enduring relevance of the policy committee. You just speculated about the possible per-unit cost of IP addresses, thinking that perhaps they would be higher or lower under different conditions. Well, in the absence of policies and some effective mechanism to collect that information, you'll never know whether you were right or wrong.

MR. POUNSETT: That's true, yeah.

MR. VEST: So it's completely immaterial what you're speculating -- you might as well basically disregard all speculations about that unless you plan actually to figure out some way to be able to monitor that and to make that information useful to people. But the real point is, and this is a point that I wanted to bring up with the poll online as well, is that people who are against resource transfers are not necessarily people who have their heads stuck in the sand. I think everybody agrees that some form of recirculation of addresses is required; that some incentive system is required as well. Not necessarily the kind that are captured by either relaxed transfers or 2008-2 more specifically. The policy itself actually -- there are three fundamental structural changes it includes. It's changing the status of some common pool asset, maybe not privatization, but some major change in status; changing the mechanism distribution from a single source to distributed; and then changing the medium of exchange that you use, that you exchange to get that resource. And there are -- you know, people could have different opinions about each of those factors. In fact, when those three factors are bundled together, and those three reforms are done simultaneously, there are some historical cases that you could look at and see whether or not they worked the way the were expected, that people speculated that they would or not. So I think -- I would urge you to stop characterizing this as do you want Resource Transfer Policy 2008-2 or are you sticking your head in the sand. I think we could all think a little bit more out of the box about this challenge.

MR. POUNSETT: I don't think we're characterizing it that way at all. As I said, the AC isn't even of one mind on whether we should go in this direction. And so I think it's -- since we're not even agreed on that, I think it would be difficult for us to be suggesting that that's the way to go and that any other way is ignoring the world.

MR. CURRAN: Center rear microphone?

MR. ECHEBERRÍA: Thank you, Jim. I am Raúl Echeberría. I'm the CEO of LACNIC. First comment is only to inform that at this moment, there is no policy like this or proposal like this under discussion in the LACNIC region. This proposal seems to be very interesting. I don't want to express myself either for or against the policy because of my condition of staff member of another RIR. But I tend to think that at some point, in some way or another, some kind of policy like this would be necessary for dealing with the problems that we have to face in the future. What I want to do here now is to share with you a specific concern that exists in LACNIC regarding this proposal, or proposals like this under discussion in other RIRs. That is what is related to the legacy space. This proposal, in case of being adopted, will permit the trading of legacy space. As you know, I assume that all of you know that most of legacy space has been allocated in this region for a long time. So in case of being adopted -- the policy as it is now -- it could permit the trading of legacy space between ISPs or organizations within the ARIN region. Our opinion is that the legacy space is of interest to all the RIRs and not of interest to only one given specific RIR. So what we want to express is just that it seems to us at least inconvenient to adopt the policy in this specific point, as it deserves much more discussion, and also consultation with other RIRs and communities from other regions, due to the impact that it could have in the global Internet community. Thank you.

MR. CURRAN: Thank you, Raúl Okay, far right microphone?

MR. DeLONG: Owen DeLong, ARIN AC, and speaking entirely on my own behalf at the moment. I'm against the policy as written, and I'm against the concept of a relaxed transfer policy in general, partially for the reasons expressed by Leo. Partially, I actually started out, when we started authoring this proposal, in favor of doing something like this. But as we started trying to iron out the details, we discovered more and more devils hiding in the details. And we've finally come a point where I'm convinced that there's just no real way to get this sufficiently right, that I don't think the potential harm from letting the genie out of the bottle is overshadowed by the potential good. I think that it is quite the reverse at this point. Thank you.

MR. CURRAN: Thank you. Go ahead, far left microphone.

MS. CLAFFY: Yeah, I guess I'm going to echo some of the other comments. As a sort of quasi-academic, I have to say I'm really nervous about listening to this conversation, because although I find a lot of the stuff in academia offensive, I kind of find this level of conversation offensive, too, because it seems like there has been so little investigation and analysis of historical precedents -- not that we can point to direct historical precedents -- but I'm pretty sure there's some stuff we can learn from history and other attempts to do market reforms or transitions of public to private resources. And I don't find that level of analysis going on here. So I'm just wondering, first of all, what went into this policy? How did you -- you know, academics have to cite stuff. So I'm sort of down to a very strict mode of discourse. I'm not saying we shouldn't necessarily go that far in here, because it gets a little nutty, too. But I feel like we should maybe go a little toward there. So what went into the proposal, historical thoughts or analysis of things that have been done in the past? I can tell that most of the people in the room aren't paying attention, so I'm not sure that these people are necessarily the ones to go do it, or even the folks in ARIN or on the board. But I do feel like some FTEs should be allocated to working on this problem full-time for at least a year. This is a big problem. This is the biggest transition that's happened since I've been studying the Internet. It's huge, and frankly, I feel like the conversation's a little narrow. So the big suggestion I gave two and a half years ago, when I gave this talk, is to have at least some kind of scenario of planning workshop, where you have lawyers in the room, economists -- I know we don't want a lot of lawyers in the room, but there are too few lawyers in the room for this conversation to be happening. So that's one thing. And then I want to read a quote.

MR. CURRAN: I wanted her to get her second point. Second point.

MS. CLAFFY: Yeah, written by a legal historian, one of my favorite legal historians, Eben Moglen. So I'll just read this. It's not written about IP addresses -- totally different space -- but it was kind of eerie to think about IP addresses when I read it again. "In my role as a legal historian concerned with the secular (that is, very long term) development of legal thought, I claim that legal regimes based on sharp but unpredictable distinctions among similar objects are radically unstable. They fall apart over time because every instance of the rules' application is an invitation to at least one side to claim that instead of fitting in ideal category A, the particular object in dispute should be deemed to fit instead in category B, where the rules will be more favorable to the party making the claim. This game about whether a typewriter should be deemed a musical instrument for purposes of railway rate regulation, or whether a steam shovel is a motor vehicle, is the frequent stuff of legal ingenuity. But when the conventionally-approved legal categories require judges to distinguish among the identical, the game is infinitely lengthy, infinitely costly, and almost infinitely offensive to the unbiased bystander."

MR. CURRAN: Okay. ARIN actually retained services of an economist to assist us in looking at this. Ben, do you want to comment?

MR. EDELMAN: Sure. kc, I've been thinking about this for -- I don't know, a year professionally for ARIN on the clock, and some time before that, too, in terms of the methodology. The methodology consists of knowing what I can know about the economic discipline of market design; that people who opine on spectrum auctions, for example, but also how to get kidneys from the people who have them to the people who need them, how to get the right high school students into the right high schools in New York City. There is an academic literature. I'm fortunate to have on my hallway, actually, two doors down, Al Roth, the man who did kidneys in the national residency match program and Boston Public Schools. It goes on. So if the citation is to him, I don't know my mentor and friend, and someone thinking about this on our team. Beyond that, the methodology is talking to people, writing memos, going to meetings, and discussing. I'm not clear on good methodologies beyond that. As to empirical methodologies, everything we'd need to study is so far out of sample that the kinds of data you can get don't seem particularly helpful, and Jean Camp's 40- to 200-year estimate this morning I think crystallized that view for me, that there's not much we can do empirically. Now, in terms of the restrictions, we know how to push the lever one way or the other way. We know how to make small blocks more expensive relative to large blocks. We know how to make more deaggregation or less deaggregation. So in terms of thinking that we know how to fix a problem if we stumble onto it, I think we're headed in that direction. But as you say, it's an awfully big deal, and it's hard to fit this into any pre-existing literature on this or other closely related subject.

MS. CLAFFY: That's why I want current existing literature. We have to write the literature; we have to do the analysis; we have to study the history and find out what lessons we can draw on from the past. I'm sort of yelling at myself, too, because we should have done some of this work, too, but CAIDA doesn't actually have the kind of skills that I'm talking about here. It is interdisciplinary, what we need, which is why I think there should at least be a workshop. I don't -- without impugning your qualifications, a one-person FTE isn't enough.

SPEAKER: There have been several workshops.

MS. CLAFFY: Workshop, please.

MR. CURRAN: Right. Let me just clarify: The proposal came from the -- this particular one came from the Advisory Council, which had a day-long retreat -- actually a two-day retreat to consider this matter, with assistance from Ben and others. And there's been multiple other workshops on address depletion. So I agree with your concern about the level of study, but it's also very hard to say that there hasn't been discussion or study. There's no empirical evidence, as Ben pointed out, that we can point at one-to-one, and it's pretty much an open table as to what happens going forward. There's no parallels that you can draw that have all the characteristics of what we're facing with address space.

MS. CLAFFY: Not all the characteristics, but certainly some of the characteristics. I understand we're at a place that no one's ever been before in some dimensions. That's why it's all the more important to know what we can learn from the other dimensions that we do share with previous incarnations of this problem. And I don't -- I mean, again, I think it's great that the Advisory Council went away for two days to think about this, but -- you know, academics spend six months writing one paper full-time. And those are crappy papers sometimes, right?

MR. POUNSETT: There's actually a lot more that went into it than just that. The AC went away and did a two-day retreat to begin this discussion. That was three months ago? Yeah. And we've spent an incredible amount of time on it since then. This isn't the product of 16 hours of people sitting around a table talking about stuff. There's quite a bit more that went into this than that.

MS. CLAFFY: As a student -- is there things that students can go do? Is there a Web page or papers or documents or notes or minutes or anything I can read to learn what you guys know that enabled you to make this proposal that I could never have made myself?

MR. POUNSETT: That's been collected in one spot?

MS. CLAFFY: Yes.

MR. POUNSETT: No.

MS. CLAFFY: Can we get it?

MR. CURRAN: All on the ARIN policy proposal page. That's where the proposal is, and the discussion's on the mailing list, kc It's no different than any other proposal.

MS. CLAFFY: Okay.

MR. CURRAN: All right. Center microphone?

MR. SCHILLER: Jason Schiller, Verizon Business, UUNET, and the NRO NC. On the general question of transfer policy, I think I am in the same camp as R.S. Based on the comments of him and others, it's very clear to me that there is legacy space that's being exchanged for money or just being outright stolen. Geoff Huston has reports on this. And it seems to me that if space is going to be shifted around, let's at least have it be aboveboard. What I want to focus in on, though, is the extent to which deaggregation can occur under this specific policy. So I'd like a little bit of clarification. When I look at 8.3.3, it basically says that the size of the transferred block can be as small as what is the current minimum allocation, which I read to be a /22. Is that correct?

MR. POUNSETT: Yeah, yeah, I think so.

MR. SCHILLER: And if I'm using some of that space, I can retain some of the space that I'm using. So hypothetically, let's say I have a legacy /8 and I'm using one /24 in the middle, does that mean that I can break that down to 16,384 /22s --

MR. CURRAN: No.

MR. SCHILLER: Keep one /24, and then have three hanging over that are useless?

MR. CURRAN: No. Do you want to answer directly, Scott?

MR. LEIBRAND: The case -- in that case, if you have a /8 and you need to keep a /22, you would --

MR. SCHILLER: A 24.

MR. LEIBRAND: You can't keep a 24. You have to keep a 22.

MR. SCHILLER: Okay.

MR. LEIBRAND: You could transfer a /9, a /10, a /11, a /12, all the way down to a /22, and that would be something on the order of 22 minus 8 blocks.

MR. SCHILLER: Can you specifically point to the text in the policy where that's written, because --

MR. CURRAN: It says when you split off your block and you get to do a transfer, then you don't get to do another transfer.

MR. LEIBRAND: It's two contiguous address ranges, so there's the address range that's .0/22, and then there's --

MR. SCHILLER: No, no, I understand how to subnet.

MR. LEIBRAND: But no, my point is this second address range consists of a /8, a /9, a /10, et cetera.

MR. SCHILLER: What I read is: "Conditions on the IPv4 address block to be transferred: The block must comply with the applicable ARIN requirements, including minimum allocation size, i.e., NRPM 4.2.2., 4.2.4" -- is there another section that says --

MR. LEIBRAND: Yes, it's section 8.3.2, last bullet point, "may retain one contiguous address range and transfer the rest."

MR. SCHILLER: But it doesn't say as the largest possible CIDRs.

MR. LEIBRAND: Yes, it does. It says if it consists of nonaggregatable CIDR blocks, you can transfer them to different --

MR. SCHILLER: I see.

MR. LEIBRAND: Transferees, but otherwise it has to be transferred as a contiguous CIDR block.

MR. SCHILLER: So then if I'm keeping a 22 and I have a /8, then that's 14 blocks?

MR. LEIBRAND: Yes, not 16,000.

MR. SCHILLER: Great. That helps me understand to what extent we're going to deaggregate. The second point I wanted to make was -- I think, Matt, you said that if people are keeping some of the space, then deaggregation is inevitable. And I just wanted to point out that that's not necessarily true. We could require the transferor to renumber into new contiguous space, and that cost and pain of renumbering can be rolled up into the price of the transfer.

MR. POUNSETT: I have one question. Where would that space come from?

MR. SCHILLER: If there's an open market for space, they could find a /22 and -- you know, basically like selling a house. I would like to sell my house, but I need that money to make a downpayment on another house. You can have my house when I have found another house. You can do the same thing with the market.

MR. LEIBRAND: Jason, that's a valid concern --

MR. SCHILLER: I'm sorry, just to continue, or we could designate the last /8 that a portion of it is kept in reserve for renumbering.

MR. LEIBRAND: I think that would be a real concern and a thing we ought to consider if we didn't have the fact that most of the demand for additional space is going to be of the smaller block variety rather than larger block, so ARIN's going to most likely have to allow some level of deaggregation anyway. So the level of deaggregation that comes with people keeping the smaller portion of their larger block is probably going to be less than is required to meet the demand.

MR. SCHILLER: I'd like to see your data on why you think people are going to need smaller blocks rather than larger blocks.

MR. LEIBRAND: Because the blocks allocated in past years -- we have data for this -- tend to be on average size much smaller than the blocks that were allocated in the past. And we don't know for sure what people are going to free up of past blocks, but the entire population of available blocks has a higher average size than the population of blocks allocated recently, and I expect that trend to continue.

MR. CURRAN: Excuse me. I am closing the microphones. There will be more time to comment on this tomorrow, but I just want to let people know the microphones are presently closed. Okay, Jason.

MR. SCHILLER: And finally, I had a question for Alain and Raúl that basically expressed concerns about most of the legacy space being in ARIN and this policy affecting globally what's happening. Do they think that this needs to be a globally coordinated policy, and would that change whether they were more or less in favor of a policy like this one?

MR. CURRAN: Alain or Raúl, if either one of you would like to approach a microphone?

MR. SCHILLER: And then, while they're approaching, my final point is, I would certainly be in favor of a transfer policy in general that's more constrained in terms of the number of additional routes it's going to create.

MR. CURRAN: Got it. Alain?

MR. DURAND: I would like to see the different policies in the different registries allowing roughly the same level of constraints.

MR. CURRAN: Okay, thank you. All right. We have Bill. Yes?

MR. WOODCOCK: Bill Woodcock. Less is more. We have what I believe is a really good idea fundamentally here, which is getting ARIN out of the business of telling people that they can't incentivize each other to do useful things. But that good idea is, as Tom said, getting wrapped up in this huge, ugly hairball of bundled other projects, right? You know, we have two responsibilities: We have one responsibility to help people get the address space that they need, and we have another responsibility of stewardship to keep the whole project from getting too ridiculous, right? Beyond that, I don't see that we need to be creating auction houses or online listing services, or writing 15 paragraphs where one will do. I would really, really like to see the AC work harder at drafting policies that reduce the total verbiage of the policy document rather than increasing it.

MR. CURRAN: Bill, as written, do you have a thought on --

MR. WOODCOCK: I do not support it as written. I support the basic premise. I specifically have problems with anything that gets ARIN involved with the transaction itself rather than recording the transaction.

MR. CURRAN: Understood. Front center microphone. Yes, Paul?

MR. WILSON: I've got Geoff Huston on the line. He's watching. He did send this to the public comment forum, but it hasn't come up yet.

MR. CURRAN: Richard's got it over there.

MR. WILSON: Well, I'm here, Richard, so I'll do the honors, and I've also got an update or two. So Geoff has said, "I observe that the proposals before RIPE and APNIC are radically different and could be characterized as laissez faire." That is, radically different from the ARIN proposal. "To what extent is the underlying principle of defending the routing system from some dire fate in the ARIN region if other regional fora do not share this concern? Is it more important to preserve the integrity of the regional system and be pragmatic about what industry players do to each other, or more important to be seen to be doing the right thing irrespective of its actual relevance to industry actions?"

MR. CURRAN: Okay.

MR. WILSON: So that's Geoff's comment. Further to that, and particularly in response to kc's question, he does refer you to RFC 1744, December 1994, written around March 11, '94 so --

MS. CLAFFY: (inaudible)

MR. WILSON: You'll find some similarities in what was discussed there and what was described as motivation, but it was in response to the sort of implication that maybe people hadn't been thinking about this very long.

MS. CLAFFY: Does Geoff stand by that RFC now?

MR. WILSON: Well, he's on -- he's --

MR. CURRAN: Yeah, we'll have to find that out. Okay. Any other comments, Paul?

MR. WILSON: That's it, and nothing from Geoff just yet.

MR. CURRAN: So would anyone like to -- would you like to respond to Jeff's question regarding the value of having an address transfer policy which protects the aggregation and routing system if the other RIRs don't seem to be going in the same way? Would someone like to comment on that? Yes, go ahead, Scott.

MR. LEIBRAND: I have lots of comments, which I'll try and keep brief. It seems to me that the policy proposals of APNIC and RIPE tend to simply ignore what is a large problem, and I'm not quite sure why they're not concerned about it, to be honest. I also think that we've got a responsibility to balance that concern with the allowing of legitimate transfers, and as shown on that continuum slide, I think the current ARIN policy is too conservative; the proposed APNIC policy is too liberal; RIPE is a little bit on another axis and might be somewhere in the middle; and I think we have to strike a balance that gets us at the Goldilocks point. And I'm not sure that 2008-2 is quite there yet, but I think it's a lot closer than any of the other policy proposals I've seen, because it does really try to strike a balance between a large number of competing interests. If there were just one thing we had to optimize, it would be easy. But there are multiple dimensions, so we're trying to solicit community input on all these different dimensions that we need to optimize for, including simplicity. And I've heard general complaints about various things, but I'm really lacking in suggestions for how to improve things, so if people have specific suggestions that they can post to PPML on how to make it better, please do.

MR. CURRAN: Recognizing that he's remote, if you want to take a moment and spend some time to compose with him, you can respond to that. I'll allow you to enter back to the mic.

MR. WILSON: He's just said a couple of things. He said "Hi, kc" He said, "I stand by it ABSOLUTELY," in capital letters. And he's also said, "We have to recognize the value that we bring to the Internet and what we CANNOT," in capital letters, "do."

MR. CURRAN: Okay. Thank you. Okay. Rear microphone, yes?

MR. OBERMAN: Kevin Oberman, ESnet, though speaking for myself. And I am opposed to the policy as currently stated.

MR. CURRAN: Okay.

MR. OBERMAN: I think the policy does not take into account true market forces. If I'm in business, and my business survival depends on getting some address space that I cannot get under this transfer policy, I'm definitely going to go to the black market. I'm not going to go broke because ARIN has a policy which I think is wrongheaded. And if my business is going to go broke because of that policy, I don't care what it is, I'm likely to decide it's wrongheaded. So people are going to do that. People are going to do RIR shopping, and in fact, they already are. I believe it is likely that one fairly large service provider in this country, who also does business overseas, is likely to transfer all their address registrations to APNIC for exactly this reason. Don't know that for sure -- you know, that's to a certain extent hearsay, but I know it's going to happen. And any policy that does not recognize those facts, instead of simply saying we're going to set these rules so this won't happen, has no chance of success whether it passes or not, because it will simply be ignored.

MR. CURRAN: So let me ask, this particular relaxed transfer policy in general you're in favor of?

MR. OBERMAN: I'm in favor -- there has to be a transfer policy or the whole thing becomes irrelevant for --

MR. CURRAN: But you're against this one because you feel it's too many constraints.

MR. OBERMAN: It's too complex, too many constraints; mostly I agree with what Woody said. The idea of Woody and I agreeing on a socio-economic issue is mind-boggling to me, but yes, I think Woody said it quite well.

MR. CURRAN: Thank you. Far right microphone?

MR. LEWIS: I have a question to try to understand this policy. I'm undecided because I don't understand everything yet. The holder of the space has to deserve the space, demonstrate need right now, I'm assuming. Otherwise, they won't have the space. The person who wants the space also has to demonstrate need for that, also. And when you have two sides that both deserve space and they want to transfer it, there can be some money going back and forth. What if the holder is -- their space is being reviewed by ARIN to see if they actually deserve it? ARIN decides that they don't deserve the space anymore. Are they going to lose the space through that review, and then throw everything else up in the air?

MR. POUNSETT: I think -- if I understand your question properly, I think the thing that addresses that is the Safe Harbor section, which I talked about. There's a provision in there -- Section 837, I think it is -- which specifically exists to prevent ARIN from doing an audit on someone who has just announced that they have his space available to trade.

MR. LEWIS: I guess what I'm really concerned with here is the person getting the space has a demonstrated need that if there was a space available, they would deserve to have it under normal process.

MR. POUNSETT: Yes, that's right.

MR. LEWIS: So this isn't exactly like buying and selling addresses. You see, I don't like the idea of a market at all. I'm trying to avoid a market. What I'm trying to understand is the transfer policy of registration, who has it? And I'm somewhat more for letting people with a transfer for a legitimate use of addresses. And if money is used to make someone become more efficient, but I don't want it to also be a free market where I can just go out and buy the address I want. That's what I'm concerned about.

MR. POUNSETT: Yeah, we definitely tried to address that. Scott was mentioning that there are a lot of different dimensions that are -- you know, pulling on this idea. And a couple of the things that we were trying to balance out is the need to -- or desire, to maintain needs-based distribution, but also allow people to give each other incentive to be more efficient. And so yeah, it is maintained in there that in order to be a transferee, in order to receive resources, you must have -- be able to qualify for them as you would now -- you know, when ARIN has the space to give.

MR. CURRAN: Richard, remote participation?

MR. JIMMERSON: Yes, we had two comments from the remote participation facilities on this topic. The first one is from Lucy Lynch. She's stating her full support for Rob Seastrom's comments at the microphone earlier on on this topic. The second comment was from Geoff Huston, and that comment's already been read verbatim by Paul Wilson.

MR. CURRAN: Thank you. Okay, center front mic?

MR. FARMER: David Farmer, University of Minnesota. I'd probably say I'm for a relaxed general transfer policy, and undecided, leaning toward against, on the specific one.

MR. CURRAN: Okay.

MR. FARMER: There's a couple of ones I want to bring up real quick. One is, I think no matter what happens here, there's an important piece that I think is not covered in the policy, and that is dispute resolution. There will be disputes, and ARIN and the registries as the entities that are deciding who is the authority for those addresses is going to have to address dispute resolution. And it -- because it's just going to happen.

MR. CURRAN: Dispute resolution. Steve, you want to take that?

MR. RYAN: I think the contemplation in this policy is the dispute resolution would relate to the clauses that are in the RSA. So there's a preference always for arbitration there, but there is a dispute resolution mechanism in each RSA. The policy requires you have an RSA; therefore, there would be a dispute resolution mechanism. Let me take one minute on this, because I think it's important. The current transfer policy with the way it exists is going to force ARIN to make very difficult choices. For example, let's assume that we find, based on intelligence we receive in the marketplace, that there's a transfer going on of a /16 for $150,000 by a company that deliberately sends us false documentation. If we go out and revoke the space, the traditional American response is that they sue the person revoking, argue that the arbitration clause shouldn't occur, and that we are an anti-competitive conspiracy, all of you being the conspirators and I congratulate you on that. So if we stay with the current policy, and I'm not going to speak for or against this policy, but if the current policy has significant litigation risks for us, adoption of the policy will similarly lead to test cases for litigation. So the ultimate language of this policy, if you were ever to adopt this policy, has to be very carefully thought out. On the other hand, we as a group in the standard setting world are allowed to restrain activities in the marketplace so long as the restraint is imposed for an appropriate and thoughtful reason and not to favor a particular group, but in order to facilitate the continued operation of the Internet. So as we go forward, it would be very, very important that we document why we would have any policy. So if it's an eight-paragraph policy, each of those paragraphs would have to be very carefully enunciated, not just in the policy, but in the explanatory materials about that.

MR. CURRAN: Thank you. Any other comments?

MR. FARMER: My other comment is, we really have competing stewardship responsibilities. Making v4 hang around is only going to cause problems for getting v6 done and out there. One could argue that the proper stewardship is, pour gasoline on v4 and make it exhaust next week. I'm not going to propose that, but one could argue that that's the proper stewardship role, rather than trying to -- you know, tweeze it out as long as we can.

MR. CURRAN: Is it your belief that we should head down that direction? Because we don't need hypotheticals, we actually need recommendations.

MR. FARMER: I understand. Oh, man. It's a hard choice.

SPEAKER: That's why we're here.

MR. FARMER: Right now, my personal opinion is, yeah, pour gasoline on v4.

MR. CURRAN: So you'd say we do not need a transfer policy?

MR. FARMER: No, I think we need the transfer policy, but I think we need to make it as unrestricted as possible. Start it now. Make the market happen. Make IPv4 untenable.

MR. CURRAN: Okay, burn the routing table.

MR. POUNSETT: Okay, if I can play devil's advocate to your point there for a second and ask a question? A lot of people argue that completely unrestricted trade extends v4 much longer. If that was the case, do you still think that we should go that way, or --

MR. FARMER: It has that possibility, but completely unrestricted trade also has the possibility of getting it done quicker, and right now, my -- you know, make v4 expensive as we can. It'll make v6 look cheaper.

MR. CURRAN: Okay.

MR. FARMER: Okay.

MR. CURRAN: Rear microphone?

MR. AKPLOGAN: Yes, Adiel, from AFRINIC. I'm not going to give us a staff memo --

MR. CURRAN: Microphones are closed, thank you.

MR. AKPLOGAN: My position on the policy itself, but give some perspective from AFRINIC and African region. First thing, we are one of the regions which does not have any kind of transfer policy -- at this stage, at least -- because, first of all, we are in the region where we have a very little margin in terms of availability of IP address that can be transferred, so it's not a concern for people in our region. The second thing, which is a global generic concern, which has two aspects -- one political and one more, I would say, technical aspect -- is the legacy space. The issue of the legacy space is, we are looking at it as a serious issue because what will happen is that legacy space, if added to the transfer policy, will add an additional liquidity of resources in RIR -- in RIR region, which will allow ISP in those regions to continue to operate using IPv4, for instance. While in our original, we would be struggling, pushing people to use IPv6 because they will have no choice. So we will have two kinds of situation where, in the developing country in our region, for instance, people will have only IPv6 and in front of them they will have operator which will still be using IPv4 and will tell them one day, use IPv4 or not. And this is the price, you have to buy it or not. So it could be a concern for the single aspect -- is the political aspect -- in term of consistency in the message. We, in this RIR, we have been given out in term of the unfair distribution of IP address globally. We have always said that legacy space are not something that is managed by RIR system. And the RIR system has been always locating IP address based on the real needs, and it has changed to figure -- the global figure. Now, today, we will create this system that will allow those legacy space to come into the market again, and we'll have a new pattern that could be seen as an inconsistency in our message, and could bring up some very difficult question for us as RIR system.

MR. CURRAN: Given those concerns, overall, would you be for or against ARIN --

MR. AKPLOGAN: I mean, that is the decision of the ARIN community, but it will be good that -- especially if we are going to talk about legacy policy. Something needs be done among RIR to get the common --

MR. CURRAN: That's why I asked.

MR. AKPLOGAN: That's right, a common position with that.

MR. CURRAN: Final comment, front mic?

MR. DeLONG: Owen DeLong, ARIN AC, and I wanted to respond to Jeff's question. And my response is, basically, just because the other RIRs are ignoring what I perceive to be a critical issue with transfer policies does not mean that ARIN should ignore it. Just because they're doing the wrong thing doesn't mean we can't try to do the right thing.

MR. CURRAN: Okay, thank you. Thank you, everyone -- oh, Scott?

MR. LEIBRAND: I had a response to the three other RIR people that addressed the legacy space and fairness issues. My personal opinion, and I think it's shared by a number of people, is that we probably need to get some sort of inter-RIR mechanism set up, whether that's a transfer policy or what. Because of the way globally coordinated policy, and even worse, global policy works, there's really no chance of getting that done in advance of -- let me rephrase that a different way. If we try to solve all the global issues right away, we won't get the critical issues solved of getting a transfer policy in place. So my personal opinion is that we need to first iron out the transfer policy issues, adopt policies in each region that are confined to the regions, so they don't bleed over into other regions. And then start working really hard as the next step on figuring out the inter-RIR piece. So I think we all support doing that. I think it's just a question of timing and practicalities.

MR. CURRAN: Raúl, the mic's closed. Do you have a point of information? No? (Laughter)

MR. ECHEBERRÍA: What should I say?

MR. CURRAN: Do you need to respond to that?

MR. ECHEBERRÍA: No, it has been mentioned, twice or three times, the possibility of implementing inter-RIRs transfers. This is something that's too early for saying if it is good or not. Of course, it deserves to be explored carefully. I tend to say, at this point, as a first reaction -- and it is not a definitive position, that if we opened the door for inter-RIR transfer, what will happen probably is IPv4 addresses will go away from developing regions to developed regions. So I don't see that today -- this is something I'm saying today, probably I would say something different next ARIN meeting, but this is my first reaction. So I tend to agree with Adiel in the sense that the solution is to avoid the trading off of legacy space and try to find out a common approach, a common position --

MR. CURRAN: Okay, thank you. I'd like to thank everyone for this, and particularly Matt. I'll now turn it back to Ray to wrap up today's session.

MR. PLZAK: First of all, as you notice, we still have some conversation to go on in this issue. So tomorrow morning, first thing, we will take this matter up again. The agenda's going to be adjusted overnight and will be posted tomorrow. Or before you get here tomorrow. Let's put it that way.

Closing Announcements and Adjournment

MR. PLZAK: So a few announcements we need to make. First of all, let's thank our sponsor, WildBlue. (Applause) Okay, don't forget, there's going to be a consolation prize, so keep on entering those surveys. So some reminders: Breakfast is 8:00 tomorrow. Meeting starts at 9:00. Agenda's in your meeting program and it will be updated to reflect the adjustments tomorrow. Tonight, Death For Dinner. We're going to paint the town red. And we'll figure out who's going to do it. Lots of entertainment. Social transportation. First of all, if you look inside your badge, you'll find your nametag to get in the social. You need to have that. If you don't do that, then you can't see who Richard killed, nor can you watch the Final Four and a bunch of other good stuff that's going on. Second thing, the buses will load outside the hotel lobby on Welton Street, starting at 5:30, and we'll depart at 5:45. So we have a short period of time to get ready to go. And a shuttle will be available beginning at 7:00 p.m., so we'll see you there. And we'll see you tomorrow morning, if you don't make it tonight. kc's got maps if you want them.