Your IP address could not be determined at this time.

ARIN XVIII Public Policy Meeting Draft Transcript - 12 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. You're semi-awake. Let's get started here. First of all, let's thank our sponsors, and people like you. Okay. Okay. A reminder, visit the Cyber Café and Help Desk hours are shown on the slide, and remember when you visit, sign up to win a network storage link from Linksys, and the winner will be announced Friday morning, and most importantly, you must be present to win. So reminder about the Help Desk and Cyber Café, both registration and billing Help Desk, hours are there or you can do it by appointment. I don't have any numbers yet from Bob as far as the amount of business that he's been getting, but Leslie told me that there's been somewhere in the vicinity of close to 30 people in a short period of time over yesterday, so it's really, really good to see that you -- that people take advantage of the service that's being offered here and I would encourage you to continue to do so. So anyway, we did conduct an election yesterday and it was a good election, let's put it that way, we didn't have any real problems with it, as far as I know, and the winner is -- I hope he's in the room -- Louis Lee. Now they're going to kiss and make up, okay, good. All right. So Louis' prize for winning this raffle is another three years of working with ICANN. Congratulations, Louis. Okay. We had a first-timer lunch yesterday and a raffle, and we've got 22 first-timers that are vying for the prize, and I guess they've got the stuff up here, it's over here, and so we're going to do the drawing. Now, I need some assistance. First of all, a reminder, we're giving out a digital wireless audio amplifier, 5.8 gig, so it's heavy, so got that. Life is hard when you're your own prop man. Now, I need a volunteer from the audience to come up and help me. Now, I warn you in doing so, you may be up here for a long time if we have a repeat performance from the other night, so -- and Andrew is not in the hopper, because Andrew is definitely not a first-timer to ARIN meetings, so -- Hyunseog Ryu. All right. So people do win raffles. Susan, sorry you can't take that one home. She's still got tomorrow. Okay. Speaking of which, we do have raffle prizes for the meeting surveys and so, please, if you attended the IPv6 workshop, please fill out the survey. We would like to know what you thought about it, and Jordi in particular likes to know how it's going because he does these workshops in a lot of different places and your input to him is very valuable. It helps him to improve the things that he's doing, so please take time to fill that one out. The ARIN XVIII survey, please fill it out because the improvements that we can make to the meeting is a direct result of the input we receive from you. If you don't tell us, we don't know what to do. So you earn a raffle entry, one entry per person, one lucky winner, and as I've been saying, we've got this 8 gig USB microdrive and one lucky winner for a second prize. We had a donor that said, hey, I want to contribute something else, and so Shaw Communications has -- this is getting to be a habit, coming up with these last-minute donations of raffle prizes, but Shaw has donated a cable DSL firewall router, so now we can have two lucky routers -- two lucky winners, not lucky routers, two lucky winners. So you now have two chances to win, so Dave Wodelet from Shaw, thank you very much, so let's give Dave a round of applause. Okay. Reminder, if you're not subscribed to public policy mailing list, please do so, because this is where you can express your opinion. It is the forum to raise and discuss policy-related issues. All policy proposals are first introduced on PPML, so there's the subscription information on the screen, and remember the rule book. And let's see if we can get John to do some signaling today. He didn't do it yesterday. Okay. Here we go. You can do this, here. There's all kinds of things we can use here. Anyway, so with that, I guess we say thank you, and right now I would like to take a brief interlude for a word from one of our sponsors, Don.

Word From Sponsor

MR. BERTIER: Thank you very much, Ray. My name is Don Bertier. I'm the chief security officer with Savvis Communications and I wanted to take just a real quick moment on behalf of Savvis and our 2,200 global employees as well as from Bill Darte and Washington University, St. Louis, Center for the Application of IT. We are very proud and appreciative of ARIN selecting St. Louis as the site of these meetings this week. It's been a great experience for us. I asked Tom Armstrong from our IP team, if I had to say something nice for ARIN, what would that be, and he said, you know, as we've gone through some of the integration pains as Savvis acquired what was Cable Wireless America which included Exodus and Digital Island and lots of piece parts, registration services has been just tremendous to work with on how we have to go and transfer IP blocks and IS numbers and the various other pieces of the equation that really can be very painful to the business, and that's been a great asset to our team, we appreciate the help. I also wanted to thank Katie Flowers for the great work she did yesterday on the blacklisting round table. I think that's an area that affects us all and our customers, for those of us in the service provider space and a very important topic for people to have a good dialog about. So again, welcome to St. Louis. Great to have everybody here. Have a great continued session and again, thank you.

MR. PLZAK: Okay. So I hope everyone had a very good time last night at the social. I have some photographs I would like to show people later on. Unfortunately, we don't have a traveling scanner, so I couldn't get these things scanned to throw up on the screen, but there's a couple interesting shots of Paul Rendek from RIPE NCC and me, so, and then I've got three rolls of film here, so if you see me, I'll be glad to share them with you, but I have them. I hope that many of you -- in fact, I know many of you have seen the movie that we introduced yesterday, and you know, when you put together a movie and when you watch a movie, there's always a roll of credits and stuff like that and it says produced by, directed by, you know, screenplay by, edited and all that good stuff. Well, if you look at the credits rolling on the end of this film, you don't see that. What you see is the thanks that we have appreciated the community for helping up to put together this film. Now, we did in fact have a producer, we did in fact have a director, we did in fact have a writer, a screenplay editor, a site director and editor and that's a rather large and cumbersome team to work on this, and so I think in the comments I've received about this being a very professional looking film and everything else, it's really greatly appreciated, and so I would like to take this moment right now to introduce the entire production staff of the film to you, so Erika, would you please stand up. That's Erika's embarrassing moment for the day, and thank you very much, Erika, it's a lot of hard work and I received a lot of good compliments on the film, so it's a job well done, and so Susan has to take care of you when it comes time for bonus time this year. Having gone through those pleasantries, let's move on to the agenda for today.

2006-2: Micro-allocations for Internal Infrastructure

The first order of business is 2006-2, the policy proposal for micro-allocations for internal infrastructure, and this proposal provides for a non-routed IPv6 micro-allocation to organizations requiring non-contiguous IP space for their internal infrastructure. The AC shepherds were Stacy and Bill. Brief history, proposed 9th of February of this year and designated a formal proposal by the Advisory Council on the 17th of February. It was first discussed in a public policy meeting at ARIN XVII earlier this year in Montreal. The community consensus from both the list and the meeting amalgamated and looked at by the AC was that this proposal should be revised and the shepherds were to work with the author, and in fact they successfully did put together a revised set of language which was done on the 18th of July, and so we are here at ARIN XVIII to discuss that. So counsel did look at this in March of 2006 and saw no liability risks to ARIN. Some staff comments as of October of 2006 and as hosted on the PPML said first of all, please define what you mean by justification and it needs to be a little bit more clearly defined and what are we supposed to do with IP address blocks to be routed, you know, should they be revoked. And the policy isn't really clear, but would this also apply to end user assignments and not just to ISPs, and if this policy was to be enacted, we would change it by adding a new section 6.10.2. From the standpoint of implementing it, what would it take? We see this as having a minimum impact. We could do it within 90 days from the ratification by the Board of Trustees. Requirements primarily are a guidelines change and some staff training. PPML discussion, 103 posts by 30 people, basically seven for, one against, and comments -- illustrative comments are one person -- or theme, "I support this proposal. This is an excellent technical reason for a micro-allocation that does not harm and only good for our networks and customers." And another comment is that, "Public reversed DNS delegations are important." So the full text of this proposal is in your packet and as well as it's at the CL URL. So at this point I would like to ask the author of the proposal, Jason Schiller, if you could come up, and/or Heather, so we have a team, okay. 2006-2, Micro-allocations for Internal Infrastructure; Heather Skanks/Jason Schiller.

MS. SKANKS: So, okay. I hate public speaking, but we're going to work on that. This policy was previously reviewed in April. 14 folks voted for it, against, 29 folks supported it with revisions and a significant number of folks abstained. Why was that? This is a sample slide from the proposal that -- the speech that we gave in April. There's a lot of information, it was very technical, and I think that a lot of people -- after we gave our presentation, a lot of people came up to us and asked what exactly did we mean, they said that they weren't sure what we were quite talking about and how this applied to them. So there was a lot of other confusion resulting from the way that we wrote the policy. We actually had rewritten the entire section on micro-allocation, which kind of overstepped what we needed to do. What we should have done was just take a step back and only write the part regarding the -- to address the technical problem that we were experiencing. So in this revision the editorial rewriting has been removed and we cleaned the policy up to be much more concise. So what's changed? This is the actual policy that we've proposed this time and you can see that it only addresses IPv6 allocations for internal infrastructure. We removed the part requiring that the space be not routed. Basically the policy says that in addition, if you already have v6 space, you can get a /48 in addition to it that's not contiguous for internal infrastructure if you have technical justification to explain -- in order to solve a technical problem such as alleviating BGP convergence. So what happens in v4? You go to ARIN and you get a net block, ARIN gives you a /16. You pull up or advertise the whole net block to everyone in order to draw traffic to you. You use this for all of your addressing needs. You give some of your infrastructure -- some of the address space to your infrastructure and some to your customers. You give your customer, ACME Voit, a /24 and that customer wants to have two connections from you, one for primary and one for fail-over. They announce the same net block that you've given them out of both of their connections. The edge router they're connected to tells all its neighbors that this /24 is reachable through the edge router's loop-back address, which happens to come out of the same address space that you've already gotten from ARIN, that same net block that you've gotten. When one connection goes down, the other connection should pick up, but because you numbered the loop-back for the edge router out of the same aggregate, when the primary connection goes down, the loop-back still is reachable in BGP because you have that aggregate pull-up. So if I had a white board -- there's no way to do this. So on the bottom you have the -- that's your customer and they announce the net block that you've given them through two separate connections. You can see that the two connections have different loop-back addresses, but all of that address space comes out of the same pull-up that you're sending to everyone else. When the primary connection goes down, 10.0.0.4 goes away, but in BGP you can still get to it through the pull-up, so all of the traffic that would have gone down the primary connection one is now going to the pull-up until BGP times out, in which case the route will become invalid and the traffic will move over to the second connection. These sites just save -- the same thing that I've said. The problem is that there are applications that are really sensitive, such as voice-over IP, so having the application not -- having the traffic pulled to the pull-up route for three minutes is a very long time for an application like voice-over IP or payment processing transactions and things like that. So a solution required that net blocks for loop-backs not be part of the aggregate pull-up that goes into BGP. This wasn't a problem in IPv4 because a lot of folks had multiple IPv4 net blocks, so we just took an existing v4 space that we had, didn't put in a pull-up and used that for our loop-back, so it wasn't in BGP. In v6, though, ARIN policy provides for single aggregate v6 block set up to give -- and if you were to go back to ARIN for additional address space, it's set up in such a way that you would get a contiguous address block, so the block that you put in your pull-up would still be in BGP. If you broke up the block that ARIN gave you into smaller pieces, you would have to add more routes to the routing table and it would sort of defeat the principle of v6 aggregation as important for -- is one of the highest goals for v6 assignment. So we looked at private addressing as well. Part of the problem is that global uniqueness is not guaranteed, even with the statistically global RFC that was passed -- or I'm sorry, the statistically unique RFC that was passed, global uniqueness is not guaranteed, so the only way to get that is by having a registrar assign the address space to you. The reason that private addresses weren't such a great idea is that it causes confusion in troubleshooting, you don't want private addresses to show up in trace route, folks would filter the traffic and this is an instance where we want DNS to work correctly. Staff concerns. The ARIN staff was concerned about providing technical justification, what qualifies as technical justification, and when the AC looked at it, they thought that it was very narrow and that justification must include why a suballocation of what you currently have can't be utilized for reasons covered here, that you don't want to break up the address space that you already have, that you don't want to add more routes to the routing table. Technical justification would include where you need to resolve a convergence issue, the need to use DNS, and it's pretty clear when you're trying to show that the address space is going to solve a problem like this. So one of the other concerns was about ARIN not being able to verify how the address space is being used, but there are already policies that allow for globally unique address space to not be routed, there's already an existing IPv4 policy, so it seemed like it shouldn't be any different for v6, and the other question is how do they handle it when organizations filter ICMP traffic, so applicants should be able to provide documentation on how the address space is being used including possibly internal writing information to be able to demonstrate that they are using this address space efficiently. The other question was what to do if the blocks are routed. We're not opposed to ARIN revoking the address space if it does become routed. The intent is that it shouldn't be, but ARIN doesn't want to make a policy that dictates how you should set up your network, but there's already similar text that says that ARIN may invalidate an allocation if it determines that the requirement for the address space no longer exists, so if the technical requirement that you're trying to solve by not advertising the address space no longer exists and you are advertising the address space, then ARIN can revoke the allocation and you can renumber into the address space -- into your aggregate address space that you have. Other comments from PPML. This policy will have zero impact on the internet routing table, it's not wasteful, it's a /48. The members are opposed to a sunset clause. There's not much need to have to come back to reevaluate it because it doesn't affect the internet routing table if it's not routed and because it's very -- there's very few number of cases where you might need to use this, so the amount of address space expected to be given out for this is very small, and by the fact that a previous policy was passed for v4 allowing for globally unique address space to be used for non-connected networks, members see value in global uniqueness for networks that don't connect to the internet. Questions?

MR. CURRAN: Okay. Microphones are open for questions. We'll keep folks up here so they can address them if they want. Okay. Leo.

MR. BICKNELL: Leo Bicknell, ARIN Advisory Council. My memory at Montreal is there was some discussion, but I do not remember the details, that this could possibly be fixed or at least improved by router vendors changing the way the software works, and I'm curious if anyone remembered more details of that discussion and if any vendors were contacted and researched that solution.

MR. SCHILLER: So one of the comments was that it should be fixed in the protocol and one of the comments on PPML was that it's already fixed, UNIBRIL already has the ability to do route resolution policies that can restrict what routes are considered as candidates as next ops. The problem is this isn't supported by all vendors in stable code. This was discussed a little bit at Montreal. I believe somebody from Cisco stood up and said that Cisco has this functionality. Unfortunately this functionality is only in 12/2 T train code, which is generally not considered stable or useful to ISPs. There's other vendors that don't have this functionality at all. I have pursued it with Cisco. I'm actually in the process of writing a draft RFC with John Mitchell from Cisco to try and make this functionality standard. The really big problem with that is that it's going to take some time to pass the standards bodies, and then in addition to that, it's going to take time to get implemented in everyone's code and then eventually roll down into stable code that people can use. Policy can solve this problem now and it doesn't seem like this is a wasteful policy or bad policy or has any negative impact on the internet, so I would say let's solve it now with policy, let's let the vendors catch up and maybe in the future we can revoke this policy if need be if you think it's that important to reclaim a couple /48s.

MR. CURRAN: Leo, would you be for or against this policy, given that information?

MR. BICKNELL: I believe I'm probably for it.

MR. CURRAN: Okay. Thank you. Microphone over here.

MR. PALET: Jordi Palet. I am against this policy as currently is written because I believe, yes, a /48 is not wasteful, but if we start using a /48 to solve all kinds of problems, then it becomes another one and another one and another one, and especially my idea, I already talked with Jason, is the recent technical solution for this which is ULA Central, the only problem with ULA Central is that it has not been advanced by let's say political reasons. Basically the reason is there was not an agreement between IETF and the registries to move ahead with that. I think it will be more useful and also solve other similar problems or situations to actually put some effort to define with the registries and with IANA what we can do with this ULA Central, and if necessary, if the registries want to take care of this central registry, maybe do a small modification in the ULA Central rough to say instead of random allocation of the prefix, to make it contiguous so it can be broke for as many registries as they are able. Right now it's five, but maybe in the future it's more, whatever. I think that will not only solve this problem, but many other problems that could appear in the future.

MR. SCHILLER: I don't understand why you would be against this policy. It seems to me if the members here voted to adopt this policy and ARIN adopted this policy, then it would clearly show that this RIR is definitely amenable to managing an IP space for the sort of allocations that you're talking about, the ULA Central allocations, and I think passing this policy will send the right message to the IETF that at the very least ARIN is amenable to moving forward with ULA Central.

MR. PALET: Well, one possibility then will be to move forward with this policy, but state somehow when ULA Central -- because I understand that you need it quickly, right? So one possibility will be to say let's move with this policy, but once ULA Central is able, let's change the prefix to the ULA Central prefix.

MR. SCHILLER: I'm certainly amenable to that. I also want to point out that it's probably going to take three to six months for this to get implemented. That may be enough time to send the signal up to ULA Central and for them to sort out their issues and provide the block prior to this policy actually being implemented and the addresses given out.

MR. CURRAN: Thank you. Front microphone.

MR. DeLONG: Owen DeLong, C2 Company. Perhaps I'm a little confused, but as I understood it, you removed the part that said these addresses can't be globally routed, and yet you're trying to sell the policy on the basis that these addresses can't be globally routed.

MR. SCHILLER: Not specifically in those words, but yes. We removed the text that said these addresses must not be routed on the internet, but the justification to get these addresses clearly shows that you're trying to solve a BGP convergence issue and the way you solve it is by not routing those addresses as an aggregate. Did that answer your question?

MR. DeLONG: It sidestepped my question nicely, but no, it didn't really answer it. I would support this policy actually if it did specify that the addresses were not to be exchanged.

MR. CURRAN: Can I ask a question just to confirm? Was the reason that the statement that said these addresses were not to be routed because generally ARIN's -- our policies don't specify routing requirements?

MR. SCHILLER: Yes, that and -- that was discussed at the last meeting and also on PPML, and the consensus was that ARIN does not set routing policy and it should be removed.

MR. CURRAN: So given the text as is, you're saying you would not support the policy?

MR. DeLONG: That's correct.

MR. CURRAN: Okay. Center rear microphone.

MR. DIVINS: Dave Divins, ServerVault, and I support this policy. As somebody who this policy absolutely does not affect, and if it ever does affect me, I've done something horribly, horribly wrong, I think there's a technical need. You know, somebody's proposed something that there's a technical requirement for that I feel they justified, probably doesn't affect 99 percent of the community and, you know, so I would support this because there's a technical need that's been displayed.

MR. CURRAN: Okay. Thank you. Center rear microphone. I'm going to point out there are four mics and three of you in one line. I'm not saying there's anything wrong with that, you'll probably get there at the same rate, but okay, Randy.

MR. BUSH: Certainly, John, you should be able to keep track of the queue no matter how many there are, we'll trust you. Randy Bush, IIJ. I was an objector to this proposal. I remove my objection. I support it.

MR. CURRAN: Thank you. Okay. Center rear mic.

MR. POUNSETT: Hi. Matt Pounsett from the CA Registry and ARIN Advisory Council. I just wanted to comment on a couple things. I do support this proposal. I think it's -- you've got a good technical justification and I think the edits you've made are good. I just wanted to comment on a couple things. With regard to routing, I think taking out the text about routing was a good choice because we don't put those things in public policy. The fact that you're pulling it out of a specific block for those allocations means that if people choose to, you know, filter those -- if somebody does route them and people choose to filter them, then they've got an easy way to do it. With regard to Jordi's comment about ULAs, though, I don't see how that -- how using ULAs solves the problem of reverse DNS for these. As I understand it, those are not going through central registries, so there would be no DNS delegation, right? Is that right?

MR. CURRAN: Go ahead, please respond at the mic.

MR. PALET: I will need to read again the Central ULA, but I think it's possible to use DNS also for the Central ULA and also reverse DNS, so that should not be a problem.

MR. SCHILLER: Just to clarify, the Central ULA is a draft RFC that has not passed. This is not the ULA RFC which has passed which is statistically unique.

MR. WEILER: Sam Weiler, SPARTA.

MR. CURRAN: Go ahead, Sam.

MR. WEILER: An editorial thing. You took out the requirement to not route, but there is still the word non-routed in there. I would say if you want to remove it at all, remove it in both places. Maybe I'm confused. Would the equivalent of an RFC 19/18 space, a single address block shared by everyone, meet the need here?

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

MR. SCHILLER: No, it would not meet the needs, and there's a couple of reasons. One, it's essential for DNS to work for these addresses. If these addresses are going to be used for loop-backs and point to point interfaces for the purposes of troubleshooting, for the way they show up in telenets, so that people can trace route through the network and see non -- and not see non-routable space, DNS is very important for our internal support people. They need to be able to telenet to a router by name, because they can't remember thousands of IP addresses. In addition, the reason why statistically unique also does not work is because of the overlap problem which we would almost definitely have within our RFC 18/19 address. One of the big problems is when you merge a network with another company's network or you connect lots of VPN customers that are using private address space, you often come to a point where there's overlap, and we need to be able to point to some authority that says we have the legitimate claim to this address space, you are the ones who are in the wrong, you are the ones that have to renumber, and frankly renumbering is a burden, so we would like to avoid that.

MR. CURRAN: Sam, would you support this proposal or not?

MR. WEILER: Maybe.

MR. CURRAN: Thank you.

MR. WEILER: I really don't know yet.

MR. CURRAN: Okay. Rear microphone back. Leo? Louis?

MR. LEE: Louis Lee, Equinix, NRO council. I support this policy. I was one of the first ones last time around to mention the routability provision in this and I might want to remind everyone that there used to be a similar provision for the micro-allocation for infrastructure in v4 that was removed and the internet didn't go down when that provision was pulled out. I am a user of that v4 policy in my exchanges, and it is very bad when you announce an exchange v4 block to your peers. You can announce it to your customers, but to your peers, with Cisco defaults, that route will take precedence. Now, you can solve the routability issue other ways, either with a recommendation elsewhere or using some kind of centralized bogone, bogone list which is already out there, so that's a possibility. Various folks would be monitoring for these blocks anyway if ARIN were to publish where this block comes from, so that argument could easily be taken care of and set aside. For an emergent technology that this policy would be used for like a VOIP, it is very important to be able to trace route through and find the problems quickly. You don't want to deploy technology and have it only work halfway and have it go down easily and not be able to fix it easily when you ask your customer to do a trace route to you to see where that packet is being routed. So I believe all my concerns from last time have already been addressed and I support this policy as written.

MR. CURRAN: Thank you. Any other comments? The microphones are open.

MR. WEILER: Sam Weiler. To clarify my maybe, no, not without textual clean-up, with a little bit of textual clean-up, yes.

MR. CURRAN: In particular, what --

MR. WEILER: There's still the word non-routed in there. If you're going to use it, expand; if not, drop it.

MR. CURRAN: You're saying the word routed in not the policy justification, but the actual policy text?

MR. WEILER: Non-routed.

MR. CURRAN: Non-routed, okay. Any other comments? Okay. At this time it's time to collect some guidance for our illustrious advisory council, so we're actually going to have a show of hands on advancing this proposal 2006-2. We're going to have one vote regarding everyone in favor and then everyone opposed.

MR. BRADNER: Sam suggested a wording change, so that's a third option.

MR. CURRAN: Sam suggested a wording change. Do you have a precise wording change, Sam?

MR. WEILER: Strike the word non-routed from the policy.

MR. CURRAN: Simply strike the word non-routed from the policy. We need to read the policy text. Hold on. I guess the question is, Jason, would you propose that we change the text of the policy proposal to strike the word non-routed and proceed with that? Is that acceptable to you as a whole or would you like to hear about the votes both with and without that word?

MR. SCHILLER: I think the policy is fine either way. I'm not sure how the community feels about it, so I would like to see the votes in both directions.

MR. CURRAN: Yes, Heather.

MS. SKANKS: Sorry. I think that I would just be concerned that taking out the non-routed part might open it up a lot further than intended, but I think that it's not clear how much or how that -- how much more it would open it up.

MR. CURRAN: Okay. We can break this into two policy proposals, 2006-2 and 2006-2B. 2006-2B is the same policy text with the word non-routed struck from the policy description. I will read it now. Policy statement 610.1, Micro-allocations for internal infrastructure. "Organizations that currently hold IPv6 allocations may apply for a micro-allocation for internal infrastructure. Applicant must provide technical justification or indicating why a separate block is required." The remainder of the policy is as-is. We're going to conduct two votes. They are independent votes, so it is possible for you to vote in favor of both 2006-2 and 2006-2B, completely orthogonal, independent votes, so the first vote is on 2006-2 as written, micro-allocations for internal infrastructure. We're going to conduct a vote all in favor and then all opposed. I have my tabulators ready, and at this time all those in favor of 2006-2 please raise your hand nice and high. All those opposed to 2006-2 as written raise your hand nice and high. We will now conduct our second vote, 2006-2B on the text as amended with the word non-routed struck from the policy description. I'm going to ask for all in favor and then all opposed. All in favor of 2006-2B, please raise your hand. Okay. All opposed to 2006-2B, please raise your hand. Okay. Thank you. Results are coming up shortly. Hold on. Mr. Darte.

