Policy Manual

Every time new policies are adopted, a new version of the NRPM is posted. The NRPM Change Log links to all
previous versions of the NRPM, as well as details about which policies
were enacted and which sections were modified.

ARIN Meeting Archive

ARIN on the Road
events provide the latest information on ARIN's technical services,
the status of IPv6 adoption, current ARIN policy developments and
updates about ARIN and the RIR system. Archives of our presentations
are also available.

Welcome to the ARIN Vault!

Using the navigation on the page, you can find
information and documents relevant to ARIN's history, or using the
"Search" link above, you can search for specific items. If you wish, you can
return to the main ARIN website.

Search

Note: This transcript 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.

Meeting Called to Order

MR. PLZAK: Good morning. I need to caution the people at the table up here, these mikes in front of you are live, so when you make comments, we'll be able to hear you.

MS. TAYLOR: We don't make snide comments.

MR. PLZAK: Sure.

SPEAKER: Most of the time.

MR. PLZAK: Okay. I'm going to do the introduction and overviews and so forth. Going to talk a little bit about attendance statistics, and then I'll move it through a whole bunch of things that you have. And then we'll do some introductions. So the first thing we're going to do is, for the people who were at that session, hopefully one of them is in the room, is have a drawing for a gift.
And the gift is a Skype telephone. So I need a volunteer to come up here and draw from the bag, and it can't be someone that was an attendee. So -- okay. I still need a volunteer -- oh, the inevitable, the irrepressible David Conrad. (Applause)

MR. CURRAN: You did that in a timely manner; I'd like to thank you.

MR. PLZAK: Yes, another service provided by -- I don't want anybody to misconstrue who was selected here given the proximity of this person to where David is sitting, but the winner is Bernadette Lewis. (Applause)

MR. PLZAK: Bernadette will be on the agenda after my opening remarks. By the way, she is the Secretary General of the Caribbean Telecom Union. So welcome to the ARIN meeting, Bernadette. Okay. So you all received a packet that looks something like this. And instead
of showing you slides, everything is in the packet, I'm going to go through it, and you also got some other goodies as well. So if you open your packet up, on the left-hand side, the first thing you will see is a pamphlet which is the meeting pamphlet, and it has the agenda in it. There's information about the social. It's got the floor plan, tells you where the restrooms are, and the food, and so forth. And it talks about the foosball tournament last night, the social -- it talks about the Cyber Café. And then on the last page, very important, are the rules of discussion. And these rules, as you all recall, are there for two purposes. First one is that everyone in this room has the right to speak. The second one is that everyone in this room has the right to be heard. And it's the job of the Chair to make sure that those rules are enforced.

And we have 13 policy proposals on the agenda for this meeting. So the Chair will have his hands full, but I'm sure that John will be up to the task. The second item that's in your pamphlet is the policy discussion information. It has again a reiteration of the meeting courtesies. And then all the policy proposals that are going to be discussed are in this pamphlet. And there's also the policy evaluation process in the back of the pamphlet, to include the floor chart about how it works. And this is provided to you as a reference to assist you as we go through our discussions. And the third item in there is the Number Resource Policy Manual, the NRPM. So what's on the right-hand side of that folder is everything you need to do to be successful at this meeting. And then on the left-hand side are some other items.

First one is that, as we always do, we always conduct a survey at the end, and we always try to encourage participation. And so if you complete the survey and submit it, you will be in the drawing for a MPv4 watch, which means you can watch movies on your wrist. Okay? Or whatever other video things you would like to watch. And that is the prize for completing the meeting survey. And the next item that's in there -- a very important thing, a duty for all of us that are members -- are the elections. And this is an information sheet about this year's election cycle. It has information about how to be a candidate, about voicing your support, a copy of the election cycle this year, and other interesting information, and what positions are open for election this year as well. Then you have a copy of the ARIN annual report for 2006. And this is what we did last year. And you will find in here staff reports, reports of all the policy activity and other useful information and statistics. So that's what's in your meeting packet. So that takes care of all that. I tell you, these props are overwhelming a little bit, but that's fine.

So time for some introductions. None of the members of the Board of Trustees are native to Puerto Rico, and neither are the representations of the statutes that are shown for them. We have John Curran, the Chairman, and Lee Howard, the Treasurer, so if they would raise their hands, please. So where's Lee?

MR. HOWARD: Hey.

MR. PLZAK: Way over there. Okay. Then we have Mr. Bradner, the Secretary, who I believe is not in the room. But he looks something like that, if you've ever seen Scott with a beard. Then there is me, and Bill Woodcock. I'll let you figure out who is who. And we have Mr. Manning, and Mr. Vixie, and again, you can figure out who's who.

MR. CURRAN: There are three people in that.

MR. PLZAK: You've got your choice; I said you can figure out who's who. So maybe we should have a raffle drawing on that one. And of course, the esteemed counsel, Steve Ryan. Steve, would you please identify yourself. He's over there.

MR. RYAN: I'm standing.

MR. PLZAK: Okay. (Laughter)

MR. PLZAK: So Advisory Council. Fourteen of the fifteen members are here. I would ask them all, to please stand up. I'm not going to read their names. So would Advisory Council members please all stand. Remember, these folks are your Advisory
Council members, and they are here to help you and to get your input into the policy process, and to assist you in understanding what's being discussed. So please take advantage of them -- with regards to policy -- I don't want anything else.

SPEAKER: Not like that, not like that. (Laughter)

MR. PLZAK: Then we have the three persons from the ARIN region who are in the Numbers Council, and you can see their reserved chairs. Unfortunately it's raining outside, so there are actually vacant chairs, and they are in here. And that's Sandy George, Louis Lee, and Martin Hannigan. Marty, would you three guys, please stand. That's one, two, and three. Thank you. Kind of hard to see from up here. So then we have our colleagues, AFRINIC, Yaovi and Didier. And from APNIC,
Paul, Sam, George, Donna, and Akinori, and Akinori is actually the -- actually I should go back a little bit. Didier is actually from the Board of AFRINIC, and Akinori is from the Executive Council of the Board APNIC. LACNIC, Raul is here, and from RIPE NCC we have Axel, Nick, Sam, Paul, and Filiz. So ARIN staff -- would the staff please stand? Wherever they happen to be, there they all are. Okay. And we'd like to thank our sponsors and special participants. So our sponsor is Centennial de Puerto Rico for the network connectivity and Cyber Café. (Applause)

MR. PLZAK: With network assistance from JW & Associates. (Applause)

MR. PLZAK: And we had some special participation last night that helped us to have the foosball tournament, and that was the Laboratorio Gauss from Puerto Rico.
(Applause)

MR. PLZAK: And they also happen to manage the dot PR domain. And of course everyone else in this room, you are a special participant, you are what makes this meeting possible. So we have again the Cyber Café, got some Internet access out there, materials, and presentations. If you were not in the introductory session to the policy evaluation process yesterday afternoon, you can see the new animated feature, explaining the process at the Cyber Café. And this year, we have a new feature, we have the Wheel of Fortune. I'll tell you, we actually had Vanna White scheduled to come down here to do the Wheel of Fortune, but at the last minute she had to decline, so instead, Richard will be taking care of this. So I won't go any further than that. So what we're going to do is we're going to be conducting over the course of
time some very targeted surveys, and so what we're going to do is we have a raffle form, one per day. And we'll draw two names during each morning and afternoon break -- at the Cyber Café, there'll be a drum. You have to be there, so you have to complete -- there is only one question you are going to have to answer. And you complete that and you put it in the drum, there will be some question about something we want to gather some information and feedback from. Then a name will be drawn out of the drum, and whoever gets their name drawn out from the drum -- there'll be two people that get to spin the wheel and get a prize. Now, we did it with one person yesterday. And that person won an extra beach towel, which by the way everyone should have one for their own. You noticed that Susan made sure it was raining outside so you'd all be inside here for the meeting.
But Sandy Murphy won one yesterday, which she's very pleased to have, because I believe her husband's joining her later in the week, so they will have matching beach towels. So congratulations to Sandy. I've got a whole box full of prizes here, folks. You get 12 chances to win. So whatever comes up in that wheel, when you spin it, you will get one of these things. So I'm not going to pull them all out, but you can see there's a lot here. Okay. So answer those survey questions. There'll be 12 lucky winners. And the grand prize is an iPod shuffle. So if you're really lucky you'll get the iPod shuffle. So we've got two help desks in operation by the Cyber Café, one for registration services, one for financial services. Information is there, and it's also in the meeting packet. So any time you want to during those hours, go there; otherwise, call appointment for registration
services and financial services -- being bankers, they will only deal with you by appointment. Not really. They will talk with you anytime really. Complete the survey, please, both on the IPv6 workshop and the survey for the meeting. We really take this information to heart. And once you do that, you get a raffle entry, one entry per person. So one lucky winner. And again, it's that watch. The foosball tournament was last night, and it was a very, very well-attended session. And we had some very good participation. And so results of the tournament: Third place, Owen Delong and Axel Pawlik, so Owen and Axel. (Applause)

MR. PLZAK: Second place was Leo and Abram. (Applause)

MR. PLZAK: And they won't let you forget it, first place, the champions for
2007, your champions, Raul and Bob. (Applause)

MR. PLZAK: There is one other trophy that we didn't award last night, but everyone knows about it, and that's this one. And theirs were the team that was also present, and that's Raimundo and Sam. So if they would come up here, they can please claim their trophies.

MR. CURRAN: Speech.

MR. PLZAK: In case you don't know, that's what you do in Holland, it's Amsterdam. Okay. So tonight is the social. It's an evening of enchantment; join us at 6:00 to 10:00 at the Beach Club. We'll have food and beverage. There'll be ample to eat and ample to drink. Entertainment, we'll have a calypso steel drum band, we'll have beach volleyball, we'll have foosball for those who think they need a little bit extra practice. There'll be billiards, and there will also be air
hockey. So lots to do, lot of different things, good chance to network and to spend some time relaxing with your fellow participants at the meeting. And just a reminder, John does not have on his striped shirt, but these are the rules, and so pay attention. So the surf's up, and let's roll. First thing I want to do is invite Counsel up here to give a brief report on our recent legal matters, and then we'll proceed with the agenda.

MR. RYAN: Thanks, Ray. It's a measure of our society that with a bunch of techno people here, the lawyer has to begin the meeting. But let me just say I'm actually here with a lot of good news today. As you know, in Montreal, when we were there, we were sued in United States District Court. That is, ARIN was sued, for $50 million which if we had lost, we would have of course tossed them the keys to the
building, and said good luck, it's yours. That lawsuit in the United States District Court was by Mr. Gary Kremen, and when we were in St. Louis, I briefed you on the nature of the lawsuit. I'm very, very pleased to tell you that in the first weeks of December, the United States District Court, based on arguments and motions made by ARIN, threw out that $50 million lawsuit. In the United States, it's almost unprecedented to have a suit thrown out before discovery. There a legal presumption that in fact the court is supposed to read the complaint as if it were true even when the court knows it not to be true; in other words, there's a presumption that is accorded the person suing. Notwithstanding that presumption, the court not only threw out the $50 million suit, but the court also vacated the 2001 order. And if you recall, as I described
this case before, this case began without ARIN being in court. In 2001, Gary Kremen went to court and got an order that treated IP numbers as if they were a Ford LTD, and said it should be transferred from one person to another. Mr. Kremen then refused to fill out any of the necessary paperwork to effectuate a normal transfer within our system, and we accordingly refused to give him the resources. So when the court threw out the $50 million lawsuit, more importantly to us, the court made a decision of record, which you can find in our website so you don't have to listen to me while this is going on -- you can look about us, and then in the media listing on our website, there's a copy of the court's order. And the order that vacated the 2001 order basically recognized that ARIN's procedures had to be followed by a member of the community even in the instance where a
court order had been given that certain resources were to be turned over. So that Mr. Kremen's entire premise of his lawsuit went out the window because the court said basically you and everybody else has to get in line, fill out the forms and be treated in a non-discriminatory manner. So this is the first major decision that ARIN has experienced in the United States District Court that recognizes the lawful way ARIN derived its authority both from the community and originally from the U.S. government contract. And it traces the antecedent way in which those authorities were given to us. So we're very, very proud of this. We're very, very happy that the court granted us literally every single thing we asked for. In standing before the court partway through the argument where I had the opportunity to call my opponent a liar, which -- you know, is pretty strong stuff -- the court said,
well, Mr. Ryan, how would you like the order to read? And I gave him sense of what we wanted, and that's exactly what the court gave us. Now, the case is not over. The portion of the case that we care the most about, which is the recognition of our authorities and the recognition of the process of the community, that portion was not appealed and is final. So we're very, very happy about that. The judgment that threw out the $50 million lawsuit has been taken up on appeal. And the issue there has nothing to do with IP numbers, it's really the application of statutes of limitation to an antitrust complaint. So even if the court at the Ninth Circuit Level rules in our favor, we won't learn anything more about how IP works or IP law is advanced, it'll have nothing to do with that. The opponent's brief is due on
May 4th in the Court of Appeals, our brief is due on June 4th, and we'll continue to keep you apprised on that. But I really wanted to share with you -- you know, we got up in St. Louis and forthrightly disclosed to you that we had been sued, and now we can forthrightly disclose to you that we absolutely crushed our opponent, and that the district court, you know, gave us everything that we asked for. So I think we're very, very proud as a management team of that accomplishment. And that's the last thing I have to say about that lawsuit unless there are questions or comments from the Chairman or the members of the Board, or Ray or you. If you have a question about this, we would be glad to answer it.

MR. CURRAN: I guess the only thing that would be worth mentioning is on the aspect that is appealable; how do we stand,
are we in good stead, and what could happen one way or the other?

MR. RYAN: So as a lawyer, I always want to go to the Court of Appeals having won the judgment below, and I'm now the appellee. The burden is on the other person normally to show that the judgment of the lower court should be thrown out. In this case, it's slightly different. Because the case was thrown out on the pleadings as a legal matter, the Court of Appeals will judge the dismissal of that antitrust complaint as if it were a new matter, because the Court of Appeals can make the same legal judgment that the district court could make. So we expect oral argument in this case to occur in September or October of this year, and I expect in all probability a decision some point in late 2007 or early 2008 on this case, if it goes all the way through. Keep your fingers crossed, and
we're going to do the best we can with this, and we like our chances of succeeding in the Court of Appeals. If there aren't any other questions, I want to do 60 seconds on a second legal issue. Lawyers get -- we get the podium very seldom at these meetings, and I figured I'd use it. I just wanted to tell the community -- and again something we're very, very pleased about, and some days it will be my job to come up here with bad news, but today is not that day. We have signed a very, very important RSA with the United States Department of Defense. The Department of Defense RSA is important because if there was any entity in the world that could argue that the Internet and IP numbers were government-furnished material, it might be the United States Department of Defense. And instead, the Department of Defense has agreed to be covered by the rules
of the community in the same manner, with some accommodations for the special nature of their sovereign activity, which we do for any sovereign whether that be the Royal Canadian Mounted Police or one of the sovereign nations of our Caribbean counterparts here. But that agreement has one thing that I wanted to underline to you. The Department of Defense has voluntarily agreed that they will return to us IPv4 resources that they believe are no longer necessary that had been previously issued to the Department of Defense. So we have a member of the community of great importance, and frankly, of great sophistication, agreeing that it will return to us those things which it had no duty to return to us previously in returning IPv4 address space, as the Department decides it's no longer necessary. Using this as an example, we've now entered negotiations with all of the civilian
agencies of the United States government, and we are creating a simplified and non-DoD-like agreement that would be suitable for each of the U.S. government agencies. So working with one sovereign within our area -- we're working very, very hard on this; we're going to be doing similar work with our counterpart sovereign governments in the Caribbean region and in Canada. So we're very, very pleased with these activities as well.

MR. CURRAN: Thank you. (Applause)

Internet in the Caribbean

MR. PLZAK: Thanks, Steve. So now on with the agenda. And the first order of business is, and it's my extreme pleasure to welcome to the podium the Secretary General and the winner of a prize, Bernadette Lewis, to give you a presentation about what's going on from the standpoint of the Caribbean and the development of the Internet there. So Bernadette?

MS. LEWIS: Good morning, everyone. I'm really, really happy to be here at this 19th ARIN meeting, and I'd like to thank ARIN for the opportunity to be here to present an ICT scorecard for the Caribbean, and to give an overview of some of the Internet governance initiatives that are taking place in the Caribbean at this time. But by way of introduction, I'd like to tell you a bit about the CTU, Caribbean Telecommunications Union. It was established in 1989 by the Caribbean Community, CARICOM, and its members comprise government, Caribbean governments, private sector and civil society organizations. And our mission is to create an environment, in partnership with members, to optimize returns from ICT resources for the benefit of stakeholders. Our focus is on ICT policy development, capacity building, and the representation of the region at international
fora. In order to put my presentation in context, I'd like to introduce you to the Caribbean. And we have a short video clip that gives an overview of the Caribbean. (Video played)

MS. LEWIS: Thank you. The purpose of this video clip is really to show the diversity in the Caribbean in every area. And having established that the Caribbean is characterized by diversity, you could appreciate it's very difficult for us to come up with a set of averages to formulate an ICT scorecard. But nevertheless, we will begin our presentation, our assessment, by looking at a number of characteristics of ICT development. And the first one that we're going to look at is policy. And there's a universal recognition that ICT policy must support national development plans. But the size and limited resources -- in many Caribbean countries, it makes it particularly -- makes
them particularly vulnerable. But ICTs present an opportunity to help overcome these challenges. And we're seeing, in the Caribbean, a lot of work has been done on the development of ICT policy, and there's a growing maturity in policy development. The evolving policies are adopting more structured, pragmatic approaches to leveraging ICT opportunities. So I think we have done fairly well on the issue of policy development. So I've given a score of seven out of ten. Then we move on to the second dimension, that of legislation. In many jurisdictions, up until 1998 or '99, thereabouts, the telecommunication law dated back to the days of telegraph. And without exception in the recent time, all of the Caribbean countries have updated their telecommunications and information legislative frameworks to reflect the changing technological landscape.
Much of the legislative reform was to prepare the market for liberalization. But more work has to be done to bring the legislation in line with the post-liberalization market dynamics. And provisions must now be made in law for eCommerce, privacy issues, issues of cyber crime, content and intellectual property protection, digital signatures, and the list goes on. The new legislation must also be crafted with the necessary flexibility to withstand the challenges that rapid technological advances will present. So on the legislative agenda, we still have some work to do there. We gave it a score of five. Moving on to the next dimension, of regulations. Out of the legislative framework and reform that developed in the late 1990s, we have had a number of semi-autonomous independent regulators being established. And these had to ensure a smooth transition from monopoly to liberalized markets. And these institutions were responsible for creating an enabling environment of equity, transparency for all stakeholders, and to seek the interest of the consumer. Now, each of the Caribbean countries has independently adopted different approaches, practices, and methodologies for regulating the sector. And while some commonalities may exist, the development of regulatory functions across the Caribbean reflects the diversity in the different experiences and circumstances in the nations of the region. So most countries would have some form of regulation, and their regulatory institutions, they are fairly inexperienced. They are constantly being challenged by technological innovation, dominant operators, and the need to maintain some semblance of
independence from the political directorate. But we did fairly well on the issue of regulations, so we gave it a score of six. And we move on to liberalization. Liberalization of the Caribbean telecommunications marketplace began with the Hispanic countries. Puerto Rico liberalized in 1986, followed by the Dominican Republic in 1992. In 1997, many of the English-speaking Caribbean countries entered into commitments under the World Trade Organizations agreement, and adopted the reference paper guidelines to liberalize their telecommunications markets by dismantling the exclusive agreements entered into with various incumbent operators. So the majority of Caribbean Islands have, to a large degree, liberalized their ICT sector. So the score for liberalization is six. Competition. Would-be competitors found that in spite of the liberalized environment, and the oversight of the
regulatory institutions, they were severely disadvantaged. The incumbent operators controlled the international connectivity infrastructure. They controlled the local loop, Internet access and so on. Furthermore, they employed a lot of delaying tactics to frustrate connection, and engage the regulators in legal wrangling. And many of the new licensees were not even able to commence operations, far less compete under these conditions. But in spite of that, we have more than 50 operators in the Caribbean, with up to 100 business units operating in 30 countries of the Caribbean. So generally, competition has not been particularly robust in the English-speaking Caribbean. I think in the Hispanic countries, and the British overseas dependencies, the competition is a lot more robust. So we have a score of five. And this is especially because in the English-speaking Caribbean, you would find
you have effectively duopolies operating. It's not a vibrant competitive environment. As far as the infrastructure is concerned, the region is quite well-connected, in that there are about 30 satellite systems with footprints in the Caribbean. We have about 20 or so marine fiber (?) systems operating in the region, and we expect that we will have about four more in this year, 2007, coming on stream. And locally, the infrastructure for voice is good, broadband services through fixed line and wireline facilities are available. You find mobile telephony devices are almost ubiquitous. But this is not the case with computers. And many of the governments and service providers have embarked on community-based telecenter projects to bring ICT facilities and services to citizens in their communities. So the score we gave for the infrastructure is six. As far as affordability is
concerned, the question is, can Caribbean citizens afford ICT services? And we found that competition in the Caribbean markets resulted in the prices for voice services coming down more than 50 percent. There have been significant reductions over the last two years. And the cost of cellular phone is certainly in reach of the average citizen. But the cost of the computer -- or computer, on the other hand, is definitely beyond the scope of the pockets of the average homeowner, and the price of broadband services. So some reductions, but it's still high. And not being able to afford broadband relegates users to frustrating experiences on the Internet, and restricts them to very basic services such as surfing and e-mail. So the score for affordability is four. Access. I think the Caribbean governments are definitely committed to the
principals of universal service. And they have undertaken to provide access to ICTs in many forms. For example, they are providing access to the Internet and other ICT services by placing computers in schools and libraries and community-based centers. And a number of operators in the Caribbean have also embarked in such programs. Now since liberalization, there has been a steady growth of small-business-type Internet cafes and international calling centers. Whereas the number of mobile subscribers have seen an exponential growth, the growth of Internet subscribers has been very slow indeed. So on the issue of accessibility, we've given a score of four. And now we move on to effective use. The development of information-based societies requires the incorporations of ICT in every sphere of everyday activities, in filing tax returns, paying bills, promoting Caribbean culture, in every area of human
endeavor. But providing access to ICTs is not sufficient. It requires a structured approach that encourages citizens to use them. So for those Caribbean citizens who have access to ICTs, are they really deriving tangible benefits from their use, are they using them effectively? And when I speak of effective use, I'm not talking about chatting on your cell phone for hours and hours about the ICC World Cup Cricket spectacle that we've had in the Caribbean. No, it's not about that. It's -- effective uses about reaching the long-stay children in hospitals and teaching them from their hospital beds effective uses about finding the buyers for your fish while you're still on the boat out in the sea. It's about promoting your Caribbean culture, the Calypso, and the Reggae, and the Ska, and the all other types of culture on the Internet. It's about buying and selling, and
sending X-ray pictures to experts abroad by a high-speed connection. It's about paying your taxes online. And what we find in the Caribbean is that our citizens are spending more and more disposable income on non-productive use of ICTs. So the score here for effective use is three. So overall, the total benefit, we have a score of five. And this is hardly a passing grade. And we need to maximize on the enabling environment we've created to really move to the point where we're leveraging ICT opportunities. And how do we go about improving this score? Well, there are certainly a few things that we have to do. We have to plan strategically. We have to move away from the partisan politics, and there must be a demonstration of political will from our regional governments. We need to be pragmatic in the development of Caribbean models for ICT development. And we also need to build human
capacity. Building public awareness of the potential of the Internet, educating and training our workforce on ICT skills and services. We need to manage the resources, the ICT resources. And this involves regional cooperation to establish infrastructure and build the appropriate systems. We have to cultivate public-private sector partnerships and pool the resources and share experiences. And then in terms of using effectively, we have to have our governments being the first and early adopters of ICTs, and they must use ICT to deliver services to their citizens. Enterprises must be encouraged to incorporate technologies in their everyday processes. And then we need to develop niche industries, niche enterprises which can leverage the technologies for competitive advantage. Now, a significant component of
effective use is directly related to maximizing the benefits of the Internet. Unfortunately, in the Caribbean, and based on the statistics we have available, Internet penetration is very low; it's at 13 percent. And having said that, I'd like to point to some of the CTU's Internet governance activities which we hope will bear fruit in the coming years. And we have a mandate from CARICOM. In January 2005, the CARICOM secretary had requested the CTU to take up the issue of Internet governance on behalf of the Caribbean. In September 2005, we staged our first Caribbean Internet Governance Forum. And coming out of this, we determined Caribbean positions on a number of specific WSIS issues. And we also had the recommendation of the creation of a regional Internet governance framework. At that session, we also prioritized some of the Internet governance issues, which we had to
take up as a matter of urgency. In 2005, November, the CARICOM secretariat took the outcomes of this first meeting to the WSIS -- Tunis round of discussions. And by May 2006, we held a regional workshop on Internet governance where we addressed technical and policy issues, and we had ICANN participate in and supporting this workshop. Then in September 2006, we established an online Internet governance forum. And you can visit the CTU website and see the trend of discussion which we've had over the last few months. And then in November 2006, we also held the second joint Internet Governance Forum, in association with the Caribbean Internet Forum in Grenada. And this coincided with the UN's, the United Nation's, Global Internet Governance Forum in Greece. And we were able to liaise, using the technology with participants at the Greek meeting, at the meeting in Greece, and to
exchange what we were doing in the Caribbean and hear what was happening at that forum. And we were able to progress the development of a Caribbean Internet governance framework. We also identified a number of Internet governance projects that we were going to take up on behalf of the region. And then last week, we had our first ministerial Internet governance briefing seminar, the purpose of which was to raise the awareness of ministers, Caribbean ministers, on issues of Internet governance. And coming out of that meeting, we had commitment from regional governments, that's our ICT ministers and Internet stakeholders, to a regional Caribbean agenda. And we have developed an action plan for advancing the Caribbean Internet governance agenda. So over the course of 2007, we will be rolling out a number of Internet governance activities. And I'd like to say that the CTU is committed to working
with Caribbean Internet organizations and institutions such as ARIN to improve the ICT score. And our goal is to ensure that every Caribbean citizen is able to reap tangible benefits from the ICT revolution. And with that, I end this presentation. I thank you all for your attention, and I look forward to working together with you all in building a healthy Internet governance framework for the Caribbean. I thank you.

