ARIN XXVI Public Policy Meeting Draft Transcript - 7 October 2010 [Archived]

Note: This transcript 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.

Opening and Announcements

John Curran: Good morning, everyone. I’d like to get started. Welcome to Atlanta. I see everyone’s recovered from last night’s social, or is sleeping in, one or the other.

Okay. A couple of brief messages. First, sponsors, TELX, let’s give a round of applause. We’re going to have a remark from our sponsor. Michael, come on up and say a few words.

Michael Lucking: Thank you, John, I appreciate it. Good morning, everyone. I’m Michael Lucking with TELX. I want to welcome you all to Atlanta. I hope everyone’s really enjoyed it and enjoyed the socials that we provided earlier with NANOG, and hopefully you got to go to the aquarium and other things we’ve done.

It’s been a really good week for us. We really enjoy doing this. I want to point out some of our partners that we’ve had for this week to bring the connectivity to the hotel. We had Fiber Light and BroadRiver both supplying metro loops to get back to 56 Marietta. We were able to get connectivity from nLayer and Broadband ONE. So far several people have commented they’ve been able to download to their heart’s content this week, and bandwidth graphs are proving it. We’ve hit a peak of about 75 meg. So keep going.

Anyway, I look forward to this next coming couple of days with ARIN and getting together with everyone as often as possible. So if you have any questions about TELX, please see me. And, again, have a great couple of days.

(Applause.)

John Curran: Okay. The NRO NC election winner, Jason Schiller. We have counted the poll from yesterday. Thank you, Jason, for your work in the past and your work going forward.

Okay. Rules and reminders. The Chair will moderate discussions of draft policy so everyone can speak and be heard. Please state clearly your name and affiliation each time you’re at the microphone. Please comply with the rules and courtesies in the program.

Today’s agenda. We have a couple of reports. We have the IPv6 IAB/IETF Activities report. We have – some of the regional Internet registries were here giving updates. We have the NRO NC report. And we have the NRO and IANA Activities report. Template changes, we have a presentation about template changes and Whois, RESTful Whois. We have the Policy Development Committee report, and we have the AC On-docket Proposals report. These are the ones that are on the docket but not necessarily up for discussion at this meeting.

We also have some policy work. Today we’ll be discussing Draft Policy 2010-10: Global Policy for IPv4 Allocations Post Exhaustion; Draft Policy 2010-8: Rework of the IPv6 Assignment Criteria; Draft Policy 2010-9: IPv6 for 6rd; and Draft Policy 2010-12: IPv6 Subsequent Allocation.

For the people who are remote, I’ll say to the extent that the agenda moves around, we’ll do everything we can to make sure draft policies are discussed at the start time on the agenda or after. We won’t be starting any of these before their time, so you don’t have to worry about that. But please make sure you tune in at the start time if you really don’t want to miss a policy discussion. Which means everything else will move around to make sure that happens. If you want to see everything else, I guess you have to stay on the remote all day.

AC lunch topic tables. At lunch, members of the Advisory Council often have topic cards. And there’s a question of should this be at the end or not. If you’re interested in particular topics, you can find the AC members on the lunch topic card that interests you.

Other discussions for lunch topic tables is the IETF draft, IANA reserved IPv4 prefix for IPv6 transition. We have the Whowas service being discussed, and we have IRR data being discussed. If you want to talk about these topics with AC members, they’ll be at the appropriate tables.

At the head table, so we have – let’s see – Scott Bradner, Paul Vixie, Bill Darte. We have Lee Howard, Marc Crandall, Heather Schiller, and Cathy Aronson. Much better this morning. Coffee’s good.

Okay. Let’s start right ahead. First item on the agenda will be the IPv6 IAB/IETF Activities Report. Marla Azinger will come up and give that.

IPv6 IAB/IETF Activities Report

Marla Azinger: Good morning. I’m Marla Azinger. I work for Frontier Communications. This is the IETF Activities Update.

This presentation is not an official IETF report. There is no official IETF liaison to ARIN or any RIR. It is believed to be accurate. I believe I got things accurate, but if there are errors, it’s my fault. So if you know something that I don’t that’s not accurate and it needs to be corrected, please let me know.

Next slide. Routing area working group. The routing area – I’m going to do another review, because we do have a good number of new attendees again at this conference, so people can get familiar with what the working groups are and what documents should be coming through them.

The routing area working group receives occasional proposals for the development and publication of RFCs dealing with routing topics but for which the required work does not rise to the level where a new working group is justified, yet topic does not fit with an existing working group and a single BoF would not provide the time to ensure a mature proposal. The working group will serve as a forum for developing these types of proposals. And right now they have two active proposals. Next slide.

The v6 maintenance working group, known as 6man, is responsible for the maintenance, upkeep, and advancement of IPv6 protocol specifications and addressing architecture. The working group will address protocol limitations, issues, discovered during deployment operation. It will also serve as a venue for discussing the proper location for working on IPv6-related issues within the IETF. They have six active documents. Five of them are new, and IESG is processing one document. One is in RFC Editor queue, and there is one new RFC. So they had progress.

V6ops. V6ops develops guidelines for the operation of a shared IPv4/v6 Internet and provides operational guidance on how to deploy v6 into existing v4-only networks as well as into new network installations. They right now have seven active documents, five of which have revisions since their original submissions. They also have two in the RFC Editor queue, one is in the IESG review, and they have one new RFC.

On side notes from the last meeting, there’s more presentations that keep going on avoiding the use of NAT and then the exact opposite of how to correctly use the use of NAT. So it’s kind of a polar debate that keeps going on. There was also a new document, a basic guideline for listing ISPs that run IPv6, and that was a kind of interesting much longer debate than we thought we would get into. But it ended up being pretty good because everybody decided there needs to be a document that details what really qualifies someone as an experimental IPv6 network versus an actual, good, solid provider of IPv6 network services.

Shim6. Sorry. I said it, but we didn’t go through the slide. Next one. There we go. The Shim6 working group is chartered to track the implementation and testing of deployment efforts of a layer 3 shim for preventing locator agility with fail-over capabilities for IPv6 nodes. The group is also expected to shepherd to completion a few remaining informational documents that complement the existing protocol specifications. There hasn’t been much action in this group, and there are two active documents that seem to keep getting revised in between each IETF.

Next. Behave Working Group. This working group documents best current practices to enable NATs to function in as deterministic a fashion as possible. Due to the working group’s experience with translators and their behavior, it has been given the task to help encourage migration to IPv6. To support deployments where communicating hosts require using different address families, v4 or v6, address family translation is needed to establish communication.

In Behave, specification work group on this topic, it will coordinate with the v6ops working group on requirements and operational considerations. There are three active documents in this working group, and IESG is processing one document right now. So you can follow the progression if you’re not familiar with it. It keeps going through kind of different review groups, and by the time it gets to the RFC review, that means it’s pretty much done and it’s going to become an RFC unless something drastic happens at the last minute. RFC Editor is working on five documents, and there are actually four new RFCs. So there’s been a lot of progress in the Behave Working Group.

I’m not telling you next slide. I’m sorry. Sorry. Go back one slide.

These are all the RFC documents that are in the RFC Editor queue, and then the ones that are newly published. So you might want to go look those up. There’s been a lot of work in Behave.

Next slide. Secure inter-domain routing, known as SIDR. The SIDR working group will develop security mechanisms which fulfill those requirements which have been agreed on by the RPSEC working group. The routing protocol security group has been chartered to document the security requirements for routing systems and, in particular, to produce a document on BGP security requirements. In developing these mechanisms, the SIDR working group will take practicable deployability into consideration. There are 16 active documents. There’s quite a bit. And there are three new ones: signed object template for the resource public key infrastructure, CA key rollover in the RPKI, and certificate policy for the resource PKI. And one note is if you’re in the security area, you should go read the SIDR-AARP-11 document. This describes an architecture for an infrastructure to support improved security of Internet routing. And you need to read that so you know what to expect as to what’s coming.

Next slide. Softwire. The Softwire working group is specifying the standardization of discovery, control, and encapsulation methods for connecting IPv4 networks across v6 networks and v6 networks across v4 networks in a way that will encourage multiple interoperable implementations. And they still keep – they’re busy creating new working documents to help v6 and v4 convergence. There are two active documents: one is at IESG review and one new published RFC. You might want to go check out the new one.

Next slide. DNS operations. The DNS operations working group will develop guidelines for the operation of DNS software servers and administration of DNS zone files. These guidelines will provide technical information relating to the implementation of the DNS protocol by the operators and administrators of DNS zones. They have eight active documents in the working group right now.

Next slide. Operational security capabilities for IP networks, OPSEC. This working group will document best current practices with regard to network security. In particular, an effort will be made to clarify the rational supporting current operational practice, address gaps and currently understood best practices for forwarding control plane and management plane security and make clear liabilities inherent in security practices where they exist. Right now they have been making some progress. They have three active documents. One is IESG review, and one is in the RFC Editor queue.

Global routing operations, known as GROW, is to consider the operational programs associated with IPv4 and v6 global routing systems including but not limited to routing table growth, the effects of the interactions between interior and exterior routing protocols, and the effective address allocation policies and practices on the global routing system. GROW has eight active documents right now in the working group.

Next slide. OPSWAG. They work on operational documents for IETF. And they do have two active documents right now. One of the interesting – well, I put two interesting factoids that have been going on.

Sorry. My notes got screwed up.

There’s one document that was published or is close to getting published. It’s at Last Call with RFC. This covers when a private network or Internet work grows very large and it runs into the problems where the current private address space just isn’t enough. And this document describes the problems faced by those networks, available options, and the issues involved in assigning a new block of private IPv4 address space. Now, the last one we then had someone present a new document that requested IANA to assign another /8 in order to be used for transitional technologies but only for service providers and it would be used as basically 1918 space. So that’s a little bit of interesting activity in OPSWAG.

Next slide. The next IETF is in Beijing, China, November 7th through 12th. And then the rest of these slides are just informational tools that you can go check out and find more information on IETF documents and working groups.

Next slide. And references with – the red ones that are kind of easier to go to in order to find what you need to find.

Any questions? That’s it.

John Curran: Microphones are open for questions. Any questions for Marla? No?

Okay. Thank you.

Marla Azinger: Thank you.

John Curran: Okay. Next up we have the RIR update from LACNIC. Carlos, are you here? Yes. Very nice.

RIR Update - LACNIC

Carlos Martinez: Good morning, everyone. My name is Carlos Martinez. I come from LACNIC to give you our RIR update. So what are our most important projects in 2010. LACNIC has embarked in a whole strategic planning project that has several projects. One of them, one we consider very important, is the customer orientation project, which we want to try to view our members or customers and treat them as such. This is a kind of stretch concept for RIR, which basically has some sort of monopoly within each region. But we want to do some things different.

We are planning to create a new website. We consider our current website is a little bit confusing for some people, even for me sometimes. We want to redesign it and update its content. There’s a whole lot going on the government relationship between LACNIC and the government within the region. So LACNIC is working at positioning itself within that framework.

We are doing the whole – a whole reengineering of our systems. And then within engineering, what is my area of interest, we have four projects that we consider strategic and very important, RPKI one of them. We are working towards meeting the January 1st deadline, which is something that all RIRs agreed on. I think we will have no problem in doing that.

We are working on implementing EPP. Also DNSSEC and IPv6 are important projects. DNSSEC for the reverse zones, and IPv6 has a few branches to it. We want to improve utilization of IPv6. We want to also be able to measure how much IPv6 is being currently used within the region. Not only by counting allocations and assignments or even roots in the routing table, but actual utilization. We have different ideas on how to do that. In fact, I’m implementing some of them. If someone is interested in the room, I will be happy to have a nice talk about this.

Staff. Our team’s growing. In the past few months there have been three new full-time employees. One is our new CTO, Arturo, who wasn’t able to be here; myself, the new I&D Engineer; and Sofia, which is our second hostmaster. Our hostmaster now has two full-time employees. We are currently 23 of us, and we plan to be 25 by the end of the year.

Our membership. We have 1300 members now, which is quite a lot. We have two new /8s from IANA, 177 and 181. We are working with guys from RIPE to try to deboganize them. In fact, we are still working with some large ASs who are still filtering some of these prefixes. But we need to start using them very soon because we are running out of space. What we have allocated so far: IPv4, one .78 of a /8 and 70 IPv6 assignments. These numbers are may be a month and a half old. Probably they’re bigger now. We’ve assigned 143 ASNs, which a large percentage of them are 4-byte. And we haven’t had that return problem that much. We have some exchanges requested, but not that much.

We’ve had a LACNIC XIII event – missing there one I – in Curacao in the Netherlands, Antilles, which it was an awesome venue for an event. Some scuba diving and some great beaches over there. We had 250 delegates from 19 different countries. We had our Members Annual Assembly. We had a very nice Policy Forum. We had seven tutorials: IPv6, BGP, CSIRT, RPKI, DNSSEC, and EPP. We had an interconnection forum, a network security forum, which I chaired, an IPv6 forum, and government working group met there also. Together with our event, LACTLD, which you may or may not know is an association of the region’s CTLD operators, which has been quite active now, had their meeting together with us.

LACNIC is playing host to some other projects which all of them are in collaboration with other organizations. We have the AMPARO project, which is a project to create training material and documentation to promote the creation of computer security information response teams, CSIRTs. We have already four or five workshops. They are four-day workshops which are being held throughout the region. We have Ecuador. We have Mexico, Dominican Republic. This week it was in Santiago, Chile. And the last one for the year will be in Bogota, Colombia.

We have FRIDA, which is collaboration project with IVRC from Canada who is providing funding for research projects. We have our Raices or Roots projects, which is a project which promotes the installation of copies of the F-root server. This is an agreement with ISC. And we have another project regarding to – with public affairs.

Our next meeting in a couple of weeks will be held in LACNIC XIV in Sao Paulo, Brazil. This will be a smaller meeting only with a Policy Forum without the workshops, which will be held with the first LACNOG meeting. As you know, as it was even mentioned a couple of days ago, LACNOG is having its forum meeting. We are quite enthusiastic about it. We already have 300 people registered for it. I hope they are all able to make it to Sao Paulo. And our next big meeting will be LACNIC XV, which will be in May 2011 in Cancun, Mexico.

We are making very careful decisions about our venues, as you see. Mostly beaches and warm weather, every one of them. So I hope to see you all there in Cancun. Thank you so much. I will be happy to entertain your questions now.

John Curran: Any questions for Carlos? Thank you very much.

(Applause.)

John Curran: Continuing this morning’s reports, we have the NRO NC report by Louis Lee.

NRO NC Report

Louis Lee: Hi. This is the report of the NRO Number Council. I’m Louis Lee, Chair of the ASO Address Council.

The three members of the NRO Number Council who represent the ARIN region are Jason Schiller, Martin Hannigan, and myself. And as you’ve heard yesterday, Jason’s current term finishes at the end of this year, and congrats to Jason for another three-year term.

The three individuals from each of the five regions make up 15 members of the NRO Number Council. Our role is to serve as the Address Council within the ICANN address supporting organization. Our functions and responsibilities are defined by an agreement signed between the NRO and ICANN. This memorandum of understanding is referred to as the ASO MoU.

Now, we are charged primarily to perform these functions here. We appoint two individuals to the ICANN Board of directors, and currently serving on the Board are Ray Plzak and Kuo-Wei Wu. We offer advice to the ICANN Board on matters related to number resources. And as described in Attachment A in the ASO MoU – can you read the fine print there? – the ASO Address Council shall review the process followed by the RIRs in terms of reading a position of common agreement and a common text to describe the proposed global policy, and the Address Council shall undertake measures in accordance with an adopted procedure to assure itself that the significant viewpoints of interested parties are adequately considered. In other words, we make sure that the PDP rules were followed. And serving on the ICANN nom com this year and most likely next year also is the ASO AC member Wilfried Woeber. This past year we had an all-day face-to-face meeting at ICANN 38.

And the ICANN affirmation of commitments. When the Joint Project Agreement between the U.S. Department of Commerce and ICANN ended a year ago, they signed a new agreement called the Affirmation of Commitments. This new agreement contains specific provisions for periodic review of four ICANN objectives. These reviews provide a mechanism to assess and report on ICANN’s progress in four areas.

They are assuring accountability, transparency and the interests of global Internet users; preserving security, stability, and resiliency of DNS; promoting competition, consumer trust, and consumer choice; and, lastly, Whois policy.

Oh, back real quick. So on the accounting and transparency review team, I’m serving on that right now. The security, stability, and resiliency of DNS, Hartmut Glaser from also the ASO AC. The competition, consumer trust, and consumer choice review team will be formed next year, and the Whois policy team, Wilfried Woeber will be serving on that.

And moving on. Here we go. We are working to increase the ICANN community communication. The Address Council is doing that. I’m sorry, let me get back a little bit. The Address Council is working to increase communication to the various communities within ICANN. We’re making a presentation at the next ICANN meeting to educate and inform these communities on the status of Internet number resource policy developments, including active global policy proposals and significant regional policy proposals.

Now, the global policy proposals that we’re tracking, the IANA policy for allocation of ASNs to the RIRs – this is ARIN Policy Proposal 2009-6 – was ratified by ICANN last month. As you may recall, until the end of this year, RIRs can receive two separate ASN blocks, one for 16-bit ASNs and one for 32-bit-only ASNs from IANA under this policy. Starting next year IANA will not distinguish between the two blocks for RIR requests, justifications, and assignments. So whether we need to extend the deadline for another year is for the community to decide.

The allocation of IPv4 blocks to the RIRs. ARIN Policy Proposal 2009-3 was deemed by the NRO EC as having lost its global policy status because a substantial change was adopted in the ARIN region. I will talk more about that on the next slide.

And lastly here, the global policy for IPv4 allocations by the IANA post exhaustion. This is ARIN Policy Proposal 2010-10. It’s an active global policy proposal that was drafted to address one of the two objectives of the previous v4 proposal. It’s designed to provide a framework to IANA to allocate v4 address blocks that it receives post IANA exhaustion.

This is a slide from the update presentation six months ago. Since then the address policy working group in the RIPE region has passed the proposal in its original text form. Afterwards, it became the job of the NRO EC to produce a single global policy proposal for the ASO Address Council to process. Now, with the substantial change of the adopted version of the policy in the ARIN region, the original policy proposal no longer meets the definition of global policy proposal. And as such, it will no longer be handed off to the ASO AC and subsequently to ICANN for ratification then on to IANA for implementation.

So, as a result, we see two viable options. The first one was to send ARIN’s version of the policy proposal around to the other regions for adoption. Now, we’ve seen no interest by the original authors of the proposals to do that. The second one is to take on – sorry, the second one is to take the not so contentious portion of the policy proposal as a new global policy proposal to all the regions for adoption.

I want to thank John Curran for all his advice, the ARIN Board of Trustees for all of their time, Einar, for the fantastic job he does managing policy and making everything easy to find. Thank you, Einar. And Therese out there in Chantilly right now for dealing with all our travel details. Big round of applause for these guys.

(Applause.)

Louis Lee: And thank you all. Any questions?

John Curran: Floor is open for questions for the NRO report. No one? Okay. Thank you, Louis.

Okay. Next up we have the – we’re a little ahead of time, so rather than moving into 2010-10, I’m going to look to see if I have Axel in the room. Yes. Axel, would you mind coming up and having us the NRO Activities Report?

NRO Activities Report

Axel Pawlik: All right. Now, good morning. The NRO report. As we have heard yesterday already, the NRO is a loose cooperative body of the RIRs basically formed for the purposes of protecting the global unallocated number pool, for promoting, protecting the bottom-up policy development process, and in general as a focal point for industry interaction. If you want to talk to all of the RIRs at the same time, then the NRO is a way to do this.

It’s an unincorporated entity, has been established – and has established the ASO within the ICANN framework. And Louie just talked about that. MoU signed 2004. We decided for the simplicity of the whole thing – maybe that’s the wrong term – for the fairness of it to have the informal office – offices we’re taking through the RIRs, so every year – so this year I’m the chairman, Raul is the secretary, and John is the treasurer. And this whole thing will move on next year. So I get two years of holidays and the others will do the work, I hope.

We have also coordination groups. There are currently two of them. Established the Engineering Coordination Group with Andrei Robachevsky of RIPE, NCC, as the chair, and the CCG, the Communications Coordination Group, with Paul Rendek as the Chair.

We are also preparing for a coordination group for the registration services managers basically to communicate formally and give some communications to the NRO AC on this level as well on differences on issues in registration services.

Good. Overall, for a very long time the RIRs all together decided that they wanted to share the joint cost, and that was initially just a contribution to the ICANN budget. But of course the NRO also has a couple of expenses, certainly travel and the like, and hosting of meetings, of retreat meetings. And we have a big, complicated formula that we are updating every year. And these are the current percentages. NRO contribution to ICANN. We have good and frequent contact with ICANN. They have asked us to formally renew our contribution agreement, which we have done. The level remains the same. Currently I think the ICANN budget is way higher than this, so we’re just a tiny sliver of the big cake, but of course they’re happy to get our support.

We regularly go to ICANN meetings, obviously, and at most of them we also talk to the Governmental Advisory Committee, the GAC, sometimes on invitation, sometimes we ask them whether we should present anything, and basically of course it’s these times mostly around IPv6 and IPv4 and where are we and will the world come to an end and, if so, how. That goes very well. We are – the RIRs are very well acknowledged as communicating well and talking about the issues and drawing in their regional governments wherever possible. So we do get a few pats of our shoulders at these meetings. That’s why we go, of course.

Also, as Louie just said, we have always done a bit of an update, and traditionally we said we don’t want to do so much because the ICANN circles, to some degree, is very much about domain names and other things and not that much about numbers so we don’t want to be too visible there. On the other hand, numbers are becoming much more visible. And that’s our own making as well, talking to journalists and analysts and all that. So we will be seen. And there’s no point in running away and hiding, so we said we would do this a little bit more actively and maybe we get maybe even a couple of hours out of the ICANN organization for the meeting to stand there and talk about the current issues and what we are doing to save the world. But you talked about that already.

There’s another ICANN meeting coming up, a couple of them. The IGF, Internet Governance Forum, it’s, well, going on for five years already. We have always been there with increasing confidence on my part of this. I was a little bit afraid on the first one, not knowing how it would turn out, how friendly or unfriendly this thing would be.

The last one just happened in Vilnius a couple of weeks ago. We do workshops there. Gazillions of workshops going on in parallel. And we also try to get some in and to focus on things that are close to our hearts and important to us that we can push the right way together with participation from the industry. Of course, other workshops. We have IPv6 Around the World. Basically the good news, yes, there is IPv6 and it does work and it is being deployed, not as quickly as we want to, but basically it’s a more positive, more upbeat thing. Enhancing transparency in Internet governance, basically that goes towards talking to governments and making ourselves known and also requesting from governments that they are transparent.

So those are the two workshops that we did as the NRO formally. There was also a very nice RPKI workshop about certification and impact of that that LACNIC I think sponsored. And of course lots of other very interesting stuff. The really nice thing that we saw there this time was quite, quite obvious is that we were mentioned quite, quite often as a positive example – and I’ve heard that yesterday also; I think it was Lee’s speech – saying that we are seen out there, our outreach does work and is recognized, and that’s a very good thing of course.

Now, Internet Governance Forum. Yes. That was the fifth, and we don’t know when that will continue. Probably it will. That’s the UN General Assembly going to decide this.

Apart from this, there are lots of interesting things going on in parallel to this meeting in Mexico, the Plenipotentiary of the ITU. We have friends in the industry and some of our own stuff there to follow this whole thing. And we get basically daily updates on what’s going on there. It’s interesting. We have of course talked to the ITU for the last gazillion years about how well the process works and the PDP, the bottom-up industry self regulation, and that there are no big problems that we would know of with allocation of resources, especially to maybe developing countries. That’s something that always came back up again in the ITU. Some people just don’t stop saying that some developing countries can’t get IPv6 resources. Not true.

So we have had this IPv6 group that talked about IPv6 in general. Two correspondence groups, one about development, the other on helping development on, and the other specifically about finding out and analyzing the problems with allocations to developing countries.

I’m happy to say there were no significant nor no real tangible problems brought forward. Not surprisingly, I think.

This correspondence group then was put into a dormant state, so I think it’s a good step. However, seeing that there’s the plenipotentiary going right now and things are being dug up again and put on the agenda, it remains interesting.

Other ongoing activities, obviously we are working together quite closely on implementation of the RPKI system certification. A lot is going on in terms of outreach and communications in general. Typically it’s IPv4/IPv6. And IGF preparation I have here. Probably will continue.

We do a couple of retreats a year, two more or less regularly now for quite some time. This year they were hosted by APNIC in the beginning and alongside the ICANN meeting by the RIPE NCC. And, yeah, it’s things we need to – we needed to – sorry – we need to do together as the RIR. So outreach, certification, implementation, communications, which is what we basically talk about. And that concludes this presentation. If you have any questions, happy to answer.

John Curran: Any questions for Axel? Thank you, Axel.

(Applause.)

John Curran: We still have a little time before 10:00 and the start of our first policy discussion. I’m going to ask Einar to come up and give the Global Policy Development report.

Regional PDP Report

Einar Bohlin: Good morning, everyone. I’m Einar Bohlin, the Policy Analyst at ARIN. Yes. So I read a lot. I read all of the RIRs’ policy mailing lists and I get to go to some of their meetings. I attend their meetings online if I don’t go. So I get to keep up with what they’re doing policy wise and proposal wise.

This slide is an attempt to show you a snapshot of what’s going on now proposal wise and what’s occurred over time. So it’s by topic on the bottom and it’s the number of proposals when the snapshot was taken. In this particular instance it was – I did it last week. So, for example, in the category of IPv4, there are about 14 proposals on that topic right now. And in the past you can see v4 has been a highly discussed topic. v6 is still being discussed pretty well. Directory services is on the increase. ASNs has dropped off the chart. There’s a new topic of resource reviews, which is not only at ARIN but at some of the other RIRs too, and this has to do with auditing v4 space and being more efficient with v4. And then there’s an “other” category.

So of the totals, the very bottom shows you how many of the current draft policies are in that topic and being discussed this week.

This chart shows the draft policies being discussed this week and whether there’s something similar in the other RIRs. So we’re discussing v6 assignment policy, and that’s unique to ARIN. We’re discussing – we have two draft policies, actually, on the topic of transition – assignments of v6 space for transition from v4 to v6. APNIC is also discussing that topic. As you can expect the global proposal is being discussed at every RIR. And on the topic of resource reviews, the RIPE NCC, the RIPE region has a couple of proposals on that topic.

That top one is the transition proposal again, v6 space for transitioning from v4 to v6.

2010-13 is interesting. The general topic is what to do with the last /8. So LACNIC actually doesn’t show up here, but it has an established policy. The other regions are discussing still what to do with the last /8 in one way or another.

And 2010-14, one part of that has to do with registrations in the Whois database, and the RIPE NCC has something similar to that.

All the RIRs do their – when they do their presentations, they mention what proposals are under discussion or recently adopted. Those people are here and they have staff here that is willing to talk to you if you have questions about what’s going on in their region.

At a high level, the topics that are being discussed at the other regions – I already mentioned the last /8, audits. LACNIC is looking at reducing the criteria for ISPs for v4 space. APNIC is looking at something that ARIN did recently, which is v6 space for multiple discrete networks. And we also – in the ARIN region we implemented POC validation. AFRINIC and the RIPE region are looking at proposals on that topic.

These are links to all of the policy pages for the other RIRs. And the bottom link is on the NRO site. It’s a comparison document of all the RIRs’ policy at a very high level. If you want to see, for example, what the minimum v4 allocation policy is at all of the five RIRs, you can go to that document and on one page look at those policies.

Thank you.

John Curran: Thank you. Any questions for Einar? Okay. Thank you very much.

(Applause.)

John Curran: I do not want to start the policy discussion prior to 10:00. Making me wonder whether or not Barbara Roseman is here. Barbara, are you here? No. Perhaps not. Okay. We have a challenge. Andy Newton, would you like to come up and talk about template changes and Whois-RWS?