MR. DARTE: I would just like to clarify that the Advisory Council, at least I, and I'm sure all my colleagues recognize that this isn't, in fact, a vote, but merely a show of support for it.

MR. CURRAN: And thank you, Bill. As everyone should recognize, the Advisory Council receives this as guidance in them making their decision about community consensus in these matters. So on the topic of 2002 -- sorry. First, number of people in the room, 109. On the question of 2006-2 as written; in favor 47, against 1. On the policy proposal 2006-2B with non-routed struck from the policy description; in favor 6, against 10. Thank you very much.

RIR Updates: APNIC

MR. PLZAK: Thank you, John. The next item on the agenda, we're going to have a few update reports. The first one would be from APNIC. Paul, are you here? There he is.

MR. WILSON: Good morning everyone. I'm Paul from APNIC and I'm here to give you an APNIC update. Okay. One thing we've been working on quite hard in the last couple of months at APNIC is new staff structure, so I thought I would just give you an overview of that. We've got now within APNIC a two-tiered structure with four areas of major activity at the top, and these areas are services, communications, technical business and at the site level chief scientist, and those positions are filled by myself in an acting capacity by Sinjai who I think some of you know, like Gerard who's been up here presenting for APNIC before. Like Sanjay, again, he's playing two roles at the time being. We'll be advertising a business area manager sometime soon -- thanks. Okay. So I just thought I would give you an overview of how we're structured these days, as of just last week actually. So just going through a few highlights from each of those areas, the services area is responsible for, well, services to our membership and community. It's got a help desk unit within it that's busily extending its help desk hours and it's also going or gone live with VOIP and Live Chat Access, and both of those services are getting steadily increasing use these days. We have a resource services unit, which is our name for registration services comprising the host master staff. They are busily localizing request forms at the moment, so we've got a lot of languages in our region. Probably our main form, our most important form, the IPv4 request form, is going to be in seven languages with the form itself and its supporting help information there, and that's going to be a pilot for localizing the My APNIC portal, which is our main user member interface to APNIC services. In that on-line services area we're not only working on My APNIC in that respect, but we've been working on ICONS, which is the support website for ISPs around the region. It stands for Internet Community of Online Networking Specialists, and you can visit ICONS at icons.apnic.net. That's also something that's getting quite a lot of support with work, particularly with SANOG group, the South Asian Network Operators Group, who are starting to use it more and more. We have a new -- or an ongoing development of an internal resource management system called ARMS, the APNIC Resource Management System, and that's just recently been upgraded with all of the IP address management being done through better interfaces than before. And also with some thanks to LACNIC, we're providing a public statistics interface using the 03 software, so you can come to APNIC and do your own sort of ad hoc query of the statistical data that we carry on historical resource allocations and so forth. The training and education unit has a new manager, Cecil, who has spent the last couple of weeks at RIPE NCC learning about how training happens at RIPE NCC. He's been involved with a pilot webcast of a training session that we ran at the APNIC head office and just made it available to the APNIC community by webcast. We have some collaborative development of new training modules, particularly in the security area of IPv6. We've done so far 40 training events in 18 different locations around the region this year. And also last, but not least, is the e-learning project, and so that's a new e-learning service which has been launched at that URL and that's got a couple pilot modules on it at the moment for online learning about APNIC. In the communications area, marketing and outreach is one of the major sets of activities there. We have a new interactive so-called APNIC interactive CD, which is a whole bunch of information, educational and resource materials which are packaged on a CD for easy distribution, and surprise surprise, that material is also available online. We have a lot of work going on these days with network operator groups around the region, not only SANOG that I mentioned, but also PACNOG, Pacific Network Operators Group, and NZNOG, which is a particularly active national Network Operators Group of New Zealand. And we've got various agreements and MOUs and so forth for various training and cooperative activities that are going on with these groups and with other groups such as the ISOC chapters for AU and the Pacific. And there's a couple of photographs there from sessions that we've been involved with, one in the Pacific somewhere and one in Baton, a very nice place to go if you ever get the chance. Okay. Policy unit has been moved into the communications area. We have a new meeting format which we trialed at the last meeting, which is sort of taking a leaf out of the RIPE book by creating a more prominent and more interesting plenary through the course of the meeting and that was a pretty successful thing at our last meeting in Taiwan. I heard some unkind person yesterday suggesting that not much happened at the last APNIC meeting in Taiwan, which is not the case at all. We had eight policy proposals and a fee structure discussion that went through the meeting and so that was a pretty active meeting and that was a lot of fun, too, so Paul Rendek, you missed out. The major policy decisions that went through there was that we did accept the HD-ratio of.94, and that's subject to interpretation of other RIRs. The 4-byte ISN assignments have gone through. The other one that's not listed there is the ability to make variable length assignments of IPv6 address space, so we've broken the /48 barrier and it's now up to the ISP what length of the assignment that they choose to make. The technical area has a software unit and network operations and security. The software unit just at the last meeting launched and demonstrated a new system for updating the reverse DNS by using XML over HTTPS that gives quite a few improvements over the current e-mail based system with immediate success or error reporting rather than having to wait for an e-mail reply and do something with that, it uses dynamic DNS to update the APNIC name service within seconds, and that was something that was demonstrated at the APNIC meeting. At the same meeting we did propose to deprecate the e-mail updates system for updating the DNS, and that's something that some people are still a little bit attached to, so we haven't quite decided yet to get rid of the e-mail update system, but that may be coming in the future as people get used to the idea or we are able to address the particular concerns that people had. Resource certification is a big R&D activity at the moment and I think you've heard all about it by now. We were able to announce three future meetings. APNIC XXIII will be in Bali. APNIC XXIV will be held together with SANOG X in New Delhi, India around this time next year, and APNIC XXV is happening back in Taiwan with Apricot 2008, so everyone is invited and please come along, and that's all I've got to say. Thanks very much.

RIR Updates: RIPE NCC

MR. PLZAK: Thank you, Paul. And I believe now we have Axel from the NCC and the employer of the one who gave the unkind words to APNIC.

MR. PAWLIK: Talk to me in private and I will take action.

MR. PLZAK: I do have photographs from last night as well.

MR. PAWLIK: Thank you. So, yes indeed, I'm Axel from RIPE NCC, which you don't see on the screen -- yes, you do. It's down in the far left corner, the little house, as you possibly know. The big one is the queen's palace and -- I shouldn't have touched this. Okay. We're not moving there. Although we have a little bit of reorganization going on ourselves, but I will tell you at this time we are in a transition phase here and once we've settled down, next time I can tell you a little bit more from the real perspective probably what will be most visible is that we are splitting Paul's job; he's having far too much fun, so we split this. As you know, Paul is -- Paul, where are you? He's sneaking out or he's not paying attention. His title is head of membership services and communications, and we are employing or have employed a new person on, as Paul said, my executive team who will take over responsibility for the whole membership services/customer services area. We're putting up a new group there and Paul will have to look at his title, probably it will be something like chief network officer or something like that and I think he's evidently able to do this. Basically the idea is to look after training still and the outward facing parts of our organization, external relations, governmental liaison, stuff like that, similar to what Paul has said. But, okay, news from some of our services. Basically we are continually updating our documentation, trying to make it easier to understand and of course we are never quite finished in that. We have received a number of IPv4 addresses, address block, that's very nice, and finally the v6 global allocation has been made as /12 to RIPE NCC on the 3rd of October, which is Germany's reunification day, so double reason to celebrate there. Then we have had a project that looked into the 32-bit AS numbers basically looking at how complex it might be to transition to that, and we found that it might be quite complex, so we gave our community an early warning basically look at this and give yourself enough time to do that. Training, we are looking, as usual, about 80 or 76 courses in quite a number of countries in our service region for the course of this year, we're looking at 50 countries there, but of course we are never able to get to all of them, so we also do e-learning. That has been quite successful. We have two courses online now using the RIPE database and basically something about internet misplaced and how the RIRs came into being and what the ideas of the NRO and how they all play together and we have quite a number of other things in the pipeline, some of them quite ready, but need to be signed off of, for instance, the policy process, I think about 100 hits on that stuff a day, so it seems to be quite popular. ENUM, you know that we are doing the TRO registry for ENUM. We have, again, updated our request form. We're getting about 40 queries per minute on the ENUM tree. We see that Germany and Austria are the most active, they have the commercial servers out there. And there is -- I put in a link to a presentation from Brett Carr who gave it last week at the RIPE meeting, some more information in there might be interesting for you to look at. Test traffic. You know that for quite some time we have network of we call test traffic boxes scattered mostly through our service region, but some in other places as well on the globe. We are not quite happy with the business model of that. Basically we thought it would be very popular with the ISPs to prove themselves that their lines are good and the traffic flows very freely. That was never really popular, so we changed it a few years ago, and again it's not quite there what we want to do. We have over the last few years already started to implement other services on those boxes, for instance, the monitoring of DNS service and other things, and so we are looking at this with fresh eyes. We want to replace the boxes, slightly different administration scheme there and have it open to more services, more experiments there. We are also looking at some legal issues. Eventually, eventually it has happened we have had -- what do you call it -- a subpoena, I think, from Turkey through the Dutch authorities ending up on our doorstep. That's the first one that we got from abroad formally, otherwise we got lots of faxes, of course, who used the address there and then, you know, all this here, yourself also. Also we are looking at the RIPE database what's in there and what the situation is with regard to data protection and privacy laws in all those countries in our service region, that's very interesting. Also we're looking at articles of association and maybe make a few changes there also over the next half year. Right. Membership liaison. You know that we do regional meetings to reach out to our members primarily in the eastern parts of our service region. Moscow, again, we basically just came back a few weeks ago. It was the third meeting in Moscow. It was very popular, more so than we thought, so we'll just have to go back next year. It's great fun. People are very happy that we are coming. Also we have another one scheduled for the middle east for Bahrain, and again, will be the third time and we think that we will probably come back to the region next year somewhere. We did a number of roundtables, so-called roundtables where we want to reach out to governments and regulators. We have gathered about 20 or 30 people for these and never seem quite as successful, but some of the people there said it would be nice if we could put them alongside the RIPE meetings, so we are looking at that. We have done that this last week for the first time. We had a Monday afternoon -- part of the afternoon dedicated to government regulator and technical community, RIPE community interaction. It's a bit of a slow start there. We'll keep on going. We'll do it again next RIPE meeting and after that. We have quite a number of people who want to talk, but then last minute they are not quite there yet, so we'll see whether that becomes a smashing success, but we'll keep at it. Certification, also supported in our service region. I put forth the proposal to set up a task force of our members, some of our members. The idea is to continue the prototype development that we have seen in APNIC -- mostly APNIC led over the past year or so. We want to formally do a trial deployment in the RIPE region for next year. We are putting in some extra effort in terms of manpower for integration of that into our business processes and then we want to install -- or we are in the process of installing a small task force of about three to five people from our members together with us to look at what this all means for their business processes, for ours and how we should go -- or if we should go ahead with this and that is planned to -- decision on that is planned to happen October next year. Some words about corporate governance. We just had our general meeting last week on Thursday. Planning for next year was the big topic there. We, for the first time, plan to increase our -- formally plan to increase our staffing by five FD's. The budget does go up a little bit, but still remains around the 11 million Euros. The new things that I mentioned are the customer services department. That's some idea that we had for quite a while and now we are eventually getting our heads around it and implementing it and I'll talk more about that next time under certification, of course. We also have had our members decide on the charging scheme. As by now usual, the fees will go down because membership growth is up again quite nicely and we also have the plan of having one year turnover as a reserve, operational reserve, and we are by far beyond that so we are also redistributing two and a half million Euros back to our members in form of rebate. The next RIPE meeting -- well, it's a little bit early still -- will be in May, will be in Tallin, and we hope not to have snow there, but we never know. Of course you're all very welcome to come. If you have any questions, ask them now. Thank you.

MR. PLZAK: Thank you very much. Thank you, Axel. It's comforting to see that an RIR can have a meeting and not have a beach scene, too, although I guess you could get to a beach in a few places, if it's not frozen over. Actually you have these subregional meetings in these nice places like Bahrain. So we go to the beaches of Holland, right?

IANA Activities Report

MR. PLZAK: Next up is the IANA activities report, and this is going to be presented by Barbara Roseman. Barbara.

MS. ROSEMAN: This is a short, very brief presentation. David Conrad had hoped to be here at the meeting, but his transportation plans got disrupted in Toronto when United had a plane that just didn't want to take off or something. We've gone through some staff changes and -- none of these graphics are coming through which is kind of unfortunate. Go ahead. Next page. Okay. So this is our current structure. We've recently promoted Michelle Cotton to the IETF liaison position. She's been basically performing that role for quite some time, but we decided that we wanted to dedicate her full time to that role and bring in additional operational personnel to do some of the day-to-day work that she was doing. We still do have our numbers liaison role open and we're hoping to fill that shortly. These are the allocations that we've made to the RIRs going back to January of 2005, and you can see that the number of days that it takes us to fulfill an allocation remains somewhat erratic. A lot of that has to do with specific questions involved with the given request. What we have found recently for IPv4 allocations is that the RIR is actually eligible for a greater number of /8s than they are asking for and so we try to figure out what's going on there, what it is that they truly need for the next period and what will work best for them. We did under the IPv6 global policy, we've assigned /12s to each of the regions. That was done a couple of weeks ago and they are now available to the RIRs for allocation. We're engaged in a process of regularizing our internal registries. We're going to try to go to a format that will allow for XML and other forms. Currently the registries that we maintain both on behalf of the RIRs and the IETF are in a number of different formats that were created in an ad hoc manner and we're trying to harmonize them across everything, and that's it. Any questions?

MR. CURRAN: Any questions? Thank you very much.

MR. PLZAK: Thank you, Barbara, and I would like to congratulate you to be the first presenter for IANA in a long time that hasn't been questioned by Geoff Huston. We are at the point where we should be able to do our morning break. The refreshments are available in the foyer, and I don't know what's available this morning. We've been having some pretty good breaks, so let's thank our sponsors for that. When we come back, we'll have a slight agenda change. We will begin with the NRO activities report, and that will then be followed by Lynn St. Amour's internet governance information report, so see you back here at 10:50. Thanks. (Recess)

NRO Activities Report

MR. PLZAK: As I said, we have a minor agenda adjustment here. The first report will be the NRO activities report and we have a further adjustment in that approaching the stage is not Axel Pawlik, but Raúl Echeberría, the chair -- the current chair of the -- and Malibu Stacy races down the hallway -- Raul. Raul is the current chair of the NRO Executive Council and he'll provide the activities report.

MR. ECHEBERRIA: Good morning everybody. It is my honor to be here giving the NRO report. As the chair of the NRO, this is the last time for some years that I will be here in this condition. At the end of this year I will be pleased to pass the responsibility of being the chair of NRO to my colleague, Ray Plzak, of course if he's willing. Okay. I will speak a bit about the organization of the NRO. The NRO was created 24 October, 2003. It was formed by the Regional Internet Registries, the four existing RIRs at that time. AFRINIC joined NRO later when it was recognized as a regional internet registry. The objectives of the NRO is to formalize their cooperative efforts and protect the unallocated Number Resource pool, promote and protect the bottom up policy development process, and last but not least, to act as a focal point for internet community input into the RIR system and represent the RIR community in the relationship with other organizations and bodies. The structure of the NRO, as you can see the slide, is composed by an Executive Council that is responsible for representing the NRO, Numbers Council is an advisory council, and the Secretariat and some coordination groups. The Executive Counsel is formed by one representative of each RIR. Usually they are the CEOs and the offices will change every year. As you see, I said before, I'm the chair, reports to the Secretariat, for which APNIC is the treasurer, and next year then Ray Plzak will become the chair, Paul Wilson will become secretary and -- I'm not sure, I think Axel Pawlik will become the treasurer. This is the group of the Executive Council. Guys, I like this picture because I look younger because the picture was taken two or three years ago, I don't remember. The EC meets periodically by teleconference and/or face to face. In 2005 we have had 10 meetings and we have had seven meetings in 2006 until now. We expect to have at least a couple of more meetings this year. All the minutes are available in the NRO web site. I recommend you to check their web site. You will find not only the minutes that it is important in order to be an Address Supporting Organization, but you will find also more useful information. The Address Supporting Organization is one of the support organizations in the ICANN structure. In October of 2004, one year after the NRO was created, the NRO signed a memorandum of understanding with ICANN and vis-a-vis this memorandum of understanding the NRO fulfills currently their role, responsibilities and functions of the ICANN Address Supporting Organization. The Address Supporting Organization has one council, as I will not speak very much about that, because Martin Hannigan surely will speak also about that and discuss activities, but what is important is that the Address Council as a part of the Address Supporting Organization is, by this memorandum of understanding, is the equivalent of the Number Resource Organization Number Council. The NRO Number Council has responsibilities of the Address Council of the ASO. This is a policy advisory body composed of 15 members, three from each region, two elected at large. I understand that you will have an election today for electing one of the representatives. One of those three is appointed by each RIR board. There are also some observers from ICANN staff and RIR staff that participate in the Address Council meetings. The Address Council advise ICANN board, select ICANN board members, two ICANN board members, and also has responsibility of selecting one member of the ICANN NomCom. This is the list of members of the Address Council. Those that have the asterisks are those members appointed by the respective RIR boards. The NRO has also three coordination groups, the communication coordination group, engineering and the legal team, and those coordination groups are chaired by the member that belong to the RIR that is responsible of the Secretariat each year. In 2006 the chair of the communication coordination group is Susan Hamlin. The chair of the engineering coordination group is Ginny Listman, and the chair of the legal team, the coordinator of the legal team is Steve Ryan, all of them from ARIN region. Those are some of the topics that are currently under consideration of the NRO, thus we continue working in some of the procedures that we have to provide procedures for the functioning of the Address Supporting Organization, so we have -- always have some procedures to get rid of and establish. So we have established this year the charters of the coordination groups as we are trying to improve the communication between the Executive Council and coordination groups by taking advantage of this meeting here to meet with Susan Hamlin and Ginny Listman, too, in order to work in this issue. So we have many activities related with internet governance matters, some of them as part of the follow-up of the World Summit Information Society, WSIS, so we have one -- as a result of the WSIS agreements, the Internet Governance Forum is being created. Lynn St. Amour will speak about that later. As one advisory group of the Secretary General of United Nations has been established and the Number Resource Organization have two members of the Executive Council in this group, Adiel Akplogan from APNIC and myself. We are participating -- we plan to participate in the first Internet Governance Forum meeting with the NRO. The meeting will be held in Athens at the end of October and beginning of November as we plan to be there with many activities and also distributing materials, information materials, and participate in several workshops. Other issues that has been under our consideration this year is establishment of liaison relationship with ITU. We have signed an agreement with ITUT, the part of ITU that deals with communications. We have not had any activity yet related with this new situation, with this new agreement, but we expect to explore the possibilities of this new relationship. We have also had meetings with representatives of the Government Advisory Committee of ICANN, the GAC, trying to improve also the relationship with governments through the GAC and I think we are getting a fluid relationship as well. We expect also to participate in the ITU Telecom World 2006 in Hong Kong in the beginning of December together with ICANN and ISOC we are planning several activities together there, which we will have a booth in the exposition in the ITU Telecom World. One interesting issue is the certifications, everything related with certification. Some RIRs have more progress than others in developing for certification authorities and also working in the implementation of certification routing issues and so we are trying to take those activities also in a more coordinated fashion through NRO. We plan to have a meeting in San Diego during IETF in order to get better coordination. We are also working on harmonization of IP allocation practices with different RIRs. We have much work to do at this point, but perhaps we will have some results to report to you in future meetings. We are discussing -- this is something that has been in every presentation of the NRO in the last five years probably, four years at least, but I have to say, once again, that we are working on establishment -- the signing of service contract with IANA. We have had some meetings with ICANN representatives during these meetings here in St. Louis, and thank you, ARIN, for hosting those meetings, so I think we are on the right way, so we have had some friendly contacts and exchange of ideas and probably this time there will be a more successful negotiation. Finally, one other thing, the incorporation of NRO. We have taken some positions regarding the incorporation of the NRO, but it has not been certainly a priority for NRO this year, but probably we'll continue working on this issue and we will have soon the NRO incorporated. Finally, those are the links that all of you probably know, but you can find interesting information for you, I hope useful, in the web sites of the RIRs and also the NRO web site. Thank you very much.

MR. PLZAK: Thank you, Raul. If you noticed, I think he at least three or four times said that I would become the chair next year. I don't think that's in anticipation -- sorry. Raul, we have a question over here.

MS. MURPHY: I thought of this question listening to the various registry reports, but I thought perhaps just asking one question rather than asking all of them. Does the NRO consider the routing registries run by the registries to be part of their mission or part of what they work on?

MR. ECHEBERRIA: Okay. I will give a personal answer at this point, but I think it is up to each RIR. I don't -- it has not been considered as part of our mission.

MS. MURPHY: So then I should have asked each one of the registries.

MR. ECHEBERRIA: But probably some -- the deployment of some new technologies like CRISP, for example, would change the priority of these persons. Like APNIC, we have confronted our community as we have not a mandate from our community to set up a router registry with them. I think that is different in each region. I don't know, unless Ray would like to add something.

MS. MURPHY: The question I was going to ask was there is a definition of security for RPSL systems. There's an RFC that defines the security for routing policy systems, and I was wondering if you knew how many of the routing registries that run -- let's see -- how many of your registries that run routing registries employ and implement that security system.

MR. PLZAK: So you are asking how many of us are compliant with an informational RFC?

MS. MURPHY: I'm asking you how many of you have implemented the security system, yes.

MR. PLZAK: Okay. And with regard to that particular RFC, I know that ARIN has not. I don't think that RIPE NCC has not. I don't see Paul here, so I can't get an answer for APNIC. I know that AFRINIC has not because they are just now working on developing a routing registry, and obviously LACNIC hasn't because they haven't set one up yet.

MS. MURPHY: I'm surprised to hear about RIPE because I had reports from RIPE members that some of the securities recommendations were implemented, but --

MR. ROBACHEVSKY: Andrei Robachevsky, RIPE NCC. RIPE NCC routing registry fully implements RFC 2725 which actually specifies security authentication for the routing registry; however, it only works for the address space and internal numbers signed by the RIPE NCC.

MS. MURPHY: Yes, I would expect so. Okay. Thank you.

MR. PLZAK: Anyway, what I was going to say was Raul said three or four times about me becoming the chair of the Executive Council next year. I don't think that was in anticipation of me taking the position as much as it was him giving it up.

Internet Governance Forum (IGF)

MR. PLZAK: So anyway, now Lynn St. Amour is going to provide us an update on what's going on with the Internet Governance Forum. If you recall, she presented a similar type of report at our last meeting and talked about internet governance, so we asked her to come back and give us some more information, and Lynn.