MR. PLZAK: Thank you. (Applause)

MR. PLZAK: Thanks, Bernadette. Does anyone have any questions or comments at this time? It must have been an outstanding presentation.

MS. LEWIS: Great.

MR. PLZAK: Thank you very much.

MR. CURRAN: Thank you very much.

MS. LEWIS: Thank you.
(Applause)

Regional PDP Report

MR. PLZAK: At this time, I'd like to call on Richard to come up and provide the regional PDP report.

MR. JIMMERSON: This is a brief report of the policy discussions that are going on inside the other regions to set us up for other discussions we're going to have here, so that perhaps we can draw on them and get comments from them on things that are happening in the other regions as we move forward in the next two days. First, ARIN policy report. These are discussions, policy discussions, that were in play during our last meeting. And a 4-Byte AS number 2005-9 was implemented on 1 January of this year. The Residential Customer Privacy proposal was abandoned through the process coming from the last meeting. Also at the last meeting, we had 2006-2: Micro-allocations for Internal Infrastructure that was implemented by ARIN
on 20 December of 2006. Capturing Originations in Templates was implemented on 28 March, 2007. And changes to initial IPv6 criteria is a policy proposal that was not formally on the agenda last time at the last meeting. However, it was proposed at the same time as the meeting last year, and it's up for discussion at this meeting this week. The regional report, updates from the other RIRs, the discussions we have in the other regions for IPv4 countdown policy, it's something that's been proposed in each of the regions. The status in the other regions is that there's an informal discussion taking place right now inside the AFRINIC region and the RIPE region. And there's discussion inside the formal process in APNIC and LACNIC. I believe in AFRINIC and RIPE NCC, it will become more formal inside the process very shortly.
Twelve-month allocation period. That's something that's under discussion in the AFRINIC region, and something that's been adopted in both the LACNIC and RIPE NCC regions recently. PI assignment size/24 minimum for multihomed, is under discussion in the RIPE NCC region. Address space for TLD anycast services has been adopted recently in the RIPE region. And there's an EGLOP proposal under discussion inside the APNIC and LACNIC regions. For IPv6, changing the HD ratio to 0.94 is under discussion in all of the regions. APNIC, LACNIC, it's been adopted. To amend the v6 assignments and utilization requirements to a /56, similar to what we had take place in the ARIN region, APNIC has adopted that, and in both the LACNIC and RIPE NCC regions, we have that under discussion. And address space for TLD anycast services, that has been adopted recently in the RIPE
NCC region. Provide independent assignments for end users, we have that under discussion in all of the regions, recently adopted in the APNIC region. The proposals do differ slightly in each of the regions, however. Removal or plans to assign 200/48s, that's been abandoned in the APNIC region. That is something that's still being considered currently. And it's under discussion both in the LACNIC and RIPE NCC regions. And the removal of the multiple /48s, that's been abandoned in the APNIC region and under discussion currently in the LACNIC region. Removal of interim status language from the policies under discussion at APNIC and LACNIC, and the removal of requirements to announce only the single aggregate is under discussion in the LACNIC region. That's something that was added to the policy a few years ago there, and it's under discussion to change now. Critical
infrastructure discussion inside AFRINIC for IPv6 and a ULA central policy is under discussion in both the AFRINIC and LACNIC regions. For directory services, the deprecation of e-mail updates is under discussion in the APNIC region. And a recent proposal for contact e-mail requirements in the RIPE NCC region has been withdrawn and is no longer under discussion. These are the references and links, if you want to go look at the other RIR websites and see all of the active policy discussions for each of the regions. And also, we have colleagues from all of the other RIRs here at the meeting this week, and I'm sure they'd be very happy to talk to you if you do have questions about policies that are ongoing inside their regions. And with that, that ends this discussion.

MR. CURRAN: Thank you. Any
questions for Richard?

MR. PLZAK: Yes, Jordi.

MR. PALET MARTINEZ: Jordi Palet. The 200/48 is not abandoned in APNIC. I still didn't resubmit the new version. And the ULA central is also under discussion in APNIC.

MR. JIMMERSON: Maybe something that we didn't have correct on the slides. Is anyone from APNIC here to provide clarification on that if it's needed? Or is what Jordi had to say correct? Sam?

MS. DICKINSON: The ULA policy has just been released on Friday, so that's why --

MR. JIMMERSON: Okay.

MS. DICKINSON: I was not able to get that through. And I'll just have to clarify with the 200. I thought that was abandoned. Okay, I'll check that out.

MR. JIMMERSON: Thank you, Sam.

MR. CURRAN: Any other questions? Thank you, Richard.
(Applause)

Internet Number Resource Status Report

MR. PLZAK: And I'd like to call on Leslie Nobile to provide the Internet Number Resource Status Report. Leslie.

MS. NOBILE: Good morning, everyone. I have the joint stats. This is the Internet Number Status Report. It is prepared by all five of the Regional Internet Registries. And it is the statistics for all of our regions in a side-by-side format. We update it four times a year; this was recently updated 31 March. So the stats are pretty fresh, good data. This first slide is the status of all of the IPv4 address space, the /8s. So I usually start at the bottom right corner with the space that's actually not available for the RIRs to issue. There are 16 /8s that are reserved for experimental -- or that are being used for experimental, 16 being used for
multicast, one for private use and one for public use. So those are not available to be issued by the RIRs. On the left is the division of the space for the five RIRs and legacy space. We used to call this central registry, the 93 /8s that were issued prior to the establishment of the RIRs, the SRI NIC, DDN NIC, IANA itself. So anyways -- so as you can see, AFRINIC has one /8, APNIC has 24, ARIN 27, LACNIC 4, RIPE NCC 24. And this is based that we're issuing from currently, and that we've issued previously. So this is the IPv4 allocations from the RIRs to the ISP RIRs, it's the side-by-side comparison, we go back to 1999. It basically just shows the growth trends in each of the regions. Looks like we're all issuing quite a bit of space right now. There has been quite a bit of increase in the v4 allocations over the past year or two. And this is another way of looking
at it. This is the cumulative total of the address space. It shows how each of the regions, the total that we have issued thus far. And at this point, as you can see, APNIC and the RIPE NCC have issued more space since 1999 than ARIN has. And this is a recent development; it used to be ARIN that had a slightly larger piece of the pie there. This is the ASN assignments, again just shows the growth trends in each of the regions. As you can see, ARIN was issuing quite a few ASNs early on -- 2000-2001, and that has decreased over the past several years. And this again is the cumulative total. And as you can see, ARIN issues quite a few ASNs. But we've seen a real increase in the RIPE NCC region; they have started issuing quite a few ASNs in the past couple of years. This is the IPv6 allocations from IANA to the RIRs. And this data is prior to
October '06. This is when IANA was issuing the RIRs /23s of IPv6 space. And up until October of '06, you can see that RIPE NCC was getting quite a bit of space from IANA to issue to their members, to their LIRs. We had a new policy, a new global policy in October of '06, and IANA issued each of the RIRs an equal amount of space, a /12 worth of IPv6 address space. And that is what we're all issuing from currently. So that justs list the /12s right there. This is the IPv6 allocations from the RIRs to the ISPs. Their growth trends are interesting; it's gone up, and it's gone down. We had some real growth in 2003, 2004, 2005 in all of the regions, but it's actually gone -- diminished somewhat. There's not quite as much of a demand for the IPv6 allocations in -- at least in several of the regions. It looks -- actually, it went down in all of the regions last year except for AFRINIC and LACNIC, where it's increasing,
they are issuing more v6 allocations. And this shows the cumulative total. As you can see, the RIPE NCC is issuing the majority of the IPv6 address space right now to their members in their region. This is just the links to the RIR statistics, and they're of course kept on the NRO site, all the RIR stats, and on each of the RIR's websites. And then the raw data, the historical data is kept on the IANA and ICANN sites. That is all I have right now. Any questions? Thank you. (Applause)

IPv6 IAB/IETF Activities Report

MR. PLZAK: Next up is the IPv6 IAB/IETF activities report. And Lea Roberts is going to be doing this. Thomas Narten, unfortunately, could not be with us this time. And so, Lea, please.

MR. ROBERTS: Good morning, everyone. I'm going to try and channel Thomas Narten again this meeting. Certainly,
we miss him, but I'll do my best. And one of the things we added to this presentation is an official disclaimer, as it were. This is a personal report more than any kind of official report from IETF. But we've done our best to make sure it is totally accurate. One of the big things that's been going on over the last six months in IETF is the emergence of relooking at routing and addressing, and the scalability of the routing system. There was a workshop in Amsterdam in October, and that's proceeded with a bunch of more work inside the IETF. In the recent meeting in Prague, there was a full-day routing workshop, a routing research group workshop before the meeting. And several other meetings inside the various working groups and BOFS, looking at scalability of routing and addressing. Work is ongoing there. There's certainly a lot of work to be done. As many
of you know, this has been an ongoing question since even before IPv6 was fully formed. But it has new vigor. And as a personal note, I would suspect that ARIN's and various other RIRs are starting to do PI IPv6 might have kind of spurred that view in the IETF. Anyway, there are a bunch of URLs here with more detailed information on the work that's been going on -- in particular, the RAM mailing list. RAM at IAB is a very active mailing list. It has a lot of dense information in trying to really wrap around what the problem statement should be. And anyway, it's exciting to see a lot of the people who were active in IETF many years ago getting energized and back in the -- in looking at how to get things going in a more scalable fashion. Moving on to some of the other working groups. The GROW working group is kind of not very active right now. But
there's at least one draft still in the process from GROW. SHIM6 is reaching kind of a steady state, the three core docs are in the final stages. Looks like they will go on to the last call in the IASG sometime soon. And SHIM6 is certainly not being presented as the solution for multi-homing, but merely one solution that should help with the multi-homing problem. The IPv6 working group is also winding down, I guess you could say. There are a bunch of documents that have been finished and are in the RFC editor queue. Their work is essentially done, from their perspective. There is one interesting draft that Thomas did, RFC 3177 BIS, but it was never accepted as a working group document, and it's up to us to kind of keep it going if we want something to come of that. And as Jordi has mentioned on more than a couple of occasions, there's some
movement on reviving centrally assigned ULAs. One extremely active working group is v6 OPS. As you can see on these slides, there's a lot of working group documents going on in that working group. And the Softwire working group is also doing some good stuff in how to sort of mesh IPv6 and IPv4 in various flavors across different infrastructures. So you don't have to -- in places where you aren't doing dual stack, you can still have connectivity. And we've also added some slides about the various DNS stuff. Here are the documents active in DNS OP, and one in the RFC editor queue. DNSSEC is also pretty much done. There is a lot of deployment yet to do, but the spec's pretty much solidified at this point. Again, a big list of active documents, both still in ID form and a bunch in the IESG, and one about to become an RFC. Another working group of interest we thought was the Operational Security
Group. Here's the active documents in that group. The next IETF will be in Chicago in July, and it's still in the time frame to establish BOFS. If anyone has something they want to bring to try and get some work started in the IETF, there's a process for doing BOFS at Chicago. Any questions?

MR. CURRAN: Microphones are open. Any questions?

MR. MANNING: I have a comment.

MR. ROBERTS: Mr. Manning.

MR. MANNING: Does anyone think the PPML list is busy? I'm sorry, Chair, I'm not supposed to do straw polls, but the routing, the RAM mailing list is busier than PPML --

MR. PLZAK: Uh-huh.

MR. MANNING: By a long shot.

MR. ROBERTS: That's right. And there are some pretty intense discussions happening.

MR. CURRAN: Thank you.
Other questions?

MR. ROBERTS: Thank you.

MS. AZINGER: Sorry, Marla Azinger, Frontier Communications. RAM is busy, but I also would caution that there's stuff on there that is what I consider white noise. So even though it is really busy, you have to be able to decipher it.

MR. CURRAN: Okay, thank you.

2007-11 Refinement of ISP Initial Allocation Policy

MR. PLZAK: 2007-11, right before coffee break. Bear with us a second here. Anyway, it's a good reminder of time that, please pay attention to rules. The Chair would greatly appreciate it when you come to the microphone, identify yourself and affiliation, and clearly state -- the first thing that you should say
after that is whether or not you support the proposed proposal. And if you don't do that, I think the Chair will stop you right then and allow you one --

MR. CURRAN: I'll actually take this moment to ask a favor of the attendees of the policy meeting. I need to have the approval of the meeting to limit debate of these policy proposals. And I propose that when someone comes up to the microphone, that I will limit their debate to approximately one minute to speak on a given policy proposal. If we don't do this, it will not be possible to actually get through the meeting. If someone feels strongly I should not be limiting people's comments to a minute, please raise your hand now. Thank you.

MR. PLZAK: The first proposal is proposal 2007-11, Refinement of ISP Initial Allocation Policy. It was introduced on the PPML on the 22nd of February this year, and
designated a formal proposal by the Advisory Council on the 2nd of March. This is the first meeting in which it will be discussed; the text has not been revised since it was proposed. A simple description is that it removes the sentence which refers to completing a template. The shepherds are Robert Seastrom and Stacy Taylor. From a legal assessment, liability risk is none; staff adds no comments, but notes that the NRPM change would modify section 4.2.4.3. And the implementation assessment is that the impact would be minimum from a standpoint of resources. We could do this within 90 days after the Board of Trustees ratifies it, and the implementation requirements are guidelines, changes in staff training. The discussion so far on the PPML, not much discussion. Seven posts by three people. Three for, none against. General comment, "I entirely support 2007-11," and "fine." And the full text of the proposal in your pamphlet that was part of your meeting handout, and also is online at the URL shown. And with that, I will turn it over to R.S., who will make the presentation proposal.

MR. SEASTROM: Bear with me a sec here. Thank you. This is policy proposal 2007-11, which is refinement to the initial ISP Allocation policy. It's pretty straightforward. In NRPM 4.2.4.3., there's a sentence that says, "When completing Section 7 of the Internet ISP network request template, please keep this in mind." It probably shouldn't have been there in the first place. The appropriate place for instructions is in the attachment to the template, not in the policy itself. However, now that ARIN has re-done all of the templates, it refers to a template title and template section which no longer exist.
Are there any questions?

MR. CURRAN: Microphones are open for discussion. Microphones remain open for discussion. Last chance. Okay, thank you, R.S.

MR. SEASTROM: Thank you. (Applause)

MR. CURRAN: In order to facilitate the Advisory Council in doing their job, it is sometimes necessary to pass along to them a show of hands in favor or oppose to proposals. I'm now going to ask for such a show of hands. I'm going ask those who are in favor, and then those opposed. All those in favor of advancing policy proposal 2007-11, please raise your hand now. Nice and high. Keep those hands nice and high, like you're reaching for a sugary treat at the break. All those opposed to advancing
policy proposal 2007-11, please raise your hands. Thank you very much. We have a count? Okay, thank you. I wanted to make sure I knew what Ray was doing to the count. The total number of people on the room was corrected. The room count is 114. Those in favor 53, those opposed 0. Thank you very much.

MR. PLZAK: We are ahead of schedule and it's now time for the break, and we will do so. So see you back at the appointed time. Thank you. (Recess)

RIR Update - AFRINIC

MR. PLZAK: Everyone has to be in the room and ready to go. And here running quickly to the stage is Stacy. So the next item on the agenda is the first of the RIR updates. A little different departure from previous meetings is that we are scattering the updates throughout the agenda. And so the
first one is from AFRINIC, and Didier is going to present the AFRINIC update. Didier.

MR. KASOLE: Good morning. I wish to start with the membership growth. For the last two years, the membership growth was around 140 percent versus 2004. You can see it on the graph. And then you have on the right the cumulative graph. What the impact of the -- the impact on the existing allocation. There is a steady growth in the existing allocation, as is a steady growth in the existing allocated was a result. IPv6. Last year, we had been focusing on IPv6 awareness among the community, through training and conferences. This had led to more interest in IPv6, and you can see countries where IPv6 training are conducted, and we have an IPv6 by field. You have Egypt, Sudan, Kenya, Nigeria, South Africa, Angola, Tanzania, Morocco, Tunisia,
and then, Cameroon, Senegal, as well as Burkina-Faso, and then Togo. Policy development. We have some policy points under discussion; there's the IPv6 assignment for critical infrastructure. The IPv6 address allocation and assignment policy, proposal to change the allocation and assignment period to 12 months. The IPv6 PI assignment for any sites, proposal to change the IPv6 HD ratio from 0.8 to 0.94, the proposal for an IPv6 UA liaison central (?) All of them are in discussion. Cooperation with other organizations. With the partnership and cooperation with other organization, we have an MOU send with AfNOG doing AFRINIC HD, and then we in this MOU, we will support 2007 meeting, then fellowship to attend AfNOG AFRINIC event in Abuja, support streaming during the events. This event in Abuja will happen next week. With other organizations, we are
planning to sign with Association of African Universities, as well as AFTLD to be signing in Abuja. We continue our active participant to the NRO activity through its EC, the ECG and CCG. Also working on specific project with specific AIAG, with APNIC partnership on icons. Some ongoing projects. Beside our coactivity, which is Internet resources management, we are working on some of the projects of interest for the community. My AFRINIC is a portal that allow IR to easily interact with AFRINIC and manage our resources. It's a bit (inaudible) was started. Fee switch to analysis and review, there's an AIRRS is a tool to provide analysis and statistics on the resources allocated assigned by AFRINIC, including routine information. It's already up and running.
The activation of an RIR for AFRINIC region, the Internet issue certification, RFC-3779, and the Voice-over-IP is implemented between AFRINIC locations. The next public policy meeting will happen in Abuja from 29th April to 4th May. It will be a back-to-back with IPv6 hands-on (?) training, the AFTLD meeting, the African Regional Education Network, and then the AfNOG, and INET Africa meeting. Thank you very much. Merci bo que. Any question?

MR. CURRAN: Microphones are open for questions. Thank you very much. (Applause)

2007-1: Reinstatement of PGP Authentication Method

MR. PLZAK: We are now going to embark on a discussion of policy proposal 2007-1, Reinstatement of PGP Authentication Method. This proposal was first introduced on the PPML in October of last year, and was designated a formal proposal by the advisory
council in February of this year. This is the first public policy meeting discussion of this proposal. The text has not been revised since it was designated as a formal proposal. Simply, it supports the PGP Authentication. The shepherds are Leo, Bill, and Matt. Counsel has a substantial assessment here, and I will read this: "Counsel has some concerns regarding liability that might be imposed on ARIN by proposed policy 2007-1. These concerns may be resolved by explanation to cure my ignorance or by editing if the concern exists." "My most specific concern is that ARIN validate a chain of trust not longer than five steps. I'm concerned about fraud that may occur somewhere in the five steps that is not detected by ARIN. I have been told by techies that such an undetected fraud could easily occur." "Does this policy leave ARIN
responsible for damages to third parties, including our members, if it does not detect such fraud? It seems to me that establishment of an overall ARIN policy of cooperating in using PGP does not create this concern, but this specific language does. Is the additional language integral to PGP, and hence unusual and unobjectionable? I apologize in advance if this is an instance where my lack of technical knowledge creates confusion." Staff had several comments; I will paraphrase them. First of all, that we recommended that a new section be created in the NRPM to deal with this area, and call it "Communications," and that 12.1 be the authentication, and subsequent numbering would change appropriately. The proposal uses a term "crypt-auth" as a notation to be fixed to POC records. Such a notation is not technically necessary for ARIN's central authentication
methods. Continuing on, staff believes that there was a formatting problem with the policy submission. It appears that authors have inadvertently incorporated procedural texts under the headings "updates to templates," "updates to documentation" and "keys in use." In the section, keys in use in communication proposal requires validation of trust not longer than five steps. Some more comments in that regard. And the technical issue here is that -- maybe not necessarily a technical issue -- the PGP key for host master in arin.net exists at pgp.mit.mou as well as other well-known PGP repositories. This was set up in the early days of ARIN and it's -- the key is at this point MIA. So we've got some problems that we would have to deal with regarding that missing key. We also have raised an issue about
there being two e-mail addresses, hostmaster at arin.net and reassign at arin.net to easily accept e-mail. And so we did that to set up a differentiation for workflow, so we would have to deal with that as well. And proposal text that "ARIN shall PGP sign all outgoing hostmaster e-mail with hostmaster role key, as staff members may also optionally sign mail" and so forth, implies that staff may sign with arbitrarily sourced individual keys. And we would intend that if such keys are generated, they be signed with ARIN's hostmaster key in control procedurally to maintain communications integrity between ARIN and its customers. And the change would be the new Section 12. Implementation Assessment, staff believes that the resource impact is significant, it would probably take 4 to 12 months after BOT ratification. Implementation requirements are
registration software changes, template changes, directory service changes, guideline changes, and staff training. So far, in terms of PPML discussion, 180 posts by 21 people, 11 for, 2 against, in essence. Comments, it's fair to say it's time the membership put PGP into play. Why ARIN is still using e-mail for this process anyway -- 1997 is a long time ago. Under no circumstance should ARIN trust a message signed by key not registered with ARIN's for some business process. The full text is in your meeting handout, and it is also available at this URL. And at this time, I'd like to call one of the proposal authors, Mark Kosters, to come up and make a statement. But before Mark begins his -- come on up, Mark, his presentation, I believe the Chair has something to say.

MR. CURRAN: Yes. It has been noted that policy proposal 2007-1, -2, and
-3, which we'll discuss, are policy proposals that potentially, because of the nature of them and the fact that they discuss implementation, could have been made by ARIN's consultation and suggestion process. And the Board is aware of this fact, but the fact of the matter is that they are policy proposals. Some folks went through the effort of putting them out so that the members could see them and discuss them. We're going to proceed on the track that they're on, because that's the right thing to do. It is possible that after the ACs had consideration and the ability to move them that when they get to the board, they may be thought better handled by a different process. And I want to raise the fact that a few folks have approached me and said, do we really need to discuss these? We've got 13 policy proposals, these seem like implementation issues.
We're going to handle them as they were brought up, the policy suggestion -- the consultation and suggestion process -- was another alternative equally good? But it's not required one way or the other. So we're going to proceed as is. I just don't want people to be surprised if when it gets to the Board, we end up with the same results, only without actual change of text to the NRPM. Okay? Thank you.