Template Changes and Whois-RWS

Andy Newton: All right. Good morning. I’m Andy Newton. I’m Chief Engineer of ARIN. And I’m here to talk to you about the changes that we are doing for reverse delegations which will affect templates and some of the queries that we have to add into Whois-RWS to get it to go.

Essentially we have been working at ARIN for the past couple of – it has been over a year, year and a half, working on change our data model for the way we handle our reverse DNS management from being basically where the nameservers are based on the network to where we have discrete delegations in our data model.

What that means is as opposed to having nameservers directly on our networks, we now have an ability to specify what delegations we have in the reverse DNS, put the nameservers on there, and what that does is it allows us to put DNSSEC delegation signer information on there, and also when we go do lame delegation checking. There’s not the ambiguity about whose nameservers we should be describing as lame if it does come up lame.

So let me go into this. So there are a couple of changes that go along with this. There’s going to have to be changes in the way we process templates in order to do this. And so that you can get this information back out, there are going to be new queries on port 43 and in the Whois-RWS system.

In addition, we are – and we have talked about this in the past meetings. We are coming up with a new RESTful registration service as well. On top of that, at the end of this I’m going to go ahead and talk about some smaller changes in Whois-RWS and ARIN Online.

So, again, why are we doing this? We’re doing it to enable DNSSEC. We’re also doing it so we can do better lame delegation checking. And the whole reason we embarked on this, and it has been a fairly large project, is because basically the ARIN community asked us to do this. And it makes a lot of sense.

I can move past that slide. Back in August, Mark Kosters, our CTO, sent out an email to the announcement mailing list, and that email basically described in fairly good detail all the things that are going to change, and there’s a lot of links in that email or that announcement which point to places in our website which describe how the templates are going to change and what you need to do in order to change your template processing.

Essentially, version 3 templates, which have been deprecated for a number of years, we’re going to go ahead and retire those completely. Version 4 templates, we’re going to go ahead and still process them. Of course version 4 templates have nameservers on them. So we can no longer take that information in and process it, because what would happen, if we accidentally – if we accidentally took the nameserver information, we could unintentionally or we could mistakenly overwrite information. So we don’t want to get into a process of actually modifying information you don’t want to, so version 4 templates are going to ignore the nameservers from now on. Version 5 templates, which are what we announced in August, are really no different than version 4 templates, other than the fact that nameservers aren’t on the template anymore. Version 5 templates pretty much clarify everything.

Both version 4 and version 5 templates will require an API key. Right now you can go into ARIN Online; you can get an API key. There’s a couple ways to use this. You can go ahead and put it in the subject of your email templates. You can put the API key in your mail from address. For version 5 templates you can put it as line 00 in the actual template itself. Or for complete backwards compatibility you can associate via ARIN Online an API key with your mail from address. So you don’t actually have to change any of your template processing.

To manage this information, it’s going to be real easy. You just go into ARIN Online and sign in. There’s the delegation information right there. And you can make all the changes you need.

For port 43 and Whois-RWS, delegation information will be essentially first-class entities. You’ll be able to look up like 192.in-addr.arpa and get the information, the nameservers associated with that delegation here we have a screen shot of it. So you’ll be able to see the delegation signer information, the nameservers associated with that delegation point, et cetera.

There are going to be new queries for Whois-RWS and Whois itself. Essentially for Whois there’s the new D type. So can you say “d! NET_HANDLE” to actually look up all the delegation information related to a network, or you can put in the delegation name itself, and for Whois-RWS very much the same thing. You can say “/rdns/ NET_HANDLE” – I’m sorry, “/net/NET_HANDLE/rdns”, and get it. And here are some actual examples of how this works.

And let me describe some other changes we’re doing, very small changes. For Whois-RWS we have a new pseudo resource called PFT which essentially mimics some of the behavior you see on port 43. So if you’re used to using the website, when we switched over to the RESTful Web service, when you’re viewing it via a browser, when you put an IP address in, you only got the network. You do that with port the 43 client, you get the network, and you get the Org and all the other related information. So we’ve added this PFT pseudo resource specifically so people using the RESTful service via Web browser can get all the same information as if they were using port 43. It’s real simple. All you do is you append /PFT to the end of the URLs and you get it.

We’re also working on better CIDR support. The search box for the website – there was an oversight. We didn’t include CIDR support there at all. And so we’re working on that. And that by default will use the less specific semantics. And it will also use PFT as well if you get a single hit back.

And that’s it.

John Curran: Any questions for Andy regarding all those changes? No questions for Andy? Okay. Thank you very much. Thank you, Andy.

Oh, look at that. Right on time. How easy was that? So we’re going to start on Policy Proposal 2010-10: Global Policy for IPv4 Allocations by the IANA Post Exhaustion. I’m going to introduce it, and then I’ll let Martin Hannigan do the policy presentation.

Draft Policy 2010-10: Global Policy for IPv4 Allocations by the IANA Post Exhaustion

John Curran: History. Was Proposal 115, introduced in June 2010. Draft policy in July 20th. The current version is the 20th September version. The shepherds are Bill Darte and Owen DeLong.

Summary. Global policy proposal. So it needs ICANN Board ratification. Establishes an IANA reclamation pool for IPv4 address space comprised of any eligible IPv4 address space returned to the IANA. Address space distributed on a quarterly basis to RIRs based on need. Address space in this pool cannot be transferred.

Status at all of the RIRs. AFRINIC, proposal introduced in August 2010. APNIC, presented at APNIC but returned to the list for further discussion. Proposal introduced at LACNIC in September, and proposal at RIPE introduced in August of this year.

Staff assessment. Liability risk. No.

Staff comments. The proposal defines RIR exhaustion as an inventory of less than the equivalent of a single /8 and inability to further assign address space to its customers in units equal or larger than the smallest of any RIR minimum allocation. For clarification, we interpret this to mean the exhaustion occurs at the point when ARIN has less than a /8 and no /24s per policy 2010-2 available for use. And that’s important to clarify because we want to trigger this and not have policy changes somehow have an ambiguity as to whether or not we’re in this state or not.

Resource impact. Minimal.

PPML discussion. 29 posts by nine people. Three in favor. Zero against.

“The no transfer provision is essential. Without it, a region could be very liberal. Non-needs based transfer policy can potentially suck all the remnants into their region and sell them off. "

“Just drop the transfer restriction in my opinion. The other RIRs can choose whether or not to – choose not to return address space until the transfer issue is rectified but at least we would have an enabling policy at the IANA. "

“Once demand for IPv4 slacks off to the degree where you can get even a weak consensus for creating policy that returns some of them to IANA, allowing or disallowing liberalized transfers will have become a moot point. "

“I think there’s more at stake not having global policy than the concern about what happens to a few final breadcrumbs of IPv4 or any particular RIR getting more than their share of those crumbs. "

Those are a couple of the comments that were on the list.

That summarizes the staff review. I’ll ask Martin to come up and do the presentation.

Martin Hannigan: Good morning, everyone. I’m Martin Hannigan from Akamai Technologies. And I’m also a member of the ASO AC. This proposal is being presented in my capacity as ASO AC member on behalf of the authors. And note I am one of the individuals that contributed to this policy.

John Curran: Stand by. We’re working on the slides.

Martin Hannigan: Microsoft Windows, huh?

(Laughter.)

Martin Hannigan: I’m telling you, Macs are the way to go.

John Curran: Hold for one minute while we’re working on it.

Martin Hannigan: So getting to this point, getting this thing done was a very interesting challenge. In the past, global policy proposals were typically done by – not as a requirement or anything, but Geoff Huston actually has done most of them, if I remember correctly. And it must be pretty good to have a day job at an RIR because trying to get this done as your volunteer job is probably slightly more difficult. Goat herding is not an enjoyable job, and monitoring five different mailing lists is fairly difficult as well as getting updates processed when they need to occur. It was quite an eye opener. It’s not an easy thing to actually get done. Not that that should change. I think we ought to be very conservative with our approach to global policy because of that and the fact that it does take quite some time to make changes and to get things implemented.

Hello, Tom.

Tom Zeller: While we’re waiting, I’d like to ask a process question about how this usually – Tom Zeller, Indiana University and ARIN AC. Just the process, is this typically – are these proposals drafted globally and the same thing goes to all the regions, or somebody drafts one in one region and if it passes it goes to the others?

Martin Hannigan: John, do you want to answer that?

John Curran: Bring your laptop up, Einar.

Einar Bohlin: Both files are corrupt.

Martin Hannigan: Both files are corrupt. Would we like to postpone this for a few minutes?

John Curran: So why don’t you go find your laptop and I’ll answer the question. With regards to how global policy is done, yes, generally what happens is that it’s drafted by a group of people who have interest and they will work on a single proposal text.

Now, the reality is that each RIR has its own particular template. Sometimes they have their own particular formatting requirements. But materially the proposal text that goes is the proposal text that’s drafted in a single place and then gets put on the templates that’s needed for each RIR. The material aspects of the proposal, though, will be 90 percent identical, if you know what I’m saying. Okay?

Martin Hannigan: Please give me a second while I de-Akamai-ize my desktop. Okay. Am I back on? Please no pictures on Facebook while I’m doing this. So Draft Proposal 2010-10. I’d like to thank multiple people for their time and effort, particularly Steve Bertrand, someone that’s relatively new to the community.

The way that this whole proposal came about was at the last ARIN meeting. A bunch of us were kind of hanging out in the lobby and during the discussion of 2009-06 we had been basically encouraged to go ahead and try and put something forward. Steve, that was his first – he was an ARIN fellow, if I remember correctly, and amazing. He did a great job. So did the rest of the authors. I’d like to thank them all.

So just some definitions for folks that aren’t familiar with how all this works. So ICANN and the IANA obviously, legacy address space, we’re talking specifically in some cases about legacy address space, and that’s address space that was allocated prior to the establishment of our RIRs.

RFC 2050, basically the bible of RIR operations. Most of our proposal and stewardship thought is derived from that document. You see John Curran reference that quite often. Needs basis. Resources are allocated on a needs basis. That means that you have needs. You ask for IP addresses. You justify them and you get them. And finally the ASO AC/NRO NC. Effectively the same thing, different classifications for the same committee. The ASO AC is the official body or advisory council of the five RIRs. Two voted members, one appointed. Each RIR Board appoints an individual.

Okay. So problem statement. This is going to be pretty quick, because conceptually this is the same as 2009-06. Tried to keep it short and to the point. We know why the proposal didn’t make it and reach global consensus. V4 addresses could potentially be stranded at the IANA post depletion. Current allocation process ends at N equals five. When we get down to the last five /8s, they go out to the RIRs and it’s over. Stranding may prevent the return of address space at the IANA. There are a few other issues, but we’re going to get into those later.

One other point. If there isn’t a global policy proposal, the IANA may act unpredictably. And that’s not nefarious; it just means that they move to deal with this issue themselves if they have stranded address space. And we may or may not agree with that. We may or may not agree with their action.

Okay. Provides for the IANA – provides for the IANA to allocate v4 address post depletion. Defined eligibility criteria. All the things you would expect to be in a proposal. Published distribution method. We tell them basically here’s some guidelines, here’s how you do it. Public reporting so that we have a view into how things are going and what’s coming in and theoretically what’s going out. And, finally, maintain the values of RFC2050.

Why not just adopt 2009-06? Well, why not? Transferring addresses without need is a roadblock to global consensus and mandatory return is also a roadblock to global consensus. With these two components in any proposal, it’s unlikely to reach any kind of consensus globally, and it’s quite possible without these that we may not reach global consensus.

Regional feedback. In the AFRINIC region we actually had some support. In the APNIC region there was a lively discussion, Randy Bush. In the ARIN region we had some similar discussion. LACNIC, my last review of the mailing list, there was no feedback, although I did receive some mail from the co-chairs, which was procedural mostly. And then the RIPE region, we received some feedback that was very similar to the APNIC region feedback. And basically the communities are split again.

So 2010. How does it work? Conceptually, again, 2009-06 was the template. If v4 addresses are returned to the IANA, they will be placed in a pool for redistribution. They will be allocated to RIRs based on the established eligibility criteria, and that criteria basically says if you have a certain amount of IP space – if you have a certain amount of IP address space in your inventory that is no greater than X you will be eligible to receive space. It is nontransferable. That is how we opted to address the transfer problem that this community had. And it is open and transparent. The public reporting takes care of that, and the proposal itself is pretty clear.

So comparing like proposals. 2009-06 versus 2010-10. You know, the differences for the most part are the inter/intra RIR transfer policy hook, the /10 exception and the mandatory return language. Why mandatory return fails. Threat conditions are rapidly evolving. Who knows what’s going to happen at depletion. An RIR could abandon needs based allocations at any time without a codified agreement. So theoretically – and it’s highly unlikely that this would happen, but, again, based on the conditions that may develop as we approach and enter depletion, an RIR, a community of people, could opt to change their policies in their region, which is perfectly within their rights, and we may not agree with that. And they may not agree with the changes that we make as well. A redistribution of address space should not result in less stewardship. It’s a roadblock. Basically what I mean by that is – or what we mean by that is that right now the RIRs have similar standards for the most part. There are some differences. And no two RIRs are alike. We should never expect that all RIRs are going to implement exactly the same proposals or policy. But occasionally that’s a problem.

Removing the roadblocks. Well, RIRs have returned address space previously. The ARIN region returned a few /8s last year and a precedent has been established. No reason to believe it won’t happen again. And lack of a policy may actually prevent that. If there is no policy that prevents address space from being – I’m trying to say this properly – the dissimilar standards may prevent the return – the further return of any IP address space to the IANA.

Why transfer of space fails. Needs basis system is fair until broken. We have multiple data points on this. I think that at a high level we all agree, including most people in all the other regions. I think that the difference here is that we have a unique situation with depletion. And I don’t think that we all – I don’t think that we disagree with respect to, like, markets and things like that. I just think that we have a different viewpoint on what the outcome of those things are.

So, for example, my personal viewpoint is that every address needs to be in the RIR system because those addresses may be worth a significant amount of money, and I know that others have the feeling that the market will just kind of let that happen and encourage v6 to proceed. I think both approaches are valid, and I think that more discussion is required to kind of get on the same page with respect to that.

Any RIR could abandon needs based allocations at any time. Oh, I’m going back over the same thing. I’m sorry. I’ll skip that. The crux of the problem is that we cannot reach consensus in all RIR regions. So we tried to address that with a transfer hook. And basically we tried to create a mechanism that would let us deal with this problem later so we could get the addresses into the system and potentially out to the other RIRs. So it allows RIR communities to develop better transfer requirements. We thought it separated the proposal from the politics. We were wrong. We’ll reach global consensus with transferability.

How does it work? RIR communities come up with proposals globally or – global or globally coordinated, two sentences or 200. Basically the RIR communities retain the power to decide. So, in summary, conceptually the same as 2009-06. Removes the transfer and mandatory return language that are basically unable to reach consensus. Allows two control mechanisms for the RIR communities to address allocation size and transfer. So in case we have the fire hose to garden hose issue with the routing table, theoretically the RIRs could, as we always have, work as a community and address these problems. Similar approach with the transfer language. Ensures that if there is need and there are v4 addresses at the IANA they will be distributed. Removes roadblocks with respect to the return of addresses to the IANA and basically takes all the issues off the table and puts the focus back on communities that may have IP address space to return to the IANA. And hopefully we’ll get it done and we’ll share in the benefits and pain of depletion.

That’s all I have for you.

John Curran: Now Chairman Paul Vixie will come up and help moderate the discussion of Draft Policy Proposal 2010-10. Stay up here.

Paul Vixie: Thank you, Marty. The microphones are open. Remote participation is available. Leo.

Leo Bicknell: Leo Bicknell, ISC. Generally I think I support the proposal. But there’s one small aspect of it that I’m just really confused about. There’s this one sentence that if a RIR is formed after this proposal they can’t use it to get space. And I’m not intimately familiar with the process to form an RIR, but my general impression is that it’s onerous. I don’t think they’re going to magically appear in the hundreds. So I’m a bit curious why that clause is there.

If we went through the probably multi-year process to form a new RIR and it popped up three years from now after exhaustion, why couldn’t they get their fair share of space from this policy?

Martin Hannigan: If only Chairman Mao ran the Internet and we could just make everyone happy by fiat. Good question. You know, I think it’s kind of a hot button issue, and I really am not totally prepared to answer that, but I think I can give you some of the input to that.

Basically, why would a new RIR need IPv4 space if we’re transitioning to IPv6. And for all intents and purposes we expect that that process will probably happen fairly rapidly after depletion, and every address – every v4 address needs to be in the system for transition. I’m not opposed to funding new RIRs with IPv4 address space. It just didn’t seem practical. And if any of the other authors want to comment on that, I’d be more than happy for the help.

Louis Lee: Louis Lee, Equinix, ASO Address Council chair, and also one of the authors of this global policy proposal. The process of creating an actual regional Internet registry will take longer than for us to make a small tweak into this proposal to make accommodations for it. We are – we have that in there, in part to make sure that if something comes up quickly and unexpectedly, we wouldn’t accidently give out space that we didn’t intend to.

Martin Hannigan: Let me elaborate on that a little further. I think the two regions people are thinking about are in the Middle East and the Caribbean. It is quite possible, based on my knowledge of both regions, that they may actually have a need for IPv4 address space. If the consensus is that that is actually a requirement, I think we would at this point and at this juncture and with our expectations going forward – it would be fairly easy to modify the proposal to eliminate that hot button issue.

Leo Bicknell: Leo Bicknell, ISC. So let me say that just slightly different. If those areas are today covered by an existing RIR, which in theory the whole planet is, they could get space under this proposal. If a new RIR was formed to serve them, and they could not get space under this proposal as a result, they actually become disadvantaged. And given that it is amazingly unlikely that a new RIR would be formed, it just seems silly to have that sentence, because it’s almost a virtual certainty it’s a nonissue. But if it is an issue, then it should be fair. I don’t know that it would stop me, because I think it’s a – from supporting the proposal, because I think it is a non-issue, but it just seems like a fairness thing that’s kind of silly to exclude.

Paul Vixie: Thank you, Leo.

Owen DeLong: Owen DeLong, ARIN AC. My concern is with Section 4 in that it states the inability to assign address space to its customers in units equal to or shorter than the longest of any RIR’s policy defined minimum allocation.

I know that ARIN has a policy defined minimum allocation of a /24, but I believe, if not now, at least in the past, other RIRs have had much longer minimum sized prefixes like /28s and even /32s in one case in the past. So I would really hate to see us lock up the RIRs not being able to get address space because they have a single /30 floating around somewhere that they don’t really have any practical way to give out. I think that needs a significant rewrite.

Martin Hannigan: So with respect to that, if I understand correctly what you’re saying, basically, one, I’m not sure that that’s an issue, at least from the perspective of the authors. And the reason why is you could always not accept /28s. And what we wanted to do with some of the sections of this proposal is to encourage the RIR communities to work together. So at some point we would expect that, for example, if we couldn’t handle /28s in the global routing table, that our intelligent communities would make a decision to try to balance out their minimum allocation units and that we would move forward in a cooperative basis.

Leo Bicknell: Marty, it’s got nothing to do with what people do or don’t accept in the routing table; it’s if any RIR has a policy of /28 but ARIN has a policy of /24 and all ARIN has left in its inventory is a /30, they’re not eligible to get more space under this policy. That’s a bad thing.

Martin Hannigan: I don’t quite understand that. Maybe one of the co-authors can help me out. Chris is at the back microphone.

Paul Vixie: Chris.

Chris Grundemann: Chris Grundemann, TW Telecom, one of the authors. The reason for that is that in an earlier clause the minimum allocation the IANA can hand out is the smallest prefix from any region. And so if they’re going to hand out those small prefixes, then that’s what needs to be used. Right? So we said the two minimums are the same, the minimum that IANA can hand out and the minimum that the RIRs have to use. In this policy.

Leo Bicknell: Right. But the minimum the IANA can hand out versus the minimum that an RIR has in stock are two very, very different numbers, and you’ve tied them together in a way that creates an absolutely illogical deadlock.

Paul Vixie: Jason.

Jason Schiller: Jason Schiller, UUNET, Verizon, NRO NC and one of the authors of this proposal. We had made a conscious decision about stranding addresses. And the question was what do you want to do with small fragments. In the event that all the RIRs do not have the same minimum allocation on assignment unit, you have to deal with that. One of the ways you could deal with that is to say the only stuff that can get returned to the IANA has to be large enough that any of the RIRs can give it out. Another way is to say that you can return small stuff to the IANA, but then it gets stuck there and they sit on it and maybe they can aggregate it and roll it up. A third way is to say these small fragments can be allocated to RIRs and they get stuck in limbo there. In that case the RIRs have the ability to make policy and change their allocation and assignment plans. So we actually discussed this and we made a conscious decision of where do you want small fragments to get stuck and where can they best be dealt with. And that was collectively the decision that we came up with.

Paul Vixie: Thank you. David.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I have a number of comments. I’ll start with in response to Leo, the – I like the way this is. Yes, we want to be fair. What this allows us to do is if a new RIR is created, we can look at the conditions on the ground at the time and pick the appropriate result. If we leave it moot in here, there could be serious unintended consequences when that happens. And we don’t want to have that variable in this equation right now. My next comment is in regards to –

Martin Hannigan: Hold on. Let’s do them one at a time. So they only get exactly what the other RIRs get at the time of their creation and with respect to what’s in the inventory.

David Farmer: Yeah. I think we agree.

Martin Hannigan: Okay.

David Farmer: Basically I’m saying I support the way you guys dealt with that.

Martin Hannigan: So do you want it in or out? New RIRs or no RIRs?

David Farmer: No new RIRs at this time. When we create a new RIR, we can figure out what that means with the stuff on the ground when that – because that’s going to take a major thing anyway. And it takes IANA action, and IANA can put the right words in when that happens.

The other issue is on previous policies we just had a major discussion about complexity. This whole thing about the fragments is complex. I think the right simple answer is nothing smaller – no blocks smaller than /24 go back to IANA. They just stay wherever they’re at. And only blocks to /24 can go out from IANA.

Then my final comment is I greatly appreciate the work you guys put into this and the way you found to cut the baby in half.

Paul Vixie: Can we just say cut the steak in half instead, please?

(Laughter.)

David Farmer: Okay, fine. However, I have to echo some of the comments from – that let’s not worry about the – let’s not worry about the transfer issue. Let’s leave that off the table.

Paul Vixie: Thank you, David. I noted that Jeff was going to come to the microphone. Are you – no. We have remote – Jason. Sorry.

Jason Schiller: I just wanted to address the comment of fixing at a /24. We had also discussed that in our group and we wanted it to be tied not to a specific number but rather to the policies that were implemented and as those policies change allow that number to float.

So I just wanted to ask a clarifying question if, David, you would be comfortable with something that said the shortest minimum allocation or the longest minimum allocation or something like that that was a little bit more flexible than simply flat out at /24.

David Farmer: I’m fine with whatever kind of language, but I think it’s silly – when you look at DNS delegation and all that kind of stuff, it’s silly to be moving fragments smaller than /24 around between the RIRs. It’s bad enough to have RIRs handing out those things. But the damage and just craziness in the DNS delegations is going to be nuts.

Martin Hannigan: No one said that depletion was going to be perfect, but thank you. And we are not cutting babies in half.

Paul Vixie: I want to note that /24s never have been good to hardwire into anything anywhere. And something that floats around with some flexibility would have been better for a lot of equipment that I’ve used. We have a remote participant.

Cathy Aronson: Yes, from Joe Maimon at CHL. He said if no one else asks, he has three points: Is there any other way to deal with RIR reservation policies other than hard coding a /10 exemption in the definition of RIR exhaustion? His second question is: If removing mandatory return torpedoed the previous global policy, how will this one fare better with intentionally – with that intentionally left out? Which is actually something I’d like to know. Somewhat tangentially, what possible shape could a global transfer policy take that would win consensus? Has any thought gone into creating one?

Martin Hannigan: So on the first point, the /10 was so that we could defer to other regions’ transition proposals, policies, and give them some continuity with respect to their own regions. It was feedback that we received from the APNIC region. We looked at what was going on globally with regards to transition proposals. We have 4.10 in the ARIN region, and that’s the number we picked. With regards to the second question – that was mandatory returns?

Cathy Aronson: Yes.

Martin Hannigan: With that in the proposal, it’s not going to reach global consensus, but we thought that with the modification of the transfer language and actually allowing the creation of transfer but separating it from the proposal it would be a compromise as contrasted against the mandatory returns.

Paul Vixie: Rear mic.

Unidentified Speaker: There was a third point.

Cathy Aronson: The third point was: What possible shape could a global transfer policy take that would win consensus? Has any thought gone into creating one?

Martin Hannigan: No, and that’s exactly why that language is in the proposal.

Tom Zeller: Tom Zeller, Indiana University and ARIN AC. I have to agree with Owen that you’ve sort of artificially linked the smallest unit that can be given out and the smallest unit that an RIR – how do I want to say that? You’ve linked two things that don’t have to be linked, basically, and could leave us ineligible for some fragments. And I understand the desire to generalize it instead of saying a /24, but in this case I really think if you just say /24 it just simplifies things in a certain way and makes certain things clear.

And – and I know this leads to more complexity which always leads to failure – maybe we need a separate mechanism for redistributing pieces that are smaller than a /24 and just consider them as separate crumbs that can be moved around, and if ARIN doesn’t want anything less than a /24, then, fine, it won’t get any. But people could still return something smaller than a /24 and it could be given out to somebody.

But if you put those smaller crumbs aside, which are really kind of not maybe that important, and you look at – focus on /24s, I think the whole thing would just work better. But nice job on pulling together a lot of threads and different concerns and objections. I congratulate you.

Paul Vixie: Thank you, Tom. I note that we are into the time normally reserved for a break, so I’m going to close the queues. Moving to the left microphone.

Emilio Madaio: Hello. Emilio Madaio from RIPE NCC, Policy Development Officer. I would like to echo the last comment. We had an impact analysis in our region. That’s kind of the staff assessment you have here. And there was some kind of confusion similar to the last comment and Owen’s comment about the Section 4.

My question is, though, on the Section 6 about the transfer rights, and I would like to put the point of view – I would like the authors to elaborate better their intentions. Because what I read here talking about intra-RIR transfer, they will be allowed under an ICANN Board ratified global policy or globally coordinated RIR policy. So my question is: Is it the intention of the authors to have globally coordinated policy influencing entity-to-entity transfer within the same – within the same region?

Martin Hannigan: That would be completely up to the RIR communities.

Emilio Madaio: Okay. So you’re saying it is possible to still have transfers inside the same region without such –

Martin Hannigan: Well, we’re not trying to define what goes on inside a specific region. But if five RIRs put forward a proposal that allowed inter or intra RIR transfer and it reached consensus globally, all the more power to the communities, I guess. We didn’t really – we tried to stay out of the transfer issue as best as we could and theoretically put it back in your laps.

Emilio Madaio: By “your laps,” you mean laps of all the RIRs?

Martin Hannigan: Yes.

Emilio Madaio: Okay. Because my point was transfer intra-RIRs are ruled by local policies. So having a local policy that has to confront with other local policies, is that the intentions of the authors?

Paul Vixie: So what Marty has said is that this proposal deliberately does not address anything about transfers, leaves it open for future work. I want to note that the queues are now closed. If you’re not in the queue, please do not get into the queue. Geoff.

Geoff Huston: Two comments here. Geoff Huston, APNIC. The first one is actually a comment more generically about global policies versus coordinated policies. As I recall and I think I recall pretty accurately, global policies were meant to be adopted by all RIRs to in effect direct IANA to perform certain actions. They were not specifically intended to limit or direct the RIRs across the RIRs. That was coordinated policies.

And so firstly I suppose I’m speculating and wondering a little bit to what extent what you’re proposing here oversteps and starts talking about RIRs rather than IANA. Second comment. What this is in effect, if I get rid of most of the paraphernalia, is a proposal to allow IANA to distribute and manage independently and separable blocks of addresses of size less than a /8 in v4. When you strip it out, that’s what we are talking about.