MS. ST. AMOUR: Thank you. I have just a couple of slides on WSIS, who in fact spawned the IGF, and it's critical that you understand that background because it will continue to be with us in various elements over the next couple of years. WSIS was a part of the World Summit. It began in 2001 with a series of preparatory sessions and concluded at the end of 2005. Its original purpose was to harness the potential of ICTs to drive economic and social development with a particular focus on developing countries, and initially it was envisioned that there would be primarily two main focus areas, ICT development and capacity building and financing strategies. Fairly early in the process, but late in some of the introductory processes, internet governance really started to come to the fore. Much of the internet community -- and I use the internet community in this context to talk about the Istar organizations, so the IETF, ICANN, the IEBL, the other organizations related to the IETF and all of the regional internet registries, we quite often work with various CCTLD forms and some of the other supporting organizations and ICANN as well. We were all extremely concerned. We thought internet governance was a misnomer, and in fact we fought quite hard to have it replaced and instead to talk about collaborative mechanisms. We obviously weren't successful at that point. The conclusion of WSIS actually called for a continued focus on internet governance through two specific mechanisms. One was the Internet Governance Forum, the other was something called Enhanced Cooperation. I've got slides on those two points later on, so I'll just leave that at that for the moment. Some of the key results in WSIS, in internet governance I think the most critical result was a recognition of the roles and the players currently with respect to internet development and some of the governance and development mechanisms that clearly then led to -- therefore there was a minimal impact on current internet structures. The slide says for now, because we don't think that that pressure has gone away. It also led to an understanding that there was a need -- reluctant understanding, it should be said, for many governments, that there was a need to move the debate beyond the technical aspects of such things as IP address allocation, DNS or route servers, and we do actually believe that that's very likely to come up again next year through the IGF. It also said that continued dialog would be helpful in this area, and that led to the IGF. In general, some of the other key results of WSIS was there was an increased focus on ICTs for economic development and capacity building. Many of us believe that it was just far too little far too late and more of the nature of we have to be seen to be doing something in these areas, so let's take some action, but it was not nearly the focus or get the amount of attention as the internet governance issues. The outcome was broadly characterized as everyone was happy, which in UN speak basically translates to everyone could interpret the outcomes as they -- again, the areas to watch as we go forward are enhanced cooperation and the IGF. A couple slides on what the forum is. It's very telling to me that when we describe what the forum is, most of the points talk about what it is not. It has said that it will not discuss issues that fall within the scope of existing bodies. It will have no oversight function, it will not replace any of the existing mechanisms, organizations, institutions or arrangements and it will have no involvement in day-to-day operations or technical operations of the net. It should be a neutral non-duplicative and non-binding process, and in fact when we talk about it in the positive sense, we say that it should discuss cross-cutting international public policy issues, contribute to internet governance, particularly through capacity building in developing countries and be a place for exchange of information and best practices. The forum actually has a five-year mandate, although it's clear that there will be a critical review after this fall, after the first IGF which is in Athens at the very, very end of October and the first few days in November. A number of other countries have already stepped up for IGF II, III, IV and V, you see them there, Brazil, 2007; India, Egypt and no takers yet in 2010. The IGF is led by a representative personally appointed by the UN Secretary General. That individual is a Mr. Nitin Desai. He was also very instrumental in the working group on internet governance and in some of the other related WSIS processes. There's a small secretariat in Geneva lead by Markus Kummer who was previously with the Swiss government, and there are 47 representatives on the advisory group that come from business, government, civil society and what is often called either the internet community or the technical community, and in fact, Raúl Echeberría and Adiel Akplogan are both on the advisory group from this particular group. And if you look at the people that are on the advisory group, there are over 50 people that actually come from IETF, ISOC, ICANN or the RIRs, so that's just an incredible turnout and that was not the way the forum was initially thought to be comprised, but the point won't escape the people in this room that you can't have a discussion that talks about internet governance and not involve the people who actually understand the internet, how it's developed and how it's run today or operated today. The AG's role to date has been both central and yet light, so they are there to assist. They don't determine. It wouldn't run like the program committees we're mostly familiar with. In fact, they give advice. They're asked for specific input. It's largely -- the agenda and logistics are largely determined by the secretariat, and it's unclear whether this type of AG and structure will continue into IGF II. ISOC's contributions have emphasized the following, and I know that they're very consistent with everything that Raul and Alejandro Cassante at DL and numerous other folks are inputting, and that's that we should actually focus on development of areas that actually impact the availability of the internet and the access to the internet. We should focus on cross-cutting international public policy issues, those that don't have a home anywhere else. The model is that of a program committee, not an advisory body and certainly not a governmental advisory body. Should be multi-stakeholder in nature, that means there should be equal participation and equal access from governments, the private sector, civil society and the internet community, and that the outcome should be to share and inform on best practice and any other expertise sharing. We're very clear that there should be no new organizational structures or meetings unless need is proven. We believe that most of those structures and organizations exist today, and obviously make the related point which that we should leverage the existing organizations and the knowledge base. We actually do think those criteria will largely be met, but it's requiring a pretty significant amount of focus from the folks on the AG to continue to ensure that that's the focus and they stay within their limit. There are four key focus areas identified; openness, diversity, security and access. I won't read the subpoints there because I think they're pretty obvious and certainly easy to read. There is also a session called "setting the scene." That was an accommodation for people who wanted a lot of these discussions to have a more political focus. There was an attempt to actually bring back many of the issues that were discussed in the internet governance like issues of ICANN, issues of route servers, issues of IP address allocation into the IGF, and the accommodation was that there would be this scene setting session, and they did finally agree on the four theme areas you see on the top of the slide, but we believe that that will actually be the session that will likely start to set the agenda for IGF II in Rio in the following year. There are 30 or so workshops that will be running in parallel. Raul actually mentioned in his presentation a few moments ago that the internet community has a number of workshops both there and at various IT events occurring later in the year, and the main focus of those is to continue educating people on who we are all, what our organizations are, how we work, how the internet works, what's made the internet so powerful, why it's developed so quickly, and at the same time to encourage broader participation in all of our activities, not just from developing countries, but that is a key sub-focus, but really a much broader participation, and we're also involved in a range of other workshops and everything from local access to IDNs. As of early September there were over 700 registrations. Just as another note, there's another comment on the slide that says there's some tension between not having this run as a governmental session, but as a conference or a forum, and one of the ways that plays out is you can't just register and come to the conference, your registration has to be approved and you're allowed to come if you can actually show a direct relationship to the activities and discussions that are under way. Key concerns, lack of developing country participation. Funding has been extremely limited. There is no funding from the UN, and in many UN events of course there actually is specific funding of specific participation set aside. ISOC is doing what they can to bring people in. I know a lot of other I groups are doing the same as well, but they will be significantly under-represented and that's been pointed out as a key problem for many organizations and we're putting focus on getting that fixed for subsequent years. So Athens is truly a guinea pig. There will be a very critical review in terms of the success. So far there's been less political posturing than expected, and I actually think that was an accommodation. I think that was through the specific intervention of Kofi Anan and need to side with several governments who were very anxious that the discussions that proved so difficult and so compelling to some in the WSIS process continue in IGF, and I think one of the concerns is that Rio is going to be hosting IGF II next year and they are one of the countries that have some very strong feelings in particular about the US government's involvement in the various aspects of internet developments, but they also believe in a greater role for governments. I'm not clear that -- Raul probably has some more specific information, whether that's more specifically within an ITU environment or in some other UN structure, but it's pretty clear to everybody that's involved that IGF II will be much more politicized. There's likely to be a return to the issues that were on the agenda in WSIS I and WSIS II. G77 is a -- you can actually Google it and find out in fact. There's a grouping that has come up through the WSIS process which is called G77 plus China. G77 is actually 120 or 130 countries, so when you have 120 or 130 countries plus China, you become a fairly substantive voice in any of these discussions. They were very active in some of the later days of WSIS, have been relatively -- relatively -- quiet through this IGF process, but we believe that they will actually step up and be much more active in the coming year. So it's unclear what issues will be addressed, but we do actually believe that there will very likely be a return at some level to those issues that occupied us in WSIS I and WSIS II. So as much as we may or may not like all these discussions and participation in these forums, and they do take a lot of time and effort, it's pretty clear that this is just the beginning, and I think I said in my last talk we should ignore this at our peril. The success of the internet has clearly brought new interested parties. The geopolitical climate gives a number of countries extra passion for these sorts of issues, and internet resources are now considered by nations to be strategic assets, and even if they don't understand the internet and they don't understand how easy it is for them to participate in virtually all elements of the internet's development, they just feel that governments should have a say and a place and should be pretty front and central. Their issue is, of course, they get lots of comments from their citizens who are worried about spam or pornography or X and worried about the level of commerce taking place on the net and feel that they should have more control similar to other infrastructural communication models they're more familiar with. So again, the IGF will continue for the next four or five years. The critical test is Athens this fall, but that really is only one component and the one that had many of us in the internet community worried was this thing called enhanced cooperation, and that's quite a long paragraph there. The only line that means much is the very last one which actually says, "associated with the coordination and management of critical internet resources." This was actually an accommodation that was thrown in at the last minute in the documents that came out of WSIS II. Nitin Desai has been appointed by the UN Secretary General to consult informally in the background, will be producing a paper on what might be done to increase cooperation among governments and all the relevant stakeholders particularly in the area related to coordination and management of critical internet resources. He's in the eleventh hour of finalizing a report which will be sent to the UN Secretary General. I have a slide on what we think might be the content of that in a moment, so I won't get that here, but the point is that it's not going away and it will show up and it's already showing up in many other forums. There are a number of regional discussions taking place, you will see things -- proposals surface every once in a while for regional framework in X region for some matter having to do with internet governance. The ITU this fall has their planning potentiary which is every four years their strategy and budget session, it sets the budget for the next four years. That's a three-week event taking place in Turkey. At the same time they also have their, every three years, ITU World Telecom Congress in Hong Kong, and also as Raul said, a number of us from the internet community are participating in those events, sometimes in an educational sense on various panels and others trying to be -- participating through some specific delegations, particularly in the planning potentiary so that we can help ward off any mischief that might come through that process. So the last slide here is "Reading the Tea Leaves." It says Athens will be a success. UN events always are a success, they really are, it's just degree of success. So the difference between a success and an outstanding success, in our view, will be the degree to which the developing countries and the issues of increasing access are truly dealt with through that forum. I suspect the outstanding success will be defined quite differently by a number of other governments that are there. It's clear that each party will put their own spin on the event. I think Athens will be a peak pivot point for determining the agenda for IGF II going forward to Rio next year and I suspect most of the attention will be focused in the corridors and lobbying with respect to what that agenda item is rather than focusing on the topics on hand in Athens. So the next point is enhanced cooperation, really is a balancing act, but what we actually expect Nitin Desai's report to say is that he will review the existing mechanisms, he'll come out in support of the current model of the organizations and efforts we are all undertaking to actually improve our access, not only to developing countries, but to governments. Clearly the ICANN GAC, Government Advisory Council's role, is a critical element in this and the ICANN -- ICANN has actually set up a task force to look at the relationship between ICANN GAC and that is playing a pivotal role in the background here. The report will likely mention the new agreement between ICANN and the U.S. Department of Commerce. I suspect they'll just simply say something like it's moving in the right direction and they applaud that and I don't even think it will go so far as to set some suggestive end points. If in fact it is as lightweight a report as that, it's pretty clear that that won't appease a number of other governments who would like a much stronger position, much stronger involvement of the United Nations in internet governance and in these forums, so again, so I think that will -- particularly if it comes out ahead of the IGF in Athens, I think that will color the agenda that's there and really start to increase the pressure on the Rio agenda. So that was all I had. Questions?

MR. CURRAN: Excellent presentation. Microphones are open for questions.

MS. ST. AMOUR: The ring leader from last night.

MR. DARTE: I don't remember. I'm Bill Darte and I'm representing Washington University here in St. Louis. I wonder if there has been any impact assessment and associated probabilities if things go moderately well, moderately bad or really bad through this process.

MS. ST. AMOUR: With the IGF process in particular?

MR. DARTE: Yeah, all of the internet governance impacts that might exist, you know, has there been an analysis that if this really goes bad, what would be the impact to the way we think of the internet operating today worldwide?

MS. ST. AMOUR: Well, I mean, some people would say nothing, you know. The governments of the world, the UN could declare they were going to manage something, take over something, and in fact there's just no way fundamentally for that to happen. I think there's a lot of room for mischief in a lot of individual countries which collectively could give us all a very bad day. Have there been plans put in place to assess what some of those possible outcomes are, from my perspective, no. There have been conversations and discussions. I think, you know, a lot of time and energy focused on the WSIS process, we get through the WSIS process, we've being trying to damage control around IGF and I think we came out of the WSIS process extremely well. The only thing better would have been no IGF, no discussion forum and everybody just went home, and that was probably unlikely to happen, but I think the internet community came out of it very, very well. We've been focused on at some point, if you will, managing the expectations around IGF. Dialog is good, communication is good, but if it's educational in nature, that's even better. If that really is the intent of IGF, then we support it, sometimes somewhat begrudgingly because it requires so much time and effort, but it is a good thing. If we can continue the IGF along that road, then I think that that poses little danger to any of us and hopefully it actually is of some benefit. The enhanced cooperation is the one that is much more difficult to assess because to date it's been largely underground, it's one or two individuals individually I wouldn't say negotiating, but individually interviewing and talking with different people to try and write reports to the UN Secretary General. I think we'll need to wait and see what comes out of that report before we start looking at any other scenarios or alternative plans. This is all new for all of us. It requires a lot of time and patience and sense of humor.

MR. CURRAN: Any other questions? Okay. Thank you very much.

MR. PLZAK: An interesting phrase in one of your slides here, Lynn, Road to Rio, I believe that was an old movie with Bob Hope and Bing Crosby and Dorothy Lamore. Road to Zanzibar, same cast.

NRO NC Report

MR. PLZAK: Next on the agenda is the report by Marty Hannigan on the NRO NC's recent activities, and so Marty.

MR. HANNIGAN: That was an interesting presentation and a thought came to mind. Maybe fiber net bombs. If we spent as much money on fiber, we'd have a lot of access, so with that -- how do I control this thing? So I'm Martin Hannigan and I am a member of the ICANN NRO NC ASO AC and we are here in St. Louis, of course. And a little bit about the members of the ASO. Sandy George, if he could just raise his hand real quick, Sandy is a member. Sandy this year is also a member of the ICANN NonCom, a group of people that are going to process candidates to join the ICANN board. Louis Lee re-elected to the NRO NC. Louis wrote some advice to the ICANN board related to the current IPv6 policy this year. Myself with -- the slide is a little bit of misnomer. I am up here today as Figowy Diving Company speaking for myself, but I am with Rent-a-Bahama and I'm a little busy these days as an independent contractor kind of moving around the world doing things and trying to make things better on the internet. I spent some time this last year on organizing the appointment of seats nine and ten on the ICANN board. Those two seats are appointed by the ASO AC, and we run a process and select candidates and appoint them to the ICANN board to represent the RIRs to some extent, but a board appointment is basically, you know, fire and shoot for the most part, but we did a lot of work on the process last year to ensure that we have a little bit more of an ongoing relationship and we did appoint seat ten -- seat nine -- I'm sorry if I get the number wrong, but one of the seats, and Dave Wodelet from Shaw Communications went through the process and he was appointed to the ICANN board, and I spoke with him for a few minutes yesterday and I am still standing here. So just a quick rundown. I'm not going to repeat much of what's already been said, and this is not a report of all the other regions and ASO activities, it's our region, so if anybody feels left out, please stand up at a mic and say so and I'll be happy to acknowledge that. So we appointed two seats to the ICANN board. We run a process and last year there was something like approximately 23 candidates that we whittled down to five and three, if I recall correctly, and had a runoff type vote, had a face-to-face meeting and Dave was appointed. We defined internal operating procedures to process global policy documents that reach us. That process is basically the RIR PDPs. When asked, we -- or sometimes when not asked, we offer limited advice to the ICANN board related to these policies and the creation of new RIRs, if asked. Some of this stuff is defined in the MOU between the NRO and ICANN. We then certify -- if we do receive a global policy, we certify that that policy is in compliance with the local RIR PDP, so as a group we run off and we ensure that all of the PDPs have been followed and we, for the most part, certify that and forward to the ICANN board as such. So how do we do all this? Well, we communicate. We meet twice per year. We met in Istanbul, Turkey at the RIPE meeting. We are going to meet at the ICANN meeting in Sau Paulo. One member from the ARIN region attends each RIR meeting to keep in contact with the other RIRs as unofficial liaison. We run e-mail lists. There's a private list. All these lists are operated by the secretariat. One is the Ac-coord list. There are also some open lists which you should feel free to join, and actually we are encouraging you to join them. The general comments list, which is open to anyone, and the AC public discussion which is basically, I believe, postable by the ASO and readable by the entire public, and I'll have to check on if it's postable by the public, I'm sorry, I do not know that right now. And for the Brazil meeting we are recommending plastic sippy cups, and many of you may be aware of a slip and fall accident in Turkey that required some stitches in someone's derriere, and plastic will be recommended extensively. So -- and thank you, Rob, for the sippy cup, I really appreciated that. Rob -- when we went to NANOG we shared a room at the last NANOG and Rob bought a sippy cup and put my name on it and it was in the rest room and for days I looked at this thing and I went, jeez, I wonder what that is, and finally I asked Rob and he told me and I got it. So just a little bit of data on some of the things that you may feel are important to make sure that you're getting your return on investment of sending us these places and funding these things. Our attendance is very good. I've demonstrated the attendance of -- all these are approximations. These are done -- these statistics were culled from the minutes and I put them together rather quickly, but I hope this is demonstrative, and the mailing list statistics. You see a few spikes there. The first spike, I believe, is the discussion surrounding the global policy process that we created and sent to the NRO. We have different spikes depending upon different issues, and the July spike is surrounding the board nominations, if I remember correctly. Since the last time we were here, Sandy George was unanimously reappointed to the NonCom. Generally it's on a -- not so much official, but it's a tradition that the person who is appointed from the ASO to the ICANN NonCom serves for two years to make sure that there's some continuity. There was a global policy, as you know, sent to the ICANN board and approved by the ICANN board unanimously and we were part of that. They ratified it and we also created a process to process the global policy. And what I mean by that is we can get the policies from the RIRs or the mechanisms that are in place, and then we just have some internal procedures that we use to handle these things expediously and get them out the door and over to the ICANN folks so that they can ratify them quickly and make everyone happy and the chair nomination policy was created. So the IPv6 global policy was certified compliant to the ICANN board. 13 members agreed, one was not present and one abstained. There was an undisclosed business conflict that prevented me from being able to vote. RIRs were deemed to have followed their policy development procedures as required. So what that means is our job is not so much a political one, but it is a procedural one to make sure that as defined and agreed to in the memorandum of understanding with ICANN, the people of the NRO, that these procedures were followed, and they were. And those are the footnotes for later reference. So some of the feedback that we received, and whether this was in scope or out of scope, I tried to summarize that here. A lot of it was out of scope, in my opinion, to what we are supposed to be doing and I think we handled it well. So to begin, there were some issues surrounding the policy that we received from general folks, so it was discussed on the Coord list. Basically it was ratified by the five RIRs as expected. We heard about some feedback from the ICANN board relating to the policy around reporting and some concerns on fragmentation. There were some discussions around the block size reduction and it was concluded that it defers fragmentation, which was not really within our purview, and basically if there's a mistake, we think it can be fixed. The IANA manager also made feedback to the board on this issue, and the final result. The ASO provided advice and Louis Lee wrote that advice to the ICANN board. The IANA manager also provided feedback and you can ask him about that, we're not sure what he said. Consensus was this was the will of the RIRs. There was some discussion around if there could be any kind of modification and a little debate. There was no suggestion that anything be modified, but what it all came down to was that we certified the process, you guys voted for it and said yes and we looked at that and said you did what you said you wanted to do, what you were supposed to do and we carried out what you wanted us to carry out, and the ICANN board reviewed it and they ratified it. So what's next on the big agenda. We're going to meet in Sao Paulo next and appointing another ICANN director for May. We're a little bit behind right now on this, but we're catching up. The staggered seating dates threw us off a little bit and we're in the process of fixing that. Sao Paulo, Brazil face to face, what we do in our first -- our general assembly meeting so-called is we plan for the next year. We kind of set our road map. We'll meet twice face to face usually at one RIR meeting and then at one ICANN meeting. We will again organize for the appointment of this next director, and that has actually already begun, so we're not sitting on our heels awaiting anything, it's just a complex process that has to get off the ground and getting moving and that has happened. And what the first part of that process is is the lessons learned from the last one, and things seem to be coming together nicely. We'll elect a new chair and co-chairs for 07. Any new members we will greet them and officially welcome them to the council, and Sandy has already been reaffirmed as the NonCom rep, congratulations, Sandy, and Vint Cerf will be completing his term, from what we understand, that we're looking forward to seeing the debate around who's going to be the next chairman. And in UN speak, as Lynn pointed out, we're going to conclude a successful 06. So credits, the Rent-a-Bahamas Companies for the time that they allow me to work on their dime to do some of this work, Equinex and USC for Louis and Sandy. The ARIN secretariat -- ARIN is the secretariat this year and they do a fantastic job in supporting us. They put together all the phone calls and things and make sure all of the people are able to get together, and it's not an easy job, and if anybody would like to volunteer, I'm sure you can talk to Ray and he'll be happy to get some help. Of course the Address Council, we work closely together. The NRO Executive Council. Some ICANN folks, I don't know if they're in the room, I know that some of the IANA folks are, but Bart Boswinkle, Olof Nordling and David Conrad, and then from our region Jason Schiller actually participated in the /12 discussion, gave us a little bit of advice that he passed on. Any questions?

MR. CURRAN: Microphones are open. Any questions? Thank you very much, Marty.

MR. HANNIGAN: Thank you.

MR. PLZAK: Thank you, Marty. And yes, I will be glad to pass off the secretariat at the end of this year, that's for sure. Okay. We are now at the point that we can break for lunch, so I think I've got some announcements here. I sure do. First of all, let's thank our sponsors for these guys, and people like you. And reminder about security, this room is not locked and there is no security, so take your valuables with you. Reminders, Cyber Café and Help Desk are open. And reminder, if you visit, you can sign up to win, and lunch is now available in -- that way, so see you at 2:00. (Whereupon, a luncheon recess was taken.)

APNIC Cert Demo

MR. PLZAK: Lunch is over and the first item this afternoon is Geoff Huston is going to talk to you about using resource certificates and it's a report to you about what's been going on since the last ARIN meeting and also I think you're going to do a little bit of a demo or something as well, Geoff, so with that, I'll turn it over to Geoff.