MR. KOSTERS: I'm Mark Kosters, and I work for VeriSign. And many of you probably know that when it comes to some sort of controversial thing that goes on with VeriSign, I'm usually the guy who has to speak in front of the technical body. Well, here again, here's yet another controversial thing I'm talking about, but I'm very happy to say it's not on behalf of VeriSign. So I'm working with a whole host of Internet luminaries here on this particular proposal. And I'm going to need a lot of
help in going through this, but I'll do the best I can. One of the things that we had this sort of little cabal, and saying, man, we really need to do a better job of authenticating submissions that come in to ARIN, and what is one way of doing this? And we had -- back in the InterNIC days, we used to have more than just "mail from," we had a crypt password, which meant you put like a -- basically you put a little password on your e-mail submission. And the other one is PGP, and it was thought it would be a good idea to actually go through and to try to reinstate this. So here you can see the arguments in favor, and sort of the big thing that is -- what all this is about is actually bringing it up to the same speed as other RIRs in terms of authentication submissions. And this is actually not hard to actually implement it, so it's something that
basically the staff of the InterNIC did years and years ago. It probably is easier today. In fact, some of the software I have been recently playing with, I played it with an early 2000 time frame, and it's much easier now than it was back in those days. And the big thing that we need to do is, we need to look at how can we actually better authenticate these submissions as they come in, because we're actually -- as the Internet is becoming less and less sort of a safe place to be and we need to add on sort of stronger authentication through all the entry points that hackers can actually use. So the arguments against the PGP side is that there's a sort of misconception that the Web of Trust is actually involved in actually authorizing these changes. As we go through this presentation, you're going to see that that's really not true, and in fact, it's actually a bootstrap that's going to be used that I will talk about in a little bit.
So if there's anyone that says, wait a minute, this Web of Trust isn't going to work, there's no way that we can rely on a third party. Well, you really don't need it, and we'll go through that. So what happens here is that there's a confusion of authentication and authorization. So the authorization is actually what we're really interested in, and that is, does this party have the ability to modify their templates or their actual resources that are registered within ARIN? And really, that's the big thing. Authentication, making sure that their identity is there, that's a sort of a handshaking thing that actually occurs, and there's really nothing prescriptive in the policy on how to do that. It's really up to ARIN staff to actually make sure that this was the party that they really meant to talk to. So the second sort of argument
against it is it would be much easier to create a new authentication protocol from scratch involving web transactions. And we have a lot of this with SSL and so on, and maybe that would be a thing to look at in the future. But really when it comes down to it, PGP has been around for a long time, and as I said earlier, these technologies are becoming easier to use as opposed to harder to use. And there's a lot of plug-ins that one could actually put into the system. And this is also something that people, if their IT departments can't actually furnish this, there may be other alternatives they can use as well. So here is another argument against that actually was seen, and that is that the private key that's associated with hostmaster at arin.net is missing in action. And therefore, it can no longer use PGP. Well, really that doesn't matter at
all either. In fact, you can have another one with the same e-mail address, and it's really between the users of ARIN's service and ARIN to make sure that those keys are actually in sync. And you really don't have to use MIT key server to actually make sure that it's the same. It would be nice that they were uniform, but it does not necessarily have to be so. Now, another argument against it is that if this proposal was passed, that would require ARIN resource recipients to do something differently. And this does not change how you currently do services, so again, this is false. This is just an envelope that you could put on top of your submission to make sure that it comes from the party it says it is. And this again is something that's optional. So here is another one, as in terms of without a direct binding of the PGP key binding to the POC record, ARIN staff
won't know whether the e-mail is from the authentic POC. I have to look at this one. So this goes to the question of the sort of indirect levels of trust that's going on there. It's really between ARIN and the user of the service to make sure that that key is actually directly tied together, and this is something that you don't really require, you do not require a transitive trust actually for it to occur. And so you remember that whole sort of brouhaha in the list about, well, we can have five levels of interaction. Well, it doesn't matter, because it's really between ARIN and the party that's affected. And those things need to be tightly bound together. Here's the next one -- crypt-auth notation is not technically necessary for ARIN systems to discern authentication methods. Actually, this is not a problem,
and this doesn't have to be publicly available. The InterNIC in the days of old did make this available that -- so people who would -- when it came time for them to actually put their submission together, it may not have -- their communications may not have happened so much that they forgot what sort of method they used. And this kind of gave them a hint to make that occur, and maybe that's no longer a good idea, but that was the way it was done in the past. So here we go on the transitive distances are greater than five steps, and this may be overly prescriptive. And yeah, you know what, it can be. And the whole idea behind that -- Woody and I talked about this for a little bit, is the idea that PGP is a Web of Trust, and it's all about, okay, I know this guy, and I know this guy actually knows this other guy over there. And he signed his keys so therefore since I trusted this intermediate party, I
can therefore trust him, the third person. Well, that works well in the PGP Web of Trust, and the idea here is that maybe this could actually be used to help ARIN in the future if this becomes really sort of successful, helping them authenticate parties as they come into the fray. Saying well, okay, I know that Cox and Comcast have introduced this new third party over here, and since I trust the Cox and Comcast contacts, I can therefore trust this third party as well. And that again -- the idea, the mechanisms behind that are not actually in the document -- and that would have to be done by ARIN staff in terms of that ways that they best know how. From that perspective, it's not prescriptive, but perhaps this idea of having no more than five layers of interaction is. So that is the end of the presentation. Any comments? Did I just
totally blow you away with lots of stuff?

MR. CURRAN: Microphones are open for comments. When you come to the microphone, identify your name, affiliation, whether you're in favor of the proposal or not, and then keep your other comments to the minimum necessary. Do not repeat comments made by other speakers, thank you. Center microphone back.

MR. BICKNELL: Leo Bicknell, ARIN AC. I want to make one comment as the shepherd, and then one comment as myself. As the shepherd, I want to point out that although this did not go through a revision process after the AC accepted it, there was actually a rather extensive revision process that occurred before the AC accepted this proposal. So there has been some pretty significant editing on this particular trio. I also want to say that I fully support this proposal. I believe anything we can do to,
at the end of the day, get rid of "mail from" is a good thing. I think this is one rung on a very tall ladder, and that will compose many other things, and I think this is a great first step.

MR. CURRAN: Thank you. Other comments? Far microphone. Yes.

MR. SEASTROM: Oh, over here.

MR. CURRAN: Yes.

MR. SEASTROM: Rob Seastrom, ARIN AC. I'm in favor of this proposal. One of the problems that goes with trying to push something like this forward is a lack of good understanding. Especially when people like myself who don't use PGP in the larger communications sort of environment -- I don't publicly publish keys of my own, for instance, and then they are public servers. I'd like to underline two things that Mark pointed out. One is the length is subject to modulation by ARIN staff -- the length that ARIN will accept -- and that the
number of people who signed it is important as well, because that factors into that amount of trust you want to accord to it. And this really only solves the key distribution problems. It is not something where someone is going to be coming up handing a key to ARIN that ARIN has never seen before, and saying, "Oh, this is me." This is something that provides the key distribution solution so that at the inception of a business relationship, you can say, these are my keys, and this is how you can see that these are my keys.

MR. CURRAN: Thank you. Far microphone, yes.

MS. MURPHY: The other far? Sandy Murphy, Sparta. I'm in favor of this proposal. Ed Lewis pointed out on the list that the content is authenticated in PGP e-mail, not the header, so it's not guaranteeing the e-mail address. That means Mark could sign content,
and then he could mail it from any e-mail address that he has available to him. That unfortunately does bring up the possibility of replay. Mark sub-allocates something to me, submits a template sub-allocating something to me, he and I have a falling out, and he retracts that, and then I re-submit the original sub-allocation. So dates or something might be necessary. How much more time do I have?

MR. CURRAN: About 30 seconds.

MS. MURPHY: Okay. It's entirely appropriate for the policy manual to have something in it about security, and putting it in a publicly available place like the manual is a good idea. We might want to, if you're doing that, you might want to discuss what cryptograph, what security services are being offered, like authentication, or confidentiality. You might want to say it's crypto-based, no retinal scans please. Open
source, open standards, multiple implementations. Lots of community expertise, et cetera. At some point, you just want to say "Oh heck, do BGP." I mean PGP. Slip of the tongue.

MR. CURRAN: Okay, wrap up.

MS. MURPHY: And that's my reasoning for why it should be in the policy manual.

MR. CURRAN: Thank you. Okay. Front center mic.

MR. DeLONG: Owen DeLong, Jittr Networks. I support the policy. It's about time we had stronger authentication on templates. Thank you.

MR. CURRAN: Thank you. Center back microphone.

MR. LEWIS: Ed Lewis from NeuStar. I support the spirit of the policy. The question is about the five -- whatever. The other thing I want to bring up, though, was I don't want to see ARIN become a trust
introducer; in other words, ARIN signs other people's keys and put them back out in the wild.

MR. CURRAN: Front center microphone.

MS. AZINGER: Marla Azinger, Frontier Communications. I support this policy; I'd like to make a point of clarification that if this does become what we do doesn't mean that the other two options will go away. And that's just people assuming that maybe we might get there, but assumption, I'll use that word. And the number one to five, I had a very in-depth conversation last night about what that means and looked at ratios and really kind of came up with a different number that I'd support more than five, just because one is hobbling as far as you're really restricting it. Two, you're still kind of limping along. Three, okay, we're moving it,
that's a good ratio out there. But when you get to four you start to lose the security issue. So I just would push more for like three instead of five.

MR. CURRAN: Would you like to respond, Mark?

MR. KOSTERS: Yeah. Again, that's all with the sort of -- a sort of rosy view that this can actually help authenticate parties later on down the line. It's nothing about authenticating resources, especially when they first start out, because that actual handshake has to happen between ARIN and the affected resource owner or holder. And those two parties need to have some sort of communication that assures that the resource holder is the person who they say they are, and knows is the key that is associated with it -- has nothing to do with the two to five sort of degrees of freedom that you can actually use with us from the later perspective.
In fact, I think the authors agree that this is something that probably should be taken out because it does introduce confusion and is really not necessary.

MS. AZINGER: It introduces confusion that I could see the ARIN staff asking for guidance on what -- how many steps out they should allow. And the only reason I say push it back from five is because it's really easy for us to start with a smaller number and then push it out to a larger number, but it's a little harder to go the other way.

MR. KOSTERS: Yeah.

MR. CURRAN: Good point. Far microphone over here.

MR. RICH: Yurie Rich, Command Information. I support this proposal. I guess I'd ask in reviewing the policy as it moves forward what risk does ARIN take if we don't implement something like this, since it's more of an industry standard than our
current practices?

MR. CURRAN: Do you want a formal answer on that or --

MR. RICH: No.

MR. CURRAN: Thank you. Far microphone over here. Yes.

MS. MURPHY: Am I allowed again?

MR. CURRAN: Yeah.

MS. MURPHY: Sandy Murphy, Sparta. Two other short points. The language of the three proposals all together provides that these exact mechanisms be the ones supported, which lets out the case that something becomes widely popular, something new. And it might be good to modify the language to make it possible to add something later if it becomes available. There is language in the policy that says the POC may indicate crypt-auth, and then "mail from" would be prohibited; that means that there's a possibility that both might be in effect at the same time, and that might be a good thing
for incremental deployment, but it does open the opportunity for downgrade attacks. So I'd recommend doing something to the language to talk about that.

MR. CURRAN: Okay. Thank you.

MS. MURPHY: Did I say I supported this proposal?

MR. CURRAN: Yes.

MS. MURPHY: Okay.

MR. CURRAN: Center microphone, back.

MR. SEASTROM: Rob Seastrom from ARIN AC again. Conversely to what Ed said, I agree with him that ARIN should not be in the trust introducer capacity, but I think that ARIN should absolutely be in the interest of assigning keys, the signed fingerprints of which and the signed public half of which are kept private for those who of us who don't want, for reasons of our own, our PGP key floating in the wild. Do you follow that?

MR. CURRAN: Okay, yep. Care to
respond?

MR. KOSTERS: I have really no sort of issue either way.

MR. CURRAN: Good comment. Any other comments? We've heard from a lot of people who are in favor of this proposal. If anyone is against this proposal, could you seek out a microphone, please? Okay. Thank you, Mark. (Applause)

MR. CURRAN: From time to time, it's the job of the chair of the meeting to solicit a show of hands in order that the AC can have guidance on what they do with these policy proposals. I'm about to solicit such a show of hands, where I'm going to talk about policy proposal 2007-1, Reinstatement of the PGP Authentication Method. I'll ask for one show of hands in favor and then one show of hands opposed. At this time, if you're in favor of advancing policy proposal 2007-1, please
raise your hand. Nice and high. Okay. All those opposed to advancing policy proposals 2007-1, please raise your hands. Okay. We have a count. First, I'd like to say the count in the room was a little lower last time. It was artificially high because we had staff in the count. It was not 114 -- with the removal of ARIN staff, it was close to 100. At this time in the room, not counting staff, we have 84 participants. Those in favor of advancing policy proposal 2007-1, 47 -- those against, 0. Thank you very much.

2007-2: Documentation of the Mail-From Authentication Method

MR. PLZAK: Next proposal is 2007-2, documentation of the "mail from" authentication method, which was introduced last October, designated a formal proposal in February of this year. First discussion meeting is this meeting, and the text has not been revised. It defines "mail from" as the
default authentication. Relies on the adoption of policy proposal 2007-1, reinstatement of PGP authentication method. The shepherds are Leo, Bill, and Matt. No risk and liability. Staff comments are that that "mail from" is the default authentication method. It is not used to protect against vandalism. Even an authenticated user can vandalize. And again, the same recommendation regarding the NRPM numbering. Resource impact, minimum. Implementation within 90 days after Board of Trustees' ratification. Change of requirements basically are guidelines, changes in some staff training. Not much discussion on this topic. 23 posts by 11 people. 4 for, 1 against. Comments are "e-mail mechanisms been in place for over a decade and won't go away anytime soon." "I like the idea of having access to a method such as SMTP, and we need to remove 'mail from' entirely."
So with that, the text is in your handout, and also is available online as you URL, and I'd like to call Mark Kosters back up to present this one. So and Mark is speedily hurrying up here. So why he went so far away is beyond me because he knew he'd come right back up here again. I guess you just want to be up here to take the slings and arrows and since you can't do it for VeriSign.

MR. KOSTERS: Thank you. So okay, so this is here for completeness. So this is the default sort of authentication method, and this is trivial to actually forge. And I'm actually -- can I say something controversial?

SPEAKER: No.

MR. KOSTERS: No?

SPEAKER: No.

SPEAKER: That's my job.

MR. KOSTERS: Whose job is it? Bill's job. So I guess I look at it from,
I'm not a lawyer here, but as a common sense sort of like houseowner, I like to keep my doors locked when I leave, and this seems like a good way of inviting someone in if you leave your doors unlocked and open. And whether or not there's liability associated with it, I don't know. So this again is here for completeness. This is really sort of the sort of default mechanism if none other are chosen, and so this is just here. So are there any questions about this? This is the one I'm probably the most embarrassed about.

MR. CURRAN: Microphones are open for questions. Microphones remain open. At this time, you can stay up here, Mark. Thank you for that eloquent presentation. At this time, I once again seek a show of hands on this policy proposal. I'm
going to ask for one show of hands in favor and one opposed. Yes?

MR. HOWARD: Can we have the text of the proposals back up, please, in case anybody is unclear on what we're voting on?

MR. CURRAN: There you go. Okay, policy proposal 2007-2, documentation of the "mail from" authentication method. I'm going to ask for a show of hands for all those in favor, and then a show of hands for everyone opposed. All those in favor of policy proposal 2007-2, please raise your hand nice and high. All those opposed to policy proposal 2007- 2, please raise your hand. And another highly contentious vote. Policy Proposal 2007-2; 84 people in the room; all those in favor, 42; all those against, 0.

2007-3: Documentation of the X.509 Authentication Method

MR. PLZAK: Next item is policy proposal 2007-3, which is documentation of
the X.509 authentication method. Introduced in October of last year, designated a formal proposal in February of this year. This is the first meeting in which it's going to be discussed. The text has not been revised. The proposal simply supports X.509. Authentication relies on the adoption of proposal 2007-1. The shepherds are the same three individuals: Leo, Bill, and Matt. Counsel sees no liability risk. Again, the staff comments regarding use of the term "crypt-auth," and also staff comments regarding the renumbering of the NRPM. And some -- policies of the general term communication which may be interpreted to cover other forms of electronic interactions such as web-based communication. The only other communication that is directly tied into a specific POC is voting. The election system needs to be modified to elect X.509 authentication,
assuming we could use parts of the existing system. A ballpark estimate implementation would be three to four months -- talking about the election system. So resource impact to be minimum. Implementation probably about 120 days after ratification. Implementation requirements are changes to the election system software, guidelines change, and staff training. PPML posts -- 23 by 10 different persons. 2 for, 1 against. General comments are "Having once considered how we would go about arranging for security e-mail view the X.509 where PGP, I'd settle first for X.509." Relationship is clear. "This the kind of rathole you get into when you put too many details into a policy, policy is not a process document, policy is the general framework that defines limits, mandates," and so forth. And lastly, what if a POC is both the PGP assigned by ARIN key and an
ARIN-issued X.509 certificate. The text is in your meeting handout and is also available online at this URL. And I'd like to turn it back over to Mark for the presentation of this proposal.

MR. KOSTERS: This is yet another sort of key variant. It's very similar to PGP but it's just using a different format. You have a private key and a public key. And the public key actually is associated with the data that you maintain, and whenever you submit something in, it has to be signed by that private key, and ARIN actually verifies that yes, this signature that you have sent actually covers this resource that you have, and is verified and is good to go. So there's not much of a difference between X.509 and PGP. The only sort of thing that is different is that X.509 usually is associated with certificate authorities and I know just a bit about that. And -- it has a little bit -- some people like it,
other people don't. And so it's there as one of the sort of the stronger authentication methods to deal with ARIN. This again is here for completeness. ARIN has X.509 facility that's already baked in. I didn't -- I'm not sure about what the other authors think, but I didn't actually realize that ARIN was contemplating using this with the election mechanism. That's kind of an interesting idea. I kind of liked the password idea there, but Woody, want to say something about that?

MR. WOODCOCK: Speaking as one of the other authors and not as a Board member, and neither in favor nor against this particular proposal -- that use of it was not anticipated by the authors and was not intended by the authors. If staff feels like doing that, that's up to staff, but it certainly wasn't any part of the point of this. This is merely intended to complete
the documentation of the three authentication methods in the policy document. No more.

MR. KOSTERS: So to kind of reinforce that, I guess we were looking at this as mainly as a way to secure ASs and IP network information within ARIN, as opposed to dealing with election sort of information stuff. So that is the end of the presentation. Any questions? Pretty easy stuff.

MR. CURRAN: Microphones are open. Yes, Mr. Manning.

MR. MANNING: My name is Bill Manning, and I think I support this whole class of proposals, but I'm concerned that we do not have a defined mechanism for re-keying when somebody loses their keys. I don't know about anybody else, but I lose my keys all the time. And I really don't want to have show up in the ARIN offices to re-establish my authenticity over the resources that I
have been delegated. So I'd like to know how you recover from lost keys or lost PGP keys or any of that kind of stuff.

MR. CURRAN: So Bill, would you be against advancing the proposals as is?

MR. LEWIS: Ed Lewis, NeuStar. I'm in favor of the proposal. I'm actually in favor of having this proposal available whether you want to use them or not. I think the office should be out there. That was my comment I was going to make, but I want to answer Bill's question, because when we looked at this few years ago, we asked folks in other regions what was happening with their certificate systems, and he said the most common re-keying occurred with the laptop when the key crashed. The private key was then gone.
And they just went to the process and said the same way you got the first key and we did it again, because again, in this case, the studio authority at the RIR is not used to trying to keep you outside the RIR's realm of interest. It was a closed smaller job than being a general purpose CA.

MR. CURRAN: All right, acknowledged. Front center microphone.

MS. SETTLEMYRE: Allie Settlemyre, Microsoft. What information is going to be required to actually get a key? Because in the APNIC region, you actually have to send them a copy -- fax them a copy of your driver's license, which is kind of ridiculous.

MR. CURRAN: So to ask the question, there's no statement right now of information about what would be required, which would be against the policy as written because of this issue?

MS. SETTLEMYRE: Yes.

MR. CURRAN: Okay.

MS. SETTLEMYRE: Because it is painful to get a key. It takes a couple of weeks. You have to provide the same information that you provided the first time, just from the other regions.

MR. KOSTERS: May I answer --

MR. CURRAN: Go ahead, respond.

MR. KOSTERS: One of the things that we have -- the other authors and I have kind of struggled with is the idea of it being too prescriptive or not. And this is more sort of -- here's the facility -- here's one of the frameworks that you can use to authenticate this information. How that works within that framework is really up to ARIN on terms of how hard or easy they want to make it to issue you -- actually, you have to generate the cert and they have to actually sign it. So how that signature actually happens is really up to ARIN to implement as opposed
to -- I don't see that in the policy. Otherwise, it starts getting on the prescriptive side.

MR. CURRAN: Center rear mic.

MR. SEASTROM: Rob Seastrom, ARIN AC. I'm in favor of this proposal. I'd like to address Allie's concern firstly. The idea is to provide a multitude of mechanisms by which you can authenticate. If you prefer PGP because you like the idea of a public Web of Trust and making it easier to replace your key should you lose it, then you should use PGP. If you're masochistic and really like OpenSSL Command-Line with 50 different flags on it to get it to do one simple operation, then you should obviously use X.509, and if you want people to rip off and steal your resources, then you should use "mail from."

MR. CURRAN: Thank you. (Applause)

MR. CURRAN: Far microphone. Yes.

MS. MURPHY: Sandy Murphy, Sparta. I'm in favor of the proposal. I did come up with the question -- you were talking about VeriSign has some experience with running CAs.

MR. KOSTERS: Oh, oh.

MS. MURPHY: Which brought to mind the question of, "Oh, multiple CAs." The PGP proposal is specifically designed to have keys with other trusted introducer signatures on them. ARIN currently runs its own CA. This is intended to document current practice, but this language itself doesn't say anything about that. Is there any intent of accepting X.509 certificates signed by other CAs other than ARIN or one of the other RIR CAs?

MR. CURRAN: That's actually probably out of scope of this particular proposal, meaning that it's not addressed either way.

MS. MURPHY: Uh-huh.

MR. CURRAN: I'm going to ask again, as phrased, are you in favor of this proposal?

MS. MURPHY: Yes.

MR. CURRAN: Yes? Okay. So the question is, would you prefer to see this proposal specifically say it should accept other X.509 certificates?

MS. MURPHY: I'd prefer that it said whether it meant it to be only ARIN CAs or whether it would open it to other RIR CAs or whether it would open it entirely. I think it is a matter of policy to state --

MR. CURRAN: What --

MS. MURPHY: That --

MR. CURRAN: What is your preference that it should say?

MS. MURPHY: Oh -- blah-blah-blah, ARIN and other RIR CAs.

MR. CURRAN: Okay, so noted. But as is, you would advance it as is even with
that omission?

MS. MURPHY: Yes. For the third time.

MR. CURRAN: Thank you. Front center microphone.

MR. DeLONG: Owen DeLong, Jittr Networks. I support this policy. And what Rob said.

MR. CURRAN: Okay, thank you. Oh, and I just want to say in response to the prior comment, the question about accepting other RIR CAs would be a great topic to bring up at the open microphone. I want to continue to advance the policies as written, but that's not to preclude the thought. It's just I want to keep us focused on the policies at hand. Okay, thank you. Center rear mic.

MR. LEWIS: Ed Lewis, NeuStar again. Still for the policy, to answer Sandy's question, if we're going to just
ARIN-issued certificates under the same principle that Marla said, it's easier to expand your permissiveness and security than to constrict it.

MR. CURRAN: That's kind of why we have lots of good, juicy debate.

MR. KOSTERS: So I actually have, as an interested observer listening to this, it really turns out to be, from my perspective, however ARIN associates that resource to the POC, whether it is a thought CA, a VeriSign-issued CA, a valid cert CA; it doesn't matter. It is that public key that you're after and tying it together, and it could be an ARIN CA. It really doesn't matter in that perspective. Now, it's up to ARIN in terms of how they want -- whether the actual sort of nitty-gritty sort of process -- sort of issues that they want to actually solve with it. But it's really just that that public key associated with that entity is really
what we're after here.

MR. CURRAN: Microphones remain open for the topic of the proposal on hand. Any other comments on the proposal? All right. Thank you, Mark. (Applause)

MR. CURRAN: At this time, it's necessary to get some input for the AC to help them in their process. So I'm going to call for a show of hands in favor and opposed to policy proposal 2007-3. I'm going to ask for one show of hands for each. Everyone ready? Everyone in favor of policy proposal 2007-3, please raise your hand nice and high. Okay. Everyone opposed to advancing policy proposal 2007-3, please raise your hand nice and high -- wherever you are. Okay. We have a count? Okay. Total number of people in the room, 84; those in favor of policy proposal 2007-3, 43; those against, 0. Thank you very much.

MR. PLZAK: Thank you, John. Thank you, everyone. I really want to congratulate you all. We're actually moving through very efficiently and quickly today. Although it doesn't mean that we will continue that way. So it's now time for another set of announcements, and we're about ready to break for lunch. Regarding security, this room will not be locked, so there's no security here. So take your valuables with you unless you care to risk donating them to someone else. Don't forget to go to the Cyber Café. There is Internet access and materials and presentations. Don't forget Vanna -- excuse me, Richard -- will be back through doing the prize raffle, and there were two winners at the morning break. So just remember, complete your raffle entry form, one per day. We will draw two more this afternoon. If you haven't completed this particular questionnaire, please put it in.
And if you're present when your name is drawn, you get to spin the wheel and win a prize. One of the prize winners this morning did a real nice dance while the wheel was spinning, and I don't know that necessarily helped him or not. So you can do anything you want, I guess. So anyway, please do that. There are 12 lucky winners in total, and the grand prize, which is already gone, it was won this morning by Didier; and Andrew Dul was the other winner this morning, and he won a USB lava lamp. How cross-decade can you get?

SPEAKER: Dude, that's so cool.

MR. PLZAK: And it is right there for everyone to admire. So anyway, don't forget the help desks are open in the Cyber Café, the registration services, and financial services. Make appointments or just drop by and talk. And please don't forget to complete the meeting survey and enter your raffle entry for -- to be the one
lucky winner of the video watch. And let's again thank our sponsors and special participants. (Applause)

MR. PLZAK: And so lunch is served. The meeting will resume at 1:30 p.m. Thank you.

IPv6 Routing Table Report

MR. PLZAK: Welcome back. We'll begin the afternoon with a couple of reports, and then a panel. So the first report will be done by Cathy Aronson. It is an IPv6 Routing Table Report. Cathy?

MS. ARONSON: Wow, that's really hi-tech. Hi. Do I have slides? I do. In an effort tonight, I have to make a presentation myself, I had swiped this one. I haven't presented this in probably three years maybe, but this really neat fellow named Gert, he does -- since 1999, he's been looking at the IPv6 Routing Table and how it's changed and silly things that happened. And it's kind of neat, because we didn't really have this kind of information when we started out, when the v4 Internet was really small. And so it's kind of neat to kind of follow it through time, and since he
doesn't have a travel budget, I have kind of given this in a lot of different places over the years. So that's what this is about. I'm going to talk a little about some trends, you know, like the size and all the McDonald's graphs, and the 6bone and some other things. And the slides are available. He usually gives this at every RIPE meeting, so it gets updated twice a year. So this is the McDonald's graph, you know, upward to the right. Some things drop out here and there. And the x-axis is actually the year/the month, which confused me a lot when I first started looking at these, but they are all pretty consistently that. So there is about almost 9,000 prefixes in the v6 routing table right now, which is kind of cool. I'm sorry?