Now, the biggest pool of such addresses happens to lie, for those with memory, in the old B and C space. And right now today there are the equivalent of seven and a half /8s that are sliced and diced into fragments of a /16 or larger. If we were collectively going to accept and by consensus approve this global policy, my speculative question to you is: Why would those legacy B and C holes not be affected by this, and, if they are affected, what would be the likely outcome of that were we to implement this policy now. Have you thought about this and what implications are there? Thank you.

John Curran: When you say are they affected and what would be the implications of it, it’s the policies for the returned space. So it provides a way for space that’s returned to be reallocated. I’m not sure how that can have an effect on someone who is holding their resource and not doing anything other than using it.

Geoff Huston: The holes in the B and C space are not obviously anywhere, are they? Where are they? They’re certainly not allocated out to end-users or LIRs.

John Curran: Oh, you’re saying the holes, not the allocations.

Geoff Huston: The seven and a half /8s in total that are in effect in nowhere space in the old Bs and Cs. That’s the bit that I’m wondering. Once you start saying IANA can deal in little bits, at the moment the little bits can’t go back to IANA because they’re too small. There is no policy that allows IANA to do anything with them, so the RIRs basically collectively are saying, well, it’s a common resource.

John Curran: The RIRs collectively have bits of them.

Geoff Huston: Bits of them. And it’s a kind of common resource. But under the effect of this policy were it to be accepted, what are the implications, if any, was my question – because I’m not sure – to that pool of address space? And I’m kind of wondering, because it kind of seems to intersect.

John Curran: Okay.

Martin Hannigan: Just addressing the first point with regards to the local policy implications, I think the 2009-6 had some of that as well with mandatory returns.

John Curran: I’m going to look carefully and see if I can answer that question.

Paul Vixie: Thank you, John. Can I get Tony at the microphone since he and Geoff sort of have competing visions about when we’re going to run out? I’d like to hear his views.

Tony Hain: Well, no, I think part of what Geoff was saying right there toward the end is there are some fundamental assumptions about how the tail end plays out that are in the current set of assumptions people have, and this policy would step on that very explicitly if it were in place today.

And one of the concerns I had as I was reading it is I couldn’t go find the text. I scanned it. I found this thing that said quarterly. I’m sitting there going, now, wait a minute, given the burn rates in some places in the world, quarterly doesn’t cut it, and/or depending on how quickly you want to play this game, it all goes to one region anyway. So, well, depending on how you want to – so as much as you’ve got protections in there, there is a potential that if it steps on other assumptions that have been made to date, it can create a big problem. I understand you’re looking at trying to look past this, but the way it’s worded it actually could step on it, and that’s the problem.

Paul Vixie: Do you have a suggested patch?

Tony Hain: No, this is kind of occurring in real time here.

Paul Vixie: Okay. Thank you.

John Curran: Geoff Huston, can I ask a question about your question again? Is it your assertion that little fragments of space, the C and B space, which are held by the RIRs, that that should be returned into this reclamation pool or that they should not be returned into this reclamation pool? As specified, it’s optional. It’s space offered for return.

Geoff Huston: The way I read this, IANA is given the ability to deal with it. And my inference would be that a number of RIRs would see that as being, then, appropriate that they return it. That has implications in the existing run out scenarios, because currently, I must admit, our assumptions and modeling have always been that that common resource would be managed equitably such that every RIR would get equal use – in other words, about 390 /16s – from that pool.

If it were to go back to IANA, it would be a relatively different distribution and it would create very, very different outcomes. And I was wondering if that was an unintended side effect of what’s being proposed here.

John Curran: I think the RIRs could certainly opt to return their pieces of that leftover fragment space using this policy or collectively RIRs could decide to exclude it. It would really be a decision for the RIRs to make since the policy allows it to be done. You’re right.

Geoff Huston: But if they withhold that lot from – without handing back to the IANA, it sets an awfully weird precedent for any return space. And this is why I’m sort of wondering about the cross impacts of this policy against our existing – I wouldn’t say plans, but our existing conceptions of what we’re going to do in the next few months.

John Curran: So I think what Geoff brings up, which may not be known to a lot of people, including folks even working on the proposal, is there are many little pieces of address space stranded in every RIR that we’ve historically assumed are about even and would be used by the RIRs to fill in gaps when we get to that point. This policy doesn’t just apply – potentially does not just apply to space returned to an RIR that it in turn sends up to the IANA. It could return to those little holes. And if it’s used in that manner, that would affect a lot of people’s assumptions about end game.

Paul Vixie: I note that David and Leo have gotten into the queues after I closed them. Please be brief. Front microphone.

David Farmer: I just wanted to quick point – a question to clarify this. I hope it clarifies for other folks. Where do those little itty-bitty blocks sit right now? Do they sit in IANA or do they sit in the RIRs?

John Curran: They sit at the RIRs.

David Farmer: Thank you.

John Curran: Leo.

Leo Bicknell: Similar clarifying question. Why are they stranded? If there’s a B available and somebody qualifies for a /16, why wasn’t that already given out?

John Curran: If you go and look at one of those nice heat graphs of allocations of the Internet, have you ever seen one where they display the space? In some areas of that heat graph where you’ll find – see that the allocations that were made were sprayed across multiple registries, several registries in many cases. The management of the leftover pieces of those heavily overlapped areas is very problematic because of things like reverse DNS. So we haven’t – in general we’ve tried to take contiguous blocks and put the RIR responsible for contiguous block in charge of a contiguous block.

Where there really is – and when we do that, there ends up being a gap. So if we end up in a particular pattern, if we ended up with in a /16, 170 of them were managed by ARIN, and /22 were RIPE, the rest of those in that /16, the rest of those /24s, for example, might be stranded. We’re not making them worse. ARIN’s managing the block. We realize there are some RIPE pieces in there, but we’re not adding to that block right now because we’re not trying to increase the problem that we already have.

When we get to the end of address space and we really are in a situation where we have to make an allocation work, yes, we will put effectively – we will give people assignments in areas that were traditionally called, for example, swamp space, suddenly a few more allocations will be made there. We haven’t been increasing use of those mixed areas right now.

Leo Bicknell: I think my trouble and maybe some others’ is the use of your word “stranded,” because they’re not permanently stranded, they’re just currently inconvenient.

John Curran: Right. Chris.

Chris Grundemann: Chris Grundemann. I just wanted to state that with regard to some of the comments about direction to IANA versus direction to the RIRs through a global policy process, what we’re trying to do here – I think Marty covered it fairly well – is remove roadblocks. RIRs have returned space in the past. Going forward we need a way for that to happen. And I think that most organizations, many organizations, anyway, in many regions will have a hard time returning space at all if they aren’t certain about what’s going to happen to that space.

Paul Vixie: Thank you, Chris.

Martin Hannigan: Thank you very much. I’d like to thank the authors of 2009-6. We considered their work the template for the work that we did, and we’re looking forward to continuing to proceed if possible. Thank you.

Paul Vixie: Thank you, Marty. So we’re at the point once again where we need to know what you think. We have people standing by to count hands. Please raise yours nice and high. First we’ll look at those who are in favor of this proposal. Thank you very much. If I could see a show of hands those who are opposed to the proposal. Thank you very much. So at the conclusion of the reading of the numbers, we will be on a coffee break until – what time?

John Curran: We return from break at 11:00. Oh, wait. Sorry.

Cathy Aronson: That’s four minutes from now.

John Curran: 11:02? Let’s see. That’s a great question. We have a policy due on the return of break at 11:00. Therefore, I’d like to start relatively timely. So if people could come back here by 11:15 that would be good. Thank you.

Paul Vixie: Now for the traditional reading of the numbers.

John Curran: There’s still the results.

Paul Vixie: We have 138 people. They did not all raise their hands. 40 raised their hands in favor. And five against. Thank you.

John Curran: Thank you. I’ll see everyone back here at 11:15.

Draft Policy 2010-8: Rework of IPv6 assignment criteria

John Curran: Okay. I’d like to welcome everyone back. If everyone would come in and be seated. Welcome back, remote participants. I hope you enjoyed the break.

We’re going to pick up where we left off on the policy proposal discussions, and we’re picking up with Policy 2010-8: Rework of IPv6 Assignment Criteria.

John Curran: You have a copy of the proposal in your Discussion Guide. You have the staff assessment of the proposal in your Discussion Guide. Between the staff assessment and the proposal is generally the rationale. That is not in the Discussion Guide. The rationale is taking a break.

It is available online. If you want to read the rationale for Policy Proposal 2010-8, somehow it did not make it into the book, you need to go online to read the rationale. Just want to make that clear. For people online, this isn’t a problem. You’re not shredding trees. You have the whole thing online.

I’ll do the staff introduction. Started out as Proposal 107 in January. Became draft policy on the 23rd of February. Presented already at ARIN 45 (sic). The current version is the 14th of September version. The shepherds are David Farmer and Scott Leibrand.

And summary: It changes the IPv6 assignment policy so that need is determined by the total site count. Presuming sites get /48 or larger, you count up your sites and that’s the measurement used. Provides a formula to allow initial assignment that allows for aggregation and growth.

So ARIN assigns on nibble boundaries, for example, /48, /44, /40. Subsequent assignments are based on a 75-percent site count. Not individual site utilization; truly the site count.

Draft policy’s unique to ARIN. Current policy for /48 in AFRINIC, qualified for IPv4 policy, and have a plan. Kind of the plan we all started out with. APNIC, push a button. Automatic if multi-homed with IPv4 space or plan to multi-home. LACNIC, automatic, if organization has IPv4 space or have a plan and route the aggregate. RIPE, need to be multi-homed.

Staff assessment: Legal liability: None. Liability risk assessment. Staff assessment, issues, concerns. Greater than 12 sites must be assigned to a /40. Fee schedule increases at /40.

So the question that comes up is if you are in the situation where the – if you’re in the situation where you have a – you start going to a larger category, you end up with a fee increase, theoretically, because you’ve gone to the next boundary.

Inconsistency between the assignments and allocations. So this would create a very separate regime for assignments distinct from allocations. And that means we’re doing things differently. Our policies were becoming more consistent between assignments and allocations.

Resource impact is minimal.

PPML discussion: 36 posts by 13 people. Five in favor. Zero against.

Some of the comments. “This is a good start for the rework of the policy, but it sounds as if the acceptable justifications are wide and flexible enough to warrant reasonable justification of I want to be portable and globally unique, which in my opinion is all you should need and desire to have your own allocation. "

“What’s the definition of “site”? Any building campus on the network. I think that’s as good a definition as any. I’d like to make sure that the ARIN policy makes it easy for large end-users to consider themselves ISPs’ LIRs, you get a /32 where appropriate and justified. "

That concludes the introduction of the policy by staff. And I’ll now have David up to give the proposal presentation.

David Farmer: Okay. Oh, boy, I didn’t check this.

So what does it do? It replaces Section 6.5.8 with new language. We’re attempting to restate it in clear, plain language. The old language was somewhat cryptic and not well understood by the people that need to use the policy, the end-users.

Removes direct references to IPv4 policy. Makes it sort of mostly independent. General goal is to provide sufficiently large initial assignments rounded up to nibble boundaries to reduce routing table growth.

So what does it do? It allows end-users to meet one of the following criteria to get a /48 or larger. If you have a previous IPv4 allocation, this is much the same as what’s in policy already.

If you’re multi-homed, this is new, but there’s general consensus, it seems to be, have 1,000 or more hosts. This is intended to be congruent with current IPv4 policy, mostly to make sure we don’t have any discontinuities when v4 runs out on who can get address space. And then provide a technical justification indicating why IPv6 addresses from an ISP or LIR, other LIR, are unsuitable. This is probably a little controversial.

So for end-users with multiple sites, allows up to a /48 per site. Basically based on the concept of site equals a location, not a site equaling an organization.

There was a bunch of discussion at the last meeting on this. I was headed away from this and was asked to bring it back here again this way.

Total assignments based on the number of sites rounded up to the next nibble boundary. This does eliminate HD-ratio, replaces it with a 75-percent threshold of the number of sites.

This is to simplify it. I’m not sure everybody in the room understands HD-ratio. I will tell you: End-users do not understand what HD-ratio is.

Provide for large – provides for larger sites. This is intended to be mostly unused. Although, I’ve had some feedback that maybe there are people doing things in this, so I have to look at this maybe a little closer. But the intent here was you need to use quite a bit of the subnets before you get more than a /48 for a location.

And this – the original intent for this was to be mostly unused, just defining it so that people know what they have to do.

Subsequent assignments require 75-percent utilization of all of the site assignments in total.

Subsequent assignments are normally made by expanding a current assignment in place. When that’s not possible, a new assignment of the next nibble boundary is made, and then we move on from there. And then so in this case, or there are other cases – there are other cases where end-users might end up with multiple assignments. They should consolidate into a single aggregate when possible. And they must return the unused – any unused space of those separate assignments. If you move out of them, you have to return them. But you don’t – you should move out of them, but you don’t have to.

Changes in queue. A couple of things didn’t make it into the freeze here. Discussed on PPML was a change to the clause c. So instead of a thousand hosts, flat out, it’s 2,000 hosts within 12 months. This seems to be more in line with the intent of the IPv4 policy. And we need to make a couple similar changes to the number in one of the examples in the rationale.

Add a subnet clause to that same section there. It would basically put d and push down. And this is just some of the proposed text, throw something out and put a number of 200 down for subnets.

Some people wanted to – the concept of measuring hosts in IPv6 seems ludicrous to some folks. They think subnet is the right way to go. This is the proposed way to deal with that.

Staff comments: As a consequence of rounding the nibble boundaries, this creates a fee increment going from 12 sites to more than 12 sites. The answer is yes, and that’s just a consequence of this. Maybe we can adjust the fees if this is felt to be inequitable. But that’s something for our friends at the Board to take care of, I think.

Staff finds the policy text in a few sections here a little confusing and unclear, and they probably need to be cleaned up. Due to compressed cycles here, I wasn’t able to get any real answers to staff’s concerns on these parts.

So discussion questions that I have that maybe prompt some discussion. Should we keep the host counts? I think probably till well after runout just for consistency sake, as I discussed on the PPML.

Is the site location the right concept? HD-ratio versus the 75 percent threshold. I’m sure there’s opinions on that. If you want to keep HD-ratio, what does that mean for an end-user?

One of the motivations for changing to the 75-percent threshold is the current HD-ratio policy is somewhat ambiguous on what that means in our assignment policy.

Staff has worked this through, but that doesn’t mean it’s clean in the way we all want it to be.

So questions, comments? Paul, I think it’s time for you to run the mic.

And then the slides, there’s some appendices with the whole proposal written out here just so that I’ve got it if we need to review sections.

Paul Vixie: The floor is open for comments and questions, either here in the room or on the remote participation.

Owen?

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC.

I support the policy as written. If you could go back to your discussion point slide. No. Yes, it’s the right concept to use; 75 percent is a very good idea; and, no, we should dispense with HD-ratio in general but certainly in the end-user case.

Paul Vixie: Thank you, Owen.

Wesley George: Wes George with Sprint.

I think the comment I want to make on this, I’m not sure how I feel about the proposal yet. Site location, the question that you’re asking specifically there, I think I’m leaning towards no on that. But mainly from the perspective of what it does in terms of allocations and your ability to aggregate.

You know, there was discussion on the list somewhat about, well, I’ve got, let’s say, a college campus or a business campus or something like that, where you have multiple buildings associated with it. Do I give each building a 48; do I give that entire location a /48?

I think there’s probably some clarity that needs to – that needs to be there about that specifically, because, done wrong, what you end up with is you’re giving out way more /48s than are really necessary based on the amount of subnets that are even feasible within a building or within a location. And you end up driving more deaggregation than I think would be necessary.

Because it’s not likely – if people are given – if IPv4 is any indicator, if people are given /48s, it’s not likely they’re going to say, okay, I’ve got all these /48s and they happen to be contiguous and they’re all in the same area, so I’m going to aggregate those up. The only way that aggregation typically happens is if you’re given a supernet and told to subnet it, not if you’re given a bunch of supernets and then you’re trying to be a good Internet citizen and you aggregate up further. So I think that would be my concern.

David Farmer: Just to respond to that. The assignment you’re given is the nibble boundary-base thing. If people are thinking they’re being given a bunch of /48s, I would argue that.

But even if an end-user organization were to announce the /48s individually, how is that any different than providers announcing traffic engineering routes and all that that the community requested that we take out of policy?

So if you’re asking for tighter policies on the end-users, why shouldn’t those tighter policies apply to providers?

Wesley George: Because there’s two separate problems. I agree they’re both problems and I agree they both need to be addressed, but I don’t know that you should lump them together.

There are – saying, well, because this other group is doing it we ought to be allowed to do it too is specious reasoning, in my opinion. We’ve got to solve the problems we can solve. And I’m saying there’s room to tighten this up a little bit without fundamentally altering the way the policy is being done.

David Farmer: What I’m trying to say if it’s a problem in one place, it’s a problem in another. We need to deal with it both ways, not just in one place.

Wesley George: Right. But what I’m saying is this is the one place that we can deal with it here, so let’s make sure that we do.

Tom Daly: Tom Daly, Dynamic Network Services.

Clarification question. How does the v6 multiple discrete network policy, if at all, apply to this? Or does that apply to allocations only?

David Farmer: That’s a little fuzzy.

John Curran: One second.

David Farmer: My opinion, that’s a little fuzzy.

Tom Daly: Taking a quick read of it, it seems like if we’re trying to allow subnets for sites, /48s for sites, an end-user under the existing guidelines should just be able to apply under MDN.

David Farmer: I think that’s one possible solution; however, that’s rather complicated for end-users, just my response to that. And then the other thing is, with MDN, there’s no requirement that that would be an aggregatable single thing. With this, we end up with an aggregatable single thing, or we don’t end up with – you might not be all aggregatable, but there’s a lot more bound on that in this case.

John Curran: Multiple discrete networks is certainly a more encompassing policy, more flexible policy. And I guess while it’s one way some of the organizations that would use this policy could solve their problem, this would change default v6 allocation – default v6 assignment policy for all end-user assignments.

So if we don’t do this policy, then some of the people could solve their needs with MDN and the work involved. But the vast majority of IPv6 allocations would be allocated according to our existing – assignments, I’m sorry. The vast number of IPv6 assignments would be done according to our existing assignment policy. And, if we do this, they would be – the vast majority of them would be assigned according to this policy. Change in the nature, for example, of the routing table and aggregation.

Paul Vixie: Does that get you? I’d like to close the queues soon. Left-hand microphone.

Jeroen Massar: Jeroen Massar. I just have a comment about the definition of a site. One of the better definitions is basically an administrative border so that when you have an administrative network operating group that they manage like maybe five to ten buildings or something that they get a /48 for their management, because then they can divide wherever their routing goes internally.

If you have that at completely different sites, generally you have a different networking group which will handle this. So administrative would be a better concept than –

David Farmer: One question for you. So in that concept that you’re proposing, would an enterprise made up of multiple different administrative domains therefore end up with multiple sites? Or do you consider the overall administrative domain of the organization to be the site?

Jeroen Massar: Depending on your size of the administrative domain, that could be multiple sites, yes.

Paul Vixie: Sir.

Kevin Oberman: Kevin Oberman, ESnet.

Once again in this discussion I see the v4-engrained tendency to worry about allocating too much space. I see a deliberate effort in some parts to avoid that, and I appreciate that, but I would really urge that when a problem can be resolved by simply handing out bigger chunks of space in v6 land, within some bounds of rationality, we’re much better off giving off bigger space than either forcing people to renumber into a different space or having lots of spaces to fill up the routing tables. And I know we’re all aware of that, but there still seems to be an instinctive reaction to “don’t hand out too much space. " And I really wish people would avoid that.

Also I’ve noticed, Paul, that you or John has not been doing the usual of asking everybody up at the mic whether we support the proposal or not. Was that a policy change or just an oversight?

Paul Vixie: That is because I’m going to be asking for a show of hands at the end.

Kevin Oberman: Okay. I just missed that. I was so used to hearing that for every person up at the microphone.

Paul Vixie: Thank you. Heather.

Heather Schiller: See, there’s a conflict in the extra-large site portion. So an extra-large site is one that requires more than 16,384 /64s. But later on in the same paragraph it says: Extra-large site will receive the smallest prefix such that the total subnet utilization justified does not exceed 25 percent.

So if we need – 25 percent would be 4,096 subnets.

David Farmer: No. 25 – that’s probably bad wording. The number of subnets you can have in a /48 is 65,000. 25 percent of 65,000 is –

Heather Schiller: Okay. Then maybe it is just very poorly worded.

David Farmer: Yes. Thank you for pointing that out. I will help to clarify that.

Paul Vixie: Do we have a question from the remote?

Cathy Aronson: No, he withdrew.

Paul Vixie: Back microphone.

Scott Leibrand: Scott Leibrand, ARIN AC.

I support this policy. I’ve been very involved with it, and I think we struck a good balance. But I got up here to address the MDN question.

With MDN, you basically have to have different ASNs to get different blocks for the multiple networks, because they have to be discrete networks, not just discrete buildings, discrete sites. So anyone who runs a connected network with a bunch of sites basically has to go under the regular policy. I think John addressed that larger point correctly. But I think it’s worth pointing out it’s multiple discrete networks. We’re talking about multiple sites.

There’s somewhat different things. I think I support the approach that David’s taking here, and I think it addresses the concerns that MDN addresses, but for companies that have a single network instead of multiple networks.

Paul Vixie: Thank you. John.

John Curran: I’m not going to – Scott, I’m not going to disagree with your conclusion. But I am not sure that the MDN policy requires discrete ASNs as written. Discrete networks does not necessarily mean discrete routed networks.

Scott Leibrand: I was not trying to imply it was a hard and fast requirement, but it tends to be the correlation.

John Curran: Tends to be the case.

Paul Vixie: Michael.

Michael Sinatra: Michael Sinatra, UC Berkeley.

I’m leaning towards supporting the policy as written.

I do have a question which is regarding the site location issue: Is it possible or desirable or really undesirable to effectively leave that somewhat vague in the policy and give the staff some leeway to make reasonable interpretations of where a site boundary is for the purpose of assigning addresses? And maybe the staff – maybe someone on staff wants to answer.

David Farmer: I’m willing to find some flexibility there. I’m having trouble finding language that while clear and understandable to end-users gives that flexibility. So if you have some suggestions, I’m all open to them.

But there’s a tension between leaving that flexibility and providing clarity and understanding.

Michael Sinatra: Thanks.

John Curran: Did you guys flip a coin? Jason.

Jason Schiller: Jason Schiller, Verizon, UUNET, NRO NC.

I have a couple of points I wanted to make. First thing I wanted to pick up on was Jeroen’s discussion about a site. In general I support this idea of considering separate sites and giving space separately to the separate sites. Certainly for geographic locations that makes a lot of sense. If you have 100 stub networks in different locations all with their own connectivity to an upstream, treating them like individual sites makes a lot of sense.

If you want to talk about cases where it’s a little less clearer, I think I would talk less about the organization of which networking group is running it and talk more about the structure of the networks themselves.

Really in my mind the question is what about a single contiguous network that has a single routing policy, even if it is geographically disbursed, do you want to treat it as one site or multiple sites? I think that’s probably something you should consider and maybe have some thoughts about.

David Farmer: Do you have an opinion on that?

Jason Schiller: I think it would be nice if it’s a contiguous routing domain for that end-site to be able to be aggregated. In the case where that end-site is getting upstream from a single ISP and they’re using PA space, they’ll probably get aggregated in the PA space anyway. But in that case it might be good to allow multiple noncontiguous /48s per location, because that way the ISP can do internal regional aggregation. So yes and no is kind of my answer, sadly.

The second point I wanted to talk about was the nibble boundary. These seem like really, really, really big steps to me. And I can certainly understand wanting to be able to give people a SIDR they can roll up and aggregate.

Certainly if they have one geographically discrete location, you want to give them one /48; if they have two geographically discrete locations, two /48s seems to makes sense. You can roll it up to a seven. If they have three, four /48s seems to make sense to me.

I don’t like these big jumps of going directly from a /48 to a /44 for somebody that has two geographical locations. That just doesn’t seem appropriate to me.

Thirdly, this 25 percent utilization doesn’t seem to be in line with the HD-ratio. And I’m not sure why you just don’t use the HD-ratio.

David Farmer: I would like to have a discussion with you on that. When you read the HD-ratio policy as it is in our policy, it says nothing about subnets. It may be implied. It may be what staff actually does. But that’s not what it says. It says of /56s.

So when I read that, I read if you use a /64 out of a /56, that entire /56 is utilized. So in that case, by current policy, if you have a /48, my interpretation is you only need to use 256 /64s and you can get a whole ’nother /48.

If you have a different interpretation, I’d like you to provide it to me and we can talk about this. But I think this is actually more conservative than current policy as it is actually written.

Jason Schiller: I guess the question is: How does staff interpret it today, both in the PI case and in the PA case, where there’s multiple sites for an organization?

Paul Vixie: John.

John Curran: How would you – I want to be very clear. In the PI and PA space, how will staff interpret this policy?

Jason Schiller: The current policy.

John Curran: The current policy.

David Farmer: Current NRPM.

Heather Schiller: How does staff interpret? The example given was if /64 – David is saying if a /64 is used, he considers the entire /56 to be used. I don’t believe –

John Curran: The site is used. An allocation to a site counts as a site – are you saying under this policy or under current policy?

Jason Schiller: Under current policy.

John Curran: I apologize. I’d actually need to ask Leslie. Leslie, are you here? Leslie, for – under the existing policy, for determining utilization of allocations – assignments made by an ISP, how are we counting the utilization?

Leslie Nobile: So we’re counting – in /48s, even though the HD-ratio table is in fact 56s, we do a conversion so that we get the right numbers. But we do 48s as the – does that make sense?

Heather Schiller: No.

Jason Schiller: So two cases. Case one, Akamai, Inc. , comes to an upstream ISP and says they have three sites, three separate networks, not interconnected: one in New York, one in Chicago, one in LA. And they say I would like a /44 of PA space. In the second case they ask for a /44 of PI space.

John Curran: If they’re coming to ARIN, they’re asking for PI space.

Jason Schiller: No, they come to the provider and ask for PA space. How does ARIN view the utilization of that resource?

John Curran: We have not had a provider come back, so we have no way to answer that question, sir.

Jason Schiller: So it says in the NRPM that assignments larger than /48 need to be approved by ARIN staff.

What guidance is ARIN staff using to approve such requests?

John Curran: Assignments made by an ISP larger than /48 need to be approved by ARIN staff.

Have we had any come in that we’ve reviewed? I don’t know if we’ve had any ISP come in asking for that approval.

Leslie Nobile: I think we probably have. There’s not many of them. But initially I think they were just going through – I actually really don’t know the answer to this.

John Curran: We would have to go back and look and see what the practice has been there.

Leslie Nobile: I do not believe we’re reviewing them, to be honest.

John Curran: I don’t think we’ve had any submitted. I don’t know of any.

Heather Schiller: The question is about HD-ratio, it’s not about. . .

Joel Jaeggli: Joel Jaeggli –

Paul Vixie: Wait a minute. Excuse me.

John Curran: People are not using it, is the problem.

Unidentified Speaker: Use the mics, please.

John Curran: Just let it continue.

Paul Vixie: We’re going to continue. Joel.

Joel Jaeggli: Just a question: Wouldn’t you use the PI criteria to assign like larger than a /48 under those circumstances? Wouldn’t that be the evaluation criteria?

John Curran: Yes, you would expect that to be the evaluation criteria.

Joel Jaeggli: Because I know that’s happened because I’ve requested one of those.

Paul Vixie: Owen.

Owen DeLong: I’m hearing a lot of people express concerns about why are we giving away all these extra 48s and why round up to nibble boundaries and this, that, and the other thing.

Some numbers for people to contemplate: If we were to give everybody that currently has an active AS in the routing table ten – not one, not two, not five, but ten /28s, not /48s, /28s, we would consume exactly one /12 in each of the RIRs and we would still have 506 /12s remaining in the first /3.

