ARIN XVIII Public Policy Meeting
Draft Transcript
Wednesday 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."

Meeting Called to Order

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 Timer 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?

SPEAKER: Yeas.

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.

NRO NC Election

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 info@arin.net, and you will receive a prompt reply. So with that, I say thanks. Okay. Moving on.

Regional Policy Updates

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.

Internet Number Resource Status Report

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.

IPv6 IAB / IETF Activities Report

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)

Blacklisting Round Table

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 101.78.41.3, 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 info@arin.net. 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.

2006-3: Capturing Originations in Templates

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 mo