ARIN XII Public Policy Meeting Minutes, Day 2, 23 October 2003 [Archived]

Call to Order and Announcements
Presentation (Read-only): PDF

Ray Plzak opened the second day of the ARIN XII Public Policy meeting at 09:00 CDT. Announcements included thanking Server Central for their meeting sponsorship and ANet for partially sponsoring the previous night’s social event.

Policy Proposal 2003-12: IANA to RIR Allocation of IPv4 Address Space
Presentation (Read-only): PDF
Presenter: Ray Plzak

Einar Bohlin, ARIN Policy Analyst, presented information about this policy proposal. Ray Plzak then provided some additional background information. Highlights included:

• Introduced - September 12, 2003
• 2 posts on ARIN Public Policy Mailing List (PPML) by 2 different people

General Comments:

• Cathy Wittbrodt had a question about the projection rate formula given in the policy. Ray Plzak clarified that special needs cases are calculated by taking the previous six month’s allocation rate and multiplying it by 9. If that is the allocation rate, there is no special need. Owen DeLong suggested the equal sign in the formula be changed to less than equal.

• Michael Dillon - How similar is this to the way allocations are currently made to the RIRs? Ray Plzak responded that there is no formal policy now and that’s why this policy is being proposed. Currently, different justifications and questions are required for each allocation from IANA. The idea behind this proposal is that IANA should deal with the RIRs the same way that the RIRs deal with ISPs. Michael Dillon also asked if the information regarding these various rates will be made public. Ray Plzak responded that it will be an internal administrative process.

• Richard Jimmerson clarified that the IANA lists ARIN’s /8s on its website. However, when ARIN submits a request, IANA only reviews the /8s that are delegated or allocated to ARIN after December 1997.

Polling of consensus:

Q1 : Approve of Policy 2003-12?
Yes? 42 No? 0

IANA to RIR Allocation of IPv6 Space Discussion
Presentation (Read-only): PDF
Presenter: Ray Plzak

Ray Plzak announced that this is not a formal policy proposal, but an informal discussion and information gathering session. This topic has been previously presented at both the APNIC meeting in Seoul and the RIPE NCC meeting in Amsterdam within the past few months. When the language is agreed upon by all four RIRs, this will be a global policy proposal to be forwarded to the ASO Address Council then transmitted to the ICANN Board for adoption.

This policy is similar to the IPv4 proposal, especially in the discussion and determination of available space. The policy will use the HD ratio to determine the RIR utilization rate.

General Comments:

• William Leibzon - People want to have sparse allocation by regions, so it may be better to go from /20 to /18 in sparse locations.

• Ray Plzak - How the RIRs make allocations to the ISPs has nothing to do with the allocation that they receive from the IANA.

• William Leibzon - Yes, it does. If we want to do sparse locations, then we want to have a larger amount of block be received from IANA.

• Ray Plzak - That could be a factor. So what would you suggest?

• William Leibzon - Slightly larger block of address space received from IANA each time and then allowing RIRs to do sparse location. But I would like it to happen only if all RIRs do it, not just by one region.

• John Curran - To follow up, you think the allocation should be larger now or should be larger if and when an RIR has a plan for sparse allocation?

• William Leibzon - If and when it has a plan for sparse allocations. If and when all RIRs agree to this plan. I think we need to wait before deciding on IPv6 policy with IANA and to decide whether we want to do a sparse location or not.

• John Curran - In the current environment, there is a method of getting an IPv6 allocation on the current allocation plan. I guess what I’m wondering is, given the current plans of the registry, is this a good allocation size or would you still recommend changing it?

• William Leibzon - We could do with a larger space so RIPE, for example, won’t have to go through and get an additional space.

• John Curran - You would recommend doing a larger size now, A, so we wouldn’t get multiple requests from someone like RIPE, and, B, because it would facilitate if we ever do sparse allocations in the RIRs, we have a block big enough already.

• Ray Plzak - One of the things you should consider in thinking about the size of the block that the RIR gets is how often do you think that the RIR should be going back to the IANA to conduct business? IANA has its own things it has to do as an agent managing IP address space. So from auditing capabilities, a shorter time might be better than several years.

• Dale Finkelson - What were the criteria that you used to pick the /20? Was that based on the utilization that you’ve seen over some period of time in the past or was it based on projected allocations or was it a random number?