There really is no risk to the address space from giving out these rounded-up-to-nibble-boundaries /44s, even /40s. I think we should go ahead and define a site that gets a /48 as a building, or in the case of a multi-tenant structure each tenant within that structure qualifies for a /48, or, if they can show need, something larger.

I think that because people are bad at bit math in their heads and people do bit math on the fly in their heads in order to configure routers when we have these weird odd boundaries that we should look at reducing the number of outages and other problems caused on the Internet by moving things to nibble boundaries, where people no longer have to do bit math in their head.

I think the human factors engineering of this is well worth the additional address space that it will consume, because it is just a tiny, tiny, tiny fraction of the available address space. And, quite frankly, having more than three-quarters of the address space, more than seven-eighths of the address space, and certainly more than 991 one-thousandths of the address space sitting on a shelf versus making use of it for practical purposes like this simply does not make sense to me.

Thank you.

Paul Vixie: Thank you, Owen. I will note that given we’re using /64 for a LAN, which probably will never have that number of hosts on it, that beginning to conserve as soon as we get above the /64 is a little bit odd.

Are there any other questions or comments on this proposal? Far right. Thank you.

Gary Giesen: Gary Giesen, AKN.

I’d just like to sort of echo Owen and the gentleman from ESnet’s comments that if we can solve problems, whether it be problems with aggregation, renumbering, whatever, by throwing address space at it, I think we should. There’s no reason – obviously it’s got to be bounded on some reasonable measure. But if we can throw a little bit of extra address space at it to solve the problem, I say go for it.

And as for the definition of a site, I think we should actually leave that fairly open to how – to what the actual end-user wants to do. Whether they want to aggregate a campus network into a single /48 or whether they want to number discretely, I think that should really be up to them. Because ultimately they’re the ones that are going to be able to make the best decision for their network.

We’ve got the address space. Why don’t we just let people do what they need to do.

David Farmer: Before you run, does this seem reasonable limits for you?

Gary Giesen: Yes, I support the policy as written.

David Farmer: Then the other comment I would have on defining this, I mostly agree with you; however, I think we all need to degree on what the upper bound of a site can be. And that’s what I’m trying to define here, because I personally would have a problem if somebody came along and said I need a /48 for every floor in a building or something like that.

I think we’ve got to find some reasonable upper bounds. And in the way we do things and all that, the location, the building kind of thing seems to be one of the more reasonable bounds to work with.

Gary Giesen: I’d actually tend to agree. I’d say a single-tenant building would get a /48; multi-tenant building, each tenant would get a /48.

Cathy Aronson: Cathy Aronson, ARIN AC, not remote participant.

Some of you have heard me say this. I’m going to say it again. People have said that with v6 we can address every grain of sand on the planet, and maybe we can. But if we give it away a beach at a time, it’s going to go away a lot faster.

So we don’t know whether – I mean, everybody thought v4 had a lot of address space too in the beginning. And I know Owen doesn’t agree with me. But we have to strike a balance between giving away beaches at a time and not.

Paul Vixie: Owen, do you want to respond?

Owen DeLong: Let’s experiment with as many as 20 /12s, and, if I’m wrong, then we can be more conservative with the next 480.

(Laughter and applause.)

Cathy Aronson: But that also creates a swamp, Owen, and then we’re back – anyway. . .

Paul Vixie: Sounds like that lunch table is going to be interesting today.

(Laughter.)

Heather Schiller: So I was going to try to clarify something that Jason was trying to say, which is that ARIN has a – in the ISP reassignment policy they have a section that says about the assignment of multiple /48s. And he was trying to sort of point out that there’s the possibility of creating a discrepancy between ARIN being able to allocate multiple 48s for end-sites where ISPs could not do the same for their customers.

But the policy for ISPs actually says if a single end-site requires multiple 48s, and this policy actually addresses a single organization that has multiple sites. So we use the word “sites” to mean, many times, and you kind of have to look at the definition of it in context of the particular policy and the particular organization.

Paul Vixie: Thank you very much.

David Farmer: Just to comment on that. If there is an inconsistency, I think the right answer for us is to figure out what we want and then make it consistent, rather than oppose or not do something because it’s not consistent with a different part.

Paul Vixie: I note that there are no further questions or comments. John, is it lunchtime?

John Curran: Two minutes. Enough time for a show of hands.

Paul Vixie: Thank you for reminding me. I will get this right. Can we have our tally takers? We’ll have a show of hand on this.

I wanted to note that yesterday John could not remember the names of the people at the head table and that this morning I not only called Jason by the name Jeff, I previously had called Lee and Woody by each other’s names. So there’s something in the water.

I would like to see a show of hands those in favor of this proposal. Get them up nice and high so we can count you.

John Curran: I don’t think it’s in the water; I think it’s about being a Board member.

Paul Vixie: There’s not enough coffee in the universe for this job.

(Laughter.)

David Farmer: Hey, that’s better than the open mic that our President of the United States says.

Paul Vixie: Are we set? Thank you. Those opposed to the policy, if you would let us know that from a show of hands. Proposal to this policy, draft policy.

David Farmer: The language would be draft policy.

Paul Vixie: More coffee is not always the solution. There’s a wonderful comic strip called “Too Much Coffee Man,” which tells the story of my life.

So the time for the lunch is now until when?

John Curran: We’re on lunch break until 1:30.

Paul Vixie: So after the reading of the numbers we will all go out for lunch and be back here at 1:30. Lunch is where the lunch always is, in the lunchroom, where you had breakfast.

Thank you, sir. The tally is here. Survey results are: 150 people in the room. 44 in favor. 15 against.

Thank you very much. See you at 1:30.

(Lunch break taken at 12:00).

RIR Update - RIPE NCC

John Curran: Okay, everyone, welcome back. I’d like everyone to take their seats. We did not get to the update from RIPE this morning. So we’re now going to have Axel come and give the RIPE update. Update from the RIPE NCC.

Axel Pawlik: Basically sort of the more interesting things that I thought might be of any relevance to you in comparison with us and stuff like that.

Now, you probably know how the RIPE NCC does its corporate governance. We have two general meetings a year, which we use to get some bearings on what we should do, where we elect our members representatives onto the Board and stuff like that.

So in May we did the first GM of the year and it was very exciting, because we were told to do electronic voting. And my first reaction to that is, oh, no, I don’t want to implement anything. I really don’t want to do this; can’t we just do paper ballots and send letters. Apparently that was not possible under Dutch law. It’s really weird. Electronic voting. We did this.

We said we would hire services from somebody else. I think it’s BigPulse, the company. We had little 15-minute slots on the agenda that were fixed in time, so we had to make sure we reached them in time and not too early and not too late, and people then were able to remotely vote.

And the people in the room, by the way, had to do paper voting as usual, because our articles were made up that way; that it was interpreted that it was not possible to do electronic voting once you’re on site. Very interesting.

So those papers ballots had to be input by hand into the system, which we reckon it was about two seconds per vote or something like that. It was interesting and it worked. Thank God. We were very relaxed and very happy afterwards.

So the result of the votes, then, is that we have a small change in our executive Board. Janos didn’t quite make it this time, but we have Remco van Mook on the Board now, and you see the lovely picture.

And of course since we had to have this link between online voting right at that time that is necessary under Dutch law – you can’t have just two weeks of prevoting; now you have to sync it with the meeting – the whole thing was webcast also. That was a new thing with our members. It was not a public meeting.

Right. That worked and we hope to improve on it even further next time around.

All right. Well, you might have heard about these things already. We do exhibit good stewardship in that we do some reclamation. We know it won’t save the world. We will run out of address space soon. But there is an added benefit to this also in terms of just not getting some address space back but also we regain some of our lost members who forgot about us or forgot to pay or whatever.

So they come back and reopened and contributed to the budget a little bit as well.

We do considerably more audits these years. Obviously it’s important that we do this, and you see from the numbers that we have stepped it up quite significantly. And we continue to do so. Oh, God, yes.

2007-01, PI space. We have had this lengthy process where we asked our members to confirm that they know the people they have given this address space to once upon a time. And participation isn’t bad there. Or wasn’t bad. But still there is quite a lot of people that – what we call – it’s often end users, people who have no sponsoring members, so we have to go and find them ourselves and go and use the telephones, possibly, even.

That will be quite labor intensive. We need to do this. Good stewardship again. Speaking of that, we – as I said, we do audit our members that they adhere to the policies and give us good demonstration of their need.

Of course we also want to be audited ourselves desperately, so we paid KPMG to do this, basically to look whether the RIPE NCC staff is adhering to the processes as they should be. And yes we are. That’s good.

And, of course, for large requests we do some internal escalation procedure. I think that’s just good practice.

Now, you have heard reference to this before, RIPE Labs. Something we thought of earlier last year where we said, oh, God, we are fossilizing ourselves; we implement stuff until it’s near perfect and then we roll it out and people adopt it or not. Sometimes they don’t, and then we waste a lot of energy. We need a way to coordinate with our community much – communicate with our community much more frequently and with a lower threshold and all that.

Apart from that, yes, the RIPE NCC is more than the regional Internet registry. We do other things as well. We want to get them out into the public and talk about them. If we have ideas for new stuff we want to talk about and see what the feedback is, whether people say don’t ever do this or whether they say, oh, that’s extra cool.

So we launched this RIPE Labs thing, revamped it. It looks better. Basically, as I said, the idea is to improve communication with the community, help ourselves a little bit with implementation of services, but also to give a platform for all sorts of people, from researchers to engineers, to talk about their nice and cool projects. So have a look, if you haven’t done so already.

Okay. One of those things that we’re discussing currently on Labs is a pilot for a new measurements project. You know that for oh-so-many years we do the test traffic measurements project, measurements over the net.

And the idea was that would have been very useful for our members, the ISPs of the region, to measure how full their lines were and those were still expensive and all that stuff. And this has never quite turned out to be that popular as we thought. Probably we didn’t have this quick feedback loop at the time. That’s something that is behind labs as well.

So the idea is now we have some of the TTM nodes, of course, on the order of – shy of 100 around the world but with a strong focus on our service region, not surprisingly, which is nice.

But of course the world is a different place, especially in Internet terms these days. So there are many more measuring nodes really necessary to derive any meaningful picture of the overall weather on the Internet, let’s say.

So the very high-set goal here is to have a measuring thing in every AS and every major city and even the smaller cities.

So we have nice plans for this. We have some hardware. We’ll announce this properly at the next RIPE meeting. And there is, as I said, a set of articles on labs.ripe.net, why we’re doing this and what’s behind this and how you can participate and what the hardware is and what you can derive from that.

IPv6 Ripeness. We are also, same as the ARIN folks, asked regularly: How is it with IPv6? Are we ready yet? And so this is some thought about finding some measurements, some things to look at to have some scale of what we call IPv6 Ripeness, also about – also on Labs.

As I said, Labs is one way to look at community needs. Of course, there are others. The one formal way that we have is the Activity Plan, which we write up every summer when other people are holidays and we present to it the Board. The Board says yeah, it sounds reasonable that we present this.

We publish it, present it to the general meeting together with a draft budget that would finance all those activities. And then we get feedback from the – formally from our members to agree on a charging scheme that would enable that budget and those activities.

Now, that’s fine, but of course we need to do more. That’s RIPE Labs. There are training services that are training courses that we give regularly in rather high frequency. And we have caught on to the idea to ask the live members that come to those training courses and do sort of mini surveys: do you want us to enhance this in the database, for instance, or what do you think of certification and how can we make this palatable to you. Things like that.

And of course the big membership survey we do every two or three years. One of those is coming up next year. And so far we’ve only had good experience with that in that they bring us new ideas that we then implement. For instance, all our regional activities in Moscow, for instance, or in the Middle East is something that came out of membership survey.

Staff exchange with APNIC. Now, it says APNIC. Of course we also want to do it with others. This is one of the ideas that came to my mind about ten years ago when I entered the circus, saying that, oh, we have five similar organizations all around the world; wouldn’t it be cool if you could rotate some staff.

Took a while, but now we have done the first formal staff exchange with APNIC. They had the capacity and we worked together with them. That was at least the first part of the exchange. Very good experience. The second one is still ongoing.

We are very happy with this. And of course we are talking to Mary K. as well, we want to do this with ARIN and with the other RIRs wherever possible. That needs, of course, a little bit of slack in having people available to send away. Of course always easy to accept, mostly, to accept some.

So this, I think, is a very nice thing. It serves a little bit as a motivational incentive there for staff as well. And well certainly if you go to Australia, if you come to Amsterdam, it might be different. I don’t know.

John Curran: Mauritius.

Axel Pawlik: You said that. Good idea.

External relations and communications. As I said earlier, there’s a lot of things that we do together as RIRs within the NRO that’s a bunch of work. There’s the usual background stuff we do for our members and the governments in our region. There’s activity plan. There’s support for the RIPE and all the other meetings, the regional meetings, meetings with law enforcement.

Now we come up with the idea of having only regional meetings and those roundtables for governments and regulators but also regional roundtables. So we want to do that as well. That’s a website to be done.

Yesterday at 8:00 I was sitting there half awake and was talking to some journalist from England about IPv6 adoption and what it means that the RIRs do not give out IPv4 space, and said, no, that’s not quite true. No, no. We give out IPv4 as long as we have it. Not for long, though. Stuff like that. Lots of that.

Outreach activities. A whole big list of meetings, and they’re getting more.

Having been in Vilnius at the IGF, it really pays off. It might not be seen by everybody as the core of our activities, but it’s becoming core of our activities. It’s good people understand more and more how we’re doing it and why we’re doing it the way we’re doing it, so that’s a good thing.

Lots of channels, talking to journalists, IPv6 acknowledged – I’ve seen it on some screen a little bit earlier – talking about experiences about rolling out IPv6. That’s a good thing.

We talk to governments. I have Norway here and have the EC here for December. We are getting increasingly invited to those things, which is lovely.

Yes, Rome. In November. It should be not too hot. We hope it will not be rainy. I’ve told people from APNIC to this time come with more than just a shirt. Last time we got very wet and very cold. Of course they’re all heartily invited. It should be nice. Probably it will be a nice meeting. We are still chasing the Vatican about that social they wanted to sponsor. My theory is they are retracting a little bit because they found out who we are and what we do at socials. I’m not quite sure. And we couldn’t secure the Pope myself. But I’m German, I can do that as well.

All right. That’s basically me for now. Any questions I’m happy to entertain, otherwise I thank you.

John Curran: Thank you, Axel.

(Applause.)

Draft Policy 2010-9: IPv6 for 6rd

John Curran: I have Mr. Paul Andersen, Mr. Paul Vixie. I have Dan. I have Owen DeLong. I have R.S. and Stacy. Very good. Okay. We’re going to resume our discussion on policies starting with IPv6 for 6rd, Draft Policy 2010-9. I’ll do the staff introduction, and then we’ll have Marla come up and do the presentation.

History: Origin is 4 May of this year. Became a draft policy on the 20th of July. The current version is the 24th of September version of the text.

Summary: Adds to the IPv6 allocation policy. Allows an ISP with IPv4 space to request an IPv6 allocation for a 6rd deployment. The allocation gets reviewed after three years to see if it’s still needled. If it is, it can be kept.

Status: APNIC has a similar proposal, which has been returned to the list for discussion.

Liability risk: No. We don’t see any issues from a legal perspective.

Staff: Reassignments of /64s to customers will qualify an ISP for a /32. If ISPs want to make larger reassignments to customers, they can qualify for increasingly larger allocations with no other qualifying criteria. For example, if you want to use this and assign 48s to customers, you’ll automatically qualify for something as big as, for example, a /16.

Resource impact: In terms of ARIN staff, minimal.

PPML discussion: Ten posts by four people. One in favor. Two against.

Here’s some extracts: “I think the language here is adequate to at least start meeting the needs of providers that want to deploy 6rd, and I think it’s more important that ARIN not pose an impediment to this process, especially between now and IANA depletion, than to have ideal wording. " “2010-9 as written more or less guarantees an IPv6 /28 to all current IPv4 registrations. " I’m guessing that’s an “against” comment. “I need some convincing that we’re solving a problem that actually exists versus policy for policy’s sake. " This concludes the introduction. I’ll now have Marla come up and give the presentation. You can come on up, too.

Marla Azinger: (Off microphone.)

John Curran: Okay. It’s been noted that there’s another policy proposal that is going to come up and that we need to actually discuss both of them and they’re related.

So I’m going to introduce the second policy but note that it’s hard to discuss two policies at once. So while we’ll go through the introduction for both, I want us to talk to this one, keeping the other one in mind as the next discussion. Because trying to discuss two policies at once does not make for conducive discussion. Actually, I’ll defer to the Chair. Paul, it’s your call as to whether we discuss two policies at once or not.

Paul Vixie: Well, we’ve never done it, and that makes it interesting. So, no, let’s not do that.

John Curran: Okay. But the policy that follows this one is related because it’s another transition proposal, and you need to think about it because you might want one versus the other.

Draft Policy 2010-12: IPv6 Subsequent Allocation

John Curran: This one is IPv6 Subsequent Allocation, Draft Policy 2010-12. Submitted in June; current version, 20th of July. Adds an IPv6 subsequent allocation policy. It allows an additional IPv6 allocation for transition technologies, IPv4 to IPv6. These allocations are reviewed by staff every three years. APNIC has a similar proposal. Okay.

The question is under what circumstances – right now transition technologies is transition technologies, and there’s some discussion of enumeration or not. As such, it’s left to staff. No criteria to be used to determine the size of the allocation an organization qualifies for. Again, it’s an open topic. Should the staff be approving any requests for subsequent IPv6 allocations of any size, whatever the justification, if they say “we’re using it for transitional technology”; i.e. , if someone comes up with a new and innovative technology that requires a /15, do we say, wow, that’s interesting, but since it’s transitional, do we approve it? Because it is left open.

So posts, six posts by six people. Zero in favor, two against.

“I generally support the concept behind both policies of providing flexibility to get additional allocations for justified implementations, but prefer a more generalized policy change for any appropriate transition technology like -12 has, than I would for something specific, like -9. " A preference for this policy over the prior one.

“I cannot support 2010-12 until it has been rewritten into a form that offers guidance to staff as to how requests are to be evaluated and places appropriately conservative safeguards on both the number of subsequent allocations and the raw count of allocable addresses. "

“If ARIN is going to adopt this, then I would prefer ARIN designate a specific block for IPv6 temporary special allocations and make all of them from that prefix. "

Recognizing there’s a more general allocation policy, let’s now go back to 2010-9, which is the one specific for 6rd, and discuss that.

Marla Azinger: Hello. I’m Marla Azinger. I work for Frontier Communications. And I’m going to start this out with the what and the why. So we don’t have a problem if someone has an initial – sorry, let me start over. We do not have a problem if someone is just going for their initial allocation. However, we do if someone already got an initial allocation, like myself, and I have a /32, and it is deployed in my backbone all the way out to my edge routers. We’re peering with transit; we’re peering with final peers. So we’re already using it. It’s very deeply deployed to the point where pulling it out would be very painful to do and then go back to ARIN and ask for, you know, a newer, bigger one.

So this is more an issue when you have somebody that needs a subsequent allocation just for transitional technology, like 6rd is an example. And due to timetable intervals we ended up doing two proposals, because we had the 6rd and then we got community input not really until close to the time crunch of where we have timestamps set for the policy process. And so we left 6rd alone because there were also some people that still supported it. But we then wrote a second one that was a subsequent allocation policy that removed the items just as being specific to one type of technology.

The authors do want everybody to know that we would abandon the 6rd proposal. However, the AC already accepted that one. We do favor the subsequent allocation policy. And I do want to ask Leslie to confirm one more time, because I know the question keeps being asked: Why are we doing this? You should already just be able to get a subsequent allocation. And I would be happy to sit down right now if I could get Leslie to say, oh, we don’t have a problem. So if you could just reiterate it, Leslie, if you could, that I can’t qualify because I don’t meet the ratio.

Leslie Nobile: Right. You don’t qualify.

(Laughter.)

Leslie Nobile: So you could get an initial allocation for 6rd. Pretty easy to get a /32. But for a subsequent allocation, you would either have to have met the HD-ratio on your current /32 in order to justify an additional allocation, or you actually have to open up a whole new account under a new ORG ID and request it separately. Those are the two ways I can think of. We thought maybe MDN, but I don’t actually think that would work. So I wouldn’t even offer that as a solution.

Marla Azinger: I do not wish to open a second ORG ID and have a second account and have a second bill. I’m pretty sure other people tried to make sure that their costs going out the door don’t increase. So moving forward. Okay. So the goal. Get the community to decide on one of the two proposals. Get the community to decide on any modifications to the preferred proposal, like what do you want removed or what do you want added. And then ideally get the ARIN AC to write the preferred modifications that we can come to kind of a consensus on and move it forward for ratification so that we actually get this resolved before the next policy meeting. It would be nice if this doesn’t take six to 12 months to get done.

Sorry. This is an eye chart, well, because it’s lengthy. This is the 6rd one. There’s a lot in it. It’s very long. And I’m going to go through more of this right now and not stick – hopefully all of you got a chance to actually read this. It is in your sheets that you all have, the pamphlets, which you can probably read easier than this slide.

The part that we do want to keep around is just the instructive example that is at the end of this first 6rd proposal. And the instructive example is really the only part that really needs to be kept, because it gives ARIN staff a good way to analyze requests for additional space due to technical requirements. It’s a good example.

Mark Townsley: Hi. This is Mark Townsley. I think that that’s the instructive example from -12.

Marla Azinger: There is an added extra line.

Mark Townsley: Except for the first line.

Marla Azinger: Right, right.

Mark Townsley: Everything else is from 12 except for the Roman numeral one, which says: Transition mechanisms which embed IPv4 addresses within ISP allocated prefixes allow for – and allow for service provider managed stateless operation. One such mechanism is 6rd defined in RFC 5569.

Marla Azinger: Just a side note. If you read and compare your pamphlet to this slide, you’re going to say what the heck? There’s an extra line in here. That’s the first line. Okay. So I did ask Mark to come here to go through specifically how we got here, because there are certain technologies that exist now and that we don’t know what’s going to come down the road where people will need a subsequent allocation just for this transition piece and to use it for that.

So this isn’t about getting into technology and how exactly it works and all the tidbits. This isn’t a technology forum. He’s mostly just going to go through it so you can see how it applies to the addressing.

Mark Townsley: Thank you, Marla. And so, yes, Marla asked me to come here and describe this. I’m going to talk in general a bit about transition mechanisms. What you see on the screen here are three either/ors in transition mechanisms in general.

What we see is that the transition mechanisms either tunnel or translate. They’re either stateless or they’re stateful in their operation. They’re either service provider managed, so given to you by your ISP, or something that’s a bit over the top, right, managed by the user themselves to get IPv6 access irrespective of whether the service provider is aware of it or supports it. So these are the three either/ors.

Okay. I’m running into the same problem. What’s advance? Have to use the little toy. 6rd is a stateless service provider managed tunneling protocol. That’s how it fits in the whole realm of tunneling protocols. So I want to speak a bit about why that’s relevant to address assignment policy. 6rd begins with what we call a 6rd IPv6 prefix. This is a standard allocated prefix from the RIR. That’s what it begins with. The second piece of construction is an IPv4 address. Actually, it’s only the unique bits for the particular deployment, the unique bits inside IPv4. Often that’s /32 if you have a deaggregated space. But theoretically the protocol has provisions for this to make it smaller. We’ll talk more about that in a minute.

The position of that – the position and size of that address are described by two variables, N and M. We’ll get to that in a minute as well. Following that naturally in any IPv6 address is your subnet ID and then the 64 bits so that SLAC can operate. The subnet ID gives you routing in the home, allows you multiple subnets. Of course the Internet space ID allows SLAC to work. So this construction is exactly what allows 6rd to be stateless and service provider managed. If you did not embed the IP address, you would no longer be stateless; you would be something else other than 6rd. If you didn’t start with a service provider prefix, you would be something else, like 6to4 or something else that we already have. That’s why this is a new thing, and that’s why it’s important with respect to IP allocations.

So a bit about the packet flow and encapsulation where 6rd is in the realm of the universe and so on and so forth. One thing about the deployment model here is because of the stateless operation, because of this embedding, et cetera, et cetera, the IPv6 packets follow the same path as IPv4. So when you’re talking from home to home to home to home, you’re not going up to some tunnel concentrator and tromboning your traffic back, you actually follow the same path as you would for IPv4 as long as you’re inside the service provider domain.

The only time you go through a big Cisco router or something is when you do this. . .relay function. That’s the blue line. Upstream traffic off of your service provider network. It’s a relay function that’s stateless. So you can send the packets out over anycast. You can hit anyone you want and you don’t build up state every time users are added, you don’t build up state every time TCP connections are open. So it scales remarkably and provides the user an experience that’s quite good. Very close to IPv4. In fact, the quote from RIPE labs that you see there is that externally, 6rd looks, feels, and smells like native IPv6.

The other chart that you see there are measurements from Google, from our friends Lorenzo, Erik, Tiziana, et cetera, who published a report where they measured IPv6 around the world. You’ll see France dwarfs everyone else including China. And that’s one reason 6rd is deployed there.

So what should N and M be? That’s the question of the day. Apologies for that little hiccup and too much moving around. Let’s look at some examples. N of /32 equals M of /64 in the typical case for a service provider with nonaggregated IPv4 blocks. /64. The problem with this particular model is /64 does not work – does not give you multiple subnets in the home. This breaks existing residential IPv6 equipment. You go out and buy an IPv6-enabled residential gateway off the shelf today and they’re picking one for the subnet. The Linksys routers that we’re selling, the Valet routers, by default have a home and guest SSID from the start. Right? We also want to add we – from the – the ZigBee Alliance has sent requirements into the IETF saying we want to be able to have a v6 subnet in the home that works alongside your Ethernet IPv6 subnet.

All these things lead up to routing in the home. The alternative is NAT or really obscure stateful things where you take your neighbor cache and you start applying /128s based on discovering of the hosts. And it gets really nasty. It’s stateful. It doesn’t work well. So we want to keep that subnet ID in the home. If we let the /64 become the least common denominator for the IPv6 deployments, then what we’ll end up with is the residential gateway manufacturers having to do all these arcane things, and IPv6 – the experience for IPv6 will go down.

So let’s look at another option. Remember I told you a moment ago you only need the unique bits. What if you have an aggregatable block of addresses? You can deploy IPv6 within a /32 and give a /56 to the home, 256 subnets. More than you need for this particular application. And it actually works quite well with the CGN. But I don’t think we want to encourage deploying a large scale NAT and so that you can get aggregatable space so you can do your 6rd. It happens to work well in this model, but I don’t think it’s one we want to encourage. We want to be able to deploy IPv6 alongside your global IPv4 before the day that we need to have the NATs.

So let’s look at another model, /24. Gives you /56 in the residence. One of the recommended sizes for residence. But /24 feels, seems like overkill to a lot of people. So where is the middle? The middle is /28. /60, 16 subnets may not be as many as you want, but it’s way better than zero. It’s way better than zero. And it actually matches most 6rd deployments today. The 6rd deployments that I’m aware of that are going on in Europe, the ones that are ready in this region, this is what they’re targeting. I’d be happy with bigger. But, anyway, that’s for discussion for later.

So there has been a lot of discussion – this is straight off of the PPML – about size. Remember, there are two things up here today. One was what Marla is talking about, just getting the subsequent allocation so that if – you’re treated no worse because you happen to start with a /32 a while back than you would be if you were a brand new ISP that was created today going for initial allocation. So this is straight from the mailing list. Bill Herrin and Owen DeLong were having a discussion, they sort of agreed on this as text that you could put into the direct policy in order to try to get a cap. No organization can justify holding total IPv6 allocations that exceed /24 under this policy, with a rationale. No organization can justify more than two disaggregate allocations under this policy respective of individual total size, with a rationale. Unless an organization is mapping more than N, he gets five. Number of disaggregated IPv4 allocations with this transition mechanism, then the largest additional allocation they can justify is /32.

