ARIN XVIII Public Policy Meeting
Draft Transcript
Thursday 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 Raul Echeberria, 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, Raul Echeberria 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