MR. HUSTON: Thank you. For those of you who were at NANOG earlier this week, some of this material might be a little bit familiar, but I'll try and do a bit more and also show you a little bit more about what we've been up to. This is a report on resource certificates and progress report on the trial that we've been doing in APNIC and also with others in the RIRs and a little further afield in looking at how and why our resource certificates. The recent discussion on the PPML mailing list I thought was actually pretty appropriate and certainly leads right into this topic. If somehow we could get the discipline and the scrutiny into the routing registry, actually get the routing registry to be able to be a reliable thing as distinct from a best efforts thing, that would be great. Mark Kosters comment that certainly it allows for strong security, but, you know, there is a lot of work to be done here and the end result may be complex; hopefully not that complex, and certainly our desire. And hopefully this is a tool that will be useful as distinct from yet another distraction, and one comment from Ed, which I think is really quite bang on the ball within most security staff, don't over-claim. ARIN can only offer attestations from what it actually knows. If it doesn't know, how can it possibly attest? So we're looking at a model and saying, well, how can we use those features inside a security system, what are the real things we're trying to do here. When you see something in a routing system, in a route registry, in a WHOIS object, the first thing I suppose that comes to anyone's mind is is this valid. So what's a valid address, what's an invalid address? A valid address, so far as I can see, is one that you can actually see its provenance; which RIR did it come from, what's the sequence of allocation actions that happened in our distribution framework, how can we demonstrate and validate that sequence of allocation actions. And then it's a case of who, who advertised this prefix in the network, what is their party, who is the originator and is that originating AS valid, is this actually the same validity test, where did it come from, what's its provenance. And of course tying the prefix to an originating AS is a very, very delicate combination because they may not be the same party. I may have allowed my prefix to be advertised by someone else, so the real question we all have is where is the credentials that were passed over, where did the address holder actually explicitly authorize the AS holder to originate that route. And if you really want to push a little bit harder into BGP and you're actually looking at an update coming in on your routing system, you might want to know something else; is that path authentic, and here you went to a multi-year discussion in the routing protocol security requirement working group of the IETF, but I really can't figure out which of those two statements is the right one. Does it represent a viable or actual transit path from where you are to that prefix or something a lot stronger. Did that sequence of update paths represent the paths that the BGP update message itself took through the network. I actually don't know which is better. I certainly made computation that the first one probably looks a little easier than the second, but either way you really are worried about the authenticity of the path. We have today a routing system which is an approximately good system. It's approximately good because, quite frankly, if you really, really want to be naughty, there are two places to be naughty that are very, very hard to detect if you do it right. One, of course, is our good friend, the DNS, and the other one is our even better friend, the routing system, and if you want to combine the two and advertise a fake instance in any cast of a route server, in effect one of the route servers of the DNS, the DNS route servers, then quite frankly you can do an awful lot of damage and not be seen. So how do you make the system more reliable? How do you actually get rid of one of these quite fundamental weaknesses in the internet model? Wouldn't it be good if security was good, fast and cheap and simple? Wouldn't it be brilliant? Wouldn't it be good if we actually had a reliable infrastructure here that we could validate these assertions about addresses and their use, that you could actually look at the routing system, the current snapshot of them and be able to say something quite definitive about the addresses and the originations and paths that are in there rather than all of us pouring over bogone lists day after day after day. So wouldn't it be good if we could actually publish these routing authorities such that a resource holder can publish something that cannot be altered or forged, and you as a third party on your system can be able to authenticate that that was really the assertion made by that holder of that resource, that's all they said and nothing more. And what would be really gooder is to do this gooder, faster and cheaper if we really had a reliable, efficient and effective way of doing this such that good security would be a cheap and natural alternative rather than an expensive luxury that none of you could or would want to pay for. So wouldn't it be good, gooder, if we could take some of these fuzzy assertions, some of these risk-prone things, some of these rumors, and wouldn't it be good not to have to rely implicitly on trust mechanisms of other people. If you look at the origination proposal of yesterday, the implicit trust of ARIN's process, implicit because it is not demonstrable outside, is a key part of that proposal. What would be good is to be able to actually validate what was implicit and make it explicit, to actually be able to test these assertions for yourself and demonstrate to yourself that they're either good or bad. So all of this motivation underpins the trial that we've been doing. It certainly started out in APNIC many years ago, but we've actually strengthened I think and done a huge amount of work across 2006. We're basing this in standards work, so the underlying mechanisms are not attribute certificates, but resource certificates, so it's a full-blown X.509 version v3 public key certificate with a critical extension; in other words, if you don't understand it, you can't validate it. The critical extension talks about IP addresses and ASNs inside the certificate. RFCs quoted, the approach we've used is to actually try and invent as little as possible; in other words, use whatever we can get hold of, particularly in the open source area, and leverage upon that with extensions to those tools and contribute back as open source tools and open standards, so we're trying to do this in a way that actually works inside the open source community and works with them, so the foundational platform of course is open SSL. If you look around, that's one of the, I think monuments, if you will, in the security area and it's a damn fine piece of work, and part of the trial program is indeed adding support for resource extensions to open SSL. X.509 is worse than a camel, I mean it is just so gallastically weird. As a security standard it seems to say, well, do anything you want vaguely and there's a huge amount of trying to design a profile for resource certificates that actually is much more definitive, much more restrictive and much easier to compute over, so we have done a huge amount of work in the design of a certification framework of making particular choices in the X.509 specification and anchoring this on what we do in terms of distributing addresses around. The certificate says some things and doesn't say others. The certificate says that the subject, whose private key -- sorry -- whose public key is contained in the certificate, they own the private key, it's their secret, whoever they may be, and it doesn't explicitly identify them. You may put your own name in the subject field, but it isn't saying that's who I am, it's saying what I have a right to use, and the certificate says that that person who has that public key there is the current controller of these resources and the resources are inside the certificate, and all of that of course is assigned to the private key by the issuer. So it's not an attestation about identity or role, it's an attestation that binds that private key that you have to rights of use of a number resource. And also, there is nothing else in the certificate, so it's not an attestation about any form of related routed policies or any other kind of attributes you might want to express. If you want to express those, say it somewhere else and sign it. The certificate itself is simply an instrument that allows you to sign things saying I have these resources and a right of use form. So how does it look? This should be a structure that should be pretty familiar to all of you. IANA, RIRs, possibly some LIRs or NIRs in the APNIC context and some ultimate recipients of address space. That's how addresses are distributed. What we're really saying is issue certificates that precisely match what you did, no more and no less. In other words, talk about certificates in terms of what you do, what you have direct knowledge of, and if someone really wanted to, that they could work backwards over documentation and actually say, yeah, that really is a certificate that's valid. What does it look like? Let's take a APNIC context. Here's a national internet registry, NIR2, APNIC issues them a resource, 192.0.0.16, and actually put the public key of that NIR and sign it with their private key. What it's really saying is that APNIC has issued that resource to that entity. They might then issue it down to an ISP. Now the issuer is the old subject, it's NIR, and the subject is now the ISP and they sign it with their private key and of course publish the public key of the recipient, so now the NIR has allocated 192.2.200/24 out of that certificate. So if you were choosing to validate this, you would also make sure that the resources listed in the subordinate certificate are a subset of the resources listed in its superior. And of course this ISP might want to issue a self-signed certificate, one that effectively it issues to itself as an end entity. I issue this certificate to myself. Why? We'll see. So here's something that's pretty typical now. I want AS 6500 to route my private prefix 192.2.200. You can look at this and go, who made this document up? Is it really ISP4? Do they really have that address? By itself that says very, very little. You actually don't know where it came from and why, but I could add a certificate, that end entity certificate and I could sign that with the matching private key of that certificate, so now I've got quite a strong statement that if you look at this as a third party going why am I seeing AS 6500s announcing this prefix, what would you do. Well, the first thing you would do is a bit of cryptography, does the signature match the rest of the text; in other words, did that private key really match a private key -- sorry -- did the private key really, really sign this and you do a test with the corresponding public key. So now you can say yes, that wasn't changed, it wasn't forged, it wasn't altered. The key signed it, cool, but whose key. Where did the key come from. The certificate starts to point to a few things. You now say is the certificate valid, are the dates in the certificate corresponding to or at least covering today when I'm doing this test, does the cryptography match, and now the real test, is there a path of valid certificates all the way back to the trust anchor of your choice. If you trust APNIC to certify accurately what it did, then APNIC will have issued a certificate to that NIR that you can trust. The NIR has issued a matching certificate down to the ISP and the ISP has issued an end entity certificate. If all of that holds, you can now say a number of quite powerful things that you couldn't say before; it really, really was signed by ISP4 and that really, really is a valid address in play, duly delegated to them, ISP4 holds that right of use. And whenever I see that in route registry or in BGP or whatever, I now know it has the explicit permission of ISP4 who currently holds that address; I know. As long as I'm prepared to trust the trust anchors, the rest is a computation rather than a guess. So certificates are a very, very strict form of actually making sure that what you're seeing corresponds to reality. So, okay, you get a certificate; cool. What can you do with them? If you are some kind of intermediate registry and you do allocate addresses further down the food chain, then you can issue subordinate resource certificates to actually map what you're doing as a resource distributor. So you would issue signed subordinate resource certificates to people that you have given addresses to or AS numbers or whatever and maintain -- because you're now a certificate authority, maintain a collection of everything you have done that matches the current state, so the certificates that you have published as certificate authority are, in effect, an exact mirror of what you do as an allocator in the registry. What about when you have a certificate? Well, realistically the true fun starts when you sign things. So you can sign routing authority, routing requests, WHOIS objects or even internet resource or route registry objects with your private key and also reference and include in what you sign the certificate corresponding to that key. So you can sign an attestation with a signature that's associated with the right of use and all the rest of us can see these things and validate them. Was it really you that produced that document, has the document been altered in any way, shape or form since it was signed and is it valid today. All of a sudden you actually have a very, very tight form of understanding the validity of what you're seeing in all those various places where you can publish signed themes. So here's a signed object. Some of it looks familiar. There's only two bits added, the two bits that got added are the sigcert and sigblock. The sigcert is the certificate, my certificate, or in this case an example certificate drawn from Telestra, and the signature block is being used to sign all the rest of the information including the expanded sigcert. Notice up there, too, in the traditional route registry object there are a bunch of addresses in there, IP resources, so if you went and looked at the matching certificate, what you would actually find across there is that this certificate includes a resource set which covers everything that was in that route registry object. How would you use it? Not many folk are really, really keen on being a certificate authority. Not many folk really, really want to buy a lunar SA, the HSMs and all the other paraphernalia of certificates. Not many folk I think truly want to go to that expense. Some will, and for very, very good reasons, but everyone's mileage differs. We're certainly looking in terms of use scenarios at secure web portals, portals where you outsource this kind of activity back to someone you are prepared to trust, and that portal can generate and sign objects. That portal can actually be used to validate the signed objects against that resource PKI, and if you are doing allocation further downstream, it can manage that subordinate's certificate issuance and indeed automate a good deal of it, backing up what you do as an LIR or an NIR. Maybe you don't trust that kind of portal. Maybe your line of business, whatever it is, says I really want to do it myself, so we're also looking at local use tools, tools that you can use and deploy that actually do local repository management, sign objects yourself directly with your own machinery, generate more certificate objects and indeed if you really want to generate and maintain a local cache of all of the certificates in the system. Why would you generate a local cache? If I ever live long enough, we may see secure BGP, and if you really want to do validation in anything close to realtime, you might need most of the certificates around very, very close to you so that you can validate, which is an expensive operation, but you can validate the stuff as quickly as you can by simply maintaining local copies of certificates, and of course validate stuff against PKI. So I was going to do a quick demonstration because I felt that the last few times I've talked about certificates, I've actually done this stuff entirely wrong. Talking about how great cars are by explaining the workings of an internal combustion engine is somewhat bizarre, and I feel that I have been talking about the internal combustion engine and certificate fields and aren't they wonderful and the true beauty of all this kind of stuff; kind of irrelevant really, isn't it? So instead, I actually want to talk about how you can abstract this out and how you can look at this without actually having to look at the certificate and try and figure out what's going on. So we have a web portal here with effectively a local incidence of an ISP sitting behind it. It's got a certificate set so the resource that it has already there are certificates, it has keys, it has a local certificate authority and a key manager, it can actually generate end entity certificates and maintain resource collections and so on. Let me talk very quickly about what you will see. You wouldn't use one certificate to sign everything. You may want to, for example, restrict the resources that you're going to use to sign something to a particular purpose so that if you have transit upstreams, you might sign some kind of I give my transit upstream permission to carry these routes and use only those routes and only those resources that you're passing to that transit. You may have a different set of resources that you use for customers and so on. So the first of this is actually managing your resources and putting names on subsets. So here you see an example, there's all, everything that this particular example entity has; the AS number, the IPv4 addresses, the IPv6 addresses and so on. So the first thing this thing does is just manage the resource collections. The only true use of certificates is when you sign things, because that's what certificates do, they allow other people to validate your signature. So the other part of this is actually a signed object manager. Documents can effectively be signed with a resource collection and the validity dates on the certificates that you use to sign them actually determine the validity of the document itself. I give permission for you to advertise my routes up until the 1st of December. Generate a certificate, the validity expires on the 1st of December. What you don't see in either of these two interfaces is the underlying certificates and that's deliberate. So I'll do a quick demo, but be aware that we are working on this quite actively, and late last week I got a note from George Michaelson here about, yes, I think we're ready. It does seem to work, but check very carefully. So we'll see how and whether it really does work, and I'm going to do two things. I'm going to try a demo and I'm going to try a demo on a machine back in Australia, which is, I think, doubly tempting the gods. These are resource collections. It just simply attaches names to subsets of resources, so any way you want to slice and dice what you own, you can add another resource name to collection here, so I might have something about an AS number. It wants some kind of description, I don't know why actually, and I might give it AS 1221, so I've just simply created a subset of resources which now has AS 1. Bigger, you want bigger, let's try bigger. That's more like it. There's nothing much there. You know, you click on the AS number, and oh, yes, AS 1221 is there, fantastic. The real thing, though, comes when you try and sign things, so the next thing is actually saying, well, what can I sign, how do I do the signature. So let's go to a signed object here. I would like to add a new signed object, so it says, as it should do, what do you want to call it, who knows, what's its description, what resource collection, what particular resources are you going to use to sign this object. And now two fields there, valid from, valid to. If I've got a contract with an upstream that expires next month, I may want to put the validity only up to the period of the contract; in other words, those dates are to what dates am I attesting that this is an accurate thing, when does it become invalid. What are you signing? Anything you want, absolutely anything, all these files to sign. No clue what I'm looking at here in terms of what files I have, but I can sign any object. This is a file. I have signed that file with the AS number resources. Here is one I did earlier. Here is the resource. It's a couple of IPv4 prefixes. What did I sign? I signed an object. What does a signed object actually look like? Mime, hideous amounts of mime. Let's take a copy. Why? Because what I would like to do is validate if that really was a valid field. So now I'm going into the other part of this demonstration that goes can I validate signed objects, what does it look like. Obviously validation is successful. What it's telling me is that those two resources, 58.160/13 and 203 blah, blah, blah, were duly allocated to this particular entity. There was a path from APINIC that showed the delegation that went all the way through, and the data that was actually signed is that particular text file there. There is no certificates that you're actually being forced to manipulate. This is just merely a case of signing things and testing their validation. If you want to look further, that's the original text file. Let me make this hideously bigger again. That's the mime object, heaps and heaps of Base 64. If any of you are Base 64 fanatics, decode now. What's the certificate? This is the certificate. The bit that's really important here is just where it says SPGP IPv4 address block critical. It says critical for a very, very good reason, because if you ever try and pump it into something like Windows, even though it's in 2. Font, what Windows says is I do not have enough information to verify this certificate because the resource extension is not recognized by these kinds of engines. It is a critical extension, so if you see it in a certificate, you must be able to understand it. If you don't understand it, you cannot validate it. That's why I feel a little bit of work has to be generated. We couldn't just make these very simple browser-based certificates, it doesn't work like that. So what have we done? Sorry about this power point. Very simply shown, how you use certificates can be done in a way that actually hides most of the mechanisms of the certificate itself, but this can be treated as a relatively simple case of understanding how to sign things and how to validate things. So where are we right now? Over the last few months we've done a great deal of work in terms of taking the -- I wouldn't say hideous mess that is X.509 v3, how dare I say that, but taking the melange, the fuzzy specification of PKI certificates and making quite specific choices about what resource certificates really have, looking at generation of repositories that tightly align -- not just tightly align, but precisely align to how allocation actions happen to existing resource allocations and assignments. Tools for actually the separation of registration authorities and certificate authorities, registration services, the underlying topography, how do you do that handover, how do you actually make that work, and that work has actually being undertaken by the RIPE NCC over the years, and of course tools to perform validation. We're still working and are basically very, very close to completion open source contributions into open SSL. This particular work is being done with Randy Bush and Rob Austein and its being generously supported by ARIN, which I thank them. We're also doing extensive tools for managing resource collections, managing object signings and signed objects, you've seen that sort of demonstration there, trying to abstract certificates and actually look at their use rather than their mechanics. That work is also being done with Rob and Randy and folk over at APNIC. Tools for certificate management for you as ISP or an LIR, and of course testing, testing, testing, testing, testing, and also a good deal of work at looking at the operational service profile, what kind of infrastructure will be needed in APNIC to support this all the way down to machinery as well as bandwidth, servers and so on. Next steps. We started this trial about 12 months ago and we certainly intend to complete it in two months, so complete most of this by the end of this calendar year, but in APNIC we'll be doing quite an extensive evaluation over the next couple of months looking at how far we got, looking at the bits that we didn't get done in that period, looking at the kind of work that really applies, also to have a very extensive appraisal of was it really what we intended to do, because often in these kinds of projects you end up with entirely something else, and we certainly would like to make sure that the original objectives were, if you will, addressed; that what we didn't achieve there were good reasons and what we did achieve, although deviant, there were good reasons to be a deviant. Very deeply, however, also look at the implications of this form of certification of resources. There's no fuzziness with certificates. There's either a certificate and it's valid or there isn't, and then there's no information whatsoever. So when you return an address to an RIR, the certificate should be revoked on the return. There's no intermediate space for these things, those kinds of implications and further. Certificates can be seen as quite a tight right of use in this kind of context and actually understanding those implications is part and parcel of this exercise. We're also in APNIC going to do a critical assessment of its infrastructure, the operations, how well it integrates into our existing services and the utility of this kind of authentication model and the underlying considerations of policy, of which there are an awful lot, and also have a look at what will need to be done to take this to production. Interestingly, last week I saw a very similar presentation from Axel Pawlik from the RIPE NCC indicating a very similar approach with one subtle twist that I must admit I appreciate and I think actually works very well, that this evaluation in the RIPE community will actually be done with members with folk from the community themselves, so certainly in APNIC I have taken that on board and we'll circulate this amongst the membership of APNIC to make sure that we all understand where and why we're heading, and that if we do choose to go with this all the way to production, it is a clear and definite choice. Credit where credit is due. George, Rob and myself from APNIC, Randy and Rob with generous support from ARIN, Rob Kisteleki from the RIPE NCC and Steve Kent and Russ Housley, who many of you who have been in the security community probably know them very, very well, have been more than generous with their time in assisting and advising us when we got thoroughly lost inside some rather fuzzy RFCs. If you really want to play with this stuff, and you can, and you want to look at the enormous amounts of, if you will, debates and considerations of how we got to where we are, that particular URL is out there and the URL for this project, so you're more than welcome to have a look, download the tools, play with it yourself if you feel so inclined. So I think that's the end of it. Any questions?

MR. CURRAN: Does anyone have questions for Geoff? Right corner over here.

MR. KOSTERS: Mark Kosters, VeriSign. So you have these wonderful certs. Where do I find them?

MR. HUSTON: Certs are published by issuers. Let me follow this through. Where you find them is in what they call the subject information access field of the certificate itself. Wow, that's weird, I need a certificate to find where the certificates are; big problem. However, certificates have two ways of being found. If I have a certificate in my hand and I want to validate it, it actually is going to contain the URL of its parent. Lift it up, URL of its parent. Keep going back until you find a trust anchor of your choice. So you can do the equivalent of OCSP, the online certificate service portal. You can also start the other way and actually build your own cache of certificates, take the trust anchors of your choice and follow all the SIA fields downwards and just collect them all up and put them in your local area. We'll be doing tools for both. So either where you find them is you have one and you want to find whether it's valid or you have some trust root point certificates and you want to collect all of its descendants.

MR. KOSTERS: So if I have an IP address, how can I find -- that's in my routing table, how can I validate the route? What is the first thing that you have to do? Do you go to an IRR to get that information?

MR. HUSTON: Today this way without secure BGP handing around various bits and pieces, you would go to an IRR. That's a very, very fuzzy answer because there are many IRRs. One would hope that you're able to sign wherever you publish, so if an IRR has that object and it's signed, you now have a certificate in hand, you can now proceed to validating. This is not DNS SIC and some might say that's very, very good and I might agree with them. The reason why it's not DNS SIC is that DNS SIC had adopted a checkerboard pattern of trust keys, it hasn't been from the root down, and I suspect that of all the other aspects of DNS SIC that's been the toughest, so what we're trying to do here is actually make the trust model work from the top down from the start.

MR. PLZAK: Okay. Thank you. Sandy.

MS. MURPHY: I have two questions, so I'll ask one, then I'll turn around and you can go to someone else. Sandy Murphy at Sparta. You displayed a diagram of IANA to the NIRs to LIRs to ISPs. Each of the lines in those diagrams, if you started at the point that was ARIN, each of the lines is roughly equivalent to a template, like ARIN's -- the NISP and allocate templates, okay. Could one suppose that one might take ARIN's collection of templates for the direct allocations and assignments and sign them all and produce certificates?

MR. HUSTON: Certainly in the trial what we have been doing is using that style of information and generating trial certificates. I suspect, though, that that's cutting across a few corners of due diligence, because once you had certificates inside your process, any further issuance of resources can be certified cleanly. Certifying history is always a little bit more of an issue, so there's certainly a part of this evaluation, how big a task is it to certify our history as distinct from how big a task is it to certify what we're going to do in the future, and they are quite separate work items, but yes, the glib answer is with a lot of work somewhere we can certify history where we definitively understand it.

MS. MURPHY: So this is part B of that question, not my second question. If you get down to the bottom and you're signing the route origination, let us suppose that there was in the template some record of AS originations. Do you believe that it might be possible to produce a route origination of that data also?

MR. HUSTON: This is the route origination authority. This would be actually what you would launch somewhere. It's actually your own document signed with a certificate that provides for the validity and authority.

MS. MURPHY: Yes.

MR. HUSTON: This particular route origination authority requires no other form of validation other than the certificate chain.

MS. MURPHY: Yes, I know, but I'm supposing that you've generated the certificates from your history and you have in hand something that says this prefix is going to be announced by AS.

MR. HUSTON: I would let that prefix owner and holder -- I should use the word holder -- that prefix holder actually do that generation of that object. It's their prefix, it's their routing.

MS. MURPHY: Yeah, but you already have the information and if you generate the certificate, you have the key to doing the signing of that also.

MR. HUSTON: Oh, the key is owned by the ISP. It's their key, not my key, not ARIN's key.

MS. MURPHY: Okay.

MR. HUSTON: It's their key. I can't sign for them.

MS. MURPHY: You proposed one mechanism where the ISP would have the registry --

MR. HUSTON: No, I did not say registry. And again, very careful choice of words here.

MS. MURPHY: Okay.

MR. HUSTON: I was careful to use the concept of a web portal.

MS. MURPHY: Okay.

MR. HUSTON: Whoever you're prepared to trust to be your trusted agent. You might trust your RIR, you might trust someone else to do that work. It's not apriori that the RIRs have to do this job or even need to do that job. That's part of our evaluation as to how much the RIRs will need to do in this.

MS. MURPHY: I'm looking for a suggestion of possibility, not that it would happen that way.

MR. HUSTON: Okay.

MR. PLZAK: Bill.

MR. DARTE: Bill Darte, I'm with ARIN Advisory Council and Washington University. I'm just wondering about the legal implications and have you thought about this, because I've looked at the warranties associated with commercial CAs and they basically say we don't really mean it. The attestations of association that are in our certificates don't -- we don't really mean that, more or less.

MR. HUSTON: There's a great deal of work to do, Bill, and that is certainly on the agenda to truly understand those kinds of implications as to the strength of these certificates. Certainly I would expect the RIRs to say we did it, we mean it, it's accurate, this is the allocation, that happened. That's my expectation, but to what extent we need to work through that, we're going to evaluate.

MR. PLZAK: Ed.

MR. LEWIS: I have a few questions. One question I'll ask first is how does this relate to what's in Proposal 2006-3? Is this what we see coming after something like 2006-3 where we collect the information and put that out as available? Because that's where I got confused about 2006-3. I thought that would lead into this work, but after hearing about this work and thinking about it, I don't know if those two are related to each other.

MR. HUSTON: I think that if you went down this path, they wouldn't be tightly related, in my personal view. Of course the entire issue of publication of signed outcomes is finessed inside this presentation and inside this work. Publication of certificates, easy; validation of certificates, easy; validation of signed objects, therefore, easy, but how do I get the signed object to validate. Certainly I see an application almost immediately of this as populating our route registry, but as I responded to Sandy a few seconds ago, it's me that has the key, I sign the object, I publish the object, it doesn't get published and signed for me. And that may be a critical difference in terms of who has the responsibility of doing the work. And certainly tools can be created, it can be made easy, it can look like 2003, but ultimately, you know, it was my finger on the trigger as the end user, the right of use holder of the address.

MR. LEWIS: I guess the question I'm asking comes out of the fact that ARIN is helping to fund the tools of this work, but we also have the policy proposal before the AC to do the other work and I didn't know how they balanced with each other, not the technical relationship, but how ARIN is treating this.

MR. PLZAK: Let me say something here. What ARIN's involvement at this point is is that the board has desired and seized the fact that the IR should have something that's interchangeably working between them, so therefore our efforts in this area are to ensure that the underlying development work would produce something that we could use if we wanted to use it. Let me take Randy first, then I'll come back to Sandy.

MR. BUSH: I was going to come back to Sandy actually. Randy Bush, IIJ. Sandy, you're deeply --

MR. PLZAK: Bill -- I know that's a second question, I'm aware of that, but Sandy's second question comes before his second question.

MR. BUSH: Sandy, you are rather deeply in the security area, A. B, you know something about the quality of the data of the registries where RIPE's registry thinks there's allocations out of 7/8, which of course is IANA reserve, and there are people in prominent positions in this room who have things registered which they really don't own and I don't think -- I can't imagine why you would suggest generating authoritative signed certificates from what we know to be very flawed data.

MS. MURPHY: I'm looking for a means of -- I'm looking for an idea of whether it would be technically feasible; not a good idea, but technically feasible to reduce the start-up costs of everybody having to do something new for each and every allocation.

MR. BUSH: Yes, we could quickly produce sows ears. That does not make them silk purses.

MS. MURPHY: Yes, garbage in, garbage out, I understand.

MR. BUSH: That does not make them silk purses. Certainly you could write the code to go forward. You can do it in a day.

MR. HUSTON: Could I just say that on the whole, certainly with the more recent allocations definitively with even some of the others we are confident in some of the data, but that doesn't mean you can run a program over the lot. I think there's a certain amount of understanding where we clearly understand and know that our data is good and I certainly have spent many years trying to look at the registry data and understand which things I can automatically classify as less than good.

MS. MURPHY: Yeah, but this --

MR. PLZAK: I'm going to have to close some mics pretty quick here. This is very, very interesting conversation, but we do have a lot more stuff to discuss here, so is there anything -- okay, thanks. Sandy.

MS. MURPHY: My second question?

MR. PLZAK: You had a second question?

MS. MURPHY: Yeah.

MR. PLZAK: And could you please make it brief.

MR. MURPHY: Golly. The route origination attestation --

MR. PLZAK: Mark, were you in line? You can be in line. Go ahead, Sandy.

MS. MURPHY: The route origination attestation you indicated is signed by the prefix holder. I had asked this morning about IRR's support for something called the routing policy system security which the gentleman from RIPE indicated is being done. In that document route objects which indicate that a prefix can be originated by an AS must be attested to by both the prefix holder and the AS holder, and I did speak with a gentleman who can raise his hand if I wishes to be identified, who said that he would prefer that model because otherwise someone could say I give permission to AS123 to originate my routes -- Owen raises his hand -- and AS123 has no idea that this is happening and the person produces a route with AS123 as the originator and then bad things happen coming from that prefix and AS123 gets the calls. I would like your comments on that as a security model.