• Ray Plzak - It’s probably a combination of all those, plus what I just said about trying to think about how often the RIR should go back to the IANA. The only real operational experience we have for a rapid allocation rate is what’s been happening in the RIPE NCC meeting. But again they’re allocating /32 for /29. If they changed their policy or if they went to a sparse allocation policy or something that may make a difference how they would administer /20. The operational experience in the interim, we haven’t been doing it as fast as the RIPE NCC has, however, within the first six months of the year we did allocate more at a faster rate. It’s not to say as things change in the environment in our region that we could not begin to allocate even more space. Then, again, I can’t speak for the exact experience of what the rates are in the APNIC region, but we’re kind of at a crossroads of trying to determine what that should be. So it’s like when we did the v6 policy in terms of 200 customers, a number had to be selected. This /20 number has not been really raised in the other regions. There’s been thoughts it should be media /8. Some people think it should be a /16. So I think that all those things they could make a case for them. One of the things we did factor into this was a consideration how often the RIR should touch the IANA so that there could be some kind of audit done.

• Dale Finkelson - Once you set this number, how much effort would be required to change it if it turns out that the utilization rates go up more rapidly than you expected?

• Ray Plzak - What we’re talking about here is a minimum size, if you will, as a unit. So it’s just as RIPE now with the policy from the RIR to the ISP. There’s a minimum size, but you get more by the original maximum amount. So if the allocation size was set at /20 and my 18 month projection was for 2.5 of those, I should receive three.

• Dale Finkelson - It would be continuous?

• Ray Plzak - In that case I would say yes, they should be continuous.

Policy Proposal 2003-11: Proposal and Scope of the WHOIS Directory
Presentation (Read-only): PDF
Presenter: Michael Dillon

Michael Dillon, as author, presented this this policy proposal. Highlights included:

• Introduced - August 21, 2003
• 31 posts on ARIN Public Policy Mailing List (PPML) by 12 different people

General Comments:

• William Leibzon - Whether WHOIS information is correct or not is not important for statistical analysis.

• Michael Dillon - I’m more concerned with the relationship between ARIN and the organization WHOIS information as listed. Organizations that receive resources directly from ARIN should be required to publish this information in the directory. Some allocation assignments, reassignments that happen, anybody who doesn’t have a direct relationship with ARIN but has a direct relationship with some other organization should be able to voluntarily do this and list information in the directory. We shouldn’t require them because we have no way of enforcing the requirement. If ARIN allocates you a block and assigns a block to a customer or suballocates a block to a customer, you can require the customer to do certain things if you want to and the customer can list certain things in the directory. It’s up to you, not up to ARIN. If you don’t have your customer’s information listed in the directory, then what will happen is your entire IP block will be listed under your name and if there’s any operational issues, we will contact you because you’re the one we can get to and then it’s up to you to decide what do you do? Do you contact your customer? Do you unplug your customer? It’s none of our business at that point.

• William Leibzon - But there is a requirement right now that all small allocations and assignments be listed, this is a good requirement because we are able to see how the ISP is doing reassignments and allocations. We are able to see the scope of it. Again, there are a number of reasons when the allocation is not precise but it’s still going to be useful. And you are right to verify information. But to actually require not to publish it is just a bad idea.

• Cathy Wittbrodt - To clarify, when an ISP gets a block from ARIN, they’re required to SWIP that information when they hand over those blocks to the customer, so it’s not an optional thing for an ISP to have that information about their customers in the database /29 or longer. When you go back to an ISP for another block of address space, you better have SWIPed all this stuff that you handed out. That’s what they [ARIN] use to judge your utilization.

• Michael Dillon - I’m not suggesting that ARIN should no longer collect information from people in order to make decisions about allocations. ARIN should continue to do so. I am talking now about the information which ARIN publishes and makes public. I fully expect that ARIN will continue to collect the information through SWIP and through other means. This is not about that. This is about the information which is published.

• Cathy Wittbrodt - SWIP is publishing the information anyway.

• Michael Dillon - No. SWIP is submitting the information to ARIN, which at this point automatically publishes it. If this policy was enacted, ARIN would no longer publish everything that was SWIP, some of it would be kept private and some of it would be published.

• William Leibzon - It is better to have some information than to have no information? Does Michael agree with that?

• Ray Plzak - No.