So trying to keep it under control if someone is out there trying to game the system or is just being irresponsible in their deployment of 6rd or whatever transition technology. So I think – well, that concludes sort of the idea of 6rd. I hope you understand it, got it all in your head, if you didn’t before. And I turn it back over to Marla.

John Curran: Thank you.

Marla Azinger: Well, now as we’re – officially 6rd is done, that proposal –

John Curran: Want to have those people who want to speak on 6rd, save it, have their chance – Paul, do you want to come up and moderate. They’re checking procedure. Hold on.

Paul Vixie: I was about to ask Marla how we would go about picking one of these since they’re so similar. She said I should let her continue.

Marla Azinger: So what I’m going to do is take you through the subsequent allocation, and then actually it gets to a comparison and then to kind of a polling of what would you prefer and then now let’s look at details, if you prefer any of them. Or if you stop at that point and say no, nothing, well, then we stop at that point. IPv6 subsequent allocation. So I do want to thank the community, because this came about because the community finally gave some input, which I was able to turn into something quick enough so we did have comparisons. And it made a cleaner proposal be borne to PPML and the whole process. I do want to thank everybody for the input they gave. And we do believe this one’s closer to the mark than the 6rd one was.

So this is a draft policy for subsequent transitional technology. This one you can probably still read up on the big slide, which is a bonus, because it’s not obviously as lengthy as the other one. So this one, you have the section, modify 6.5.2.1 Subsequent Allocation Criteria adds the following sentence: Subsequent allocations will also be considered for transitional technologies that cannot be accommodated by, nor were accounted for, under the initial allocation. And justification for the subsequent subnet size will be based on the plan and technology provided.

So justification for these allocations will be reviewed every three years and reclaimed if it is not in use. Requester will be exempt from returning all or a portion of the address space if they can show justification for need of this allocation for other existing IPv6 addressing requirements be it native v6 or some other v6 network technology. This isn’t perfect. But it at least was cleaner. We think it’s a cleaner start to really having a discussion that gets somewhere in the community. We just added the one top line to the instructive example. Mark, did you have something to add?

Mark Townsley: Just to reiterate, I actually helped write a lot of the first one. And, gosh, the second one’s much better. Once I looked at it I was like: Forget this. I like the short one, too.

Thank you, Marla, for writing the short one and submitting it. I don’t know what I’m doing on these policy things.

Marla Azinger: Thanks, Mark. So we’d like to keep the instructive example with the one sentence that was added but add the one sentence to the top, actually, to underscore that 6rd is just one such mechanism that can justify a subsequent request. It’s not what it’s all about. It’s not the only thing it’s about. So we have two draft proposals. And this is a simple comparison where the first one that we put out, the 2010-9, the con: Policy language isn’t crisp and it’s not succinct and it’s too specific to 6rd.

The second one, 2010-12, it’s definitely more crisp and succinct, and the 6rd is mentioned as a justification example. It’s not all about 6rd. The con: Mailing list feedback that it is missing strong policy language on allocation size and limits. And also term: How many times you review it, was also more discussion. I don’t know if that ended up on the PPML or not. There’s been, I think, more hallway discussion this week about it than we’ve seen on PPML. So how to proceed? What I’d like to do at this point is just agree on whether this policy – one of the policies should or should not be accepted to work, and then move on to polling the room on different aspects of the policies such as, you know, size, you know, does it matter, what do we want to do with it, and then how many times do you review it, aspects – so there’s other aspects that we would then walk through if we can at least come to a consensus on which one would we like to work with. So which draft? This is the same slide, but I just thought that maybe it would be useful to look at.

John Curran: Paul, you can come moderate.

Marla Azinger: And let me show you something real quick. We’re not going to discuss it, but I’m just going to show you these slides so that you know where – if you do think one of these works to work with, where we’ll go after that. We’ll look at size. We’ll look at review terms. And if somebody brings something else up, obviously we’d discuss that as well.

Paul Vixie: Thank you, Marla. Let’s – wow. There are a lot of people at the queue. This is cool. So we do have two similar proposals and we do have to give – at the end of this we have to give the AC some guidance about sort of which one to pursue. They probably will not interpret anything we say as please pursue both, but that means that when you begin your question or comment, you might say which proposal you’re talking about just to try to keep this straight. Let’s go with Lee.

Lee Howard: Mr. Chairman, move to divide. I do not know how to consider two things at the same time.

Paul Vixie: Move to divide.

Lee Howard: If you would like to open that item for discussion, I will offer that we could consider the second proposal. We could go out of order on the agenda, consider 2010-12 before considering 2010-9.

John Curran: He wants to know which of the ones we’re talking about first.

Tony Hain: Might I offer just an addendum? This is Tony. Should we ask the overarching question of do we need anything at all before we even discuss the two of them? If everybody objects to both out of hand, then there’s no point in spending a lot of time on order.

John Curran: May I confer with you for a moment? (Discussion between Mr. Curran and Mr. Vixie off microphone.)

Paul Vixie: Rather than divide, we’re going to conquer.

(Applause.)

Paul Vixie: So per John’s suggestion, since these do overlap, but one is sort of a superset of the other, before we move on with Tony’s suggestion about do we need this at all, I would like to hear from – and you may – the current queue might have to step aside, I would like to hear from someone who wants the first proposal, -9, in preference to the second proposal. If we could get somebody to speak up for that.

John Curran: If you specifically want 2010-9, that’s what you want to have happen, come speak.

Cathy Aronson: I totally get that. This is Cathy. The question that I would have is what other technologies were presented that made the second proposal happen? Because none of them are listed. Like is there some specific technology, or is it just there might be one?

Paul Vixie: I’m sorry, Cathy, we’re not taking clarification questions on this matter right now.

John Curran: Are you saying you have to have 2010-10 – 2010-9, Cathy?

Paul Vixie: Is there a possibility this could affect your desire to have -9?

Cathy Aronson: Yeah.

Marla Azinger: There is no known one that I’ve been told personally. It just was a common comment by several people that they were worried that – because v6 is in its infancy and we are still making several things to make it happen and work, that what if – it’s the what if scenario. So what if there is another technology? Alain, do you know of another technology?

Alain Durand: I’ll answer speaking as the chair of a softwire working group at of IETF where this is being developed; this is currently the only technology that will require space. We had a bunch of transition technology. Many have been up and down. This is one that does a lot of tracks right now. There’s nothing other in the working group that required any space.

Marla Azinger: So it was to satisfy people that were concerned about other. . .

Cathy Aronson: I would tend to be more in favor of a simplified version of -9, then, because at least it’s for a technology we know and we’re not just trying to leave it open for anything that might come along.

Paul Vixie: Thank you, Cathy. Leo.

Leo Bicknell: Leo Bicknell, ISC. I prefer -9 for a very similar reason. I believe that -12 leaves far too many doors open for future bad ideas that could come along and essentially bypass the policy process. So I prefer -9 because it is specific to a single technology.

Paul Vixie: Far left.

William Herrin: I’m not speaking about -9 in particular; I’m waiting for the folks –

Paul Vixie: Your name, please.

William Herrin: William Herrin.

Paul Vixie: You’re not in line for -9?

William Herrin: Not specifically, no.

Paul Vixie: Owen.

Owen DeLong: Owen DeLong, Hurricane Electric, ARIN AC. I think -9 is a much cleaner proposal. I think the language is much better and that it has a much better chance of providing useful guidance to the staff and better policy in general. So I would rather see -9 than -12. I think trying to make things generic where there’s no actual need is sort of an absurd exercise in bureaucracy.

Paul Vixie: Yes, sir.

Lorenzo Colitti: Lorenzo Colitti. Not directly commenting, but in reply I think what might be useful is to focus on what we want to – the properties that we want to guarantee, and then something that’s generic but can guarantee the properties we care about in both the 6rd and in other cases is I think more useful. So basically it’s - if it’s clean, then let’s make the other one clean without losing generality where we can.

Paul Vixie: So we have some yeses, some nos, some none of the above except all of the above, and we have not clarified our situation at all. Therefore, we’re going to take Lee’s suggestion and divide. Let’s hear pros and cons about -9 independently of whatever your thoughts are on -12. So we are starting with -9, which is what is on the schedule right now. Anyone in the queue who wants to speak about their opinions, comments, questions about -9, for or against?

Wesley George: Wes George, Sprint. I don’t know how much of this is applying specifically to -9 or specifically to -12, so I’m just going to say it and let people interpret it as they will. The first question I would have – we clarified with Leslie earlier, and this may kind of be a question to her – is if someone were to come today with plans to deploy 6rd and say basically I don’t have enough space to do this, are you saying that they would be denied? Or has ARIN already denied a request like that? And, if so, I think we actually might be able to generalize it a little bit from the perspective of how do I get more address space if I can show that I have a plan to do something that’s going to require more address space if I don’t meet the HD-Ratio yet.

There are – I think beyond simply 6rd there are going to be other people who show up with a business plan that says: Look, I want to build a wireless network. I need another network to do that. Yes, you might be able to do multiple discrete networks or you might be able to build a new ORG ID or whatever, but since there’s been concerns raised about doing that in this case, maybe that’s the problem we need to solve, is how do you come forward with a business plan that says I need more address space when the block I already have isn’t big enough but I don’t meet the HD-Ratio.

Paul Vixie: John, please.

John Curran: Acknowledging that might be a problem, if that problem were fixed separately at some future time, you’re saying we don’t need either of these?

Wesley George: Well, possibly.

Would you leave this mic on, please?

I think possibly the – you might be able to solve the problem more generally. And that was what I was kind of in favor of, is rather than saying let’s do it just for 6rd because that’s the one thing we know about, you know, I think I’d rather not be back in 12 months talking about the same thing again with a different technology and have four or five different little subtexts that cover different things that have come up over time, when what we’re really pointing out is a hole in the existing allocation policy. Sort of the related thought to this is free.fr is the one that gets held up as the shining example for 6rd. How did they get their allocation? Is RIPE’s allocation policy that much different, that much more lax that that’s how they were able to get the policy? Or is there some sort of a policy that’s different there? That would be the thing we need to fix.

Rob Seastrom: I’m Rob Seastrom. I work for Afilias. I’m on the ARIN AC. I would like to make two comments, one of them specifically not in support of -9 and the other germane to both -9 and -12, if that’s okay with the Chair.

Paul Vixie: Be clear when one stops and the other starts.

Rob Seastrom: So I liked Mark’s – this is about -9. I liked Mark’s diagram showing specifically how 6rd, which you can think of as private replicated 6to4, works. If you ignore theoretical extensions for a hypothetical ISP that doesn’t have deaggregated space, the IPv4 address of the end site gateway will end up embedded as a 32-bit field in the IPv6 address.

So your end site address is going to be exactly 32 bits longer than your allocation. So a /24 gets you a /56. A /28 gets you a /60, et cetera. I’m concerned that this will end up being an end run, de facto, end-site policy and will result in the shrinking of what’s expected as normal and traditional in the market to a /60, which will do harm to the IPv6 ecosystem and the concept of plentiful subnets at each end site. So that’s the end of my comment about 2010-9.

My comment about 2010-12 and 2010-9 is when we talk about transitional technologies; the implication is that the need for the addresses is temporary. The notion that we can reclaim or sunset space that is allocated out of normal blocks is kind of unsupportable. But Leo Bicknell pointed out to me that we do have an existence proof from the 6BONE, which was from 3ffe: : /16, that it is possible to do this in an isolated netblock. So I submit that the right way to handle these temporary and transitional allocations is to get a separate block from the IANA, an allocation, say, for instance, of 5fF00: : /8, that would – and I chose that prefix because it sends the right message about the temporary nature of this – divide it up between the RIRs, have the instruction be to allocate from that space with the understanding up front that in 15 years it’s going away. And as far as a default allocation out of that, I would hope that the default allocation would be something that was large enough, say a /24 for a 6rd user, that would not adversely impact the end site allocation. But I do not support either of these proposals as written.

Paul Vixie: Thank you, sir. Further down the table.

Dan Alexander: Dan Alexander. To reply to the previous comment about there’s other things beyond the transition technologies that was one of the – there were some that considered -9. That was one of the shortfalls, because it was strictly limited to 6rd. And one of the problems that we’ve been encountering all this week is the current thinking in the room right now and we’re discussing, oh, /48s to every end site and we’re evolving off of conversations just a year or two ago about basing the HD-Ratio on /56s, and the reality is this is all a work in progress.

So the hole that you mentioned in the policy right now is what do you do with the people who have gotten a v6 allocation. And the evolution of thinking has changed as far as how v6 should be deployed, and they have no mechanism to go back and fix the thinking from the past. And that was one of the drivers of -12. While it’s – there’s some wording that doesn’t help in there, the intent of 12 was to allow that fix of what’s been done and just expand the address space that’s been given.

So it’s – I kind of wrestle with and at some point we’re talking about one policy where we’re hearing, oh, it’s not – it’s not restrictive enough or it doesn’t define the parameters well enough, when in reality nobody in this room truly knows the parameters. And in the same breath we’re also talking about the near infinite amount of address space; that we should just give everybody a /48. So we’re kind of contradicting ourselves a little bit, I think. That’s why I’m actually more in favor of working on something along the lines of -12.

Wesley George: If I can respond to that briefly to close my discussion. I’m in favor of looking at this from the perspective of actually adding on space to the end of an existing allocation. We had discussion in previous meetings about sparse allocations and the fact that we wanted to be able to give people the space so that if they come back later and realize that they need more space because either they guessed wrong in the way that they did their initial determination of how much space they needed in their initial request, or something like this comes along, with the assumption that temporary’s probably not real likely, this may be a cleaner way to do it, to say basically we’re going to extend this space, we’re going to extend the bit length of what we’ve given you, you now have more space, and if at some point in the future you realize you don’t need as much of it anymore, you can give it back. But if we’re saying that the space is as infinite as it is and we ought to be giving people more space in order to compensate for the fact so that they only have to have one block ever and we can do aggregation and we can do all of these things, then it makes much more sense to have a more general policy that is less restrictive in terms of space that you can get and the ways you can add on to it where it makes sense to do so than it is to go and carve something out as a special block that may or may not be temporary so that you end up with more and more deaggregation and more and more of the same kind of IPv4 stuff where I have multiple blocks, not because they’re for different purposes, but because I couldn’t get enough space in one block to make it all one block.

John Curran: So the only comment to be made is that the staff will need guidance very clearly if we’re to consider transition technologies or temporary technologies a valid claim for use of address space, because otherwise everyone says, well, you know, the block, hey, I’m doing transition now, give me a transition block. And if that’s the case that an additional allocation is immediately qualified for by making that claim, we would need to understand, okay, that’s going to be a normal allocation out of the normal block pool. To some extent because of the ease at which someone can request a block, it’s not necessarily a normal block and you probably do want it subject to being clearly identified and clearly reclaimed. Unless we really want everyone else to have a second IPv6 block everywhere.

Paul Vixie: Mr. Herrin, far left.

William Herrin: William Herrin. I think there’s perhaps a hidden gem of wisdom here that maybe in this early phase of IPv6 we should be placing a lot more weight on demonstrated need for addresses and a lot less on prior competent use of those addresses, at least until we gain operational experience with how we’re actually going to do things.

(Applause.)

Paul Vixie: Thank you. Alain.

Alain Durand: Alain Durand, Juniper Networks. So stepping back a little, what it seems to me that is happening is that if you’re in Europe you get space and it’s easy to deploy v6 with 6rd, and if we’re in the States or North America we are fighting the policies and in the end ARIN gets in the way of getting v6 deployed. That’s what it looks like. Now, I’ll make another observation that this seems to be tied to the fact that we have policies that are very, very specific, way too specific, in my opinion, and they do not leave enough room to staff to make interpretations. When all this started about six, nine months ago, I had a discussion with staff saying, okay, if we wanted to get more space to do 6rd, what will happen? And the answer was: Uh, there’s no policy; we don’t really know. And I would like to offer this as the community to think that maybe we should stop making those policies that are way too specific.

Paul Vixie: Thank you. Jeroen.

(Applause.)

Jeroen Massar: My comment is in line with that.

Paul Vixie: State your name, please.

Jeroen Massar: Jeroen Massar, IBM, SixXS. In RIPE region it’s very easy to get address space, like German Telecom, France Telecom have a /19. You’re debating a /28 here for transition technology, which is really useful. And this address space can also be used possibly for other transition technologies. But as Alain – Mark already mentioned, there are not many other alternatives for this. There is also currently, as far as I also know, not a single other technology in the IETF meeting or in the agenda or anything. And it is a very simple one. It’s scalable and it will work. That’s my segment.

I’m, by the way, in support of 2010-9 as more or less written. What Robert Seastrom mentioned as sort of a special block for these prefixes might be a good addition so that people have an incentive of actually finalizing their transition maybe so that it will end at one point. But, as you know, on the Internet everything will take ages. So it’s maybe also not a good idea.

Paul Vixie: Thank you. David.

David Farmer: David Farmer, University of Minnesota, ARIN AC. Originally I was thinking this was an either/or situation. I’m actually going to speak in support of 2010-9 and will later in 2010-12. I think we need to define – in order to make people happy; we need to define a policy for 6rd and what the community thinks is acceptable use for 6rd. And then we also need to correct the situation independently of what happens when I have a new need that I didn’t anticipate when I got my first initial allocation. And they’re kind of linked at the hip, but they’re kind of not linked at the hip. So I kind of like doing both of them.

Now, whether they have to be two separate pieces of text that is a different question. But there are really two ideas here. It seems to be coming out into two ideas here. There’s the transition issue, but there’s the associated idea of new business model came along and I already got stuff based on my old business model and how do we fix that. I think that’s an equally important thing. And so that’s why I’m saying is there really – I was thinking it’s an either/or, but I think it’s a both.

Paul Vixie: Okay. Lorenzo.

Lorenzo Colitti: Lorenzo Colitti, Google. I don’t have a lot of experience reading policies and thinking through the implications, so what I can say is that I support the general idea of something that will let us deploy technology that’s probably going to be useful.

I think that this is a replay of a conversation we had in the hallway yesterday. I think that we need to recognize that this is crunch time for v6 deployment. And there are several big players that actually need to get something done now, because we have another year to get something out there, if we don’t want the Internet to go to carrier grade NAT and all sorts of things that none of us likes. So we have to think a little bit outside of the box of the stewardship issue of just preserving address space. We have to I think take the big view and say we’re all in this together, we need v6 deployment to be successful. We have to think that if v6 is not deployed, then it doesn’t matter how much address space we conserved.

And so really – Mark presented the data – according to our data, v6 power is about – at 6rd is by itself responsible for about 80 percent of the Internet that we see today. It is the single residential deployment of IPv6 that we see today. Having looked at access technologies for the Google Fiber to the Home project, I know how hard it is to deploy native IPv6 on DSL and on other technologies, because the vendor gear simply isn’t there. And ISPs that have deployed these technologies in large numbers today are facing an impossible situation. And this is the way out.

So, with that, I don’t know how to treat the language, because I’m not a specialist in that. But let’s try to take the broad view. If we’re worried about saying, okay, we created a loophole, now everyone says “I’m using 6rd; I want a /28,” then maybe we can just limit that to people who got a /32 before this policy was instituted and sort of create a grandfather clause or – I don’t know what would work. But I support the general idea, and I think we do need to make something work sooner rather than later.

(Applause.)

Paul Vixie: Far left microphone.

John Springer: John Springer, Inland Telephone. We have as a bone deep organizational policy the idea that we need to promote the adoption of IPv6. So the first thing we need to do is not penalize our pioneers. Then when I look at my own particular situation – I have a /32 allocation – this 6rd stuff looks very tasty to me. If I’m going to have sort of – if I’m going to get caught up in a “time is of the essence” situation here, maybe I need to turn that back in and ask for something else.

Marla has a problem that needs to be fixed. She can’t be the only one. So we don’t need to – in my humble opinion, I don’t think we need to quibble about this or that and delay and push this out; we need to give guidance to the Advisory Council and say please do something about this. So I don’t believe – I don’t believe that the idea of going either/or on this is the way to proceed. I think we need to make it so that people that have initial /32 allocations have room to do 6rd.

Paul Vixie: Let’s go to the remote participant.

Stacy Hughes: Stacy Hughes channeling Joe Maimon: Neither. Thank you.

Paul Vixie: Wow. Front microphone.

Andrea Cima: Hello. Andrea Cima, Registration Services Department at the RIPE NCC. As a few people have mentioned RIPE NCC allocation practices for IPv6, I just wanted to clarify that we do not allocate extra address space for 6rd. I just wanted to clarify that.

Paul Vixie: Thank you. Leo.

Leo Bicknell: Leo Bicknell, ISC. A couple of quick points. I am a firm believer that if we actually gave every ISP who wanted a /3 or whatever it is we could do, because the numbers are big, that we have also encouraged – because the number space is big – things like sparse allocation and other ways of using the space.

I think no matter how big of a block we gave people, there would be somebody in the room who would be telling us now that they don’t have space for 6rd because of the way they allocated. So I think that is a very real danger in how people are using this space. The new numbering opens up new capabilities. I also want to point out one of the reasons I think 6rd is different is that one of the reasons we need the size prefixes we do is because of the mess that was made in IPv4.

If every ISP had aggregatable IPv4 space, so they all lived mostly in /8s and /12s, depending on how big you think some of them are, as we saw in the demo, you would need fewer bits to make a 6rd prefix. So while I will occasionally argue with Owen we have more numbers than we know what to do with at lunch, in this case we’re eating up numbers not because we have them or because we think it’s good for sparse allocation or all that, we’re eating them up because of a mess we made in the previous technology. And that seems to me a very dangerous and very different precedent than the other arguments we have of whether or not 2 to the 16 is a big number or 2 to the 64 or whatever it is. So that’s why I’m very cautious about allocating these large blocks.

Now, to the point a couple people made about existing folks having this, R.S. kind of channeled an idea we talked about earlier, said it more eloquently than I could have, of having a separate top-level prefix for this. I think that’s key for a couple of reasons. First of all, as many people have heard me say in the past, temporary isn’t. I know of nothing temporary in my world. If it’s not pulled out the same day, it’s there for the next 50 years. So if we’re going to have different little blocks in all the different RIRs and my access list has to be 37 lines long to make this all go away, it’s permanent. If it’s in one block – we did it with 3ffe: : . I don’t know how; it was a bit of a miracle. But if we have it in one block and you can make it one line, I think we’ve got a fighting chance. And it also means that I would then have no problem that if somebody with a /32 today came in said I have to have 6rd, give them a /24, whatever it is out of that, overlap it on your existing – I don’t care, because I think it really can be temporary – and the industry can bring power by filtering later to bear to make it go away.

(Applause.)

Paul Vixie: Thank you, Leo. I’m going to be closing the queues shortly. We’re down to about our last 15 minutes. Far right microphone.

Carlos Martinez: This is Carlos Martinez from LACNIC, although I’m speaking strictly for myself now. I want to sum up things that several people have already said. If I could vote here, I would definitely support -9, specifically because it’s 6rd dependent. I fully agree with the gentleman who said it will prevent future bad ideas. And I support the general idea, just as Lorenzo. And I believe – for example, in our region we allocate /32s for customers. And I find it really hard to believe that they need more space. If they need more space, it’s because their numbering plan sucks and they definitely should redo it. And this is a good time to redo it. Probably a /32 here is, I don’t know, a /28 or /24, I don’t know, but I think the same idea applies. Thanks.

Paul Vixie: Thank you very much. The queues are closing. Closed.

Kevin Oberman: Kevin Oberman, ESnet. I listened to Leo’s arguments, and all of his whys I agreed with, except I thought they were whys for the other side. I was further baffled by it. Frankly, I’m sort of in Owen’s camp and I’m not terribly worried about running out of address space unless we are totally insane about the things we do things. And this is not totally insane. It does strike me that this is really caused by the lack of a policy for getting additional space for existing people and therefore should be in the language restricted to people who already have address space. They’re the ones who have not yet reached the HD-Ratio to get new space and they can’t do 6rd without new space. We should give them new space.

There’s no reason someone coming in new shouldn’t be able to put forth a proposal that he needs this space and he’s going to be doing 6rd so he needs this much space. That’s a separate issue. So this should be restricted to additional allocations to people – or assignments, rather. I’m sorry. And I think, though, that they should be contiguous when possible to existing ones and we should not worry about them coming back. That’s an answer to a question from either you, Paul, or John. I don’t remember who asked it. I don’t have a problem with it. Once again, I’m not paranoid about running out of space at this point. We’ve got lots of room to screw things up, and I’d rather screw them up in a manner that does not explode the routing tables than in a manner it does. I still worry about the size of my FIB, and I always remember that IPv4 FIB entries are twice as long – I mean only half the size of IPv6 FIB entries. So we not only eat them up, but we eat them up even faster.

Paul Vixie: Tony.

Tony Hain: Tony Hain, Cisco. First and foremost we need something in this space urgently. We have people that are being told no, they can’t deploy v6. This is the wrong answer. So to echo the comment about not shooting the pioneers, please, let’s stop shooting the pioneers.

To echo some of Leo’s comments about not creating the mess we created in the past, I believe that if we go down this approach we actually create the mess. So all of the concepts about separate space actually expand the mess. There are issues about whether or not you want to have technology specific policy, which in general I think is a bad idea. I tend to prefer -12 over -9. But to a first order, I don’t think we need either. I think we need clarification that people who are our pioneers are supposed to be able to have enough space to go out and deploy. And if their business case says I need mumble for 6rd, that’s what it says. It should be expanded on their existing allocation and reviewed. When they’ve turned off the technology, if they haven’t used up the space for some other reason at that point, review does what the review does. But there’s no reason to have it be separate. Just expand their existing space to accommodate this for whichever size prefix they’re going to give their customers, review it in three years, and it either comes back or it doesn’t.

You don’t need a whole separate policy for this whole thing. You just need to be able to say I’m doing this, I need a /24 or /28, whatever it comes out to be, review it in three years, and it either comes back or it doesn’t. And if it doesn’t come back, it’s because they’re using it for something else, right?

John Curran: Just a question to follow-up. In general, if someone was doing IPv6 services and then they went on and bid IPv6 satellite services and wireless and a whole bunch of things and they kept using their allocation for different purposes, all those would be eating down their supply and eventually they’d get to the point where they’re at 70, 80 percent, or HD-Ratio, and they say, oh, the next project doesn’t really fit. It’s too tight. We need another allocation. And they have no trouble getting the next allocation because, while all their other projects used up pieces and now they’re near the end, Leslie and I would look and go, yeah, they’ve used it, give them the next block.

This is not just another application. This is an application which, because of its encapsulation of addresses, its block size, it is going to use several orders of magnitude more space in many cases than the provider has. So I guess what I’m saying is that I understand your philosophy, and I agree with it. It does say when will ARIN listen to someone who says I need an additional allocation and I haven’t used my last one, but my additional allocation is so big and so huge you have to ignore my previous utilization. We’ve agreed to do that once for transition technologies, or at least that’s what these proposals would have us do. We can’t do it in general unless the community tells us to do it in general.

Tony Hain: I appreciate the question because that reminds me I forgot my fundamental point. Stewardship does not equal strangulation. Currently the mind-set of stewardship in this particular region is strangulation. And stewardship is judicious management of the space. So none of the providers in this region should have /32s unless they have zero customers. So that whole block of people that rushed out and got a /32 shouldn’t have had those to begin with; they’re in the wrong size blocks to start with. So they should have had not necessarily /24s that they might need for this, but, again, do a /24 for now, review it in three years.

So I’m saying 2010-12 is the minimum bar. We need something much better, but we need it now. And this is the only thing on the table that fits the space.

John Curran: Thank you.

Paul Vixie: Let’s go to Chris.

Chris Morrow: Just a quick question actually for Tony who walked away. I don’t understand if you say we’re going to allocate the space – I don’t understand what staff would be looking for here. You’re going to allocate some extra space. You’re going to change 2010-12 to say subsequent allocations are okay if you come up with some sort of justification for the reason that you need it, the distinct new reason. Then you say three years later we’ll review it and then we’ll decide to give it back. What are they reviewing for?