MR. HUSTON: Well, it's trivial to implement. In this particular case ISP hands a document you're seeing right in front of you across to AS 6500, AS 6500 would sign it again --

MS. MURPHY: Yes.

MR. HUSTON: -- with their AS, so yes, it's trivial to implement.

MS. MURPHY: But that wasn't my question.

MR. HUSTON: Does this need to be bilateral in terms of security?

MS. MURPHY: Yes.

MR. HUSTON: Personally I don't think so. That is purely a personal observation as distinct from an oh my God it has to happen this way or bad things will happen.

MR. PLZAK: Okay. Ed and then Mark and then that's it.

MR. LEWIS: A question about I guess operational complexity; not the complexity of setting this up, but in using this stuff. For an average advertiser for a prefix and whatever average would be, how many certificates do you think would be involved in certifying or validating that this advertisement is true?

MR. HUSTON: I had a look at that actually and had a look at -- you're talking about validating in BGP itself?

MR. LEWIS: Yeah.

MR. HUSTON: Validating in BGP. I did a quick scan across BGP updates over a period of 14 days and found that if you're just looking at origination validation, around 88% of all BGP updates you have seen before sometime in the previous 36 hours and sometime in the previous 1,000 prefix updates. Quite frankly, most of the things we see in BGP are boring repetitions of things that happened seconds ago. The whole validation issue, to my mind, is being vastly bloated and vastly inflated without true data. I don't think it's as big a problem as many people make out.

MR. PLZAK: Mark.

MR. KOSTERS: Mark Kosters. My question is is there a way that you can help bootstrap this before it all gets under way? Is there anything one can do that can help bootstrap this?

MR. HUSTON: There are two things that I must admit we would appreciate. The first of these is that URL there contains our current best thoughts about this. If you're deeply interested in this area and want to help, certainly have a look through that and send us mail, send us comments. Secondly, I suspect that ARIN as well as well as RIPE and APNIC will be actually doing this kind of exercise one way or another of evaluation. I think if you have views and opinions, although it's ARIN's call, but those topics I think are topics for the community, not any individual RIR and I'm sure some kind of feedback I would expect at some point to understand where we're going. Thank you.

CRISP Status

MR. PLZAK: Thank you, Geoff. Next item will be a discussion or report on CRISP status by Tim Christensen.

MR. CHRISTENSEN: Good afternoon. I'm Tim Christensen. Most of you know me as the foosball coordinator at ARIN. I've got just a few slides to talk about CRISP for a few moments. First an update on where CRISP stands as a working group in the IETF. Most of the working group goals and milestones have been completed. The remaining goals and milestones as far as the CRISP working group stands are -- and this is a -- this next bullet contains about 11 modifiers to a noun, so I apologize. Domain and IP address registration, administration directory services required, schema element specification drafts still need submission to the IESG for review. That's a lot of words that basically says that there's a couple of documents on their way into the IESG for final review for proposed standards, and the domain availability or DCHP registry time for the IRIS needs to be submitted to the IEGS for review. It's not on the slide, but I just checked recently and the type that ARIN community would care about which would be the address registry or AREG type has been submitted to the IESG and is currently in the RFC editor queue. So that's what's happened in terms of getting the protocol defined. What has happened in the RIR space with regard to CRISP? Well, over the RIPE NCC they have built a prototype for a CRISP compliant server for a number resources and it's been available since September of 2005, but there has been little or no feedback from their community on what they think about that server. Andrei is here and can make further comments if he cares to, but the information we've received is that there has not been much response or input from the community. In LACNIC, the LACNIC folks did develop a prototype for domain names only, not for the address space, but they found that it didn't interact well with various client implementation and they are continuing development for domain names. Again, I point out there is no current development in the address arena that we're aware of at LACNIN, and Raul, you can correct this if any further movement has happened there, and there has not been any development or movement up to this point in AFRINIC, APNIC or here at ARIN. So the questions that I'm here to ask today are the following: Number one, is the ARIN community interested in CRISP, and question two, should ARIN develop a prototype and deploy that to move in the direction of a CRISP V service.

MR. PLZAK: Microphones are open briefly, but just I guess generally I would just like to see a show of hands to get a sense of what the answer to the first question would be, which is -- so I'll ask you, are you interested in CRISP? If you are, please raise your hand. I guess the better question is do you know what it is. Okay. Thanks. Do you think ARIN should develop a prototype; how many think we should? Okay. And how many people think we shouldn't? How many people think we should wait and see what happens? Okay. Thanks. Lee Howard.

MR. HOWARD: My name is Lee Howard. I'm on the Board of Trustees. I did my own count of hands there, and by my count six people were interested, but nine people thought we should develop a prototype. I don't understand.

MR. PLZAK: I saw that as well, Lee, and I had to figure out what I was going to say when we discussed this with the board.

MR. LEE: It may be I think your sort of corollary question, whether people know enough about it to know whether we should do anything about it is actually a valid question. Do we need more education before we can decide if we should move forward.

MR. PLZAK: Right. Given the fact that a working prototype has been out there since September without much feedback from the community where it's deployed and some problems with another deployment and there has been no real activity in the addressing world in four of the five regions, it kind of begs the issue a little bit. Bill.

MR. WOODCOCK: I just got a private note from someone suggesting that maybe it would be useful to have a quick primmer on what CRISP is, and given the number of people that raised their hands knowing what it was, I think maybe like two to five minutes would be useful.

MR. PLZAK: You've got two minutes to do a CRISP primer, and actually it can be done that quickly really.

MR. CHRISTENSEN: It probably can, I don't know by me or not, but it probably can. I'll give it a try, and my apologies to all of the authors for all of the mistakes I'm about to commit. CRISP stands for Cross Registry Information Service Protocol. It is essentially a work that came out of the original NOC 43 or let's get over the WHOIS thing protocol development. The idea was to create a service that would essentially replace WHOIS with something that is, well, better, or as Geoff would have said, gooder. The replacement essentially uses new technology. It applies concepts of authentication. It applies encapsulated information, and by the way, it does referrals. There's a whole piece of CRISP that will, if you ask somebody a question, it can figure out whether or not you're asking the right person the question. If you're not, it can go get the question answered for you and return it to you. I won't get into the technical foundation of what lies underneath all of CRISP, but there have been a couple of sample implementations that were created in the process. The one that moved far along and got input from some of the people in this room was IRIS, and that has been the basis for the work that has been done since then to stand up sample implementations or prototypes.

MR. KOSTERS: Can I add just a few things?

MR. PLZAK: Yes, you may, Mark.

MR. KOSTERS: Mark Kosters, VeriSign, actually one of the genesis of this. So it's XML based and it has two things that Tim didn't mention that I will. One is based on authentication that Tim mentioned, you also are going to have access to control, so therefore only the right people can see the right things, and right now you don't have that sort of ability in WHOIS. And the second part is that it's truly multilingual. Right now we know WHOIS not multilingual, so -- and the reason why this was created was to counter this whole sort of storm that's actually occurring on dealing with privacy versus need to know, and WHOIS does not have that ability to enforce that. It's all or nothing. CRISP -- or IRIS, rather, allows the ability for people who need to know to see the information that they need to see.

MR. PLZAK: Ed, did you have something to add to the description or are you asking questions?

MR. LEWIS: I was going to say why I support it. I'll wait until we're finished.

MR. PLZAK: So I believe -- Bill Woodcock, is that primmer enough for you?

MR. WOODCOCK: I wasn't the one who --

MR. PLZAK: Well, you raised the primmer issue. Okay. All right. So Ed, go ahead and make your statement.

MR. LEWIS: Ed Lewis, Geoff Huston World Tour 2006. I was going to use that last time and forgot about it. Actually there's -- the two reasons I think that CRISP or IRIS is a good idea to pursue in general, not necessarily for ARIN right now or whether it's a good or bad idea, one example I thought of while I was sitting up here is that I've started using LACNIC WHOIS because no matter what IP address I put in there, it goes to whoever it belongs, if it's a RIPE address, if it's an ARIN address, it's good to ask one server and go anywhere. The referral service that Tim had mentioned, that's one real important component of that that I can ask any IRIS server and get pushed to where the data really is. The second thing that came up is about access control, and I want to enforce that that's actually what I thought would be the big winner for the IRIS protocol because we have so many questions about who has data access right now and any piece of data that we -- we have law enforcement that wants certain data, we have privacy things come up in other places. IRIS has a built-in capacity to let us differentiate the user based on who they are or what their rights and privileges are and what they get back, so I think IRIS is a good platform to build on that. That goes back to the WHOIS reformation proposal that Leo Bicknell was working on for a couple of years and it eventually disintegrated because it was too much work, but I think that's where IRIS has really big win for organizations and that's why I pushed it in the past, too.

MR. PLZAK: Okay. Just to let you know, this is not a trivial subject for us, by the way, and we do intend to stay with it, and this will not be the last time you see us before you discussing it, so if there's nothing else, Tim, thank you. Matt? Okay. Matt's asking can I re-poll the room on the questions, so I will do so. So given the fact that Bill Woodcock has now agreed that we now have a better understanding, are you interested -- as the internet community interested in CRISP given what you've heard and what Ed and Mark elaborated on? Okay. And I guess I should ask the opposite question. Is there anybody here that is not interested or doesn't care -- think ARIN should not be interested in this, and I'll ask the second question again, should ARIN at this time develop a prototype? Answer is yes to this question, do you think ARIN should develop a prototype? Okay. And how many think ARIN should not be involved in this type of activity? Okay. Thank you. Mark.

MR. KOSTERS: Ray, I'm sorry. I have one additional suggestion. A large part of this is latent with policy, and so you can't just say we'll develop a prototype. We also need to have -- need to start thinking about what is the appropriate measures of allowing who to see what and how is this going to be done, and that needs to be done jointly along with this venture or separate or however, but that's another part that needs to be added into it.

MR. PLZAK: I agree, and I would anticipate that those who are the stronger advocates for adoption of this would be willing to make the appropriate policy proposals and guide them through discussion. Okay. Thank you.

WHOIS By The Numbers

MR. PLZAK: So now, Leo. There he is. And Leo is going to -- his name has been used a couple times in the last few days about WHOIS, and so you get a chance to do WHOIS again. Leo is going to give you a presentation entitled WHOIS By the Numbers, and he's done some statistical studies I think you might find interesting. Leo.

MR. BICKNELL: My name is Leo Bicknell. I work for Harrah's Entertainment. I'm also on the Advisory Council and most of you are probably well familiar with me as the WHOIS whipping boy, having been up here at several meetings now, and I think this is going to be fun, fun for a couple of reasons. One is there's no policy proposal here, so you don't have to take this with all that heavy weight and decision making that goes on, and the second is I'm actually up here to kick the hornets nest, and that's you guys. I really hope there's huge long lines after this and everyone is unhappy, because that's a good outcome, so this will be fun. And, you know, on the bright side, after the first 75 slides of math, you'll understand the next 38 slides of statistics, so you will enjoy this. But let me talk about where this came from. We all love this title, purpose and scope. We keep talking about what should be in WHOIS, why it should be in WHOIS. We've all been at a policy discussion, gotten up to the mic and we've made wonderfully vague statements like that will affect all the Legacy holders. Well, okay. Is that three people, 300, 3,000? No one ever puts a number to it. And in fact, as I have done a bunch of WHOIS policy and talked with people, many people basically assume that everyone else puts data in WHOIS the same way they do, and it's not true. So the first thing I'm going to do here is I'm going to have a little fun with you being at the podium, I would like everyone who has sat down and read part of the policy manual just for fun to raise their hand. Wow, that's more than I would have thought. How many of you in the last six months have gone out and looked through other people's SWIP records just to see what they were doing? Interesting set of people, but it's not the whole room and we need to understand these things to be able to make policy on them, and I think that's been one of the things holding up the WHOIS policy is a simple lack of understanding of what's there, why it's there and who's putting it there and so forth. So what I'm going to try to do here is, first of all, make sure we all understand the basic structure of WHOIS, because there's some confusion on that, and with that we'll get some really basic statistics. We're going to try and analyze some of the missing and incomplete data and we're going to try to look for some of the stale data, and two things that have recently been large discussion items, I was encouraged to put forth some statistics, we're going to look at the effects of 2003-3 where we adopted residential privacy and we're going to kind of look at postal codes in WHOIS and see what we can tell about looking for those. As with any good presentation, we start with a disclaimer. I did all of this from a bulk WHOIS dump that I downloaded May 2nd, so certainly some more recent activities from this year are not in here. I have fact checked this with ARIN staff and a few people's names you will see in here and we believe it's still relatively up to date. It's important to recognize that some of the data in WHOIS is this Legacy data, and not everyone knows the date off the top of their head. ARIN became ARIN on December 22nd, 1997, so any data you see with a date before that is something that came from a different organization and was inherited and that has something to do with the quality of the data. Also, because it's really hard to do, I didn't include any data from an RWHOIS server; however, you will find later that I did some statistics on the RWHOIS servers that are in there and give you a little bit of information on that. So the first thing we're going to go through, basic statistics. WHOIS has five basic data types from the perspective of getting a bulk WHOIS dump. I believe that ARIN has a number of other hooks into it internally for some of the private data they keep and other stuff, but it you download bulk WHOIS, you see these record types. What happens is AS numbers, networks and in V4 and V6 can have organizations. They also have points of contact. Organizations also have points of contact, and I want to point out a couple of things here. Not all of these are required on every record type. Different things are required at different levels. The prime example is simple reassignment, as you're probably all aware, allows you to omit certain pieces. I forgot what I was going to say. Anyway -- oh, the color coding. You will find throughout this whole presentation that I color coded these items to make it a little easier to follow which one we're talking about, so that's why everything is a little bit different color, but I wanted to put numbers on these. How many records are we talking about? Well, 18,000 AS numbers, 1.3 million IPv4 records, 354 v6. That number has actually gone up a pretty reasonable amount since I took this dump since the numbers are small. 1.2 million organizations and 176,000 points of contact. Now right there that's an interesting number. There are 176,000 people who are responsible for 1.2 million things, so there's something to think about. All told, if you downloaded the bulk dump when I did, there's 2.8 million records to download and process. And I will say that if you're trying to do this on an older, slower machine, it takes hours to import this into a database. So let's look at what we most commonly talk about, IPv4 networks. There are six different tags that you can find on an IPv4 network in the database. Four of those sort of are directly from ARIN, if you will. ARIN makes assignments and allocations. ARIN also has, I believe, primarily Legacy records that are transferred to other RIRs and ARIN has a few records for things that are reserved. Then there are reassignment and reallocation records, both of which come from those of you who hold allocations, and basically that's what we think of as SWIP data, and so it really shouldn't be a surprise to anyone, the bulk of the data in WHOIS is SWIP data, in fact 97 percent. So when we talk about WHOIS records, we're talking about the data that you guys are putting into the database. The data that ARIN is entering directly is only 3 percent. An interesting comparison is IPv6. The reason the assignments are blank is because this dump precedes the ability for anyone to get assignments, so there really were none. That's one of the areas that have changed. There were 247 allocations. We see that there are already some reassignments and reallocations as well, so, you know, v6 should operate more or less as it continues to grow. One other way to look at this is unique organizations. If you take all of the IPv4 assignment records and trace that over to an org record, how many org records does that actually represent, and here's the numbers you see. It's interesting because these numbers are lower, which is what would you expect. That is, most organizations have somewhat greater than one record. Lots of people I'm sure in this room have 50, 60, 70 records they've gotten from ARIN, right? So overall there's 95 percent of the organizations are from SWIP. The numbers themselves, though, don't really tell the story. The story is when you turn that into average records per organization, you can see with reassignments, we usually give them the right size block on the first try. Most orgs only have 1.06 reassignment records. With reallocations, for whatever reason, it seems like we've got to give them three blocks before they have enough, and I'm not sure what this says. This is one of those areas where I want to kick all of you and say why is this. I'm sure there's good reasons for it, but from what I looked at, I couldn't tell you. So one of the other popular things that ARIN staff always stands up and does is produce these wonderful graphs of growth, so I want to show you some of the growth figures. Here's a graph of the autonomous system number growth. A couple of things that I want to point out that will carry through all these graphs. The first is there's 160 records in the database for autonomous systems that have no registration name. These are all Legacy ones, it is simply blank, no one seems to know exactly when they were registered. In reality, if you wanted to look at them, you could guess pretty close. At that time they were assigned in order and so you could find the one before or one after and narrow it down to a pretty small window, but I simply put those numbers up so you could see it. The other thing to remember with these is these only include data that is in WHOIS today. If someone got an AS number in 1985 and returned it in 1987, it's not there. It doesn't show up in the counts, so these are still in use resources by the year they were allocated. The first thing probably everyone is going to ask on this one is what's with this big drop-off at the end. Well, we're not entirely clear. I did ask ARIN staff, I did a little poking around myself, and the only speculation we have, although I'm not sure it covers the entire number, is ARIN's staff did start to do some reclamation efforts on sort of unpaid ASNs and thing of that nature, so that may account for part of what happened there. They started, my understanding is, recently and worked backwards, I think, so that's why it would affect the more recent ones first, but we don't really know why there's that big drop-off there. IPv4 networks show a much more sort of normal trend. An interesting thing I would point out from a statistical point of view is the lines that we end up getting, you'll see on a couple of graphs look fairly linear, and I'm not quite sure what to make of that. We often see a lot of graphs that look like exponential growth curves, but when you graph them over this longer time period, it seems like after we get through the knee of the curve, we've got a fairly linear growth. To me, this is expected because if you look at technology adoption, go back to the adoption of the automobile, of the TV set, pick your favorite technology, they generally start out very slow, they take a very steep path upward and then they level off at a saturation point, so, you know, one interpretation could be that we have gotten that widespread adoption and it's occurring as fast as it can and eventually we will level off. That could be 50 years from now, it could be next year. That's a very hard thing to predict and I'll leave that to the Geoff Hustons of the world to figure out. V6 networks, of course you couldn't get them back in 1980, 1985, so those numbers are zero for a good reason, but, you know, we've started on a fairly good up-tick on those recently, and this is the only record type, by the way, for which there are zero with a registration date missing, which I think is what we would all expect since we just started giving them out, but that's a good thing to note.

SPEAKER: The up-tick or the take-up of V6 networks, that is the 2001 prefix, that's not any of the prior IPv6 work, is that correct?

MR. BICKNELL: It is whatever is listed in WHOIS, so I would presume so, but I can't say that for certain.

SPEAKER: Okay. Thank you.

MR. BICKNELL: Organizations follow a very similar trend line to networks, which is no surprise, and an interesting one that I wonder if it tracks the ASN numbers at all is points of contact. We saw very large growth rates up to 25,000 records per year and then that dropped off and it drops off very similarly to the AS number. So I'm probably getting you all just about to sleep about now, but it gets better, trust me. One of the questions we often get asked is how much data comes from before ARIN existed. There's only two dates in the database. There's a registration date and there's an updated date. One of the cautions I got very early from talking to ARIN staff is updated does not mean customer contact. ARIN staff may update a record for any number of reasons, for instance, putting a note on it, we can't find these people and they haven't paid us in years, that means an update. There is a whole bunch of other things that could occur. You can ask staff if you really want to know, but since we only have two dates on the data, I thought it was important to include both and it's interesting to see the different numbers. 21 percent of the ASNs were allocated before that magical December 22nd, 1997 date, but only 5 percent of the networks, obviously no V6. So the next thing and sort of where we get more interesting is we're going to look for missing and incomplete data, which actually is a bit of a challenge. It's hard to find something that isn't there, but there are some obvious choices. We could look for records that don't contain all fields, that's the obvious one. We can also look for cases where fields should exist and don't for some reason. So this is going to be a hard slide to read. I welcome you to download the pdf after this if you really want to dig into the numbers. Remember that many of these fields are optional. A prime case is most of the records are missing comments. We don't expect every record to have a comment. I think many people in this room would hope that most records had an abuse contact. The reality is 98 percent of IPv4 networks do not, so, you know, I don't know what that means for the people who are interested in those things. A lot of people get paranoid about being able to contact someone, but we have very large numbers where there is no direct contact on that record. That doesn't mean you have no method to contact these people. What it means is you have to walk the database one way or another. You have to go from a resource to an organization to find an organization to contact. You have to go from a resource to its parent resource to find someone to contact. So I don't want to suggest that these are things that have been assigned that we can can't trace anymore, but they are things where your first query will not get you anything useful, you must do subsequent queries to find it. It's also just kind of humorous to me on the POC front, you know, I don't know how we arrived at the list of what we asked, but it's quite clear that no one ever puts their cell phone as a point of contact, which probably shouldn't surprise most people. I know I wouldn't. There are a couple of things that came up here, for instance, with networks you'll see down at the bottom a very small percentage were missing a net type field. We actually didn't close that loop with staff. It turns out that those records represent ones that were transferred to AFRINIC. If you queried them in the online WHOIS tool, they showed up correctly. If you queried -- if you downloaded the bulk dump, that field simply showed up as blank, and that was just an error in how things were done. However, I use that to bring up an interesting point, and this is back to kicking the hornets nest a little bit. One of our strong tenens is research and the ability to look at this stuff and it surprises with me given how long ago that happened that it hasn't been caught before. I wonder if that is an example of very few people downloading bulk WHOIS and actually analyzing the data. This is all well and good, but it includes all of the SWIP entries including simple reassignments which I'll point out, simple reassignments should be missing some of these fields. There's a reason why some of these numbers are so high. So everyone always immediately asks, well, does ARIN do a better job, because I think we all really hope so, right? So what I did is pulled the data for networks and v6 networks where it's only an assigned or allocated block, so this is data that ARIN should have entered, and the results are actually really good. There's a few v4 networks that are missing registration dates, again due to being assigned before ARIN came on the scene. The ones that are missing contacts, by and large are missing them legitimately. You don't have to have all the contacts for certain resources. For some of them you don't need any, you can simply point at an org ID rather than having a contact on the resource itself, and sort of one of the important things here, you know, net type, parents, those sorts of things are missing. There ARIN seems to be doing a really good job of keeping their own data up to date. What about RWHOIS? If you scan through the database, you will find that there are 377 organization records that list an RWHOIS server, but when you actually go through those, only 346 actual different RWHOIS servers, several organizations share one and that shouldn't be a surprise. I didn't try to pull down any data from RWHOIS servers. I figured the two people that ran them wouldn't like me doing bulk dumps off of them, plus due to the way RWHOIS queries work, you may actually have to do a fair amount of work to figure out what to query in the first place. However, I did test them for simple accessibility. All I did is connect to the RWHOIS server and send an RWHOIS command, in particular if you know RWHOIS the hold connect on command, very simple thing that most RWHOIS servers implement. Only 59 percent of the RWHOIS servers actually accepted my connection. So there had been a lot of talk in the past about should RWHOIS servers always be up, should the public be able to query them or just ARIN. There is some test data. I believe ARIN does test them internally, so they have some data on that as well. If you care, I tested this on August 1st of this year, if you're looking for a particular date. The next section is on stale data and this one is one of the first areas that when I collected some feedback from AC members and other people that the community was interested, it also turns out this is one of the hardest things to actually figure out. But we have several clues about stale data. The first one I think maybe people will find humorous. There are still a number of EECP and bitot email in the database. I suspect that most of those can't be mailed. There may actually be some that work I suppose somewhere, but I suspect not. I have included some updated dates just because I find it interesting. I gave some a little bit of leeway after ARIN was created and said have any of these been updated, and again that may not be due to customer contact, but several of them have, in fact, been updated. I suspect if we had a better way to validate e-mail addresses, that this is but the tip of the iceberg and many of them not working for all the usual reasons we all run into, right; people changing e-mail providers, things happen, whatever. One of the tests I really wanted to run but was unable to run, and this is where I would encourage anyone in this room who has access to such a service, you can go to the postal service and put in a street address, city, state, zip and it will tell you if it's valid or not and actually turn it into their crononical format of what it really should be. With, you know, over a million records, I couldn't find any service where for free I could easily put this in. Scott is offering to help here. Certainly people do this all day. Many of your businesses do this on a regular basis. It would be very interesting to see -- you'll see later in the presentation we do have some evidence that some of these addresses are, in fact, stale and out of date as well. This number, from talking to ARIN staff yesterday, didn't quite turn out to be what I thought it would be. There are 7,725 POC records in the database that appear to be unreferenced if you look at a bulk WHOIS dump, and ARIN does purge records that don't go with any particular record, a POC record that is. It turns out that one of the causes of this number is that POC entries are shared between the WHOIS database and the IRR -- or sorry -- yeah, IRR database, the route registry. So it is possible that a significant number of these POC contacts are actual blocks for route registry objects, and thus when you view it simply from a bulk WHOIS dump view, you don't have those in that data so you see them as orphaned. It turns out this is not an accurate count of orphan data, but there is probably a few. Here's where we start to get into the really juicy stuff. The first section here is on residential customer privacy. Obviously it's been a controversial topic for a long time, but we did pass 2003-3 allowing ISPs to submit private residence for the street address. And so what I did is look through the streets for things that matched that pattern, and the first thing you have to be aware of is it's not just that pattern, particularly when you're dealing with a strict match on a database. A PBT is often used instead of private. Some people say private customer, not private residence, so it actually turned into a rather long regular expression attempting to match this, and I suspect that I did not impact yet all of them, but I think I probably got 99 percent of them in the end. So the policy went into effect in 2004 and what the graph on the right is showing you is the percentage of new records with private in the name, and you'll notice there were some records before the policy was put in place that had private in the name, and I did look at some of these by hand and it seems that some people just kind of slipped in a record that said private residence or something similar before the policy was there, so that's an interesting data point. But you can see that this policy seems to have gone over like gangbusters in the community. Roughly 50 percent of new records at this point are marked as private residence, so people are making very heavy use of that. You can look at that same data a slightly different way. You can look at the total number of records in the database that are marked private and that, of course, is ever increasing because 50 percent of the new records are private and we're up at 186,000 records are private, and I see that Marty has jumped up.