• Leo Bicknell - I think William did make a good point in that ARIN’s process is open. WHOIS is an integral part of that, and excluding that function in this policy is a bad idea. Similarly along his concerns, ISPs are not open processes. Generally they are companies. It is not clear to me that they need their entire dirty laundry aired out for the entire world to see. ARIN clearly does need that information. ARIN may need to make some of that in summary form available to extend the open process, but we need to make that distinction. The ARIN process is open. People do need ways to verify that. Maybe WHOIS is not the way, but that is the way it has been.

• Owen DeLong - I think this is just generally a really bad idea because there are so many other good reasons to publish the data. Sentence 2 is also a bad idea because I think keeping the process open is a good thing. I think that the problem you were trying to solve here is POC verification, and I think there are better ways to solve POC verification than simply deleting the POC data from what is published. Deleting the data is not a good way to make the data better.

• Marla Azinger - I do not agree with your document. Being a small company, we only have so many people we can hire for abuse reports and complaints. If we take that information off of WHOIS, we’re going to have to increase our abuse team.

• RAY PLZAK: You don’t have to increase your abuse team.

• MARLA AZINGER: You’re missing the point. One, I don’t like it because it will increase abuse complaints that come directly to the company and don’t go to the customer first where we have very capable customers handling those issues. Two, I don’t agree with having to update POCs every three months. That’s just too frequent. Three, if we are going to do it, I do think it’s a good idea to update POCs, which I do regularly, some people don’t, so you have to take an action. Don’t make it so quick and don’t say you have to update every POC like ARIN did last time, because I’m still updating POCs that’s still the same. It’s a lot of time, a lot of work for something that didn’t change.

• Michael Dillon - Since you have a direct relationship with your customers, you can require your customers to do that. You can tell your customers a part of the deal is when you sign up with our company, you have to follow the rules here and list your information in the WHOIS directory and have it point to somebody who is ready, willing and able to deal with abuse issues and you have to be able to do at least click on an URL and e-mail once every three months to verify your contact information still works.

• MARLA AZINGER: Good point. I love this area, I really do, but customers are lazy. And a lot of our customers when their POC stuff changes, I get that information. They send it to me, but they’re not about to deal with ARIN because I am the ARIN liaison, and they are scared of ARIN and they don’t want to deal with it no matter what. So to tell my customer you have to deal with ARIN directly in terms of what your information is, they’re not going to be happy and I don’t want to be put in that position.

• Michael Whisenant - I think the intent really is to have someone who is willing and ready to act on information. That really has already being available by looking at the parent directory within the existing ARIN database. I think generally this is a bad idea by eliminating the majority of the hierarchy that exists today. All you’re wanting is ARIN in their first relationship rather than dealing down with the suballocations; that those second tier customers may eventually begin to have a relationship with ARIN, have them supply this information, make sure it’s current, understanding the process is a good thing for them to learn what’s going to be required when they evolve to the point they deal with ARIN directly. In addition to that, I do believe that the three month is entirely too aggressive. And I disagree with removing data from the directory. I believe that there’s another proposal we mark it as unverify is a better idea than simply to move information from a directory simply because a person is too busy within 60 days to respond.

• Comment from the floor - I do use this information for research purposes. I much prefer that you mark it as unverified because even if that person is not there, if I know the organization, it’s possible I could go to their webmaster, whatever their organization is I can find it in a different way. But as soon as the information is gone, I’m totally lost.

• Michael Dillon - If ARIN made available some type of summary information, that said Organization X has within the last month allocated three /20s, 15 –

• Comment from the floor - That wouldn’t be close to what I need. This is the amount of the allocation in this particular part of the country, these are the people who are getting it. I use it to map for geographic reasons when we’re trying to do summaries, who is requesting sort of the locations on the net. These things even though WHOIS is bad is better than anything else.

• Chris Liljenstolpe - I think removing the data from WHOIS is inherently bad. Once it’s gone, it’s gone. Generally companies don’t pick up and move their buildings. So addresses, organizational information is still there. I can hunt and peck and try and find someone else at the organization. I’m much more in favor of marking that data as potentially unreliable. The other proposal that’s out there to mark it is potentially unreliable I think is a much better proposal than simply erasing it from the database and making it unavailable to anyone. Thank you.

• Louis Lee - The text “unreliable” might be construed as the person being unreliable. So “unreachable” would be a little better. I want to strike the text that says “within the ARIN region” because organizations and individuals might not be within the ARIN region at the time that you check the data. They might have moved out.