Tony Hain: Are you using the technology you claim to be using to acquire the space to begin with. If you made it through the transition and you’re doing something different and you’re no longer doing transition, then that’s part of the review. I’m done with that. That’s the level I’m thinking of.

Chris Morrow: I guess I heard your initial comment as sort of it’s just a subsequent allocation, not a subsequent allocation for transition technology.

Tony Hain: Fundamentally that’s where I’d like to go. And the fact that the transition technology requires a bigger block than you might otherwise need, it’s a business need for now. Your business need will change in three years. Whatever it is when the review comes up, that’s what it is.

Paul Vixie: Left microphone.

Mike Joseph: Question and then a comment for staff. If I were to come with having no previous IPv6 allocation as an LIR, the NRPM says that requests for larger allocations reasonably justified with supporting documentation will be evaluated based on the number of existing users and extent of the organization’s infrastructure. Would I be approved if I requested a /24 to be able to number /56 end sites for customers using 6rd today?

John Curran: So the question is if you come to us looking for a request and the size of your request is not a /32 but much larger because you’re saying your purpose is 6rd, that’s your initial purpose.

Mike Joseph: Yes, correct. Would that be approved?

John Curran: I understand my thoughts on it. I want to make sure I’m right. Leslie, if someone asked for a /26 and they said – a /24, say – and they said, Here’s our purpose. It’s going to be – this is under current policy – it’s going to be to serve these customers, allocating them a /56 each and 6rd technology, would we give them a /24?

Leslie Nobile: I was just thinking about that, and under existing policy I do not think that we would give them a /24. Because it says it’s based on customer base and network infrastructure, current existing.

John Curran: We actually do evaluate plans to see that they meet those criteria, and you would be creating new infrastructure to do that. So right now we don’t have a way of telling that. You haven’t proven – we have no idea whether that /24 would ever actually be used.

Mike Joseph: And we need to fix that, too, because I think – I agree with the previous comments that we need to address the issue of needs based allocation rather than ratio based allocation, and I think that’s the most important gist of these comments. And just to close, I would support making sure we come up with an answer quickly for 6rd, and I would support that along with /24 boundaries. As far as what block that lives in or which proposal gets us there, I’m somewhat ambivalent.

Paul Vixie: Thank you. Can you state your name?

Mike Joseph: Mike Joseph, Google.

Paul Vixie: Front microphone.

Mark Townsley: Hi. I’m Mark Townsley, Cisco. In terms of all the – Kevin, I believe, who was before me, I reiterate everything he said. I appreciate everything he said. I want to make one technical comment, though, about – that that was in respect in terms of size and all that stuff. I don’t want to go there.

One comment about the idea of allocating a separate special 6rd block, that to me sounds like ARIN, by policy, would be trying to inch 6rd towards 6to4, somewhere closer to 6to4, which does operate in its own block. I think that’s the wrong technical solution. I think that the point I made in my presentation of 6rd outside the service provider looks, smells, and feels like native IPv6 is very important to the operators, and trying to not let them have that, strangle them and not let them have that for some reason, is a bad idea. We should not make 6rd 6to4. We want to get rid of 6to4. Thank you.

Suzanne Woolf: Suzanne Woolf, ISC and veteran policy hobbyist. I’m looking at this and I’m thinking, first of all, I am against promoting today’s bad ideas against tomorrows. I really don’t like the idea that we might be promoting 6rd now and we might have to go through this to promote deployment of technologies that may in fact be more conservative of address space and more useful for transition. So let’s throw out talking specifically about 6rd and fix 2010-12 to do the right thing in providing guidance to the staff, as John called out, on how to support justification for transition technology.

Paul Vixie: Michael.

Michael Sinatra: Michael Sinatra, UC Berkeley. If we think that these transition technologies are going to be temporary, then we should use a separate address block because – I agree with Rob in that case – because it will eventually force us to get rid of it. It will make it easy to get rid of and it forces us to get rid of because it pollutes the routing table and we will have good incentive to get rid of it at a certain point. If we don’t think they’re temporary, if we think this is going to stick around, then let’s expand the existing allocations.

Paul Vixie: Rear microphone.

Dave Barger: Dave Barger, AT&T. We currently have I guess I could say over a hundred separate IPv6 initiatives on the table right now and supporting 40 million plus customers, and we have two /32s. You know, one that was obtained under one ORG ID, one under another one. And 6rd is in the plan, you know, as some transitional solutions. Knowing that we want to get /28s to support these 6rd plans along with a plethora of other projects going on there, we got a big plan. We need a lot of address space.

Currently when we go to ARIN and ask for more v6 space, you know, we’re faced with the fact we have these two /32s deployed in our network, obtained a long time ago, but we’re not meeting the HD-Ratios on those, so what do we do. And, again, I just want to reiterate what a lot of other people have said, is we need to be developing plans that make it easy to get v6 going. And we can argue the point a year and a half from now again. I mean, we’re always going through policy revisions. But let’s make it easy for the large providers to get our v6 going. And, I mean, if I have to go through six iterations trying to justify a /28, that is detrimental to getting our programs going. So we need to be developing policies that are based on need. Obviously we need to provide sound business plans and justifications for why we ask for X prefix size, whatever it might be, but it ought to be, okay, fine, that looks good, here it is, get on and get v6 done.

So I’m not in favor of 2010-9 because it is technology specific. I think a comment was made earlier that 2010-12 might be a good start. And I’m inclined to agree with that, but something needs to be worded to make it easier for the service providers to get those allocations and get them quickly. Just because we got a /32 initially, that we didn’t have the foresight to ask for a /24, that should not penalize us now.

Paul Vixie: Thank you. Cathy.

Cathy Aronson: Cathy Aronson. I have a question, and this has always just been a bug thing for me. So Mark’s saying “we can do it in Europe,” and the RIPE guy’s saying “we don’t have a policy for that. " So I’d just like to understand what the policy is in Europe and how it can be done in Europe without a policy.

John Curran: Is there someone from RIPE who would like to speak to that? Thank you, Andrea.

Andrea Cima: Hello. Andrea Cima, Registration Services Manager, RIPE NCC. I cannot go into the details of what the request was and how they justified it. What I can say is that if you come to us, if a member comes to us and says we want IP addresses, v6, fine, we want additional IPv6 address space in order to do 6rd, that additional address space has not being given out. If someone comes and demonstrates the need in a different way, then we get the address space. But I cannot go into details on how a provider justifies the needs to us. You know, and there is –

Cathy Aronson: It’s just that we constantly face this in this region that RIPE is so much better and the policy is all encompassing, and then but there is no policy. So I’m just mystified.

Mark Townsley: May I comment on her “but we can do it in Europe” statement?

Paul Vixie: Go ahead.

Mark Townsley: So the fact is for – I don’t know what goes on behind the scenes, absolutely, but, anecdotally, right, I’m working with customers, lots of service providers and residential gateway members and chip vendors for those residential gateways. 6rd is ready, locked, and loaded, ready to go. And however it’s done, through whatever black magic, nobody’s coming to me in Europe and saying, oh, we didn’t get our space, even though multiple service providers have deployed or are in trial and planning to deploy. It just hasn’t come up as a problem yet.

There was a discussion on a mailing list it might be a problem, and then I was waiting for somebody to say, Mark, this is a nice thing that you’ve got, but I can’t get the space. It didn’t happen. But at least two, three people in this community have come to me going, oh, my God, how do I get around this? It’s the only one I have a problem with. And I’m just – I’m not a policy specialist. I’m just trying to work with the customers here. I don’t hear it in the other regions. I don’t know why. Okay? I only hear it in this region.

Andrea Cima: Well, what I can say, what I can add is that IPv6 – it’s based on, for example, current customer base. We base IPv6 allocation on that, which is, as far as I understood, the same thing which is done also in the ARIN region.

John Curran: I can actually –

Paul Vixie: What are you trying to do? Okay. I see that we have Lorenzo and someone else who added themselves to the queue after they were closed. This is interesting. So let’s go with Aaron.

Aaron Hughes: Aaron Hughes. First I want to say I certainly support some flavor of transitional space, preferably a separate chunk that is temporary. Additionally, it’s very clear that we need to solve somehow going back for subsequent requested space. And I wanted to say I heard a few comments that said /32s were enough, and I heard a few comments that said /32s are clearly not enough.

I want to remind everybody we told the community the wrong thing to do for subnetting initially and said things like one subnet gets a /64, more than one subnet gets a /48. You could quite easily justify 4096 customers in a given region. You could quite easily say I have, oh, nine or ten regions, let’s cut them into 36, leaving a total of 16, or maybe 15 if you use one for your own infrastructure, and then run out because you grew before you grew the number of customers with v6 and certainly not meet HD-Ratio. We did this as a community together.

Lorenzo Colitti: Lorenzo Colitti, Google. Sorry for showing up again; I’ll keep it short. Number one, I have seen one – as a v6 operator, v6 content provider, I have seen one transition mechanism provide production quality v6; that is 6rd. And the answer that was clearly given from ARIN staff ten minutes ago was you cannot run 6rd in the ARIN region because our policies don’t allow you enough space to use it. So I think this is a case of let’s not throw out the baby with the bath water. This is the only thing we have working. We’re running out of time. Let’s try and figure out a way to do it without spending too much address space on it.

Paul Vixie: Thank you. John, would like the privilege?

John Curran: Can I make a statement, a comment on that?

Paul Vixie: Yes.

John Curran: Unless you have tens of millions of existing customers and a plan that shows that that existing base is going to become 6rd, then the current infrastructure test and current customer test wouldn’t let us give you the allocation. You can get a /32 very easily, but wouldn’t let you get an allocation that is of a size that’s a thousand times bigger or a /24, for example. That would be ARIN’s interpretation of it, because we’re supposed to base on what it would take for that customer base. And so it may be that we are – where is Tony? – strangling, maybe that we’re strangling, but we’re strangling per your instruction and we’ll continue to kill on and on.

So to the extent that you do want something allocated that doesn’t tightly comply with current customers and current infrastructure, yes, a policy like this would probably be desirable.

Lorenzo Colitti: To respond just to that, perhaps we can consider the alternatives. Alternative A is no deployment at all of v6 because simply can’t get the space, throw up our hands. Alternative B is we’ve got a /32, we’ve got two, we can use one of them for 6rd and we’ll be able to /64 to each subscriber. I really don’t want that to happen because there are gateways on the shelf today that use multiple prefixes for multiple network interfaces, guest network, real network, and that is really something we want to preserve for v6 users. So think of the users as well. And maybe it is – maybe it’s the case – and I’m here, shoot me here – that at the beginning we have to make some mistakes because we have to get this thing going.

Paul Vixie: The queues were closed a while ago. So no more, please.

So we have reached the point where we need to start asking questions and holding up hands. We have not reached the point where I’m totally clear on what questions are going to be useful to the AC, but I’ve discussed it with Marla. We have an AC member who might want to weigh in.

David Farmer: David Farmer, ARIN AC. One of those questions I hoped is I really, as an AC member, need some guidance on whether people think 6rd should be temporary or permanent.

Paul Vixie: So this is the question about should it have a dedicated prefix?

David Farmer: I won’t go into the solution. It’s just whether it should have to come back or not. I don’t want to specifically ask that. I just want to know what the mind-set of the community is. Do we want this to come back eventually? I think the AC can figure out the mechanism if we know what the will of the community is.

Marla Azinger: You could easily also ask if they can justify using it for other v6 purposes as opposed to handing it back.

Mark Townsley: One thing. I didn’t get into my presentation the technical aspects of 6rd alongside native and the various ways to transition from 6rd in native and do it together. It would have been another 15 or 20 minutes of presentation. But understand that native and 6rd can exist alongside in the same block and there might be reasons for doing that. So the existing language in both, I believe, certainly in -9, talks about review after three years and if there’s a sufficient need. Review after three years and if there’s sufficient need.

In terms of temporary, that’s fine with me, but I mean to say – I don’t know how the policy stuff – some people don’t like that. I don’t know. But the – nobody is doing 6rd because they would rather do native. But they can’t. Right? So I think even I want 6rd to be temporary, and I’m the one getting it in the Cisco products and trying to sell it to you. I want it to be temporary. Okay? I will say, yes, should be temporary. But do I want that to translate to ARIN putting it off into a separate block and pushing it more to 6to4? Absolutely not. Okay? Just to be clear.

Paul Vixie: Okay. So in the absence of wisdom, we’re going to do for and against on each of the two proposals, recognizing that almost no matter how these numbers come out, the AC has got a tough job.

These are interesting times. So on proposal 2010-9, all those in favor of this approach please raise your hands now. Can you enable the rear microphone?

Alain Durand: Could we be in favor of both?

Paul Vixie: Yes, it’s fine to be in favor of either or both, any combination. Okay. Thank you. All those opposed to 2010-9? Okay. Thank you very much. Moving on to the next proposal, 2010-12. All those in favor? And note again you can be in favor of both if you wish. Okay. Thank you. Now, in the final show of hands, those opposed to 2010-12? In addition to reading the numbers here, the AC will be using these numbers for their own guidance.

Owen has a question.

Owen DeLong: I’d like to also request for the AC that we get guidance on how many support doing something other than 2010-9 or -12 to enable 6rd.

Paul Vixie: No, I’m sorry. No. You can do that on the mailing list. Okay. So there are some really interesting other questions about how to proceed if not one of these or a merger of them, and you should watch the mailing list for that because that’s just a little bit too complicated to do in voice. David?

David Farmer: We’ve done the continue working on question before. Just as a possible suggestion. But I can understand if you didn’t want to do that one either.

Paul Vixie: We would have to do it twice. And maybe four times. So no. I recognize this is a great send-off to Marla to sort of lock her in a phone booth for half a day on her last day of school before she graduates. But I think we should let this end. Do we have numbers?

John Curran: Yes, we’re going to go directly to break.

Paul Vixie: With the reading of the numbers we’ll be out to go eat again, because at ARIN we like to overfeed you every two hours. All right. In the matter of 2010-9, of 146 people in the room, 28 in favor; 31 opposed. And in the matter of 2010-12, also 146 people in the room, 56 in favor; 17 against. Thank you very much. The cookies are waiting.

Marla Azinger: Thank you.

(Applause.)

IANA Activities Report

Barbara Roseman: I’m Barbara Roseman, and the last time I spoke with you guys I was the general manager of IANA and I’m not anymore. We brought in Elise Gerich, who many of you probably know from NANOG days. And she’s the VP of IANA. And I’m doing what we’re calling business operations. So you’ll see me less frequently than before, but still occasionally.

So I’m just going to run through some of the work we’ve been doing recently. We have a new IANA Whois server, we’ve introduced IDN ccTLDs, some work on the root DNSSEC, the AS global numbers policy, obviously.

Give you a little update on the v4 status as it looks from IANA, and a little bit of information on the root zone management and DNSSEC Key Ceremony.

So our new IANA Whois page. It’s meant to provide better answers to you guys for referrals to where to get the more detailed information, and we think it’s working pretty well.

We’ve started delegating ccIDNs. If you go to the Whois service, you can look things up under the U-label or under the IDN itself, the special codes, if you have them.

You asked us to sign the root, and we did. It took us a while to get it done, but it’s now signed and in production.

(Applause.)

Barbara Roseman: And that’s something that we do in partnership with VeriSign.

You can get information about the Key Ceremony out on our website, but there’s another slide following as well that talks a little bit about it.

The AS Numbers Global Policy is approved and is now policy. IPv4 status, which has always been talked about quite a bit, 12 so far this year. And we informally – this is really, really informally. We anticipate that we’re going to run out around February. And so that’s just based on the rate at which the RIRs have been coming back to us for allocations.

The last five blocks, as you know, will be allocated simultaneously. And we actually expect that it will be something like the last six blocks will go all together; that somebody will make a request for the last one, and that will trigger everything.

The Key Ceremony was held on 16 June of this year, and the next one is going to be the 1st and 2nd of November.

And if you were here at the NANOG meeting, our team mentioned that they’re changing facilities for where we did this. We did it on the West Coast last time. But VeriSign has sold off some of their infrastructure, so we’re going to be doing it on the East Coast this time. And at that time the KSR for Q1 of 2011 is going to be processed.

So I’ve been presenting on automating the root zone workflow for almost five years now. And we keep thinking “Okay, yeah, we’re right there. It will be ready any minute. "

And actually last year – this year we got as close as we could get. We were already set to go into production, and then some of our requirements changed. So we’re now looking at Q1 of 2011. And I feel like I may be here next time talking about this as well.

So it’s just one of those things that looks easy when you talk about it from outside, but once you start working on it, it actually gets very complicated.

And then in other news, we’ve made some changes to the multicast request process. Everyone who has a /24 of IPv4 unicast space also now has a multicast /32.

And we’ve done this by reserving a special – the IETF reserved a special block. And the way it works, as you can see there, is you have 234 /8 plus the 24 bits of your unicast address.

We’re introducing an annual review process for multicast address assignments in order to keep the data more fresh, less stale. And as you can see there, we’ve put in an extra box. There’s the registrant name. That’s who you got the multicast addresses on behalf of. And there’s who they want to have as their ongoing contact.

So this is in case the person who originally requested the addresses moves on, they can create a role account that can go to somebody else.

We’re trying to introduce this in a number of areas in the IANA registries, all of which require updating RFCs in order to get done. But it is slowly allowing us to clean up some of the older data.

And thank you. Any questions?

John Curran: Any questions?

(Applause.)

John Curran: Okay. Next up would be another RIR update report. Geoff from APNIC.

RIR Update - APNIC

Geoff Huston: Hi. My name is Geoff Huston. I’m with APNIC. And welcome to the APNIC report.

We’ve been really, really busy. And here’s a graph of how busy we’ve been. Oddly enough, we don’t give away ASN numbers in the Southern Hemisphere as much as you guys do in the Northern Hemisphere of this planet. Our ASN giveaway rate is about one or two per day, whereas here in the Northern Hemisphere you seem to ship about ten a day out the door. What do you do with AS numbers?

Stacy Hughes: Round them.

Geoff Huston: Wow. Very weird. We don’t give away many. We gave away a lot of IPv6. We’re very, very busy. And, gee whiz, we shipped some IPv4 addresses out the door.

That graph doesn’t really do justice to just how busy we’ve been. So I thought you’d like this one. This is the daily allocation rate of APNIC normalized to /8s per year for the last ten years. And you’ll notice that even the global financial crisis in 2007/2008 only lasted for about, oh, two months in the Asia-Pacific region.

This year has been incredibly exciting. You’ll notice we started 12 months ago when our allocation rate was the equivalent of just under five /8s a year. In September, the equivalent rate of moving IPv4 addresses out the door is up to eight and a half /8s a year. So we are really moving stuff in this region.

Predominantly there are two real pushes out there. One, of course, you’ll know about. It’s the device in your pockets. It’s iPhones. There’s also a certain amount of ADSL deployment, but it’s a matter of where. And the major build-out right now and the major booming economies are of course China, Korea. Less so in Japan, but Japan is more mobile. And India and Vietnam.

So, yes, growth is extremely high. We’ve also been pushing IPv6 in the region and working very, very hard at promotion. And we’ve done 541 delegations this year, which is up by heaps.

The other thing we’ve been doing, which is kind of novel, we got given Network-1 in March, in fact in February. And we asked our dear friends at RIPE to go and test it. So we gave them 1.1.1.0, because we thought it was kind of funny. So they put it up on their 10-meg link over at AMS-IX and a quarter of a second later melted it and handed it back.

So we then decided we really should test this and put it up on a 100-meg link, and that melted as well. So then we decided we had to get serious with our good friends over here at Merit actually and NTT in Japan, did exhaustive testing of this block and found that, yes, 1.1.1.1 produces a little over 100 meg all by itself, and second is 1.2.3.4, oddly enough.

But, oddly enough, there are other blocks as well that you guys just like to steal and lose and leak traffic onto the public network. So when we got given further addresses through this year, we thought, well, we’re getting good at this, so let’s test them.

The most recent tests have actually been done in Network-49 and Network-101. Who the hell decided to use 101.101.101.101? I know. Because I’ve now got that block reserved because you can’t use it. There’s just way too much traffic there.

But, yes, as we get blocks from IANA these days we are subjecting them to a pretty intense test to find out which is still toxic, the toxic remnants of people claiming it inside various products and services.

Speaking of services, yes, we do have a member service department, and they’ve been working very hard too. The number of new members in APNIC rose by a little over 10 percent so far in 2010, which is really quite cool. We’ve got 3,000 folks now using our portal and the rest of the myAPNIC services.

What do people ring us up for? Fascinating. They ring us up about reverse DNS. What do people use reverse DNS for? I have no idea. I really wish I understood this. But it’s a deeply fascinating topic. Either that, or it’s incredibly confusing. Because that’s the number one topic on the help desk. The other ones you can read there, obviously.

In terms of policy, we’ve actually managed to get three policies through the policy development process and out there. The first is a mandatory abuse contact information.

We used to also have an IP prefix exchange policy where you could take the various bits of fragmented stuff you accumulated as dross over the years and exchange it for a bright, shiny single prefix.

Unfortunately, we really haven’t got access to large prefixes these days, so, yes, we’ve managed to say we just can’t do it anymore.

And we’ve also removed the initial aggregation criteria for the initial IPv6 allocations as a measure of trying to make sure that v6 is readily available in the region.

Over in research and development, we’re just working 30 hours a day. We’re just really pumping this stuff out. We did some routing research. And I think I might have reported it at the last ARIN meeting, some results of that about routing scaling.

Working very, very hard on certification services and trying to understand exactly what DNSSEC means and how it behaves and when you roll over your keys why does your server melt.

And also trying to do a certain amount of network testing and monitoring. One of the more recent ones we’ve been trying to do is actually get through all this craft about IPv6 and try and answer the question: Exactly how many of you out there can access IPv6 end to end today, and what about tomorrow?

We’ve been trying to understand the difference between component tests, routing, DNS, quad-A records, et cetera, and end-to-end deployment, true connectivity.

So we’re starting to publish some work on that space and actually trying and get some understanding of what’s going to happen in IPv6 over the coming months as we have fun with v4.

We’re moving. And part of the moving of offices and moving of machine rooms is that the technical guys have now discovered that two is not enough and if you really want rock-solid reliability and this thing called DRP, which you evidently can’t have enough of – to have all this DRP we have to build triangles. So we’re building triangles. Next week it will be circles. DNSSEC will be running very smoothly, or is and has been since April. And we’ve now discovered that Agile software development is very fashionable, so we’re doing it too. We’re very proud of that.

We now also are working very hard on IPv6. We’re now doing the secretariat for the Asia-Pacific IPv6 Task Force and working not only at the technical level in the community such as this, but also trying to work very, very hard with various governmental and regulatory bodies.

And one of the more interesting ones is the Asia-Pacific Economic Community, APEC, and the telecom ministerial working group. And we’ve worked very closely in two workshops there – firstly at Taipei and secondly in Brunei – in securing stable growth of the Internet with IPv6. And that’s been very effective, I think, in forming the public policy process in countries in the region as much as it is in informing industry operators.

We do lots of training and education. The training staff travel all over the region, but also of course it’s a lot easier if we can do it using the network. And we have now managed to set up 18 E-Learning Web classes with fair fewer attendees, and that’s been very successful. Very proud of that achievement.

Then Internet governance. It’s the current buzzword, isn’t it, has been for some time. The first Asia-Pacific regional Internet Governance Forum was in Hong Kong this year. And we were one of the main organizers. And we’ve also in this most recent IGF that was in Vilnius in Lithuania – we hosted some remote hubs in those cities around the region.

And we’ve got a new building. Here it is, bright and shiny before we whacked the logo all over it. We’re moving across the river. So if you come to the coffee shop down there in Park Road in Milton, we won’t be there in December. We’ll be over trying to get a new coffee shop established next door to this building. And if they won’t build one, we’ll have to build our own, because George Michaelson and I can’t survive without good coffee.

Last but not least, please, if you’re touring around the region or want somewhere to go in February because up here in the Northern Hemisphere it’s bitterly cold and the blizzard is blowing, it’s really nice in Hong Kong. And February 21 to 25 we’d like you to come over and join us at APNIC 31.

After that, if you can’t make that, we’re going to sunny Busan in South Korea later on in the year. And in 2012 you can make your travel plans right now to come to Delhi.

Thank you very much.

John Curran: Thank you.

(Applause.)

John Curran: Any questions for Geoff?

Any questions for Geoff? Okay. Thank you.

Next up is the update from the Policy Development Process Committee, the PDP Comm. Come on up, Lee.

PDP Committee Report

Lee Howard: Good afternoon. I’m good at a great many things. I’m really bad at naming committees. The Policy Development Process – it just has no good acronym – reported on this at the last public policy meeting to say we’re doing this, and I wanted to tell you where we are right now.

I’ll start with committee members. I’m chairing the committee. John is a – as the president/CEO is an ex-officio member, which means that he sits there because of his office. Scott Bradner, Paul Andersen, John Sweeting, and Dan Alexander are all participating on this committee, which means we have some great expertise.

The charter for the committee. This is per Board resolution. It’s to come up with improvements to the process to make it clear to newcomers what the process is, because it’s not easy for people to understand how it is we make the sausage here; to encourage open community participation, obviously; and to strive, of course, for both timeliness and relevance in new policy.

Our goals. Primary goals are to make sure that the policy proposals that we see and pass are important; that they’re significant for a significant portion; that they’re necessary for a significant portion of the community.

They need to be concise and clear and relevant to allocation or assignment of number resources. We should not be discussing policy proposals on the color of garb that the staff should wear.

In scope for the committee is a revised policy development process to eliminate ambiguities, potentially including a revision of the global policy development process as practiced in our region.

As you heard from Louie Lee earlier today, the NRO NC works on global policy proposals that involve all the RIRs and IANA, but each – the way that policy process flows down is it uses the locally developed policy development process, which is to say ASO policies follow the – follow the ARIN region policy development process for adoption before getting rolled up to become global policies.

That, what I just said, is complicated. And it’s part of why what – what needs to be improved about the policy process; that it’s unclear and it’s not easy to understand as you start out. So we may be looking at that.

And we also need to take up the question of when we get into “who is the community,” there’s some places in there for what are the important – from whom do we need to hear input when we’re considering policy proposals.

So the committee has taken all of this chartering and problem statement stuff and identified some more specific-level problems.

And I want to warn everybody that these are not necessarily worded incredibly well. These were kind of notes that we took to guide us in our process. So this is sort of rough information and feedback to you to let you know how we’re going through our review of what we’re working on.

So the first problem that we’ve identified is the newcomers have a hard time understanding what this policy development process is, how we do this.

And so the right column here, in all of these, is how we propose to address the problem that we’ve identified. So the first one is we need a new process that is easier to understand.

Second problem identified is it takes too long to pass policy. That’s especially going to be a problem, as several people have said, in the next few months as we get closer to the depletion of the IANA unassigned pool; that we may need more rapid iterations of policy as time goes on. So, again, that could be addressed in a new policy process.

We need to be spending time, so we need to prioritize on the most significant policy changes that are needed, the 80/20 rule. Let’s not waste time on wordsmithing parts of the number resource policy manual that nobody uses.

Continuing on. This is sort of a different set now. There’s been a perception that the Board doesn’t explain itself well to the Advisory Council, either before the AC has said something or that the Board will say, you know, this needs a little bit more work and hand something back to the Advisory Council. That’s something that needs to be worked on. But that can be addressed in an operational guideline. We do not need a new policy development process step for that. That’s operational.

Policy workload is high. I don’t know if you all are aware how hard the Advisory Council works, but they put in a lot of hours, and that’s part of the reason that you see the shepherds get up here. There are two shepherds assigned to every one of the policy proposals.

It takes a long time. They spend – they have meetings very frequently. And for volunteers, the work they do is just immense. So we need to streamline how their workload is handled and again make sure that we’re prioritizing the time they spend on the things that are actually most significant to the community.

But most of the parts of that particular problem can be addressed with operational guidelines. We do need to make sure the PDP recognizes that policy proposals need to be significant, but we also can sort of do some workload, workflow prioritization with just operational improvements.