MR. HANNIGAN: Just for clarification, Leo.

MR. BICKNELL: Sure.

MR. HANNIGAN: I'm Martin Hannigan. When you say people have started using this like gangbusters, you mean host masters, yes?

MR. BICKNELL: Probably primarily.

MR. HANNIGAN: I just want to be clear that this isn't generally an individual choice that the end user -- I want to make sure everybody is clear and that they understand what you're presenting. This is a choice by the person who's responsible for the IP address block at the ISP versus the individual customer.

MR. BICKNELL: In general. There are several ISP that have what I consider overly streamlined policies that allow customers to enter data in a web form and get auto provision and there is not necessarily a manual check, so there are -- I have documented cases of end users entering this, but yes, certainly most of them would be ISPs entering private residence.

MR. HANNIGAN: Corporate policy.

MR. BICKNELL: Yes. One of the observations of this is as a researcher now, I guess, it would be amazingly handy if instead of putting private residence in 300 different variations in the record, we could have a flag that said this is a residential privacy private record so we had a, you know, attribute matching the database. That would be greatly appreciated. What about outside the policy? We didn't have this for years and people wanted it, and many ISPs, it has been rumored, have simply put down their own address for substantially all of the records they listed, so they would give, you know, Joe Random a DSL connection and simply list One Corporate Center, blah, blah, blah on the SWIP entry. It's very actually easy to find this behavior, because all you have to look for is street addresses that are repeated over and over and over again, so I did just that. Here's what we find. It turns out 268 Bush Street, which happens to be in San Francisco, is listed on 104,000 records. I highly doubt there's that many DSL connections in that one building, and the list kind of goes down from there. You're probably wondering why I highlighted four of these in red. The reason I did that is when I first pulled this data, I stuck all of the addresses in Google trying to ascertain, you know, if they really were who they said they were and that kind of stuff. The four that are in red appeared to me to be -- and I cannot verify this 100 percent -- multi-tenant buildings, and in particular the very first address is the one that made me see this. The 268 Bush address actually appears in four different variations in the database, one that has street, one that has street with period after it, one that has street with period and suite 500 and one that has street without a period suite 500. So that was the very first clue of, hey, wait a minute, there should be a suite number here. So it appears to me that all four of those, in fact, are multi-tenant buildings and should have suite numbers, however most of the records do not. But probably what you're all wondering is you don't know where any of these are, particularly since I didn't give you city, state and zip codes on them, but you probably care who is putting these in the database. Well, fear not, I have that for you. You will notice a pattern. We'll come back to that in a minute. Out of this list I did some more digging. The only one to me that does not seem like the behavior I have just described is Allstate. I was unable to contact anyone and verify this, but it really looks to me, looking through the database, that Allstate as a corporate entity supplies connections to their individual local, you know, insurance reseller and marks them all as contactable through their corporate address, which arguably could be correct. So that, to me, does not look like the general behavior I just described of, you know, sort of DSL connections being marked with the ISP. All the rest do seem to be ISPs and seem to largely follow that pattern. So what are our totals here. If you remember from my first slide, there's 1.2 million organizations. There are 294,000 records that I could identify as residential privacy records. There are 232,000 records that appear to be listed with the ISP's address using only the top 10 streets. We drop down to around 2,000 records per street at that point, so I kind of set that as a cut-off, so that means that 41 percent of all the org records in the database are anonymous in some form or another. The more interesting one, as you all saw, is SBC. There are 284,000 records of those that appear to be parented by SBC net blocks, which makes SBC responsible for 97 percent of the 2003-3 compliant records. So basically we have one ISP using this policy. Why isn't anyone else using it? That's a question I would like the community to answer. One theory that has been put forth is many people, particularly if they aren't here in this room right now, don't know they can, but I would certainly like to hear from the community why people aren't using it. What else can we tell? Even though the street address is missing, we can look at city, state and zip for all the residential privacy records and, in fact, the zip code has generated an awful lot of discussion on the mailing list, so in the next section what we're actually going to do is look at postal codes and try and figure out what can we tell from postal codes that are in the database on residential privacy records and in general. So the first place we can look at is let's just look at the facts. We often talks about US and Canadian zip codes. It turns out there are actually 195 different countries represented in the ARIN database. I will say that most of them don't have many records. The US has 94 percent. Canada almost 5, Great Britain, Mexico, Argentina, Australia and Venezuela round out the list there as top areas. If you want really specific location information, zip plus four often gets you to a single delivery address. Four percent of the records in the database have that. A global statistic, if you pulled down from the postal service, there are 29,470 valid zip codes in the postal service delivery area, and I'll be the first to point out some of those are not zip codes where anyone lives. There are virtual zip codes for a number of reasons for specialized delivery, rebate centers, those sorts of things that we would never expect all of them, but there are only 24,829 zip codes actually in the ARIN database, which I think means there are a reasonable number of zip codes that have no entries at all. So what are the top 10 zip codes? There they are, and how many records are registered to each one. Evidently Allen, Texas is a center of internet activity, because they have a lot of records in the database, and we all laugh and we say that facetiously, but it turns out that's actually true. It is the home of one of the largest providers. So you can see here the breakdown again and again you will see SBC does kind of top this list, but obviously certain zip codes definitely win the record game. So we have to address this, and I did talk with Dave from SBC before this. Why does SBC keep showing up? Well, the most interesting question to me is why didn't anyone else show up. There are lots of other ISPs that sell lots of DLS connections, lots of cable modems, but SBC is the only one you see in the database. It actually appears to me that SBC generally is being a good citizen and doing what the researchers would like and SWIPing everything, and many of other ISPs for one reason or another are not, and that's not to say they're doing anything wrong. If you sell cable modem service and you give the people one dynamic name, you can SWIP /22 to a city and say that's cable modem people, so you don't need more specific records. SBC is actually putting in much more specific records than virtually any other ISP. So a little summary. Went over some of the trends, missing data, data inconsistency and integrity issues, the effects of residential privacy and postal code analysis. What I'm hoping is right now there's an awful lot of you who are good at doing analysis on all sorts of things, is I have left you with far more questions in your mind than I have actually answered, because I really would like to see more people looking at this and, you know, I do think that the research element of ARIN providing WHOIS data and all the RIRs for that matter is very important. If we're going to make policy, we need to really understand what's there and what the effect will be. So hopefully you will all look at that. However, there is one more thing. Over the course of this project, I went through a lot of records. Believe me, it was very boring to debug some of these scripts, but I was looking through the residential privacy records, you know, things that actually have private address in the street name and one of the things that struck me at first is I saw a reasonable number of records that quite clearly were not actual residences. The first actually basically what I did is selected them from the database and kind of space barred through about 20 screens and then started reading to get something at random, and the first page I got turned out to all be Fresno State University stuff. Well, I can find Fresno State University, that's not hard, and right after that was a whole series of records from like the California Department of Transportation or something like that, and again, you know, I can probably find them. So what I did is I actually stopped at the very first record I found that wasn't one of those, and it turns out to be this particular record net 70.247.246.128. Please don't all ping it right now, it's someone who is actually using the internet; all the data you need is up here. So I said, well, that's interesting, because I don't have a street address, and in fact when you look through this, the Plano, Texas 75075 is one of the popular zip codes. Turns out to be an SBC, you know, lock box mail stop, so the only thing I have to identify this person is Victor B. Williams, M.D. and his IP address. So what did I do? I did what any enterprising person would do. I put it in Google and said I'm feeling lucky, and it turns out I was lucky. It returned me a map, a phone number, everything I needed to know to find this person, and the very interesting thing to me is not only did I'm feeling lucky work, but when I went to verify, sure enough the DSL connection in Google locked just like the answer returned, and when you go look at the full list of Google answers, it's the only result when I did this query that returned to that name. There is no second record to go look through, and you're probably saying, well, you got really lucky, right? I actually tried this for about 20 more records and most of them returned one entry to some white pages service, several returned two or three entries, none returned pages and pages of entries even without a street address, city, state and zip, it was trivial to find the actual phone numbers, addresses, et cetera of holders and it's all because, if you look at the record again, they have actually put the customer's name in the customer name field. So I think anyone who is doing research on residential privacy probably really wants to look into that and see what the implications of that may be. So hopefully now I have now riled you all up, so we can have some questions and/or some discussion which I'm sure Ray will want to keep short.

MR. PLZAK: Okay. Fine. I'll start with -- who are you today?

MS. ARONSON: Cathy Aronson at ARIN AC. If you're a provider like a cable provider and you're just giving somebody a single IP address, you don't have the SWIP, though.

MR. BICKNELL: Correct.

MS. ARONSON: SBC sells a lot of connections to businesses and stuff where they give them subnets, so it could be that there's a lot of providers that don't need to do it because they don't have to SWIP them.

MR. BICKNELL: That's true. I'm not suggesting that anyone is violating a rule by not SWIPping them, I'm merely pointing out that the way the rules have been written, SBC feels they need to SWIP everything and pretty much no one else does.

MS. ARONSON: Well, I used to work for one of those providers and we SWIPped all the people we gave subnets to, but we never -- you know, we had a gazillion people with one address.

MR. BICKNELL: Right.

MS. ARONSON: And if you remember back when the policy was written, I believe that particular ISP was instrumental in the policy happening and now they're using it, which is consistent.

MR. BICKNELL: Absolutely. Like I said, nothing is wrong here. I merely point it out because I have seen more than a few people stand up at the mic, as several of you are, which is good, and say, for instance, it is absolutely critical that I be able to deliver a subpoena directly to the end resource holder. Well, it appears SBC is giving you that ability and no one else. So all I'm merely trying to do is forward that discussion of is that actually critical or not.

MR. PLZAK: Okay. Marty?

MR. HANNIGAN: Marty Hannigan, Renaissance Corporation. Leo, that was great. The SBC records, I mean typically the policy -- I'm not a SWIPper, so I'm not sure, so I'm asking you. They could put private residence there and actually itemize the record, right?

MR. BICKNELL: Yes, they could.

MR. HANNIGAN: So that's another example of corporate policy sounds like.

MR. BICKNELL: I actually talked with Dave from SBC and I see he's up at the mic, and so I'll let him address their corporate policy. He seems willing to talk about it.

MR. HANNIGAN: One more question. It looks like you got the NSI data in there pre-RIR, so I will assume that you assumed -- well, I won't assume actually. Did you assume that a lot of the anomalies that you saw were pre-RIR, and I guess I would kind of ask Mark and Randy and the guys to kind of think about that maybe or see what your response is and see or ask you, you know, you suggested some of us go off and do research, and I can tell you that I'm going to take this back and do some research, and am I going to -- how much -- what difference will I see if I strip out all of the pre-ARIN existence data and --

MR. BICKNELL: So here's your answer to a degree. With v6, no surprise, none.

MR. HANNIGAN: Yeah. V4 is what I'm talking about.

MR. BICKNELL: With V4 that's the green networks element. If you go by registration date, five percent of it pre-dates ARIN. If you go by updated date, three percent does, so at most it would give you results of three to five percent.

MR. HANNIGAN: Thank you.

MR. PLZAK: Sam.

MR. WEILER: Sam Weiler, Sparta. First, thank you, Leo. I really appreciate this. I wanted to throw some more particular examples into the fray to help the discussion along. Using the same Plano, Texas address that seems so popular at 75075, we have such organizational names as Wells Fargo Bank, private address, or Wilbur Surgery Center, Inc., private address. Another one that struck me as interesting, which doesn't have Plano, Texas, Banana Boat of California, Inc., private residence, customer's city, customer's zip code, so there are people filling out bogus data in these fields if they're filling them in at all. There are several records that do have the name.

MR. BICKNELL: Having been through a lot of the records, I would say that's pretty common, and I have my own question as to whether or not making a business marked as private residence is an acceptable thing or not. The kind of thing I keep coming back to is we're getting data here, and for no other ISPs are we getting it, so I'm not saying that something is better than nothing necessarily, but you have to consider that.

MR. PLZAK: I'll go with Randy, then Dave.

MR. BUSH: Randy Bush, IIJ. I'm coming in from the cert angle. My personal need for certified allocations is for purposes of routing, and we know there are currently about 180,000 prefixes in the database -- the active routing table. Though I applaud SBC for Swipping 600,000 and the thing is how do I know which allocations should be given certs and which not? In other words, so ARIN allocates, you know, a /2 to SBC and SBC makes 600,000 suballocations. Of those 128 are, you know, /5 and those are the ones that need routing certification, and the other 599,000 whatever don't need routing certification, so I don't particularly want certs for them. Somebody else may, so I have two questions which is how do I know of those which really need certification and which don't, and secondly, do people here have need for certification for the other 599,872? You see I can still subtract.

MR. BICKNELL: I'm going to channel Geoff Huston, and if I get it wrong, he'll probably jump and correct me. I believe in the model he just proposed you would not decide. The people who got the resources would decide if they need to assign a route announcement or not, so that's who would make that decision.

MR. BUSH: Sorry, I'm speaking -- I'm not saying I decide. How is it decided? How is anybody supposed to decide which gets certified and which not? As I said, I am personally interested in only the ones for routing announcements. Others may have other needs for certification and finding regularity. I'm asking to hear from any of those and then to know within a policy, social or technical structure where we're going to put the detense on the knob.

MR. PLZAK: Thanks, Randy. Dave, you'll be the last guy.

MR. BARGER: I'll try and keep this brief, and before I go further, I'm Dave Barger with SBC. Anybody who wants to talk during the break, I'll be around if you have any specific questions, but I want to touch on maybe two or three of the things that were just said. First of all, a comment was made about, you know, our corporate policy and our practice of applying the term private residence or SBC internet private customer to the customer name. Yes, that is a corporate policy, that is my team's policy and -- but the thing I want to point out is that policy is driven by customer demand, and I mean, our customers are first and foremost in our business. You know, we're approaching 9 million DSL customers right now, largest DSL provider in the country, and that is what has driven a lot of this policy work. Some of you might recall that I had made the original policy proposal back in 2002 which brought on 2003-3, the residential customer policy. That was driven by our customers and I mean a lot of angry customers, you know, seeing personal address information in the WHOIS database. The other thing I want to point out is I think this whole discussion, I'm glad Leo brought this up, because I think a lot of these numbers just sort of needed to be gotten out on the table, but I think one thing that it does point out is that obviously times have changed over the last number of years. WHOIS has not, and the intent of WHOIS, you know, well and good maybe back in the late '90s and the data that's gathered, maybe we need to take a whole new, round up fresh look at what WHOIS is all about. Maybe we need to scrap it and start over or maybe we just come up with a different way to use it, but I think that's kind of what we're all talking about here is we're trying to find different ways to put these bandaid approaches on, you know, how do we protect our customers, how do we protect our companies and all that kind of thing and, you know, maybe we just need a whole new fresh look. A couple of other quick comments. A comment was made about a couple of obvious business-type SWIPs like ACME Rocket Company, but it says private residence, okay. Clearly, to me, I would think that SWIP entry should have a valid corporate street address for that end user, for that business. The only thing I want to point out is the way our tools work, the way our processes work, we have a database with a lot of automation behind it that does all of our IP subnet assignments. We have probably 500 plus people at any given day working in different provisioning and work order management teams turning up customers and all this kind of thing. They all use the same tool, they use the same SWIP interface in this tool and there is a box that says click here to mark this as private residence. Now, clearly their own internal policies say you're not supposed to do this, you know, if this is a business customer, but then again it's driven by humans, you know, it's their mistake. So those are the kinds of things when we have time and I have enough resources in my team, you know, we go through and try to go through that data and fix those things, but we don't catch them all, so there are certainly going to be that amount of erroneous or what I would consider erroneous type entries out there. Finally, just one of the examples Leo had up there of all of the various street addresses, the ones that were in red on the slide, some of those, again, have evolved over the years. Our internal corporate policy for quite some time said that we cannot list our physical building addresses in public databases and, you know, I always thought that was frankly kind of stupid because of the kind of searches that Leo did, everybody knows who SBC was or Pacific Bell was and, you know, it doesn't take a whole lot of work to go dig out a real street address, but the fact of the matter was corporate policy said and legal said you can't do this, so we had to go with these lock box type things, totally ridiculous, and now they've come full circle and said, yeah, let's use our street addresses. So we're in the process of going through and fixing data now, getting rid of all this old street address information, lock box information and you're going to start seeing a lot of stuff that says 208 South Afrey Street, Dallas, Texas, 22nd floor because that's where our offices are, so, you know, trying to stay in compliance with what everybody wants to see in WHOIS and trying at the same time stay in compliance with our own corporation saying that we can do, you know, there's always that fine line.

MR. PLZAK: I did close the mic, but Bill obviously has a burning desire so I'll let you have the absolute last word.

MR. DARTE: Sorry. Really quick thing. ACME Rocket Company may well be a DBA or a sole proprietorship, in which case it's an actual person rather than a corporate person and there's no incompatibility.

MR. PLZAK: Leo, thank you. Very good work, and so thanks much. This, as you know, has been very much so of an ongoing debate for about the four or five years and it's going to keep on going, and so yes, there's a real problem here and it does really have to be addressed and we'll have to come to grips with it. So we are now at the point of the afternoon break, and so let's be back here at 4:15. (Recess)

Harmonization of RIR Practices

MR. PLZAK: Let's get started. We've got one more presentation and then we have one more policy to discuss and then we have an open mic yet for the afternoon. This morning during the NRO activities report Raul made a mention about harmonization amongst the RIRs, and so Leslie is going to give you a short presentation about some discussions that have been going on and some considerations and so forth about harmonization of RIR practices, so Leslie.

MS. NOBILE: Good afternoon everyone. I have a short presentation. As Ray said, this is being discussed in all of the regions at this point. We just wanted to talk about it here at ARIN to sort of raise the question, start you thinking about this issue, if it is an issue, so should the RIRs harmonize their allocation periods. Well, we need to first define an allocation period, and I can tell you this was difficult to do. I'm going to let you read it, because I probably have 15 iterations of this definition up here already. I mean it's basically the length of time that the RIR allocates space for a requesting organization to sustain its needs for that entire period of time. That is always defined by policy. So just a few background facts to think about before we really ask this question and talk about some of the various allocation periods in the regions, just some things to think about, keep in mind. So the most general basic RIR principle is the fair and responsible distribution of internet resources, right, fair and responsible being key words. Policies are defined in every region by a community, but in general policies are very similar across regions, but they are based on the specific needs of a region. Right now there is a current disparity in allocation periods across the regions, and I will tell you what they are in a couple of later slides. So in general the allocation periods, in ARIN it's three months for newcomers and initial requests and relatively new people to the ARIN region, or six months. In LACNIC it's three months for initial requests, the allocation period is three months, and then one year for any subsequent request. In APNIC it's one year. In AFRINIC it's two years, and in RIPE NCC it's two years. So this means that those registries will look at the requesting organization's allocation needs for two years out. So more specifically for ISPs, in the ARIN region, as I said, three months initially or six months if the subscriber has been a member of ARIN, subscriber member of ARIN for more than one year. Now, ARIN does issue allocations from a one-year reserve for aggregation purposes, so there's -- every time we make a /20 allocation to an ISP, we will take it out of a /19, for example. Now, in LACNIC, as I said, it's three months for initial allocations and one year for any subsequent requests. This is a brand new policy implemented probably within the last 30 days. In APNIC the allocation period is one year, has been for quite some time. In AFRINIC it's two years. That's the general allocation period for ISPs, however, they will allocate for shorter periods with their less experienced LIRs. In RIPE it's the same case, they do allocate for two years in general to their experienced LIRs, shorter periods for the less experienced LIRs, the newcomers. They define what that shorter period is based on their experience. Now, for end users or PI assignments, in ARIN we will issue for one year. We have a one-year allocation period for end users. LACNIC is one year, APNIC one year and AFRINIC one year. In the RIPE NCC it's an indefinite period of time. There is no allocation period specified and no policy. So some of the current discussions in the other regions. As I said, LACNIC has a brand new policy implemented. They have extended their allocation period to one year from subsequent allocations. Before this they were issuing space to their ISPs, requesting ISPs for three months. That was the maximum number. In RIPE NCC there was a policy proposal discussed last week to change their allocation period from two years to one year. And in the AFRINIC region there will be a discussion/proposal, I'm not sure which one it is yet, and that is going to be presented at the next meeting in December in Moreschi at the AFRINIC meeting, so it is being discussed across the board. So here are two slides. These are kind of the food for thought slides. Fact or fiction, don't know, don't know if there's enough supporting evidence either way, but I'm just going to throw these out there. So longer allocation periods create an unfair advantage. Well, if your look at things like administrative burden, is there less of an administrative burden on someone who gets an allocation for two years than for someone who gets an allocation for three months? Like, for example, you can make fewer requests to an RIR. That's a big administrative burden to come to the RIR and show your utilization and justification every three months or every six months. There is an ease of address assignments. If you get a large allocation up front, it's pretty easy to divide that up. It's a bit easier than it is when you're getting smaller allocations. And do allocation periods affect the ability to do long-term network deployment planning? I don't know; seems logical that it could. Now, Lynn St. Amour was talking this morning about was this an internet governance, et cetera, and she pointed to the fact that there's a lot of people outside our organization and other governments who are very interested in what we do and how we do it and there could be a global perception of unfairness across regions due to policy differences. So the final fact or fiction, longer allocation periods contribute to the increased consumption rate and rapid depletion of IPv4 address space. I'm not sure if that's true. There is some supporting evidence perhaps. If you look at all the IPv4 space issued in 2005, RIPE NCC issued roughly 35 percent of all the space, APNIC issued about 30 percent of the space, and ARIN issued about 25 percent. I only listed the three larger RIRs. And remember, RIPE allocates for two years, APNIC for one year, ARIN for three months or six months. Now, some research, and one of those researchers is in this audience, indicates that there is roughly four years of IPv4 address space left, so question to consider. And I don't have any other slides, so it's really just open for discussion and I'll turn it over to John. Thank you.

MR. CURRAN: Microphones are open on the discussion of harmonizing allocation periods. Yes. Center back.

MS. SKANKS: Heather Skanks, Verizon Business. Thank you, Leslie. We've been talking to Leslie about this over the last couple of days. Most of her presentation was geared toward IPv4, but I wanted to say how important it is to think about this for IPv6. In IPv4 the previous assignment size -- and assignment size has a lot to do with how long the assignment will last as well, so previously a long time ago the assignment size -- the maximum assignment size that ARIN could give was a /14, and large ISPs were going through them very quickly, so they were basically stacking 14's on top of each other and you couldn't get a lot of aggregation because you could only request enough aggre space that would last you 16 months, 18 months, and you couldn't request a large enough block that would even last you that long. So the question to consider in IPv6, and part of what I also want to say is that the information that Leslie gave about the amount of time that the address space is supposed to last you was only for IPv4. There's no guidance in the PPML -- in the NRPM that says how long V6 space should last you, so there needs to be some guidelines not only for the registrars giving address space to ISPs, but for ISPs in giving address space to their customers.

MR. CURRAN: Okay. Microphones are open. Central microphone.

MR. DUL: Andrew Dul. Heather, there is a two-year window for subsequent allocations, correct? So are you worried about initial or subsequent? So you're saying the /32s are not --