SPEAKER: 900.

MS. ARONSON: 900. Did I say
9,000? I woke you up, didn't I? Next time, it will be 90,000. This graph shows that most of the 6bone has gone away, as it was planned to go away on -- when was it -- 6/6/06, which is kind of catchy. So the 6bone prefixes have been going down over time, and the RIR-assigned prefixes have been going up over time. This is, as you can see, the 6bone is for all intents and purposes dead at the bottom. And then this little blip here is one of the little things that happened. There were a bunch of more specifics injected, and then they disappeared. This happens seemingly a lot, because the people -- there aren't as many rigorous peering (?) arrangements or filtering agreements or even filtering that we have in v4, yet with v6 still. Even though it's been three years since I presented this, I don't think any of
that has changed. This is where the 3FFE, the 6bone prefixes were returned to the ICANN/IANA and then it was down to a few in -- what is that -- September, and now, it's down to 1. We'll talk about that in a minute. Here it is. So there's 1 AS -- Bill Manning, who's announcing 3FFE prefix that he shouldn't be --

SPEAKER: (Off mic)

MS. ARONSON: To the Global Internet, and I was just -- through all this, I was looking this up and realizing that he would be here and I would get to say that. It's pretty cool. We're not really sure why, but apparently, he's aware of it and he doesn't seem to want to comment. So --

MR. CURRAN: Mr. Manning, go ahead.

MR. MANNING: I would like to comment but the microphones are out. The particular reason that prefix is still around has to do with the fact that there is a set
of DNS servers that were numbered out of 3FFE space. And somewhere along the line the IANA removed the capability of manipulating host records. So we announced it because there is a name server there. And when we can change the host records, then we get rid of it.

MS. ARONSON: Seeing that these blocks have been given back, you're a hijacker.

MR. CURRAN: Just to be clear, the records are served by multiple name servers; right?

MR. MANNING: That's probably true.

MR. CURRAN: And they're not all in 3FFE space; right?

MR. MANNING: That's correct.

MR. CURRAN: I just want to ask those questions for the sake of people building active filters worldwide right now.

MS. ARONSON: Right.

MR. MANNING: So you can make that particular -- the name server in question is
the only one with a v6 address for that particular delegation. But I've talked with the IANA there, and I will continue to do so, and we'll see if we can come to a resolution of this.

MS. ARONSON: Excellent. And meanwhile, as Gert says here, the v6 Internet is still around even though the 6bone has gone, and that people should perhaps stop giving transit to 3FFE since it no longer is assigned to anyone. It's been given back to the IANA/ICANN -- just like the RFC said. Pretty fabulous. So the thing that amazed me when I got these slides about a week ago is that one thing hasn't changed in three years; there's still this bug, so when I first started presenting this, there was this bug, and I don't know how many of you were here at the meetings then. But basically what happens is if you inject a bunch of prefixes by mistake and then you withdraw them, if all the timing
is right and the conditions are right, the router never sends a withdraw, so they just stay there forever. And this is an incident, the one that says the big drop is an incident where somebody dumped (?) a whole bunch of networks and they -- everybody filtered them out but they're still there because of this. And there's actually a bug ID, it's a CISCO bug, and there's a bug ID, and I guess it's fixed in some of the newer versions of code, but not everybody has them. So that's pretty interesting. It took a long time to figure out what it was and how it was happening, and then it took a long time to fix it, and now it's taking even longer for people to upload the code. So that's pretty interesting. This is the breakdown of prefixes by RIR, and you can see -- I think that the 6bone, you can see where it dropped off, and then you can look at -- you know, RIPE is up
at the top, and APNIC is in red, and you can look at the different -- who's assigning what over time, which is pretty cool. And then you can also see where that more specific bug was, and that that happened in the ARIN region. Isn't that fabulous? And then because this is a more RIPE-centric talk, this is actually a breakdown of 6bone prefixes per country in the RIPE region, for the major countries in the RIPE region. So you can look at -- it would be cool to have this for here, but we don't. And then the AS numbers that are in the v6 routing table. There were 487 origin-only ASes, and the numbers all the way to the right are what they were the last time he gave this talk, so that would have been at the last RIPE meeting, and the next RIPE meeting is like next week. And then there's a mixture -- over time, they are a mixture of RIR and 6bone
space advertised, and how many -- there's 590 ASes that only announce one prefix, which is pretty good. And then there's that one pesky 6bone prefix that's still out there. And there's also quite a few ASes that are still announcing they got their 35, they got bumped up to their 32 because of the policy change, and they're still advertising both the 32 and the 35. And all of these paths are observed. This is a snapshot of a view from Gert's AS, so it could be slightly different depending on where you look at it on the Internet. So again, there was this migration from 35 to 32 -- and a lot of people -- I guess, I think this AS -- I mean there's nothing wrong with having them both in the routing table. I mean, some people just -- and then there's some traffic engineering going on, which is what the next thing is. There's also some exchange
points -- more specifics that are getting advertised, and then there's a whole mergers and acquisitions thing that he's been tracking, which is at the bottom, with NTT Japan and America and stuff. This is a breakdown by length of prefix, and the numbers all the way to the right are what the numbers were for each column last time he gave the talk. So there's a lot of /32s, there's still some 35s from when that was the minimum allocation. There's a bunch of more -- there's 134 /48s, and there's a breakdown of some of those a little further in the talk. Go --

MR. CURRAN: Sorry. This breakdown of the 48s, is there a breakdown of the larger prefixes, like the 3 /64s and the --

MS. ARONSON: You mean the longer ones?

MR. CURRAN: The longer -- I'm sorry.

MS. ARONSON: I don't know if he
has that in here or not, but it is pretty funky that there are three /64s in global routing table.

MR. CURRAN: Okay.

MS. ARONSON: Filters would be a fabulous thing.

MR. CURRAN: Okay.

MS. ARONSON: But there's only 7,000 prefixes, John.

MR. CURRAN: Uh-huh.

MS. ARONSON: I mean 700, you know that, but -- and then he looked -- there's 1,144 LIR blocks that have been assigned by the different RIRs, and this is a breakdown of like what percentage of a region's members have v6, so in ARIN region, it's like 8-1/3 percent. And then the percentages on the right are what they were the last time he gave this talk. So they're going up a little bit, and AFRINIC has like the biggest jump, because they have 11 and they used to have
one. Let's see -- this doesn't count the micro-allocations, like we in this region give out /48s. And then I have another slide about this, but there's a miniscule amount of these that are actually visible in the global routing table. So this graph, the solid bar is the total allocations for that year, and the year is on the x-axis. And then by how many are routed for each year -- on January 1st of -- like '03, the red ones were in the routing table, and January 1st of '04, the green ones were in the routing table. So as you see over time, more people are getting blocks than are advertising it. It used to be really closely aligned. Like they would get it, they would advertise it, and now like almost -- in '04, almost twice as many allocations were made than showed up in the routing table. So I don't know whether that's a land grab thing or -- we're not really sure
why that is, but it's kind of sad, like people are getting blocks and using them or not using them, or maybe not routing them. But there's also a bunch of very large applications that have happened recently, when -- he's listed some of them here. Let's see. And then there's been allocations to -- there's a bunch of PI allocations within the ARIN region that are listed here. It says 43 direct assignments from ARIN, and four of them are in the BGP. It's kind of a bummer. And then there's also been a bunch of anycast assignments, and his point is that we should all -- if you are filtering IPv6, that you should make sure that you're familiar with this list, and that you're letting them in in your filters. And then the RIRs -- I think Leslie talked about this -- the RIRs have gotten /12s recently, and so those are all listed here. And there's actually the webpage in
these slides for where you can look to make sure your filters are up-to-date. And then the -- it looks like the RIPE region, they've started putting route objects for v6 in their routing database. And so this is a tracking of the objects in the routing database versus how many entries are in the routing table. And he hasn't done a one-to-one correlation, so there could be route objects that don't actually have routes in the global routing table. He's going to start trying to pair it up, but it looks like over time that more and more of the route objects are actually appearing in the database, which is useful for people doing routing. And this is how you do it. If you want to do it, you just fill out this form and you put your information in the database. This is really fascinating to me, so that's an April Fool's joke -- somebody -- his name is at the bottom. He wrote some code to do
this longest path, geographical longest path stuff on the routing table. Well, it turns out that some of these packets that we're sending with v6, I don't know about with v4, were going like 40,000 miles or 40,000 km to get to where they're going, from Ireland to Germany to the Netherlands to U.S. to Japan to the U.S. to Japan. That's kind of insane. There's like -- it's really interesting to read this paper, because there's a ton of these, and the data is just going everywhere to get to where it's going. And if you look some of the times, there's like a router somewhere that actually could be peering but isn't, so the packet's going all the way back across the country again. And some of this may also be because in v6, we had so much tunneling, and I don't really know how much tunneling is still going on, but it could be still pretty significant. So the tool -- the ghost hunter 1 -- which is those big paths, is
available, and then these are some other things. There's also a peering policy project that has been going on for several years, and that's available at the URL that's listed, which I think that more people with v6 over time will start having peering policies and filtering. So that's it. And if you have questions, I might be able to answer them, or we can refer to the expert.

MR. CURRAN: Does anyone want to ask Cathy questions about the presentation? Sort of stump the Cathy?

MS. ARONSON: It's not hard.

MR. CURRAN: Thank you very much. (Applause)

IPv6 Multihoming BCP

MR. PLZAK: Next up is a report from Marla regarding the IPv6 Multihoming best trend practices.

MS. AZINGER: Hola. (Speaking Spanish)

MS. AZINGER: Hello, my name is
Marla. (Applause)

MS. AZINGER: Thank you. I work for Frontier Communications, and I am the Chair of the AC. And I also do the peering coordination for Frontier. And I have the pleasure of traveling and following the IPv6 multihoming and traffic engineering issue that we're all working on. So this presentation is a brief review and updates on my happy pursuit of IPv6 Multihoming and Traffic Engineering. And when I first started this pursuit, these were two of the primary questions that I put out, so some of you may have seen some of these slides before. What solutions exist or can exist in order to enable v6 multihoming and traffic engineering? Can we come to an IPv6 multihoming and traffic engineering solution on a global scale? And I believe that in summary, the
answer is yes, and we're working on it. That moved this on to how exactly the solutions for IPv6 are being made. Discussion is occurring within IETF. The location of the discussion has been -- for lack of better terms, a moving target -- first it was an IPv6 OPS, then the IAB, and now within the IETF. And acronyms are in multiples and it keeps traveling around, but it's getting worked on at least. So believe it or not, having it travel on to many different groups, still hasn't dropped the ball. So I actually am impressed with that. The fortunate thing -- we're not getting distracted, and the circumstances and a lot of the white noise that was there before is quieting down, and people are starting to get more focused on actually looking for a solution that we can implement. The document of current possible solutions with their pros and cons is still
available on the "nro.net," and it would soon be updated with two newer possible solutions that are being worked on in the IETF community. This is the long one. These are the suggested solutions that we have had before so far. CIDR boundary. A few people are doing this currently, but not preferred method, and that's due to route increase and aggregation increase. Second one is aggregation slicing. This one is just not being discussed. Metro. A few people have expressed interest in this, but it's not been accepted widely. At most, you will see that small localized attempts to do this are occurring, and probably will continue to occur. But it's not going to be the main means of a resolution for the traffic engineering and multihoming. Community codes. This is still under discussion, and actually may be
integrated with a few of the other solutions that are being worked on right now. A published list, this is not being discussed. Policy. A few have discussed this on the side table type events, maybe at the bar. But it's not been heavily pursued as an interest of how we want to resolve this. Shim6 is being worked on, and it's not being accepted widely. Map and Encap -- there's a heavy focus in this area and a strong desire to fix not just multihoming and traffic engineering, but to address the health of the Internet as a whole. Therefore, the desire to create a solution using a protocol is being heavily focused on. And our Locator ID Separation Protocol that has been given the nice little acronym LISP, and enable Future Internet innovation through Transit wire. Nice mouthful. That one's eFIT. Briefly, the draft on LISP describes a simple incremental network-based
protocol to implement separation of Internet addresses into endpoint identifiers and routing locators. This mechanism requires no change to host stacks, and no major changes to existing database infrastructures. Their proposed protocol can be implemented in a relatively small number of routers. Briefly, the eFIT proposes to move Internet Service Providers to a separate address space, then end-users, and suggest a way to make this work, just by coupling it with the means to provide the mapping services between user and provider address spaces. Those are the two newer ones. Max prefix was another one, and that one is not being discussed. And I didn't review in-depth all the many other ones. I only reviewed in-depth the two newer ones. And this slide, I just want to put out there because I would like to put forward special thanks to the following people that I
have been working with and are dedicated to finding a solution, and have been very open and honest in working with the issue at hand. I have a great appreciation for all of their hard work. Some of these people have been working on this for -- you can even say a decade. And some are newer, but they're all working really hard. So David, Dino, Vince, Chris, and Jason, thank you. And this one -- what would an IPv6 presentation be without recognition of Jordi? You can't do it. So while in Bali, Jordi started a new IPv6 campaign, one that unites two respectable movements; the fight against global warming, and IPv6 utilization. So good job, Jordi. And he will be given a chance at open mic right after this, if he would like to explain himself to everybody. So now back on to a more serious note. If you would like to understand more
about the new suggestions put forward, you can go to the following web links and read the draft documents that have been submitted to the IETF. And it would be fantastic if you did, and went to the RAM mailing list and put in input. But these are where they're very, very detailed. So get a cup of coffee or whatever and have at it.

MR. CURRAN: Microphones are open. Any questions for Marla? Apparently, we take questions in English or Espanol. No? Okay, thank you.

MS. AZINGER: Gracias. (Applause)

Legacy Address Space Panel

MR. PLZAK: If you would bear with us a moment, we need to change some seats up here. So we're going to bring the panelists up for the panel discussion. So we will bid a fond farewell to Cathy and Matt and Marla. And now I'd invite up the members of the panel. See if you can all get here. So please come up.
Missing one person. It's our learned Counsel. Would someone please go find the lawyer? Is there an ambulance out back? So anyway, let's go ahead and get started. I want to do a couple of things here. First of all, to help set the stage, we pulled together some numbers out of the ARIN database regarding legacy address space. And to set a definition -- and Leslie did talk about it a little bit this morning. Legacy IPv4 address space is considered to be that address space that has not been issued by an RIR. It was --

SPEAKER: RIR.

MR. PLZAK: RIR -- here we go. I'll get it straight one of these years. It is address space that was either issued directly -- allocated directly by the IANA, or by the Internet Registry prior to the Regional Internet Registries, and that would be from the DDN NIC, the SRI NIC, or
Inter NIC. So that's the characterization of that address space and how persons got it. So if you look at the number of the direct registration records in the ARIN database, it's somewhere around 40,000, and about 82 percent of them are considered to be legacy networks. And of those, 16,000, or about half of them, have been updated in some shape or form since December of 1997. So that's about 54 percent. And of the 20,000 organizational records associated with these networks' registrations, about 48 percent of them have been updated since ARIN's inception. And of those, 2,277 of them, or about 11 percent of the total number of organization records associated with this address space, these organizations have R.S.As, Registration Service Agreements with ARIN. And so looking at it from another perspective, out of the 31,000, about 44 percent are shown to be routed, or at
least signed in -- 13,000 are being routed in some form and 17,000 are not being routed. So that is sort of the numbers we're talking about. The panel is going to make some comments, and then solicit your comments. But a couple of ones that spring to mind immediately have to do with should this address space be subject to the policies that are developed by this community? Should these organizations receive services other than the services that were in existence at the time they received the address allocations? And as ARIN moves forward and different things go on, we have added services over time, and we'll continue to add services in the future that could affect the way these networks are used. So with that, I will turn it over the moderator, John Curran. John.

MR. CURRAN: Thank you, Ray. So we
have collected an esteemed panel here for a variety of viewpoints and backgrounds to talk about the legacy address space issue, and to share some perspectives that might be held by members of our community. What I would like to do is have each member of the panel speak briefly sort of on their views on legacy address space in ARIN, and what they see the issues are. So I'm going to start with Bob. If you would do an introduction --

MR. ANTIA: Sure.

MR. CURRAN: And talk about your position on this matter.

MR. ANTIA: Sure. Bob Antia. I'm the CTO of China Managed Services. We're providing managed services in the Chinese telecoms. As a legacy address holder, up to now, ARIN's been invisible to me. And in talking with other legacy holders, it's pretty much the same. There hasn't been any outreach. There hasn't been any marketing or any sales to us on why we need ARIN and why
we should subscribe to ARIN. Many of the legacy holders would be willing to give back address space if there were, in their view, a predictable outcome, in that they could negotiate their way into a solution that would be most satisfactory to ARIN, and satisfactory to the organization. Many organizations that have legacy address haven't been very good about managing that space. So the consolidation of that space will ultimately cost some money, and there's no return of that investment. So it's going to be on a whole prioritized down in most organizations, without a return on investment. I believe there's an opportunity for ARIN to work with the Department of Commerce and get an -- there's an opportunity for a tax deduction for bringing stuff back. There's an opportunity for ARIN to reach out and take fees away for bringing back -- so I think there's a lot of things that could be
done to reach into this community of address holders and bring them into the fold.

MR. CURRAN: Good to hear. Next?

MR. SHACKLEFORD: This is Scott Shackleford, Cox Communications, a non-legacy space holder. When I was asked to be part of this discussion panel, it was kind of easy to have just the initial stance of space is out there, and they're not using it, and they don't need it. They should give it back. And probably a lot of you would have that as well. Admittedly, I didn't have as much of an understanding of their point of view, so to speak, but recent conversations with Owen and Bob here definitely have enlightened me to see that it's a much larger issue. There are many more facets involved than I would have thought were even in existence or worthwhile. So I kind of have a revolving door
opinion right now. And I'm saying that not to be Charlie Brown wishy-washy, but just to keep an open mind, and try to see all of the areas that need to be addressed. So I'm very vanilla right now until I can just kind of soak it all in.

MR. CURRAN: Okay, next.

MR. DeLONG: I'm Owen DeLong. I am a legacy space holder. I'm kind of the exception to the rule in that I'm a legacy space holder, who, as a lot of you probably know, has been very active in ARIN in the ARIN public policy process. I actually voluntarily brought my legacy space into compliance with the ARIN Registration Services Agreement, signed the RSA, and pay ARIN fees on an annual basis, and keep my records up-to-date for my legacy space. However, having said that, that was a voluntary action on my part. And I firmly believe that ARIN does not have any eminent domain rights or power to force legacy
holders into any such process, that legacy holders have a good and valid assertion that their space was issued to them under terms and conditions of belief that it was in perpetuity, and it's up to them to voluntarily return it if they so choose. Whether we think that was the right rule or not, it was the rule at the time when the address space was issued, and there was no provision made for that rule being later changed on them. And I don't think that they have any contractual relationship with ARIN to support such an action. So I think we need to look for ways to encourage them to voluntarily come and join in the ARIN process, and bring their addresses to the table for that purpose, whether they're using them or not, whether they want to help us out by returning some or all of them or not. I think it behooves us to try and find ways to work with them and kind of bring
them into the process. And that's going to require us to have something we can offer them in trade for what we're asking them to give up. And so far, we don't have much. But Bob and I are working on a proposal that might help solve some of that. And so look for that hitting PPML fairly soon.

MR. CURRAN: Leslie, do you want to say anything additional?

MS. NOBILE: No.

MR. CURRAN: No.

MS. NOBILE: Sorry.

MR. CURRAN: I see we're joined by our esteemed Counsel.

MR. RYAN: I'm going to defer to the CEO, as has my prior --

MR. CURRAN: Okay.

MR. RYAN: I'll take the last slot, if I may.

MR. CURRAN: Okay, Ray.

MR. PLZAK: He probably wants to respond to what I said earlier.
(Laughter)

MR. PLZAK: Anyway, Leslie is here to provide support. We had formed a small mailing list to help the panel members to discuss some of the issues beforehand to maybe better understand each other. And so Leslie was there to provide some statistical support, and I was there as the Devil's advocate to kind of stir the pot up. And so that's what my role has been into this so far. It was just to get the discussion going. And that's the idea of this panel. And I also invited the General Counsel to participate in this panel as well. So I'll turn it over to Steve.

MR. RYAN: Well, from a legal perspective, this is why I love you guys. I have never seen the United States government give away anything without any strings attached before. And so there's a real question in my mind whether -- with regard to
some of the legacy address holders who received early addresses who were in the Defense or academic community but held Defense contracts, whether the issuance of space at that time was pursuant to traditional government theories of government-furnished material or government-furnished equipment. The paper record is really pretty strange when one looks at it. And it does appear -- to the extent that I've had an opportunity to look at some of the paperwork -- that it's one of the few times in the history of governments that they gave away something seemingly without a clear set of strings attached to it. I believe that those who are government contractors and who received it as government contractors actually have the weakest case to argue that they have some enhanced right over other members of the community in this regard. And I'm still
evaluating the legal theories that address that. But looking more generally, there are clearly legacy address holders who are not government contractors who did get early resources, and who are clearly not covered by GFM, GFE -- any kind of theories with regard to that. And with regard to those people, from my legal standpoint as a person who has adopted the notion of RFC 2008 and all of the sort of learning of the community, I think what we need to do is fashion a -- I do think we need to fashion a policy proposal or a series of proposals that creates a series of carrots, but not particularly sticks, that would be intended to entice legacy holders to bring their resources into the system, to give up those resources that they don't need, and to actually come out of that process benefited as opposed to being treated in a detrimental or in a pejorative or even a
negative way in any regard. And I think the sooner we adopt such a set of policies that are well-thought-out by this community, the better off we'll be legally as we address this situation. Because there's a window coming that intersects with the IPv4 exhaustion issue, where for a brief time, these resources will actually become financially more valuable if they were unencumbered, and where that value will only be for a limited period. So in that sense as a lawyer, I look forward to working with you to try and describe mechanisms that are affirmative, positive, and that entice people to feel that it is a civic duty, but maybe even a beneficial civic duty, to perform in that way.

MR. CURRAN: Can I ask one question, Steve? And this is asking as Counsel to ARIN. You said potentially, for
those folks who have received legacy addresses who didn't necessarily get them through government contracts or GFE, that it might be useful to try to take an approach or a policy or a set of policies or actions that entice them to participate in the community -- the use of carrots, not sticks. My question is, is the shying away from sticks because it's not felt ARIN has any useful ones, or is it because of the liability that's entailed by doing that?

MR. RYAN: I've thought a little bit about what a stick might look like here. So for example, it's very clear to me that denial of service by ARIN is legally permitted. In other words, I don't believe we, as the non-profit trying to carry out the community's wishes, have a duty to provide free services for legacy address holders. And the denial of those free services to legacy address holders pursuant to their lack of agreement is perfectly permitted, in my
judgment, as a matter of law. I've thought about it that far. I haven't thought carefully about what would be the stick beyond denial of those free services. And in my view, the two are quite different. The stick might be that we -- for example, I've thought about whether I could ask the United States Congress for authority to have the government obtain back that which the government gave. I don't know if that's constitutional, actually. I mean, I've started to play with different theories here.

MR. CURRAN: Okay.

MR. RYAN: And I guess as you come up with proposals, I'll tell you whether we can do them or not.

MR. CURRAN: Okay. That's what I was -- I wanted to know where we had -- what bounds we had explored in terms of our legal known areas, and the ones to be explored with respect to our services that are provided
sort of free and incidentally to that community. We sort of have a good understanding that we're within rights if we wish to turn them off. But we haven't yet explored what happens if we were going to take other measures. That's what you're saying. Owen?

MR. DeLONG: If I could comment on that aspect of the stick. Realistically, turning off those services would, as I understand it, entail essentially removing the records from WHOIS, and no longer providing IN-ADDRs for them. And that's about it; correct? So I think that would be sort of cutting off our nose to spite our face from the community perspective, because those actions would be largely irrelevant to most of the legacy holders, the IN-ADDRs might be a little bit uncomfortable. But if they didn't have someplace
else they could go to get their IN-ADDR references put into the root zone, it's unclear whether they would have legal standing to do something about that as a denial of service attack. It's also unclear what would happen from a legal perspective, and I'm not a lawyer. So see if you can maybe expand on this a little bit more than I should. But I think that certainly there are theories that would allow people to make big nasty lawsuits against ARIN if ARIN started issuing those numbers to others in that process.

MR. CURRAN: If you imagine, if you reclaim, it's sort of with the intent to issue, particularly if we're running into an area of tight IPv4 resources. Let me redirect the -- since we sort of explored the edge of the sticks, I want to move and start talking a little bit about carrots. And I know, Bob, you suggested some items. I think when you were speaking, you said the words
"tax break." I'm not sure.

MR. ANTIA: Yes.

MR. CURRAN: So I guess I would like to hear little more about the carrots that you think could be explored.

MR. ANTIA: Ultimately, the consolidation is going to cost money for the end-users; those that are still using them. And either you can offer money for the addresses --

MR. CURRAN: Uh-huh.