There’s been a specific question about shows of hands at the public policy meetings: Is it a good thing or bad thing? Is it a vote? Is it a poll? Is it a sense of the community?

There are an awful lot of sort of baked-in questions to this question. And should the count be official, should it be reported, or is it just informational, should the Advisory Council be doing their own count? And should the Advisory Council vote or raise their hand or take – participate in the poll?

All questions on which we have not reported back yet, but questions that have been submitted to the committee for consideration.

There’s a standing rule right now that a vote by the AC on the disposition of a proposal requires a majority of the seated members, which means when a policy – in an Advisory Council of 15 members, a majority is eight people. If you have 11 of the 15 people show up to a meeting, you could – and seven of them vote in favor of advancing a policy or abandoning a policy proposal, you have deadlock because you’ve not achieved majority. That’s a parliamentary problem we can address just with parliamentary procedure, but it needs to be addressed.

Timelines. This is a specific case that came up not too long ago that if the AC is going to take an action that might generate a petition to whatever their action is, a petition of their action, then the minutes from the AC meeting need to be released so that people can see the notes on the discussion for why they took the action that they took. Otherwise, their actions could well be partitioned with nobody knowing exactly why the AC did what they did, and they might have had very good reasons. In fact, they probably did have, with certainly what they thought were very good reasons, and maybe the community should see those reasons before petitioning their decisions. Again, probably just addressable with operational guidelines, but we’re getting into what those will be.

The NRPM needs edits. Several people have pointed out that there are inconsistencies within the existing policy manual and that those inconsistencies do not necessarily cause policy gaps in most cases but they certainly cause confusion. And that’s another thing that probably doesn’t need to be addressed with a new policy development process but probably does need to be remanded back to people who can look at the NRPM overall and give it a good, thorough scrubbing. It’s been a while since it’s been overhauled.

Now, the rest of these, you’ll notice that the column on the right is empty. And that’s because these are questions that we haven’t really been able to take up and figure out how to address them yet.

So we’re looking for ideas. But some of this is we’ve not had enough meetings to get into these parts of the questions yet.

The first one is governments are people, too, and have opinions, apparently, and would like to be able to participate. I think we’re very lucky in our community to have representatives from various of our regional governments able to be here and able to participate, but it is often the case that governments, that representatives from governmental bodies, have even less ability to speak freely than representatives from large corporations. So we need a cycle in there for a way to make sure that input is heard.

There’s a question or an issue that there’s an awful lot of work on PPML and these meetings are intense. We need to find ways to make it possible to participate without being completely overwhelmed.

I do think that Einar had a fantastic slide that he presented at the First-Timers’ Lunch on Tuesday, explaining that, well, really, you can probably get by with just surfing PPML once a month or checking to see what the status is on any given policy proposal and then checking the agenda when it’s drafted, when it’s drafted for public policy meetings, to find out when proposals you’re specifically interested in will be discussed and remotely participating; that way you can get by with a couple of hours. Really interesting suggestion. So maybe that – that actually may address that one in particular.

And then back to the global policy development process being a little unclear, especially when changes are needed and a complaint that that process is also slow. I’ve also heard, though – although this has been fed into the committee as a problem, I’ve also heard that this is by design. So maybe this is not an area that’s a problem, it’s just a concern. So we should be thinking about at that.

When we look at the question of who is the community, which was specifically included as part of the scope, these are some of the examples of who should we make sure that we hear from.

And then, finally, it’s unclear where policy variations for different kinds of organizations or different sub regions within our overall region are appropriate. And we’ve seen several policy proposals in the last couple of years that address either certain kinds of companies or certain kinds of ISPs or certain – or companies in certain regions of our region, and we should probably come up with some guidelines for when that’s appropriate and when that’s not. We have not come up with those guidelines yet.

Next steps. What we’re going to do is – the Policy Development Process Committee has been discussing these things, and we’ve come up with a few ideas that we’re still kind of kicking around.

And so what we propose to do is to talk to the AC first tomorrow after the Members Meeting and share with them some of the specific ideas that we’ve talked about that might be part of the new policy development process and new operational guidelines.

And we wanted to talk to them first because they’re the ones who are most closely involved and feel the pain most acutely. And they’re also the ones who as volunteers directly involved with the process – are the ones who spent the most time thinking about the problems and potential resolutions to them.

Once we have done that, the next step would be to go to the Board and make sure the Board doesn’t see any particular issues with the direction we’re going, come up with some draft documents, which would then, of course, be posted to the public policy mailing list. Because we do things in public and before we take any actual action, we need to make sure that the public is engaged in the process of developing the public development policy development process.

(Laughter.)

Lee Howard: Peter Piper picked a peck of pickled peppers.

So that’s where we are and that’s where we’re going. And I listed the members of the committee. Of course those are always available on the ARIN website, if you look for it real thoroughly. And these slides will be posted shortly, so you can find them there. And of course my name is Lee Howard, and you’ll see me on the ARIN Board section. If you go to ARIN “About Us,” “Board of Trustees,” and look up my name, you’ll find my email address. You can email me with specific suggestions, issues, or concerns you have and make sure that you can find me and let me know what your specific input is.

John Curran: Any questions for Lee?

Lee Howard: Question from over there.

John Springer: John Springer, Inland Telephone.

In some of the proposals that you’re going to be submitting to the AC and the Board about the policy development modification process, is one of them something along the lines of time is of the essence?

Lee Howard: Yes, that’s been thoroughly noted. The trick, of course, is to balance the importance of timeliness, of working with alacrity, with the need to make sure we have input from everyone and everyone has had a chance to provide whatever feedback they want to provide to the process.

So that’s the balance we’re trying to strive for, but I think that we will be at least improving, if not making it perfect. That’s the goal.

Anybody else? I’m certainly available after hours and online.

Ralph Bischof: Ralph Bischof. I’m with NASA.

A real quick question on the government access. Do you have any type of ways that you’re going to go about doing that, whether it’s physical, electronic, things of this nature for government entities to really have a voice?

Lee Howard: To tell you the truth, the committee has not discussed this point yet. It’s a point that we need to discuss. But I also need to admit that I don’t know what would be most useful and effective for input from agencies.

So that’s another – if you have a suggestion, if you know what works for you – I’m trying to look at the people in the room who work for the government – that would be a great idea for a specific comment. Please.

All right. Thank you very much.

John Curran: Thank you.

(Applause.)

John Curran: Okay. Now we have the chair of the AC, John Sweeting, to come up and give the On-Docket Proposals Report.

AC On-Docket Proposals Report

John Sweeting: Good afternoon, everyone. I just checked with Einar, and it’s confirmed there are no on-docket proposals to report on.

(Applause.)

John Sweeting: So I would like to take a few minutes more of your time, though, before we get to the open mic to recognize and show appreciation to one of our AC members who has had to make the tough decision not to run for re-election. For those that don’t know, I’m talking about Marla Azinger, who has spent six years on the AC.

(Applause.)

John Sweeting: She is a past chair and served as vice chair for two years and has been very influential in all the policies that have come out of the AC. I think Marla would like to address the room. So without further ado, Marla.

Marla Azinger: First I wanted to apologize to those that did nominate me and I told I would run. I did accept my nomination. And reality kind of hit me in the forefront, and I kind of had to make the hard decision to pull my name.

I’m sorry. It’s kind of sad, because it’s just a lot of work, and a lot of you are like friends to me. And I feel like a retard that I’m crying at the mic.

Anyway, it’s hard to pull back from something that you’re so involved with. And it was the right thing to do, though, because at work it’s – with what we have going on with the integration with territories that we purchased, I don’t have time to do justice to what you all deserve with policy and the amount of time, specifically on the AC.

And I didn’t want to be someone that sat there taking up a seat and not doing work. I never want to be that person. And I kind of felt like I was starting to get on that edge. And I know going forward I don’t have the time to do what it requires.

So I just wanted to thank everybody that did support me being on the AC these last six years, because I absolutely loved it. And I absolutely love being involved. I hope not to go completely into the sunset, but I’m going to try and stay involved, but I just can’t do the AC time requirement that there was. So, anyway, sorry. I look like a fool. I’m sorry. But thank you.

John Curran: Thank you, Marla.

(Applause.)

John Curran: Thank you, John. And at this point we’re now going to open mic.

Paul Vixie: So before we move to open mic, I’d like to let you know the Board has been meeting on and off all week, and in our first meeting we passed a resolution. You’ll see this when the minutes are published, but I thought I better sort of read it out loud now.

The ARIN Board of Trustees resolves to express as it does hereby express its appreciation and gratitude to Marla Azinger for her outstanding service to ARIN by serving on the ARIN Advisory Council, her efforts and co-chairmanship of the Advisory Council, her outreach to the IETF for ARIN, as well as her policy development efforts for the ARIN region. Will be missed by all. Now, we passed this motion by acclamation, which I would like to do again now. Will the Board please join me.

(Applause.)

Paul Vixie: Thank you, Marla.

Open Microphone

Paul Vixie: So open mic is sometimes a bit of a hairball. It’s almost indistinguishable from when we try to discuss two proposals at the same time.

(Laughter.)

Paul Vixie: And I look forward to it. It’s one of the highlights of the week. We can address anything. This is finally our time when John and the staff have not told us what in advance we can talk about and I don’t have to keep anybody on topic.

Fairly often we go back to something that the queues were closed on before everybody had a chance to say what they wanted to say. In this case I expect we might address questions like is 6rd supposed to be temporary or should we really allow that as just sort of an extension to the architecture and support it as best we can and not try and strangle it.

Those are questions that were hard to put to a show of hands at the end of that segment. We have a slide that shows -

John Curran: Do you have it? It’s going up.

Paul Vixie: We have a slide that staff’s put together that talks about sort of the things that we have touched on in the last day or three. This is not intended to sort of lead the discussion but just to remind people of things that we’ve talked about in case you’ve forgotten: Oh, yeah, I wanted to say more on that topic.

If there are more than one slide in this deck, then -

John Curran: That’s it.

Paul Vixie: Okay. So with that having been said, rear microphone.

Dave Barger: Dave Barger with AT&T.

I’ll throw out something we haven’t talked about yet. Okay. I know most of us in the industry probably watch Geoff Huston’s numbers quite a bit in terms of IPv4 exhaustion, and I think today’s date it says June 2, 2011, for IANA, and we use those as a measuring stick for doing our IPv6 project deadlines and all this kind of thing.

I’m just wondering if ARIN could possibly state an estimated exhaust date for the ARIN repository. I know Geoff publishes an RIR exhaust, which I think is saying January 2012 right now, but for those of us who get the vast majority of our space from ARIN, that’s what we’re focusing a little bit more on. So kind of throwing that out to ARIN and see if you guys can answer that.

John Curran: Okay. So first thing you need to know. All of the forecasts are based on discrete events of RIRs coming in and getting their next block or blocks.

Those discrete events we’ve sort of normalized and averaged and extrapolated; both Geoff’s done it, Tony Hain’s done it. Nate and I did a bottoms-up analysis of how often individual RIR members come in and get their distinct blocks to try to figure out which of you are coming back when, none of which takes into consideration, oh, I’m opening a new business, or, oh, I’ve moved into a new territory or any of the others.

So I guess I need to preface this with no matter what date we give, anybody actually planning their business based on this date is braver than most people. Okay? So first and foremost thing to understand is that right now it’s our estimate that in or about May there’s going to be the final five /8s depleted.

As Barbara said, one will be given out, one or two; whatever that request is will trigger the condition that leads to the other five. I will say that she also noted at the present run rate potentially that could be February. We’re looking at May.

Whether or not that occurs, the moment that occurs we’ll already be in a circumstance in ARIN where effectively we will have run out for some customers.

If you come in now and you attempt to produce a request for /7, I think you might find it’s challenging, because whether you can meet it based on your prior usage or not, it may not be in the pool.

The number of what we can handle will dwindle quickly after May. How far and how fast will it drop? Between May and August of next year it will drop from approximately a /8 to approximately a /32. Okay? So you’ve got a very short number of months after that time.

Now, there is actually a long tail. It is true there’s a lot of little pieces, but the reality is that we do expect those little pieces to use – be used very, very quickly. So when organizations come in looking for a discrete assignment and it turns out that they end up getting something that’s smaller, that doesn’t surprise me in the least.

So does that get your question answered, Dave?

Dave Barger: Yeah, John, that does answer the question. And, you know, I think – I mean, we all know that it’s going to run out and it’s going to run out fast. And, I mean, as an ISP, I fully expect to be totally rejected by ARIN if I come in and ask for a /10 in June of next year.

But I think the importance of this, though, is that it’s not – I mean, exhaust is what it is. But we use these as tools to go back into our weekly reports, project reports and monitoring progress and all this kind of thing to use a bigger club to beat the right people over the head and keep reinforcing the message.

And believe it or not – and I don’t know if this occurs in the rest of your businesses, but there’s still one or two people out there that say: Now, what was that IPv6 thing you were talking about again?

And you always have to go back and beat with a bigger club and hit them harder.

John Curran: So for that purpose, just to be clear, if you want to understand, the number, the most conservative number with the published methodology I have seen says you will have no more resources available to you in this region in February. Okay? That’s not ARIN’s estimate, but that is the most conservative number with the published methodology I’ve seen.

Dave Barger: 2011?

John Curran: Yes.

Paul Vixie: So I want to point out –

Dave Barger: It is what it is, and that’s what I can report. Thank you.

John Curran: Thank you.

Paul Vixie: I want to point out the ARIN Board did a resolution a few years ago announcing to the community that this was so and that – and anyone who wanted to continue growing their networks or therefore growing their business, if their business was based on their network, really should be deploying dual stack. And we said that several years ago. We’ve repeated it often. I will repeat it again.

If you are building v4-only networks now and if you plan to keep doing that until the bottle is empty and there ain’t nothing left, that is, in my opinion, not the best way to serve your shareholders and customers. You should be doing dual-stack. You should have been doing dual-stack. This is incredibly real. And the difference between now and February is almost not worth mentioning or thinking about.

Martin.

Martin Hannigan: Martin Hannigan, Akamai Technologies. I’ve got two points for you. There seems to be at least two issues remaining with regards to this meeting: ARIN exhaustion leadership and regional policy that was not able to be addressed at this meeting.

We also heard that the IANA exhaustion date may be pegged to February 2011 and it’s likely the last /8 may be allocated from the IANA and assignments begun from it in this region before our next meeting.

Without debating either specifically, what does the BoT need from the community, possibly and probably via the AC, in order to be able to interpret the will of the community and, if warranted, act on proposed policy between now and the next meeting on at least a temporary implementation basis?

The second point that I have for you, which is a little bit redundant to Dave’s point, is – the second topic I’d like to suggest that we discuss is what the plan is for IANA depletion day. We’re going to need to plan with respect to this. And we’d like to know if there’s going to be an event, a press release, something more elaborate or something more gloomy. Where is the party and how do I get invited?

And I think that it’s probably – if I had to guess, it’s going to be coordinated to some extent. And I think that it would be important to coordinate it with the community as well as IANA and the other RIRs. Thank you.

Paul Vixie: So to the first point, I’ve got John searching the bylaws for the emergency policy language.

John Curran: I have it.

Paul Vixie: To the second point as to having a party on runout day, that strikes me as a great idea, although perhaps not a great use of member money.

Martin Hannigan: I was being sarcastic.

Paul Vixie: We’ll have to take it under advisement, and that means please feel free to advise us.

John, could you read the specific text of the emergency policy.

John Curran: So the specific text says that the BoT may initiate the emergency PDP by declaring emergency and posting a draft to PPML for discussion for minimum of ten days. The Advisory Council will review the draft policy within five business days of the end of the discussion policy and make a recommendation to the Board of Trustees. If the Board of Trustees adopts the policy, it will be presented at the next public policy meeting for reconsideration.

So if we thought there was an emergency, we have this mechanism out there, this tool, as you were, which we can take out of the box with all rigor and ceremony and make use of. The last time we did that we were reminded that we should use caution in making use of the emergency PDP process. So it is there.

Now, you asked the question what do we need from the community to have faith. That’s actually the AC that will be judging the output of that process.

Does that help answer your question?

Martin Hannigan: So I understand correctly, let’s say something hits PPML. It gets a groundswell of support. The AC would put it on the docket and then they would declare it’s an emergency and forward it to the Board, or will there be some collaboration time?

John Curran: We would be putting it to the PPML. We would instruct the AC they have five days to give us a yea or nay recommendation, and then we would look at that yea or nay recommendation.

Martin Hannigan: So if you saw a proposal on the list, theoretically that means you could take it and declare it an emergency. You wouldn’t have to have it sent directly to the Board?

John Curran: We actually have to declare it and repost it. If it’s on the list, it’s got a lot of support, and we thought it was important, we would pick it up and say we’re going to make this emergency policy. It’s now being posted for that purpose, the clock now starts, the AC will pick it up after.

Martin Hannigan: Thank you.

John Curran: As for the ceremony, I have not heard of anything, but I’m happy to liaison with my fellow executives of the fellow RIRs and IANA to see if an appropriate ceremony can be done.

Martin Hannigan: I was being fairly sarcastic about the party. But I do think it’s important to coordinate to make sure we’re all together.

Paul Vixie: When I said the meeting would be a little bit of a hairball, I would still like people to slow down a little, please. The man with the Google shirt has something to say about a ceremony.

Wesley George: Wes George with Sprint. There was a discussion in both the combined session with NANOG, and I had some hallway discussions about it as well, about a quad-A day, where some non-zero number of folks turn on quad-As on their main websites and leave them there and see what happens. I would think that there would be no better time to do it than the IANA runout day.

(Laughter and applause.)

Paul Vixie: We’ll see if anybody is willing to go v6 only on that day.

Marty, are we done?

Martin Hannigan: I think so, unless somebody else is going to comment. Thank you very much.

Paul Vixie: Next up.

Kevin Blumberg: Kevin Blumberg from The Wire. This is my second ARIN meeting. The one thing I’ve noticed is a lot of policy is talked about here, far more than I’ve ever seen on the PPML in the last six months.

And what I would actually like to see is possibly flipping things on their head and having policy working groups at the meetings where policies can be worked on by groups, then taken to the list in a free state so that people can discuss them, et cetera, rather than having them on a list to start with where behind the scenes people were talking about it, they put it on the list, and there’s just – well, you’ve seen zero, two, four, six total posts on policies, yet when we come here there’s 16, 18 people talking about things.

So I’d really like to see ARIN policy working groups actually in the meetings but allow community involvement after the fact. That’s the first part of it.

The second part of it is we’re all technology-driven people. We’re not linguistic pastry chefs. And I would really like to see ARIN hire a staff writer to help shepherd along, just like the AC shepherds along, to help the policy, the people that make the policies, into things that are clearly, decisively worded. And that is just one of my directions I can ask for. Thank you.

Paul Vixie: So to the first, I want to say there is a PD comm. Lee Howard is the chair of the Policy Development Committee. I hope that he is taking notes about what you suggested with regard to working groups. It may even be that policy-specific mailing lists might have to be developed so we don’t overwhelm people on the PPML.

As to the second matter, I think John wanted to speak.

John Curran: So note that with respect to the wordsmithing, the revised PDP now has policies that come in. There’s an interface with the staff where the staff is supposed to go through and help with the wordsmithing of the policy. Not changing the meaning, but a clarity phase where the words and the references are corrected.

That’s something that we’re trying to make happen more and more frequently so we end up with a policy proposal that doesn’t have language which is, you know, either not the definitions in the NRPM or doesn’t match other sections. So hopefully that should be occurring for new submissions.

When you take the form for a new policy submission and you send it to the staff, there’s actually a round of editorial review. Not to judge it, but to clarify your meaning before it goes out. Now, we’ve taken a pretty light hand on that, just to make sure the references are right and that the sentences are legible. Do you want us to move to the level of artistic review in terms of phrasing and wording?

Kevin Blumberg: I am not a very good writer. I never have been. My mother is a Ph.D. in English literature. She can take the two paragraphs that I have done, having no understanding of what I have done, and summarize it into two sentences. I think that the more complicated – there was a mention yesterday, when you have a 1500-word proposal, every additional word that you add lowers the chance.

We have to simplify. And I think the only way you can simplify is by having a writer involved almost at the very beginning, from the concept phase, then that writer gets involved and helps.

John Curran: Okay.

Paul Vixie: Thank you.

John Curran: Lee is right there.

Paul Vixie: Lee, I think you wanted to say something about this. By the way, Lee’s degree is also in English.

Lee Howard: I in fact did major in English. What I heard you say is “be pithy. "

(Laughter and applause.)

Lee Howard: To your first point about working groups here doing drafting proposals, so, yes, I heard that. And I’m very interested in other people’s discussion of that idea. Here to me personally, on the mailing lists, at the bar, whatever works for you. One of the things that I talked about is the conflict between making sure that the process is open and making sure that it’s speedy and does a good job, and produces a good sausage.

So the trick there is how do you make sure to be able to include remote participants during the initial drafting. It may be sufficient to say they can have their input once there’s a draft that’s been reviewed by a bunch of people after it comes through.

I just want to make sure we don’t disenfranchise anybody. In fact, I think there’s – I believe the APNIC policy process has a working group system that is more like what you’re describing, where each policy area has a working group dedicated to it. So it’s not without precedent and certainly well within the realm of policy review.

Paul Vixie: John would like to comment.

John Curran: What people need to remember for drafting new policy proposals at ARIN interactively with other people, we have the open policy hour. You can sign up for it. You can stand up and give two slides, hey, I want to talk about this.

People who think that everyone who got a v6 allocation will never qualify for another one and want to fix that, come meet with me, and then you have the days – we had the open policy hour several days ago, so you have days to work with people to submit a proposal or work on it in the hallways.

We specifically encourage people to suggest ideas for new policies there so they can interactively do it at the meeting.

Aaron Hughes: Aaron Hughes. I think this particular meeting we had an exceptional event happen that drove a bunch of conversation on a few policy proposals, and that was that we had an industry expert describe what happens with 6rd. And that discussion didn’t happen on PPML.

So the suggestion I might make to accommodate both Kevin’s request and to engage PPML discussion prior to the meeting is that the shepherd reach out to industry experts when necessary to get that kind of discussion to happen prior to the meeting.

Paul Vixie: John and Lee have both taken note. Let’s go to the remote participant.

Stacy Hughes: Joe Maimon, CHL: With regards to the comments about disparity of discussion on list and at meeting – this is speaking to you, Kevin – could proposal abandonment prior to meeting be premature? It’s part of the PDP, though.

Paul Vixie: We’re going to let Lee answer that.

Lee Howard: Lee Howard again. I think that one could definitely argue whether the AC exercises that ability more often than it should, certainly within the realm of debate. I think that that function is required in order to prevent a denial of service attack on the public policy meeting.

John Curran: And it’s protected by petition.

Lee Howard: And again, of course, as we know, it is protected by petition so that there is always the opportunity for the – if the AC makes a decision with which the community disagrees, the community can petition that and bring proposals forward. And we’ve seen that happen quite a few times.

Stacy Hughes: Joe says thank you. And he has one more comment with regard to Marty’s comments, what Marty said, only with more – with more emphasis on any attempt to hold on to more of the last /8, with regard to what should the Board do.

Lee Howard: I also wanted to respond to Joe on one more point, which was to say thank you so much; it’s fantastic that you’re able to respond remotely to the discussion about remote participation. Way to go, ARIN.

(Applause.)

John Curran: I just want to note with respect to petition. So the ability of the AC to take something and prevent it from coming here because they don’t think it’s relevant or it’s not something – again, the petition process is relatively easy and it only takes ten people to force something to be presented here.

So we’ve had that exercised very successfully. Some of the items on the agenda for this meeting were petition items.

Paul Vixie: Okay. Let’s move along.

John Curran: Before I go, I don’t think the last comment from the remote participant was clear.

Was Joe asking a question there, Stacy? Oh, I’m sorry. Couple of things. One, just to kind of keep everything congruous, there was some comments made today about the way policy is formed in other regions and the way policy is here and the details and things like that, and to go to the comments about having someone else or an actual author write policy instead of just technical people and policy people. I think we have a tendency in this region to become policy technicians and focus on wordsmithing instead of focusing on actually doing what we want to do.

I think that – I don’t know that there’s anything that ARIN staff or the Board can necessarily do, but as a community I think we should move away from that. I’m guilty of it as well. I think if you propose a clear concept that there’s probably ways to turn that into policy that aren’t arguing about which word goes where in sentences at the meetings or on the list.

Beyond that, on another point to the POC validations that came up during staff report, I’d like to answer both of them. One is that the fact that all of these POCs are freaking out and don’t know how to respond is illuminating the problem that we were trying to illuminate with this policy. This is exactly what we expected to happen. These are not valid POCs. If they can’t respond, then they shouldn’t be the POC. If they’re telling you to call their upstream, then their upstream should be the POC on that space.

I’m not sure what to do with that information, but that’s the information we wanted defined.

To the second question, no, we should not be doing updates for records that have no invalid POCs.

Paul Vixie: Thank you.

Marty again.

Martin Hannigan: Hello. Martin Hannigan from Akamai Technologies.

As I sat down, my AOL IM exploded based on my comment related to the February 2011 date. I can appreciate that it’s very difficult to set a date, but I think that the pressure is mounting for you guys to actually give us more information related to the date.

And I personally would like to see that happen. I want to reiterate my comments and others’ that we would like to get better dates, and if it’s from you or someone else, it would be really good to have something that people actually had confidence in.

I’m pretty convinced that there is going to be or can be a coordinated effort to peg it to a date once we get a little bit closer, and I would like to urge you to think about that a little bit more.

Thank you.

John Curran: Marty, I need to ask you what you mean by something. So the moment the final five run out or the moment that the depletion occurs and the final five /8s is allocated is based on when – the independent actions of five RIRs; when one of us goes for the last /8 that’s /8 No. 6.

So certainly ARIN doesn’t – well, we have some idea and we can estimate and we’ve all talked. Even independently the RIRs don’t actually know – I don’t know when you or you or you, particularly you, are going to come in for more address space. Okay?

So I can’t tell RIPE and APNIC we think we’re going to end up triggering our need for /8 on January 15th, because I’m guessing. So my concern is that we can easily tell the community this is going to happen next year. We can probably even tell them it’s going to happen in the first or second quarter of next year. And what’s going to happen is we’re all going to get our last allocations.

But as we’re getting down to trying to forecast a handful of discrete events, I don’t know what you mean by coordinate. I guess I’m wondering: Do you want us to set a date?

Martin Hannigan: Well, yeah, if you can.

John Curran: What would that date be, what would we be setting, I guess?

Martin Hannigan: Let me address your point. Let me slow down in my head. I think really fast sometimes and I talk really fast sometimes when I do that.

So you guys are subject to utilization just like we are with respect to your IANA requests. You have to hit a mark. I believe it’s 80 percent.

As we close in upon those last five /8s, I would be surprised, especially since we can monitor pool depths and counts and things at the IANA and RIRs, if it wasn’t fairly predictable as to who was going to trigger the last five /8.

Now, if the RIRs could see their way to coordinating that, and that’s the comment I made earlier, you could theoretically, understanding who is going to trigger that, push that off a little bit so you can coordinate the final action that would cause the allocation of the last slash five eights.

To the second point, what would we actually do – was that the last question? I don’t know. But I think it would help us with respect to putting a nail, an additional nail in v4. Lots of folks have spent money in capex and they’re waiting for traffic to start flowing and the questions are coming in, the pressure’s mounting. I feel it. I can’t go into detail, but I feel pressure every day.

And I think that as we progress toward that day, it shouldn’t – I don’t really want to wake up and see a press release that says IANA allocates the last five /8s. It doesn’t really need to be a big surprise. And it can still be a big press event. I just think there should be something better than Tony saying February 2011 and someone else saying much later in the year.

I think that as we get closer it should be easier to pull the numbers and get us something more accurate. If it’s within 30 days, I think that would be okay. But I think it needs to be better than it is and I think that we do actually have the control and the power to improve upon that.