• Bruce Campbell - Point 2, is that really another way of saying you want to remove unreferenced objects from the database?

• Michael Dillon - No. It’s really a way of saying that I want the contact information in the database to be certified that the people whose contact information is published are ready, willing, and able to communicate and act upon that communication. I want the database information to be somehow in some way certified and then verified.

• Bruce Campbell - I think you’re trying to do too much with one proposal; the database verification method is covered in another proposal and an access method could also be a separate issue.

• Bill Manning - It might be useful to accept all incoming entries into the database as not verified or without key. And when they provide an X-509 key or they do their registration, that would be a way to, in Michael’s words, certify. And so you basically come in as this is unverified data and only after they provide the key you say that’s verified because the verification process occurs at key exchange.

Policy Proposal 2003-16: POC Verification
Presentation (Read-only): PDF
Presenter: Andrew Dul

Andrew Dul, as a member of the Advisory Council, presented this this policy proposal. Highlights included:

• Introduced - August 11, 2003
• 1 post on ARIN Public Policy Mailing List (PPML)

General Comments:

• Owen DeLong - I think this is an excellent approach to the problem. I have no objections whatsoever to this policy as written.

• Michael Dillon - I think it’s a bad idea for processes like this be entered into policy documents because it ties the hands of ARIN staff. And I would rather trust that staff would implement a reasonable process and then over time tweak that process to make it better rather than encapsulating it into a policy like this. It has things in it like ARIN should mark the POC as in process. That’s reasonable to have in a policy. But the rest of it is too detailed.

• William Leibzon - I think it’s a good future policy proposal. I kind of agree with Michael a little bit. I also want to actually be able to see verification of a particular resource. For example, an e-mail address, I want to see if this e-mail address has been verified.

• Andrew Dul - Basically if someone returns an e-mail and says everything’s verified but you don’t call the phone number to check that it works, it’s not verified?

• William Leibzon - Right. It will say e-mail verified, phone number it doesn’t say anything.

• Ray Plzak - Andrew, since you are in this proposal advocating a number of things that ARIN staff should do, have you done any kind of an analysis or resource impact on ARIN staffing?

• Leslie Nobile - The idea of publicly displaying the status of a POC basically would be giving information to people that probably shouldn’t have it. Because of the hijacking issues, making that kind of information publicly available might not be such a good idea. Making it internally available is a good idea and that is something we are doing. We have a status field for every POC in our database. It’s unverified, it’s verified, it’s suspicious, it’s suspended.

• Alex McKenzie - In general, I certainly support anything that verifies POCs. My concern centers around if somebody external is going to complain about my POC, ARIN has no way of validating whether or not this is a complaint because they’re unsatisfied with the response or they’re complaining simply trying to tie up my time and resources. In principle, I agree. I think it needs some work. I would encourage work to continue on it but wouldn’t support it. Thank you.

• Andrew Dul - I think one thing that I put in here originally to try to combat the random customer from the other side of the world bugging you because they don’t like you or that kind of thing was the time frame for verification is very long and in some people’s opinion, being a year, and there’s also a statement regarding that if it’s been verified within one year, we don’t go out and try to verify it again. So you at most have to verify it once a year.

• Alex McKenzie - But I guess my interpretation of your statement is based on the external website is the fact that even if it is verified within that year and somebody registers a complaint, that it could go into a state that it then has to be re-verified or some other communication. It’s just a general concern, I don’t like the principle of the idea of somebody from the external community writing that this POC is not available or is inaccurate and our experiences show it gets abused. That’s just an overall statement.

• Owen DeLong - It would be good to let staff have flexibility on the time frames for the state changes in the database. The one year provision is a very reasonable compromise between minimizing the impact of organizations through complaint DOS, for lack of a better term, and verifying the point of contact information is reasonably up-to-date. Making it a little bit more generic in saying that “all reasonable efforts to contact” or words to that effect instead of specifying telephone, e-mail, whatever, would be good. I don’t think we need to separate the verification flag out by contacting method. If you get a phone call back from somebody that says yes, that’s my e-mail address. Yes, that’s my phone number. Yes, all the contact information there is correct, that you can consider the contact verified. The same thing for an e-mail. So I wouldn’t worry too much about that level of detail, but otherwise I think this is a good thing.

Policy Proposal 2003-5: RWhois Server Use
Presentation (Read-only): PDF
Presenter: Mark Kosters