MR. ANTIA: Which we don't want to go anywhere near, or you can offer some sort of reward for turning in the addresses. In talking with people, it was suggested why not sponsor a bill to get a tax break for bringing in every /24. Since you can't get any tax break for bringing them in because they have no value, why not create an artificial value for them so that there's a sort of carrot -- a monetized carrot to return those addresses in.

MR. CURRAN: Interesting. An interesting approach.

MR. RYAN: Let me comment on that. The one thing I am is a politician. I worked in the Congress as chief counsel of a committee for five years, and there's no way on God's Earth that we would be given a tax break for companies that were benefited for being early adopters than being paid to give back that which they didn't pay for to get. I like the notion, though, that if there are costs, that it's not unfair to think of whether ARIN or other community bodies could actually foot limited costs not to buy the addresses, but to accommodate the process by which the return occurred, or to defer forever routine charges on any of those spaces that were ever returned. Or even more broadly, to benefit that legacy address holder by giving them a benefit financially with regard to fees they would otherwise pay on non-legacy address
space. Those are what I consider appropriate carrots that are within the control of the people in this room, which is the universe of people who I think is best-suited to come up with a policy to address this issue.

MR. CURRAN: Very good. Any of the panelists want to talk on the issue of possible carrots? Yes.

MR. DeLONG: One of the carrots that I'm working with Bob on possibly developing is providing essentially reduced ARIN or even waived ARIN fees for a certain period of time, not only on their existing space, which obviously, for the most part, currently have without fees in perpetuity, but also possibly allowing them to get v6 space on a fee-free basis for some number of years to facilitate their migration to v6, on the assumption that that's sort of going to be important over the next several years.

MR. CURRAN: Interesting. Microphones are open, and we'll start in the
back rear. Yes.

MR. SEASTROM: Robert Seastrom, ARIN AC. Once upon a time, there was some discussion -- the concept of a registry of last resort, where the data in the registry would be utterly frozen, and that there would therefore be no database maintenance requirements compared to what's happening right now. And that sort of never got any traction. I'm wondering if anybody has been kicking that around as an idea for sort of getting it off of ARIN's plate.

MR. CURRAN: Okay. The question is the registry of last resort. I'll paraphrase and say there has been a discussion of a registry of last resort. It's come up in the hallways, it's come up in -- there's actually been little papers written here and there, with the goal of better understanding and being able to allocate or itemize the expenses involved in tracking legacy address records. I don't know how the panelists feel
a registry of last resort would fare. Would it help solve this problem? Anyone want to speak to this issue? No? Yes.

MR. ANTIA: I'm not sure it would either help or hinder it. I think that if these legacy holders have been ignoring ARIN, they would ignore everybody else.

MR. CURRAN: Right. There was a -- and I guess I'll keep going. The proposals I've seen for registry of last resort were ones that would sort of recognize that those address space holders -- those legacy holders weren't participating in any of the RIRs, and so could get a very simple set of registry services -- presently effectively what they're getting from ARIN -- but it would not be something that was necessarily borne by ARIN. It would be the -- or claimed from some other organization or fund, or set of funding. But it would effectively recognize and codify them as being separate from the
system. Actually, someone who's a expert on such proposals happens to be here and is occupying that microphone. Why don't you speak, Bill?

MR. WOODCOCK: I cleverly cut in front of the people at the other mic. So really basically, the idea was if the legacy holders are separated off into a separate registry which is static but operates in the spirit of the way the Internet was operated at the time the legacy holders got their address space, which was sort of each according to their abilities and each according to their needs, that this would remove the cost of supporting legacy holders from the RIRs, so the RIRs would no longer have a cause for complaint. And at the same time, it would provide an incentive for any legacy holders who wanted to receive any services to actually enter into an RSA with the RIR of their choice. So anybody who really didn't
want to do anything could continue to not do anything, and not pay the minimal cost associated with operating this, because again, no dynamic services would be provided. It could be handled by volunteers in the same way that, for instance, the root name servers are. And if anybody does want services, they just pick the RIR that serves them or their region, and pay a membership fee and join up and sign the RSA.

MR. CURRAN: Thank you for the clarification. So I guess one of the implied questions when we had a discussion of legacy panel, a lot of people noted that the legacy address space situation was both a record upkeep situation as well as a participation, and I guess cooperation with issues such as reclamation. Clearly a registry of last resort sort of only addresses half that problem. Comments from any of the panelists?

MR. ANTIA: Wouldn't it be in the best interest of the Internet to bring these
people into the existing organizations as opposed to shuttling them off on their own? The idea of reclaiming those addresses and making them participants I think would have more value.

MR. CURRAN: I think probably there's another -- I'm going to -- we're still answering your question, R.S., in a very long way.

MR. SEASTROM: I actually do have a second question.

MR. CURRAN: Right -- in a very long way. I know we have another person -- expert in registry of last resort at the far mic, Mr. Manning, and I -- and to answer the question and then refer to Bill for more answers -- the thought is that those people may not want to join the registries. And sort of the registry of last resort discussions were on the basis of the fact that potentially, there are no amounts of carrots available to bring them onboard.
Bill, do you want to say more about registry of last resort?

MR. MANNING: Yeah, I guess. From a registry of last resort perspective, a lot of the legacy holders can tie their allocations or their delegations or their prefixes that they claim to be holding to a registry which no longer exists, be it NSI or SRI or some other pre-existing condition, or the IANA. But all of them can tie it back to the IANA. So one possible way forward is to approach the legacy holders as an agent of the IANA -- since the IANA's busy -- and say look, we want to keep things up, we want -- to some degree, I'll almost be willing to say, "We'll bend over backwards and keep your records up-to-date, do these other kinds of things, but oh, by the way, we're ARIN and this is the current stuff." So as the registry of last resort, we'll be happy to maintain your records and
keep them accurate, because one of the problems is inaccurate data. So a static registry of last resort I think is silly. Bringing people in and showing that ARIN reaches out and is willing to help them come on to the modern world, I think that that's a cost that I think I would be willing to spend to invite them in and show people that we're friendly, and reaching out to them, as opposed to here is a barrier to entry, because there is that perception that there's a barrier to entry, and that they would rather keep up with things the way they've always been. I'm uncomfortable with the idea of a registry of last resort. I would like to see the registry stay consistent.

MR. CURRAN: Other comments from the panelists on the registry of last resort issue? Yes, yes? No, no? No, no?

MR. ANTIA: I think it's a good idea to keep them within ARIN.

MR. CURRAN: Okay.

MR. ANTIA: Or within the RIRs.

MR. CURRAN: Steve, did you want to comment?

MR. RYAN: There's a political reality to this issue, which is it's a rock in our pocket that we carry around uniquely in ARIN because the majority of the legacy address holders were in North America, I think. I don't know if that's a fair statement. But when we go into the world community, people tend to see this as a uniquely -- not ARIN problem, but American U.S., not American -- North and South America, but U.S. problem that was an unfair benefit to us. And given that, I think the notion that if we could create an indigenous mechanism to resolve this problem, recover unused IPv4 legacy address space even symbolically from this community,
particularly those who are leaders of the community in a sense that are in this room, I think that there's a moral imperative to this issue, that -- it sounds badly from a lawyer. Doesn't it? The moral imperative. But there's a --

MR. CURRAN: But we'll still listen.

MR. RYAN: There's a moral imperative here, I think, of those who got this benefit -- if they're going to treat it in the spirit that it was given to them, they would give it back, quite candidly, and you know, I want to salute Owen for that. I mean -- you know, that's pretty cool. And I think that is consistent with the spirit. So I think it would be helpful if we could work on an ARIN program that would be consistent, but that I would be delighted to see the other RIRs benefit from a similar program.

MR. CURRAN: Do you have a second
question, R.S.?

MR. SEASTROM: Yeah. Without addressing what Steve just said right now about the moral imperatives, and I apologize if I wasn't paying sufficient attention during the PowerPoints -- but I saw plenty of numbers with percent signs after them. I didn't see any numbers with dollar signs before them. Is that correct?

MR. CURRAN: No, I didn't see any dollar signs either.

MR. SEASTROM: Has anybody done any research to see what exactly our costs of carrying are for this? Is this something that's like the one percent of fraudulent transactions that Citibank has to just sort of live with because it costs more to fix the problem than it does to just lump it?

MR. CURRAN: So the question would be --

MR. SEASTROM: Is this something that it makes financial sense to try to fix?

MR. CURRAN: So again, looking at the legacy space issue from two perspectives; one is the cost of providing services, incidental though they may be, or small as they might be, the cost is absorbed by the ARIN organization. You want to know how big that cost might be.

MR. SEASTROM: Right --

MR. CURRAN: Okay.

MR. SEASTROM: ARIN does stuff, in a broad sense, in the public interest.

MR. CURRAN: Okay. I don't know at the board level. I don't think we've gotten ever an official estimate. Ray, do you want to try to --

MR. PLZAK: (Off mic).

MR. CURRAN: Do you want to try to ballpark support of the legacy address space, both in terms of --

MR. SEASTROM: I'm sorry for lobbying that in their list.

MR. PLZAK: Leslie will address
this not from the standpoint of dollars and cents, but in terms of time and resources. As far as efforts around it, not necessarily -- I think what you're asking about as far as like maintaining DNS records, which is a whole myriad of other things that her people on her staff are involved in.

MR. SEASTROM: As far as I'm concerned, money and time and effort are really fungible --

MR. PLZAK: Right.

MR. SEASTROM: Because you're paying for people's time, and you have to keep additional --

MR. PLZAK: Right, I understand this issue. I was going to tell you, you're not getting dollars. All right, go ahead Leslie.

MS. NOBILE: So I'll just reiterate what we had said -- 54 percent of our legacy registration records have been updated. So we're constantly updating legacy records.
Right? So that's just part of that. But a big part of our effort with legacy space has been directed at the hijackings that we were experiencing for quite some time. We put major effort, major hours into trying to stop people from hijacking the legacy resources, because that's where most of the hijackings came from. People were looking for unrouted space and records in the database that had not been updated for years, the spammers who were hijacking, they would put those two together, and then they would come in and start trying to take over the records, change the name service, change all the information, et cetera, et cetera. And we've spent just innumerable hours on stopping that effort. And today, as a result of those three -- basically, I guess about two years of sort of fighting that and putting new stop-gaps and measures into
preventing that, we now have procedures that we've had to completely modify, and we have to put a lot of extra effort now into verifying who's coming into ARIN for resources, that they are who they say they are. It just -- it takes a number of hours to just -- just in that effort.

MR. CURRAN: So to come back to R.S., I guess one of the items that could come out of this is, it might be useful to understand what percentage of ARIN's budget would be saved, for example, if we weren't providing services to legacy space holders.

MR. SEASTROM: Yeah. That's a fair statement, yeah.

MR. CURRAN: Okay. Thank you.

MR. RYAN: Well, let me address that. I think there's SG&A costs that are difficult to calculate. I think you all know what I mean. In other words, we operate 40-something people a building. We have an accountant, we have a lawyer, we have a
priest -- no, we don't have a priest. And so there's an SG&A overhead kind of component of this. But even if we drill down and the number was negligible what the support cost is, we still have a choice with regard to that. It may be a very prudent choice, and inconsistent with our interest to shut off those minimal services we provide. But again, all of this is, in my thinking, highly symbolic. And I return to what the DoD did, agreeing to return IPv4 space that is no longer needed by the government based on their own decision. I think actually the DoD has done better than some of the people in this room. Think about it. You know, this is not an organization that's warm and fuzzy, and then as a policy matter, thought that that was the right policy for the Internet.

MR. LEWIS: Ed Lewis, NeuStar. One thing that I found missing after the panel started going was that I don't think we have ever really come -- ever expressed a good set of goals for bringing the people into the fold. I think it's come out now -- at the expense of the staff to support these, I guess unpaid-for database additions and so on. Also, I think the hijacking case where it's unclear who actually has the space -- I was going to say Owen's, but that's not Owen's. But who has the space? And I think that -- you know, I'm still trying to get an idea of why -- why do we want to bring these people into the ARIN fold? I don't think that's really been expressed. And I guess -- the next thing I had was that -- the discussion about the registry of last resort. I don't think that these legacy holders benefit by having their stuff trapped in ARIN. We who are members of ARIN benefit
because we look up to see who's responsible for data from that space. So we're the relying parties. We want to see that in the database. We don't -- they may not care. So it's not a matter -- I don't think we should look at it as if they were a burden to us. But we want to know what they have. So I don't want to discourage that. I want to be right.

MR. CURRAN: Right. That accuracy and ability to look up is one of the reasons that we had, for example, people talking about registry of last resort. With respect to, why bringing legacy holders "into the fold" might be valuable, I've heard people say, so they can be aware of policies, so they can participate in policy development, so that we can track them, hunt them down, and reclaim them. So I guess I'll turn it over to the panel to get statements. Why bring legacy holders into the fold?
As an organization, why is that of interest to ARIN?

MR. DeLONG: Well, there's a number of reasons. Number one, right now, we've got at least two and probably more different sets of address policy out there floating around within the ARIN region. One is you have it and it's yours under unclear terms of -- you know, John Postel wrote you down in a notebook once upon a time and it's yours thereafter. And then at the other end of the spectrum, there's the current registration services agreement, which says essentially that at any time, ARIN can ask you to justify your continued use of the space, and if you can't do so, may have the right to reclaim it. So I think there's a lot of benefit to bringing some level of consistency to address policy in the region across the board. On another level, I think it's worthwhile to try and incorporate as many
people into the process, because I think it makes the organization stronger and it brings us to better, more beneficial policy in general to not have disenfranchised -- what was it, 46 percent of the /24 equivalents that are out there. That's a large body to disenfranchise.

MR. CURRAN: Any other panelist want to speak as to why it's important to try to bring these folks into the fold?

MR. RYAN: I mean, there's a community need. Let's think of the exhaustion issue at a current run rate and think about a 10 percent recovery or a 20 percent recovery or a 30 percent recovery of unused legacy space, and whether that provides a cushion for IPv6 implementation for developing economies. I think that there's a moral imperative there to go back and use these resources properly, because -- am I wrong, or are the IPv4 resources going to become
valueless after IPv6 is adopted? In other words, if we look out -- and I honestly don't know the answer to this -- if we look out 10 years to when IPv6 is the system, will IPv4 numbers still have great value?

MR. CURRAN: I actually offered to hold all the extras once we've moved.

MR. RYAN: Yeah.

MR. CURRAN: Because I thought someone should do it, and I'm already up here onstage. I guess would any of the panelists like to discuss the value of IPv4 addresses in -- I don't know whether to say 10 years from now or in a post-IPv6 transitioned world.

MR. DeLONG: I think 10 years is certainly an optimistic time frame for that.

MR. CURRAN: Let's say in an IPv6 transitioned world, do IPv4 addresses still have value?

MR. DeLONG: I argue they don't
have monetary value today and should never monetary value. But they're just integers. You know, on a reality check level, anybody who wants to can start an Internet registry anytime they want, and hand integers out to whoever they want. They are just integers, and trying to claim you copyrighted an integer is sort of an interesting concept. On a more practical level, because currently the people who run routers and the RIR system cooperate with each other, and at some level, the people who run routers refuse to route addresses to people that the RIRs did not give them to, and don't listen to other potential IP registries, the network continues to function.

MR. CURRAN: Microphone -- go ahead.

MR. ANTIA: I think they will have a diminishing value across time. There will be specific instances where it'll be required. An analogy I made was DC Power in
New York; it's still there. I mean, Legacy Elevators still use it. You just can't get a new one.

MR. CURRAN: Right, okay. I have tech-net numbers available if anyone would like one. Front microphone over there?

MR. WOODCOCK: That was essentially going to be my point, right, that v4 and v6 are different protocols. And we've had different protocols in the past. I remember when IP addresses were considered worthless, because only a few academics could use them to talk to each other. And who wanted to talk to academics anyway? Real businesspeople used Apple Talk and NetWare. And Apple Talk and NetWare addresses are at this point something that if you had a need for them, you would make some up and use them, but nobody bothers; right? But that's been a 20-year process.

MR. CURRAN: Center back? Yes.

MR. BICKNELL: Leo Bicknell. I
have a question and then a comment. The question probably more for Steve is -- I'm a bit confused where the presumption of free and in perpetuity comes from, because the current RSA clearly states that it's modifiable over time. And when these transactions occurred, if I'm not mistaken, basically someone sent in an e-mail and they got back an e-mail that contained the number, not the number and 50 paragraphs of legalese saying forever, no matter who does it and all this other stuff. So it seems to me that was never communicated in the original assignments, and most contracts are modifiable. So why would someone assume those weren't?

MR. RYAN: Here's the question. What was the contract? In other words, I think -- again, I have an incomplete picture at this point. And I may very well agree someday with your viewpoint. However, at the
current time if you look at it, a contract traditionally is based on the agreement to provide something of value and the return of consideration. It's hard to see here the normal elements of contractual requirement in the documents that I'm looking at, in all of them. In other words, you maybe right and it may be a constructive contract that a court would construe what the terms are and argue -- or lawyers would construe what the terms and a court would decide yes, indeed, that was the terms under which this was granted. But it's not as clear. Our RSA is very clear on what requirements the member of the community does and what requirements we do. And I have 100 percent certainty that our contract would be upheld if attacked frontally in court, which it never has been.

MR. CURRAN: All right, well --

MR. BICKNELL: The comment that I
had, too, is I agree completely with Steve in that I think exhaustion is the driver here. And my concern isn't so much for the people who are on the stage, or in fact even the people who are continuing to use their legacy assignment. My worry is in the numbers. We seem to be protecting an awful lot of ghosts. Fifty percent of this space doesn't have an updated record, isn't routed on the Internet at all. We're protecting people who have ceased to exist. They have died, they've forgotten they ever had one -- yes, how much of it's DoD, I don't know. You know, it seems like that problem is solved. But if we run into an exhaustion situation and there's 13,000-odd prefixes out there that don't even have a person or a company or an anything behind them, we have to find some mechanism to reclaim those. Even if it's as simple as send out an e-mail; if you respond, you get to keep it in
perpetuity, and if you don't, we're pulling the record. That would get rid of everybody who doesn't exist anymore.

MR. CURRAN: So let's talk about the issue of the need to reclaim these. I guess there's a statement from Leo that says the exhaustion of IPv4 sort of mandates that we pay attention to this, and that we embark on some method of getting valid contacts and implied -- if you're not using it, getting re-use for those address blocks. Is there any reason why that's not straightforward? Yes, Mr. Bradner.

MR. BRADNER: I'd like to speak to that for a second, even though I'm cutting in line here. One of the assignments that I was given, Al Samanka (?) and I were given by the chair of IETF when we took over the IP Next Generation effort which produced IPv6, good or bad, was to ascertain whether aggressive reclamation was worth it. And after a lot of deliberation, we
decided it wasn't, because if we were in the end game where another 10 percent of addresses made a difference, we would have been too late and it really didn't make any difference at all. And that was our formal report back to the IETF.

MR. CURRAN: Can I ask the year of that report?

MR. BRADNER: A decade and a half ago, something like that.

MR. CURRAN: And at the time you did that, the forecast for IPv4 address depletion?

MR. BRADNER: 2008, plus or minus 3.

MR. CURRAN: 2008, plus or minus 3. So here we are.

MR. BRADNER: It doesn't change the math.

MR. CURRAN: Would you update the report with the same conclusion or --

MR. BRADNER: Yes, if we're talking
about the -- let's say we're talking about the non-routed stuff that we just heard about.

MR. CURRAN: Okay.

MR. BRADNER: That gives us, what, another 20 percent? What difference does that make if we're in a crisis situation where -- if we're in a situation where v4 is running out, people begin to see that it's valuable somehow and want to start selling it and convincing ISPs to route it as a commercial entity, I don't think it's going to make any difference at all.

MR. PLZAK: John?

MR. CURRAN: Yes.

MR. PLZAK: One quick question for Scott. When you were making that decision regarding v4 reclamation and so forth, what was the assumed environment, operational environment of IPv6?

MR. BRADNER: No assumptions made.

MR. PLZAK: So IPv6 did not exist
in that you were going to --

MR. BRADNER: No, it was irrelevant.

MR. PLZAK: Okay.

MR. BRADNER: It was irrelevant to -- we were looking at what the end game was going to be. And if the end -- and what the amount of reclamation one could do would have on that end game. And we didn't see that there was any significant impact it would have on the end game. And I still don't think there's one.

MR. PLZAK: So no consideration with regards to continued growth and development of the Internet or anything else like that, just --

MR. BRADNER: It was purely whether it made any difference to go out and try and convince Jeff Schiller (?) that he wanted to give up part of his NETI team.

MR. CURRAN: Right. Okay.

MR. BRADNER: I don't want to be
part of that committee.

MR. CURRAN: Any other panelists like to comment on the benefit, if any, of 10 percent more v4 space?

MR. DeLONG: Actually, I think that the real low-hanging fruit here is to try and identify the legacy holders that are defunct and reclaim that space, not so much for the purposes of extending the useful life of IPv4, because I do agree with Scott and his conclusions. I think that they put a lot of effort into that research, and I think that the map does hold up pretty well. But because I think that it would reduce -- you know, we could add those prefixes to the Bogon (?) lists and it would certainly reduce the number of prefixes that are easily harvested for abuse purposes. And so I think that's a worthwhile effort just on that score.

MR. RYAN: John, let me label the theory so we have a phrase to label that.
It's the escheat theory. Escheat is what happens when somebody die and you can't find who owns the asset and it escheats to the state. So for example, if there's stock that is unclaimed and you can't find the holder of it, it doesn't -- Yahoo doesn't get to keep their own stock. That Yahoo stock goes to the State of New Jersey or wherever the last residence was of the account holder of the stock. So I think what we could call this is the escheat theory -- if we can't find the owner of it, it escheats back to the community for the purposes of the registry. That would be the theory.

MR. CURRAN: Okay.

MR. ANTIA: Didn't IANA at one point try a reclamation project that was somewhat successful?

MR. CURRAN: Mr. Manning, I see you at the mic.

MR. MANNING: Yes. Suzanne
Woolf -- Suzanne, raise your hand -- she did most of the work on the second pass. The first pass, I did some of it. We reclaimed 38 percent of the entire v4 pool from dead people, from organizations that were bankrupt and had dissolved -- all kinds of stuff, right? We can do that again. More interestingly, people are starting to touch on what happens when the v4 space that's out there that has residual or no value, what's the garbage collection technique? And I believe that the proper end game is that some organization -- and I'm going to pick on the IANA because I can -- should in fact be the repository of all of the unused space. It shouldn't go to John Curran; it should go back to IANA, where the IANA can find and collect all of the garbage bits up and say, okay, I've got all of them back, drop them in the trash, eventually. We're not going to be done with the
v4 problem until we get rid of it. So we're going to have to track it until it's not used.

MR. CURRAN: Center back microphone. Name and affiliation?

MR. LEWIS: Ed Lewis, NeuStar. I think the first speaker, Bob, next to John, you made a comment that was interesting early on -- to a lot of the legacy holders, the RIRs are irrelevant or they're invisible, that they don't see the RIRs coming to them. And I was thinking that eventually, they're going to probably need to have resources out of the RIRs for v6. And so one that carries us all there right away was using the fact that you have legacy space in v4 can help get v6 space justified. The whole idea of -- that they see the RIRs are invisible, I think that's something that was kind of interesting when I heard you talk about that. Just when you think that -- they
eventually would need the RIRs to get into the new Internet, the v6 Internet. That's just one part that came out, but I think that was an important thing.

MR. CURRAN: Picking up on Bob's point that there may actually be people who aren't dead?

MR. LEWIS: Right.

MR. CURRAN: Their organizations are there somewhere, and they received a very early assignment, but they're not connected and they're not exactly active.

MR. LEWIS: They could be connected to the Internet. They could be on an ISP and operationally be there, but the RIRs -- I mean, it sounds to me like the RIRs weren't even known to them. It's not like they're avoiding the RIRs, but the RIRs never tried to include them into the fold.

MR. CURRAN: There's a little difference between them not knowing who the RIRs are and not knowing who the Internet is.

MR. LEWIS: Well, that's not the distinction I'm trying to make. It's not knowing who the RIRs are versus the RIRs never having contacted them to try to get them to join.

MR. CURRAN: Okay.

MR. LEWIS: I guess -- actually with Bob's comment here, I'm not -- I don't know what the intention was there -- is he saying that ARIN and so on haven't yet sold them on becoming members, or are they just completely oblivious to ARIN?

MR. CURRAN: There may have been less than sufficient turnover or some -- they don't know where the addresses came from, they've got them. It was --

MR. LEWIS: And that was part of the -- my comment before about why would we want to do this. What are our goals here, do we really want to go out and make an effort to bring them in?

MR. CURRAN: So along those lines,
Bob, for the people who just seemingly have addresses, don't exactly know why or how they have them, but because they're not participating in ARIN and because we don't necessarily have good contact information, for example, is there an outreach campaign that's needed?

MR. ANTIA: I think there is an outreach campaign that's needed of -- and I'll give you the example of the perception of ARIN outside this community. In meeting -- my meetings, my consulting I did the weeks before this meeting, I mentioned I was coming to this meeting, 80 percent of the people who were in the technology side of the business had no idea who ARIN was. The other 20 percent who knew who ARIN was, said, "Man, they're a pain in the ass to deal with." So that's the perception of corporate America.

MR. CURRAN: That's great. Good to know. I'm glad we're --

MR. ANTIA: So some outreach and some changing of that perception I think would be helpful for ARIN.

