ARIN XVIII Public Policy Meeting Draft Transcript - 11 October 2006
"This transcript of the meeting may contain errors due to errors in transcription or in formatting it for posting. Therefore, the material is presented only to assist you, and is not an authoritative representation of discussion at the meeting."
MR. PLZAK: Good morning. Welcome to St. Louis. This is the ARIN XVIII meeting, and so as is customary, I'm going to do the intro to the meeting. And as discussed earlier, I will do a description of facility layout, talk about what's happening this week, introduce everyone, talk about the game plan for the next couple days, and review the rules.
So, first, a quick tour of the facilities. This is the general hotel floor plan, and you -- basically everything is on this floor and pretty well marked and relatively self-contained, so it shouldn't be too hard to find your way around. The General Session obviously is in this room, which is the St. Louis Ballrooms D and E, and the Cyber Café is located across the way, and so, you know, if you need to get together with someone to have a quick conversation or something, you can always just say meet me in the Cyber Café because you're already in St. Louis. So you're meeting them in St. Louis. Featured there though are the help desks for both financial and registration services, and the help desks are open as shown on the slide here. In addition, there's movies and also a raffle going on. So come and visit us, and when you're there, you can drop your name into a tank to qualify to participate in the raffle. We did one yesterday, and it took awhile for us to get a winner because, you know, you've got to be there to do it. Okay. So the winner is going to be announced Friday morning. You must be present to win, and this is the prize. It's a storage link. It's a pretty nice one too. So if you want to get it, be here -- go to the Cyber Café, drop your name into the hopper, and be here Friday morning. Otherwise, Susan Hamlin would love to take it home and use it at home. The help desk, here are their hours, and registration and billing services, and you can go there and meet. They do have private consultation rooms available, and also if you wish to schedule an appointment, you can either do so in person and schedule an appointment for a later time or you can do it by e-mail at the addresses shown on the screen. And the Cyber Café features a lot of things, one of which is those guys. And let's take a look at -- this is the flash presentation of what both of the IRRs are about, and also we have a featured presentation, and in true Hollywood version, we're going to see a trailer. So this rated C and some material may prove to be educational. So it's now playing in the Cyber Café. Please come by and see it. So meeting registration is around the corner. Restrooms are located back in the corner over that way. The break area is next door. And the First Timer lunch for those who are scheduled to be there is in the Rose Garden Room, which is over in that direction. So the First Timers' Luncheon is welcome to first time meeting attendees. It's an opportunity for them to meet with members of the ARIN staff, the Board of Trustees, the Advisory Council members, and members of the NRO Number Council, those that are from the ARIN region, and it's at lunch today. So there will be a First Timer raffle. So if you are a First Timer, and you go there and put your name in and do correct things, you will qualify for a drawing to receive this little digital wireless audio transmitter, and the winner will be announced tomorrow morning, and again, you must be present to win, and again, if no one is present, Susan has something else to take home.
So let's look at attendees. Registered attendees as of this morning for the ARIN meeting is about 169. And this is the general break-out. 45 people are here for the first time. 143 people from the U.S. 29 states. Five people from four Canadian provinces, and we have 21 people here from outside the ARIN region from 12 different countries. NANOG had a registration of about 400 people, and the crossover or the overlap is 103 people have chosen to go to both meetings, which is a nice number and wish it would become bigger.
So tonight, Explore the Unexpected, join us at 7:00 to 10:00 at 701 North 15th Street. The food and beverage will be a buffet dinner and open bar. Entertainment will feature an Enchanted Caves Scavenger Hunt. Of course, we'll have foosball, billiards, and the photo booth, those four guys I showed you pictures of earlier, you'll have an opportunity to have your picture taken with them, and, of course, we'll have a deejay there for dancing as well. So the transportation, pick up your badge at 6:00 p.m. tonight. The buses will leave at 6:30. The first bus will return back to the hotel at 8:00, and then every half hour, a bus will be coming back to the hotel with the last one leaving the social venue at 10:30. After that, you're on your own to get back here before the meeting starts tomorrow morning. So in your bag, what have you got? Well, let's see. Lots of stuff. Well, outside the bag, you've got a T-shirt and a baseball cap. The reason we're giving away a baseball cap this time is that for those of you that have been coming to ARIN meetings for some time, you notice that Bill Darte always wears a baseball cap, and the cap was getting a little old and weather-beaten. So we said Bill, if we get to have a meeting in St. Louis, and you help do that, we'll get you a new baseball cap. So that's why we're giving away the cap this time. But anyway, so also the T-shirt. Some literature about the area. Then in your meeting folder, you've got the newsletter. You've got the Number Resource Manual. You've got the policy discussion information, the proposals, the policy evaluation process, information on the election that we'll be conducting, and a survey flyer, and also the Adventures of Team ARIN Comic Book. So a lot of material there. Some of it is very important from the terms of the process of this meeting, and it is given to you as a reference to make it easier for you to participate in this meeting. And remote participation is available. Web cast and presentations are posted on the web site, and announcements and agenda changes will be posted on the web site as well.
So speaking of the survey, please complete the IPv6 workshop ARIN. The ARIN XVIII survey is online at the URL shown. It's a relatively simple process, and you will earn a raffle entry. One entry per person. So if you fill out 15 surveys, you're not going to get 15 raffle entries, although I suppose somebody is going to try to game it anyway. But anyway, there's going to be one lucky winner, and to the lucky winner is an 8 gigabyte USB microdrive. So let's take a little look around town about St. Louis, past and present. Well, if you were here in the 60s, you saw this happening. They built the Gateway Arch, and it's actually quite an engineering achievement the way they did it, and that's what it looked like. And so I'll let it run through one more time, so you can get a quick check of it. And if you were here -- this is what it looks like today.
So just some introductions. John Curran, the Chair, Scott Bradner and Lee Howard, and that's me, and Bill Manning right there, Paul Vixie, and Bill Woodcock, and off in the corner some place, General Counsel, Steve Ryan. Okay. If -- and I know no one was here in 1904, or I hope not, but that's when the World's Fair was held in St. Louis, and it was also the Games of the III Olympiad. So these are some scenes from those events. And one of the things that they had at that time in the Olympics was a tug of war contest. And so let's introduce the Advisory Council. Alec Peterson, the Vice Chair. Dan Alexander. Please, if you guys are here, just stand up or raise your hand. Paul Anderson, I know is not here. Cathy Aronson and Marla Azinger, Leo Bicknell, Bill Darte with the baseball cap, Mark Kosters, and Matt Pounsett, and Lea Roberts, Alex Rubenstein, and Robert Seastrom, Stacy Taylor. Thank you, Stacy. Suzanne Woolf and, of course, the Chair, Ron da Silva. And actually, the ARIN Advisory Council does not conduct a tug of war. They actually are working together for you. So please take advantage of the members that you have elected to the Advisory Council, and if you have concerns or want to discuss aspects of policies that are being discussed now or some idea you may have for a policy in the future, grab one of them during the social, during a break, in the hallways, or whatever, they're here for you, so take advantage of them.
Anyway, in the 1800s, the Mississippi River, this town was really a booming town. It was a major port on the Mississippi river, a lot of river traffic, and this was not an uncommon scene. Well, today the riverboats look slightly different, and we have the Sandy, the Marty, and the Louie, and, of course, I'm talking about the members of the Number Resource Council that are selected from the ARIN region, and that's Sanford George. There's Sandy. Marty Hannigan. I don't see Marty. Oh, there he is. It's hard to see back there with these lights, and you're wearing dark clothes besides. And Louie Lee. There he is back there.
Today, if you go -- you can see the 1904 Flight Cage, which is part of the St. Louis Zoo, and I'm going to show this to you as I introduce the members that are here from the various IR staffs, and if you look at the pictures along the sides of each of the staff's presentations, you will see animals from the regions where they're from. So from AFRINIC, we have Ernest and Didier. From APNIC, we've got Paul and Geoff. From LACNIC, we have Raul and German. And from the RIPE NCC region, Axel, Nick, Paul, Andrei, Leo, and Filiz. So welcome to our colleagues from the other regions. Again, I invite you to take advantage of their presence here to talk to them about what's going on in the other regions, and if you are curious about a policy or something that's going on in that region, this is a good chance for you to talk to them. So please take advantage of them.
And so what's left is the staff. If you looked in 1914-1917, you'd see a big hole in the ground where they were doing some work, but behind it you see what was then the Anheuser-Busch Brewery, and then you see what it looks like today. So one of the features of this brewery is its marking symbol is a wagon, an old beer wagon, that is towed by a team of horses, Clydesdales, and we're using that as a vehicle to introduce the staff to you because we're pulling things for you. So we have Nate Davis, Director of Operations. And Richard Jimmerson, External Relations. Please stand up guys. Susan Hamlin, Member Services, and Mary K. Lee, HR and Admin. Ginny Listman, Engineering. And Leslie Nobile, Registration Services. And Bob Stratton, Financial Services. And laying around doing nothing is me. So that's the staff. Again, take advantage of us while we're here, and please take the opportunity to talk to us, and we welcome the opportunity. In addition to the Amigos, the directors, there are a number of other ARIN staff members here from various departments, and please chat with them as well. Get to know us better.
And so if you go a few blocks away from here, last year you would have seen Busch Stadium as it looked. It was only like about three blocks or so away, and they've torn it down, and right next to it, they've built the new stadium, and that's what it looks like today. And if you'd go in there today, you'd see our sponsors. There's one of them, Savvis, and Cisco, and Washington University, the Center for Application of Information and Technology. That's Bill Darte's organization. And I couldn't resist doing this, the old public television tag, and people like you, because you are the ones, just by your presence, that help make this process work, and so you are a sponsor in kind, if you will, just by being here and participating in the process. So Vince Lombardi said this, individual commitment to a group effort, this is what makes a team work, a company work, a society work, a civilization work, and, in fact, that's what makes ARIN work.
So here's the game plan for the next several days. We are going to have some information presentations on the Internet Governance forum, a presentation discussing harmonization of IRR practices. There will be speeches. This is the fourth quarter, so you get to hear candidates do their speeches. We have candidates for the Board, the AC, and the NRO NC. Then we have some technical presentations, activities to report on IPv6 from IAB/IETF, one on IP address renumbering, a discussion about what's going on in the producing of a BCP and IPv6 multi-homing. APNIC is going to do a demo of the Cert. We'll talk a little bit about what's going on with CRISP, and we have a presentation by Leo Bicknell about WHOIS By the Numbers, and then we're going to have a round table discussion this morning about a very interesting topic, blacklisting. Policy discussions, three of them this time. One in the area of Directory Services. That's 2006-1, Residential Customer Privacy and 2006-3, Capturing Originations in Templates. And then the other one is in the area of Micro-allocations, 2006-2, which is actually IPv6, and it's Micro-allocations for Internal Infrastructure. The public policy mailing list is the forum by which you can raise policy-related issues and discuss them. All policy issues are discussed, introduced and discussed, on a PPML. Consensus is measured against the PPML, as well as what happens in this meeting, and perhaps that is the more important forum for discussion of policy. And if you're not a subscriber to the PPML, it's very easy to do. Just go to that URL shown. So let's stay in this motif of football, and here's how a proposal is going to be presented today. We'll start off. Here's the play. And as the quarterback, I will take and do a pitch to background of the proposal, and I'll pitch it back to the halfback, who is the proposal author, who in turn will present it and will toss the presentation off to the wide receiver, who happens to be the Chair, John Curran, and he will run the discussion for us to go by. So that's the order of business for those three proposals.
In order to do this, we have to have some rules, parliamentary procedure, and so we are going to have a little pre-meeting warm-up here to discuss those. So you've got to study the rule book if you want to survive the gridiron. So first of all, please be courteous. No e-mail, no surfing. Silence all cell phones, pagers, computers, and other electronics. It's getting as bad as being on an airplane. So rules of discussion, first of all, equal rights and privileges and obligations for all. Full and free discussion. So I'll be interested to see if John can do all these things throughout the course of the day. Okay. One policy proposal at a time please. Speak from the designated spot when recognized by the Chair, and those designated spots are the microphones. State your name, your affiliation, and whether or not you intend to or not to support the proposal. If you don't do this, the Chair will ask you to do it before he allows you to give your speech. And let everyone speak before you get up to speak a second time on a particular topic. And there is a three-minute limit to you getting up and making a speech. This is not a platform for you to run for any type of thing or propose a cause for ten or fifteen minutes. And direct all your remarks to the Chair. No debating or attacking anyone else in the room, across the room debate. So if you have amendments or secondary proposals that you want to suggest, suggest those to the Chair. And lastly, only the Chair may poll participants, and only the Chair will explain what the affirmative and negative responses mean. So those are the rules. And, John, you now have the hand signals to use. So are you ready for ARIN XVIII? I'll ask again. Are you ready for ARIN XVIII?
MR. PLZAK: Okay. On with the show. So we'll start the clock. So first of all, a brief presentation on the new consultation suggestion process. I'm not going to go into a lot of detail on it. It was implemented by the Board, approved by the Board on the 1st of August, and we implemented it on the 15th of December. So it is a communications tools is what it is, and it's designed as a means for the Board or me, the Executive, to consult with the community or the members, and it is also a communications tool by which the community or members may make suggestions back to the Board or to the Executive. It -- the consultation process is going to be used for us to get a sense or consensus of what the community or the members think. If necessary, we needed to put a question to the members, we could use this process to conduct a vote of the members only. And the consultation process will take place via e-mail discussion. The suggestion process is designed to be a simple method for process and practice questions to be asked or suggestions to be made to the way ARIN does business. It is not, and I say this very strongly, an alternative to the policy development process. This is not a shortcut. This is not another way to get a policy change made. This is a way to take process and practice questions to staff and to the Board, and it may be something that the consultation process gets called into play. So, for example, a suggestion may be made and either I or the Board may decide, hey, we really want to get a bigger sense of what the community thinks about this, so in turn we would turn right back around and use the consultation process for it but this is what it's about. You can read about it on the web site. And so with that, I will now call on Counsel to come up here and give a brief discussion of some legal matters. Steve. That's Steve Ryan, General Counsel of ARIN.
MR. RYAN: So why is your lawyer talking to you? Let me tell you that there's been a development that we wanted to share with you. As we were leaving Montreal at the last meeting, on the evening that we were flying home, ARIN was sued in California, and we wanted to share some of the information about that with you. This has been the first time literally that we could do so in a meeting capacity; and so as part of our open and transparent processes, we thought we'd let you know that we had been sued in a major way. And let me talk briefly about what has occurred and what we're doing about that. The story is actually a little bit convoluted. It begins in 1998. There was a man named Richard Kremen who is a cyber squatter who had squatted on a name called Sex.com, among other things that he owned. His Sex.com domain name was stolen according to him by a man named Cohen. Mr. Cohen hijacked that and disappeared to Israel and other places in the world, and a lawsuit between these two gentlemen ensued. Mr. Kremen was the person aggrieved. In 2001, unknown to ARIN and without any notice to us, on a day in the course of this lawsuit, the United States District Court in San Jose issued an order, ordering ARIN to turn over certain IP resources that Cohen or people that Mr. Kremen and the court believed were associated with Cohen had obtained from ARIN. No one has ever said that ARIN acted improperly in issuing resources, but what they were, in essence, saying in the court order is that Cohen used money that had been Kremen's to obtain the resources, and in lieu of the money, we were to transfer the resources to Mr. Kremen. So if you've got that, Cohen is the bad guy, according to the court. The court issues an order without ARIN being there. A court order tells you to do something. Well, in 2003, in December of 2003, I had been General Counsel for you about 30 days at that point. We received the order approximately two years after it had been issued. It was provided to us in a formal way, and Mr. Kremen asked us to obey the order. That is, to revoke the IP resources that were held by Mr. Cohen and transfer them to Mr. Kremen. We agreed to do so, so long as Mr. Kremen would do what all of you have done since ARIN began in 1998, which is apply for the resources and sign the normal RSA. Mr. Kremen refused to do that and has refused to the current date. His theory is that he doesn't have to do that because he has a court order, and our theory is that we have a certain set of rules and requirements, and that you have to obey the rules and requirements of the community, and we don't read the court order as giving Mr. Kremen a permanent pass from the rules that all of you obey. We've tried to be very cordial with Mr. Kremen. We believe that Mr. Kremen may have been badly treated by Mr. Cohen, but he certainly has never been badly treated by us. During the time that we've been negotiating with him, we agreed to what was called a standstill order, that there would be no court activity while we negotiated. We turned over thousands of pages of documents within ARIN's control to help him find assets that Mr. Cohen might have had. We revoked resources that were held by Mr. Cohen or his associates that were covered by the 2001 order when they were not paid for. In other words, by our own processes, we were very aggressively trying to recover these resources so that they weren't out there. On the other hand, we ultimately could not reach a conclusion with Mr. Cohen -- pardon me -- with Mr. Kremen because he refused to sign the paperwork even if we filled it out for him. What happened in 2006 is that Mr. Cohen was arrested and extradited to the United States, and we had hoped that by that extradition, that this matter -- that the tension over the matter would go away. We were wrong about that. In April, ARIN was sued by Mr. Kremen, and Mr. Kremen's fundamental issues are not just that we didn't turn over the resources to him. His theory is that this room is an unnecessary and -- unnecessary place to be. He's never been to this room to talk about policy, but his argument is that IP resources are actually property. They're like domain names. They're like a Ford LTD. They're like this computer screen that's sitting next to me. They are a piece of property that can be owned. And, of course, that's not consistent with the entire theory by which the internet community governs IP resources. Fundamentally, he wants to create a market and argue that if you hold IP resources, you are the owner of property, just like a Ford LTD, rather than that those IP resources belong to the internet community, that they are issued by an RIR, like ARIN, to you, but that they can be revoked if you use them improperly or if you don't pay for them, and then they can be reissued to another person who is in need of them. So he's fundamentally attacking the process that we have in his lawsuit. He's claiming that we are an anti-competitive conspiracy that offends Federal Antitrust Law and that offends California Fair Trade Act, and so we are involved in a major piece of litigation with him. The status of that litigation is as follows: He filed a complaint against us in April. ARIN has aggressively responded to this. Where we had been cordial and respectful for the past three years in negotiating and seeking a solution, now that we've been attacked, and we believe improperly, we are defending that lawsuit vigorously, and that was a decision that the Board made. With regard to that defense, we have two issues that we have raised. First, we've gone back to the court and said that the court in its 2001 order ought to consider modifying the order to make it clear that Mr. Kremen, like everyone else, has to sign an RSA and has to pay for the resources in the future. Second, we filed a motion to dismiss his lawsuit. Now, a motion to dismiss a lawsuit is a motion that is disfavored in law. The way that the court is required to look at a motion to dismiss a lawsuit it has to presume, the judge has to presume, that everything that the plaintiff said is true. Even if, for example, it's not. So, for example, Mr. Kremen has claimed that IP resources are property, the court has to accept it as true simply because he said it. Notwithstanding that, we filed a motion to dismiss, and we are awaiting oral argument. I will be arguing this case on October 23rd, a week from Monday, in United States District Court in San Jose. And for those of you -- there's no reason why you would know me, but I've been an Assistant U.S. attorney. I grew up in courthouses. This is what I do. And so I'm going to argue the case myself. I happen to be a litigator, and I'll be arguing that with a team of lawyers. It's a very complex case. I would say that the pleadings in this case now would be about this high. We've spent hundreds of thousands of dollars responding to this over time and dealing with Mr. Kremen. So those two aspects, the change in the 2001 order and the motion to dismiss, will both be argued on the same day. So I really want to say a couple of things from the heart to you. One is that Mr. Kremen is a legacy address holder. He has legacy address blocks. He understands the game of IP resources very well. He's never participated, to our knowledge, in this process of coming here and saying that anything about the ARIN community is proper or improper or arguing that we should have a different policy process. In effect, his lawsuit invites the United States court to substitute a legal process for what you do. Second, right now, you know, Mr. Kremen is a man who has very, very significant resources. He has investigators. He has a team of lawyers that, frankly, are very talented. You know, you can get very good lawyers if you have money, and we are involved in very serious litigation. So what I'd like to do is to suggest that I'm here now to answer your questions. I'll be glad to answer them on the record in the room. I'm glad to have you catch me in the corridor, but I need you to understand that we are under legal attack, and just the very fact that we would do this in an open forum, I think, talks about the values that we have in this room that we try and deal with one another as adults, we try and work out the issues of the future of policy in this room. This is a fundamental attack on the policy process. That's -- you know, you should not misunderstand what this is about. It's fundamentally asking that the current rules that we've developed for the community from RFC processes at the IETF to all of the things that you do will not be the way that we go forward. I need you to be thoughtful about what's happening on public policy lists during this period. Some of the threads of public policy lists emanating from this lawsuit will likely end up in court. So be thoughtful about what you say and what you do on lists as you address these things. Everyone, of course, should continue to express how you feel about the public policy process. The public policy process in this meeting will go forward, notwithstanding that there's a lawsuit addressing fundamentally these issues. So we wanted you to know this. I really appreciate the Board and Ray suggesting that we take this head-on and tell you about it. I think some of you had seen a list activity related to this. If you have any questions or if the Board has any comments, I'd be glad to take them right now and, you know, answer them as best we can.
MR. CURRAN: Microphones are open. I see Ole.
MR. RYAN: While you're coming to the microphone, let me just say, we will keep you updated about this. I want to be very clear about this. I don't know if the court will rule from the bench. When we say rule from the bench, that the court will make a decision on October 23rd. If the court does, whether that decision is good or bad from my perspective, we'll certainly share with you any of the court's decision and our commentary on that. It may well be that the court will take the matter under advisement and think about it, and I now have grown hairless thinking about when judges will decide things. I have one case that's now pending for 21 months since I've argued it. I obviously confused the judge that day because's he's not quite sure what to do with it. But I can't tell you a timetable of when the next milestone will occur other than the oral argument on the 23rd. Sir.
MR. CURRAN: Name and affiliation.
MR. JACOBSEN: Good morning, Counsel. I'm Ole Jacobsen with Cisco. I was just wondering if the information about the thing in San Jose would be posted somewhere since I assume a fair number of the people in this room are kind of sort of in that area. Are we allowed to come listen?
MR. RYAN: Yes. The court is open. It's before a Judge Ware, W-A-R-E, in his courtroom in the San Jose courthouse at 9:00 a.m. on Monday, October 23rd, and I'd be delighted, by the way, if, for example, Cisco's legal officer, you know, sent a lawyer, if people in the Valley -- you know, I think it's very useful for you to actually observe these things, and, frankly, for the people who are engineers, it might be very interesting to see how the legal system addresses fundamental issues which you understand but which will be new to the judge.
MR. JACOBSEN: So it's not like sausage-making?
MR. RYAN: Well, as an officer of the court, I'm not going to answer that question.
MR. CURRAN: Any other questions?
MR. RYAN: There's one other issue. We have every reason to believe that because Mr. Kremen is a very colorful individual and his fight with Mr. Cohen has been this is the sort of stuff that you write interesting articles about, that there will be press interest in this issue, both because of the colorfulness of the people that are involved and also because of the fundamental IP issues to the extent that the press understands the second issue. It will probably be the former issue that generates press coverage. If you find out that reporters are calling around on this, I'd be very interested in knowing that. We obviously have our own views on what we would like to say to the press that may be not unlike what I told you this morning. So if you could let ARIN staff know if the press is contacting you on this, it will be so that we can call them affirmatively and let them know our views on the subject. You know, you might get called by the press, you know, as they're doing a story on this as they're trying to understand what the IP issues are.
MR. CURRAN: Okay. Steve, thank you for your time. Oh, Sam.
MR. WEILER: Sam Weiler, SPARTA. I'm not quite sure what to make of your request that we be thoughtful in our mailing list postings. I'm wondering if you can be a little more concrete. Is there anything you'd like to see the community do, say in our public policy process, to help ARIN -- to help the community defend this process.
MR. RYAN: Well, look. I'm not here to coach you on how you feel about the public policy process, any of you. You know what I mean? I think by your very presence in this room, you say that this process is a valuable one. That process is under attack. You can make your own conclusion about how you want to address that. And let me say this. We live in a grown-up world now. Okay. When I go home at night, I may be -- I go home to my family, and they know my good points and my bad points. We're family. We know ARIN has good points and bad points. When you're fundamentally attacked, you have to decide whether, you know, it's time to focus on big picture points. Is the public policy process an important thing? Is the way we govern the internet something valuable? Do we want a market in IPv4 and IPv6 where people sell it on EBay as opposed to distributing it based on requirements that the community sets. In this sense, Sam, you know, if you want to -- if anyone wants to support or criticize ARIN, I just ask them to be aware that there's a lawsuit on that fundamentally attacks us, but, you know, we're not thin-skinned. You can still say things that are critical of us, if that's how you feel. This is a democracy, and this is a fundamentally democratic process in this room. If you believe that you want to defend that when you're responding, be my guest. I hope -- Sam, thank you for the -- frankly, I appreciate being asked that question, and I hope that that is helpful in answering it.
MR. CURRAN: Any other questions for Counsel? Okay. Thank you very much, Steve.
MR. PLZAK: All right. As a reminder, Steve said he would be available for the next two days if you want to engage him in a conversation in the hallways or whenever. And so if you had some questions and you didn't want to express them here this morning, he would be still glad to meet with you and discuss these matters with you. So on with the meeting.
MR. PLZAK: The first thing on the docket is the Number Resource Organization Number Council election. And so what is it? We have one open seat. It's the seat that is currently occupied by Louie Lee, the incumbent. Who can vote? Everyone who is registered to attend ARIN XVIII can vote. In addition, all ARIN members have been given an earlier opportunity to vote. The voting booth is open today. It actually opened at 8:00 this morning, and it's open until 4:00 this afternoon. And where is the ARIN election headquarters? At the URL shown on the screen. At the election headquarters, you will find the voting booth. You'll find the biographies of the candidates, and you will find statements of support. So who are the candidates? They are Pervez, Louie the incumbent, and Jason. And I don't know if all three of them are present or not. Pervez is not here. Okay. In the interest of fairness, here's his motivation statement that he has made. He says, I have been conducting business related to the internet for the last ten years and would like to share my ideas to help build ARIN into a stronger organization for many years to come. Below that is a brief summary of his biography. I won't bother to go through it. I will call your attention to the fact that this information is all presented at the ARIN election headquarters, and I strongly encourage you, since Pervez is not here, able to be here to make a presentation on his behalf, that you go to the web site and read about him. Next is Louie Lee. Louie, are you here? Louie, you can come up here and say a few words for a couple minutes, and I'll leave on screen your motivation statement.
MR. LEE: Thank you, Ray. If you don't want to go on site or you don't have your laptop, you can also pull out your packet, and you'll find the information from that web site near the back of that, and I have a page. And on the record of service, you'll find stuff you can blame on Louie, stuff you can't blame on Louie. One of the things you can blame on me is the, hopefully you don't find too distasteful, the campaign that I've been pulling with the buttons and the T-shirts. So let's see. Well, I've been on the NRO NC for one term now, three years, and I've been the pen for the group for much of their documents that they issue out to ICANN and also to the community that has served the group well, and the group supports my re-election, and I hope you do too. So please vote for me. Thank you.
MR. PLZAK: Thank you, Louie. And Jason, are you here? There he is.
MR. SCHILLER: So for those of you who don't know me or have only seen me in these public forums, you know that I've talked a lot about IPv6, but I wanted to tell you a little bit about what I do in my day job. Yes. I am working for Verizon Business, and I am working on their IPv6 roll-out with two other engineers, but that's really not my lead project right now. I'm also doing a lot of v4 work, changing our BGP architecture, changing our MP less mesh architecture. Right now, I'm looking at AS integration. So I'm not just a v6 guy. I'm also a v4 guy. I think that in the future, there's going to be a lot of new policies that are going to need to be figured out for v6, and that's very important. But I also think there's a lot of work to be done in v4 as well. We need to figure out how to transition. We need to figure out how to continue to support v6 and v4 together and how to deal with v4 exhaustion. And I think the NRO is a very important vehicle. It's a place where we can look at our global policies, unify things, and do things that are good for the stewardship of the internet. And as a Tier-1 ISP, I have a lot of insight as to what's good and bad for the internet, for the ISPs, for the internet as a whole, for the routing table, for our customers. So I think I'd be a good candidate for this. So please do vote, vote today, and thanks for your support.
MR. PLZAK: Thank you, Jason. So, what is the board voting procedure? It's actually three very easy steps. Go to this URL, and you first register to vote, and you do that by creating a user name and password, and what you need to have is your first name, your last name, and the e-mail address that you used to register for ARIN XVIII, then you vote. You vote only for one candidate, and you can only vote one time. And this is the one time when you figuratively put your name in a box that you're not going to get a door prize. What you're actually going to get is a person who is willing to work for you for the next three years on the Number Council. And lastly, you will be asked to confirm your vote. So that's it. It's very simple. You can do it in here. So instead of surfing the web for awhile, if you want to while you have your laptop out in front of you, you can go ahead and vote. And again, a reminder, you have from 8:00 a.m. this morning to 4:00 this afternoon to vote. And if you have any questions, please stop by the ARIN registration desk or send an e-mail at email@example.com, and you will receive a prompt reply. So with that, I say thanks. Okay. Moving on.
MR. PLZAK: The next item on the agenda are the Regional Policy Updates, and for that, I will call up Einar Bohlin, and I will say it before he says it. Einar Bohlin, our Policy Analyst.
MR. BOHLIN: Thank you, Ray. Yes, I am Einar from ARIN, and this is the Regional Policy Development Process Report. So essentially it's an update on discussions and developments policy-wise at the other RIRs, and it's since we last met in Montreal. I'll be talking about several different areas, IPv4, IPv6, AS numbers, directory services, and a couple other policies. So to begin, IPv4, the first item here is 12-month allocation period. So essentially here in the ARIN region, we give out IP space to ISPs for three months. In the LACNIC region, they're moving forward with allocating -- for subsequent allocations, allocating for 12-month needs. And then in the RIPE region, they're discussing moving back from two years to one-year needs. Second item is PI assignment size. In the RIPE region, they're discussing setting /24 as the minimum assignment size for multi-homed end users. Micro-allocations for critical infrastructure is being discussed at LACNIC, and RIPE has moved forward with their policy for address space for TLDs that do anycast services, and this would be a /24 in v4 space or a /28 in v6 space, and that's for generic and CC TLDs. Some more v4 discussions include two from AFRINIC or actually policies that have moved forward and been adopted. AFRINIC has adopted an end user v4 assignment policy, which can get you a /24, and they've adopted a temporary assignment policy. It includes not only temporary needs for things such as making convention or conference like this, but also includes experiments. And LACNIC has moved forward with a resource recovery policy. This one is essentially there are two criteria that need to be met. The first one is that the resource is not seen in the routing tables for a year, and the second criteria is that it's not being used. So if those two things are met, then they attempt to recover the space. Moving on to v6. The HD-ratio has been changed and is under discussion, as you can see here. APNIC and LACNIC have adopted the.94 value, and RIPE is discussing that. The next item is changing the way IP address space is assigned by ISPs or LIRs to their customers. It deals with opening up /56s as an assignment size basing utilization on their /56 assignments, and that's moving forward in the APNIC region, and it's under discussion at LACNIC and RIPE. I already mentioned the address space for anycast services. This is the v6 side of that policy. All right. Everybody's favorite, it seems. PI assignments for end users. The first one I'll point out here is the APNIC policy. They're moving forward -- or it's in last call rather -- with a policy that would allow the assignment of a /48 multi-homed. That would be right from APNIC to end users. Then there's a -- there's a policy from the same author at AFRINIC, LACNIC, and RIPE which would allow the registration of a /32 for a certain amount of time. It's -- I think it's three years from the point where there's a solution for multi-home. And I have RIPE times two here. The next one isn't PI per se, but what it does is it's easier to explain the current policies that you have to be an LIR and not be an end user to get an allocation, and this other policy -- this other proposal at RIPE would do away with not being an end user. So you could just -- you just need to be an LIR. And finally in the v6 world, there's a -- there's some work being done in critical infrastructure. AFRINIC has a new policy. They don't have -- they haven't had one in the past and they're creating a new one. It's under discussion. And APNIC is modifying their existing critical infrastructure policy, and this would allow -- or limit rather -- an operator to one /32. Moving on to AS numbers. The 4-byte AS number proposal has moved forward in APNIC, LACNIC, and RIPE, and it's under discussion in AFRINIC. Next topic is directory services. The first item here, contact e-mail requirements. This is basically a proposal that requires accurate and up-to-date information in the database. It's under discussion. And WHOIS privacy in the LACNIC region. This one is -- it would allow ISPs to essentially choose to only have the customer name and prefix displayed in WHOIS. That's under discussion. A couple other proposals here. APNIC is discussing changing or redefining what lame delegation means. They have an existing policy, and they're just bringing their definition up-to-date. And the last one allows me to say a word that I don't get to say too often, improve reachability of new IANA blocks, and the word is de-bogonization. This word is to cleanse somehow the blocks that IANA gives to the RIRs, and it calls for cooperation among ISPs and RIRs to make that happen. Here are some references. Here you can find the entire proposals and read them, and I'd like to remind everybody that like ARIN, everyone in the community may participate in these discussions. So if you have questions about these things, like Ray said, we have colleagues here from the other RIRs, and they're very friendly, helpful people, and I'm sure they'd be glad to help you. Thank you.
MR. PLZAK: Any questions or comments for Einar?
MR. BYARUHANGA: Ernest, from AFRINIC. I wanted to clarify that the 4-byte AS number policy is actually awaiting Board approval from AFRINIC. Thank you.
MR. BOHLIN: Thank you, Ernest.
MR. BUSH: Randy Bush, IIJ. The policy regarding HD-ratio, the one that is in process and has been in consensus would be APNIC region. I'm one of the two proposers of it, by the way. It is not to change the assignments. It is to say that instead of standardizing on the /48, do whatever you want. But what that meant was we no loner had a basis for how to calculate HD-ratios. So we're saying that whatever you allocate, we're going to view it as how many /56s that is for the purpose of calculating HD-ratios. It is not saying you should assign a /56. It is not saying you should assign a /312 or a /14. It's saying assign what is appropriate, but for the purpose of calculating HD-ratios, it will be viewed as how many /56s it is.
MR. BOHLIN: Thank you for that clarification, Randy. That is what we have here in the ARIN region. Thank you.
MR. PLZAK: Thank you very much, Einar. Okay. Moving on.
MR. PLZAK: I would like now to call on Leslie, wherever she is, to present the Internet Number Resource Status report. Leslie.
MS. NOBILE: Good morning everyone. A quick report on the joint stats. So this is pretty fresh data. We had to update it quarterly. It was updated as of 30 September 2006, and this data goes back to 1999. That's when we started collecting this and what will be displayed in the presentation. So this is probably the more interesting of the slides. It shows a current status of all IPv4 address space. I'm going to start in the bottom right corner, which is the space that is not available for the various reasons listed right there. That is being held in the IANA at this point. On the left side is the space that has been allocated or that the RIRs are currently allocating from. So the big gray bar is where most of the legacy space resides. There's 94 /8s. This was issued by the pre-RIR organizations, the SRINIC, the DDMNIC, et cetera. And then you see each of the RIRs, the amount of space that we currently have in /8s, ARIN having at this point the most IPv4 blocks from the IANA and, of course, the available space. It says the IANA reserved is right now 59 /8s. That number changed last week. There are now 55 /8s remaining. ARIN was issued four /8 blocks by the IANA last week, last Wednesday I think. So there really are 55 /8s remaining in the entire v4 space pool. So this is v4 allocations from the RIRs to the ISPs only. It's a yearly comparison. You can pretty much see the growth trends. At this point, what's most interesting is there's quite a bit of growth in the three larger RIR regions in the past couple of years, and APNIC and RIPE NCC are both issuing more address space at this point than the ARIN region is issuing. That is displayed more clearly in this slide. This is the cumulative amount of space that the RIRs have, and at this point RIPE and APNIC since 1999 have issued more space cumulatively to their customers than ARIN or any of the other RIRs. This is the ASN assignments. Again, just up and down growth trends, pretty steady decline in the ARIN region in ASN assignments, but as you'll see in 2005-2006, the RIPE region has really picked up on ASN assignments, and they are now assigning more ASNs than ARIN. Of course, overall ARIN still has the large chunk of the pie, but that is changing, as you can see. RIPE has a very big chunk as well. So ASNs are increasing in the RIPE region, and decreasing in the ARIN region. This is the IPv6 allocations to the RIRs from IANA. As you can see, RIPE has received the most /23s from IANA at this point. They are seeing the most growth in their region, and they have a 198 /23s worth of space, and I can tell you that they are issuing very large allocations in that region. This is part of the reason that that number of 198 exists. They are also issuing many, many allocations from IPv6 in their region. So this is the growth yearly from the RIRs to the LIRs and ISPs. It's a pretty steady growth in all the regions, but the RIPE region has peaked. In fact, 2004 was a really high year for them, and things are slowing down a bit. I don't know what will happen, we'll see, by the end of this year, but we're all experiencing some steady growth in IPv6 allocations. And there's the pie, the cumulative total, and you can see RIPE has issued the most IPv6 space. They have quite a big chunk of the pie there. But, you know, it is growing in all the regions. You can see that pretty clearly. And if you're interested in doing statistics research on your own, these are the links to all of the historical data and RIR stats, and this presentation is up on the web. So you can get these links later on. Are there any questions about this? No? Okay. Thank you for your time.
MR. PLZAK: Okay. We've been more than efficient. We are 20 minutes ahead of schedule, and I know they're not ready to do coffee quite yet, and I'd hate to lose the time when we'd probably want to make it up later.
MR. PLZAK: So Lea, could you do that presentation from this afternoon this morning? Okay. On the agenda, you see a 2:00 p.m. IAB/IETF activities report that would have been presented by Thomas Narten, and Thomas, unfortunately, was unable to get here, and so Lea has graciously volunteered to present the report for Thomas. So I'll put her on the spot and ask her to come up here early, and putting staff on the spot to get it queued up. So Erika is doing all kinds of stuff here.
MS. ROBERTS: Okay. This should be exciting. Just as a point of reference, I have looked at these slides, but I was supposed to talk to Thomas later about clarification of some of them. So when it comes to the questions slide, I may or may not have an answer. So I guess it's not up yet. So I'll just kind of kill time. Anyway, basically Thomas Narten has put together a deck of slides that references various things going on in the IETF, and here they come. Okay. First, in the SHIM-6 working group, he's pointing out that you can find out things on the tools IETF work site. They have a lot of fancy tracking stuff relative to the working groups these days. So in the SHIM-6 working group, there are three core documents that are in the working group last call state. You can see the names there. Once they pass the working group last call, they go on to IETF last call, and then to IESG for further consideration and approval. So if you have any further comments on SHIM-6 or want to look at these documents while there's still a chance to comment. There is your time. The IPv6 working group is in a sort of winding down or I guess maintenance wrap-up mode. They haven't had any IPv6 working group meetings at the IETF meetings in almost a year, and there are three documents that are sort of finishing up in the IPv6 working group, as you can see listed here. There's also Thomas's document, RFC 3177, talking about moving past the /48 boundary. We talked some in Montreal about getting that as a working group document but didn't reach a consensus there, and so Thomas hopefully will be able to follow-up in San Diego and keep this document alive. He mentions here also the centrally assigned ULA document, which is an IPv6 working group document is still in the hold state. So if anyone wants to revive that, better work fast. V6 operations, this is where a lot of things are happening relative to IPv6 these days. There's an IPv6 document, just a new revision active in the working group still. There's a bunch of other documents here that are currently in the IESG various stages of process. So here are some more documents at the IESG level. The soft wires working group has a number of active documents, and one of them has reached the IESG. There's some other DNS-related documents from the DNS operations working group. A lot happening there in DNS op. And here's more DNS, DNS extensions working group, one in the IESG and a number of DNS sec active documents. The grow working group has an RFC that's come out on BGP meds. There's anycast services document in the IESG and some active documents there as well. And the security working group here has a couple -- has one document in the IESG and one active in the working group. Two more too. And the next IETF is in San Diego, November 5th through 10th. There will be BOFs there that you can look up. So are there any questions?
MR. CURRAN: Questions on IPv6 IETF/IAB status?
MS. AZINGER: Marla Azinger, Frontier Communications. I'm hoping I heard you wrong because the v6 working group ops is active. I had a meeting with the working groups op in Montreal. I know the only people that went to this meeting happened to be the people that bothered to respond on the v6 ops e-mail list. So it might not have been published as one of the official meeting rooms. It wasn't an appointed meeting room that was published on the list. But the group is active, and they are working on it.
MS. ROBERTS: I think maybe you're not hearing me clearly.
MS. AZINGER: Okay. I was hoping that was the case.
MS. ROBERTS: There are two working groups that are separate. One is the IPv6 working group, which was the working group that followed on from the IPNG working group that worked on all the IPv6 core documents for the protocol itself, and that one is the one that's kind of winding down. They've declared the IPv6 protocol is finished in it's current state. Obviously there may be some extensions needed in the future, but the original protocol specifications are complete, and so they're not having active development in that group. That's IPv6 working group. The group you're referring to that we attended in Montreal is v6 ops, and that's where the draft you're writing will -- that Fred Baker is the working group chair.
MS. AZINGER: Right. Okay. Sorry. The way I heard it real quick is that they weren't active. So thank you for clarifying that for me.
MS. ROBERTS: So v6 ops is very active.
MS. AZINGER: Okay. Thank you.
MS. ROBERTS: There's a lot of ongoing operational-related documents for IPv6 that are being developed under v6 ops, and while it's not listed on here, Marla will be talking later about her multi-homing VCP that she's been working on with Fred Baker, who is the working group chair of v6 ops, and that should present some interesting discussion certainly later on when that topic comes up again or already did come up at NANOG, and I'm sure many of you remember that from having been at the NANOG meeting. Jordi, go ahead please.
MR. PALET: Jordi Palet. I can add a little bit more information, which I think may be interesting for some people. The first question is regarding the IPv6 working group. It's closing down, but the last thing we are doing also in this working group, which I think is quite important as generally is not done in IETF or has not been done for other documents, is to make sure that all the RFCs move to standard. So the recent web page information about that process and information about which products and services support the ready RFCs that we want to move for standard is IPv6-2-standard.org. So you will find there the work that has been done. That's the first question. Second one regarding (off mike). I just want to say that this is very important work because during many years when we have been trying to find, let's say, a perfect solution, something like one fits all for (off mike), and finally we find out that we have been there already, it's being implemented in many operator networks, which is basically L2 turning protocol, L2TP, and so basically the work of (off mike) is based on that. And last of the comments, the resource for the people interested in SHIM-6 as part of (off mike) commission funded project, which is working in what we call routing and next generation, so looking to -- is BGP something that we can, let's say, enhance or complement to fulfill the needs for the future or we need to work on a new routing protocol from scratch or there is not a problem and the problem is how we are using BGP or whatever. So this project will have a web page hopefully by the end of the next week, which will be ISD-ring.org. Ring stands for routing in next generation. And there is already part of this web page working, which is related to SHIM-6. So you can look for SHIM-6.org, and that's part of this work already. That's it.
MS. ROBERTS: That's great. Thank you, Jordi. Any other questions in the IETF arena? Okay. Thank you very much.
MR. PLZAK: Okay. Now we will break for our morning break, and so please be back here at 10:50 for the blacklisting round table. So I'll see you then. (Recess)
MR. PLZAK: Okay. Let's go ahead and get started. The rest of the morning up to the lunch break is going to be a round table discussion by the panel that you see seated before you to discuss blacklisting. And I'm going to just introduce the panel members by name. And then allow them to provide to you any additional biographical information that they would like you to know about and why they're interested in this topic and any other background information they want. I don't think I really have to describe what blacklisting is or to really go into a discussion of its impact and the fact that -- and why it's there and everything else like that. I think that everyone in the room pretty much knows it. But there are a couple implications for ARIN as an organization and ARIN as a community about this activity, and it also could influence some things that we do in the future in the policy arena. So having said that, we've assembled the panel to discuss this this morning and to provide some thoughts to you and to get some feedback from you. The chair of the panel will be John Curran, Chairman of the Board of ARIN, and then in alphabetical order we have Don Blumenthal. Don raise your hand please. Adam Brower, Katie Flowers, and Rob Seastrom.
MR. CURRAN: Good morning. It's important from time to time for ARIN to explore issues that may be relevant to how we do things of IP Registration services. Here's a case where on occasion we hear people say ARIN should get involved, not get involved, very strongly get involved, very strongly run away from issues relating to blacklisting of IP blocks. So we've gathered this illustrious panel to discuss the topic. Each of the members of the panel were given a handful of questions. What I'm going to let them do is each one address those questions in a five or ten-minute set of answers, and then we'll open it up to general questions to all the presenters. So I guess I'll go to Rob Seastrom first. Rob, do you want to introduce yourself?
MR. SEASTROM: Sure. I'm Rob Seastrom. I on the ARIN Advisory Council. I'm a consultant to various ISPs. I've worked in a production environment for your traditional dial-up and DSL ISP (off mike) where we were running a whole bunch of mail servers. We've both used RBLs and found ourselves on them every so often.
MR. CURRAN: Okay. So I'm going to ask you what's the value of blacklists, how do they benefit or hurt the internet community, what's the implications as you see it for ARIN, and is there -- is there anything ARIN should or shouldn't be doing in this area?
MR. SEASTROM: Okay. Briefly, to the question of whether blacklists provide value to the internet community, I think that's pretty clear that they do. Otherwise nobody would use them aside from a few people flailing away, and I think that their use is pretty widespread. I use them myself on my own e-mail servers. So I took a randomly selected date, that would be yesterday, and did a little bit of analysis on what blacklists were doing for me. Had 10,000 attempts to deliver e-mail to me. And in order I sort of -- I look at whether there's a bogus hello, which I rejected 90 people for. 4,362 attempts. That's almost half. That's like 42 percent, I guess, fell to being on some sort of RBL. 5,144 fell to wait listing. And that breaks down to 2,200 door rattlers, 406 new records that eventually passed as mail, and the balance was other. So the total that actually finally got delivered was 1,031. So that sort of breaks down to us having about one message in ten actually getting delivered. Some of that is spam, especially because of a problem that we haven't fixed yet. So if you take a look at that overall, it looks like, and obviously some of these mask the effect of others, right, because they're evaluated in order, and only one of them -- it would only take a hit on one of them to get the message disqualified. But blacklists are right up there near the top that are responsible for basically around 40 percent of what we reject. So it's very definitely part of a well-rounded antispam policy. Now, it terms of the impact that it has to you, it's certainly a double-edged sword. I consider the reduction of spam to overshadow the operational impact that I run into every so often where someone tries to send me mail, and they end up calling me on the phone saying, why am I getting back access denied and it thinks I'm a spammer. Well, the problem is your ISP levels. I'm sorry about that. There's nothing I can do about that, get another ISP or something. It becomes a bit of an operational hassle. Of course, when you, yourself, and the ISP gets listed, and getting off of that can be a nontrivial exercise, depending on the RBL that has listed you, and, of course, when you are making decisions on your own mail server, you have the choice of sort of there's a bouquet of RBLs out there that you can choose from, and some of them are more enthusiastic about who they list than others, and some of them are harder to get off than others. So you sort of want to pick and choose carefully so that you aren't using one that's too aggressive for your -- for the local policy that you want to implement and also aren't leaving any money on the table, so to speak. But you don't have that choice when it's other people who are complaining -- when it's your customers who are complaining that they can't get mail through to other people because they're using some other RBL. So getting off of that can be tricky. Some RBLs require burned in offerings to get off, which in the modern form take the form of donations to a charity of their choice. Some require demonstration you're actually doing something to fix the problem that you have. In our case, we've had people ask us to add spam assassin filtering to the mail outgoing as well as the mail incoming that we have. We took the proactive approach on our own of having a top talkers list and investigating that on our own before anybody ever contacted us. Although sometimes the time lines that it takes to actually implement that is not something that the RBL actually cares about or has an appreciation for. So it can really put you in a tight spot. Some of them actually believe that the listing is a punitive thing and that you ought to be dealt with slowly, if at all, if you have a complaint. On the other hand, they may just have a manpower shortage because they're an all-volunteer organization. So it is fraught with impact in various cases, but the overall value proposition is positive. So the last question, I've sort of been answering my questions out of sequence here, sort of a flow of consciousness, is what are the impacts on address assignments, and my answer to that is there are really two forms of address assignments that we're concerned with here. One of them is intra-ISP where the ISP is reassigning addresses. That's the, oh my goodness, I've signed up for this ISP and, you know, I have this block of addresses, and I can't send any mail because it's on eight or ten different RBLs and this e-mail and, you know, everyone thinks I'm a spammer, and I just got this address list, so what do I do. Well, that's a problem that really needs individual contact between the ISP and the RBL because that's sort of outside of ARIN's purview. But it has the additional problem that the ISP, you know, could be a pink ISP, it would really be something where you'd sort of need to be reputation based on the individual ISP that is reassigning the space. So inter-ISP is a pretty easy and straightforward thing. Anybody who is looking at this from the standpoint of an RBL operator should be more than capable of taking a look at the last modification date or the assignment date on the block of address space and saying, well, this reassignment happened and ever since that reassignment happened, we haven't had any complaints about it, gee, maybe it's a new organization. Well, without having access to ARIN's or any RIR's database of who it was, there's no real way to say for sure, and I think one constructive thing you might do as an RIR would be to just publish a list, a date-stamped list, of when we reissued address box, and if an RBL cares to monitor that, they can take our word for it since RIRs tend to not be spammer-friendly and take us on our word that this resource no longer belongs to the people that it belonged to before. So thank you for the opportunity to put forth a few opinions on that. Thank you, John.
MR. CURRAN: Thank you, Rob. Katie Flowers.
MS. FLOWERS: As I said, my name is Katie Flowers. I am the team lead for the abuse and security department at SAVVIS Communications. The questions I was posed today are the exact same that Rob had, and I chose to take them from the point of view of the service provider because our interaction with RBLs is quite different from that of the common end user. As far as our overall impact on the internet community, they have both a very positive and a very negative effect depending upon the kind of blacklist that you use. With a more reputable list with an ISP they alert us to known spammers who have snuck onto the network via re-sellers or shell companies. They also alert us to our customers who are inexperienced, compromised, or uneducated when it comes to mail server configuration and mailing lists in general. And for SAVVIS on a personal level, they also provide us with a wealth of knowledge when we get prospective customers. We have new customers come in. We run them through the gamut of the various internet community RBLs that are out there, different groups to see what kind of history they have when it comes to spam, and that kind of, you know, weighs in on whether or not we want to have them on our network as a customer. As far as impacts on address assignments, we see two huge impacts. The first is what have come referred to as slash to burn net blocks. In essence, you can get on a list and you can get rid of the customer that caused your problems, whether it be for spamming or other AEP violations, and the net blocks they use can become completely unusable for weeks to years at a time because they are on certain lists, and that gives not only your abuse team a handful to work with, but also your IP admin teams entire net blocks that they cannot assign to new customers that have to sit and just wait for time to expire on them. Another one of the major things we see is collateral damage. Quite a few of them were blacklists out there take a firm stance that they will increasingly list larger and larger net blocks on purpose, and that directly affects customers who have nothing to do with the original issue caused by the listing or don't do commercial mailing at all in the hopes that the customer will go to the ISP and put pressure on them to fix the problem. In cases like that, the collateral damage customers have to be renumbered. So again, it's a waste of IP space. You have to have a customer give up a block, time and money to spend, renumber them with their entire new block, make sure everything works out right, and hope that the block they have won't be hit or listed again as collateral damage. Removal for us actually kind of depends on the blacklist operator, the cause of the listing and the action that was taken. As Rob mentioned, some lists, there is no avenue for removal at all. Once you're on, you're on forever, there's no way to get off. Other lists require that you pay to get off or have your removal request investigated. Others ask for a donation to a favorite charity, and yet others ask that you request removal in somewhat hostile open forums where every antispammer in the world can take a pot shot at your company and your employees and engage them in endless debates about your company as a whole and your customer base and is a complete waste of time and man-hour if removal is never going to happen. If this is just a forum where people can take pot shots and do what they please but there's no course for removal, there's really no point in working with those lists. Again, you know, removal kind of depends on the cause of the listing. If it's a listing caused by misconfigured server or compromised server, if you can work with your customer to get that issue resolved, get the configuration fixed, close the open relay, close the open (off mike), get the correct proper (off mike) in there. Removal is generally instantaneous or at the most 24 to 48 hours. Next up on our level that we'd consider would be mistakenly merged mailing lists or bugs in the system, which is a very common occurrence for people who get put on spam lists. Those ones are typically hard to address, but in general we find that if you can actually prove out that it was a merged mailing list issue or an actual bug in their mailing system, most blacklist operators are willing to accept that as long as the issue is fixed and safeguards are put in place to prevent it from happening again. For us, the most time-consuming and complicated listings to resolve are those triggered by bulk commercial mailings. As a service provider, we have to determine if the mailing itself is a violation of our AEP and understand the necessary actions that need to be taken for removal from the various blacklists. For some ISPs out there, their AUPs are not as strict as some of their removal requirements for certain blacklists. So then they are forced to make the choice between enforcing their own AEP or imposing the rules of a third party upon the offending customer to protect the integrity of their net blocks, network, and customer base as a whole. For our customers that have been listed for bulk commercial mailings, we highly recommend that they cease the bulk commercial mailing that triggered the listing if the mailing list used is not of the verified opt-in or closed confirmation variety. If the mailing list is not a verified opt-in list, we recommend they send out one mass advertisement free confirmation e-mail for the list. All bounce backs and not respondents should be removed from the list and all confirmed responses should be archived for future proof of opt-in status. Lastly, we recommend they take steps to convert their mailing practices to a verified opt-in model. We found this to be an effective method for gaining removal from blacklists as it shows a willingness to address the issue and move toward a safer model of bulk commercial mailing.
MR. CURRAN: Thank you. Next is Don.
MR. BLUMENTHAL: My name is Don Blumenthal. I've had my public private sector debut. Up until 11 days ago, I was director of the Federal Trade Commissions Internet Lab, which was our center for anonymous investigations of internet issues. I say our again. This is going to be very difficult for awhile going back to our and they and we and all that good stuff. I took an early retirement, and of two weeks ago left Washington, and now I'm trying to figure out what I'm going to do when I grow up. So this is a way to entertain myself, at least for a little bit. It's good to be here. Normally those are just blank words, but as a few people know, it's been a medical challenge to actually show up. This was the third time I was supposed to be here. I finally made it. I'm going to address my remarks from the perspective of said Federal Trade Commission as a law enforcement agency. We have very specific jurisdiction. Other agencies may have different views, but that's the nature of the games these days, particularly as some of you who follow ICANN issues may be aware. I first was asked just to address restraint of trade issues. The FTC has both, antitrust and consumer protection jurisdiction. This is kind of a throwback. I joined the FTC as an antitrust lawyer, and essentially I don't see any restraint of trade problems. If nothing else, blacklists are advisory only. And the second level, under an antitrust conduct case, predatory conduct, you would have to have a discriminatory application. You would have to establish that, say, a large ISP was using a list in such as a way as to create harm for a smaller ISP and drive them out of business and take market share. I think all the possible scenarios behind a restraint of trade case are, like we said, very unlikely. My bailiwick for the last seven years at the FTC was consumer protection, and that's where the real issues do come in. You know, there's a continuum in what would be considered a consumer. The person at home who just wants to get the web sites or use e-mail. The company that just outsources all its internet services, they're essentially just like a home user. Or larger companies or government agencies, they use an ISP to get to the internet but all of their work is essentially done in-house. I'm going to focus my remarks on the people who use internet services who aren't in a position to do it for themselves. I'm going to focus on people who are sending e-mail for their own limited purposes and concern myself with people who are using internet services for mass mailings. The issues are how consumers are affected, how they're protected, what the feedback is, what can they do to an extent to a moving target. You know, we're not at the stage where we were a few years ago. I remember an article roughly in 2001, 2002 that suggested even ISP tech support people weren't aware of blacklists. I hope we're not at that stage anymore. But the fact is I think most consumers out there don't know. They know my mail didn't go. They know I didn't get my message. But the concept of blacklists is, they know about filters and other things, but not that. Obviously they benefit. I think the standard response would be it's a great idea if I don't get that, fill in your own noun, stuff in my mailbox. They would be ecstatic if they understood the extent to which blacklists do limit the garbage that they get. There's no question about that. Having said that though, issues do arise. As I said, they're under the heading of I sent the message, why didn't it get there, somebody sent it to me, why isn't it here. And the problem is that it's frequently not the result of something the consumer knowingly did. They're bystanders in the process, and this can be the guy at home or in one case I can tell you there was a company that was trying to send me a quote and couldn't do it for two days, and I finally had to suggest check with your ISP, and it turns out the ISP had a block that had him listed (off mike), and that upped his ability to do business. The frustration gets worse when it was suggested that the listing company is particularly aggressive and broadens the scope of how they do the listing. There's really not much an individual consumer can do if the problem is at the ISP. The most obvious issue is we'll change your ISP. The danger there is there's real (off mike) for the home user and business financial costs for business in doing something like that. I think, to be honest, at the consumer level, the best defense -- did I do that in reverse -- the best offense is a good defense. I don't know. The most direct thing a consumer can do is try not to be the cause of the problem. The consumer, again, the small business or the home user, has to do what they can just to lock down their own systems, make sure that they're not hit with trojans or worms or whatever is going to start pumping spam out of their boxes through their ISPs. ISPs obviously have a range of responsiveness to try to work with consumers to stop some of these. But whether the ISP is responsive enough or not, the consumer can do things to stop the problem. If the consumer is really serious, it needs access, needs other -- needs ways around it, then fine, there are other things they can do. The public will try to learn which ISPs are better at public education, try to learn about blacklists, learn about the issues they need to consider and ask about when they call tech support, use multiple ISPs. The case I mentioned with the quote, the guy finally got it through using his personal e-mail account. You know, a business might want to actually consider (off mike). There are ways around if they're confronted with a problem. And the final thing I always recommend to people is that when you run into a problem and you need to get it addressed, act professionally. I've seen too many things botched up by I guess an attitude that's too frequent on the net, which is I'm anonymous so I can scream and rant and yell, and that rarely is productive. So if just in summary, it is an issue for consumers, it helps them overwhelmingly I think, but to an extent they are innocent bystanders because for the most part they're one step removed from the source of the problem, and folks out there just need to get better educated and act preemptively, at least try to minimize the chances that their space can be blocked off. Thanks.
MR. CURRAN: Thank you, Don. Adam Brower.
MR. BROWER: My name is Adam Brower. I'm an independent e-mail consultant. I've worked in the trenches, so to speak, for many years in various capacities and various enterprises surrounding this issue. I'm also going to answer the questions posed serially and maybe use them as jumping off points for any occasional brief commentary. First of all, the term blacklist carries a certain connotation to some people. So there's some of us who prefer the term block list. Silly as that may sound, it is equally descriptive and maybe less apt to raise the hackles of the people who were involved in it one way or another. What a block list is, is a list usually of IP addresses which can be used to prevent the delivery of unsolicited e-mail, spam, UBE, use the term of your choice. In some instances, the domain names themselves are used as a basis for a block list and the right-hand side RHS style of list. That's not the major implementation. And they're often usually queried as the DNS zone. The second question on my list was probably the big one, which is how are IP addresses added to a list. And I would have to say that the most common mechanism by which IP addresses are added result from delivery to spam trap addresses. For those of you who don't know what I mean by spam trap address, it's typically an e-mail address that is not read by a real human being, one that preferably has never, in fact, belonged to a real human being, and which can only have been added to an outgoing list of addresses by some mechanism that did not involve the actual input from the owner of an address. Harvesting from web sites is one mechanism, which is now, by the way, prohibited by can-spam, but there are many other mechanisms by which spam is added. In fact, I'm sure many of you have had a similar thing happen. I have had e-mail arrive, and the footer of the e-mail states that I subscribed to such and such a list from the IP address 22.214.171.124, which would be remarkable. There's some other ways in which addresses are added though, and by that I'm referring to preemptive listing. Some RBL maintainers get wind of an allocation given to a personality who they know previously abused the system by sending UB, and so sometimes on a best guess basis, a larger allocation than just a single /32 is added to the list. There are various philosophies on block sizes. Various RBLs have implemented different philosophies. The most conservative block by /32 by single address. The most aggressive implement is very large blocks. How is the community protected by RBLs. Well, I mean, the obvious short answer is we hope less spam is sent to end users and that protects their inbox, and by expansion protects the integrity of the e-mail and public reception of e-mail as a viable channel for communication. Marketers would see actually paradoxically some benefit to RBLs because insofar as public reception of e-mail as a viable channel for reputable real marketing insofar as that public perception is enhanced, their own market is enhanced, and, of course, bandwidth is conserved we hope. How can IP addresses be removed from block lists? And there are, again, several mechanisms that work. There is the automated example. You may or may not be aware of the CBL. It's pretty widely used right now. And entries in the CBL expire at the end of a fixed time period, or they will be removed on request. If somebody goes to the web site, clicks the address, clicks please remove me, and presto, it goes away. That's the short answer. There are other things that you could follow. In other RBLs, removal is effective through contact with the administrator of the lists, and sometimes this can involve contribution to a favorite charity or being forced to enter a public forum (off mike). I just want to interject in that context that a moderated forum, Usenet forum seems to be a good answer to that, and in response to what Katie said, there is a forum on Usenet I founded the news group, but I can't remember what it's called. I always get the dots in the wrong places. News admin net abuse.block listing. It's moderated by very good folks, and that is where a discussion of block listing in general and specific listings in particular take place, and it is the hope of the founders of the news group that the administrators of anonymously administered lists read it and respond. There are some RBLs that have no public contact points and SPEWS is a good example of that. There are other much better known entities, which have no known point of contact. Brightmail is a good example. Some large providers have internal block lists, and these are often administered through abuse (off mike) from large mailers, where I have to say prevent the delivery of some spam (off mike). How are RBLs funded? Well, they're funded through donations like a favorite charity. Some are. Some accept small donations from Joe Internet User anywhere from $10, $20, $15. Some RBLs sell data feeds to large users to offset their costs. Some are self-funded. In fact, I would have to say probably a majority are more or less self-funded in that they're cobbled together in hardware and bandwidth and, of course, there are commercial services. Again, Brightmail is a good one. Block listing is just one method in the arsenal of weapons in the user net community in opposing spam, and it has all the advantages and failings of any method. It's administered by humans and sometimes humans make mistakes, and in my mind at least, the best RBLs are those that have explicit points of human contact. (off mike). That's all I have to say right now. Thanks.
MR. CURRAN: Thank you very much. I would like to point out that the microphones are now open. While the people are getting to the mic, I want to ask a question to the panelists. I would like a response from each. Some of you highlighted things that ARIN could do, and I'm also interested in things that ARIN shouldn't do with respect to block lists. In particular, if ARIN does something, does that implicitly endorse the concept of block lists being used for the internet? Is that something ARIN wants to do? Likewise, by making it easier to operate a block list, are we doing a service to our community or not? So let's go down the panelists. Rob?
MR. SEASTROM: I don't think that doing something that makes things work better for block list operators is any more endorsing. The fact that their block list was being used on the internet than publishing WHOIS data is endorsing criminal activity on the internet. It's simply providing a data feed that recognizes the fact that there is someone that can benefit from the data feed out there. I think that the publishing -- publishing lists of addresses that have been reclaimed that are reissued would be a good thing with time stamps for that. I could go way down the rabbit hole of things that ARIN ought to do, some facetious, some not, but I won't do that at this time.
MR. CURRAN: Okay.
MS. FLOWERS: Recognition and reissue with time stamps would be a great boon to the issue, but it comes down to no matter what ARIN does, it's on the blacklist operators to be part of the internet community as a whole and work with end users and ISPs to get the issues resolved without resorting to drastic measures to force their points across. So it kind of leaves it up in the air as to whether ARIN should get involved in the matter or not I think.
MR. CURRAN: Okay. Don.
MR. BLUMENTHAL: I think the purpose of neutral measures, such as Rob suggested, are definitely appropriate for ARIN to get involved in. The things that would help the job of block lists or blacklists are definitely appropriate. I would hesitate to see ARIN get involved in anything that is specifically endorsed or assisted with block lists.
MR. CURRAN: Adam.
MR. BROWER: I have to agree with Don, and I think ARIN should not neither specifically oppose, nor endorse the practice. I think we can recognize that a perfectly administered RBL has a benefit to the community, but there's really no reason to explicitly neither oppose nor endorse. I just want to note a few things that ARIN could do just as a matter of policy, which would have the result of benefiting the practice of RBLs, list of reclaimed addresses. Rob's idea about time stamps by RIRs to be allocated by IP space would be a useful resource. I know also something on the public policy lists, the idea of capturing origination or announcement of ASs in templates is a very good idea to me. It would make administration, it seems to me, of block lists more efficient and give maintainers some insight into origination points and ASs (off mike), but no, ARIN should (off mike).
MR. CURRAN: Okay. Thank you. Microphones are open. I see someone at the center mic. Name and affiliation.
MR. VIXIE: Hi. I'm Paul Vixie, and I am speaking here today as the founder of MAPS. We started the original RBL. I wanted to give my perspective on a couple of the questions that I heard being answered. So first off, it was never a blacklist, and I know that it is widely used that way now, but it was originally the realtime black hole list, black hole meaning the thing that your mail would go into if you were on the list. It was never a blacklist. It is not a block list. It is a black hole list. So let us all begin here today clearing up that widespread misconception in the community. I invented the term. I get to say what it means. When I started the first RBL, the internet was a lot smaller, and a number of people, illuminaries in the community, such as Gilmore, came to me and said, gee, I hate what you're doing, and, you know, if you do this, the internet will become a worse place for it; and my standard answer was, okay, so show me the life form or economic force which has not overrun its habitat unless it was opposed by some counter balancing force, and if you can't do that, then tell me what it is that is going to cause the holder of Tier-1 address space and some domain name from misbehaving, what is it that will cause that person to stop doing what Grant Busch called a few years ago at this podium the tragedy of the commons plea, and no one that ever wanted to debate this was ever able to come up with an alternative, something like this, even the really terribly, horribly, irresponsible lists like SPEWS are a natural outgrowth to the fact that the internet is open to all comers, including people who may do harm. So I see the development of the internet reputation field, and by the way, the company that I founded with Dave Rand is called MAPS, Mail Abuse Prevention System, was eventually renamed Cal-Kaya (?), and eventually resold to Trent (off mike) where my ex-partner, Dave Rand, is now the CEO. So they are very busy in internet reputation space. They are not alone. There are plenty of people who want to sell internet reputation data. That's their market force is to give rise to that. If people weren't willing to pay big bucks for it, then there would be nobody like Trent or any of these other companies in the business. I will say to the best of my knowledge, Brightmail only sells spam appliances and spam filtering. They do not have a data feed for sale. Spamhaus is the big one, and of course Trent has the old MAPS business. As far as what ARIN should do, and here I have to tread very carefully because I am also a member of the Board of Trustees, I believe that accurate WHOIS information is an extreme positive value to the community, not just to the black hole list operators or to the people who want an internet reputation to work, but to everybody. I think that there is no benefit to any part of the community nor to the community as a whole that comes from anonymous holding of address space or the ability to hold address space without having a registered abuse contact so that people could send complaints to you. There is no way to justify that has a public benefit, and ARIN as a public benefit corporation should work to authenticate the hell out of every bit of WHOIS data published. I also know that there is some work going on to try to secure IRR information so that maybe some day in the future we can start securing BGP announcements. I know that can't happen if the IRRs don't support it, and I know that about fifteen percent I got in the last week came from completely rogue address space. And there are plenty of address blocks that are advertised for thirty minutes at a time, so send a lot of spam and then revoked, and there never was any kind of allocation anywhere for them, and they came through, you know, Romania or whatever. There's no security in the BGP, and we are not responsible, ARIN is not responsible for BGP, but we are responsible for accurately representing the ownership of the address blocks, and so I think that as an RIR, we should do everything we can on a foundation basis to allow the eventual security. Thank you.
MR. CURRAN: Thank you, Paul. Yes. Microphone over here. Actually, does any of the panelists wish to respond?
MR. BROWER: Paul, your point on realtime black hole is very well taken. I just made a note and underlined it three times here. And I also want to agree emphatically with Paul's note about accurate WHOIS information. You know, how can I put it? In the operation of a RBL, knowing who you're dealing with is very important. And it's sort of a base as a first line of data that is necessary. So, you know, I want to agree emphatically with that point.
MR. BLUMENTHAL: I would also echo that. That's a long-standing battle in the law enforcement community, just the need for the information (off mike) in other words, IP or consumer protection (off mike) maybe more often domain is, and that's also critical issue just for consumers protecting themselves, trying to find out they have ripped them off to use a delicate term.
MR. CURRAN: Okay. RS, did you wish to comment?
MR. SEASTROM: I just wanted to add a footnote to something that Paul said, which is that it was my understanding at the time that the black hole, and I apologize for falling into the common vernacular when I was making my comments earlier, was actually a semantic inheritance from BGP implementation of same that preceded that. Can you clarify that?
MR. VIXIE: The name was coined at a time when BGP was the only way to subscribe to the first RBL, and so your understanding is understandable; but generally, the packets that people sent when LSE routing would get invoked and their mail wasn't going to go through, there would be ICMP. People didn't implement it as a truly (off mike) down the drain. It was implemented as ICMP reject, you know, whatever. So in my opinion when we shifted over to publishing it with DNS and using it in mail servers, the connotation carried completely, and, you know, that's why we did not rename it at the time we changed the publication date in California (off mike). MR. CURRAN: Okay. Good to know. Microphone over here.
MR. BARGER: Yeah. Dave Barger, SBC ATT. There's one other ARIN about -- one thing I wanted to mention about ARIN, sort of something else they could do without jumping knee deep in this, and they really shouldn't, but I was just thinking about it from maybe a public internet education perspective. As we all know, there's lots of blacklist organizations out there that have absolutely no way to delist something once it's already there. On the other side of the coin, there are other organizations where, you know, if the ISP sets up some pretty sound processes with them, it's pretty easy to get something off the list, you know, once you work through the right processes. I think ARIN could probably help in just general education of the internet community in terms of who are the credible organizations, who are the ones who have no policy for delisting. Maybe these are the ones if you want to subscribe to a blacklist, you know, these are the ones maybe you ought to work with, these are the ones you should stay away from, because the -- and I say ARIN should probably get into this role is because those organizations that don't allow delisting, period, I mean, you know, where we're talking about wasting a lot of address space. I mean, we as an ISP, you know, we have some very large blocks that are listed, you know, 16s, 15s, 14s, listed on some lists in credible organizations, and we can't get them off. So, you know, that could represent, you know, a misuse of a lot of address space throughout the internet. So, you know, I just suggest maybe ARIN take on a little bit more of an educational role in general, making people more aware of, you know, the blacklist organizations, which ones to use, which ones to maybe steer away from.
MR. CURRAN: The impact to the address space is certainly an interesting perspective you shared. I guess, do any of the panelists want to comment on this suggestion? RS.
MR. SEASTROM: There are certainly applications for which you could use those IP addresses where it would not matter whether they were on an RBL or not, and so I understand that that's an additional level of accounting and complexity for your address allocation people, but, for instance, you could have them on dial-up pools for which if somebody has a reasonably constructed SMTP office submission system, it would not matter whether the address was on an RBL or not. You could use them for hosting shared web servers where the mail for that was somewhere completely different. So, you know, as far as a total amount -- what is that as a percentage of your total allocation the amount of tainted space, if you will.
MR. BARGER: It's going to be a small percent. I mean, of the total space, I mean, it is going to be small, and your suggestion about using, you know, that tainted space as, say, dynamic type pools, you know, dial-up or whatever, you know, that is something that we do, but can in the process of, you know, going through network migration, server upgrades, you know, routers, et cetera, et cetera, we're always in a situation where we have to take, for example, a chunk of address space that may have been used for dynamic, reallocate it, flow it over here to this other product, and then all of a sudden we have these static or, you know, nailed down dedicated customers who all of a sudden, you know, are being blocked because of some blacklist issue. So it's one of those things that, you know, we're always having to second-guess whether or not we can reuse this block for another part of the business and then find out later that it's been blacklisted or that some portion of that has been blacklisted, and you can't get it off the list. I mean, SPEWS, for example, you know, that would be one where you just can't get it delisted. So then we have to hold that in reserve to sit on it for awhile and then maybe redeploy that later as, you know, sort of all of our IP allocation automation works and everything. So, you know, it's just not the best way to, you know, reuse address space and have to sit on it for awhile and not use it.
MR. CURRAN: Thank you. Any other panelist comments. No? Okay. Thank you very much. Microphone at the back.
MR. MARTIN: Chris Martin with Verizon Business these days. So the blacklists that Paul says are sort of one manifestation of -- maybe I'm putting words in his mouth -- of like reputation on the internet, and that would be a great idea if there was a common way to determine that and a way to get information back. So often times the reasoning for being on a blacklist is simply because you exist in a country of origin, right, and those show up on a list of things, and this just happened -- true story -- customers come and say I am on blackholes.us. Well, it's because you're in the United States. You know, what can I do for you? Would you like to move? You know, there's not a lot -- so which highlights two things. One, it's a blacklist, black hole list, whatever you'd like to call it today or yesterday, the list is there, and people have to understand why things exist on the list and why they don't and what the purpose is, and often times the user that's asking the question does not have the education or information to make that determination if they're still using it or their business partner is using it or something like that. So the idea of a reputation is nice. It would be good. But there needs to be sort of a common center, which is probably never going to happen. And some information about why is this thing on that list in particular. ARIN's responsibility, I think, is really there isn't a whole lot of responsibility, aside from maybe some education, which is a good idea, this is what a blacklist generally is. This is what they generally could be used for. I wouldn't even hazard to say this one is better than that one. You don't want to be in that business. All right. You don't want to try to say that SPEWS is better than Spamhaus just as two random examples. You don't really want to do that. Because every blacklist is really there at the whim of the people that run it. So today, I can decide to dislike any IP address with a six in it. If you're using my blacklist, then you're going to have to feel the benefit of that. Yeah. So I don't really think ARIN should make any kind of judgment whatsoever about blacklists, blacklist examples, I don't think they should really say anything good or bad about blacklists if there's some place where information about general internet stuff is available on ARIN's web site, hey great, put some information up what they are, but I would definitely not say this one is good, this one is bad or this type is good or that type is bad or using it for mail is a good idea or not. I just really -- the world of blacklists is just not some place you really want to go, I don't think.
MR. CURRAN: Okay. So in particular, the role of black hole lists reputation services isn't ARIN's job, that's someone else's job?
MR. MARTIN: Yeah.
MR. CURRAN: Okay. Any panelists want to comment? Yes, Adam.
MR. BROWER: I would like to add a resounding yes vote to Chris and others who has commented on that, but I do think a very bland informative resource that simply states what blacklists are available, what their purview is maybe. In line with Dave's suggestion, I think maybe that's useful, but certainly ARIN should not be in the business of endorsing in any way any realtime black hole list.
MR. CURRAN: Okay. I'm going to warn people, I am going to be closing the microphones shortly. Yes, microphone on the side.
MR. HANNIGAN: Hi, Martin Hannigan, Bahamas Telecom. So, you know, as far as I'm concerned, the RBLs have zero credibility, and I just wanted to give you an example of why I think that. So about a year ago with VeriSign, I was assigned a task to get a block removed from an RBL, but it somehow ended up from SPEWS as an example, and let me just give you a quick, the problem, the answer, and this should demonstrate the credibility levels. Okay. Dear SPEWS, I've been looking into an issue with someone sending me e-mail from FOO (?). The resolver is (off mike). Thank you very much. Could you please take this off your blacklist. It looks like a stale list anyway. So, you know, SPEWS doesn't identify themselves, and there's nobody to fall back on, and you can't pick up the phone and call someone. So here's one of the answers I got back. You might be aware that VeriSign has gotten itself into extreme bad order with quite a few people. Stop. What does that have to do with spam. Thanks.
MR. CURRAN: Okay. Any panelists wish to respond? Adam.
MR. BROWER: I mean the obvious response is, who was that from? Was that posted on usenet? If it was, the answer could have come from anyone.
MR. HANNIGAN: Well, that's right. It could have came from the SPEWS guys.
MR. BROWER: But I don't understand on what basis someone would have assumed that that response was from anyone associated with any organization.
MR. HANNIGAN: Well, who is it associated with? That's the point.
MR. BROWER: Exactly.
MR. HANNIGAN: So you all sit on the news group and support the fact that SPEWS is hidden behind a veil of secrecy, but you're not going to stand up and support what the general feeling of the news group is when they come up with what's basically a reason to say that something shouldn't be removed. I didn't see you come to the news group and go that was bad.
MR. BROWER: I would refrain from use of the second person pronoun in this context, but what I would say is that usenet is and has never been wild west, and it certainly is not a useful venue for contacting people who are dealing with abuse issues, you know, SPEWS and other similarly administered lists. In my opinion, and this is just speaking as one individual internet citizen, act to the detriment of the concept of RBLs. Precisely because they lack a contact point. However, to anyone who's had similar problems with that or other lists without a contact point, I, again, commend to you the moderated list NANAPL or at least some form of moderated and we hope civil discussion retains.
MR. CURRAN: Okay. Yes, Don.
MR. BLUMENTHAL: Well, I guess I would just -- I've got concerns about the (off mike). I just want to toss out the situation we're aware of, and I don't know how common it is or not, but I am aware of the server problem a couple years ago that's actually discovered the cause of black hole lists. So I get this -- it's a benefit that never occurred to me until -- until it actually came up. The server configuration has changed through a fluke, a badly behaved enterprise antivirus program. I won't mention the company, but it's been named here before. The only way the administrator found out is that their mail servers wound up on the list. That was the source of the implementation. So I'm just suggesting there is some ancillary benefits to the list that ARIN usually lists (off mike). MR. CURRAN: Other responses?
MS. FLOWERS: I completely agree with you. SPEWS is not a blacklist we pay the least bit of attention to. We take it with a grain of salt. Most of the listings on that list are very arbitrary, and we choose not to post in a public forum to request removal because it opens you up to random comments from people who you have no idea if they're affiliated with SPEWS, if they'll bring up personal issues, drag you into a flame war, and you are right, there are some very non-reputable blacklists out there. Of the hundreds and thousands that are available, there are a handful that are actually out there working with the community as a whole to get issues resolved, and those are the ones that we prefer to pay attention to, work with our customers to educate them as to what the blacklists are, what they do, how you get on them, how you don't get on them. So it's a matter of education and basically the service provider, your choice, which ones you want to pay attention to.
MR. SEASTROM: If I could just trailer onto what Katie was saying, I know that you have no trouble with speaking your mind any more than I do, and my standard question when people complain of being on XYZ blacklist is why do you care, and it really sort of gets to the heart of, well, I can't get mail from or to this particular person. So that's sort of what the -- the blacklist is the secondary problem. It's the mail not getting through that's the main problem.
MR. HANNIGAN: So I just -- I guess I would support this more if there was some better set of clear understanding of maybe some standards or something. I think that if ARIN does something specifically to help ISPs combat spam, and believe me, I hate spam just as much as anybody in this room, I think it -- so anything that ARIN is going to do to identify or associate a record to help whoever is running whatever RBL combat spam, when is their credibility to that RBL regardless of who operates that, and it makes it harder for me, for instance, to stand up at the microphone when someone says ARIN said you're a spammer even though that wouldn't be the case, and I think we should be cautious in lending name and/or support officially or unofficially inferred to furthering the cause of combating spam without, and this is where I would actually say I'll support this, some further defined standards that perhaps clarify what an RBL is and who is an RBL and who is not, because I don't think it's fair that you disassociate yourself with SPEWS, because they use many of the same systems and tools that you guys use. They just happen to operate in a different way, and, you know, I think that all the RBL operators do that work in different ways, and it's great that they're participating in defeating this. I mean, I just looked at my e-mail box. I've got two e-mails that I can read and 50 that are CONGY (?) and all other kinds of junk that, you know, I can't defeat the true (off mike) and whatnot, so I applaud your efforts, but I suggest caution.
MR. CURRAN: Okay. Thank you. I'm warning people I'm closing the microphones. RS, would you like to respond to that comment?
MR. SEASTROM: Yeah. If I could reply to that. Marty's point is well taken that doing something that would be -- that would appear to be an endorsement is I think beyond what I really wanted to endorse myself. The comment earlier, well, you know, we can publish a list of these, et cetera, et cetera. Well, if we start publishing lists of things that are outside of our core mission of stewardship of internet numbering resources, well, where do we start? Do we start publishing lists of free software download sites, maybe ARIN's favorite lists of social networking sites, you know, that sort of thing. So I think that's sort of a step-off of our -- away from our mission, but certainly publishing a list of reclaimed addresses and the dates on which we reclaimed them would be well within our mission.
MR. CURRAN: Understood. Okay. Microphones are closed. We've got one last comment at the back of the room.
MR. DIVINS: Dave Divins, ServerVault. I actually want to kind of agree with what RS just said. I don't really think that publishing a list of blacklists is useful to anybody. Pretty much if you know about ARIN, you're probably more likely to know about blacklists than you are to know about ARIN, and the people in here probably don't need to be told how to get to Spamhaus or whoever they want to use, and I think any listing of services would almost be a task that is backing of them. So I really wouldn't like to see that. But if somebody wants to change current ARIN policy to add attributes to WHOIS to help these things get solved, that should go through the spam PPML process and let that specific requirement be embedded that way.
MR. CURRAN: Okay. Final comments from the panelists. RS?
MR. SEASTROM: I think in general at the end of the day, when you look at all the hassles, RBLs sure do create a whole lot of hassles, but they mitigate more than they create, and that's why we continue to use them. And that's all.
MR. CURRAN: Thank you. Katie.
MS. FLOWERS: I too feel RBLs are a very useful tool in combating spam and other issues on the internet, and besides from keeping me employed, they're a necessity to the community to keep it policed to a point, and again, I don't really feel that ARIN should take a stance, either pro or con towards them because that would just get them into the middle of an ongoing battle that will never be settled.
MR. CURRAN: Okay. Don.
MR. BLUMENTHAL: Again, I think that RBLs are useful tools overall. You know, from the consumer standpoint, it would be nice if consumers had an understanding, and I think that's something that can come with public education directly or through tech support or whatever, they need to know what's going on to channel their business, maybe reporting (off mike) good players and bad players. I've also been struck (off mike).
MR. CURRAN: Adam?
MR. BROWER: Yes. I would have to say that I think RBLs are a necessary evil unless and until the perfect FUSSP comes along, we're going to have to -- those of you who aren't familiar with that acronym, Final Ultimate Solution to the Spam Problem. Until that comes along, we're forced to use what's available. I want to emphasize again what I said before that I think RBLs, of course, they're run by human beings, and human beings are subject to failure, and when they do things wrong, the market will speak by not adopting them. There are thousands of RBLs out there, and some of them have three users, and in large measure, you could say that's the market speaking. So, you know, are they perfect? No. Do they mitigate the spam problem in some way? Yes. Are they useful? Probably. And would it be best if we didn't need them? Absolutely.
MR. CURRAN: Okay. Thank you, Adam. I'd like to thank all the panelists of our black hole list round table.
MR. PLZAK: Thank you, John. And again, I would also thank the panelists for a very, very informative conversation. Okay. So it's now time to move onto the next event on the agenda, and as the trailer indicated this morning, this is one of the favorite aspects of an ARIN meeting, which is lunch. Reminder this afternoon, the session will begin again at 2:00, but we will begin with Policy Proposal discussion 2006-3. So a few quick announcements. Please make sure you take your valuables with you. This room is not locked and there is no security. A reminder, the Number Council Election is in progress. Designated member representatives and ARIN XVIII attendees vote until 4:00 local time today. Please remember to confirm your vote. It's part of the process. Results will be announced tomorrow. And again, if you have any questions, check with the registration desk or send an e-mail to firstname.lastname@example.org. Reminder, Cyber Café is open. And reminder also, you can sign up and win a storage link disk drive, and you must be present to win. The winner will be announced Friday morning. I will say this. We did do one of these drawings yesterday at the open policy hour, and I had to go through a rather long list of cards before I finally got to someone to receive the prize. I ran into one of the people this morning that wasn't there yesterday afternoon and pointed out to them that the opportunity he had to receive one of these things, he missed it. So please, if you're going to enter, make sure you're around to get it. Otherwise, Susan would be glad to take it off your hands. And so with that, we'll see you back here at 2:00 p.m.
MR. PLZAK: So first thing on the agenda for this afternoon is a discussion of Policy Proposal 2006-3, Capturing AS Originations in Templates. And I need to have the other set of slides up here first. I've got some -- do I have some announcements and stuff to do here too? Thank you. So before we get to that, I've got to do a few other housekeeping chores here. So first of all, a reminder about the social tonight, Explore the Unexpected, and there will be foosball, billiards, the photo booth. Remember, you can have your picture taken with one of the members of Team ARIN, deejay for dancing, of course a sumptuous buffet dinner and, of course, the traditional open bar. The transportation will depart here at 6:30. Pick up your badge at 6:00. The first bus will come back at 8:00 and every half hour after that until 10:30. After that, you're on your own. Okay. Remember the rule book, and John will either say something or he will actually use the hand signals at some point, and there are probably a few hand signals that John will use that are not displayed on the screen as well. So enough said on that. Okay. So now onto the first item on the agenda, and that's 2006-3. And actually, I have a set of slides in front of this. Don't I? Don't I have a set of slides in front of this that has to do with the history of the proposal, et cetera, et cetera, et cetera. Thank you. Excuse me while we have the training session here this afternoon. Erika is not new at this, but apparently she's having some damage problems to her brain. Anyway, this proposal provides for the capture and publicly available mapping of authorized prefix originations by autonomous system numbers. The shepherds for this proposal on the Advisory Council are Mark Kosters and Suzanne Woolf. And Suzanne is on the stage, and I don't know where Mark is. He's out there somewhere. Oh, there he is. Okay. This was first introduced on the PPML in February of this year, and it was designated a formal proposal by the Advisory Council on the 17th of February, and the first public policy meeting discussion of this was at the ARIN XVII meeting in Montreal, and the consensus of the community as determined by the Advisory Council from both the meeting and the list was that this proposal should be revised. It has not been revised, and this is more of a factor of the shepherd and the author trying to work together and not being able to successfully manage their volunteer time to do that. So it's not that they didn't want to, but they just haven't been able to get to it in a meaningful way. They have worked at it, and Suzanne has reported diligently at the AC meetings about it. So from the standpoint of a legal assessment, Council in March of this year, which is when he did the last assessment of it, and since text hasn't changed or added anything else to it since then, has determined there is really no liability risk. And staff comments, as posted on the PPML, are a couple things. One is can the downstream map modify the AS mapping information. It's not clear whether or not the downstream providers or recipients of the address space could do that. Also, a comment is, is that it appears that some of this, if not all of it, may be duplicating a capability inside the internet resource registry. Maybe that should be changed and modified. But if this policy was enacted, we would put this as a new section in the policy manual, and it would become section 3.5. From a standpoint of being able to implement this staff resource certificate impact, it would take us about three to six months from the time the BOT ratifies it because it involves a lot of different things to do, change templates, change software in the registration services area, change the directory services, change guidelines, and do some staff training. So from the standpoint of the mail list, 29 posts by ten people in recent times. Five for, one against, and the thread typical comments, I personally support the goal behind 2006-3 and see it as an intermediate measure to improve the state of routing security, and another view, I think that the IRR is a much better approach. So the full text of the policy proposal is in your meeting packet and is also available at this URL. So with that, now Erika can put up that set of slides she's been trying to put up all afternoon, and I will turn the lectern over to Sandy.
MS. MURPHY: All right. I'm going to start in the same manner that I started the discussion last April to tell you where this proposal came from. Securing the routing infrastructure is a very important problem. I don't think anyone would disagree with that. There have been any number of solutions suggested. None of which have really gained any traction. So under the invitation of DHS, there were three workshops held inviting operators, researchers, vendors, various members of the registry community to come and discuss together what would be possible to do to find an acceptable and deployable solution for routing security. You may recall the directory services round table at a previous ARIN meeting, and I also point you to a web site which contains some information from the various workshops. Okay. So, the operators at this meeting suggested that it would be very useful for them to have an authenticated list of authorized prefix originations. Long phrase which means that what you need is a way to map from the prefix to the ASs that are allowed to originate that prefix in BGP updates. But such a list would be useful in responding to customer requests to route prefix, would be useful in diagnosing routing problems, finding out who's supposed to be announcing a prefix. For those ISPs that use filters on their routers to prevent misoriginations would be useful in building the filter list. They wouldn't have to rely on not authenticated, not authorized data, and, of course, it's the necessary first step to any protection of the BGP updates. Now, that list of motivations ought to be very familiar to any of you who have looked at the PKI presentations in NANOG and in ARIN and in RIPE and in APNIC. It's the same motivation. Okay. So the status of last April were that there were two different suggestions of how it might be possible to produce this authenticated list of authorized prefix originations. One was the proposal that came from the operators' suggestion in the workshops, and that was a proposal to put the AS originating. The AS is allowed to originate a prefix in the prefix templates with which operators communicate with ARIN all the time. And then, of course, there were the resource certificate PKI panels and presentations and tutorials. And there was fairly widespread support from the audience for the idea of the importance of collecting this authenticated list of authorized prefix originations. Rather mixed support for the idea of doing the collection in the templates. And the AS shepherds were assigned to advise in revising the proposal to make it better suit the membership, and there have been many discussions between myself and the AS shepherds as to exactly how to revise the text. The suggestion was that perhaps with the number of different presentations that have gone on in IETF meetings, in registry meetings, and in NANOG meetings, perhaps the familiarity of the audience with this topic is a little higher, perhaps revisions weren't needed, and that is one of the reasons why there wasn't a revised proposal. But this talk is going to talk about readdressing the original proposal. It's also going to say perhaps if you are uncomfortable with the details of collection and publication that are in this proposal, you would be willing to support a broadened statement of support for the goal of collecting this authenticated list of authorized prefix originations. So the formal proposal is taken from the operator -- a suggestion made by an operator in one of these workshops. That is that there should be an optional field added to the templates in which operators could supply the ASs that were permitted to originate a route to the prefix mentioned in the template, and then this information provided in the templates would be used to produce the list of authorized prefix originations. I actually put up here the relevant words from the proposal text in case anyone wanted to ask questions about specific wording, but I don't think it's necessary to go over all these details. The collection is supposed to be daily. There's supposed to be a bulk publication of the information. The bulk publication should not be subject to some of the restrictions that are currently placed on bulk WHOIS, leave it up to ARIN as to how the information is stored and published, and the mapping is what is kept out of the comment field, the mapping between the prefix and the ASs that are allowed to originate. Okay. So what it allows. It requires that ARIN do the collection of the originations, but it allows ARIN to choose the storage and publication mechanism. So ARIN could, for example, decide to collect the origination of the templates but store it in route objects in the IRR. It could be published in bulk WHOIS or it could be published in some other bulk mechanism in an FTP. It could be anything that ARIN decides is appropriate and within their capabilities. It could even be published in resource certificates if such a certificate structure were available. What it does not require is that ARIN say that they are attesting to the accuracy of the information or that they are saying that the prefix will be originated by these ASs. It's only information provided by the operators of who is permitted to originate routes, and the operator is responsible for the accuracy of the information, not ARIN. Okay. So why ARIN? Well, do we need to go through the fact that ARIN is the source of authority for who holds address blocks? There isn't another authority for who holds address blocks. There may be people who are well-known for holding in certain address blocks, but there is no real authority behind anything other than what ARIN states. So any structure that represented the authority to speak for an address block must start with ARIN for those prefixes that are within ARIN's space. So ARIN has an absolutely vital and crucial role in establishing the authenticated list of authorized prefix originations. You get so you could say it in your sleep if you say it often enough. Okay. So ARIN is the authority. Why do this in ARIN templates? Well, the first and foremost reason is the operators are used to using the templates. They do use the templates. They communicate with ARIN all the time through the use of these templates. It's sitting right in front of them. Perhaps they will go ahead and fill out the comment field that says what ASs are allowed to originate this. It also inherits any scrutiny that ARIN is doing on original allocations and assignments, and it inherits any authentication ARIN is doing with the members to authenticate the communication of the template, besides which we need ARIN to attest to the authorized holder anyway, and this is a potential way that ARIN could use to populate the IRR with good valid data, possibly also a way to populate resource certificates if ARIN has the data and is producing certificates, they already have the AS originations in hand. Okay. Now, one comment that comes up frequently is, isn't this data just IRR data anyway? Well, there's a difficulty in the authenticated and authorization part of an authenticated list of authorized prefix originations. IRRs aren't the authority for who holds a prefix. What we want is for the prefix holder to speak for their address, not for an AS holder to speak that, yes, these are the prefixes we announce. That mechanism is what gets us into trouble in the beginning. What we want is the prefix holder to say this is the AS allowed to announce. The IRRs aren't in a position to authenticate that the registrant is the authorized prefix holder. ARIN knows who is the authorized prefix holder, they identify that by POC. IRRs have the maintained by concept. The POC for a prefix isn't necessarily the same entity as the maintained by in the IRRs. Furthermore, even if the IRRs were the same, the IRRs don't necessarily have the mechanism that ARIN has for authenticating the communication with their members unless ARIN is going to be sharing their keys. That's possible for ARIN's IRR, but it's not possible for ARIN to be sharing keys with other IRRs or ADB or any of the others. And at last report, ARIN doesn't validate route objects that are stored in their IRR. They don't validate -- they validate objects stored in the IRR having to do with addresses that they're coming from the same person that is the POC in the resource database. They validate objects having to do with ASs, that they're coming from the POC that's in the resource database, but they don't validate the route objects, which is what maps prefixes to AS numbers. So to go through the staff comments. The first comment on here, the term user could apply to both direct registrants as well as reassignments, that's as stated in the staff comments that I received. When Ray spoke just a moment ago about the staff comments, he had rephrased this a little bit to say would downstreams be able to modify the AS mapping for their prefixes, and if they have been reallocated or reassigned an address space, then net mod would give them the capability of changing the assignment, changing the mapping. One other comment was that this duplicates the capabilities of the routing registry and could be addressed by enhancing this existing functionality. Perhaps. Note that the proposal does not make any restrictions on where ARIN could store or publish this data, so it's possible that it could be stored and published in the IRR, but it's better to collect the data in the templates because of the authentication model. We want it coming from the authorized prefix holder. We want ARIN to authenticate in the same manner that they have arranged with their prefix holders. If we're trying to do this with submitting it through the IRR rather than submitting it through the templates, you'd have to synchronize the POC and maintained by between the two databases, and you would have to institute validation of the route object that currently isn't being done. Furthermore, use of the templates buys into a mechanism that the operators are currently using. We know that they aren't necessarily currently using submission of objects to the IRRs. We're trying to buy into a customary operational procedure to make this happen more often than it does. The final comment was the resource impact is significant, could be implemented in three to six months. Three to six months sounds okay to me. Some of the public comments that appeared on the mailing lists. Some comments said that the data belongs in the IRRs. Maybe I've beaten that one to death. But publication is left up to ARIN could be the IRR. The IRRs can't do the collection process because they don't have the information about the authorized person to be speaking and the mechanism for authenticating that person. One comment said that it would result in partial or incomplete IRR objects. Now, I'm not really certain what that comment was about because any IRR object that was created from the data collected would itself be complete, and nothing about putting in one object prevents putting in other objects. So I'm not certain where the partial comes from. Some comments said that the goal was the important concept. That was one thing that Ray put up in his introductory remarks. And we should just support the goal and leave it up to ARIN to decide how. That's okay except that again this plays into using a customary operational procedure that people are used to using. All right. Now, so now I will speak against this proposal. Why you might want to support the goal only. What are the drawbacks in using the ARIN templates to collect and publish this information. Well, the ARIN authentication from the POC is typically weak. I say typically because strong mechanisms exist. There is a mechanism for members to get an X509 certificate and use that in communication, but right now more often than not, it's just mail from. Using templates doesn't necessarily mean that we're going to capture all of that data that's in RWHOIS. The same sort of problem will exist in registry run resource certificate PKIs, that only the direct allocations and suballocations like SWIP data are in the ARIN database. The third comment is that the authority to originate is specific to the indication blocks that you're given. So you can only express the authority to originate on allocation boundaries, but some of the NANOG presentation talked about the evils of deaggregating your allocated block. So maybe it's a good thing that you're only able to express the origination. Authenticity of the list as collected by ARIN is reliant on your communication with ARIN. ARIN collects the data. They authenticate it when they collect. They create the list. You know you've got the authentic data because you got it from ARIN. There are other mechanisms, and the PKI is one where the data is encapsulated and can be validated and authenticated by any recipient. It doesn't matter where you got it from. Despite all these drawbacks, I still believe that the gathering in templates is a good engineering start to forming the authenticated list of authorized prefix originations. Until or unless a better mechanism is available and in use like the PKI. Okay. So suppose you were against the specifics of the collection mechanism or some specifics of the publication. It still would be a good thing to support the goal of -- ARIN must support and facilitate the publication of an authenticated list of authorized prefix originations. This is a policy statement that the community could make to ARIN establishing the goals and priorities of ARIN's stewardship of the IP address resources. It's not -- it's not a null statement. It's establishing what you want ARIN to be doing. Such a statement would leave collection and publication mechanisms to ARIN so that it could be templates. It could be the resource PKIs, and it could be other sorts of things. So can ARIN be responsible for everything? In other words, why is it only support and facilitate? Why don't I just say they must collect and publish? Well, some ISPs are going to want to maintain control over their suballocations like they do now with RWHOIS, and it's a good thing for members to have the choice or not the choice. So ARIN may not be able to collect and publish the entire list, but they are still the source of authority for any suballocation origination authorization. So they must still play a role in supporting and facilitating the collection and publication if the ISPs are doing their suballocations themselves. Done.
MR. CURRAN: Okay. People who have comments in favor or against the proposal as written, who would like to talk about a goal-oriented approach instead, or questions on the presentation, please approach the microphones. The microphones are open.
MS. MURPHY: Okay. I believe you got there first.
MR. DELONG: Okay. Owen DeLong, C2 Company. I don't like the proposal as written on the template based front because I don't think it collects enough information to produce an IRR object, and the IRR is the correct place to stick this stuff, not WHOIS. We don't need yet another place to stick mappings between networks and autonomous systems. The more I think about this, the more I think the fundamental flaw in this is the idea that ARIN should be involved in mapping prefixes to autonomous system numbers. ARIN maps autonomous system numbers to organizations and ARIN maps prefixes to organizations, and the organizations should then be responsible for mapping prefixes to autonomous system numbers much the way that, for example, the registrars map DNS servers to domain names, and the organization with the domain name then maps their posts within that domain to that domain name and to their IP addresses. So perhaps what is needed here is a mechanism for submitting a public key with your template application for an autonomous system or for a prefix and then publishing whether it be in DNS or some other mechanism a record which maps a signature from your private key on the combination of the IP address and the autonomous system that originates it.
MS. MURPHY: So you're suggesting a new mechanism of publishing the mapping?
MR. DELONG: Well, not only that. I'm suggesting that ARIN should only be producing mapping between autonomous systems and AS -- I'm sorry -- and IP number resources and organizations, not attempting to map autonomous systems and IP systems together because that's not what ARIN does.
MS. MURPHY: Yeah. ARIN would not in this proposal be performing the mapping. They would only be recording the mapping that the operator did.
MR. DELONG: Right. Except it's unclear from any of this process which half of that is the operator that's actually authenticated in your process and potentially the IP resource and the autonomous system resource involved could be independent parties from each other.
MS. MURPHY: Yes.
MR. DELONG: And you're only authenticating one of them no matter which side you're authenticating.
MS. MURPHY: Yes. Well, the intent is to capture only the prefix holder's authorization of the AS origination. So only the prefix holder needs to be authenticated, and the templates involved are authenticated as being from the POC from the prefix. So I'm not certain that there's a problem there. Over on this side.
MR. KOSTERS: Mark Kosters, ARIN AC. As one of the shepherds, I've been hearing numerous people voice their concerns about this proposal, and it all really boils down to not so much the mechanics, because that can be worked out, but whether or not the mission of ARIN ought to be broadened to facilitate this sort of action, no matter how it's done, and that's something I would love to hear more about. Whether or not ARIN ought to facilitate something like this, whether it's this or some sort of PKI sort of WISBANG (?) thing or whatever else Geoff is going to talk about. The delivery mechanism is something that's unclear to me how the PKI mechanism is going to be any different than this on how people are going to boot strap it. But the basis of this really turns out to be whether or not we want to broaden ARIN's mission to incorporate this sort of authenticated prefixes.
MS. MURPHY: Okay. Ed.
MR. LEWIS: Ed Lewis, NeuStar. I agree with what Owen was saying, and I was one of the people that talked to Mark about mission, and I won't go through that again now, but I'm also against the policy as it is right now. I'll just say that up front. But more because I have questions about it. I still don't -- there's just some things I don't understand about what's going on here. But what I want to kind of pick on now is that the presumption is that ARIN is the right place because they have the right information to do this job. So the first question I have, and being that I don't deal with routing day-to-day myself, are there cases where prefixes come from ARIN, ARIN assigns or allocates a prefix to an organization, but then routes that out of an AS number that's come from APNIC or RIPE and LACNIC or AFRINIC?
MR. CURRAN: That's more of a -- do you know if that happens?
MS. MURPHY: I certainly do know that it is the case that prefixes are associated with an org ID but routed by an AS that is associated with a different work ID.
MR. LEWIS: Well, what Geoff was just confirming over the microphone is that it may be that ARIN has assigned or allocated or whatever an IP address range -- MS. MURPHY: Yes.
MR. LEWIS: -- to somebody who then will say it's coming from an AS number which is going to be allocated out of another RIR, not ARIN.
MS. MURPHY: Yes.
MR. LEWIS: So basically if the presumption for this proposal is that ARIN has to know about both parts of this --
MS. MURPHY: No.
MR. LEWIS: -- as a crucial part of it?
MS. MURPHY: No.
MR. LEWIS: Okay.
MS. MURPHY: The assumption is that ARIN knows who the authorized prefix holder is.
MR. LEWIS: Okay. So the whole purpose of -- see, like what Owen was saying, that ARIN can say this organization is responsible for or allowed to use allocated assigned this resource.
MS. MURPHY: Yes.
MR. LEWIS: They can do that.
MS. MURPHY: Yes.
MR. LEWIS: Tying any two associations like that together is best on, in my mind, somewhere else, at a routing registry, which I guess is the common thing.
MS. MURPHY: Okay. But the routing registries don't have a mechanism to ensure that they're getting this mapping from the right person.
MR. LEWIS: To me, again, being a little naive here, they can get -- if ARIN just passed adaptations saying who is responsible for this resource or who has been assigned this resource and all that, the routing registries could then pull that information and then see that the person making the request to them has, you know, permission to say this.
MS. MURPHY: Only if their only authentication mechanism is that they have the same name as is published in the ARIN WHOIS data. If they want to authenticate that it's the same person that ARIN handed the prefix to, then there has to be some authentication mechanism set up. Right?
MR. LEWIS: Right. Yeah.
MS. MURPHY: And the problem is, is to find an authentication mechanism that ARIN has to authenticate this is right prefix holder and the IRR can say it works for me too.
MR. LEWIS: I guess.
MS. MURPHY: Sharing keys isn't good. X509 certificates may be, but.
MR. LEWIS: Okay. What I'm kind of fighting around here is there is a difference between a routing registry and the routing registry in some of the language because ARIN does run a registry but there are other routing registries that have -- MS. MURPHY: Yes.
MR. LEWIS: That's where my concerns are.
MS. MURPHY: Okay.
MR. HUSTON: Geoff Huston, APNIC. I am neither for nor against this proposal, structurally I cannot. I would, however, like to make a clarification to what you said and perhaps an observation that might be helpful to the ARIN members here. The clarification is that you mentioned is these things could be contained in resource certificates. There is no particular proposal flying around to actually write that thing in a certificate and, indeed, it would be unwise. However, certificates allow you to sign things and the things that you sign can be validated by other people, reliant parties. So that if I as an address holder with a resource certificate that simply says the IP address is wish to sign something saying I commit AS123 to originate a route, then other people can look at that signed object and validate that the address holder really did give that authority. So it's not part of the certificate. The observation, you have to be very clear about the difference between authority and publication. Even in the resource certificate model, while the certificate issuers have an obligation to publish the certificates they issue in defined places as specified in the certificate, there is no implicit or explicit means of publishing the things you sign within the certificate infrastructure, in the PKI itself. The things you sign are simply signed objects.
MS. MURPHY: Right.
MR. HUSTON: Now, your proposal has a similar kind of duality, how you derive authority to generate these things and, secondly, where and how might they be published. To what extent does ARIN have a role in the second, even if it has a role in the first is an open question. In other words, publication and authority are separate things, and I think members should be mindful of that.
MS. MURPHY: Yes. And you rightly point out that I totally misplaced terminology in my slides and spoke of the route origination authorization as being representable in a certificate, and it's not. It's a signed object that might be based on the resource certificate PKI.
MR. HUSTON: If you use that kind of certificate infrastructure and you merely used identity certificates as we know them today, you might well say that Geoff signed it. You would not be able to say that Geoff owned the resource that is being talked about. Resource certificate issue is if the certificate included the resources, then Geoff is less important and the resources are more important.
MS. MURPHY: Yes. I agree. Are there -- yes.
MR. BLUNK: Larry Blunk, Merit. You mentioned that there's no way to authenticate what's in a routing registry. Well, RIPE and APNIC do do that. So there are mechanisms. Just because it's not currently used with ARIN registry doesn't mean it can't be. I believe there was a work item to integrate the routing registries. I don't know what happened to that, if that's still on the agenda or -- I think there should be like a holistic view of how this fits in with the ARIN routing registry, and that hasn't really been addressed I think.
MS. MURPHY: Can I comment before you continue? I did recognize that I was saying IRRs in general recognizing that RIPE and APNIC have a certain happy future that their resource database and IRRs and routing registry information are more tightly coupled. So, for example, they don't have this POC to maintain by mapping to try to maintain and authenticating one is the same as authenticating the other.
MR. BLUNK: I mentioned this on the mailing list, but there's a main routes attribute in our PSL which allows you to specify and maintain in our routing registry that has authority for a particular address block. So RIPE has INET known objects. They're just address blocks. They're not prefixes. I hear people using address blocks and prefix interchangeably, but they're not the same. So if you register a template for an address block and you give an origin AS, does that mean any prefix that fits within that address block is valid, or what if somebody does an attack where they inject a more specific and append that AS to the announcement, I mean that could be considered valid, whereas routing registries use route objects which have prefix notation, and the prefix is specified exactly. There's no ambiguity there. So I think that really needs to be addressed. I believe at one time with the RIPE 81 format, they specified the AS number in the address block information, but then they separated that out and created the route object that uses prefix notations. So I guess the other issue, legacy space, should this be addressed legacy space or is that another can of worms.
MS. MURPHY: Legacy space that's presently contained in the -- in ARIN templates, you could use the same mechanism.
MR. BLUNK: Okay. But how do you trust?
MS. MURPHY: I don't know how ARIN does its authentication of net mods for legacy space, so that would have to be whatever mechanism they currently use. Okay.
MR. BLUNK: I oppose the current proposal.
MR. CURRAN: The panel here.
MS. MURPHY: Suzanne.
MS. WOOLF: Suzanne Woolf, ARIN Advisory Council. As one of the shepherds of this proposal, I can say that one of the reasons why it's been difficult to figure out how to revise it and how to bring it before the community has been that it's a large and complex topic. The establishment of authority over a prefix and its routing is a complicated problem. And this proposal, you know, there are many, many complications to that general issue and what it looks like and who has authority for which pieces of solving it, but this specific proposal is really addressing only one of the relatively small moving parts, and the attempt is merely to allow operators to leverage their existing relationship with ARIN to publish their permission for a particular AS to be associated with a route prefix, a resource that they control, and all of these questions and all of these issues are very important, frankly, I think, to the future of the internet, but this proposal specifically is one particular piece, and it's an important kind in the scope of the discussions.
MS. MURPHY: Yes.
MS. SKANKS: Heather Skanks, Verizon Business. I see two things in this proposal. I see the request to capture the originating AS information, and a second part that asks to do it in a particularly -- in a particular way, a secure method, and I'm wondering if today you have an option if you want to use a secure method of submission with ARIN, you can go through the process and set that up, or you can just send mail from the particular address you have on file, and so is it possible to conceptually separate the two? Is there some reason why the two need to be together in the same policy? And then secondary to that, instead of capturing the origination information, is a possible alternative to create a policy that says if you SWIP a net block to your customer who is multi-homed, you have to SWIP it to the same org ID that they obtain their AS under, is that a possible consideration?
MS. MURPHY: Okay. I'll do the second one first because I understood that one. There have been suggestions that you could do this mapping by just looking at the org ID associated with the prefix and the org ID associated with the AS number, and if they match, that's an authorized prefix origination. However, I know for a certain fact that there are people who own prefixes that do not have AS numbers, and there are people who have prefixes and AS numbers that arranged for their ISP to announce their route for them and do not themselves run BGP. So the mapping from prefix to AS number through the org ID does not work in all cases.
MS. SKANKS: Sure. But in that case, the exception that you can see that the -- when you look up the originating AS, it should be the same AS and org ID that the allocation from ARIN is under or the parent allocation.
MS. MURPHY: Not necessarily the case. It is possible to, you know, multi-homing cases, PI addresses, you can be getting your route originated by an AS whose org ID has no relationship whatsoever to the prefix that's being routed.
MS. SKANKS: Right. So -- okay. So you're saying is if you obtain PI space, the address space is SWIP'd to an org ID and if you're getting PI and you're not multi-homed, so which is sort of a less common instance, but I see what you're saying.
MS. MURPHY: Okay.
MS. SKANKS: And then the second question was about that this policy also seems to require that you provide ARIN the information in a particular way.
MS. MURPHY: In the templates you mean?
MS. SKANKS: Right.
MS. MURPHY: Yes.
MS. SKANKS: So not only in the template, but rather than just sending an e-mail, but you're asking to send -- to use certificate authentication or the PKR or whatever.
MS. MURPHY: Oh, that's not part of the policy proposal. I was suggesting that using X509 protected e-mail would be a more -- a higher assurance mechanism of doing the authentication than mail from.
MS. SKANKS: Sure. But the same goes for just regular SWIP, right?
MS. MURPHY: It goes for everything.
MS. SKANKS: Okay.
MR. CURRAN: Couple questions, Heather. As written, would you be for this proposal or against it?
MS. SKANKS: One of the other questions that I kind of asked externally was, was this for v4 or v6, and it seems to be for both.
MS. MURPHY: Yes.
MS. SKANKS: So I think that this is very good for v6 going forward. I think that it sort of depends on how the information is going to be used. I think that it's a good thing that should have been done all along, but it wasn't, so I have a little bit of concerns about is the expectation that we go back and update all this information for all of our previous allocations, that's going to be really difficult and a lot of work. How much is good enough and what is the expectation going to be about how we do this and what is it going to be used for.
MS. MURPHY: I'm not certain where the discussion has been taking place. I know that I've been reading e-mail about possibly combining historical routing databased ways of extracting prefix to AS originations to use that to populate such an authenticated list of authorized prefix originations and going forward asking people to provide the information in the authenticated fashion and using the history-based techniques and the specific authorization techniques, some combination of the above, because of the problem of we've got 195,000 different prefixes out there.
MS. SKANKS: Yeah. So if someone has basically hijacked or stolen something for several years, that doesn't sound simple.
MS. MURPHY: Yes. That's the problem. The history-based techniques encapsulate the current situation, and any bad things in the current situation would have to be addressed in some fashion.
MS. SKANKS: Right.
MR. CURRAN: Given that.
MS. SKANKS: So I think that the other part of it is sort of how is this information going to be used. Is it going to become -- it can be used to make decisions about who to allow -- what to allow folks to route, but it doesn't provide -- there's no secondary technical part that provides people a way to -- for the system to inherently update itself. And we have that problem today where we look at the SWIP for something and say, you know, this block is SWIP'd to a company, they're our customer too, and we're going to allow them to route it, but tomorrow the other provider might remove the SWIP information, so while it gives you one extra step, something to look at it, it doesn't necessarily do anything to make sure that, you know, going forward -- there's no other technology that makes sure that going forward they're allowed to continue to route that. So I don't have a problem -- to answer John's question. I think it's a good thing, but I have concerns about how it's going to be used and how useful it's going to be.
MR. CURRAN: So would that make you in favor of it or opposed to it?
MS. SKANKS: I still haven't quite decided.
MR. CURRAN: I really would like to hear how you would come down on that. That's something we sort of expect from everyone at the mic.
MS. MURPHY: There is a suggestion in the proposal that the list should be published, collected and published daily. So if someone makes the change, it would represented soon. The difficulty is, is that if people don't make the changes when they occur, then it's -- it's not possible to represent it. It's not possible to publish data that people haven't provided, but that's pretty much true of any mechanism that you have. It's a problem of the authenticated list of authorized prefix originations, you know, people change their authorizations but don't tell anybody. There's not much you can do.
MS. SKANKS: One thing that might help me to kind of make a decision is, is there a way to allow it sort of to be a group, so how is it handled if someone signs up for disaster recovery services and they basically -- so we say that, you know, their AS is allowed to originate something, but they also signed up with someone else for disaster recovery, and if they go into that disaster recovery mode, another AS is going to originate it and potentially not use their AS. Questions like that, you know, how is the information going to be used are kind of important to understand if you want to implement this.
MS. MURPHY: Right. That's a basic problem with using a -- how dynamic can the information change, how dynamically can the publication get new information out there is kind of a design problem in the authenticated list of authorized prefix originations, no matter what the technique would be for collecting and publishing.
MR. CURRAN: Right. Additionally note that how ISPs use this information is probably going to be a scope issue with respect to ARIN, which is really just considering whether or not it will collect this and store it on behalf of the ISP.
MS. SKANKS: Right.
MR. CURRAN: So given all those uncertainties, do you have a thought in favor or against the proposal?
MS. SKANKS: I'm sort of leaning against it.
MR. CURRAN: Because?
MS. SKANKS: Just because it's hard to -- it's -- of all of that not being sure how it's going to be used and how -- yeah. I think some of that needs to get hammered out a little bit. That's just my opinion.
MR. CURRAN: Okay. Thank you. I am going to close the mic shortly as we're going fairly long, but the mics are presently open.
MR. WEILER: Sam Weiler, SPARTA.
MR. CURRAN: Sam, go ahead.
MR. WEILER: I support the proposal. In particular, I think it's very important that the community be able to leverage ARIN's existing authentication systems for authenticating communications with users of number resources to populate whatever sort of database or certificate system we want to use. I think that is vital. I also like the proposal as it's written a lot better than something I'm about to suggest. I also would even like seeing the full certificate system that I think Geoff is going to talk about later a lot better than what I'm about to suggest. So as I listened to some earlier speakers, particularly Ed and Geoff, they were talking about identity, in particular how right now all these assignments are tied to an identity. ARIN currently has a X509 certificate system. Although the statement of practices for that certificate system prohibits its use by third parties, as in prohibits third parties from -- or prohibits holders of certificates from signing anything intended to be validated by third parties, et cetera, et cetera. Question. What would the community think about a proposal that instructs ARIN to change its certificate practice statement to allow the certificates to be otherwise used? Number two, instructs ARIN to tightly bind allocations to those identity certificates in some way making sure that the names match or that you enter a certificate name in the WHOIS. Is there a third part we need there? Oh, and the third part, of course, is ARIN publishes the public key to allow other parties to do validation of those certificates and things signed by them. That would then allow somebody else to use ARIN's authentication system to go build these databases. The reason I don't like this is it turns the top level of the certificate system Geoff is going to be talking about into something very identity based, and that looks messy to me. But it does in some way simplify ARIN's role.
MR. CURRAN: So would you propose that? You said that's your least -- your proposal is your least favorite choice.
MR. WEILER: I do not intend to write a public policy proposal asking for that.
MR. CURRAN: Okay.
MR. WEILER: But I'm curious to know if anyone in the room is fond of it.
MR. CURRAN: They will certainly be able to find you. I guess, given the choice of having this proposal advance or not, where would you go down on that matter?
MR. WEILER: I thought I was extremely clear on that.
MR. CURRAN: I didn't hear in favor or opposed.
MR. WEILER: I support this proposal.
MR. CURRAN: Okay. Just wanted to double-check. Very good.
MS. MURPHY: So Sam's proposal would be a way to get around Owen and Ed's disagreement with ARIN taking on the role of identifying the mappings by publishing the authentication mechanisms that would make it possible for someone else to do the mapping?
MR. CURRAN: Roughly, yes. That's my understanding.
MR. WEILER: Well, just as a clarification, the proposal on the table does two things. It does leverage the authentication mechanism, and it does tell ARIN to collect and publish certain information, but it gives ARIN a lot of discretion as to what formats to publish that in. It also as a third thing allows anyone else in the community to pick up that published data and republish it in some other more useful form. So if ARIN can't figure out how to map this data into a routing registry and someone else can, that someone else can republish it in a routing registry. So it gives a lot of leeway to the rest of us to build something useful out of the data.
MR. CURRAN: That's correct. Okay. I'm going to close the mics shortly. So who was next? Center.
SPEAKER: I just wondered if I could get an answer to my question about integration of address registry and routing registry, if that's still a work item? I think that would be helpful to know if that's still in the plans. I mean it could render this proposal moot if it is in the plans, but, you know, I'm now sure how that would go forward. If this goes forward would that move that work item down? I mean, I've heard it mentioned in the past, but that's never been clear if that's an official work item or if it's --
MS. MURPHY: Was the question directed --
SPEAKER: The integration of address registry and routing registry, specifically the ARIN routing registry with the ARIN address registry, there had been discussions about integrating the two in the past, and I believe that was in the work plan at some point.
MR. CURRAN: Leslie, do you want to respond?
MS. NOBILE: I would actually prefer Ray to respond to that. But I do know it is in our work plan. It's something on our list to do, of projects to do. We haven't gotten as far as even, you know, writing requirements or anything as of yet, but that is definitely on the list to do.
SPEAKER: So, I mean, would people support bumping that priority? Or maybe that's -- I'm just suggesting a possible alternative. Because I think it accomplishes what you want to do, right? I mean, if you could integrate the two as RIPE has done or APNIC. I mean, I realize it's not a simple task. It's more complex. But maybe the complexity is worth it given that there are existing tools that use our PSL and would fit into the grand scheme of things with RIPE and APNIC.
MR. PLZAK: John.
MR. CURRAN: Go ahead, Ray.
MR. PLZAK: John, let me say a few words here. We fully recognize the importance of this. This has been a long-standing issue with this. We attempted to do something with this regard with the RADB several years ago and were unable to come to any satisfactory conclusion at that time. There are -- this is definitely a work item that we plan on embarking on and working through during the year 2007, and we have a lot more complex issues than the other registries do because we have a lot more data in our database that we have no control over, i.e., all the legacy stuff. So we have got to go through a rigorous classification system before we even begin other aspects of this. But it is something that we are taking very seriously, and we plan to accomplish in 2007.
MR. CURRAN: In light of that information, would you be in favor or opposed to this proposal?
SPEAKER: I'm opposed to the proposal as it's currently written.
MR. CURRAN: Because?
SPEAKER: I think it's too specific, and I think that there needs to be a holistic look at the address and routing registry, well the ARIN address and routing registry in particular. I don't want to confuse us with other registries such as the RIDB. I think it's an important issue aside from the RIDB, and I think whatever happens to the RIDB, I think this is important to address this issue.
MR. CURRAN: Okay. I am closing the microphones as we're over time. If you have any comments, now is the time, they'll be closed in just a minute.
MR. KOSTERS: Mark Kosters, now I am for VeriSign, not ARIN AC. I am for the proposal as far as intent goes because we need to actually start working on this, and this is something we can see definitely in the mandate of ARIN to do.
MR. CURRAN: Thank you, Mark. Any other comments? Microphone is still open. Any comments from the front here, the head table?
SPEAKER: I only have one generic comment, and that is to compliment Sandy on her thorough presentation. If all were this good, things would be better.
MR. CURRAN: Okay. So it comes to that time where we collect guidance to be given to the AC for how they will handle this policy proposal. The policy proposal is 2003 -- 2006-3, Capturing Origination Information in Templates. We are going to ask for a show of hands for people in favor and opposed to this. This will be guidance to the Advisory Council for their handling of this proposal. So I'm going to ask one vote in favor and then I'm going to ask for a show of hands opposed. I'm making sure my counters are out there and ready. Okay. All those in favor of policy proposal 2006-3, Capturing Originations in Templates, please raise your hand and hold them high. Okay. Lower your hands. All those opposed to 2006-3, please raise your hands. I didn't say it, but you can't vote twice. Thank you. The show of hands on policy proposal 2006-3, total number of people in the room 114. Do you support the proposal? In favor, 42. Against, 15. This information will be supplied to the AC for their considerations. Thank you.
MR. PLZAK: Thank you, John. Okay. The next item on the agenda is a presentation by Steve Crocker entitled IP Address Renumbering, and so, Steve, the stage is yours.
MR. CROCKER: So I wanted to answer the question that I got asked, how did you come up with this idea, and I thought I'd show the history here. I want to talk today about -- I want to provoke some discussion basically. A fairly broad-ranging and sweeping idea, not the first time it's ever come up, but the idea of putting finite lifetime on addresses and forcibly renumbering top to bottom, left to right, inside and out, on a regular basis. We can all vote now, and I know what the vote will be, but bear with me, and this I intend as the beginning of a discussion rather than sort of a one shot matter, and also this is not something that is a fits cleanly within, whether ARIN should adopt this as an ARIN policy, but rather a much broader kind of discussion. I circulated my thoughts to a handful of people and got back some responses. So here's a little game. Here's some well-known people and here's some of the quotes that have already come back. All right. So what prompts all this. The short answer is I've been watching some of the recent activity from my perch on the ICANN board and watching the recent allocation of IPv6 addresses /12s for each RIR and try and understand what was going on underneath that quite large allocation. Now, one could argue that /12 is a relatively small portion of the total space, which is arguably true; and on the other hand, it is an absolutely enormous amount of address space. And the other perch that I have is a Chair ICANN Secure Stability Advisory Committee. So the question raised rather naturally is how does all this play out over a very long term, what are the stability issues. I don't pretend to be a long-term expert in addressing allocation or in routing, but I've been around for awhile and have been watching these things over 30, 35 years or so, and have some idea of what's going on, and I'm not -- I'll say at a personal level -- I'm not comfortable that there is a satisfactory amount of long-term planning. I know there's been prior work in the peer working group and a couple of RFCs and a variety of other papers, and I know that there's been resistance before. Nonetheless, let me push forward here. The short picture, the simple picture, is that renumbering has some positive benefits. It's debatable exactly how much, and I'll try to be forthright about them, but it certainly has local pain. So we're balancing, in a way, global good versus local difficulties, and that's a very unpleasant state of affairs in any economic system. Economists have terms for these things, tragedy of the commons, and so forth. The thought that I want to put forth here is that if we use a community sense to adopt a scheme that is imposed uniformly and fairly throughout the system, two things will happen. One is we can actually reduce the costs quite a lot, and the other is we can greatly increase the chances that this will be adopted and will have the benefits that it should have. So here's a quote from Geoff Huston. It's some correspondence I had with him, and with permission he said sure. The finite lifetimes have the potential to minimize long-term structural fragmentation, but it's hard to adopt measures that enhance the greater good unless they also enhance the local good at the same time. Perhaps we should blacklist an address block that has been deployed for more than five years. I think he was speaking whimsically perhaps, but let me take that as a serious proposal and push forward with it a little bit. Five years is debatable, but the basic idea is to take addresses out of service after awhile. A couple of disclaimers. This is a personal talk, not representing formal positions of SSAC or ICANN or I sit on the IETF's Administrative Oversight Committee, and I run a little company that does some things in the collaboration space and DNS security, and this is not really a (off mike) position either. So this is just me, don't kill anybody else. Basic message is that renumbering is good for us for a handful of reasons. It reduces fragmentations, recovers unused space, improves the record keeping, and that has some multiple benefits. That the costs of this need not be extraordinary, particularly if it's done, as I said, uniformly and universally. We need much, much better tools, of course, than exist now, and to make things pretty clear here, I'm not talking about something that will happen overnight. I'm talking about a strategic change that would take a minimum of a decade and probably two decades to adopt if the willpower is there. So this is a very deliberately conceptual stirring the pot kind of talk as opposed to let's all adopt this right now. Basic scheme is simple. Addresses have a finite lifetime, take them out of service after their lifetime expires, and then suitably recirculate them after they've been out of service for awhile. Devices have multiple addresses. For DHCP devices, they're allocated. In some sense, this isn't an issue because they get an address with a lifetime now and it expires. And now here is the part that I think is slightly different from any version of this idea that has been around before, and that is to make the lifetime extremely visible everywhere so that there's no question about it. You know, it's not a question of one party says, well, I think the lifetime should be this, and they either do or don't enforce it, or they either do or don't propagate that. So the specific proposal here is to actually build that lifetime into the address. There's other ways that one could go, but for purposes of discussion, let me go down this particular path. And the enforcement is brutal. Any address that is expired is simply not routed anywhere, and if one particular ISP or one particular enterprise tries to push it forward on its own, it would just run into an awful lot of resistance because everybody knows what that table is. The implementation is very simple. There's no particular hardware or software delay in the process. It's a very quick decision. A lot of changes would be necessary around the edges. This puts a finite bound on how long the connection can stay up, for example. The vast majority of connections don't last infinitely long, but some do, and it's probably important to find mechanisms to restructure those. Again, we're talking about a relatively long transition time. So this is not something that's going to bring the world to an end overnight. So here's the particular proposal. This is based on dividing time up into a cycle of 16 units. I was thinking in terms of 16-years cycles, but you could have this run much more quickly. You could think of it as 16 months or 16 days. And there's nothing magic about 16. It's convenient for purposes of discussion, and it consumes 4-bits, but you could jigger this around to other things. So here's the basic idea. Part of the -- part of the address is its lifetime, and this field in this case is a 4-bit number, and the scheme is that the address is good for ten periods, and inactive for the following six periods, and this number here is simply the number of the beginning period. So that if it says zero, then it's active for periods zero through nine, and then it's out of service for periods ten through fifteen, and then when period zero comes back around, it can be reallocated, but it's been out of service for long enough that it's damped out and extinguished from use. And then time -- the address space is divided up into 16 different pieces, and you have overlapping allocations, so that if there's a number one in that field, it's active for periods one through ten, and it's out of service for periods 11 through 15 and period zero that follows and so forth. So over a 16-unit period of time, you have ten units where the address is valid followed by six units where it's not. Side comment that there's controversy even today about whether addresses are property, whether they're owned when somebody allocates them, how long you can have it. There's analogies in property law where you have spaces that are open to the public more or less all the time, but are nonetheless private property, and so you have a few very well known examples like Rockefeller Center in New York City where they close it off once a year to make the point that it's private property. I think the common law -- I'm not a lawyer, and I don't want to attempt to play one -- but my understanding is that if they left it open and unattended for seven years, there would be a case to be made that it's no longer private property, and that they've ceded it. So this is in a way -- this is the most important aspect of this proposal, but it would help clarify issues of where the address space belongs ultimately. All right. So getting back to the technical side. A critical part of this is that devices would need two or more addresses so that as the transitions are made, there's always a live address, and in terms of which address to accept, it should accept all of its current addresses, and in terms of which address to send from, what address it uses when it sends out a packet, the policy could be very simple, simply choose the newest of the addresses that are assigned. So if there are two addresses, one that is older and one that is newer, send out packets with the newer one as soon as the newer one is in service. Also, interaction with management stations, and now this is a little teaser in a sense that says that there's quite a lot that has to happen so that every device is in effect talking to some sort of management station rather than just being a stand alone hand-managed device if it wants to last for a very long period of time, and the management station has to have a way of adding and deleting the addresses on that station -- on that device. Allocation proceeds as it does today, IANA to RIRs to ISPs to enterprises down to devices or whatever the variations are on that. The imposition of the expiration of this lifetime business can be done at every single level. So that looking ahead a little bit of possible adoption paths would be perfectly possible for an enterprise, say, to adopt the idea of expiration of its addresses even if it were given addresses that were indefinitely allocated. Once addresses are changed, there's some interaction with the DNS, so you have to put address records in the system and then change the device's address once that's -- well, once that's live. Here's a picture of what things look like from a device point of view that at times zero, the first address is allocated, green indicates that it's in the fresh part of its cycle, yellow in that it's in the latter part of its cycle, and gray that it's out of service. Five units in, a second address is allocated. Five more units in, a third address is allocated. By that time, the first address is no longer in service and so forth. how is does this have any positive benefits. Well, among other things, mergers of companies and networks now become relatively straightforward. One just simply triggers a renumbering event. You don't have to wait for the old numbers to expire, you can assign new numbers whenever you want. It speeds things up a little bit, but the mechanism is in place, and it's a regular mechanism. Almost everybody in this room knows that the addresses are not just in the devices and in the DNS, they're squirreled all over the place, and that's where the real trouble comes from. They're in the et cetera resolve.com file. They're in various other server files. Access control lists all over the place, software licenses handled on the basis of IP addresses, BGP, time protocol, SNMP and so forth and so on. Ferreting out all of those and making gradual changes to the way those systems are handled is a necessary part of implementation of this, which is one of the reasons why we're talking about a very long baseline to make any of this work. So that's the essence of the proposal. Now, what -- who has to do what? Where does this get dealt with? Well, this is far too broad to have a very specific narrow venue. There's some research to be done on everything from the mechanics of how one would implement it to what its actual value might be. There is a lot of specification work and engineering. That probably falls naturally into the IPF in the event that there's enough desire to push that forth, and then, of course, in places like ARIN and in ISPs and so forth, there's a lot of policy discussion to happen. So that raises the question of who coordinates and drives such a thing, and how does one build any kind of transition plan, and those are not things that I have clean, crisp answers, but I have a couple of thoughts. One of the kinds of questions to ask is what would it take assuming that we wanted to go down this path, where are all those addresses squirreled away, what tools are needed, and there's probably a series of other questions that fall under the general heading of what would it take to make this happen. More interesting is so even if you did all this, would it actually help, and I think that's something that we don't have enough data, and that's a clear signal that we should go and get that data by any means that we can, whether it's a desk analysis or simulations or measurements out in the field. The kinds of things that we would want to ask are how much would it help with the routing fragmentation, how much would it help in terms of conservation of addresses over a long period of time, how much would it help in terms of being able to manage inventory devices and resources over time. Security is not an unimportant aspect. Addresses are hijacked, and there's a lot of uncertainty about them. Sandy's talk was a piece of that large problem. Certainly something like this would force rather more attention on the ownership of addresses and who they're allocated to. How much would it help in terms of changing -- making it easier to change providers? The converse of that is perhaps there's a vested interest by providers in not making it easy to renumber because that locks in customers. How much would the creation of stronger tools for managing access control help in actually managing access control? Let me take a small diversion here. When I talk about -- in other context, when I talk about security, one of the images that I like to convey is the complexity of the tools -- the lack of control that we have with our tools and the complexity of the mechanisms when we try to do fairly simple things. So one of the challenges -- and let me ask those of you who are so inclined to actually try this experiment. Walk up to an arbitrary router, dump out its access control list, find the person who is responsible for that router, and ask him or her to explain what that access control list is doing. I will bet that on the average, it will take an embarrassingly long period of time to match up the data that comes out of that router with anything that you can make sense out of, and there will be a lot of loose ends that are dangling there. And I take that -- I mean, that's just the way things are, and that's a strong signal that we do not have a good connection between the low level tools that we have for managing these things with the concepts that we're trying to promulgate. A related aspect is that we have more and more blacklisting taking place at every level, at the IP level, at the main level, and e-mail level and so forth, and inherent in such mechanisms are errors on both sides, of course, false negatives and false positives, and uncertainty about how things got to be the way they are, why is something on the blacklist. Well, all of that is really intending to implement a security policy, and some of that, not all of it to be sure, but some of that would be ameliorated if you actually knew with greater precision where those addresses came from and who had them under control. Again, I would advocate that if there were sort of rolling refreshing of the address allocation process, that it would have a positive impact in this area. Most of what I've said probably comes across as, well, this makes a possible sense for IPv6. It isn't clear to me that it doesn't have some applicability to IPv4. Some have said that there's not nearly enough address space left in IPv4 to make that possible. I don't know. It's been suggested the other way as well. I'll come back to that in just a second. As I said at the beginning, I put this forth in terms of a, if you think about this, 16-year cycle, but it isn't clear to me that that's the right amount of time or that those are the right units. So one could play with that and have fewer cycles, fewer divisions, if you will, and are much faster. If I were going to sketch out a transition plan, even if I were headed towards a steady state of a 16-year cycle, I would have a test phase in which there was a much, much faster cycle, so that you know that all the moving parts would work. Certainly there would have to be some testing of feasibility, some trial software, and if this isn't the right proposal, some of the basic thoughts behind it might be approachable by some other means, and so it's perfectly fine to entertain alternatives of some sort. In any case, there has to be some sort of a road map to go. One possible way to think about transition is to start not with the entire address space but with a portion of the address space. So there are two thoughts there. One is, as I said, to take just a portion of the address space, and the other is to look ahead at the hoarding that is predicted for the end of the IPv4 address space and say, well, if that's going to happen, then let's get ahead of that curve a bit, raise the price on addresses quite a lot under the existing scheme, and begin to introduce a discounted and incentivized way, limit the lifetime addresses, and see if it's possible to transition through that. So that's the basic set of ideas, and I'll put on my body armor, and we can have a discussion.
MR. CURRAN: The microphones are open for providing feedback to Steve on this most interesting proposal. The first one is -- actually, one of the advantages of the head table is you get to go first.
MR. WOODCOCK: Addresses don't have prices. Registration services have prices.
MR. CROCKER: Yes. I'll make the standard apology that I'm not steeped in the precise details of the formulations, but we're in the same ballpark in that there's money that changes hands in order to get an allocation.
MR. WOODCOCK: Correct. That's a service that ARIN provides to its membership.
MR. CROCKER: That's fine. I'll learn to sing and dance, but there's nothing inconsistent about what I've said. In fact, the idea that this is a timed service is exactly consistent with that. So thank you.
MR. CURRAN: Okay. So Bill Manning -- go ahead. Mr. Vixie.
MR. VIXIE: I just wanted to say, Steve, that when Bill Manning proposed this in 1994, it pegged the wacky meter, but you have broken the wacky meter off of its access.
MR. CROCKER: Thank you, Paul. I'm sorry I didn't have that quote to put up first.
MR. CURRAN: Now we get to hear from Bill again. Bill.
MR. MANNING: Steve, you've been drinking Geoff Huston's Kool-Aid. That follows on with the other Bill's comment about purchasing addresses. There has been some work done in the last decade on this. The issues boil down to essentially two. One of them is service discovery. All right. You talked about some things that need to track what's live and what's dead and who gets what pieces. How do you find that? All right. So the service discovery issue is something that people are looking at, albeit slowly. The DHCP efforts, the IPv6 service discovery models, all those things are headed in that direction. The second one is that there is a consistent and persistent overlapping of the distinction between an IP address where you are in the topology and who you are, and a lot of the difficulty with persistent IP addresses is that those are expected to be what the device is. Things like HIP separate what you are from where you are, and as soon as we can do that, then it becomes much simpler to actually change the topological numbering underneath and still retain that persistent identifier of the device. So if you can solve those two pieces, we're mostly done.
MR. CROCKER: Yeah. Thank you. Let me speak to both of those in a serious way. I completely agree with you that there are these two fundamental uses of addresses that have persisted for a long period of time. One is sort of the path to get to somebody, and the other is the identification once you're there, and that if we had separation of those issues by one means or another, that a lot of the driving factors here would be alleviated. I don't know exactly how well those are progressing. So this is -- if this proposal is overtaken by positive events, that would be perfectly fine. The critical concern here that's driving things is the long-term prospect that there will be at least two forms of harm. One is the actual consumption or close to total allocation of the address space even in the absolutely enormous IPv6 space, and the other is the explosions in the routing system, or maybe it's not an explosion, maybe it's just a gradual ever larger bloat that overtakes, and those are long-term effects, like global warming, that can be quite terrible, but they come about slowly enough that you can always argue that today is not the day that you have to deal with them. On the service discovery, I frankly don't understand why that's -- how that relates to what we're talking about here in that service discovery is important, but I don't see that it's affected one way or the other by this idea.
MR. MANNING: How are you going to find your DNS servers?
MR. CROCKER: So you're talking about the initialization of this process, the priming process in a way?
MR. MANNING: Well, let me rephrase. There was a discussion I had with some nut case -- Paul Vixie, I think -- once upon a time about this thing called the root hints file and whether or not we should aggressively renumber the root name servers, and the inertia -- the argument was that the inertia behind getting everybody to change where to find the root name servers was so high that we couldn't actually aggressively renumber those guys. So the service discovery is, is where do you go find the place that tells you what you're supposed to be using now or what's dead, what's alive, which things am I supposed to do.
MR. CROCKER: Well, let me --
MR. MANNING: But we can do this a little bit later. There are other people who want to talk.
MR. CROCKER: Yeah. A quick comment, and then I agree with you we should take that for another time. I have been looking actually at the -- specifically at the root hints file and the priming responses. I think there is no question that those addresses are so deeply embedded that making a change to that set in a brief period of time is a non-starter. The question is, does that mean forever or does that mean that it just takes a long time, and if so, how long is that long time. If you're going to talk about doing it within a year or two, that's a short period time, not going to happen. If you're going to talk about setting a course in which that's going to happen, I think that's fundamentally a different discussion.
MR. CURRAN: Okay. Front microphone, center. Go ahead.
MR. HUSTON: Geoff Houston, APNIC. Since you so liberally quoted me there, Steve, let me explain. I suppose the whimsical nature of the Kool-Aid in which we were indulging in at the time, the conversation that sprung this was actually a conversation about /12 allocations to RIRs, and the real question was why, and the answer was because when you get structural fragmentation in the address distribution system, it's there forever, and it just keeps on going. Why? Because renumbering is incredibly hard, and the overloaded semantics we have with addresses are amazing, and my comment was we need that larger space in order to espouse allocation policies in order to make sure that we don't artificially and more than necessarily structurally fragment the address space because renumbering is amazingly hard. So yes, I did indulge in some speculation, but I stand by the original proposition renumbering is really hard.
MR. CURRAN: Okay. Any responses?
MR. CROCKER: No. I'll let that stand. It's clearly hard. The question is in my mind does that make it -- is that a -- is that an euphemism for hell no, can't ever happen, or is that simply a gauging of how hard it is?
MR. HUSTON: Hell no, can't ever happen, doesn't really happen. Hard is cost. And I get back to the other thing which was correctly quoted, that kind of goes -- well, it was not correctly quoted, but in context, that renumbering is a common good without local benefit necessarily because it's not that each individual fragment that appears in the routing space is the one that breaks the routing system.
MR. CROCKER: Right.
MR. CURRAN: Okay. Center, back microphone.
MR. DURAND: Alain Durand from Comcast. I would like to offer an analogy. I moved to the States in the year 2000, and ever since, I have moved about five or six times from west coast and east coast and different states. It has been hell on my family. It's been really hard, like finding new schools, new banks, new shopping centers, new cars, new everything. It's really, really hard. And one of the things that makes it possible is that you can get support from the local community where you arrive because those places have been fairly stable. So if everybody was moving once a year or once every six months, it would be total chaos. And I'm afraid that your proposal is somehow the equivalent as asking every single human being on this planet to move from one place to another on the other side of this country every 12 months.
MR. CROCKER: Well, now, I understand exactly what you're saying, but I think that an absolutely central part of the world that we're living in is that there is another address space that sits on top of the IP space, and that's the domain name system. The whole point of having a domain name system is to have that level of indirection so that it ought to be possible, and it's only I would assert by sort of violating the basic point of the design that we have IP addresses cast in concrete in so many different places, but it should not be that hard to roll IP addresses on a regular basis, making use of that enormous amount of other infrastructure that we've built over the last couple of decades, namely the domain name system.
MR. CURRAN: Okay. Front center microphone. I am going to be closing the mics shortly.
MR. SAWYER: Leif Sawyer, GCI, ISP in Alaska. I'm not sure what problem you're really trying to solve here, but I'm going to take two stabs at it. The first one is you're trying to solve the problem of not enough address space, and what you've done is you've increased it three-fold by having three sets of addresses for every device, every person, every car, everything out there that has an IP, you've tripled it. That doesn't solve the limitation. So I guess my next guess is that the problem you're trying to solve is how do I increase complexity in the universe, and that you have done.
MR. CROCKER: Thank you.
MR. CURRAN: Rear microphone. Cathy.
MS. ARONSON: Hi. Cathy Aronson, ARIN AC. I'll resist the urge to say this is insane. But I do want to stress the point that any kind of mechanism that we can come up with that makes readdressing easier is a good idea. I mean, I don't think forcing people to readdress on some arbitrary time frame is a good idea, but we do need tools to make readdressing easier, and anything we can do to facilitate that is a good idea.
MR. CURRAN: Okay. I'm closing the microphones. Front microphone, center. Owen.
MR. DELONG: Owen DeLong, C2 company. I think that this is a pretty bad idea. There are a couple of specific places that this breaks down related to, you know, things like customer VPNs and remote access control lists not under control of the person doing the renumbering. But setting those aside, I'd greatly like to focus on the primary reason this is a bad idea, and that is that it's I think the wrong place to attack this problem, and I think that the right place to attack it is that we fundamentally need a separation between end system identifier and topological location identifier, and we actually in the interdomain world sort of have that. Only the way we've implemented the routing protocol, we don't really do that. And that is that the autonomous system number is really the topological location identifier and the IP address is really the end system identifier. And I think that if we could look at moving the routing protocol to support that semantic better, then the whole idea that, you know, address fragmentation is bad could die the death it should have died when IPv6 was first designed and we could move on.
MR. CROCKER: I like that. I like that.
MR. CURRAN: Interesting thought. Final comment. Actually, second to final comment far microphone.
MR. RICH: Yurie Rich, Command Information. Perhaps I missed it, but the issue of address ownership was discussed earlier, and certainly this is a way of addressing that, but given that addresses aren't property, you license them, if you go through the proper channels and you receive your allocation and you maintain your membership and pay your dues every year, you essentially have that address space in perpetuity. Asking a large corporation to renumber every five years, getting new address space, it will never fly. They won't pay for it. If you could marshal all of the resources you identified to make this happen, you still would have the entire user community rejected. It's just impractical from a business perspective.
MR. CROCKER: I was well-warned that that would be a common response. The direction I'm coming from is to ask everyone to think about how all this plays out over a long period of time. We're talking about effects that creep up on us over a period, over multi-year, perhaps multi-decade process, and then something has to happen, and the enterprises in, you know, the business community will have the same problem, that it will be shared fate. So the question is whether you want to lay down a path that extricates us from those kinds of minds now or, you know, over the near term in order to anticipate the long-term effects.
MR. CURRAN: Okay. I actually have -- I usually don't comment, but I have to admit the novel idea has motivated me to use the mic. I guess it all comes down to priorities and what we're trying to accomplish at what cost. It's well recognized that we don't do -- as a parallel thought, we don't do a good job of urban planning in cities. Cities have remarkably old dead pockets of infrastructure all over the place, and every now and then you get something significant like a huge fire or a huge earthquake and you really get to level the ground and start flat, and you end up with well-designed infrastructure that you've done from scratch. I see this very similar to doing urban planning by planned earthquakes every four or five years, and I'm not saying it doesn't produce gorgeous results, it probably does, once we have it down to a science, but there's definitely a cost involved here for everyone involved that I just -- we have to agree on the priority before everyone can head that way.
MR. CROCKER: Having grown up in Los Angeles, earthquake country, the idea of planned earthquakes is an interesting concept. Let me take your terminology but transform it ever so slightly into planned remodeling, planned refurbishment, which is, in fact, what does happen in well-managed environments, in hotels, in industrial parks, in cities, there is an urban renewal process, and some places do it better, and some places do it worse. The internet is not exactly the same, if one wants to take that analogy, in that this is a global system, and there are -- there are some aspects of locality, but first and foremost, it's sort of one big, broad, integrated system. You could imagine trying to impose one of these renumbering schemes in a local sense behind the walls, you know, the firewalls surrounding a particular enterprise. That might be an interesting way to start. But this isn't -- this doesn't have the degree of disconnectedness and separation that you have in the urban planning situation. So, you know, to pick a place, I haven't had the opportunity to look around and see what shape St. Louis is in, but it's a reasonably old town, and I'm sure it's got a number of urban renewal issues. They are very different from Chicago or Cleveland or Pittsburgh or whatever, and all of those will have different fates that they can learn from but they don't have to be dependent upon. Here, I think we have a much higher degree of connectedness, and the fates are much more tightly intertwined with each other. So it's a reasonable thought.
MR. PLZAK: Thanks, Steve. Okay. We are slightly behind time, but it is still time now for the break. Let's take a break and be back in here at 4:05. So before we do that, I've got a couple announcements here. Number one, Bill please stay seated. Number two, reminder, the election is still going on, and the polls will close in about 11 minutes today. So please get in there and confirm your vote and do it. We'll announce the results tomorrow. And refreshments are available in the foyer. And the meeting will resume, not at 3:50 as it says here in Mickey's little thing, but it will resume at 4:05. So thanks. (Recess)
MR. PLZAK: Okay. Let's get started. The next item on the agenda is two of the updates from the IRRs. The first one will be the update from AFRINIC. So, Ernest, there you are.
MR. BYARUHANGA: Good afternoon. My name is Ernest. I'm from AFRINIC, and I will briefly talk about AFRINIC's recent activities. This presentation was done by my boss, Adiel, who couldn't be here, so I'll give it on his behalf. I'll first talk about the financial health of the organization. When we started our activities about two years ago, our engineering operations, which constituted the most part of our operations, were funded by the South African Government, and the incubation period or the funding period is coming to an end in about the end of this year. So one of our challenges that we were faced with is to assess the sustainability of the organization, the financial sustainability. This is something that we've been working on. And to make sure that this is possible, we've been working hard to ensure that there is a resolve for about one year, a resolve for the budget for about one year, that should take care of all the expenses that we shall be incurring. So right now, we have about 75 percent of that taken care of, and maybe by the time the incubation period ends, we should be able to meet all the financial expenses of the company. We've also been working to put in place good management systems, and most of these are already in place, and right now we have a few auditors that come to our offices once in awhile and audit our activities, and I would say that the results are normally good. The other thing that we wanted to share, AFRINIC is incorporated in Mauritius, and Mauritius is normally a bit friendly to international organizations, and they actually gave us a tax exemption, and this is a plus towards the organization getting financial sustainability. I'll next talk about the membership growth. As you can see from the graph on the bottom right, when we started operations, we started operations about April, April 2005, and about that time we had about ten new members, of course, excluding the members that were transferred from the other RIRs that were serving our region before we started. So from ten new members, we've grown to about 111 right now. So I would say the membership growth is very promising and, of course, this also adds to what I was talking about earlier, the financial sustainability of the company. Of course, the more the members grow, then the more the resources are allocated in the region. As you can see on the top graph, in 2006, more, much, much more, IP resources have been allocated in our region compared to 2005, which is red -- 2005, which is in yellow, and 2004, which is in red. So yeah, the more the members coming in, the more resources are being allocated in that region. The similar placed IPv6, as you can see, there's also a steady growth in IPv6 resources that are being allocated. This is partly also due to the membership growth, but also more partly due to the outreach and awareness that we've been doing recently in our region. We've been doing hands-on training for IPv6, and as you can see in the map, the countries that are shaded blue are the countries where we have done our IPv6 workshops. (off mike) the policies, a few policies have been in discussion recently and some have been adopted and others are still at consensus and discussion level. The policy for IPv4 temporary assignments has been adopted by the board. The same applies to a direct or PI assignments from AFRINIC to the end user organizations also adopted. And also a change to criteria for assignment of AS numbers also adopted. The same applies to the global policy for IP locations from IANA to the RIRs also adopted in our region. The 4-byte AS number policy proposal, it got consensus at our last meeting and is awaiting approval. Then there is a change of HD-ratio for the IPv6 subsequent allocations. It is still a proposal. It's not yet being discussed. Also, of course, what is being discussed is the IPv6 PI assignments. I think these were talked about earlier by IANA in the morning. Next, we'll talk about cooperation with other organizations in our region. Of course, as a new RIR and as (off mike) we're still trying to build partnerships and cooperation with other entities in our region, and recently we've signed (off mike) understanding with AFNOG, which is the African Network Operators Group, kind of similar to NANOG, and we participated to their funding, to the funding of their last AFNOG meeting, and also sponsored a few people to attend this meeting and other workshops. We also signed recently an MOU with the Association of African Universities, that's the AAU, and the FTRD, and (off mike). And, of course, we also continue the participation to the NRO activities through the AC, ACG, and the CCG groups of the NRO. We also have a few projects that we're doing apart from our usual tasks of an RIR. We're trying to offer a portal cord by AFRINIC, which the name was inspired from the APNIC portal. This is a portal to allow our members to easily interact with us, pay their bills online, manage their resources, allocate, suballocate, look at their correspondence with us that is ticketed ETC. So this project is still right now in the (off mike) stage, and we've already informed our members to evaluate it and give us feedback. We're also looking at analyzing the membership on service fees and also working on a tool or also similar web portal that would provide routing information. This will mainly show the information about the resources that we as AFRINIC have allocated in our region versus what is actually being used or appearing on the internet. So this is also a work in progress. And, of course, we are also working on activating a routing registry in our region (off mike) for our members. Right now, we're still advising our members or routing them to -- using them to use -- advising them to use the RIPE routing registry or any other of their choice. On this we'll hopefully be done before the end of 2007. Although it can be done any time, but the resources are still a problem. We're also, of course, closely following the internet (off mike) according to RFC3779, and we recently had a workshop office at our offices in Pretoria with Steven Kent. We had a two-day workshop with him, and, of course, we're also following what the RIRs are doing, RIPE NCC and APNIC. It's something we're keen on, and we're following it closely. Staffing and HR updates, we're five people at AFRINIC currently from four nationalities, and we're looking at hiring three more before the end of the year, assistant admin, membership liaison, and communications officer. I think actually right now the three have been hired already, and they have to start work yet. And lastly, our next public policy meeting is going to be held in Mauritius from the 27th of November to the 1st of December, back to back with a few other meetings of some entities in the region. My boss made this presentation, and he asked me to mention that these pictures are actually pictures he took from his camera. He did not get them from the internet. So for those of you that are coming to the meeting in Mauritius, this is what is in it for you. Thank you. Any questions?
MR. PLZAK: Thanks Ernest. Sorry, Bill. St. Louis doesn't have a beach like Mauritius. We've got you. We've got you and the Arch. And a big brewery to take it all down. Okay.
MR. PLZAK: Next up is the update from LACNIC, and German will do that. German.
MR. VALDEZ: This is the LACNIC report. My name is German Valdez. I work for the Policy and Standard Relations Manager. I'm doing this presentation on behalf of my boss, who's sitting in front. The first slide I'm presenting is about how LACNIC is growing. This is a statistical graph. The first one represents the amounts allocation per semester, what we're doing in the last year, and the second one is about the amount of /24 per semester we are doing at this moment in the region, and this only tries to represent that we keep growing in the IPv4 allocations in Latin America. In this slide represents also the increase of the IPv6 allocations, and you can see in 2005, we have a very important increase in relation to other years. We allocate 34 /32. In Latin America, this was made basically through very important outreach activities about IPv6, and at this moment we have 15 allocations of /32 including 2006. It looks like we lost one of the graphs here. Okay. I'll try to represent -- something happened. I had a slide about the number of the memberships in Latin American. We have so far 284 members Ray started with us, and half of these memberships are made of small and medium ISPs, and we made some changes about the medium size allocations, and this allowed the many small ISPs in the region to start their allocations with us and start our memberships growing. It's hard to explain what happened. And this is about the traditional activities of the (off mike), but also IRR, we are working very hard with our community. It not only allocates IP address or internet resources, but also tries to keep a help in many other activities about information society in Latin America. As I talked before, we have very important meetings about the promotion of IPv6. We've found that the allocation of IPv6 rates in Latin America was very low in comparison with other regions. So we organized 10 meetings of one day duration in 2005 trying to boost the distribution of IPv6 in the region, and we had 2,500 participants in these ten meetings that we held in ten different countries, and we also are given IPv6 activities like organizing (off mike) and foster some research projects, and we organized -- we helped organize the IPv6 task force for Latin America and also the meetings what we call Flip-6. That is the Latin American IPv6 forum. That is a forum where if people who are working in IPv6 activities or projects in the region can get together and exchange experiences. We have also projects that we call (off mike). It's in association with ISE. This project tries to deploy some group servers through the (off mike) technology in the region. So far we have two (off mike) already launched in Chile and Argentina, and we have another (off mike) already assigned, and Venezuela is going to be launched next week together with Panama, which is already assigned (off mike), but we're trying to find a date where we can make this launch. We have also a program. We call it FRIDA program, which is a project we are to give small grants to technology (off mike) in Latin America. It's a program that LACNIC is doing in the management, but the money is put through different organizations, like IDRC, (off mike), ISOC, and GKP, all these organizations through the funds of almost a half a million dollars in order to (off mike) projects related to technologies in Latin America. This has been a very successful project. We funded 26 research projects in different areas, like social and public policies, regulation, and technical projects, and we are preparing now our second phase of this program, and we are looking to increase the amounts of money we can put in these efforts. Also, we have two new communities supported by LACNIC in the region, the ISPs and network security. Both communities got together during the last meeting in Guatemala in May. We are very actively participating in activities related to governance also in Latin America. There is one document that is called ELAC 2007. That's the measure objectives related to the development of the information society in Latin America. This was the result of regional conference of governance in 2005. This is the kind of product of the WWSIS process, and we found that we are actively contributing to 25 out of 70 goals of this document, and we are an active actor in these activities in the information society in Latin American, and we promote strongly in any forum (off mike) of the internet governance, and it's important to say that many of the activities that we rely through, for example, the FRIDA program, the (off mike) project is made through a different kind of (off mike). We have deployed, for example, route servers in Venezuela together with the government of Venezuela. At the same time, one of the other root servers deployed in Argentina was deployed through a private ISP organization; in Chile, was with the university. What I'm trying to say is that we are trying to be a different kind of organization, get together, and work in favor of the developments and the (off mike) internet in Latin America. I won't go in detail about this slide because I've already mentioned all the work we are doing related to policy in Latin America. And I would like to summarize that we approved four different policies at the last meeting in Guatemala. Two of them are already implemented, which are the increase of the allocation (off mike) and the (off mike) IPv6. We are working for implementation date of the AS of 32 bits and the (off mike) policy. All these four policies have been approved by the LACNIC directory, but two of them are still waiting for implementation dates because this implies some changes in our process and in our systems. More information about our last meeting, more of the results, is that we had fee reductions, and it was approved by the General Assembly of LACNIC. The reduction in fees started this month, the first date of this month. And these are represented in 50 percent of not for profit organizations or end user who should receive internet resources. Also, we implemented the relationship with other (off mike) holder. This is a mandate of the General Assembly of LACNIC, which we had a resolution about LACNIC should be more involved in different activities in internet related in Latin America. We're trying to get more participation with governments and other actors in the region. We have our first meeting with the security community in Latin America. We are looking for a better coordination in the region, trying to get together all the most important actors in this area in Latin America, like the certs, and some ISP, which are working with their own certs. We are also having meetings with other important actors in the region trying to get the different parties together and trying to take the LACNIC meeting (off mike) every year, and that's why we have the (off mike) which is the Association of Latin America. (off mike) which is ISP Association. And also, we keep having a meeting with the Latin American IPv6 forum and the ISP Association of the region. We have 180 attendees, 69 LACNIC members, a little more than 100 first time visitors, and all these is 20 different countries represented in Latin America. All the discussions, the proposals, the scripts are available in this link. I'm very proud to announce that we are working very hard in our new facilities, and in the picture, you can see the house that we bought. At the beginning of the year, it was kind of an abandoned house. It was like a jungle, as you can see. And this is the house today. We are advancing everyday, and we expect to have the facilities ended by the end of this year. This is a great achievement for us. This is one step forward for the consolidation for the organization in the region. All right. This is the link with the information about our project of new facilities. It has information about the open dates. We already have the open dates. We don't have the house already finished, but we have the open date already established. It is going to be on December 11th, and, of course, all of you are invited to join us in this great activity and an important date for us. And you may see in this link all the pictures of the advance of the construction of the new offices and some other features about how we expect to be these facilities for LACNIC. It's in a great place. It's located not so far from our current offices. And this is just in front of the river banks. We have a great view and have a lot of good position in relation with other offices in Montevideo. We can go back to the presentation. Thank you. Finally, I would like to invite all of you to the next meeting, which is going to be in Margarita Island, which is a small island close to Venezuela. It's part of the Caribbean, and it's going to be -- our meeting is going to be from the 21st to the 25th of May 2007, and you, of course, are all invited. Thank you. If you have any questions, I would be happy to answer.
MR. PLZAK: Thank you, German. What he didn't show you was a picture out of the offices looking out towards across the Rambla, which is the major street there in the (off mike) district of Montevideo. Right now if you go to Raul's office, Raul unfortunately has a view of the Rio de Plata that is marred by being set back about one block from the beach, and so now Raul has decided he needs to be a little bit closer to the beach. So we can expect to see less of him in these climates as he's looking out the windows of his new offices. Significant though is the fact that I can remember LACNIC's first office. LACNIC's first office, the floor space, was less than the space that is up here on this podium, less space than that. So in a very, very short period of time since 2002, they have really grown. So to that, I offer you my congratulations.
MR. PLZAK: So now we are now to a presentation by Marla Azinger on IPv6 multi-homing BCP. So, Marla, if you are here some place. There she is. And I will let Marla explain to you why she's talking about this and what she's been doing about it, and go from there.
MS. AZINGER: Hello. I am Marla Azinger. I work for Frontier Communications, and I'm on the ARIN Advisory Council. I'm giving this talk because there's a pink elephant for ten years that people haven't -- well, people have been acknowledging it, but it hasn't been in the forefront of the global community completely. So this is an attempt to bring it forward a little bit more and also get people familiar with some of the possible solutions that are out there for multi-homing with v6 and hopefully some traffic engineering as well. Currently how IPv6 users will implement multi-homing and route engineering on a global scale is not determined. This leaves us asking the following questions. What solutions exist or can exist in order to enable v6 multi-homing and traffic engineering? Can we come to an IPv6 multi-homing and traffic engineering solution on a global scale? This discussion started for myself on the ARIN PPML, and the current problem drew more attention after a v6 policy was passed within the ARIN region. The problem that came forbear, not everyone can multi-home with v6, and due to the perception that filters must be set at a /32 and because no solution has been put forward for implementation. This issue brought forward another debate on ARIN PPML. Who should be involved in creating the solution to this problem we all face? Well, it ended up being just everybody named, IETF, NANOG, ARIN, and all the global RIRs. First, I am going to start with how the creation of solution input started. Based on the ARIN PPML discussion, IETF kind of kept getting put forward as someone we should talk to. So I sent an e-mail to the IETF v6 working group ops and asked them what their suggested solution would be, and they responded with an e-mail saying please come to the next IETF in Montreal. So on behalf of the ARIN agency, I accepted that request, and I met with several nice gentlemen in Montreal, and we sat down and discussed several different options that we could look at for multi-homing and traffic engineering. Now, there are a couple different documents coming out of IETF for this, and those will be posted real soon. Fred Baker is working on one and so is Elias, and they are two separate. I'll get to them real soon. These documents will be published out of the collaboration that we are doing, and they're also to be understood that they are a recommendation and not a mandate by the IETF. So now we need the following. We need global RIR input. What will work with RIR policy and current best business practices. In order to help this along, at least I hope it helps, I am writing a document which will be posted on the NRO site. This document is multi-homing with IPv6 and its pros and cons. This document is a living document, and it has all of the suggested solutions that have been put forward from the community overall. I'm looking for input on this because, as I said, it's a living document. So any pros and cons that people send me, I want to put them on there. Any suggested solutions that have not been thought of or may be a rearrangement of ones that exist can be added to this document. It's a community document. So this brings us to the current suggestions that have been put forward by the community so far. These are not in any special order, and they aren't in any special order in the document either. CIDR. We could decide on a CIDR boundary we think (off mike) can handle now and possibly in the future, open the filters to this decided CIDR boundary. Another one, aggregation slices, as a community we decide to allow a specific number of aggregations per AS. With this approach, we determine what CIDR boundary to filter on by considering how many more specific routes each insight requires in order to provide the appropriate level of fine grain traffic engineering capabilities in concert with multi-homing when approached. This way we can work backwards from the default insight assignment, divide that into the appropriate number of slices, and as a community decide on a CIDR that allows an appropriate number of slices. The next one is metro regional addressing. IP addresses would be assigned to a regional geographical location as opposed to large networks, ISPs, users, or PI. For example, a prefix is assigned to a suitable regional authority, such as a city. The city then chooses a single or a list of relevant providers to serve as the interchange. Each of the providers will advertise the region's prefix to the internet. Based on a protocol or by a contract, these providers will accept more specific prefixes from subscribers that are within the regional geographic location and will then interchange traffic to other relevant providers appropriately. Next one, community codes. A BGP community attribute for tagging prefixes would be used. In order to multi-home with PI space, this BGP community attribute would have to be attached to the prefix being used for multi-homing. The name of the new community is multi-home, and the internet assigned numbers authority should decide its value. BGP implementations will need to propagate the multi-homing community by default, even if they don't propagate other communities by default. Operators will take prefix from PA space used for multi-homing with the multi-home community and propagate this community along with the advertisement of these prefixes. The next one, published list. A list of approved prefixes for multi-homing would be published and filters would be open to this approved list. An example for this is, if IRRs decided that the first /41 of PA /32 allocation is to be utilized for multi-homing, then all filters should be opened for these approved multi-homing prefixes. This can be accomplished by the IRRs producing a list of approved multi-homing blocks and then publishing it on their public database as a loadable list. This list would be updated daily by the RIRs. This list would include both PA and PI blocks that are approved for multi-homing. The next one is policy, and this is also titled as a bit of work around. This policy would be written literally as a work around to provide the PA multi-homing problem a solution. RIRs would write a policy that allows providers to request PI space. The PI space would be allocated to the upstream requester who then would reassign the PI space to their customer. The next one is SHIM-6. This is a protocol. SHIM-6 provides a way to look at routing and starts communicating by both ends in SHIM-6. There is a lot of technical definition in this, and the document goes into more of it, so I'm just going to leave that one at that. Eight plus eight and GSE is the next one. This is a protocol solution that functions through identification manipulation. Eight plus eight and GSE are protocol-based solutions that attempt to completely separate the identifier, which uniquely identifies an end host from the locator, which locates the end host to one or more ISPs. GSE is an extension to eight plus eight that separates the address into the routing group, local sites subnetting, and the end system identifier. All suit or head checks should only reference the end system identifier so that the routing group can be modified. And the last one for today, maximum prefix. Rather than setting a specific CIDR to open filters, each origin AS could be limited to a certain number of prefixes. This could be implemented today if every upstream AS set a maximum prefix limit on each BGP number. All of these suggested solutions, none of them are perfect, and a lot of people know this, but it's what we have to work with right now. So that's why I wrote the document to show pros and cons and hopefully get brains thinking a little bit more and maybe figure out what direction we want to go. So if there are any questions?
MR. PLZAK: So the microphones are open for anyone that has any comments or questions of Marla on this. If not, she is available throughout the week, and please approach her. You'll be at the social tonight, right?
MS. AZINGER: Yes.
MR. PLZAK: I will also say this, that Marla has done a lot of work on this, and she has been making this presentation, she's made it at the last RIPE meeting, the last APNIC meeting, at the NANOG meeting this week, here, she will be going to the AFRINIC meeting in Mauritius, and, of course, will be at the IETF meeting in San Diego. So this is an attempt to get the global community involved in this discussion and hopefully to help work through some problems that do exist in this area that do have to be solved. So please read the documents and please comment. So with that, Marla. Thank you.
MR. PLZAK: Okay. I believe we are now at open microphone. So do I have a -- I don't have an open mic slide? Oh, back this thing up please. There we go. Okay. The microphones are open for open mic, and on cue comes the Chair of the Board to do that, and I did not explain your absence, John, because I didn't know what it was until I saw I had a voice mail. So anyway, we are just at the point to start the open mic, and so I'll turn the mic over to you.
MR. CURRAN: Good afternoon. Open mic session is where anyone is free to bring any matter before the ARIN member meeting -- actually, the ARIN open policy meeting. So this could be something that's been mentioned before that you'd like to elaborate on, a new topic we have not discussed at this point. The floor -- the mics are open. The floor is available. Okay.
MR. LEWIS: Ed Lewis, NeuStar. Last evening we had the open policy hour, and there's one thing that happened there I thought was very good, was the commentary from Leslie and the staff about the evaluation proposals that have gone through the entire process, and I think it's really good to give feedback to the community for what we've written and whether that's interpretable or not. What I'd like to see is see that presented in time where it's actually put into the minutes, and I know, of course, this was the first attempt at this, and there was only four policies that were covered, and there will be more time for more of this, but it would be good to have that where we could reference that as further work.
MR. CURRAN: Ray.
MR. PLZAK: Ed, as I said last night, Leslie, on behalf of the staff, will be preparing a report and will be submitting it to the AC, and from there, they would be taking various actions from that, some of which may be that they may just decide to publish a report as is. They may decide to parse it a little bit and propose policies or seek further guidance from the community about whether policies should be done. So there is a mechanism that we are planning to use to get that information into the community.
MR. LEWIS: I have a second thing. The other thing too was during the open policy hour, the one thing I was disappointed about last night was that for the one hour of the open policy discussion, which two years ago was pretty much a free for all, we could get up and talk. This time there was a lot of prepared material that cut into that hour. I think it would be good if we could keep that back because I know that at the L.A. Meeting a year ago the meeting went on and on because we got into some discussions. It wasn't an issue this time, but I think it's good to keep as much of that hour open for the input forum as opposed to presentations of rules and such like that.
MR. PLZAK: Ed, we are also aware of that, and we are looking at things that we can do to change that. Some of the prepared material is there because -- it's there because it's -- there are first time people that need to know what's going on, but there's some things we can do to modify that obviously. We have added the comments from staff as part of the discussion point. One thing we could consider is extending the time period out to an hour and a half. So there are different things we're looking at, and yes, we do recognize that we do need to open up some more time, and yes, it wasn't a problem last night, it was a problem a couple times ago, and that was only on one proposal. So it's a variable thing, and it's always something that is a challenge for agenda management, but we do recognize that. We recognized it when we added this next little piece to the pie there. So we're trying to work this and make it as dynamic as possible, but we feel so far that the material that's there in the open policy hour is important to those members of the community that do come to that meeting. So like I said, we have looked at that. In fact, John and I just today at lunch were discussing some things we can do with that.
MR. LEWIS: I just want to pass on one comment that was made to me. When you mentioned that this material was for First Timers. One of the First Timers sitting next to me said I just heard all of this, you know, in the First Timer meeting. So it seemed like repeating it then for some people was, you know, too much. But I do want to say that I think the real reason why I'm making this point is that the grass-roots part of the ARIN meeting is important to the process. That's why I'm bothering to say this. That's all.
MR. CURRAN: I think it's a very good point. Today we had a discussion at the newcomer lunch about the fact that some of the material that might have been useful to present was actually presented in the prior night's open policy bof, and you don't want to present it twice, but to some extent though you want to get it presented before people start the sessions before we start talking about policy matters on the first day of ARIN. So whether or not we have to look at the early morning newcomers breakfast to bring them up to speed to free up the open policy hour, I think it's a topic, an active discussion, that we'll be having with the staff and the board. Okay. Microphones remain open. We're available for any and all ideas.
MR. WEILER: Sam Weiler, SPARTA. I'm concerned that the new ARIN consultation suggestion process lacks adequate transparency and lacks adequate assurances of ARIN's accountability to the community.
MR. CURRAN: Okay. Do you want to elaborate?
MR. WEILER: It seems to me that suggestions made by the community could easily get lost in that process or not responded to in a timely manner, and it would be interesting to see a summary of how quickly items in that queue or however many or few there might be were disposed of in some fashion. It might also be interesting to see in some manner a public posting of the suggestions just so that we have the public log of, yep, this was suggested and the staff or board decided to ignore it or dismiss it or act on it.
MR. CURRAN: Sure. Let me take both of those because it's actually a very important issue. So statistics on the use of the suggestion process I think are a wonderful idea so people know it is being used and where are things being handled or not being handled as they hit the various exit criteria that are possible in the process. I see no reason that that can't be included. Clearly, you've got a counter balance when you talk about posting the suggestions because some suggestions may be suggestions that someone really doesn't want or intend to be public or by their nature not everything that ARIN is doing at the board and executive level can be public at the time it's being done. An example is we have a policy very clearly regarding contracts and subcontracts. It requires certain activities and the certain aspects of it be done in an open manner, and then other aspects of it are not publicly disclosed while the actual process is going on. So if someone makes a suggestion and the nature of that suggestion is such that we can't disclose it to the community, suggestions on legal matters are often covered by something like that, then you're not going to see a public posting of it because it's to the detriment of ARIN to do so. But certainly statistics about what's going through and an acknowledgment of the items that we can acknowledge I think is a wonderful idea. Response?
MR. LEWIS: Perhaps you could allow the person making the suggestion to make the decision as to whether or not it gets posted.
MR. CURRAN: Oh, for example -- MR. LEWIS: And the staff, of course, could choose to say, well, we don't want our response to be public because it's about a contract matter.
MR. CURRAN: Well, case in point right now, Counsel presented a discussion of the fact that ARIN has litigation right now underway. By definition, there's some topics that you won't see any response from staff or any response from the board, you just simply won't see a response. We're prohibited from doing so for the interest of ARIN. So it's perfectly fine for someone to say I posted a suggestion to the process, and here it is. I see nothing wrong with that. That doesn't guarantee an acknowledgment. There will be some circumstances where simply an acknowledgment isn't possible. It's not responsible business to do so. Does that help clarify? Okay. RS.
MR. SEASTROM: Rob Seastrom. ARIN AC but speaking for myself. I would think that it would be entirely reasonable that somebody who made a suggestion via that feedback process whose patience ran out would be more than capable of speaking for him or herself and making a public policy proposal or any other form of appeal, including perhaps just complaining about it on PPML, hey, I think I'm getting blown off here. I don't necessarily see what problem is being solved by trying to make an elaborate framework for, well, do we acknowledge this publicly, do we not acknowledge this publicly. Let's give it a try and see if it works, and if there's specific cases where it seems not to be working well, maybe we can address demonstrated problems rather than playing what if.
MR. CURRAN: Okay. Microphones remain open.
MR. HANNIGAN: Martin Hannigan, (off mike). Hey, John, could we get an update on the last meeting we discussed some vendor policy surrounding some disclosures and whatnot, and that was based on some events that took place at the last meeting, and Richard Jimmerson has done a good job at keeping in touch with me about different places of the status, but I'd like to see what you guys have to say.
MR. CURRAN: Right. I'm trying to think of whether Ray or Bob or Lee would be best to respond. We have instituted a formal policy regarding contracts which sets for certain threshold levels at which we go to the public. Clearly you don't want to have to go to the public when Ray says that we need snow removal every winter for the office. It's something that the executive is supposed to handle. On the other hand, if ARIN goes out and decides it needs services that are well understood by this community and available for multiple sources, that's something that should be done in a visible manner so people understand what we're looking for and what our criteria are. So we have the policy. It has been board adopted. I believe it's posted. Ray, do you know if the contracting --
MR. PLZAK: Yeah. The contract policy itself has been done. We're still working on some procedures that we have to get done, and we want to have those in place, and then it will be there, but let me say one thing. In the meantime, we haven't done any contracting work at all. I will tell you this, that I am anticipating us using this process for a few contracts in the near future.
MR. HANNIGAN: So my point wasn't so much to try to sell you guys pencils or anything because well, one, it helps to understand motivation, and clearly my motivation is commercial. So let's -- you know, it's about money, of course. But I think that we have unique expertise in the community that it can only be sourced from the community, and those are the acts that I'm specifically interested in being able to participate in some kind of process. So I really appreciate you guys looking at this, and I think this is great that there's been some progress made, and I'm looking forward to see what things look like, and thank you.
MR. CURRAN: Yeah. Let me respond directly, Marty. In fact, it designs that high, and high is a relatively low number actually, that any high contract award of services, and that's professional services, expertise, areas such as communication services, is something that's visible as a contract process that people can participate in. So we've set a dollar threshold that will cause this process to be engaged, and once we have the procedures, we'll put it all on the web site for people to look at.
MR. HANNIGAN: Can I mention one more thing?
MR. CURRAN: Sure.
MR. HANNIGAN: We had the spam panel this morning, and I clearly was a little emotional. I gave up fighting spam in 1998. It was a fruitless battle. And I wanted to be clear though that I don't think that we shouldn't improve the quality of our data for operational purposes. I just don't think that we should specifically improve them to make the lives of spam fighters better, but if by accident we happen to make our data a lot better so that they can do their jobs a whole lot better, I'm quite okay with that.
MR. CURRAN: Understood. Okay. We've got two people up. I'll take back microphone center.
MS. SKANKS: Heather Skanks, Verizon Business. I wanted to ask formally, and ARIN may already do this later in the week, but when they go over the review of how many assignments that they've given out, if they can list the number of requests and assignments that they've received as a result of the PI /48 policy that was passed last spring.
MR. CURRAN: Wow. Repeat it one more time so I understand what you're saying.
MS. SKANKS: So in the spring the policy was passed to allow PI /48s in the v6, and I'm curious to know as a result of that how many requests you've received and how many assignments you've made or allocations you've made.
MR. CURRAN: Leslie.
MS. SKANKS: So if they can provide that information when you do your report later in the week.
MS. NOBILE: I have it for my report for Friday.
MS. SKANKS: Okay. Thank you.
MR. CURRAN: Okay. Very good. Microphones remain open. Right microphone.
MR. WEILER: Sam Weiler, SPARTA. I appreciate Mr. Seastrom's comments about chasing real problems with responsiveness rather than imagined ones. So I'd like to talk about a real one.
MR. CURRAN: Sure.
MR. WEILER: In April, I and another member of the community asked where to take questions and comments about the registration services agreement. That was asked on the PPML and carbon copied to member services. It took us three and a half months to get an answer. That is unacceptable.
MR. CURRAN: And as a result of that actually, we put the suggestion process in place to make sure that things would not drop on the floor. It's actually that event and another event of people making suggestions where it wasn't clear how to get non-resource policy suggestions submitted and handled and not dropped that we, in fact, created the process. So I actually thank you for instigating the fact that we need a way of handling these. We've talked about it for awhile, and we've done so exactly for the reason that otherwise people are unsure how to make suggestions and know that they won't get lost in the noise of other activity. The microphones remain open. There is some social thing coming up and some other things, but quite frankly, a subset of us can remain here and go on as long as you want to go. I am going to be closing the microphones in about 30 seconds. Last chance. There will be another one. Last chance for today. We always have another one tomorrow. Okay. Thank you very much. I'll turn it over to Ray.
MR. PLZAK: Thanks, John. First of all, a reminder. The registration services and billing help desk will be open until 5:30, which is about 20 minutes from now. Cyber Café will be also be open until that time. And tomorrow morning's breakfast will start at 8:00 a.m., and the meeting will start at 9:00, same time, same bad channel. And so tonight, remember to join us to Explore the Unexpected at 7:00 p.m. at 701 North 15th Street. We have food and beverages. Entertainment is the Enchanted Cave Scavenger Hunt, foosball. We have several people here that will attempt to defend titles in this off-season expedition, and also we have billiards, and you have an opportunity to have your photo taken with whoever you want it taken with, deejay, music, dancing. Transportation, 6:00 p.m., pick up the badge at the meeting registration desk, buses depart at 6:30. First bus will come back at 8:00 p.m., and then every half hour until 10:30. After that, you're on your own. Remember to complete the meeting surveys, both the IPv6 workshop, if you attended it, and also the ARIN XVIII surveys. We do use this information, and we carefully scrutinize it, and improvements that we have made over time have been as a result of these surveys. So it's a very useful tool to us. And to encourage you to do so, we have a prize, one lucky winner, and it's that 8 gigabyte USB microdrive. So thank you again to our sponsors, SAVVIS, Cisco, and Washington University, and also people just like you. So with that, let's remember the rule book for tomorrow, and maybe we can get John to do some creative hand signals, and with that, I'll see you tonight at the social. Thanks.
(Whereupon, the PROCEEDINGS were adjourned.)