Mark Kosters, as a member of the Advisory Council, presented this this policy proposal.

Highlights included:

• Introduced - March 6, 2003
• It was presented at ARIN XI in Memphis. The current text was posted on PPML on September 22, 2003. There were no substantive comments on PPML on this proposal.

General Comments:

• WILLIAM LEIBZON: I think you just need to work on the text. Other than that, it’s a good idea and the main point of replacing RWHOIS by distributing information is a good idea.

• Bill Manning - RWHOIS has been attempted to be shot in the head repeatedly over the years and it continues to thrive. There is apparently another proposal on or a series of proposals to replace it on the hoof. Should we be encouraging people to adopt RWHOIS if there’s something else that’s relatively imminent?

• MARK KOSTERS: The actual text says RWHOIS, but it’s really meant to say distributed information service. So whatever is to replace RWHOIS, the same policy would apply. This is an attempt to say if you put up one of these distributed information servers, you have some requirements that you need to follow, and that’s the whole intent of this particular policy.

• Michael Dillon - I think this policy is premature. ARIN engineering made a presentation of technical deficiencies at the APNIC XV conference in Taipei in February. It’s that the code architecture is not good. It’s that referral doesn’t work, various other things. Ssince there is some work being done right now to fix the tool, I think that we really should wait until that’s done before we put the policy through because right now a number of companies, mine included, are using RWHOIS because we want to have a distributed WHOIS service. But we are very severely constrained and restricted by this very poorly documented and very awkward to use tool that we have to use in order to do it today.

• MARK KOSTERS: I don’t think it’s premature because it’s already fielded and it has guidelines for those who have already fielded their distributed information services.

• MICHAEL DILLON: I think what I’m really saying is a lot of the reason these issues addressed in your policy and a lot of the reason these issues exist is because we are struggling to function with this bad tool.

• Alec Peterson - Mark has already accepted responsibility for RWHOIS for better or worse and it has already been disclosed by many people that RWHOIS is not ideal for this. But these requirements regardless of whether or not you feel they are necessary for RWHOIS, that’s not really part of this discussion.

• MICHAEL DILLON: No. And I was referring to the fact there is already work going on within ARIN to address the technical deficiencies of the existing tool. And I believe we should do that first before we start setting policies saying the company – this is what you must do with the tool when – as one of the users of the tool, what I would really like to do is first implement the improved version and then I’ll address all of these issues with that new, improved version, which will hopefully make it easier for me to address all of these issues in the policy.

• Owen DeLong - We’ve got a tool. It’s out there. It’s in use. We’ve got operational requirements. This policy sets forth operational requirements for us to be able to use the tool that exists today and whatever tool gets to be played in the future. And I think it’s got to have those operational requirements specified in the policy so we can actually use whatever tool today and in the future to get the data we need.

Polling of consensus:

Q1 : Approve of Policy 2003-5?
Yes? 24 No? 5

Hijacking Report
Presentation (Read-only): PDF
Presenter: Leslie Nobile

Leslie Nobile made a presentation about the recent IP address space hijackings.

• Hijacking is defined as “Individuals targeting mainly legacy IP address blocks to make unauthorized changes to registration records in WHOIS. The WHOIS data then inaccurately reflects this false information and gives the illusion that the individual now has some authority over the resource records. Affected resources include IP addresses as well as AS numbers.”

• Hijacking misleads network operators, compromises the WHOIS database, creates liability issues, increases staff workload, slows response times, and increases staffing and legal fees.

• From April to October 2002, 110 cases were opened. 11 cases were found to have no evidence of hijacking. 84 cases were closed and 15 cases are still pending.

• ARIN’s actions:

• To help ARIN combat hijackings, ensure all of your and your customers’ ORG & resource records are updated and use stronger authentication when available

General Comments:

• Owen DeLong - Requiring text ID and raised corporate seals idea is wonderful for your customers who are incorporated. However, there are at least three, maybe two allocations in the database that I know of personally that are individuals that don’t have a corporate seal and aren’t particularly interested in providing a Social Security number to ARIN.

• Bill Woodcock - I think this is a really good idea because it removes a lot of the arguments that we have right now between people who have legacy records and can’t see why they should have to worry about paying money long after they help build the Internet versus the people who are getting IP addresses right now and paying money into the registries and working hard and have no idea why these old geezers should be allowed to freeload. Neither of these parties are in the wrong. They both exist. There’s no way around that. This is a way of removing any cross subsidy between, and I’m strongly in favor of it and I think you all should be too and I can argue with anybody that thinks otherwise on my own time.