Paul Vixie: Okay. Marty, before we take that under advisement, counsel is at the microphone. No? Giving up. The Board hears you loud and clear. We’ll take this under -

Martin Hannigan: I don’t think you guys are deflecting or anything nefarious is going on. I just feel like I really need a date. I feel very uncomfortable with the disparity between all the dates that we see out in the press.

And we have to plan. And I need to be able to pin – I need accurate data to go to my company and people that rely on me for information related to IP addressing, and I need to be able to give them something that I can rely on and I can reference and have confidence that it’s going to be fairly accurate.

Paul Vixie: Okay. I’m not promising much, but we’ll certainly try harder than we’ve tried or something.

Martin Hannigan: That’s all I’m asking for. Thank you.

Paul Vixie: Woody would like to speak.

Bill Woodcock: Marty, when you can give us accurate numbers for how much address space all of your competitors are going to apply for, we can tell you when we’re going to run out.

(Laughter.)

Paul Vixie: Thank you, Woody.

Martin Hannigan: Woody, I’m not buying that, so that’s a deflection. Thanks.

Paul Vixie: I believe the back microphone is next.

Joel Jaeggli: Joel Jaeggli. Yeah, so, I mean, what we have is models, and models are almost always wrong. We know this from economic forecasting. I can go ask the Federal Reserve how much economic expansion there will be next quarter; they’ll be wrong. I can ask the U.S. Department of Commerce and I can ask a whole bunch of people who run hedge funds; they’ll all be wrong.

If we don’t want to rely on a model, we can induce the outcome that we want. Thank you.

Unidentified Speaker: (Off microphone.)

Joel Jaeggli: Is it possible to do. Whether we should or not is another question entirely.

Paul Vixie: I note that businesses who had to – and it turned out they didn’t have to, but who thought they had to make plans around Y2K had a date to work to. And we, of course, do not. And that’s got to be an impedance mismatch for most management teams.

On the other hand, the Internet has presented American or even world business with impedance mismatches before, and those have been overcome.

So center microphone.

Matt Petach: Matt Petach. I was going to echo your comment you just made about Y2K gave us a nice date to work for and companies reacted appropriately.

And to Martin’s point, I think Woody, while being somewhat flippant, did have a kernel of truth there, which is if you want a concrete date, we as a community can make a date happen for when ARIN runs out of IP space. I’m not sure that this is a good exercise for us to collectively as a group decide we want to have happen, but it is not something that ARIN is separately from us in control of. We are the ones driving the date, not ARIN.

One final point, I also believe that if there are no valid POC records, updates should not be made for resources.

Paul Vixie: Thank you, Matthew.

Counsel is back at the mic.

Steve Ryan: I’ve grown a tiny bit uncomfortable with this discussion because I think it’s become aspirational and not achievable. And I want to explain why.

We do not coordinate the business activities of the five RIRs. We coordinate global policy together. So an RIR in another region that draws down a large amount of volume, like the Asia-Pacific region, they’re going to keep drawing down and they’ll do whatever is good for their region and compatible with their policies.

It is not something we can do in our region. We simply will continue to accept requests that are valid for addresses and apply our existing policies to it.

We’re not going to make up a policy at the executive level to declare a day. It’s not – it just isn’t possible, because we have policies we’re applying.

It would have to be a policy that the Board would have to apply in an emergency fashion, because the runout’s going to occur before we meet in Puerto Rico. So I just don’t think this is very realistic discussion of the ability to legally maneuver into a date.

The date, frankly, is about to hit you in the head, and it’s in January. And in all likelihood that’s when the trigger will occur. You know right now when the date is. And it could come faster, by the way. It could come very much faster, depending on the drawdown rate. The drawdown rate is increasing, not slowing. And, therefore, I don’t think we should spend any energy.

And from a legal standpoint I don’t know how we could manipulate this into a date. We could have a happy day for press purposes. We could have a symbolic day. But I don’t know that we could have a predictive day under our current policies, and we are going to follow our policies.

Paul Vixie: Thank you, Counsel.

Marty?

Martin Hannigan: Marty from Akamai again.

Steve, I apologize if it seems like I wanted to have some combat with you folks. That was not my intention. I think my intent is only good; that we all feel like we need to have something better. If this is a legal problem, that’s much different from some of the facts that I’ve identified.

For example, the current global policy lets RIRs draw down five /8s and they’ve coordinated together to draw down only two. Theoretically you could do the same thing with some of this drawdown on the existing pool.

But I think that we should probably – I think we’re going in circles at this point. I don’t really have much more to say about it. Someone whispered in my ear that it might actually be useful to, instead of you pegging the date, provide us with better data and statistics, more granular, and that would be a reasonable compromise.

I really don’t know what you’re already providing. And I guess Jeroen would have to stand up and address that himself. Thank you.

Paul Vixie: I think if staff is able to provide more granular data that helps other people with their tea leaf problem, I’m sure we will do that.

But I do note that no matter how much data you have about weather conditions, you’re going to be wrong most of the time when you predict whether it’s going to rain this weekend.

So it’s still going to be tea leaves no matter what we do.

David Farmer: David Farmer, University of Minnesota, ARIN AC. I just want to point out that we discussed all these possibilities, all of these strategies many years ago. Started talking about them at least three years ago.

We came to consensus, probably very rough consensus, in how we wanted to do it. Now is not the time to have buyer’s remorse. We picked how this was going to happen. I sympathize with everybody, but that’s all I can do is sympathize. That’s it.

To the questions here, I kind of agree with Chris, we found out some things we wanted to find out. We need to churn on it and think about what to do about it.

As far as the updates for invalid POCs, yes, no, don’t do them. Maybe point them to please fix your – the – an update for a – something that has invalid POCs, as long as they’re updating the POCs, yes, at first, then maybe they can update other things. But if they’re not updating the POCs, they shouldn’t be able to update anything else.

Paul Vixie: Thank you, David. Let’s go to the remote.

Stacy Hughes: Okay. It’s from Mc Tim. He says: I agree with Chris that ARIN should not continue to update address space records with no valid POCs, but I think that my answer to Leslie’s first question from yesterday is, yes, ARIN should continue this exercise of trying to contact folk listed as POCs.

Paul Vixie: Lee.

Lee Howard: David, I did not understand your comment. You said we came to consensus years ago on something and now is not the time to revisit whatever that was.

The reason I want to ask you to clarify is it seems to me there are few decisions so good that they should never be revisited.

David Farmer: I will clarify. I’m sorry. We’ve talked about a whole bunch of different soft-landing proposals, talked about how we were going to – how this was going to run. Did we come to specific decisions how we were going to do this? No. But when you decide not to do something, that’s a decision too.

And so I’m just saying we decided not to declare flag days. We decided – there was flag days discussed. There were all sorts of things discussed. And we decided not to do those. That’s sort of what I was referring to.

Lee Howard: Lee Howard again. It does seem to – okay. Fair enough. We have had many discussions along the way. Not everybody’s in the room now, and not everybody who participates in the process now was participating in the process when those decisions were made. And just because you just got to the party doesn’t mean you don’t get a drink.

Owen DeLong: It might mean that after February.

(Laughter.)

Paul Vixie: So to that point, we’ve spent about a decade and a half trying to get DNS security done. And we’ve thought we were done about every two years throughout that period, and inevitably somebody came late to the party and said “where’s my drink,” and we then sort of restarted things to allow that person in.

So I think there’s no – there would be no policy in the company or any consensus in the community against continuing to think our way out of this box. If somebody comes up with an interesting thing that looks like it should be tried or might help us, then we should be listening.

But I will say we’ve been thinking and talking and arguing and proposing for my whole time here without producing much in the way of a different result from just hitting the brick wall at full speed. So we should not give up on that basis.

But some of us are probably going to listen rather than talk when those debates are happening.

Left-hand microphone.

Mike Joseph: Mike Joseph, Google. Regarding the invalid POC responses, I think that we should maybe look at moving on a proposal perhaps to be brought in the future where records that have invalid POCs are marked as stale in the database and in the Whois and those records not only are not subject to updates but also cannot be counted towards any numbers for future updates or utilization where effectively any record which is stale is effectively invalid and held over until the authority updating the record can provide corrective information.

Paul Vixie: Thank you. I really like that everybody who has spoken on that topic really likes accurate POCs.

(Laughter.)

Paul Vixie: I was thinking of more and more creative ways to make them better and better. Bill.

Bill Darte: Bill Darte, ARIN AC, Washington University. So I was involved in some of the tabletop discussions over the last two days at lunch, and it was involved – it involved should this be the end or should we continue to figure out ways to divide up the crumbs and all that.

I think I’ll try to write up all those things I have and turn them in from our discussion, but I’ll put them on the PPML. But I thought it was interesting that of the dozen or 14 or 15 people who participated in that discussion, basically everyone said, you know, it’s just too late to do too many things. We have policies in place now that have been considered and are reasonable and probably will be as effective as we can have for this runout condition. We have the /10. We have the transfer market. We have all those things. We don’t know what the consequences of those will be, but we’ve done a pretty good job of setting up this end state as best we can and now we should just let it go forward.

So that was just for your information.

Paul Vixie: Thank you, Bill. Any remotes? John is next.

John Curran: So I’ve been listening to what I’ve been hearing here about the needs of people to somehow make a more definitive statement about the runout than what we’ve been doing. And the only thing I’ve been able to come up with – and it’s not – it’s not John suggests this at all; it is it could be done. I have no idea if it’s good. The community and the Board need to weigh in here.

Two and a half, nearly three years ago, we ruined a bunch of people’s lives for a couple of months and sent letters out. We sent out 15,000 registered letters to everyone who has addresses saying in about two and a half years we expect to be out of IPv4 resources. If you plan on expanding your network and growing, you probably need to look at IPv6.

And in some organizations – I know this made a difference, because in some organizations when we sent them to the – we sent them to the highest organizational contact we could find in the organization, generally the director or CEO which is possible to get ahold of such information.

So it would be possible to send the message, the same letter, saying: Dear folks, we now expect in the first half of next year that we are going to be out and here is the activities you should be doing if you actually plan on continuing to use Internet resources or if you plan to connect to people who are going to continue to be growing with the Internet.

If we did that, I want to point out the downsides. First, you would ruin a lot of ARIN staff life. Okay? About two and a half, three months worth; B, you’d expend order of magnitude 70-, $80,000, I think, if I remember the postage and processing. And it’s not cheap.

As a guy who signed them all – no, I didn’t sign them all; I had people signing for me, my signature over and over. But the point is it would be a major endeavor. If it was useful to do an update to that, it could be done.

I do not know if it’s useful, but if someone wants an official statement from ARIN saying “we’re much closer,” we can send it out. It can’t have a date; it would still say the second half of next year. But we can send it out and do a corresponding press release, if that would help anyone in their planning, and if the community thought it was a good expense.

Matt Petach: Send it to Martin’s boss.

John Curran: Just send one. Okay.

Paul Vixie: Bill?

Bill Darte: Bill Darte with ARIN AC again. On this subject, I mean, I think there was useful discussion on this here that would be valuable for people. In other words, if the ARIN website said there are these folks who are out there with their timers and you could read about their analyses and dadada at these places and give some indication in that presentation about what the levers are that make this more or less predictable, all of those pieces of information would be valuable and exposed to people and folks could say: Go to the ARIN website because they don’t have the answer, but they have the stuff that encompasses the answer.

And so now you can read about that and you can see where the uncertainty really comes from, and they’re saying we maybe think that this is the likely range, but your mileage might vary if you read this differently.

John Curran: I think we have most of that, but we can fix it.

John Springer: John Springer, Inland Telephone. Don’t you know when you’re going to apply for your next two /8s within some degree of granularity: 90 days, 60 days, 30 days?

John Curran: 60 days, yes.

John Springer: And so are you only going to be able to do one of those between now and IANA runout?

Unidentified Speaker: It’s tea leaves again.

(Laughter.)

John Curran: ARIN will apply for resources according to policy to make sure that we have the resources this region needs. Literally, at that point, that’s all I can say.

John Springer: How about the public burn rate?

John Curran: What?

John Springer: The public burn rate.

John Curran: The problem is that you can derive the burn rate based on the requests that we’ve done, and you can figure it out. And, actually, I mean, go to Geoff’s site; you see the graphs. He’s got it all. It’s all very well known. You can see the burn rate of every RIR.

And based on that you can figure out if you want to do 60-day smoothing or six-month smoothing or three-year smoothing. You get a different rate. APNIC’s rate of draw has changed significantly over the last two years. Okay? So depending on whether you use 90 days or six months or a year or three years, you get a very different drawdown for their next date.

So set the knobs for how much data you want to look backwards on. And when you set those knobs, you end up with different next request dates for each RIR. Because there’s either they’re there or they’re not there, it’s a very discrete event, you get into some very high combinatorials based on how you set the knobs.

John Springer: Thank you.

John Curran: Dan.

Dan Alexander: To your comment, John, about the registered letters that went out previously, would it be a possible compromise where if ARIN posted to, say, the PPML, if there’s anyone out there who is having these kind of issues with their management team or business people, that they could – rather than you do a blanket announcement, that they could make a request to you and tell you exactly who to send that official letter to to give them the weight that they may need to have the discussions internally?

John Curran: Yes. I’m not only available to send the letter; I will come out and visit them. So to the extent that you want me in your lobby saying “the end is nigh,” okay, I am there. And actually some of you I’m already doing that with your executives. You know that.

So please drop me a note. I’m happy to come out. If I didn’t say that – that’s actually a great point. I am happy to come visit any organization that needs help persuading people what is going on here with IPv4 depletion.

Paul Vixie: In which case there’ll be a gold-embossed framed copy of the letter signed by John.

John Curran: Heather.

Heather Schiller: On eBay for the low, low price of 59.99. So you sent 50,000 letters registered mail?

John Curran: Yeah.

Heather Schiller: I’m not quite sure what that means. But did any of them come back?

John Curran: We have receipts for all of the, you know – we know that we sent them. We have copies of it. We have all of that so that we can actually – for someone who says “you never told me”: Hold on. Let me flip through the files here. Not that that’s of interest to me, but yeah.

Heather Schiller: I’m sorry. I meant did any of them come back in terms of – in terms of POC information, like -

John Curran: Oh, no, no, I’m talking about letters to the executives.

Heather Schiller: Yes, I am too. Oh, so -

John Curran: Just to the CEOs of all the companies that hold address space. This was two years ago.

Heather Schiller: Which may or may not be – so – okay. What I’m really trying to look at here is how that syncs up with – I’m pulling two completely different things – that syncing up with invalid POC records.

John Curran: Not at all.

Heather Schiller: No overlap.

John Curran: CEO letters had gone out two and a half years ago before we even had a policy for POC validation.

Heather Schiller: Yes, I understand. What I’m saying: Presumably you have some list of companies and their resources that have – that letters were returned to you and a list of records that have invalid POC information.

John Curran: From two years ago. Maybe. Yes. I could check.

Heather Schiller: Okay. Just curious about that. I don’t remember what the other thing – I waited so long I don’t remember the other thing I wanted to say.

Wesley George: Wes George with Sprint.

Just to comment on the recommendation of starting to put links on ARIN’s website to the information that exists about exhaust date.

Last meeting I had a conversation with a couple of different folks about starting to show the countdown on the stuff that you carried all of the stuff that you go to.

ARIN’s done a great job over the last year, year and a half, two years, of going to industry events, make sure that they explain to anybody who will listen that this is a problem, they need to be thinking about. Here’s the resources you need. We want to help you.

I think that’s a piece that’s kind of missing from the information, and the response that I got back at the time was, well, we don’t really want to endorse one or the other of these things because there’s a divergence in the time.

I think if we’re going to go that direction, it makes sense to do both; that if there are multiple possibilities, show them all. It’s not that much harder to do that. And if we’re talking about potentially linking to that information from the website, that would be another thing; that if you’re going to ratchet up the rhetoric in that way, let’s do it full tilt.

Paul Vixie: John has a question.

John Curran: A lot of your CEOs don’t use our website. So we can put a countdown clock that says: You’ve got 140 days, you’ve got 135, you’ve got 130. There’s a number of very nice clocks. 107. You know, say you have 90, it’ll have 78, 77, you have zero. One day it will go from some number to zero.

And so it’s fairly problematic to say ARIN believes you still have 78 days, but that was yesterday and today it’s zero. And I don’t know if your CEOs are actually using our website.

Wesley George: Well, with all due respect, it has nothing to do with our CEOs in a lot of cases. This is more about having it more publicly available. Yes, I can send emails internally and I can link to Geoff’s site or I can link to the Hurricane site or any of the other ones that are out there and say this is what’s being said about IP exhaust. And they can look at that and they can say, okay, yeah, that’s great, some guy out there did this thing and we don’t know whether it’s of any real use or validity. Because, unless they dig into the underlying analysis, there’s – there’s no confidence in that analysis, right?

The fact that ARIN puts it out there and says, look, this is a model. Models are known to be wrong. Your mileage may vary. Standard legal disclaimer here. But you should know that this is out here and we think it’s as good as it’s going to get, or whatever it is you want to say. That adds a level of credibility to it. Not saying that the folks that are doing it aren’t credible by themselves, but it does add a layer of credibility.

From that perspective, it’s not about whether or not my CEO ever goes to arin.com; it’s about if I’ve got to talk to my boss’s boss, who is not the CEO, whether or not he looks at that and says, okay, these are the guys giving us the addresses and they’re saying X, you know, that association helps.

John Curran: The organization that has the Web page most frequently viewed on the Internet sometimes has these really cool logo things they do. If that page were to load a clock that showed the countdown, some more people would see it than ARIN’s website.

Wesley George: True.

(Laughter and applause.)

Paul Vixie: Thank you very much. A doomsday clock. I like this. Chris.

Chris Grundemann: So, John, what would they know about this long-distance phone number they’d see? Your CEO, I mean. His CEO. He would see a long distance or international phone number. And what would that mean to him?

Wesley George: The IP address is not sensible to the CEO of Sprint.

John Curran: No, I’m literally talking about put the countdown timer on -

Chris Grundemann: Sure. That’s what is this IPv4 and IPv6 thing you’re talking about? The right message to the right people, man. The CEO is not the right people, not for that message. The message of, hey, your business might stop in 27 days unless you do this to make sure that it continues, that’s the right message.

John Curran: I agree. I’m just trying to figure out if anyone going to the ARIN website needs us now to tell them that we’re running out of v4 addresses, then we’ve got a little bit of a bad situation.

Chris Grundemann: Yes.

Paul Vixie: Thank you, Chris. Bill.

Bill Sandiford: Bill Sandiford, Telnet Communications and ARIN AC. So with regards to John’s comments a few minutes ago and listening to the two cons with regards to sending out letters again, first of all, I have the utmost respect for the two and a half months of lost life for those staff at ARIN that might be lost if those letters go out again, but I really think the letters need to go out again.

I’ll tell you briefly why. As an AC member over the last year, I’ve had the opportunity to take part in some of these outreach events with ARIN at various trade shows, and I’ve taken it upon myself to do some outreach at some other events.

And I can tell you that people still aren’t getting it. And I’m sure that’s probably the feedback that you’re getting from Megan, Richard as well. I know Owen does this a lot with regards to his job, and he’s probably hearing it as well.

Just last week I was at an event in Phoenix for a very small embedded router manufacturer. And their CEO steps up to the microphone and says – he’s doing their product roadmap, and he says: We’re here to tell you that we’re happy that everybody can rejoice because we now fully support IPv6 in our embedded router product.

And he pauses for applause, and the room’s dead silent.

And so then he says: Well, how many people in this room are doing IPv6 today?

So of the 120 people, I raise my hand, and I think there was a guy, too, beside me. That was it. There was two people in the entire room. And he then said: Well, how many are in the production environment? And the other guy put his hand down.

So I think the answer is there was probably many reasons why you sent the letters two and a half years ago, and one of those reasons – you know, you may have met your objective in that regard, but in terms of today there’s still a lot of people that aren’t getting it. I feel bad for the lives of the people at ARIN when those letters go out, but I think they need to go again.

(Applause.)

Paul Vixie: Andrew. Andrew Dul: Andrew Dul, Cascadeo.

I think this issue is in two parts. One is information about when the runout is going to happen specifically. And just an idea, but you could see a series of press releases that were released once a month on some date, and the first press release might say something like: We expect the IANA last allocation to the RIRs to occur in the first half of 2011 and ARIN to allocate its last block to its customers sometime in 2011.

And the next month it might say something slightly different, where the dates become a little bit narrower. The next month it might say something different with the dates a little bit narrower until we get there.

I’m hoping this will generate information for people, but also that we will start to generate press about this. In terms of notifying the CEOs with a letter, I’m not sure that a letter is really what is going to make a difference at this point.

From my personal opinion, I was involved and had the discussion with some people in my organization after the letter was received. I’m not sure that made a difference in the organization I was a part of at that time. What I really think is that people in different parts of different organizations need to maybe understand a little bit more that we’re here, we need to go.

And so I don’t think a letter is a bad idea. I also don’t necessarily think it’s the best idea. General press, getting it into CTOs’ hands, those kinds of things.

Paul Vixie: Thank you, Andrew. So noting that we have ten minutes until the room – until we’re over, I’d like to close the queues soon.

So Geoff.

Geoff Huston: Geoff Huston, APNIC. I’ve got two very unhelpful – very unhelpful observations for those who were looking for exhaustion dates of both the global pool of IANA and ARIN.

Oddly enough, the closer we get to exhaustion the more uncertain the prediction mechanism becomes. In 2009 when we allocated around 200 million IPv4 addresses, one quarter, 50 million, went to just 16 entities around the world.

Now, think about this for a second. When you do statistical projections, you’re relying on the law of very, very large numbers. And even though I did not behave precisely to the average, the room will.

But when the pool you’re trying to model gets very small, statistics fly out the door. And when the pool of addresses is down to 50 million, it only takes 16 people to make it go away tomorrow.

Yes, the current model that I have in the global pool says June 2011. It assumes a statistical behavior that has never been seen before in human history. It assumes that when the bank is about to run out of money, and it’s your money and you’re aware of that, you will all queue in an orderly fashion and not run for the door.

But that won’t happen. And there’s no statistics in the world that will help. So, yes, Tony has come out with a prediction of February. I can understand that and appreciate that.

I’ve come out with June. And, yes, it’s good math, but it’s not reality either. We can’t help you. We really cannot help you at this point. Because there are a very small number of folk with extraordinarily high demand and they don’t behave statistically.

Second problem: When is ARIN going to run out? It’s going to run out after APNIC. But think about this again for a second. Over in APNIC we’re currently allocating around 60 to 70 percent of the world’s v4 address resources. Our current sack rate is approximately 120 million addresses a year.

And when our particular aperture into the global pool closes, what will these global multinational corporations do? Oh, dear, there are no more addresses; I will shut up shop. Nonsense. There are four more doors that are still open. But no one, me or anyone else, no matter how you try and model that, is going to model the interaction of policy and pull.

I do know that any model of ARIN consumption will change as soon as APNIC exhausts. And so will RIPE’s and so will AFRINIC and LACNIC. But none of us can predict that. If you really want to understand when will ARIN exhaust, I don’t know, and nobody in this room knows.

It’s basically next year if you kind of don’t run on the bank this year. But there are 50 companies out there who, if they hit the registry system tomorrow, there are no addresses the day after. You have to appreciate this is a lot of little people and a very small number of very big people. And that makes prediction of exhaustion close to impossible with any accuracy.

So as we get closer to the date we have less and less of a clue as to when it will happen. Thank you.

Paul Vixie: Thank you, Geoff. Lee.

Lee Howard: Lee Howard, ARIN Board of Trustees and Time Warner Cable. I notice the existence of a document written by a clever fellow giving dates by which organizations may want to have certain operations available over IPv6. I describe the document as RFC 5211, 5211. You can enter that into your favorite IETF search engine and find it. The clever fellow is an employee of ARIN sitting next to Paul.

What I also wanted to suggest is if whether you believe letters to CEOs are a good mechanism or a bad mechanism, I certainly want to recognize the fantastic efforts by ARIN staff, and especially Richard and Megan, on going out doing outreach and explaining to people what’s going on.

If there are other things that we can do, and not just staff, we the Board, we the AC, we the other members of the community, I think we are extremely amenable to supporting those kinds of suggestions and requests.

For instance, I participated in a panel yesterday at NANOG describing not just that we know that runout is going to happen but here’s some of the things that you can do about it. And it’s true that most of them are bad and you probably need to do – you probably need to consider multi-dual stacking.

I participated in a panel last week with a small group of organizations – we had about 20 people there – and gave essentially a very similar panel that doesn’t just say you’re running out, you need to panic, but here’s things you can do about it, pros and cons of each of them. I think the message was well received.

So I would like to do that more. I’m certainly very open to doing that more and can bring in operators with experience and even content providers with experience who are very well spoken on the subject.

And, finally, the most important point I think is to make sure that we’re not simply saying “panic” but providing solutions and recommendations and speaking to people who aren’t within the community that participates at ARIN, because I suspect that the people in this room have heard the message fairly clearly and hopefully are all making their own plans already.

Thank you.

Paul Vixie: Thank you, Lee. Anything remote? Anything at the table? Owen.

Owen DeLong: On an unrelated topic, the Advisory Council is said to represent the community, not the membership of ARIN, and yet is elected by the membership, and not even the entire membership now, the resource-holding membership of ARIN.

I would like to suggest that we consider having the Advisory Council elected by resource holders rather than resource-holding members as a step in the direction of having us accountable to the community rather than just the membership.

Paul Vixie: Thank you, Owen. We’ll think hard about that. You, sir, on your knees. I always wanted to say that.

(Laughter.)

Matt Petach: I think that’s one of the least flattering introductions I have ever had.

(Laughter.)

Matt Petach: Matt Petach from Yahoo!, formerly on my knees. I just wanted to inform the ARIN community that we have just applied for a 4-byte ASN so we can test and finally get it current with this millennium. Thank you.

(Applause.)

Paul Vixie: Marty.

Martin Hannigan: Hi. Martin Hannigan. I think I’m just going to be myself this time.

This is great. I learned a lot of things I didn’t know. And I don’t know that this discussion is targeted at the people in this room, though, so let’s think big.

We’re all here because somebody thought big. And I think we need to keep thinking big. Last week at the NTI meeting in Washington, D.C. , somebody was assigned the task of coming up with a Board-readiness template that we ought to be seeing in 90 days. Perhaps ARIN will assist in the distribution of that and ensuring that that gets adequate press.

I’m hoping that we’ll get a PR update tomorrow during our Member Meeting so that we can see what activities are occurring with relation to ARIN press efforts.

And, most importantly, I do think you should send the letter again. The reason why is, again, you’re preaching to the choir in the room. And if we went off in the wrong direction and I set us off in the wrong direction, I’m sorry.

We all know that v4 is going to deplete and exhaust, and I think that we accept all the discussion here that it’s very hard to pinpoint. My intent was to just put a little extra pressure on you folks to kind of help out in respect to getting that date improved upon, if possible, not looking for a legal problem. But I think you should do the letters and do anything at all possible to convince the naysayer right until the day they drop dead.

Thank you.

Paul Vixie: Thank you, Martin.

I’ll turn it back to John for closing. That concludes open microphone.

Closing Announcements and Adjournment

John Curran: Okay. Wonderful discussion. Folks, last night we had a drawing at the social for the people who were there and donated by Shaw Communications. We have the prize. It is a wonderful Linksys Dual-N Band wireless router. I’m looking for v6 on the side. I can’t see it; might actually have it.

And the winner is Bill Herrin.

(Applause.)

Unidentified Speaker: Only way you can get v6 support on that is WRT.

John Curran: Yes. But we know it will install.

Okay. This actually concludes our meeting for the day. We’re going to resume tomorrow with the Members Meeting. And that will be 8:00 a.m. for breakfast, 9:00 a.m. in this room.

Thank you, everyone. Vote. Remember to vote for your AC and Board members. Okay? You’re on your own this evening. I’m sure you know how to be social. Enjoy.

(Meeting adjourned at 5:31 p.m.)

Network Sponsor