MR. CURRAN: And in terms of how to do what outreach, is this through the membership, TV spots, billboards?

MR. ANTIA: It's through the membership. And most companies I've consulted into that have large address spaces are in the Dark Ages as to managing it. I'd suggest sponsoring an address tool so they could understand their utilization, an open source -- you know, get them in the community that way of realizing how inefficient they're doing things. They just don't know what they don't know.

MR. CURRAN: Got it. Okay. Back row microphone?

MR. HANNIGAN: Martin Hannigan. And I'm hoping for sunshine today. So I've had some discussions with some folks that are listed on the IANA legacy /8 holders page.
And me and them seem to disagree that IP addresses aren't or will not be worth money, IPv4 addresses, at some point. And I'd like to suggest a question for the panel, if I may. Is legacy space as property technically, economically, and legally feasible?

MR. CURRAN: I'm going to actually carve two-thirds of your question out and throw it on the floor, okay? The panel conveniently got together via e-mail for a little while before we decided we'd all be up here, and came to the conclusion that there's a topic that's probably a great discussion to have, but it's not on the agenda for this meeting, which is monetization of IP addresses. Because it certainly does change the nature of the discussion dramatically when you decide that we're not talking about the management of an Internet resource on behalf of the community, but dealing with moving property around. So I'm going to
actually ask Steve if he'd like to comment at all about addresses as property. But otherwise, I think we'll probably take the rest of the question off. Go ahead, Steve.

MR. RYAN: Thank you, John.

MR. CURRAN: Sure.

MR. RYAN: With regard to IP number resources as property, we have adopted a theological position that -- that while a domain name has a secondary value and meaning, and the protection of a trademark, for example, and it's been accepted probably appropriately as an appropriate extension of that law, I think that what the RI -- I want to compliment the RIR community. You've come up with a way to keep the costs of interconnection lower because we have not monetized in the past IP addresses. We provide IP addresses at a pittance of the sale price of the service of interconnection and transport of packets.
And I think that has been a huge benefit to the society. If we dispense with that benefit for monetization, there ought to be a damn good reason for it. More it's forced on us by the failure that we experience to address the transition of protocols.

MR. CURRAN: Thank you. Rear back microphone.

MR. DURANT: I am Alain Durant, Comcast. I'm going to stay on the same topic, but moving the monetization aside and simply talking about property, has there been a case where a legacy order has "transferred" "property" of some address base to another company or another organization, and that new organization had come to ARIN to "register" that space within ARIN? And if it does not happen yet, if this was to happen tomorrow morning, what would be the reaction from ARIN to such a request?

MR. CURRAN: I know this one by heart, but actually, I see Leslie and Ray
down that end. So Leslie or Ray, go ahead.

MS. NOBILE: I didn't hear the last part of that.

MR. CURRAN: If a entity comes to ARIN and says, "I need to change the records for this property that I've bought, it's currently pointing to the old organization, and it's now my property, and it should point to me preferably."

MS. NOBILE: Yeah, this does happen quite frequently, in fact, and they have to follow the transfer policy guidelines. That's what we tell them. So of course if they can provide the documentation that the company A bought company B or whatever, they have a legal documentation and we can verify that, then we do the transfer. If they come to us and say, "I bought this property, I bought these addresses, here's the agreement," we say no, because the policy clearly says IP addresses are not property. That's written right into
the policy. And that's what we tell them. We won't do any kind of a transfer, because you don't have the correct paperwork. So does that kind of answer your question?

MR. DURANT: So the loophole is actually to buy the company if you want to buy the other space. (Laughter)

MS. NOBILE: In fact -- yes.

MR. CURRAN: It is -- if you purchase a company, then you'll be able to as effecting transfer -- you'll be able to as part of -- as doing that, you'll be able to effect the transfer. The only reason you're getting to transfer the addresses is because you've got the reason why the addresses were signed when you purchased the company.

MR. DeLONG: John, if I may?

MR. CURRAN: Yeah.

MR. DeLONG: One thing to point out on that process, though, is that when they do
that transfer, they're required to sign a current RSA, and they move out of the legacy category if the addresses were previously in that category, and into the ARIN category. They are paying fees, and they are subject to all the requirements and changes to the RSA going forward at that point.

MS. NOBILE: Actually, they don't necessarily pay yearly fees, they pay a $200 -- is it $250 -- maintenance fee? Is that what it is?

SPEAKER: $500.

MS. NOBILE: $500?

MR. CURRAN: Transfer fee.

MS. NOBILE: $250 for the transfer fee, and then they pay a yearly maintenance fee. They don't necessarily pay ISP subscription member fees. If it's legacy space, right -- and it's an old company they have legacy space, a new company has bought them, the new company is not affiliated, they've never been in with ARIN before that,
they don't have any space from ARIN. We move this space -- and we don't even actually ask what the new company is doing with it, we just want to make sure it's utilized. We move the legacy space as is, and we still refer to it as legacy space. They do sign an RSA. They do pay a maintenance fee, but we do not charge fees on that space, we don't charge subscriber fees, because it was -- it's kind of complicated.

MR. DeLONG: They get treated as end users but --

MS. NOBILE: They get treated as the end users, thank you. I didn't bring that out --

MR. DeLONG: But they --

MR. PLZAK: One another comment. One of the reasons people want to do that and to keep those records current is that at some point in time, if somebody is interested in conducting a peering agreement with someone else, you'd want to say, "Who are you?" Remember one of the roles of the IR is to provide that registration which establishes the uniqueness of who the operator of the network space really is. So that becomes even more problematic going forward looking in terms of things like routing security.

MR. BICKNELL: Leo Bicknell, Harrah's Entertainment. Actually, I want to make a comment on Scott's earlier comment, because I think he did an excellent job with the math but may have missed the business case. I believe 10 percent of the address space, just off the top of my head, is more than enough to run a enterprise the size of UU Net, Verizon business, or AT&T or Level3, or perhaps all three of them together. And I've a feeling if v6 is not viable in time, and the business community
has an opportunity to run several billion dollars' worth of enterprise or not, they will find that last 10 percent amazingly valuable.

MR. CURRAN: Scott, would you like to respond to your response to your comment?

MR. BRADNER: Scott Bradner trying to figure out what he just said. What you just said, not him. If a 10 percent were in one place -- yeah, maybe -- 10 percent isn't in one place. It's scattered all over the place, and the effort going back to all of those places and even just doing the bookkeeping to find all those places in figuring out how to get it back. And looking at some personal experience, so Harvard's got 6Bs (?). When we got them, they all went to different parts of Harvard, legally separate parts of Harvard, but ARIN sees it as one. So we're not using anywhere near all of that. But when we go back to ARIN and say hey, can we
have some more address space? They go no, you got all this crap, and you're not using it. We can't -- it's not cost-effective in anybody's mind to do the reclamation on that sort of thing. Even though a lot of that space is really wasted. And we're not alone in that. It's all over the place. Somebody mentioned earlier that people who have legacy address space -- I think it was you -- a lot of it is very inefficiently managed. And that's where pulling those things out is just not cost-effective to do. We felt that it wasn't going to be cost-effective, but mostly it wasn't going to be psychologically effective, that we were going to be -- if it's got 10 percent, within 10 percent at the end, we're in an end game where rationality is not part of the process. We're in a scarce situation, and rationalization doesn't work there.

MR. BICKNELL: Right. And I actually completely agree on that. People will not be rational. They'll pay whatever it takes to get the address space. And so someone will knock on your door and say, we will pay for everyone to do all the auditing for you, and we'll give you an extra $100 million and all we want is 10 addresses back. And you'll go off and do it. And we the community have to keep track of it. So it's still our problem to solve.

MR. CURRAN: Following your train of thought, and I'm not going into monetization, but I guess what you're saying is that potentially, the problem of whether it's worth reclamation will solve itself if monetization happens.

MR. BICKNELL: Right. To use a simple example, today we don't extract oil from Texas, and we don't extract it from shale because it's not cost-effective. If we didn't have any from the Middle East and gas
were $9 a gallon, we'd extract it like crazy. And IP addresses are no different. Today, I can go get them from ARIN for extremely low cost per subscriber. If ARIN is out and I have to go buy them on eBay, and I have to go pay $5 million for a /24, I'm going to go see if anybody has one laying around. And they're going to be greatly incentivized to go see if they have one laying around.

MR. CURRAN: Good point. I guess you also want to find out the routing table entry cost when you do that. Microphone on this end.

MR. RICH: I guess the argument only really works so if the underlying presumption is there isn't an alternative. When you talk about hundreds of millions of dollars more -- I know you were exaggerating. But there's a viable alternative, and it's not -- the cost of transitioning is going to be far less than the cost of reclamation or
obtaining IP before it is on the "black" market. So I don't think it's a realistic situation. I guess my comment, why do we do anything -- why do we even need to -- do we really need to worry about the legacy space?

MR. CURRAN: Because you're saying we don't necessarily -- and your assertion is potentially -- we don't need to worry about it at all, because the effort involved may be more painful than what's involved in transitioning.

MR. RICH: Absolutely.

MR. CURRAN: Comments from the panelists? Everyone on the panel thinks transition is effortless.

MR. DeLONG: I think the transition is not effortless, but I think that only time will tell which one is harder or easier or cost more or cost less, and I think that at some point economic equilibrium will occur. But anything further and we get into the
monetization rattle.

MR. CURRAN: Uh-huh. All right.

MR. PLZAK: I'd like to remind the panel and everyone else that some of these issues are also going to occur again tomorrow afternoon in discussion on IPv4 Consumption. Because that's also a rich fertile area to discuss the transition to IPv6, and it's also inherent to other discussions about why isn't it happening as rapidly as some people think it should.

MR. CURRAN: Center back microphone.

MR. WOODCOCK: Bill Woodcock. Just an addition to something that Leslie said, because it's important and it's already come up two or three times in the conversation, which is that in the two sort of reclamation amnesty policies, the final sentence of each of those policies is, if the address space that's being handed in was legacy, the replacement space would be treated that way
also. Right? So if you are a legacy holder and you want to give back some, or you want to give back some with some caveats or whatever -- I mean, there is plenty of room for negotiation there, and it doesn't mean that you're automatically going to fall into a different category that you don't want to be in. Right? You can be a legacy holder and give back pieces, right? Or be a legacy holder and do updates, or be a good legacy holder and give some back and get a different block or whatever. You just have to negotiate it with registry services, and they have the tools to work with you because of those policies.

MR. CURRAN: I believe that's the policy with the -- I guess the one underlying statement that says there are some aspects of being a legacy holder today like being hidden, anonymous and unknown that go away.
So with respect to address size, I believe you're correct. But you then do end up being a known entity to the ARIN organization. Anyone want to comment on that?

MR. ANTIA: The negotiation doesn't work. About two years ago, I was with a new organization, we had some legacy address, we wanted to swap some stuff around, and we were not successful. ARIN did not -- I do not remember the details of it. Marty, you may remember, but we were not successful in negotiations.

MR. RYAN: We're ready to deal.

MR. CURRAN: Come on back. I see Jordi.

MR. PALET MARTINEZ: Jordi Palet.

MR. CURRAN: Go ahead.

MR. PALET MARTINEZ: I really think IPv6 is coming. Obviously. And I think it don't really matter too much according to what has been said during the reclamation effort in terms of how much life IPv4 would
provide. Maybe it's more a question of what cost this -- that legacy space. But maybe we can work out something, and probably could be a policy in order to somehow encourage people that has legacy space -- and they know that sooner or later, they will meet IPv6 space. It could be something like if you don't agree before -- let's say next two years to return the legacy space that you're not using, or sign there, you will not be entitled to get an IPv6 allocation in the next 20 years. Or something like that. Maybe it's a way to say, okay, this is what the community decides. You could agree or not, but maybe this could help; I don't know. What do you think?

MR. CURRAN: Panelists wish to comment?

MR. ANTIA: I'm not sure that a large number of people would ever hear that message. I think it would fall on deaf ears,
or -- because they're not listening to ARIN right now. Why would they hear that message?

MR. CURRAN: This be a message maybe that when --

SPEAKER: (Off mic).

MR. CURRAN: Tell them in person.

MR. DeLONG: Yes, all these people. At least the bigger ones --

SPEAKER: A door-to-door campaign.

SPEAKER: Outreach. (Laughter)

MR. CURRAN: Okay. Got it. Other comments from the panelists? We got about 20 more minutes. We got plenty of time here. (Laughter)

MR. DeLONG: I think that's a stick, and I think that we'll have more success with carrots.

MR. CURRAN: The threat of a stick. Okay. Yes. Center back.

MR. CONRAD: David Conrad, wearing -- I have two comments, so I'll wear
two hats. The first comment is with my IANA/ICANN hat on, and that is that we're actually discussing with the RIRs right now ways of trying to figure out what to do with -- at least the registration information of some of the legacy address space, and how to partition it out in a way that makes sense without offending three-quarters of the human population. It's often a challenge anytime you do anything with ICANN, you typically offend three-quarters of the human population, as far as I can tell. But we're working on that bit.

SPEAKER: Make it work.

MR. CONRAD: I'm sorry? (Laughter)

MR. CONRAD: We're working really hard to get the 100 percent mark. The other comment I have to make is without any hats on, especially not an ICANN hat, and that is to actually take issue a bit with what John
had said with regards to not wanting to address monetization. This whole topic is about the monetization of address space. Right now, people pay. You pay through dealing with bureaucratic processes that are created by the registries. You pay by creating companies to hold the address space, then to transfer that address space to a new company. What we're looking at in the future is, as v4 space becomes more scarce, that monetization is going to become much more public. There is also a monetization associated with transition. Right now, the primary reason as far as I can tell why people haven't transitioned IPv6 is because they actually want to connect to the Internet, and the Internet is not IPv6. You won't actually get anywhere until a significant portion of the Internet actually is IPv6 addressable, so you have a bit of a chicken and egg problem. So what
eventually you'll run into is the cost for obtaining IPv4 space will either reach a point where it overwhelms the cost of transitioning to IPv6, or you're going to end up with IPv4 forever. So at some point you're going to have to deal with actually looking at the monetization of the IPv4 address space within the registry, the RIR framework, and it'd probably be good to do that sooner rather than later.

MR. CURRAN: So just to respond, all the panelists believe it's a very important topic. We just wanted to get the non-monetization discussion of this going, because we felt that alone could easily occupy an hour-and-a-half. To respond to the second half, David, which I'll do personally; I have an RFC that's 11 years old now, yeah, coming up on 11 years old, which ends with a sentence "IPv4 and that." (?)
So I understand exactly. It is going to be -- we may not have many carrots in the IPv6 transition game right now. Any panelists wish to comment on David's -- no? Okay. Center back. Yes.

MR. HANNIGAN: Martin Hannigan again. So I guess I agree with David's comments, and I'll move on from there, and also -- I mean, it seems clear, but it hasn't been said that there can be more than one carrot, obviously. And there can be things that we do now, and things that we continue to work on that are tougher solutions, like the monetization issue. So for example, Bob raised a point about the amnesty policy, an unsuccessful attempt to negotiate the return of some resources. We could now make changes to the amnesty policy to make it more friendly in terms of a goal of some reclamation. And I would support some activity in policy around that now. And I'd like to continue to hear
about the monetization issue in the proper forum. Thank you.

MR. VIXIE: I'm Paul Vixie. I'm a member of the Board of Trustees but I'm speaking here as member of the Internet community. I'm sorry, but I have several comments. First, to the suggestion that the end game is not worth playing because it would be a non-rational situation. I believe that was Scott's analysis. It will be a non-rational situation. That's true. That doesn't mean we don't play, that means we play now when it is still somewhat rational, and when we can get those addresses back into the pool, where they will be allocated by sensible community-based means instead of an open market sort of means like when you buy DVDs on the streets of Mexico City.
So contrary to what Scott said, I think that the non-rational end game means that we have to hurry rather than that we should avoid it. In response to -- I think Jordi's suggestion that we penalize someone who does not convert, I actually have two comments. The first is if we thought people would convert to avoid this end game, then we would really not worry about it, we'd give all the address space out just as quick as we could under the policies that we had. And then we would just say, well, that's the way to get to v6 faster. Nobody in this room believes that that's going to happen. We all believe that it's going to be a very tight end game. And I want to point out finally to the idea that we would penalize someone by saying that if you don't do a certain thing by a certain time, then you can't ever do it, or you can't do it for 20 years. What spammers do is if you say that they have to
honor opt-out requests, what they do is they form a subsidiary every week. And each new subsidiary gets to spam you until you tell that subsidiary to stop. And so you have this endless chain of subsidiaries who own each other. And I don't believe that there's any power in the universe -- at least the FTC has not found it -- that makes it actually possible to audit the ownership of each of those subsidiaries to make sure that they're not 51 percent controlled by somebody who you have told not to spam you. So let me just say that that has not proven practical.

MR. CONRAD: It's good to be back. On the question of irrationality, something I think I can claim some authority on. If not intense familiarity --

MR. CURRAN: Indoctrination.

MR. CONRAD: And yeah, I was on
ARIN's Board of Trustees.

MR. RYAN: Kind of cold in here all of a sudden.

MR. CONRAD: So from my perspective, and I'm not an economist, and I'm not going to talk about monetization except I am -- you can deal with scarcities in essentially two fundamental ways. You can deal with it via a command economy, which is the approach the RIRs have historically taken, or you can deal with it in a market economy. Historically, it appears that market economies tend to be more efficient in allocation in scarce environments as long as you have sufficient monetary resources to enable the acquisition of the resource. The challenge will be, as I personally believe; it's extremely unlikely that we won't have either a gray or even a white market in address space. The challenge will be in dealing with the routing system fragmentation
that's going to result from a flood of longer prefixes generated from the unused but allocated address space that currently exists within the legacy space, as well as the space that has been allocated by the RIRs. This is a topic that is relevant to what Marla was presenting on earlier, the RAWS (?) workshop that was held in Amsterdam and the RAM mailing list, and potentially a working group that may spawn out eventually of the interminable IETF processes. It looked like you were going to comment.

MR. CURRAN: Go finish.

MR. CONRAD: Okay. The key consideration is, as was discovered back in 1996 when there was a really bad set of ideas being floated about a working group that went by the name of PIARA, (?) that routing announcements and addressing have ties together when you're actually dealing with monetization, with dealing with scarcity and
the more efficient use of address space in particular. So it's just something else that the folks here, particularly the ISPs, will need to consider as they look forward to dealing with the multiple megawatts and millions of pounds of tons of cooling that they're going to need to actually deal with their new spiffy routers from their favorite vendors.

MR. CURRAN: So I'm going to ask, I guess -- I'll paraphrase a question that was implied by your statements. It is true that presently, allocations from the registries generally are following some form of pattern. They aggregate well, they're assigned either in well-known blocks or they're assigned through ISPs who maintain some aggregation. And this means that the impacts of the routing table is something that is if not predictable, at least tolerable. And that one of the questions that comes up as we get to IPv4 exhaustion is,
what happens to the routing table when all of those little IPv4 address nuggets lying around in the world -- both legacy and non-legacy -- get routed. And you said Marla's presentation is working on technologies that will enable all that. What I'm wondering is, do you believe that worrying about the legacy space and reclaiming it is going to help the problem of those routing tables or hurt the problem of those routing tables?

MR. CONRAD: It's going to make it infinitely worse. Specifically as the address space becomes more scarce, I believe -- I might be wrong, but I believe that the unused but allocated space will begin to populate the routing tables, typically the longer prefixes. In addition, ISPs are going to need to obtain address space in order to bring in more customers unless they want to stop bringing in more customers. And they'll
obtain address space however they can, which will almost certainly mean obtaining non-aggregatable provider-independent long prefixes, which they will then need to figure out how to do traffic engineering on. So within the context of the internal tables within the ISPs, the problems that they're experiencing even today with regards to having very large tables and a lot of thrash and very slow convergence is only going to get worse.

MR. CURRAN: And that won't be more painful than moving to v6?

MR. CONRAD: That's where the monetization comes in; right?

MR. CURRAN: Okay.

MR. CONRAD: At some point, it will become more painful, more expensive, to deal with IPv4 than it will be to deal with something else.

MR. CURRAN: Okay.

MR. CONRAD: Whether or not that
something else is IPv6 is yet to be seen.

MR. CURRAN: Panelist comments?

MR. RYAN: I thought, David, for the first time in my life, I've ever disagreed with you, it was your comment that we are part of a command economy. I totally reject that notion that the RIRs are a command economy, because frankly, if we were a command economy, we would treat these resources as if we wanted to make a profit like MITRE Corporation, and we'd monetize them so that our non-profit would be highly profitable. And that would be part of a command economy, so I was a little surprised by that part of your remark. And I think what I do see here, the routing table problem is the unique problem that people who don't belong in this room don't get. In other words, they don't understand the impact on the routing table of various policy proposals. Similarly, I think there is a need to hire economists to address
this. I think we literally need a different group of people to resolve this problem than we've used to resolve other problems. I would hire an economist here for this purpose. I might hire other trades as well, and throw them into the same room to try and come up with an appropriate policy. Only kidding, David.

MR. CURRAN: Okay.

MR. CONRAD: Just to clarify, the fact that the RIRs are at least one form of a command economy does not imply that the RIRs would be interested in deriving a profit. They're meeting other goals of the community to which they serve, just like other command economies have done historically in the past.

MR. RYAN: I actually -- I --

MR. CONRAD: We can take that off.

MR. RYAN: I've a Bachelor of Science in Economics, so the word "command economy" I don't think belongs here. Maybe it does, and you're correct, we can take it
offline.

MR. CONRAD: Would you prefer socialism?

MR. RYAN: Okay.

MR. PLZAK: I should warn people I'm closing the microphones in about a minute. If you have comments -- questions for the panel, or comments, please find a microphone. Microphones will be closing very shortly. Front center sent mic.

MS. AZINGER: Marla Azinger, Frontier Communications. This is a request, because David keeps hitting on things that are more for the v4s since that panel that we're going to do.

SPEAKER: Uh-huh.

MS. AZINGER: And it's really hard to keep my butt in that chair and not at the mic to go off on that stuff, because it's stuff that he keeps saying. So I just was hoping that people could keep it to what this
panel really is, and you can save that other stuff for later -- because I don't want to go off track either.

MR. CURRAN: Luckily we're winding down. So it shouldn't be hard.

MR. ORTIZ: Hi. My name is Humberto Ortiz; I'm from the University of Puerto Rico. And we actually have two direct assignments, they're /16s. So what would it take for us to become members of ARIN, and how can we contribute?

MR. CURRAN: There are multiple members of ARIN member services here who will find that man. We got it. Okay, on that point, I'd like to thank all of our panelists. (Applause)

MR. CURRAN: I will now turn this back over to Ray, and we can talk about the next item on the agenda, which at least on my agenda is a break.

MR. PLZAK: Thank you, John.
Couple of things. Guys, would you please remain seated? Thank you, Leslie. We're not done quite yet. First of all, there's a lot of work to be done here, and I would like to thank everyone that came to the microphone. It really is helpful. And I can definitely see some policy proposals coming out of this. A reminder that the Cyber Café is open, and that Richard, nee Vanna, will be there spinning the wheel. And we got some more prizes that will be going on there. And that's some of the other things that are still there, you can get. And please be back here at 3:50 for the next part of the agenda. Thank you. (Recess)

RIR Update - APNIC

MR. PLZAK: Welcome back everyone, I would like to introduce the Director General of APNIC. And here comes Paul, and Paul, I will turn the microphone over to you.

MR. WILSON: Good afternoon, I'm
Paul from APNIC. I'm here in San Juan with a few APNIC staff, Donna, Sam, and George. And also with the Chair of the APNIC EC, Maemura-san who is going to be presenting. Okay, I'm here to give an update about goings on at APNIC since the last ARIN meeting. And I'm -- what I'm going to be focusing on mostly is the latest APNIC member and stakeholder survey which was carried out, and the results released earlier in this year at the APNIC annual meeting in Bali last month. So I'm just going to tell you what these surveys are all about because they're fairly important in APNIC's future planning and operations in understanding what our community members and our non-member stakeholders expect of us. And we've done well now for these surveys, they formally conducted -- conducted independently off APNIC actually. So the -- one of the most important things there is to have a neutral and impartial method for surveying our
members and stakeholders, and also to guarantee confidentiality of the responses. So this has happened in all four cases so far, and it's quite important aspect of the way that we carry out the survey activity. In doing the fourth survey, the consultants KPMG recommended that we have a look at what has happened in past surveys. So they did a review of the three past surveys and had a look at how much of what we heard through those last surveys had been actioned. And they found that 90 percent of stuff that we heard through the surveys had been actioned, 39 percent completed, 51 percent of items in those surveys are actioned, but ongoing action items for us. So we did the fourth survey, we launched it last year, and published the results earlier this year. And so, just looking at all the surveys we've done, the fourth survey was the most successful, and the chart is showing that with each survey,
we've got more people participating in more countries, more economies represented. So the latest survey had 320 responses which is pretty comprehensive, and they came from 33 different economies of the region. So what did the latest survey tell us? Well, we got -- firstly, we got a very good spread of participation across all the member categories. We've got quite a few categories of members from small up to extra large. We also had out of the 320, we had 50 nonmember participants, and that's fairly -- a fairly good representation there as well. We also had a good spread of membership duration, and duration of the association of respondents. We've -- APNIC, so from less than one year, up to more than ten years of association with APNIC. Okay, Part 1 of the survey, there were several parts of the survey, Part 1 was an analysis of APNIC's performance, and there were 44 questions. And the average rankings
from all those questions are shown here. The chart just really shows the spread of results that we got. So the worst result was 6 -- just over six out of ten, that's the rating on the lowest result in terms of our performance. And the highest was 8.5 nearly. So 44 questions, and we could look at those in order. Firstly, looking at the top 10, the items that were seen as being -- which had the highest satisfaction rating, let's say, out of all the questions we had, support -- APNIC support for DNS root operations. APNIC publication of statistics and other reports, support for Internet development. We also had a number of service related questions; effectiveness of e-mail as a contact method, the quality of the APNIC Whois Database, and other service and services that we operate. Technical content in our meetings, the help desk service, our use of e-mail and mailing
lists, and the overall services quality. So those were the top 10 results that we got out of 44 for this survey. Probably more important, however, it's nice to see those. But probably more important is to look at the other end of the scale, the items that were seen as being less satisfactory or native of improvement. And interestingly, here we've got a couple of issues that are related to the policy process, the policy development process, and policy documents themselves being accessible. We had issues of effective ways to contact APNIC, not quite sure why phone voice over IP was not seen as that effective. But then, again, this was -- this question probably got a rating of seven or so out of ten. So it's not too bad. The process for obtaining resources is easy and straightforward, the value for money of APNIC membership, access to services like e-mail, sorry, eLearning, and APNIC
training and open policy meeting. So there again, we have a list of 10 items which are down at the bottom of the list, and these are the sorts of things that we would strive to be improving in the year or so to come.