• William Leibzon - I also agree – it’s going to allow ARIN to lock down all the old records and basically allow any changes unless they want to play by new added rules. ARIN has to have some financial records to prove what kind of company it is. It’s going to solve quite a bit of problems trying to pin down whether it’s a valid company or not.

• Robert Seastrom - I was talking about the transparency issue and the historical record, and I really think that would go a long way for its people being able to tell ISPswhether the information is to be taken at face value or not. Obviously if people were to look at the historical information on my personal blocks, you would see a few address changes, same person, you know, across multiple changes as the POC and assume that that would play the reason of the evolution of the corporation or individual. And I think that would be a huge step in the right direction. It could be a step we do retroactively. The question is do the data exist?

• Bill Manning - I almost agree with Bill Woodcock, but I am concerned that legacy holders may have that particular snobbish attitude of we’re the old guys and we were here long before you, if we move them unilaterally to some legacy database, they might object to that as well. I would encourage ARIN to spend a little bit of their phone time talking with the legacy holder as opposed to just tracking down hijackers to invite them to join ARIN and to participate in the current process and inform them that one of the choices we have is that we expect to move you into this other thing that’s going to be relatively skim, pretty much static, and we’ll just leave you there until you decide you want to come out of your suspended animation and join the real world, and when you do, here we are. There ought to be a dialogue with the legacy holder before we move them.

• Michael Dillon - It strikes me that this conversation about moving legacy address spase into legacy databases is sort of another variation of the previous discussions we’ve been having on verification of data in the WHOIS database. I don’t think it should be separated from that. I don’t see any difference between the address space that I acquired a few weeks ago from ARIN and a legacy block that has up to date contact information and whether that actual organization is a member of ARIN or not. If that contact information is up to date on that legacy block, it really isn’t a legacy any more. I think what we’re really talking about here is the set of address blocks that don’t have up to date contact information. We don’t know who they are, what they’re doing, where they live, et cetera.

• Bill Manning - I think from a lot of people’s point of view, the difference is whether or not we’re paying fees to ARIN. Whether or not they are contractually obligated to ARIN and whether or not they have signed a contract acknowledging that they do not own the address space they have; that there are a lot of people who have address space that they received prior to joining ARIN under an informal agreement to book something like it being given to them. And there are a lot of people who do not want to sign a contract with ARIN acknowledging that that is not the case. And so this is the way of removing any financial burden of supporting those people from the regular ARIN membership.

• Jim Boyle - I believe that if ARIN is responsible for these addresses in any way, shape or form, keeping track of them or anything else, legacy or not, we should all have to play by the same rules. They should have to pay, they should have to keep track of all their stuff, and I could bet there’s many people that won’t agree with that.

• Bill Darte - To me whether it’s in a separate database or whether it isn’t, I’m not so concerned about that. But I do think it provides a wonderful opportunity to try to contact legacy folks and say, “These issues are out there and frankly we’re not going to be able to protect you as well as if you aren’t someone who we can authenticate in this process.” So I think it’s a great opportunity to go out and challenge those folks to be involved.

• Owen DeLong - As someone who holds blocks in both categories, I would be pretty upset if I got told that I just sort of had to suddenly start paying ARIN for that legacy block. Even though it wouldn’t affect me financially, ARIN doesn’t have any real authority that’s been granted to them to do that. There’s no real contract between me as the owner of that block and ARIN that allows them to suddenly tell me I’m going to start paying them for it or anything like that. And I think it would meet with some pretty strong legal challenges with a lot of other people in a similar situations. Hijacking is an issue. Hijacking is an issue that is taking a lot of ARIN staff time, and I don’t have a problem with that block being moved to a legacy registry and having the choice of paying fees to get it into the registry that I can update and that ARIN will spend time on. I think it’s perfectly reasonable for ARIN to move those into some place they don’t have to deal with.

• Bill Woodcock - To clarify the options that were on one of the slides Leslie put up.

RTMA Working Group

Working Group Chair and Moderator: Cathy Wittbrodt

“Miscreants, Hijacking, and Bogons - Oh My!”
Presentation (Read-only): PDF
Presenter: Rob Thomas

Rob Thomas made a presentation about security.

Sponsors