MS. SKANKS: The reason I'm worried about initial allocations is because your initial allocation is dependent on your engineering and design plan, so if you come up with a plan that will enforce strict aggregation, if you can only get a small block or something that is not going to last you a significant period of time, say the size block you get isn't going to last you for two years, you're going to have to -- if you have to come back in six months to get an additional block, you're creating more fragmentation, and even in the way of pre-reserving some aggregation space around it, if you don't reserve enough aggre space -- even if you reserve aggre space, you're going to get fragmentation in your internal routing table as well.

MR. DUL: I understand what you're saying. My question is because of the initial allocation policy, are you not able to obtain a sufficient block size based upon your current customers to build out your infrastructure appropriately? Because you can get bigger than a /32. You just have to justify it based on your current --

MS. SKANKS: So it's been difficult, and that's exactly what we've been trying to work out with ARIN, so how much aggre space -- do we request enough aggre space just to cover the infrastructure that we have existing today and how far forward do we look to figure out how much aggre space that we'll need going forward, and the other problem -- part of issue is in looking at what assignments we give to our customers, because there's no -- the policy basically says small, medium and large, but there's no guideline as to how long that aggre space should be given to customers, so in Leo's presentation he was saying about the number of allocations being very high and that those folks had to continually come back. Well, if the guideline for assigning aggre space to your ISP customers say that you should give them enough space to last for six months and they have to come back to you every six months for additional aggre space, you're going to be giving them more allocations, so you want to -- there's no policy that kind of defines how to evaluate growing ISPs. The policy works currently.

MR. DUL: So if I hear what you're saying correctly, you're concerned about a large ISP allocating sufficient address space to another ISP, so you want to allocate them larger than a /48?

MR. CURRAN: Jason, do you want to respond?

MR. SCHILLER: Yeah, I want to try to say what Heather said in maybe a different way. I'm sorry, Jason Schiller, Verizon Business, EU Net. Basically the problem is if you get just enough space to cover the customers that you current have and you want to do aggregation, now I'm not talking about aggregation to the internet table, I'm talking about internal aggregation so that you can keep your internal routing table small so that as both your internal routing table grows and the internet routing table grows, you can try and scale the whole routing system. If you want to set up aggregation within your network, then you need to have extra space at each level of aggregation so that customers can grow into that space over time. If you're given just enough space to cover your existing customers, then you don't have a lot of space for customers to grow into those aggregations of those levels, so instead you have as what Heather described as a stacking of the blocks. If you've got a block that covers just what your customers have and you divide it up into some sort of regional aggregation plan and all of your customers fill all of that space, when you go to get new space, you stack a new block and again you have to divide it up across all of your internal regions. So the problem is you never get into a situation where you can do any sort of decent internal aggregation.

MR. CURRAN: Okay. I would like to limit responses to -- if people want to respond to that topic, and I want to get those done so we can get to other comments on allocation period. Does anyone else want to respond to Heather and Jason?

MR. SEASTROM: Rob Seastrom, ARIN AC. I have found myself in a similar situation, and unfortunately Jason does not have the luxury which I did which I decided I was not going to run my backbone. I was going to have two different networks and get it under the multiple discreet networks policy, so this is sort of a weird case for people who are sufficiently big that it would make sense to have something where there was the geographic or topological thing where for allocation purposes they could be multiple discreet networks geographically or topologically or however their document that went to ARIN and got sliced up appropriately and discussed imbedded between them and the analysts and then get multiple buckets of addresses to be able to dip out of.

MR. CURRAN: Do you want to also respond? No other comments on this topic after you.

MR. BICKNELL: Leo Bicknell, ARIN AC. I certainly think it would be good for there to be parity between ARIN's policy and the policy that it then requires internal to ISPs, because my biggest fear out of that is actually that we create a desire to come to ARIN when there shouldn't be. If I can get six months from my provider and I can get two years from ARIN and I actually am in that window where I have the choice, I'm going to come to ARIN and get two years probably because we've created an incentive. So whether it should be six months all the way around or two years all the way around, I just think there should be very close parity.

MR. CURRAN: Microphones are open for any other comments about making harmonization between allocation periods. Yes, Cathy.

MS. ARONSON: Cathy Aronson again. When we talk about harmonizing policies, I mean, for those of you who get address space from ARIN, you're really lucky, but there are other differences in the policies that on the surface, you know, it looks like the policies are really similar, but there are these little things under the seam like assignment windows and a lot of other things that are really significantly different from region to region and really affect how people get address space and how they put it in their networks and I think if we're really trying to have a global policy, we have to figure out some way to straighten that out as well because for those of who you aren't familiar, there's a lot of differences, not just -- on the surface it's like, oh, you can get a /20 from any of them or whatever, but they're real very, very different.

MR. CURRAN: Okay. Good point. Microphones. Mark Kosters.

MR. KOSTERS: This question kind of scares me and because we only have 55 /8 available and what happens as things become more scarce. Do we start having an arms race between the RIRs to get that original -- get that space. So I think that we need to work on harmonizing these policies so that arms race does not occur.

MR. CURRAN: Okay. Good comment. Center front.

MR. SAWYER: Leif Sawyer, GCI. As an ISP it's easier for my customers if my policies are in harmony with my next upstream provider, which in this case happens to be ARIN, and I think if the other RIRs mirrored that, if they all came in harmony, it would make things easier as we went out further downstream.

MR. CURRAN: Okay. Rob.

MR. SEASTROM: Rob Seastrom again. I'm about to suggest just the opposite, making things less harmonious, so -- because there's no pleasing everyone. We already have a policy where the amount of addresses given varies based on how much time you've been with ARIN, like the initial allocation is only good for a few months. Would it make sense to have the reserved block from which your allocation comes grow to encompass a larger amount of time going forward based on your past history with ARIN, meaning that an organization that has been a customer for six years and shown a pattern of requiring more space every three months, six months, whatever, would have that space then allocated out of a reserved larger block for aggregation to have an event horizon that was maybe two, three, four years in the future in the interest of greater aggregatability.

MR. CURRAN: So you're proposing this alternative as a way of handling greater aggregatability, you're not posing it as an alternative for fairness between RIRs?

MR. SEASTROM: That's correct.

MR. CURRAN: Okay.

MR. SEASTROM: Yeah, and as everything else, we have to look at the results of our actions on the global routing table, even though we don't guarantee routability.

MR. CURRAN: Understood. Microphones are open for final comments on harmonizing the allocation period. Last speakers come to the microphones. I am closing the microphones. Yes, Leo.

MR. BICKNELL: Leo Bicknell. I think RS has a very good concept. My worry is that I know of at least three examples where someone had a very long history with ARIN being a very responsible net citizen and then changed hands, got a block here months after they changed hands, had an entirely different business plan and fell apart rather quickly. So I don't necessarily mind that being one of the criteria, but it need not be the only criteria for evaluating someone's goodness.

MR. CURRAN: Understood. Thank you everyone and thank you, Leslie.

2006-1: Residential Customer Privacy

MR. PLZAK: Now we will move on to a discussion of Policy Proposal 2006-1, Residential Customer Privacy. This policy, in essence, suppresses certain items of information regarding customers of organizations that receive allocations from ARIN. The AC shepherds are Marla Azinger and Paul Anderson. A brief history. Introduced on the PPML in January of this year and later that same month as designated by Paulo Pipolo by the Advisory Council. First public policy meeting discussion was at ARIN XVII in Montreal. Community consensus between the PPML and the meeting was that the proposal should be revised and it has not been revised, the author has chosen not to, and so the next public policy discussion of it is here at ARIN XVIII. The proposal text is in the meeting packet and at the URL shown on the screen. Legal assessment done March of 2006, the liability risk is none, however counsel makes a comment and I won't read it to you, it was posted on the list and it basically has to do with the fact that there may be a series of impacts in different portions of the internet community and he does cite a single example. Staff comments in October of 2006, suppression -- it was discussing suppression of display, what are the effects on the users of the current data and also there's some ambiguous use of the term private resident/customer. If you're suppressing the collection of information, then there are a number of factors that would lead to a diminished ability to verify utilization. If this policy was to be enacted, it would modify Sections 3.2, 4.2.3.7.6, and 6.5.5.1. In terms of an impact, moderate, probably about 90 days after the BoT ratification. It's going to require some software changes, guideline changes and some staff training. PPML discussion, 46 posts by 16 people over recent weeks, two for, three against. General tone of comments, publishing city, state postal code does not offer a reasonable level of privacy protection for those in small areas, and I'm for a good privacy policy. The one in place now is superior to this one. So as I said, that is available online and also is in the packet that you have with you. And so the author of the proposal is Sam Weiler, he's here and he's ready to present.

MR. WEILER: Thank you, Ray. This policy arose out of a difference of interpretation of 2003-3. In particular -- sorry about the lines. In particular, when we were talking about 2003-3 three and a half years ago, I thought that the phrase street address in here meant the residential customer's entire address. ARIN staff has interpreted that to mean the street name and number and that the city, state and zip code are still required on the assignment or published on their list. So the first question I asked is why am I confused. I think part of that is that the discussion three and a half years ago didn't really highlight that difference. The discussion talked about residential address information without going into detail exactly which fields were under discussion. I certainly thought we were talking about the whole address, I think that many others in the room did, probably not all. So this proposal attempts to bring the current policy in line with what I thought we were doing three and a half years ago by replacing the word street with entire and also changing some text that was introduced in 2003-5 which is the distributed information service requirements policy which does refer back to 2003-3, the city, state and zip. Whatever we decide to do from the perspective of residential privacy, we probably need to update the text at the bottom of the screen there because it's very U.S. centric mentioning state and zip code. In Montreal and on the list there were several things discussed. We heard some opposition of people wanting a more comprehensive policy, let's offer privacy on all reassignments. I don't -- I think for the most part there was not strong opposition to this policy on those grounds. I certainly see this policy as a good incremental step, it does no harm. The second item of discussion, which I think was the main point of contention in Montreal, was what's the impact on ARIN. Does ARIN need city, state and zip code for its operational purposes. I'll get to that in a moment. And the third part of the discussion was attempting to find some compromise having to do with publishing partial postal codes. I see a lot of difficulties with that and I think others have as well, namely that you still have some small areas, small zip codes with very few households, very few individuals. You have difficulties getting the 26 different countries or similar jurisdictions in ARIN's service area that may have their own different ideas of what a postal code is. And even when you're publishing a partial postal code, that's still an interestingly useful amount of information that may not give the user quite as much privacy as they want. So I think we made some progress since Montreal. In particular I think that through discussion we have resolved the question of what information ARIN could still get. In particular, we have resolved the question that this policy proposal does not restrict what ARIN could ask for under NDA. It would restrict what they can see in RWHOIS. It would restrict what they would get on a SWIP template, but it would not restrict what they could ask for. I did not change the text of the proposal to reflect this because I couldn't see any need for a change in the text. If someone thinks we need to do that, please speak up. As for the impact on ARIN, I think ARIN's evaluation of this has changed a bit in the past six months, but when I asked in particular what are you doing with this, why do you need it in hopes that we would be able to as a community make a decision as to whether ARIN's need for this outweighed residential users' needs, desires, rights for privacy, ARIN explicitly refused to say more about why they needed the data. I'll leave it at that. As for publishing partial postal codes, one thing I had hoped we would get were voices on the list saying I want this data, even having just a partial postal code is useful to me for research in this way, so then we as a community could again weigh the value of having that data or not. I haven't been hearing that. I've been hearing proposals for compromises, but I have not been hearing from people who actually want to use the data. And particularly what Leo just presented about how noisy that data is and the number of SWIP blocks that don't even have the real user's data in them now, I'm really wondering if this is useful to anybody. So here's the text of the proposal and I'll turn it back over to the chair.

MR. CURRAN: Okay. Microphones are open for questions or comments on this. Center rear microphone.

MR. HANNIGAN: Martin Hannigan. I oppose this policy and I opposed it during the Montreal session and I offered to work on a compromise with the author and I wasn't able to, and the reason why is because the author refuses to change the text. I was one of the people that proposed that instead of having full zip code and whatnot, that we reduce it so just basically the postal area code or reduced that for the United States and other areas. Quite frankly, we did offer to work with the author. We actually submitted some data directly to the author and our company spent cash, which is real money, and we put time and effort into trying to come to a compromise and I feel like we were taken on a date and thrown out of the car when I went in for a pack of cigarettes at the store. And just basically our concerns as a company, which I suspect that -- and I can't speak for the Ameren employees, but I don't know how they can answer for the list of people that use the WHOIS data for reasonable purposes, so maybe that's why the crickets are chirping, and I don't know that that characterization is accurate -- accurately reflecting the conversation on the list, because I can tell you that my concerns were never addressed and I hope that everyone else opposes this policy based on the lack of cooperation with the rest of us, and that my customers in this room agree with me and do the same thing. Thank you.

MR. CURRAN: Hold on, Marty. Sam, ample opportunity to respond.

MR. WEILER: I don't recall getting data from --

MR. HANNIGAN: Do you want me to pull up the e-mail?

MR. CURRAN: Let's try to keep this on the merits of the proposal.

MR. HANNIGAN: Okay. I'll rephrase this. Sam, can I have your permission to re-post your private e-mail?

MR. WEILER: No.

MR. HANNIGAN: That's all I have to stay.

MR. CURRAN: Other comments on the proposal 2006-1. Front center mic.

MR. BICKNELL: Leo Bicknell. I support this proposal. I believe that it will actually increase the integrity of the data is the WHOIS database, particularly given some of the analysis I just did. I have two comments. The first one is I would suggest that if this policy is approved, when ARIN staff implements it, they make it a check box on the form, this is private, so that all of the fields can have the exact same value for those of us doing research. I don't think that needs to be in the policy, it can be an implementation detail, but I strongly would like to have that. The second thing is I do think there is another area that could be addressed either by an additional policy or perhaps by a best practice depending on how rigorous you want it to be. I have actually have a question for staff, because I've never tried to do this, but when it comes to things like residential DSL and wanting to know the general location for a lot of the research roles, not all, it would be sufficient to know where the gear is that provides the service; that is, if you have a DSL concentrator, it sits somewhere and might serve 4,000 users. Saying that, you know, this /20 is DSL users in the east side of Boston, Massachusetts gives you some location data without identifying them. So my first question is is it possible today to enter a SWIP for say a /20 to a location with something like, you know, DSL customers in it and then to register pieces of that as additional SWIPS that say this /29 residential customer. Is that allowed by the software?

MR. CURRAN: That's a question to Leslie.

MR. BICKNELL: You can put in a SWIP of something that's already SWIPped? Okay. So that is allowed, so that could simply be a best practice today. We don't need a policy to have people start doing it, and I actually think a policy generally along those lines as a follow-up would be highly useful so that we can preserve some amount of the location information without having to individually identify every ISP's customers.

MR. CURRAN: Thank you. We have microphone over here, far right side.

MR. ALLMOND: I'm Gary Allmond, Department of Treasury and I support this proposal. Based on the WHOIS presentation earlier, current policy doesn't meet the privacy needs of customers for the end users. I'm also involved in law enforcement. Some of this information we need. We can still get it from the ISPs or from the upstream provider; may require a court order, we can still get it.

MR. CURRAN: Thank you. Comment from the head table here.

MR. MANNING: I would actually like to have some clarification on the last sentence -- no, the second to the last sentence in that first paragraph, "Each private downstream residential reassignment must have accurate upstream abuse and technical POC visible to the WHOIS record for that block." What is the expected enforcement mechanism to insure that that information is accurate and what happens if it's not?

MR. WEILER: That language is exactly what's in the existing policy.

MR. MANNING: I understand.

MR. CURRAN: Bill, I would like to keep it on the policy change, and since that's not changing, I'm going to take that and hold it for a subsequent --

MR. MANNING: Sorry. I'll save it.

MR. CURRAN: Microphone center front.

MS. AZINGER: Marla Azinger, Frontier Communications. I oppose this policy for a number of reasons. One, Leo, your comment about you think it might make the database cleaner, I don't agree with that at all and I'm kind of aching to say if we just got rid of all the information, the database would be cleaner, so sorry, I don't agree with that one. Secondly, I think this policy is going about it the wrong way. It's a very -- I see the point that you're getting. I just think this is like taking a gigantic mallet to try and kill a tiny little ant and I think it would probably be best if it was a different proposal that just created a special case scenario and they could apply to ARIN for that and do it that way if they really want to be small, the one-person living in the one zip code town, make a policy to let them be hiding that information. That's just another route, different suggestion. That one was put forward as well in the past. I don't agree with the fact that none of the suggestion were worked with either, so overall I do not support this proposal.

MR. CURRAN: Would you like to respond?

MR. WEILER: I would, as much to Marty as to Marla. I saw the partial zip code proposals and most of those were very specific US and Canada, three digit or five digit and I think someone proposed a one digit on the list. As still having a significant impact on the individual user privacy, I was not willing to incorporate those changes. They weakened this proposal too much, so again, I think I see an impasse there in the partial postal code.

MS. AZINGER: Okay. What about the one about putting the next larger city zip code in place of that one? It's still geographically pretty close to where that person is at, but it's a different zip code that doesn't pinpoint them.

MR. WEILER: Again, that does reduce user privacy. I would consider it, except that I haven't seen language that would really do it and writing that seems a little bit complicated. I don't necessarily even see the benefit of it.

MR. CURRAN: Okay.

MR. WEILER: Of engaging in that complexity.

MR. CURRAN: But if there was such language, it might address your need? If there was language which was sufficient to do the job and not overly complex, you might be amenable to that?

MR. WEILER: I might be amenable to that.

MR. CURRAN: Thank you, Marla.

MS. WOOLF: Suzanne Woolf, ARIN Advisory Council, speaking for myself in support of this proposal. I would like to suggest putting the WHOIS database in some historical context. The idea that WHOIS data has always been fully and publicly available is largely a myth. For most of the lifetime of the internet access to this data was restricted by technological capability. Most people couldn't get to it, they didn't know it was there. In addition, I think we should be thinking about whether if this data didn't already exist and we didn't have a default that it was public, would any of the reasons people have given for leaving things as they are be good enough to justify creating it. If not, we might want to consider whether those reasons are good enough to justify continuing with the current defaults. I don't think they are.

MR. CURRAN: Okay.

MR. OPACKI: My name is Joseph Opacki and I work for the Federal Bureau of Investigation and I oppose this proposal. Since a large portion of the private information captured in WHOIS can be acquired from other venues, it's feared that this removal will only hinder legitimate use such as those by law enforcement. As the law enforcement community has repeatedly stated in the past, WHOIS is one of the many important tools that is used to find criminals on the internet. Investigations involving child pornography, spam, fishing, virus writing and counter-terrorism matters use WHOIS to achieve fast and effective results in finding criminals. The information in WHOIS is an invaluable community resource providing realtime results to law enforcement investigations where every second counts. It is feared that in instances where no information is available in a WHOIS record or a record lists the organization that represents a downstream customer, extra steps will have to be taken by law enforcement in which vital time is lost in securing crucial digital data. There will be additional costs and burdens to not only law enforcement, but the entire IT industry. Without an open WHOIS, resources that should be devoted to such areas as research and development may be diverted to the legal process. Moreover, an already burdened judicial system will be further bogged down. The comments surrounding the policy proposal only present views of WHOIS from the user perspective who use the internet for legitimate purposes. What about residential customers who use the internet for nefarious reasons, for example, our child pornographers, our virus writers, our fishers. Leo Bicknell stated in his presentation in Los Angeles last year that ARIN's database is migrating from a database of network contacts to a database of households projecting a growth of 105 million household users. As we all know, there are sophisticated internet users who use independent IP addresses that do use the internet for criminal activity. The unfortunate effect of this policy will be to provide another layer of anonymity for criminals further hindering the role of law enforcement.

MR. CURRAN: Thank you. Center front.

MR. DeLONG: Owen DeLong, C2 Company. I oppose this proposal. I think that the zip code comprise is a reasonable one. The places where it is not sufficiently anonymous are a corner case. One statistic I saw quoted on the list was 99 percent plus of the actual people in the database do not fall into the zip codes where it does not provide significant anonymity. Something like.1 percent was given as the number of people that would be negatively impacted by this, therefore I think that the existing policy is quite reasonable, and I remember during the debate -- I don't know why Sam has a different perspective, but I remember during the debate on the original policy that the language was changed from address to street address to address people wanting to preserve city, state and zip in the policy specifically. Thank you.

MR. CURRAN: Center rear.

MR. SEASTROM: Rob Seastrom, ARIN AC, and I don't work for the federal government, but I used to work for a company that starts with A and ends with I, and as a result of working there I discovered that there are a whole bunch of different ways that you can find out where an IP address is kind of down to the municipality sort of level, and those companies that are capable of finding that information out don't give that information away for free, they charge money for it, and I do pay taxes to the federal government and I do pay ARIN membership dues and I'm not interested in having my ARIN membership dues go to create a situation where my tax dollars need to be wasted in order to find out information that we're currently providing, and additionally this would be something that would disenfranchise researchers who are of limited budgets, so I oppose this proposal.

MR. CURRAN: Thank you. Comments from the head table.

MR. BRADNER: A couple of different things. I mentioned this before. I think we're entirely on the wrong path here. We've got two very distinctly separate concepts. One is what data ARIN gets about an assignment and the other is what data is in WHOIS. We are completely confusing those two and I think that that's a mistake. If ARIN believes that it needs this information, I would like to hear from Ray for its purpose -- its operational purposes, then I think it should get it, but it's an entirely different question than what should be displayed. I'm very sensitive to the comments from law enforcement. I think that could be met with the appropriate interface through ARIN if necessary, perhaps with court approval or something, but I think that simply saying that because we want privacy, which I very much believe in, that there is no reason at all for ARIN to get information that ARIN may believe that they need, I think that's the wrong path.

MR. BARGER: Dave Barger, SBC. Scott said it. I mean, this is another Bandaid approach to a much bigger problem, and we need to go back to what is it that ARIN really feels that they need and how do we provide that; do we change the templates we have now, what goes into WHOIS, what doesn't. If law enforcement needs it, fine, we'll send it to ARIN, but not publish it in WHOIS, but come up with another solution, come up with another mechanism for that. And, you know, about the whole law enforcement issue, I mean, again, we deal every day with inquiries from federal government, state agencies, subpoenas, whatever, you know, trying to track down whoever in full compliance, work with these organizations to provide customer information, whatever they need to track these people down. And yes, that does, I understand, add sort of an extra layer to the process, it may waste a little more time, but at the same time you have the other side. You have the customer privacy issue and then an individual's right to protect their own privacy which we really have to think about. So again, I understand the law enforcement issues, but there's got to be some middle ground here.

MR. CURRAN: Thank you. Scott directed a question to Ray, and the question was -- hi, Ray -- what information does ARIN need for its purposes irrespective of what is visible in WHOIS, what does it need for purposes of registration and validation purposes?

MR. PLZAK: I would actually like to have Leslie, the direct user of this to provide a few comments. I also would like to say that we did provide some more information in our recent posting and that at the end of the day, if necessarily, I will prepare a formal letter and we'll send that.

MR. CURRAN: Go ahead, Leslie.

MS. NOBILE: As Ray said, we did revise our staff assessment of this. We really thought about it, what do we really need when you're making a reassignment. We don't need a lot. That's not the time we need the information, so basically at reassignment time you pretty much can put anything in there. As you know, whoever, Leo's presentation, a lot of stuff gets in there that's, you know, junk. So it's not that we're really looking at it at reassignment time, but when you come in for resources, we want to know who your customers are. We are going to audit some of those, because we've had many unscrupulous people that will fill our database with junk, they'll tell us lies, so we have to go out and verify and vet and see if what you're telling us is actually utilization data. So we will at that time, allocation time, issuing resources, we will ask who are your customers, tell me who these 10 are and why did you give them this space and where are they located. So it's really then that we need this.

MR. CURRAN: Did you want to comment on that, Sam?

MR. WEILER: I think I have a follow-up question. So then what I'm hearing is you don't have a need for getting that information on an ongoing basis and certainly not for keeping it in the WHOIS?

MS. NOBILE: There's other policies that say we have to collect it, so you tell me. The community decided that you need to show reassignment information on a regular basis to get additional space.

MR. WEILER: But do you need the address information to do your jobs?

MR. CURRAN: By policy, no. By definition you're asking -- I think she explained for purposes of verification on additional resources requests, that information is used in that process. So Ray has offered to send something that describes that and we can probably proceed on that point. I am going to close the microphones soon. I see counsel. COUNSEL: I just wanted to amplify that we have two case that we're working on this week who are utilizing that data, one where we believe that the person who was trying to transfer resources has been convicted of a crime related to the use of the resources. We had had a grand jury subpoena, and we're using that utilization data, and then another one where we can't -- when we looked at the data, we can't verify it and it's causing us to believe that the original application was fraudulent, so there are instances where this set of data is used internally at ARIN to evaluate whether there's been fraudulent conduct in regard to the application for resources.