MR. BRADNER: Do you have any additional information about that first one that the policy processes are fairly accessible, that's what they were complaining about.

MR. WILSON: Well, I'll tell you, the survey report is a pretty comprehensive report. And that's -- I'll give the URL, we've got the four results including all of the breakdowns of the survey result by the membership size, and duration, and so on, and also the text, anonymized text, all of comments that were made. So there might will be some comments particularly about the policy development process. I guess the dimensions of fairness and accessibility are quite -- potentially quite different, and
maybe the accessibility, that's the issue. Then -- rather than fairness, I'm honestly not sure. Something that we could, as I said, look at the reports and follow up -- follow it up in future surveys. Okay, moving on, the second part of the survey had a section where respondents could indicate where they preferred to see APNIC resources allocated in future, that's financial resources. And so that was it, a different structure of question, but allowed respondents to say where they thought that we should be spending the money. And the top 10 here are listed things like technical R&D activities, streamlining the resource request process, increasing the accessibility of meetings and policy processes which probably comes back to the question that's got just asked. We were asked also to spend resources on representing the needs of ISPs among governments and others, expanding
training activities, improving the website, supporting ISP education, deploying (off mike) and its route servers, implementing resource certification, and expanding external communications and outreach activities. So it's quite good to see these areas for resource expenditure corresponding in many cases to the particular issues that were seen as either high performance or in need of improvement areas in our past performance. And as I've said, there are a lot of other details that are included in the reports which could shed a little bit more light on what's managed under each of these topics. The report contains a lot of analysis, that has the sights on the website, I'll give you the URL. But there's some other things that we can also do here, that give us some insight into the nature of our performance. So by charting for instance, the
average rating in Section 1, against membership category, we see that there's a marked improvement in perception of APNIC, and in the satisfaction with APNIC is the membership categories increase, and in a related way it also -- the ratings also increase with duration of membership. So I guess that shows us the people get more -- they come to appreciate APNIC services and maybe understand services more as time goes on, as they become bigger. And as that being members for longer and that might give us some clues as to a need to spend more on early member education, for instance. There may also be some value for money issues going on there between the smaller members and the larger members as well. Okay, so there is a URL let for more information. The surveys are done, formally this -- all of the details on the website of all four surveys now, the survey forms, the survey responses, the formal reports from
KPMG and the formal responses that APNIC has given back to each of the surveys. And as I say, this is a fairly major instrument conducted every two or three years which we used to guide our activities as time goes on, and I guess we'll be doing the next one in a couple more years' time. Okay, so that's it for the survey. I just wanted to mention a few other developments, it's just a list of the sorts of things that we're working on at the moment. The resource certification, R&D project is going ahead quite strongly, we're spending a lot of effort on that particular project, and looking to do some pilot deployment sometime during this year. That will be linked to my APNIC, which is the APNIC member web-based portal, which is also being developed pretty rapidly to provide more and more services to members through that portal. In a more -- on the more public
side, we've got public statistics now published in an interactive way through this O3 platform which actually comes from Uruguay, the home of LACNIC. We've also got the project called ICONS which is the Internet Community of Online Networking Specialists, and that's something that corresponds with that request we have through the survey, and through past surveys to get involved a bit more with ISP education and provide some resources for ISP support in the Asia Pacific region. So ICONS is one of those efforts to -- along those lines. Internally, we've got ARMS, the APNIC Resource Management System which is under fairly constant development. We've got work on a content management system which will drive the website, that's sort of early research of this stage, but it's going to be the way we'll be operating that side of the organization in future. And the new human resources information system coming in, so
there's plenty of things going on at APNIC; I won't give you any details now of those, but possibly in future presentations. We've got meetings twice a year. The next meeting is coming up in New Delhi, it's first we've -- we will look at a meeting in South Asia. So end of August, early September, we're meeting and collocating that meeting with the South Asian Network Operators Group, SANOG 10 in New Delhi. And as usual, our annual meeting is with APRICOT, and it will be in the early part of 2008, and all are most welcome to any of those meetings, and future meetings, and the URL is there, so that you can find all the details. Finally, a word from our sponsors. Now, this relates to a project that APNIC staff taken on recently, and we see one of the major sponsors of APNIC as being listing -- illustrated here which is the friendly environment which gives us all air to breathe, water to drink, food to eat, and so
on and so forth. So we had something can ecoAPNIC which is a sustainability project operating within APNIC staff at this time. We're looking at reducing our ecological footprints, recycling high production, energy consumption, and all of these things, and trying to walk a bit more lightly on the planet, I think will also be accelerating our deployment of IPv6 in recognition of the green house benefits that Jordi is going to tell us about later on. (Laughter)

MR. WILSON: So that's the final thing I'd like to mention. So thank you very much, and this presentation was brought to you by ecoAPNIC using 100 percent recycled electrons. Thank you very much. (Applause)

MR. PLZAK: Any questions for Paul? I assume that by changing your travel range, Mr. Next Chair, the meeting you attend will be (off mike).

SPEAKER: Absolutely.

MR. PLZAK: Andrew.

MR. DUL: Andrew Dul, I had a question about the resource certification work. Can you give us any little tidbits on how that's going. I know they were planning on wrapping up most of the work by the end of the calendar year, and what's sort of going on with that?

MR. WILSON: Well, the pilot that I mentioned is that we're going to be issuing those certificates in accordance with the RFC through MyAPNIC, through the member portal, so that those certificates are available for U-Spy members now. That uses -- it is pretty experimental at the moment because we don't have secured routing protocols yet. The idea is to have a demonstration platform, their standards compliant that will allow members to get those certificates and use them. We're working very closely with the other RIRs on -- at a couple of levels,
sort of, a fairly broad scale, R&D discussion about the really widest implications I guess, of the certification activities, and also in a more targeted why on what the core -- common set of standards, protocols and methods are that would be required to be adopted by all of the RIRs, in case this kind of activity was to be adopted formally by the -- all of the RIRs and that's something that the NRO ECG, the Engineering Coordination Group, is looking at. But there is a hell of a lot of detail in that project. It's being coordinated at APNIC's and by Geoff Huston; he is leading that -- the R&D effort for us, and working also closely with people like Randy Bush and Daniel Karrenberg and Andre from RIPE-NCC and others. So it's something that you'll hear about more in some of the RIR meetings, for instance, the Tallinn RIPE meeting will have their certification task force meeting as part of their agenda, and they'll be talking
about what are all means over there, and those details. Thanks.

MR. PLZAK: ARIN's participation in that has been at the design level. This is the current direction by the Board of Trustees, and so we have been actively engaged in that R&D effort that Paul is talking about looking at the implications of what would be involved in adopting it throughout the RIRs and also looking at other things about how that would relate into, for example, the business practices of the various RIRs.

2006-7: Changes to IPv6 initial allocation criteria

MR. PLZAK: Okay, moving on we are now at policy proposal 2006-7, which I just had and I just lost. Okay, here we go. Before I begin this -- we present the staff assessment's portions of this.
If the staff assessment is being presented here, it doesn't exactly agree with what was presented on the mail list that reflects staff has had an opportunity to perhaps update their assessment, and this on large cases it is dependent upon what has happened in discussion since the staff formulated that initial assessment. And that like legal assessment is a snapshot in time, what things were and then as the policy discussion ensues and text changes and concept changes out of our policy, it could alter the assessment by both from a legal end resource perspective. So 2006-7 changes to IPv6 initial allocation criteria. First proposal in October of last year and designated a formal proposal two days later. And this is a first public policy meeting discussion of this proposal. There was a text revision in February of this year. This adds to the list of criteria
for initial allocation of IPv6 address spaces shown in that portion of the NRPM, and specifically in addition to the common criteria, if in there ISP is not known, nor can it provide a plan, it can instead attempt to justify, and tend to announce the address space within one year. The shepherds are Marla, Lea, and RS. Counsel sees no liability risk. This is of April this year. Staff comments, staff is concerned about the confusion that may occur if the text is inserted as the author indicated, and staff is suggested alternative placement. Question from the staff: How can staff verify the organization is new to providing Internet services? What happens at the end of the year if the IPv6 block is not announced? What if the IPv6 address space is used on a private network and can't be seen from a public Internet? And the change proposed would be in the F section of the
NRPM. From the standpoint of implementation, resource impact is minimum. We see the implementation within 90 days after the Board of Trustees' ratification of the policy, as is currently stated. And the implementation requirements at this point are seen as being guidelines changes and some staff training. The discussion on the PPML, 76 posts by 27 different people in essence seven threads for, five against. Some general comments, open it up wide, and worry about qualification after reasonable percentage space is actually in use. Disagreed based on a lack of proven need for a change in the likely detrimental effects it would have on the DFC. One interpretation of known ISP is having space reallocated and that reassigned to them via script by an upstream. The full text is in the meeting packet as well as present on this URL. And so I would like to ask Jordi to come forward and present the proposal.

MR. PALET MARTINEZ: Okay. This summary of this proposal is new organizations need a policy that allows them to apply for IPv6 address space on my proposal to solve this -- this problem is to add a new item to the -- new line item to the Section 65.11, which will be -- or be an organization new to providing Internet services and can justify intent to announce the requested IPv6 address space within one year through records which just contract inventory and/or other applicable documentation. It has -- there has been a spark of this test -- staff assessment, a new warning to solve one of the comments regarding the possible confusion reading that text. And I already indicated in the mailing list that I agree with that proposal, and I believe it don't change the content of the policy proposal. So the new warning for this section
will be section -- sorry -- line a, b, and c, exactly the same we have now, and we will be -- meet at least one of the following. Be an existing known ISP in the Asian region. Two, have a plan for making at least 200/48 assignments to other organizations without five -- within five years; or -- and this is the only new text that I am adding into this section. Be an organization new to providing Internet services that can justify intent to announce the request that IPv6 address space within one year through records such as contracts, inventory, and/or other applicable documentation.

MR. CURRAN: Yeah, so the text you see here is text that has been revised since original posting on PPML. It's been revised to reflect the confusion over the phrasing as received from staff as comments. This is the revised policy text.
It doesn't change the intent, but does make it a little clearer what we are all talking about. So he is presenting the policy text as intended. Just want to make that clear to everyone in case someone should happen to see an earlier version. This will be the version that will be discussed by the AC in going forward. Thank you.

MR. PALET MARTINEZ: Okay. So the rationale for this policy proposal is that the existing policy is fine for an existing -- a non ISP in the Asian region, but we are not concentrating cases of new ISPs which may want to start offering IPv6 services and somehow it becomes artificial to them to start, first providing IPv4 services. I think there was also clarification yesterday in the open policy meeting that they are actually considering the time for these -- one year -- if I don't misunderstood Leslie. I'm not sure if Leslie is here.

SPEAKER: (off mike)

MR. PALET MARTINEZ: Yeah, so it was -- you were commenting yesterday that the time for -- to be known was one year, according -- yeah, your interpretation. But this is an interpretation that is not in the policy right now. It's your free interpretation. Okay. So I think it is somehow an artificial measure according to the existing policy. Well, the other point is that they need to have a plan for more than 200 /48s but there is possibilities of perfectly running business, which has only 5 or 6 or 10 or 50 customers instead of 200, and asking the people to create an artificial plan for that is also not probably a good idea, right. Then there is another point here is the usage of the /48. ISPs can decide to use something different, so even the existing warning will not make that. So, for example, the case of a cellular operator which probably will use his last 64 instead of his last 48. It's also important to understand
where it comes from this 200 number. And it's from historical reasons when this proposal was jointly developed by -- together with RIPE and APNIC. and in fact, this situation has been already corrected in other regions like, for example, LACNIC and AFRINIC, they already don't have this requirement, and it has been discussed in APNIC. It's brought back to the mailing list. It has been confirmed to me this morning that it's not actually abandoned. I'm still working in a new version for the -- that's in APNIC. And in RIPE, I believe that it already reached consensus, I'm quite in just (?) for the decision of the Co-Chairs for that to go for the next stage. Again, asking for this may bring people to actually make up a plan when they know perfectly that they don't -- are really going to have to handle customers. Then there is another consideration, which is one
year -- I think it's reasonable time today for at least announce addressing a space. If the organization really wants to become using it and that's the reason they are asking for the resource. In summary, I think the proposal will allow new, ISPs which are reduced number of customers or ISPs which intend to offer only IPv6 services to immediately access that resource. There is one more comment during the discussion of this proposal and the mailing lists one of the possible criteria is that we were talking about was to require an ASN to be used for that organization, right? I think the majority of the comments in the mailing list were opposing to that, so I decided to remove that criteria that goes in my original version for the proposal. Yeah?

MR. CURRAN: Continue.

MR. PALET MARTINEZ: Okay. Regarding the comments from the staff, I already mentioned
it in the mailing list, I think it was before or right after lunch. It's important to realize that from the four comments they made, three of them are somehow referring to the existing text in the policy that we have today, not actually to the change that I'm proposing, and I'm going to detail it in the next -- in the next slides. The one which is relevant has been regarding the formatting and I already accepted that modification and John confirmed that AC read the proposal considering that new formatting because there is not a change in the contents of the proposal. So, that first comment, excluding the one that we already accepted from the staff is the question, how can a staff verify that an organization is new to providing Internet services? I think it really doesn't matter, but reading the new structure of -- or formatting of the text, I think it's clear
that if the organization is nor complying with not being a known ISP, it's automatically falling in the consideration of a new one, okay? So it's -- you have three choices now in section D, and if you're not a no-ISP, obviously you are a new one, okay? So it's by exclusion. I'm not sure if that's clear. If not we can come back later to this. It can somehow be read also as -- it's new to ARIN. Maybe it's new signing the RSA or whatever. I mean, this is more subjective reading, but I believe that my preview sentence is just enough to cover that to answer that question. Okay, the second question was what happens at the end of one year, if the B6 block is not announced? Well, I think the stuff should follow the same criteria. They're actually doing for the existing choice in today policy, section D, which is be an existing non-ISP in the region of -- or have a plan for making at least 200/48
assignments to other organizations within five years. What they do if after five years is not happening? So that's why I am saying that this is not actually consideration for my new text or the new proposed text, but actually for the existing text, right? And you know, this year you have still to comply with section C, which is planned to provide IPv6 connectivity to organizations to which it will assign IPv6 address space by advertising that connectivity through its single aggregated address allocation; that's still (off mike) so -- again, you still have a measure of what you need to do, or if you don't know what you need to do it's a different part of the policy, what we need to work out, but not what I am submitting, okay. Last one is what if the IPv6 address space is used on a private network and cannot be seen from the public Internet? The suggested proposal is not intended for
private use, and point D, not being end site already indicates that must not be an end site, obviously, so the organization necessarily will need to announce the located space as in C again. So again, I think we are here providing questions to part of the proposal that is not being modified by this proposal, okay. And that's it.

MR. CURRAN: Okay, microphones are open. Jason.

SPEAKER: What's going on, oh, okay.

MR. SCHILLER: Jason Schiller of Verizon Business, UUNET. Oh great, policy text is up there. The first question I have is, you mentioned about an ISP that's only offering IPv6 and not doing any IPv4, and I'm just wondering how would that work, what would you use for your router ID, if you don't have any IPv4 addresses?

MR. PALET MARTINEZ: Well, it's one of the possible cases. I'm not saying the
policy is trying to solve that case, but it may work also in that case. For example, you may have an ISP providing only IPv6 services and using some kind of proxy to Before Internet. And for the proxy, obviously, they will need Before addresses, but maybe they are connected to one upstream that it's already providing that IPv4 address, because it just -- for the point-to- point link or something like that, that's one possible scenario. I just make up -- make it up right now. I mean, I'm not sure if technically it's totally possible, but I can guess that maybe, yes, for some kind of Internet services.

MR. SCHILLER: For BGP path selection to work you need a router ID and that must be an IPv4 address?

MR. PALET MARTINEZ: Yeah, but you can get this IPv4 address from your upstream. For example, not necessarily, you need to go to ARIN for ask for it.

MR. SCHILLER: My second question is, it seems to me that the bar is fairly low, it seems that my house could get a /32. For example, if I have a wireless router, and my next-door neighbor is using me for transit, and if I therefore claim, because I'm providing transit I'm not an end site and I have a Cisco 2600 series router, which is v6 capable. And I have an upstream ISP that already does v6, I've already got, you know, a PA allocation from them. So should I be able to get a /32 for my home?

MR. PALET MARTINEZ: Okay. (Laughter)

MR. PALET MARTINEZ: We are talking here about organizations, I am not defining what is an organization. My understanding that this is a requirement which should be defined already somewhere else in the NRPM. I'm not sure if that's correct or not, but if that definition is not correct then we may need to work out some text for that section, not
probably here. Otherwise, we need to define every term in every proposal, every policy or every part of the policy manual. I'm asking, I'm not really sure if it's well-defined what it means, an organization.

MR. CURRAN: So --

MR. PALET MARTINEZ: For me, your case will not be an organization.

MR. CURRAN: So given the text you have here, Jason, do you support or not support the change?

MR. SCHILLER: I do not believe I support this policy.

MR. CURRAN: You do not believe you don't support the policy?

MR. SCHILLER: I do not believe I support this policy.

MR. CURRAN: Okay, and why?

MR. SCHILLER: I think the bar is fairly low and anybody who claims to be an ISP can get a /32.

MR. LOCH: Okay, sure. Name is Kevin Loch, Carpathia Hosting. I do not support the policy as written, I think we do need to put some significant work into rewriting that entire section regarding, you know, yesterday some comments were made. I guess it was the ARIN staff comments yesterday about things that we could work on with policy. One of them is right on here about known-ISP that needs to be well defined. Right now it's fairly ambiguous. I'd suggested on the mailing was that a known-ISP could be anyone that has had space allocated to them from an upstream. And -- but with regards to the specific text, really I want to make sure we're trying to solve an actual problem, not just a theoretical one. Do you know of any organization in the ARIN region that has not been able to get IPv6 ISP/32 resources?

MR: CURRAN : Jordi, you know of
organization that has --

MR. PALET MARTINEZ: In -- when I presented this policy proposal or the idea of this policy proposal in the last open policy meeting, not the yesterday one, but the last -- the previous one, there were two people going to the mic, I don't remember who they are, but probably -- I'm not sure, if there are minutes of that session, but two people from the region stated, I'm in this situation. There has been also another company, I mentioned it yesterday also, which is, I think, a truck manufacturer, which its based, legally speaking, in U.S., but also in Rhine and they actually in an other mailing list opening said we have so many offices and we would like to provide 200/48 and so on, and the existing policy don't allow us to do that. So this will probably solve the problem also for them. They could go also to
the similar policy that we happened to write if it becomes approved. But I guess that if they are actually getting the resources for mailing in terms of IPv4, they will prefer also to get IPv6 from mailing, I guess.

MR. CURRAN: Okay, so given the text you see here, recognizing that you noted you wanted those comments on existing other text D1, but then that could be picked up at a subsequent time, this change is, I want to stay focused on, Jordi says, that would effect it for a real world organization, would you be in favor of this change or not?

MR. LOCH: Yeah, I'm not in favor of this change because I believe that we could make some other changes that would also help in other -- clarify some other cases as well as the specific ones that he's mentioned.

MR. CURRAN: Okay. And it's not worth proceeding with this one; it's better to address them all at once?

MR. SCHILLER: I think -- yeah, I think we could fix it with another proposal or perhaps reengineering this one to address some of the other text to cover it without the way we're doing it here.

MR. CURRAN: Okay. I'm going to say for now I just wanted to stay focused on this, but the open microphone session comes later today or tomorrow, if you want to raise the other issues, because we haven't had a lot of discussion necessarily on other aspects of the same section that need to be changed. We had some on the list, but we haven't had any yet today. I want to try to keep it focused on this short time. Do you have another question about his text here in D3?

MR. SCHILLER: No.

THE CHAIR: Okay, thank you. Microphone -- yes, front center?

MR. DeLONG: Owen DeLong, Jittr Networks. I do not support the policy
as written and what will probably survive a -- or surprise a large portion of the audience in this room. I think it sets the bar too low. I think that as others have pointed out, it allows pretty much anybody who wants to pretend to be an ISP to get a /32, and I think that that is not the precedent we want to set. I agree that changes are needed to this policy to support cases that it currently excludes, but I don't think this is the right change.

MR. CURRAN: Okay, thank you.

MR. PALET MARTINEZ: Again, I think my comment here is, if the main problem is the bar is too low because the definition of organization, I don't believe the definition of organization should be put again here; it should be somewhere else in the policy manual, right?

MR. CURRAN: Is that your objection?

MR. DeLONG: The barrier is too low
by the wording in the policy as it exists in the current context.

MR. CURRAN: Okay.

MR. DeLONG: If you want the policy to be acceptable, it needs to be changed such that the barrier is not made too low.

MR. CURRAN: Okay. Far microphone, is that someone one lined up? Yes.

MR. ITO: My name is Kosuke Ito from Japan. I kind of support the intention of the -- to this addition, but as an original also of the editorial team of the IPv6 interim policy, the number D3 is already in place into the existing text. So it doesn't have to be text-out as in a D3, that's my understanding. And trying to be -- lower the entry barrier is not the intention of the original text. However, opened up to that -- newcomers as in v6 era is welcome. That's why me trying to be -- not the sitting Before ISPs used to be there as an -- entrance over the v6 service providing --
that's my comments.

MR. CURRAN: Okay, thank you. Jordi, response?

MR. PALET MARTINEZ: No, its okay.

MR. CURRAN: Okay. Microphone in the back center?

MR. BICKNELL: Leo Bicknell, Harrah's Entertainment. I don't support the proposal; I think the problem that we're actually dancing around is that point D2 up there is something that my perception is no one likes and needs to be bettered to find to include the case you're trying to define and several others. The other thing that struck me as I listened to your presentation is that it seems to me that there is some level of overlap in concept between this policy for v6 and what we call the "immediate-need" policy in v4. That provides the mechanism for someone to get it to us as they're going to use within 30 days, based on business plan
and other items and the thing that I took away from this is that the two bars is rather differently set, which maybe appropriate because v6 and v4 are not the same thing. But, I would be more inclined for instance, to support this if the policy said that it had to be used within 30 days as the immediate lead -- immediate-need policy does rather than a year.

MR. CURRAN: Okay. So, as written, you would not be for the policy?

MR. BICKNELL: Correct.

MR. CURRAN: Okay. Center front microphone?

MR. SEASTROM: To correct what Leo just said, actually the immediate-need policy right now says, immediately and I have two proposals, they're in the -- in the chute, try to address that. I understand the intent of this policy, I am behind the intent, but I think the implementation is flawed. I think that
to the greatest extent possible, we should make the v6 policy congruent with the v4 policy and if that means passing the latitude to ARIN's staff to make the judgment call, then that's the appropriate path to take. I would be fascinated to hear of sample organizations that met through D3 but did not meet D2 and also were not an end site as the initial qualifier is. This seems like, when you draw the diagram of those, you actually end up with almost nothing that actually overlaps there. I mean, you would think that an organization that was planning to be a v6 ISP would plan to have a couple of hundred customers in the next five years, maybe not. But if they're -- are that small maybe they don't need, maybe they would be better -- to go for some sort of micro allocation.

MR. CURRAN: So, as written you are for the intention but as written --

MR. SEASTROM: I like the intention
but as written I can't get behind this.

MR. CURRAN: Okay, and is there any minor change that you could make to get behind it?

MR. SEASTROM: I wish that I could propose something like that.

MR. CURRAN: Okay, thank you. Microphones are open, we've heard from people both for and against -- if you're for or against and you wish to share a comment that hasn't been shared, please approach the mics, I'll be closing the microphones shortly. Center rear mic, yes?

MR. LEWIS: Ed Lewis, NeuStar. I'm against the policy as written. After sitting here trying to understand the debate it's a little more clear to me but, is being ISP not an organization because (off mike) what organizations used in different context up until Part 3. So, this has to be an ISP it sounds like from this -- to be there. Also, the word "new," you said in
the presentation that -- the questions was how can the staff verify if they're new and you said it doesn't matter, which makes you wonder why the -- why its in the policy (off mike) at all and after taking that out there and hearing the previous couple of comments I can say that I don't see that this adds anything to the existing text, as it is.

MR. CURRAN: Okay, so you're against the policy because you don't feel it's necessary?

MR. LEWIS: Yeah, I mean, I've been in-line here actually understanding it more and as we dive through and carve things out more and more it sounds like its just trying to get around the 200 /48 number that's what it seems to me.

MR. CURRAN: Okay, thank you. Microphones remain open, if you're for this policy proposal, and would like to speak for it, please find a microphone immediately. Jason, front center?

MR. SCHILLER: Jason Schiller, Verizon Business. You know, John, you solicited a question, is there any way you could modify this policy so that you could get behind it. Can I answer that question?

MR. CURRAN: Sure.

MR. SCHILLER: I think potentially one way is to change the 200 /48 assignments within 5 years to possibly a longer period of time. That would allow a sufficient amount of time for ISPs or organizations to grow of a sufficient size, maybe 10 years, maybe 50 years. Just to throw out another number.

MR. CURRAN: Okay. So just recognizing, several of the people who have said they need to treat those -- they would like to treat the policy, they don't know how to do it, noted that the bar is too low. Lengthening the timeframe of 2 increases -- again, lowers the bar in yet another clause. Is that the change that would let you support it?

MR. SCHILLER: Yes.

MR. CURRAN: So if --

MR. SCHILLER: Because I don't think my home would qualify under a policy of 200 /48s in the next 500 years.

MR. CURRAN: I see. But no amount of years would qualify -- but your assumption is that a home would have to meet both 2 and 3?

MR. SCHILLER: I'm saying strike 3 and instead lengthen the time --

MR. CURRAN: And instead lengthen 2, okay. So that's -- an option would be instead of advancing this policy to advance one that affected the same thing by changing the timeframe on D2.

MR. SCHILLER: Yes.

MR. CURRAN: Okay. Rather than trying to rework this one, I guess we'll have to keep that other option in mind. Do you want to respond, Jordi?

MR. PALET MARTINEZ: Actually, my
original proposal, if I don't recall incorrectly, was just removing -- I think it was at that time Section D, totally. I got a negative feedback from that also. So another possibility that we have discussed in the mailing list also -- if again I don't recall incorrectly because I have been discussing this in three regions at least, so I might become a little bit confused at the end, was have a plan for making assignments and not telling how many. Again, you may consider that as lowering the bar, I understand that, but it's different chances or choices that they have been discussing in the mailing list.

MR. ITO: Yes, just one comment. As an original member of the text of this policy, as -- I talked with David Kessens in (off mike) and of the whole and this is --
this text is really, really balanced at 5 years ago. Then if you would change the parts by parts, it could be disrupting the balancing I guess. So if you like to change the parts by parts, then I would like to propose that totally review the whole text as in the whole set of the policy. Then you have to see how -- like a HD ratio issue as well, how you should balancing this text as well and make it a revision of the policy. That's my proposal.

MR. SEASTROM: Rob Seastrom again, ARIN AC. To follow up on what Jason said, if we are taking it to be the word, we are trying to make things a little bit easier without lowering the bar too awfully far. A
conversation I had with Leslie last night discussed the -- that 200 number and the /48 being no longer the standard-only piece that you're handing it. And if we were to slide the bar to the right a little bit and make it, say, 128 /48s, which would be a /41, within 4 years, or maybe a /42 within 3 years, that may be a little bit lower than we want to go but that would both clean it up and have the effect of tweaking the bar down just a little bit.

MR. CURRAN: Got it, okay. Center, rear.

MR. LOCH: Sure. Kevin Loch again. I just wanted to point out that for the few organizations that would be affected by not having this clause in, they only have -- plan to have 50 customers instead of 200, there is nothing to prevent them from going to an IPv6 upstream today and getting space from them. And once they are providing services then they meet the magic known ISP clause,
presumably. And in fact that's exactly the way it works in IPv4 today. You can't just come in unless you have a particularly large established base of instant subscribers. That's the way a lot of people in this room got started being ISPs by getting space from upstream provider and of course that's inconvenient, but that's just -- that's the way it works and that's the balance that we've, you know, established to help keep things running smoothly between routing tables and the needs of people for address space.

MR. PALET MARTINEZ: If you are not multi-home end.

MR. LOCH: If you what?

MR. PALET MARTINEZ: If you are -- if you have several upstreams that doesn't work.

MR. LOCH: If you're multi-homed, you're saying, or not multi-homed?

MR. PALET MARTINEZ: Yeah. If you are multi-homed what you just explained will not
work.

MR. LOCH: If you're multi -- I don't understand how that would be --

MR. PALET MARTINEZ: If you have different upstreams which addressing space, or from whom of them you are using addressing space to provide services to your customers?

MR. LOCH: I think you could use -- well, if there is a couple of options to that there is the -- you could use space for some customers on one, some from another provider to another. You could announce some more specific. Clearly, some people are doing that today. I don't think -- I think that's discouraged, but I don't think everyone that's being filtered across the board. And I don't think that's -- that issue has been settled yet.

MR. PALET MARTINEZ: Okay. Another example.

MR. LOCH: Once again that's the way it's done in v4 so --

MR. PALET MARTINEZ: Yeah. Another example that why I think that will not work. You have today an upstream, and in six months from now you decide that you have a better deal with another one or your upstream goes to bankrupt. You need to remember all your customers.

MR. LOCH: I think you would find that there will be a relatively short period of time between becoming and known ISP and being able to qualify under the existing policy so that that situation would not apply for more than about 3 milliseconds.

MR. PALET MARTINEZ: My understanding was one year. That was my understanding.

MR. LOCH: And that's -- I understand that. And that's something we definitely need to look -- take a look at the known ISP language and clarify that because I don't personally agree with that one year clause.

MR. PALET MARTINEZ: Yeah, okay.

MR. CURRAN: Okay. Final comment, Counsel.

MR. RYAN: I'm not taking a position for or against a proposal, I never have. Jordi, would you put up the slide where you dangle the anti-trust issue at the end of it?

MR. PALET MARTINEZ: Yeah.

MR. RYAN: And I waited until the end of the discussion, I didn't want to influence this. I think Jordi and I disagree on this issue, based on American law, currently, I do not see a legal issue for ARIN in not adopting this policy. In other words, if you chose to adopt this policy go ahead. But I do not see that the lack of a policy to provide IP address space in this situation, which I think is a little bit theoretical, which goes to the substance of the proposal. But I don't think this is the barrier to entry that would constitute and anti-trust violation given all of the other
things that one has to provide this is, I think, based on Kevin's last point, not the barrier to entry. So I really -- I just want to say gently that I don't agree with this being any part of the reasons for adopting the policy unless from a technical standpoint the community believes it does constitute a genuine barrier to entry which I do not.

MR. CURRAN: There comes a time in every meeting when it is necessary to get a show of hands in order that the Advisory Council can have some input for their
deliberation. As such if I could have the text of the proposal put up, the policy text that this proposal is up. Policy Proposal 2006-7 as shown on the screen. I'm going to seek a show of hands for those in favor for advancing this, and those opposed. So would all those in favor of advancing Policy Proposal 2006-7 as shown on your screen please raise your hand? In favor, please raise your hand high. All those who don't -- we got it, okay. All those opposed to advancing Policy Proposal 2006-7 as shown on your screen please raise your hand nice and high. Okay. Thank you. We have a count.

MR. CURRAN: Okay. Number of people in the room, 107. All those in favor of advancing 2006-7 as shown on the screen, in favor -- 2. All those opposed -- 31. Thank you very much.

2007-8: Transfer Policy Clarifications

MR. PLZAK: Okay. Moving on, by
the way we are now behind schedule. So policy proposal 2007-8, Transfer of Policy Clarifications introduced in February this year; designated a formal proposal in March, this is the first meeting for discussion, no revisions, standardizes the use of the term, number resources throughout the transfer section of the NRPM. Shepherds are Matt and Heather. Legal assessments comment. We are reviewing this policy. In the past we have advised the transfer of issue create the risk of litigation when ARIN refuses a transfer of resources. In view of the non-uniform RSAs including some that have a different dispute mechanism, ARIN should handle any changes regarding transfer as a policy. Rather than amending the RSA, ARIN should consider amending the proposed policy service provide in sum or substance that if a party does not attain the transfer of resources within a certain period of time,
for example, 30 days or 45 days, then it would have the right to initiate a dispute in the forums specified under the current RSA or the RSA that governs the party. Staff, there's no comments? And says that the section change would be in section 8 of the NRPM. Implementation would be minimum; 90 days or thereabouts after the Board ratifies and change the requirements with implementation ground-3 guidelines change and staff training. Opposed to this by 16 people; two threads four, none against. The comments are, the number one issue is whether the size of the address blocks are justified by the new assignee and the transfer policy discourages people from talking with ARIN and is there anyway to tell if resources fall under ARIN RSA or any other RSA. The full text is here. The author of the proposal is not here; however, one of the Shepherds, Matt Pounsett, will present the proposal. Matt?

MR. POUNSETT: All right, just bear with me for a sec while I get this sorted out. Okay, as Ray noted, it was originally authored by Paul Andersen. He discovered a few weeks ago he wasn't going to be able to attend, so I've taken over for him. So the first thing I wanted to note is there is actually nothing new in this proposal; that this is an editorial modification to bring the policy in line with the current practice and to clarify some confusion in the wording that doesn't seem to be part of the original idea behind the policy. So the first thing that this changes is that it takes all the phrases in Section 8 that refer to things like IP addresses, address space, ASNs, and change them all to refer to their more generic number resources. The reason for this is that there were a few cases where IP address
would be referred to but not ASNs. And so by the strict letter of the policy, it was actually not possible to transfer ASNs in some cases. A paragraph at the end of section 8.1, which refers to the transfer of resources that are outside of ARIN's region was removed. The reason -- the original reason for this had to do with ARIN managing resources that were in areas such as Africa and South America and was written before 1997. Before the -- a lot of those resources were transferred to their proper RIR. And in addition, in later years a new procedure was developed between the IRS for taking care of those transfers in a different way. So, this is just obsolete text. And finally, a sentence at the end of section 8.3 that referred to guidelines for IP and AS numbers. That seem to be purely guidelines and was not actually a policy text and so it was removed. Any discussions? Microphones are open. Jason?

MR. SCHILLER: Jason Schiller, Verizon business UUNET. I have one little editorial on this --

MR. POUNSETT: As -- just want to know. Are you --

MR. SCHILLER: I am for the policy.

MR. POUNSETT: Thank you.

MR. SCHILLER: Thank you. I have one little editorial -- the way the policy appears on the web page is slightly different than the one published here.

MR. POUNSETT: Yeah. You -- that was what you mentioned this morning. Yeah, those -- we noticed this morning a typo in the printed copy of this. It appears correctly on the ARIN web site. One of the bullet points near the end of -- it is section 8.3 I think. Is that right?

MR. SCHILLER: Yes.

MR. POUNSETT: One of the bullet points near the -- and of section 8.3 is indented when it shouldn't be. I don't --
I'm sorry I don't have the printed copy in front of me if you could --

MR. SCHILLER: It is a description of how address base is being utilized. Should not be double indented it should be single indented. The other editorial that I wanted to point out was that that is the only bullet where the old text address base still remains. It was the intention to also change this to number of resources.

MR. POUNSETT: No, that was also an editorial error that somehow got reverted at some point during the process. That should say number of resources.

MR. SCHILLER: Thanks.

MR. POUNSETT: Okay thank you. Microphones are open people in favor or opposed to this proposal please find the microphones. Okay, centre back.

MR. LEWIS: Ed Lewis, NeuStar. Right now I am undecided, because I have a question. Does this policy apply to space
that is not under RWhois like a legacy space?

MR. POUNSETT: So there is a whole bunch of people looking at me. Sorry, I am -- if it is -- the transfer policy applies to all transfer requests coming into ARIN and it specifically discusses the transfer requirements for an incoming transfer. So yes, it does, okay. Okay, that is required for that.

MR. LEWIS: Yeah I have another -- the other point I have here about the wording, it says that the POC must notify ARIN if business fails and that one line sticks up because if the business fails the POC may have been fired or laid-off already. If it says -- when it says the POC it doesn't say a POC it doesn't say or POC it doesn't say a particular who has to come in and tell ARIN.

MR. POUNSETT: Yeah an interesting point but actually -- I think it is actually outside the scope of this proposal. There
actually was a fair bit of discussion about this sort of thing on the mailing list, which actually very rarely addressed the policy proposal itself, which is just days these three changes. Albeit the entire -- the rest of that text is current policy. And it's not affected by this proposal.

MR. LEWIS: I think to get back to whether I'm for or against.

MR. POUNSETT: Yeah.

MR. LEWIS: I'm for this as an update to the current state of affairs. But the question about the RWhois that was -- that makes me uneasy about this being the way we should do transfer policy. But that is not what we're not trying to argue about. That is -- in this case I will be for the policy (off mike) other question.

MR. POUNSETT: Okay, so you are for the proposal as --

MR. LEWIS: Yeah, I think it is -- it's good to clean up the policy manual and
we will deal with the other issues later.

MR. POUNSETT: There was a fair bit of discussion there of things that probably should be addressed. But it is not stuff that is being addressed by this --

MR. LEWIS: That is why I get hung up on the discussion because I was looking at this as about the non- RWhois current space.

MR. POUNSETT: Microphones remain open. Closing the microphones. Anybody with a comment? Microphones are closed. Thank you very much. (Applause)

MR. CURRAN: Once again in order to assist the Advisory Council in their deliberations of the matter, from time-to-time, we seek a show of hands. We are currently on policy proposal 2007-8, transfer policy clarifications. I am going to seek a show of hands for those in favor and those opposed. So, all those in favor with advancing policy proposal 2007-8,
please raise your hand? Thank you. All those opposed to advancing policy proposal 2007-8, please raise your hand? Thank you. Do we have a count? The room's lost a lot of people between the last vote and this one, but a lot of show of hands in this one. Again we excluded staff this time around, sorry about that. Both shows of hands had 89 non-staff attendees in the room. So, number of people in the room, 89, all those in favor of advancing 2007-8, 36; against 0. Thank you.

Open Microphone Session

MR. PLZAK: Thank you, John. We now move on to the next item in the agenda, which is the open microphone, and I need a slide for that, don't we? And there we go. Please remember the meeting courtesies and rules of discussion, and if you're in doubt what they are, just refer to the program in your meeting folder, and I will turn the mic over to John.

MR. CURRAN: Thank you. Okay, open microphone session. This is where we have a session available for you to address with the community on any topic that hasn't come up yet, any topic that's -- may be launched new and interesting discussions that might be additional changes to our policies, any other matter that you want to bring before the esteemed body. The microphones are open. Leo?

MR. BICKNELL: Leo Bicknell, Harrah's Entertainment. Something that came up in our discussions of the PGP mail from X.509 trio of policies was several other alternatives that maybe of interest. Specifically, it seems when I talked to people, you can bucket the room into two groups of people. Basically, the belief is that ARIN members are either people who touch their resource about once every five years to update with their new e-mail address or they are people who send them about three trillion
swipes a day through some automated system. There are not a lot of people in the middle. And from everyone I talked to they seem to think the first group who interacts very infrequently would probably be better served by a, you know, my.arin and.net page with some little help-you wizard to do whatever it is you need to do. Probably, not a lot of people in this room fall into that bucket. And that the people who are doing heavy automated updates would possibly be better served by a more programmatic interface anything from CRISP to XML to choose your favorite protocol today. So, I would just be interested if anyone thinks that either one or both of those would be a good idea.

MR. CURRAN: Okay, so microphones remain open. If you'd like to see a lightweight interface with wizard to help you manage your resources or if you'd like to see
something much more intense and programmatic to help you manage your resources, find a microphone and speak for one of those. Yes, microphone in the back. That's you.

MR. LEWIS: Ed Lewis, NeuStar. I have a slight different -- this -- going back to also to talk -- the same policy problems. We were talking about codify what the intent of those (off mike) the PGP, X.509. And how much of that -- how much detail do you want in the proposal? Do you just want to say we want to provide security? And over the past couple of meetings -- right now, this is kind of scary (off mike) we were talking about this during the break. Once again coming to this idea, we want to be able provide more technical input or technical input to the staff to kind of build up an approach to do something. The policy part shouldn't get that deep, but we don't really have any other way to get information communicated to the staff,
say we want you to PGP or X.509, and how to do that, and what the security policies are and all that. We still want to look another -- some way of getting information discussed openly because, I guess, if you went to the ACSP that doesn't always go into the public view that's -- it could be a one-on-one kind of conversation for good reason, the times when that doesn't want to be public. But we could -- if we could think of some way of getting a technical discussion for those who want to look at the technical details and guts of what a policy would mean, if we -- that.

MR. CURRAN: So let's discuss that. Certainly to the extent that you want to provide input to ARIN, and it's not a matter that may not be the policy itself but on implementation or technical details, the consultation and suggestion process was designed for exactly that. And we tend to error on the side of more visibly and more
open, not less. So if you really think it's something that needs to be discussed here then you can say, I need this to have be discusses and that will lead to -- it's showing up on mailing lists, and that will lead to it actually getting a slot on the floor here to be discussed. So you don't need to worry about the fact that if you send it in through that process it will disappear. It will try, it's the belief of the Board and the ARIN staff that we want to try to address as much as possible, but if there is any doubt we're going to try to fall on the side of making it more visible and more discussion.

MR. LEWIS: Do you think it's maybe a way that a suggestion could come in that is marked as "Intended to be publicly discussed," or "publicly poll --" there was one poll recently. Do you think that might be mentioned in the processing? I want to suggest something, but I want to do it in a
way that I don't want to be the one who tells ARIN here is how you do authentication. But I want to dive in deeper to say, let's look at some of the authentication methods and what policies do we need to have, but then it could be turned into what would be a good clean public -- PPML type policy, and then say so long as we adhere to certain level of standards or whatever.

MR. CURRAN: When you say policy I just want to be clear.

MR. LEWIS: Yeah.

MR. CURRAN: You're talking about Internet resource numbering policy as in how determination of resources are handed out, or are you talking about implementation of those policies?

MR. LEWIS: Actually, in my sense I was using in both ways.

MR. CURRAN: Right.

MR. LEWIS: When I say PPML, I mean the policy process as we know the NR -- the
Number Resource Policy Manual that kind of policy as opposed to when you talking about security policy, saying I only trust some of this stuff. The problem is that the security policy that those -- that kind of detail doesn't belong in the NRPM necessarily.

MR. CURRAN: Correct.

MR. LEWIS: That's why we need to figure out where we can discuss that, some place it's, you know, more interactive in e-mail and not have to wait six at a time to get face-to-face.

MR. PLZAK: Yes, first of all, the proper place, I think, for that is the consultation suggestion process. I also think that when a suggestion is presented we have attempted to answer the specific question that was being asked or suggestion that was being made, and that if there was
something else intended, perhaps when the response is provided that this is not a closed end. I mean, that particular suggestion may be closed. It doesn't mean that the thought is closed. It doesn't mean that the discussion is closed. And so that the possibility is there to maybe reshape or get the question out because what we want to do is to make sure we have the question phrased exactly the right way we want to, to have a discussion about it. And so we also have to be careful that we keep the policy, the PPML, for policy discussions. We do have other list to discuss this. And certainly we do have some growing pains with the consultation suggestion process because it is not that old yet. It has been used a lot since it has been started. We are seeing more and more use of it. But I think that as it matures these kinds of things that you're talking about right would actually come forward. I mean,
you could say the same thing about the PPML if you looked at it five, six, seven years ago as well. So there is a number of things that we need to do here, and as we continue to grow and mature we will certainly do things better. So if in particular the suggestion is that we need to have a discussion about this then that could be the suggestion of itself other than proposing a specific dynamic if you will.

MR. CURRAN: Yeah.

MR. LEWIS: In sense of publicizing that channel I think for the -- maybe for the Members Meeting or something next couple of day to see a statistic of how many -- how many -- how busy is that channel? One thing I'd be just curious of. Also there was a poll -- I don't need an answer right away, but if you obviously know it.

MS. HAMLIN: -- we actually published today on the website, an
announcement was sent out, ARIN announced this afternoon (off mike) and suggestions and with one consultation, so it's off of the main suggestion page.

MR. LEWIS: Okay. I don't have my computer here, so I didn't see that. The other thing too is I think that it'd be good if we had the summary of the recent poll that went on there to let more people -- in a sense of openness, we had a poll of some people, and it would be good -- if that was summarized somewhere. But if that was in the same mail then --

MS. HAMLIN: That also is -- there is an archive of the consultation and it has a link to the actual polling results and the question that was asked and a link to the archive of the consultation list where there was discussion.

MR. CURRAN: Thank you. Okay, microphones remain open for the open policy hour. I will --

SPEAKER: -- time.

MR. CURRAN: We're -- sorry the open microphone session, not the open policy hour, the open microphone session. I will note that at some point we're going to have to be moving because of the social that's coming up, but we still have time now. Center front.

MR. DeLONG: Owen DeLong, Jittr Networks. I wanted to ask the chair if we could, there seems to be some question as to whether the community views it as a worthwhile to outreach towards the legacy holders and bring them fold or not, and I was wondering if the chair could get us a show of hand whether work in this area is worthwhile in the community's opinion or not. So when you say outreach I just want to know what it is you're asking people to participate in. Are you asking who would -- I'm not necessarily asking people to participate in anything. I'm asking if people want to see,
perhaps proposals moved forward towards the focus on the goal of getting legacy holders to join the ARIN fold and bring their resources under the management of the ARIN process.

MR. CURRAN: Okay. I'm willing to -- and I can proceed two ways, and I need your advice.

MR. DeLONG: Sure.

MR. CURRAN: I can ask for show of hands of those people who are interested in this, and that will seem like a vote. And depending on how it comes out you may get discouraged, or I can point out that you and Bob are working on this topic actively and if you're interested in working on it to hunt down, you and Bob, and join forces, which do you want me to do?

MR. DeLONG: I think actually for my purposes right now the former would be more useful.

MR. CURRAN: Okay, then that's what
we'll have. So what we've been requested for is we need to understand whether or not people are interested in having ARIN perform outreach to the legacy space holders, i.e. find some way to actively contact them and engage with them. So if people think ARIN should be working on that topic outreach to the legacy space holders I'm going to ask you for show of hands everyone in favor. I'm going to ask to ask to raise your hand then, everyone opposed. This is a straw man simply for the purposes so that people working in that area understand what level of effort to put in. If you believe ARIN should be doing outreach to the legacy address space holders please raise your hand. Nice and high. I -- thinking this is the last show of hands for the day so you can really put everything into it. Thank you. If you do not believe that ARIN should be performing outreach to the legacy space holders raise your hand. Okay. Thank you. We should probably ask that same
question to all the legacy address holders not in the room. Owen, for outreach to legacy address holders, in favor 28, opposed 6. Okay. Microphones remain open. I'm going to close the microphone shortly. Center rear mic, yes.

MR. MINGS: Yes, good evening, Stanford Mings of VI Technical Services at St. Thomas. First I'd like to thank the individuals, ARIN as well as the group and all the organizations to coming on to the Caribbean and having their meetings done here, both back in February for the workshop in St. Thomas as well as for this meeting. And I don't know if I should be congratulating ARIN for the ICANN meeting that's coming in Thursday, in June, but I will still thank everybody. I'm putting an open invitation out for discussion as well as physical invitation to, basically, everybody who is here to come to the Caribbean.
We're -- because of our geographical location we have a lot of, guess I could say issues, both the geographical as well as lot of companies who have become -- who have been monopolies in the past, companies such as Cable and Wireless in the Virgin Islands because of the Virgin Islands -- because of the SEC rulings on the classification of the Virgin Islands as being a rural entity we're -- we basically have a monopoly. So some recent monopolies seem to have run wild over here in the Caribbean. And I'm basically putting an invitation out to everyone to assist us in basically policies as well as consultation. We have a lot of things that we want to do over here. There is a lot of potential down here in the Caribbean, and I'm just basically putting an open invitation, and I must not forget to let you know that we also have a lot of sun and sea. Thank you.

MR. CURRAN: Thank you for -- thank
you for your invitation, okay. That concludes -- I'm closing the microphones. That concludes the open microphone session, and I'll turn it back over to Ray.

Closing Announcements and Adjournment

MR. PLZAK: Thank you, John. And why don't we get our social slides up here. Two reminders, the meeting -- breakfast tomorrow is at 8:00 a.m., the meeting starts at 9:00. The agenda is in your (off mike). Tonight is the social. It's a 6:00 p.m. The buses are leaving at 5:30.

SPEAKER: From where.

MR. PLZAK: 5:45, okay, the point is --

SPEAKER: From where?

MR. PLZAK: What ever my slide --

MS. HAMLIN: The buses will start loading at 5:30 out front -- in front on the Starbucks. So go out the main lobby to the left and right on the street.

MR. PLZAK: Right. The point is that if you can get there, get there as soon
as possible because otherwise we may run into some severe traffic problems. And for those of you that are used to horrendous commute spaces on different times of the day it could take a while as opposed to taking a short while. I don't know whether it is slides I had here. So we'll just kind of punt and hope to see you all at the social tonight and for sure see you all tomorrow morning at 9 o'clock prompt. Thank you.