MR. CURRAN: Thank you. Center rear Mike.

MR. WOODCOCK: Bill Woodcock. I do not support this proposal for reasons that were already better articulated by Rob and Owen. I would like to specifically second Owen's objection to the re-raising of this issue which we have already been through at great length, by the mischaracterization of it as having been somehow a mistake or not the intended outcome of the group or something like that; that we went through this, we came to a conclusion, the conclusion was written in the policy and bringing this back up and saying that some mistake was made is a mischaracterization of fact. I would not have gotten up to the mic just to point that out again, though. The reason I got up was because of the suggestion that the next bigger city might be used as an identifier, and I am really, really strongly opposed to that because that is misinformation rather than lack of information and that is misinformation which demographically mischaracterizes the user base such that it would look as though all of the user base was in large cities which would look larger and larger over time. And, you know, I mean real tax money gets allocated based upon apparent utilization of services. I don't think that we want to be responsible for causing other people's money to be mischanneled away from them.

MS. AZINGER: Thank you for clarifying.

MR. CURRAN: Go ahead, Marla.

MS. AZINGER: I just wanted to thank you for clarifying that because I wasn't fully aware of what effects were, throw the geographical stuff off.

MR. CURRAN: We are going to close the mic shortly. Rear microphone.

MR. BUSH: Randy Bush, IIJ. Scott -- I'm opposed to this proposal. Scott said it very succinctly. The problem is that on the left had there's the issue of what ARIN needs and on the right hand there is the issue of what ARIN publishes. I would point out to those people who go to the internet vendor task force that there are protocols within the internet vendor task force that handle the case of submitting data and marking it private. I believe once upon a time when I put up with that silliness, it was called EPS, you might want to take a look at it, but I greatly resent raising the bogeyman of sex criminals, terrorists, et cetera to justify this. The sex criminals seem to be equally distributed in the U.S. Government and those that are asking for this. I would remind you of a quote from Jeff Schiller which said "Law enforcement is not supposed to be easy. Where it's easy, it's called a police state."

MR. WEILER: Randy, I think I'm confused. Did you say you support this proposal?

MR. BUSH: I oppose this proposal. I suggest that there is a reasonable proposal that could be written that differentiates between what ARIN collects and keeps that is needed to do what Leslie thinks and says, and I support Leslie's needs, they seem quite reasonable, and what ARIN publishes in WHOIS. Those can be two different things, all right, as Scott very clearly pointed out. I think that's what we need here. I'm getting the confused look from Sam.

MR. WEILER: I hear you saying that we could write something that clarifies what ARIN gets.

MR. BUSH: Versus what it publishes.

MR. WEILER: And this is only about what it publishes.

MR. BUSH: No. The downstream customers may substitute the organization's name. That says what I hand up to you, and Leslie says she needs that information and I support that, okay? I'm not making a clear differentiation.

MR. WEILER: I think so. And it's not enough to you that she might be able to request that under NDA.

MR. BUSH: And to point out what someone else said, if Leslie has collected it, but we do not publish it, then our culture does have something called court order which can get that information if it's really necessary.

MR. CURRAN: Thank you, Randy. Front center mic.

MR. BICKNELL: Leo Bicknell. I'm going to try to illuminate Randy. I actually disagree with his last point. I think an implementation detail of this could be the bullion field I want for other reasons on the form that says this is private. ARIN can still get an actual street address, city, state and zip and by tagging that field, the organization has substituted private residence with ARIN making that substitution as they publish it in WHOIS. They have made that substitution by flipping the flag. I wish it was written cleaner, but I personally do not feel those are incompatible and I think that would be a really good way to represent this. I will also state for those who wrote it, I agree -- or said it, I agree completely with Scott and I did propose separating the two data sets in a previous proposal. I even gave the two data sets really catchy acronyms, if I do say so myself, and no one seemed to like it.

MR. CURRAN: I am closing the microphones in seconds. Center rear mic.

MR. PETERSON: Yeah, Matt Peterson, first time ARIN meeting. It seems like a short term gap. I oppose this because it seems like a short-term solution to the IRIS kind of updated WHOIS mechanism coming down the pike if that does happen. From the stats and research perspective, Art mentioned the zip codes. There is also

MSA codes that are put out by the US Office of Management and Budget that's used for statistical information. And in terms of the concerns from law enforcement, commercial services, GOIP, TraceRoute, DTR Records tend to be a lot more accurate than WHOIS data, so I think again for commercial purposes, that's the best way to get this data unfortunately.

MR. CURRAN: So you do --

MR. PETERSON: I oppose.

MR. CURRAN: Central rear microphone. I am closing the microphones. The mics are now closed.

MR. SEASTROM: Rob Seastrom again. I got to thinking about what Scott said since he was the one who tossed out in this discussion anyway the separation of data which ARIN collects and what ARIN publishes and I sort of got to thinking about that. There is a value in having the data be of constant reliability and we have talked about ways to clean up the WHOIS database and put -- encouraged people to put accurate data in there and maintain it. This is sort of heading off into another direction of encouraging people to put in we ain't going to tell you in the database, so going on down that rat hole, I thought, gee, you know, since it's really easier to be able to either know you can rely on something or not rely on something, why not just cease publishing data for network numbers. Anybody who wants to find out who the upstream ISP is can log into a router, type show IPBGP, do a WHOIS on the ASN, ASNs and POCs still published, problem solved, then everybody has their anonymity and everyone's happy, right?

MR. CURRAN: That's your proposed alternative to 2006-1?

MR. SEASTROM: I believe that it would be no less damaging to the internet than this.

MR. CURRAN: Center rear mic.

MR. HANNIGAN: I just took my happy pill. I'm better. So my needs are different than the needs of other people commercially, which is why I sound a little bit different, but putting that aside, one thing I did forget to mention was in the last meeting I committed to go to my competitors and speak to them about this issue and see how they felt about it, and honestly the general consensus is that we do not -- will not be critically damaged by not having this information. This information is something like NTPs where we have multiple reference sources for our technical purposes that just contribute to the validity of what we already know. There are published NSA patents on some of this geolocation stuff, which I won't go into same detail that we did the last time because we've already done this before, but I'm willing to compromise. I like what Scott said. I think that Leo's presentation, though, made me -- I actually went up and asked Leo, and I think this might even be a better thing to work on and maybe something perhaps Sam could work on, what is the actual use of WHOIS, what do we want WHOIS used for so that we can develop policies based on what the defined use is. And I think that's kind of what Scott said, but I don't want to characterize that as what Scott said, so this proposal does nothing to get us through that, and the proposal that's in place now seems to be much more than adequate. I'm sorry that those 25 people on Embassy Row in Washington can be tracked down by their internet posts, but it's that -- you know, it's not -- this is the hammer and the ant, like Marla said, and I continue to oppose this policy, and I apologize for being a little agitated earlier. I'm sorry, Sam. Thank you.

MR. CURRAN: And rear mic back, final comment.

SPEAKER: Casey CADA, non-terrorist version of it, which would be very hurt by this proposal. We couldn't really do what we're doing now, at least we -- maybe we could do exactly what we're doing now, but we don't know how the infrastructure is going to change and taking transparency out of this what currently is residential space just makes it harder and harder for us to do any kind of independent demographic analysis, so I just hope that it's not just what ARIN can do or would like to do with the data that matters, because ARIN has now become a core public sector resource and CADA couldn't do a lot of what it does without ARIN, so I think it's a red herring to say what is ARIN going to do.

MR. CURRAN: Thank you. And I would like to thank our presenter, Sam. Thank you. We've come to the time in our program where we collect a show of hands for the purposes of providing input to the ARIN Advisory Council. I'll make sure my tabulators are ready. Okay. We are going to have one show of hands on the policy proposal. I would like the name of the proposed back up on the screen. Okay, maybe not. So we're going to ask for those who support and then those who oppose policy proposal 2006-1, residential customer privacy. First going to ask for those in favor. Would all those in favor of 2006-1 please raise your hand. All those in favor, raise your hand high. Okay. We have all those in favor. Would all those opposed to 2006-1 please raise your hand. Hold your hand high. Okay. We have our vote, it's -- we have our tally. Thank you. Okay. Total number of people in the room 112. On the question of 2006-1, in favor, eight; opposed, 52. This information will be sent to the AC for their guidance.

Open Microphone

MR. PLZAK: Okay. Thank you, John. Okay. We are at the last item on the agenda for today. That is open microphone session, so John, I will turn it back over to you to conduct open mic.

MR. CURRAN: Okay. We're in the open mic session. This is opportunity for people to get up and address issues that have not been raised or issues that have not been raised -- have been raised that they wish to cover in more detail. I will note that we adjourn at 5:00. It's a little after that, so I'm going to keep the microphones open for a short time. If you have a topic you would like to address at open mic, please come to a microphone at this time. Okay. Front center.

MR. BICKNELL: Leo Bicknell. One of the things I ran into while putting together the presentation is that the current bulk WHOIS format you can download is inconvenient. Several people have already asked me for my scripts to process it and load it in the database because it's so inconvenient, and I don't think it needs a policy proposal or anything like that, but I certainly would encourage ARIN to make it available in a more convenient format. My personal suggestion would be proper SQL insert statements so that you could just load it, however, any number of other much more machine personable friendly formats would be welcomed.

MR. CURRAN: Okay. Thank you for that comment. Any other comments for open mic?

MR. HANNIGAN: I'm trying to think which company I'm going to say this for. Okay. Martin Hannigan, Figowy Diving. You know, some of us have been talking over the weekend. I don't speak for them, I speak for myself, but I think that it was a little frustrating to have a policy come back a second time for no change, and I don't know if that means that we should consider like a dead horse policy or something or like in the old days at UsNet we used to -- they used to make these news proposals and we would kill them immediately and they would bring them right back and we made a rule that your had to have like 50 percent text change before we would consider -- you know, these were days -- I would like to propose that people think about that and, you know, I'm not sure what to think about how this process went. I mean, I think this is a precedent that -- I believe this is a precedent that the author of a proposal -- and not to pick on Sam, so Sam, I apologize if you feel like I am picking on you. I think this is a precedent that an author didn't work with the AC or other opponents and I'm a little concerned with that because like anybody can do that, but I guess if that's part of the process, I'm willing to live with that, but I think people should think about that. Thanks.

MR. CURRAN: Mr. Bradner would like to respond.

MR. BRADNER: As one of I guess the stuckee on the process, I suspect that under this case we could have used the procedure by which the AC said the consensus was to work with the author and make a change, and if indeed the author was unwilling in some hypothetical case to do that, we could have said, okay, that wasn't met, so therefore it's no longer on the list. We have an escape, which is a petition process, which then the author could have said, hey, wait a second, I still want it to be discussed, I'll go through the petition process to do so and that would have -- I think that would have been reasonable to follow the procedure in this case. It would have gotten rid of the -- reduced the likelihood of capricious behavior.

MS. AZINGER: I have a concern about that, though. If someone says they're going to work with a proposal in the community and then after AC has made the decision that that's what they agreed to and then they change their mind after that date, that you says can kick it back then after that and say, never mind, they changed their mind, so he's going to go petition them -- she, he, Sorry, Sam. I don't mean to be --

MR. CURRAN: But the point you're saying is the decision -- that AC already had an opportunity to make the decision and then teams went off to discuss it and how would you bring it back before the AC to say that's not an option. Is that your --

MS. AZINGER: Yeah, it's not going as what was agreed.

MR. CURRAN: Okay. I'm actually going to comment on this as well because I have a totally different view. We have a handful of policy proposals in this meeting, a handful. The day that I have 125 working groups and 1,000 internet drafts, I'll have a different opinion, but as long as I'm looking at less than 20 policy proposals, we will try, to the extent possible, to make sure everything gets in front of everyone in a way inclusive process, because the organizational risk for us to tell someone, well, you didn't do it right, is fairly high. Recognize that even going off to work with the author, people could have different ideas that only show up in the post-subsequent work, so while we probably could have done something different in this case to address Marty's concern in particular, we have still a policy proposal before us that was fairly well defined, it was well understood, it was not a replay of a policy proposal that was of the same words that occurred earlier, and so organizationally while it may take us some effort, we are here to actually do work at ARIN, not just enjoy the cookies, so I am sorry you have to listen to these, it's a feature of coming here. Thank you. Sam, would you like to --

MR. WEILER: Yeah, I would like to throw a few things onto that fire. First, I do believe that it is possible to make progress on a proposal even without the text having changed. Secondly, I believe it is possible to make such a trivial change to the proposal, but picking on whether or not the text changed to the minutia is really a pointless cause, and in my own defense, this wasn't the only proposal that was resubmitted without changes.

MS. AZINGER: I had one, too, actually ad nauseam repeatedly, so one of my concerns, too, is when we have ones that the community kind of gets tired after so many rounds, and I am going to admit that myself, I get tired with it, too, and I was tired with my own that went around so many times. I'm just kind of wondering if there is also maybe a point when we have one that kind of seems to be the horse is getting beat over and over again, that maybe there should be a year or two year pause before the subject can be broached again.

MR. CURRAN: Let me actually respond again. I want to be clear. A policy proposal that's been discussed, if it comes forth again, the AC is perfectly within its right to say we will consider this matter. The petition process is, as Scott noted, is our relief valve to insure that something -- maybe circumstances changed and the exact same text and exact same issue now has a body of interest behind it and it's going to move forward in the petition process. So the AC shouldn't hesitate to remove a process if it feels it's a replay if that's what it has to do, because the petition process does a lot of progress. In the case of the discussion today, I'll note regardless of whether it was a small change or a big change, there was probably some enlightenment in the room with respect to what is on the template versus what is published, and it may be as a result of the discussion today that we end up with a subsequent proposal that actually makes ground. So even policy proposals that don't look like they have support could in discussion advance all our consensus building.

MR. POUNSETT: Matt Pounsett, ARIN Advisory Council. I just wanted to agree with some of that, that it would be very difficult for us to set any hard and fast rule about how often or even if a given proposal could repeat without changes. As Sam noted, we had another this week that was presented without substantial changes, but a much clearer rationale, so I think a lot of good was served by bringing that forward again. And as you noted, there was some perhaps not new discussion, but maybe new enlightenment of people brought through discussion of Sam's proposal today, and so it might be worth having a formal place in the AC's -- in the AC's process to maybe review those decisions right before a meeting if there's something that is being brought back, but I think setting hard rules about that wouldn't serve the group.

MR. CURRAN: Thank you. Okay. Rear center microphone.

MR. DARTE: I'm Bill Darte with the ARIN Advisory Council. I would just like for the people that weren't in the AC meeting when we reviewed this from our last public policy meeting to know that, in fact, we made the decision to go back and work with the author because that was what we judged to be the consensus of the outcomes of the public policy mailing list and the results of the meeting itself and that we considered the fact that this was a rehash and that perhaps, you know, it shouldn't go forward, but as it turns out, so we understand the policy proposal process, we understand our authority. We look at these things as a body of 15 knowledgeable and experienced people and then we do make a decision of what to do, understanding that there are the escape clauses, et cetera, but we are conservative in the same way that John has articulated. We want to make sure that there's a fair and complete hearing on any policy proposal before we make a recommendation that it should not go forward.

MR. CURRAN: Okay, Leo. Front center microphones.

MR. BICKNELL: As more people have stood up and spoke, I've become more concerned. I think in this particular case there were flaws in how this policy came to be presented here today and there is room for improvement, but I am extremely concerned that what I am hearing is people who voted for or more often against the policy because of how it got here, and I think that would be a very wrong thing to do. Regardless of how a policy arrives at a meeting, we need to vote on the merits of the policy and not the process it took to get here, not the person who presents it, not who said what. We're voting on the policy and I'm really concerned that a lot of people voted against this due to how it got here and not because of what's in it, and I think that's letting the community down.

MR. CURRAN: Thank you for your comment. Would you like to respond?

MS. AZINGER: Because of that concern, that is like putting a big flag out there, and I don't want anybody walking away from here thinking, oh, what if Leo was right. Is there any chance, with that statement made, that we can vote again, because I don't want to leave here with people thinking I was swayed because of that.

MR. CURRAN: It's a show of hands, it's not a vote, but if we take parliamentary principles here, the way we would reconsider this is if a large number of people in the room said we want to reconsider this, I would do the re-vote, but first have to ask with a show of hands how many people wish us to do a reconsidering of 2006-1.

MS. AZINGER: Okay.

MR. CURRAN: So I am going to ask for a show of hands. I'm going to check that my tabulators are available. The question on the table is whether we reconsider 2006-1. A vote of yes means we will reopen that topic, 2006-1. A vote of no means the current decision remains as is.

SPEAKER: The proposal itself or working on that subject here?

MR. CURRAN: We have to open the whole proposal, so the proposal itself, okay? So I'm going to ask for a yea vote and then a nay vote. A yea vote means that we will literally reintroduce 2006-1, okay. Sam will come back up here, take any questions and we'll do another show of hands, okay, on advancing it. A nay vote means the show of hands we did earlier holds. So you should raise your hand yea if you want us to reopen this matter. All those in favor of reopening policy proposal 2006-1, raise your hand now. Raise your hand nice and high, we can't see you.

MR. HANNIGAN: He's under there.

MR. CURRAN: Okay, so we have our vote. All those opposed to reopening 2006-1, raise your hand. Raise your hand nice and high. Earlier I was going to say this was the last show of hands, I'm glad I didn't because we can actually sneak in one more. Thank you. On the issue of reconsideration of 2006-1, those in favor is zero, those opposed is 54, so we will not reconsider the matter. Microphones remain open for our open microphone session. Front center. Owen.

MR. DeLONG: Although I think that the AC probably acted properly in this particular case bringing the policy back as-is without any changes because the rationale change was sufficient to warrant some reconsideration, I am concerned about setting a precedent where a policy that achieves clear consensus of it should be revised and then reconsidered generally probably shouldn't be allowed to come back to a meeting without revision for reconsideration because I think that that is potentially a less open process given that the people who were involved in coming to the consensus that the policy needed revision may or may not still be there at the subsequent meeting and it opens the door to, well, if I just bring my proposal back to enough meetings, I don't have to modify it so much as just find the right audience.

MR. CURRAN: Okay. Point taken. I am closing the open mic session. If you have a topic, please approach the mic immediately. Center rear.

MR. HANNIGAN: Martin Hannigan. So I guess the only piece of the -- I'm not so disappointed that the policy came back, because as I understand, as you explained it, the petition process is there, it could be used if the policy is rejected or whatever, I'll go read it, that seems fine. I think the concern here, though, was two-fold, so during the discussion on the last time there was a point where the author introduced something into the argument that was prepared and not presented and we weren't given an opportunity to review, and I had brought that up at that time. It was a mathematical calculation and I don't have a Ph.D. in math, but I have five of them back at the office and sometimes these kinds of things are good to be able to review. In this case I think the piece that I'm concerned about was that we all had gone down the yellow brick road after the meeting holding hands saying we're going to revise this policy and get it passed, and in the middle of that, the yellow brick road turned to dirt and it was over from there. So I have some strong words on that, I'm not going to use them because it's an unfair characterization, but it's almost like I say I'm going to meet you at a restaurant and you go and show up and wait for me and I never come and take you on your date, so to speak.

MR. CURRAN: Let me be clear. The AC has a number of tools at its disposal. It can decide that there is no consensus for a policy to go forward. It can be decide that a policy should go forward. It can decide that it should work with the author. It can also create a policy that it believes represents --

MR. HANNIGAN: Right.

MR. CURRAN: So there's a number of tools there. If indeed you believe that the consensus and the working with the author would have resulted in a proposal that would actually advance at this meeting, you have available at your disposal the policy process. You can get together with the AC and submit your 2007-1, okay, to take up this matter, so don't feel as though you have been robbed of the opportunity to address this. It's just the author does retain the right not to accept edits or suggestions from the AC as an essential part of our concept to prevent hijacking of proposals, which is more of a -- which is a higher risk.

MR. HANNIGAN: Okay. Thank you.

MR. CURRAN: I am closing --

MR. BUSH: Randy Bush with 30 titles, I don't want to bore you to death, but I work for IIJ and I really wish other speakers would speak to who fills their rice bowl, not what badges they hold, because I want to know where your real bias is. I am willing to work on a substitute proposal. I even wanted to work with Sam. What I'm not willing to do is discuss how evil you people up there are. I'm even sure half of you are pederasts, but I'm not willing to work on it unless this group supports something -- not this proposal, but something to solve the privacy of the end site issue, so John, would you mind going through the horrible exercise of calling for a show of hands?

MR. CURRAN: And to clarify, what you want to hear is?

MR. BUSH: Is this group interested in something that deals with end site privacy.

MR. CURRAN: Can I ask, do you want to know that question or do you want to know how many people would like to work with you on that?

MR. BUSH: I want to ask the question I asked.

MR. CURRAN: I'm just checking. So the question you're asking is does this group want to have a policy --

MR. BUSH: Actually the second question is interesting. If more than two people answer yes, I'm not interested in working on it.

MR. CURRAN: I thought you wanted design teams. Oh, that was another task force.

MR. HANNIGAN: John, could I --

MR. CURRAN: Go ahead, Marty.

MR. HANNIGAN: Am I allowed to propose a second question in complement to Randy's?

MR. CURRAN: Sure.

MR. BRADNER: As long as it doesn't contain pederasts.

MR. HANNIGAN: Okay. I would like to suggest and propose that you ask the second question that consists of how many people would be interested in defining the purpose of WHOIS -- for the purpose of WHOIS for ARIN.

MR. CURRAN: Understood. Scott, do you want to respond.

MR. BRADNER: I think what Randy is trying to get at is how many people are satisfied with the privacy policy we have today or how many of us would like to see some proposal on --

MR. CURRAN: Is that a sufficient paraphrase, Randy?

MR. BUSH: What was the matter with my words, Scott?

MR. BRADNER: I couldn't hear them.

MR. BUSH: That's unusual.

MR. BRADNER: That is unusual.

MR. BUSH: So how many people here do and do not support working on proposal 2007-666 to address privacy for end sites? Got it, Scott?

MR. BRADNER: It's a rewording of what I just said.

MR. BUSH: No. You were speaking of am I happy what there is today. I'm not addressing that, it was drawn up by pederasts.

MR. CURRAN: Before we do any shows of hands, do you want to respond, Sam?

MR. WEILER: Not respond, but would a useful question, Randy, be how many people are flatly opposed to providing additional privacy to the residential customers?

MR. CURRAN: Randy, would that suffice?

MR. WEILER: Would that be more useful?

MR. BUSH: I think my question was clear. We will spend more time dorking around with it than just asking it.

MR. CURRAN: Understood, but I would like to avoid multiple shows of hands. I'm going to propose the question, Randy. I would like you to remain at the mic in case I didn't get it right, because I will not use your exact words. We're going to ask for a show of hands for how many people support working on a policy for residential end site privacy.

MR. BUSH: I will accept your adding of the word residential.

MR. CURRAN: And then we're going to ask everyone opposed to working on a policy for residential end site privacy. Are my tabulators ready? Okay. I'm going to ask for a yea and a nay. Everyone in favor of working on a policy for residential end site privacy, show your hands nice and high. Do we he have a vote? All those opposed to working on a policy for residential end site privacy, raise your hands. Working on a policy for residential end site privacy, in favor, 38; against, 16. This information will be provided to the AC for their consideration. I see no one else at the microphones for this open mic session. I declare the microphones closed. I end the open mic session. Thank you.

Announcements and Adjournment

MR. PLZAK: Thank you, John. First of all, before I ask you to clap your hands, we've added one more sponsor to this list and that's the Internet Two people in the back that have been providing the webcast, so for everyone. Wireless cards, anyone that picked one up and you're not attending the meeting tomorrow morning, please turn it in at the registration desk before you leave. If you don't, it's yours for a nominal fee. The network will shut down around noon tomorrow after the members meeting. What that means is that if the meeting goes beyond noon, the network will stay up until the members meeting is over. Meeting surveys, again, remember we really appreciate and use your comments both on the IPv6 workshop and the ARIN XVIII meeting. Raffle entry, we now have two possible lucky winners, one for the microdrive and one for the firewall router. And so some reminders, we've got about eight minutes before the Cyber Café Help Desk closes. Help desk is already closed. Bankers go home early, I guess. Members meeting will start tomorrow morning with a breakfast at 8:00 in the place where breakfast has been the last two mornings. The meeting will start promptly at 9:00 a.m. in this room, so thank you very much. See you tomorrow morning. Be safe tonight.

(Whereupon, the PROCEEDINGS were adjourned.) 16 * * * * *